Looking for consultant

Slavisa Zigic wrote:

Could you be a little more specific? I'm always willing to do
electronics for money, but I may not be the best choice to tackle your
particular problem, whatever it is.

Bill Sloman, Nijmegen

 

[Nial Stewart]

<bill.sloman@ieee.org> wrote in message
news:1110992431.576549.285340@z14g2000cwz.googlegroups.com...

Slavisa Zigic wrote:
Could you be a little more specific? I'm always willing to do
electronics for money, but I may not be the best choice to tackle your
particular problem, whatever it is.
Bill Sloman, Nijmegen

My background's FPGA design, but I'm willing to try an appendectomy if he'll
cover the insurance, I lived with a load of doctors through university so something's
bound to have rubbed off


Nial.

 

[Slavisa Zigic]

Nial Stewart <nial@nialstewartdevelopments.co.uk> wrote:
: <bill.sloman@ieee.org> wrote in message
: news:1110992431.576549.285340@z14g2000cwz.googlegroups.com...
:> Slavisa Zigic wrote:
:> Could you be a little more specific? I'm always willing to do
:> electronics for money, but I may not be the best choice to tackle your
:> particular problem, whatever it is.
:> Bill Sloman, Nijmegen


: My background's FPGA design, but I'm willing to try an appendectomy if he'll
: cover the insurance, I lived with a load of doctors through university so something's
: bound to have rubbed off


: Nial.

We are looking for consultant who will be able to solve the following
problem:

PCB with Xilinx Virtex II and EPROMS. EPROMS are loaded with bitstream
through JTAG. Once PCB is powered up, FPGA will have problems loading core.
Nature of the problems is intermittent. Sometimes it will load core,
sometimes it will not. When it doesn't load the core, it reports CRC error.
When it loads the core, everything works perfectly.

We are looking for experienced consultant (PCB, digital electronics, FPGA,
10+ yrs. of experience).

Contact:

Slavisa Zigic
email: ziga@cfrsi.com
tel: 703-385-4493

 

[John Larkin]

On 16 Mar 2005 23:43:56 GMT, Slavisa Zigic <szigic@nyx.net> wrote:

Nial Stewart <nial@nialstewartdevelopments.co.uk> wrote:
: <bill.sloman@ieee.org> wrote in message
: news:1110992431.576549.285340@z14g2000cwz.googlegroups.com...
:> Slavisa Zigic wrote:
:> Could you be a little more specific? I'm always willing to do
:> electronics for money, but I may not be the best choice to tackle your
:> particular problem, whatever it is.
:> Bill Sloman, Nijmegen


: My background's FPGA design, but I'm willing to try an appendectomy if he'll
: cover the insurance, I lived with a load of doctors through university so something's
: bound to have rubbed off


: Nial.

We are looking for consultant who will be able to solve the following
problem:

PCB with Xilinx Virtex II and EPROMS. EPROMS are loaded with bitstream
through JTAG. Once PCB is powered up, FPGA will have problems loading core.
Nature of the problems is intermittent. Sometimes it will load core,
sometimes it will not. When it doesn't load the core, it reports CRC error.
When it loads the core, everything works perfectly.

We are looking for experienced consultant (PCB, digital electronics, FPGA,
10+ yrs. of experience).

Contact:

Slavisa Zigic
email: ziga@cfrsi.com
tel: 703-385-4493

Try hanging a small capacitor, 33 pf maybe, from the jtag clock pin to
ground at the FPGA.

John

 

[Joerg]

Hello Slavisa,

Just a hint from a guy who is not an FPGA expert. Sometimes these kinds
of problems are not digital. There could also be issues with, for
example, the power supply rail during or shortly after power-up. Timing
issues are another area to look at. Same for the transmission lines if
the EPROM is far away from the Virtex chip.

Regards, Joerg

http://www.analogconsultants.com

 

Although you don't explicitly say so, you appear to be working
somewhere within the United States of America.

Your problem seems to lie in the data transfer between between the
EPROMs containing the programming data for the Virtex II FPGA and the
FPGA itself.

Since the transfer sometimes works, the proportion of bits being
corrupted during transfer has to be very low. You are going to have to
hang a scope probe on the connection and look at the analog signal to
get some kind of idea of the way the data is being corrupted.

This is hands-on work, and the chance that I could offer much help from
the Nijmegen in the Netherlands is not all that high - though modern
scopes digitise the signals that they look at and can be persuaded to
turn the screen image into an e-mailable file.

You've already had a couple of pieces of useful advice - John Larkin
and Joerg both know what they are talking about - and should be able to
get more.

------------
Bill Sloman, Nijmegen

 

[Nial Stewart]

We are looking for consultant who will be able to solve the following
problem:

PCB with Xilinx Virtex II and EPROMS. EPROMS are loaded with bitstream
through JTAG. Once PCB is powered up, FPGA will have problems loading core.
Nature of the problems is intermittent. Sometimes it will load core,
sometimes it will not. When it doesn't load the core, it reports CRC error.
When it loads the core, everything works perfectly.

This sounds like a signal integrity issue, like the others have said it'll probably
take a bit of hands on analysis and I'm based in Edinburgh, UK. If you're willing
to pay for flights I'll come and visit

Some things to look at....

These config signals can be relatively fast, especially if you're using a
serial configuration scheme. It's important to consider this when placing
devices and routing signals.

How far away ftom the FPGA is the configuration device?

Are the config signals routed carefully over a continuous ground plane?

Are there signals with fast edges close to your config signals that could
be inducing noise on your signal lines?

If noise is being coupled onto your clock line John's suggestion of a small
cap at the FPGA might be worth trying to decouple it a bit.

Some of the Xilinx config devices allow you to specify what the configuration clock
speed is. If this option is available it could be worth slowing the configuration
down to see if it helps. This is a bit of a bodge though, if things seem to be better
I wouldn't rely on this to give guaranteed 100% performance. You still need to
clear up the signal intergity problems.

If you're really stuck it's probably worth contacting your local Xilinx FAE. They
should be able to help or know of local consultants that will give you a hand.

Hope this helps,

Nial

-------------------------------------------------------------
Nial Stewart Developments Ltd
FPGA and High Speed Digital Design
www.nialstewartdevelopments.co.uk

 

[Greg Neff]

On 16 Mar 2005 23:43:56 GMT, Slavisa Zigic <szigic@nyx.net> wrote:

Nial Stewart <nial@nialstewartdevelopments.co.uk> wrote:
: <bill.sloman@ieee.org> wrote in message
: news:1110992431.576549.285340@z14g2000cwz.googlegroups.com...
:> Slavisa Zigic wrote:
:> Could you be a little more specific? I'm always willing to do
:> electronics for money, but I may not be the best choice to tackle your
:> particular problem, whatever it is.
:> Bill Sloman, Nijmegen


: My background's FPGA design, but I'm willing to try an appendectomy if he'll
: cover the insurance, I lived with a load of doctors through university so something's
: bound to have rubbed off


: Nial.

We are looking for consultant who will be able to solve the following
problem:

PCB with Xilinx Virtex II and EPROMS. EPROMS are loaded with bitstream
through JTAG. Once PCB is powered up, FPGA will have problems loading core.
Nature of the problems is intermittent. Sometimes it will load core,
sometimes it will not. When it doesn't load the core, it reports CRC error.
When it loads the core, everything works perfectly.

We are looking for experienced consultant (PCB, digital electronics, FPGA,
10+ yrs. of experience).

Contact:

Slavisa Zigic
email: ziga@cfrsi.com
tel: 703-385-4493

Judging by your website, it looks like you have a company full of
PhDs. You should have the smarts there to figure this out.

You could have a voltage incompatibility, power supply startup
problem, signal integrity problem, control signal problem, etc.
Search 'configuration' on the Xilinx website.

================================

Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com

 

[Fred Bloggs]

Slavisa Zigic wrote:

We are looking for experienced consultant (PCB, digital electronics, FPGA,
10+ yrs. of experience).

No you're not looking for an experienced consultant, most of whom are
near worthless. You are looking for an intelligent person with a track
record of fixing problems. Your problem is either layout or turn-on
sequencing related, trivial whatever the case. Just find someone who can
pay attention to detail and make measurements, with enough background to
characterize the engineering parameters so as to make a permanent fix
that works through production. The damned "job" won't take half a day,
and that with a liberal frequency of coffee breaks.

 

[Rob Gaddi]

PCB with Xilinx Virtex II and EPROMS. EPROMS are loaded with bitstream
through JTAG. Once PCB is powered up, FPGA will have problems loading core.
Nature of the problems is intermittent. Sometimes it will load core,
sometimes it will not. When it doesn't load the core, it reports CRC error.
When it loads the core, everything works perfectly.

We are looking for experienced consultant (PCB, digital electronics, FPGA,
10+ yrs. of experience).

Do you have any power-on reset to make sure the power rails are stable
before you start trying to load the configuration? The pin is called
PROG_B on the Spartan-3 series, I'm sure the Virtex II has something
similar.

If so, have you scoped to make sure that the pin is in fact being held
low for long enough for the rails to be stable?

 

[Nico Coesel]

Slavisa Zigic <szigic@nyx.net> wrote:

Nial Stewart <nial@nialstewartdevelopments.co.uk> wrote:
: <bill.sloman@ieee.org> wrote in message
: news:1110992431.576549.285340@z14g2000cwz.googlegroups.com...
:> Slavisa Zigic wrote:
:> Could you be a little more specific? I'm always willing to do
:> electronics for money, but I may not be the best choice to tackle your
:> particular problem, whatever it is.
:> Bill Sloman, Nijmegen


: My background's FPGA design, but I'm willing to try an appendectomy if he'll
: cover the insurance, I lived with a load of doctors through university so something's
: bound to have rubbed off


: Nial.

We are looking for consultant who will be able to solve the following
problem:

PCB with Xilinx Virtex II and EPROMS. EPROMS are loaded with bitstream
through JTAG. Once PCB is powered up, FPGA will have problems loading core.
Nature of the problems is intermittent. Sometimes it will load core,
sometimes it will not. When it doesn't load the core, it reports CRC error.
When it loads the core, everything works perfectly.

We are looking for experienced consultant (PCB, digital electronics, FPGA,
10+ yrs. of experience).

I'm very very familiar with that problem. You need a power supply
capable of delivering at least the maximum current for each Xilinx
device when programming through JTAG.
I even managed to crash and literally burn several Xilinx Spartan 2E
devices while implementing the JTAG programming algorithm just by
trying to program them.
In short: stay away from programming Xilinx devices through JTAG. The
JTAG implementation is buggy and may also vary between devices. For
instance the algorithm described for Virtex and Spartan 2 devices
doesn't work for Spartan 2E devices.
Either use parallel programming or the serial programming through DIN
if you want something stable.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

 

[John Larkin]

On Thu, 17 Mar 2005 20:35:49 GMT, nico@puntnl.niks (Nico Coesel)
wrote:

I'm very very familiar with that problem. You need a power supply
capable of delivering at least the maximum current for each Xilinx
device when programming through JTAG.
I even managed to crash and literally burn several Xilinx Spartan 2E
devices while implementing the JTAG programming algorithm just by
trying to program them.
In short: stay away from programming Xilinx devices through JTAG. The
JTAG implementation is buggy and may also vary between devices. For
instance the algorithm described for Virtex and Spartan 2 devices
doesn't work for Spartan 2E devices.

2E's also have the crazy powerup current surge, wherein they look like
millifarads of capacitance as you try to grunt them up. I think
they've fixed that on the Spartan 3's. I sure hope they have.

We always use slave serial config mode, and it works. I did have one
board that needed a cap to ground (or a serious termination, that
worked too) on the config clock line; never understood why.

Can you really program a Xilinx chip to fry itself? Neat.

John

 

[Greg Neff]

On Thu, 17 Mar 2005 18:26:54 -0800, John Larkin
<jjSNIPlarkin@highTHISlandPLEASEtechnology.XXX> wrote:

On Thu, 17 Mar 2005 20:35:49 GMT, nico@puntnl.niks (Nico Coesel)
wrote:


I'm very very familiar with that problem. You need a power supply
capable of delivering at least the maximum current for each Xilinx
device when programming through JTAG.
I even managed to crash and literally burn several Xilinx Spartan 2E
devices while implementing the JTAG programming algorithm just by
trying to program them.
In short: stay away from programming Xilinx devices through JTAG. The
JTAG implementation is buggy and may also vary between devices. For
instance the algorithm described for Virtex and Spartan 2 devices
doesn't work for Spartan 2E devices.

2E's also have the crazy powerup current surge, wherein they look like
millifarads of capacitance as you try to grunt them up. I think
they've fixed that on the Spartan 3's. I sure hope they have.

We always use slave serial config mode, and it works. I did have one
board that needed a cap to ground (or a serious termination, that
worked too) on the config clock line; never understood why.

Can you really program a Xilinx chip to fry itself? Neat.

John


The OP stated that they are using JTAG to program the PROM, not the

FPGA. The mechanism used to configure the FPGA from the PROM was.not
clearly stated.

You certainly can program an FPGA to be a toaster, Just tie lots of
internal outputs together, and attempt to drive them to different
states.

By the way, I would not try using a capacitor on a Xilinx FPGA clock
input. The Xilinx inputs are blindin/screamin/honkin/biteyerass fast.
They have no hysteresis, no patience, and no sympathy. Xilinx doesn't
have Doc Johnson on retainer for nothing. The capacitor will reduce
the amplitude of an aggressor signal, but it will also slow the clock
transition time. This will have the effect of increasing the time at
which the input sits near the transition voltage, widening the window
in which the input will be susceptible to an aggressor. I have seen a
small capacitor make the problem significantly worse. On the bright
side, this makes it easier to identify the aggressor.

================================

Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com

 

[John Larkin]

On Thu, 17 Mar 2005 21:59:20 -0500, Greg Neff <greg@nospam.com> wrote:

On Thu, 17 Mar 2005 18:26:54 -0800, John Larkin
jjSNIPlarkin@highTHISlandPLEASEtechnology.XXX> wrote:

On Thu, 17 Mar 2005 20:35:49 GMT, nico@puntnl.niks (Nico Coesel)
wrote:


I'm very very familiar with that problem. You need a power supply
capable of delivering at least the maximum current for each Xilinx
device when programming through JTAG.
I even managed to crash and literally burn several Xilinx Spartan 2E
devices while implementing the JTAG programming algorithm just by
trying to program them.
In short: stay away from programming Xilinx devices through JTAG. The
JTAG implementation is buggy and may also vary between devices. For
instance the algorithm described for Virtex and Spartan 2 devices
doesn't work for Spartan 2E devices.

2E's also have the crazy powerup current surge, wherein they look like
millifarads of capacitance as you try to grunt them up. I think
they've fixed that on the Spartan 3's. I sure hope they have.

We always use slave serial config mode, and it works. I did have one
board that needed a cap to ground (or a serious termination, that
worked too) on the config clock line; never understood why.

Can you really program a Xilinx chip to fry itself? Neat.

John


The OP stated that they are using JTAG to program the PROM, not the
FPGA. The mechanism used to configure the FPGA from the PROM was.not
clearly stated.

You certainly can program an FPGA to be a toaster, Just tie lots of
internal outputs together, and attempt to drive them to different
states.

By the way, I would not try using a capacitor on a Xilinx FPGA clock
input. The Xilinx inputs are blindin/screamin/honkin/biteyerass fast.
They have no hysteresis, no patience, and no sympathy. Xilinx doesn't
have Doc Johnson on retainer for nothing. The capacitor will reduce
the amplitude of an aggressor signal, but it will also slow the clock
transition time. This will have the effect of increasing the time at
which the input sits near the transition voltage, widening the window
in which the input will be susceptible to an aggressor. I have seen a
small capacitor make the problem significantly worse. On the bright
side, this makes it easier to identify the aggressor.

It was CCLK, the serial configuration clock, that I had to bypass.
Without that, the configuration was intermittent, sort of what the OP
describes. I discovered it accidentally by poking it with a 1x scope
probe; as long as I held the probe on the pin, it would configure
every time. So then I scoped it with a 500 MHz scope and a 1GHz fet
probe, and it looked fine, no nasty ringing or anything, and
setup/hold times were huge. So we just ECOd the cap onto all the
boards.

I hate stuff like that; never did understand it.

John

 

[Winfield Hill]

John Larkin wrote...

By the way, I would not try using a capacitor on a Xilinx FPGA clock
input. The Xilinx inputs are blindin/screamin/honkin/biteyerass fast.
They have no hysteresis, no patience, and no sympathy. Xilinx doesn't
have Doc Johnson on retainer for nothing. The capacitor will reduce
the amplitude of an aggressor signal, but it will also slow the clock
transition time. This will have the effect of increasing the time at
which the input sits near the transition voltage, widening the window
in which the input will be susceptible to an aggressor. I have seen
a small capacitor make the problem significantly worse. On the bright
side, this makes it easier to identify the aggressor.

It was CCLK, the serial configuration clock, that I had to bypass.
Without that, the configuration was intermittent, sort of what the OP
describes. I discovered it accidentally by poking it with a 1x scope
probe; as long as I held the probe on the pin, it would configure
every time. So then I scoped it with a 500 MHz scope and a 1GHz fet
probe, and it looked fine, no nasty ringing or anything, and
setup/hold times were huge. So we just ECOd the cap onto all the
boards.

I hate stuff like that; never did understand it.

No doubt your small-size cap made little difference in the risetime,
but perhaps it lowered Zclock, and prevented double-clocking on edges.


--
Thanks,
- Win

 

[Greg Neff]

On Thu, 17 Mar 2005 19:27:38 -0800, John Larkin
<jjSNIPlarkin@highTHISlandPLEASEtechnology.XXX> wrote:

(snip)

It was CCLK, the serial configuration clock, that I had to bypass.
Without that, the configuration was intermittent, sort of what the OP
describes. I discovered it accidentally by poking it with a 1x scope
probe; as long as I held the probe on the pin, it would configure
every time. So then I scoped it with a 500 MHz scope and a 1GHz fet
probe, and it looked fine, no nasty ringing or anything, and
setup/hold times were huge. So we just ECOd the cap onto all the
boards.

I hate stuff like that; never did understand it.

John

With subtle crosstalk problems you can stare at a signal until you are
blue in the face, use all your fancy triggers, and still not see it.

I track these down by first examining the PCB layout. I make a list
of all signals that are physically close enough to be crosstalk
hazards. I then take my best guess as to which one is the likely
culprit and start there. In some cases it can be a group of signals
that transition simultaneously, like an address bus.

You then need a 2 channel fast DSO and a pair of FET probes. Set the
scope to edge trigger on channel 1(first try falling edge, then try
rising edge). Connect channel 2 to your victim signal (in this case
CCLK). Now use channel 1 to look at your potential aggressors. You
will now clearly see any crosstalk on your victim. The crosstalk
will affect a clock only if it is coincident with the clock edge, but
if you can observe the crosstalk while the clock is high or low, and
the signals are asynchronous to each other, then you know that the
crosstalk will also affect the clock during its transition.

================================

Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com

 

[Brijesh]

Winfield Hill wrote:

John Larkin wrote...

By the way, I would not try using a capacitor on a Xilinx FPGA clock
input. The Xilinx inputs are blindin/screamin/honkin/biteyerass fast.
They have no hysteresis, no patience, and no sympathy. Xilinx doesn't
have Doc Johnson on retainer for nothing. The capacitor will reduce
the amplitude of an aggressor signal, but it will also slow the clock
transition time. This will have the effect of increasing the time at
which the input sits near the transition voltage, widening the window
in which the input will be susceptible to an aggressor. I have seen
a small capacitor make the problem significantly worse. On the bright
side, this makes it easier to identify the aggressor.

It was CCLK, the serial configuration clock, that I had to bypass.
Without that, the configuration was intermittent, sort of what the OP
describes. I discovered it accidentally by poking it with a 1x scope
probe; as long as I held the probe on the pin, it would configure
every time. So then I scoped it with a 500 MHz scope and a 1GHz fet
probe, and it looked fine, no nasty ringing or anything, and
setup/hold times were huge. So we just ECOd the cap onto all the
boards.

I hate stuff like that; never did understand it.


No doubt your small-size cap made little difference in the risetime,
but perhaps it lowered Zclock, and prevented double-clocking on edges.

Pretty good discussion and helpful hints?
Was following everything till now, whats a Zclock?

Thanks
Brijesh

 

[Winfield Hill]

Brijesh wrote...

Was following everything till now, whats a Zclock?

The impedance of the clock line.


--
Thanks,
- Win

 

[Mac]

On Fri, 18 Mar 2005 09:04:30 -0500, Greg Neff wrote:

On Thu, 17 Mar 2005 19:27:38 -0800, John Larkin
jjSNIPlarkin@highTHISlandPLEASEtechnology.XXX> wrote:

(snip)

It was CCLK, the serial configuration clock, that I had to bypass.
Without that, the configuration was intermittent, sort of what the OP
describes. I discovered it accidentally by poking it with a 1x scope
probe; as long as I held the probe on the pin, it would configure
every time. So then I scoped it with a 500 MHz scope and a 1GHz fet
probe, and it looked fine, no nasty ringing or anything, and
setup/hold times were huge. So we just ECOd the cap onto all the
boards.

I hate stuff like that; never did understand it.

John


With subtle crosstalk problems you can stare at a signal until you are
blue in the face, use all your fancy triggers, and still not see it.

I track these down by first examining the PCB layout. I make a list
of all signals that are physically close enough to be crosstalk
hazards. I then take my best guess as to which one is the likely
culprit and start there. In some cases it can be a group of signals
that transition simultaneously, like an address bus.

You then need a 2 channel fast DSO and a pair of FET probes. Set the
scope to edge trigger on channel 1(first try falling edge, then try
rising edge). Connect channel 2 to your victim signal (in this case
CCLK). Now use channel 1 to look at your potential aggressors. You
will now clearly see any crosstalk on your victim. The crosstalk
will affect a clock only if it is coincident with the clock edge, but
if you can observe the crosstalk while the clock is high or low, and
the signals are asynchronous to each other, then you know that the
crosstalk will also affect the clock during its transition.

================================

Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com

Very interesting. Thank you for sharing that!

--Mac

 

[Greg Neff]

On 18 Mar 2005 05:40:40 -0800, Winfield Hill
<hill_a@t_rowland-dotties-harvard-dot.s-edu> wrote:

John Larkin wrote...

By the way, I would not try using a capacitor on a Xilinx FPGA clock
input. The Xilinx inputs are blindin/screamin/honkin/biteyerass fast.
They have no hysteresis, no patience, and no sympathy. Xilinx doesn't
have Doc Johnson on retainer for nothing. The capacitor will reduce
the amplitude of an aggressor signal, but it will also slow the clock
transition time. This will have the effect of increasing the time at
which the input sits near the transition voltage, widening the window
in which the input will be susceptible to an aggressor. I have seen
a small capacitor make the problem significantly worse. On the bright
side, this makes it easier to identify the aggressor.

It was CCLK, the serial configuration clock, that I had to bypass.
Without that, the configuration was intermittent, sort of what the OP
describes. I discovered it accidentally by poking it with a 1x scope
probe; as long as I held the probe on the pin, it would configure
every time. So then I scoped it with a 500 MHz scope and a 1GHz fet
probe, and it looked fine, no nasty ringing or anything, and
setup/hold times were huge. So we just ECOd the cap onto all the
boards.

I hate stuff like that; never did understand it.

No doubt your small-size cap made little difference in the risetime,
but perhaps it lowered Zclock, and prevented double-clocking on edges.

The cap does make some difference in the rise time, especially if the
clock signal has an added source termination resistor. Your are right
that it is not a big change, but it doesn't take much when dealing
with these high-strung FPGA inputs.

If there was enough ringing on the signal to cause double clocking,
indicating that the clock signal was poorly terminated, then John
would have seen this on the DSO. The FET probe capacitance would not
have made this invisible.

In John's case my money is on crosstalk.

In the OP's case, it could be any one of several things.

================================

Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com