Hi *,

I recently designed a board with a Virtex 5 on it, which I got back from
the assembly line a few days ago. This is not the first board I've
designed, and I've used many FPGA-boards from others before, but I've
never come across this problem:

FPGA configuration via JTAG will only work if the bitfile is generated
with the DONE_cycle=6 option set. If I leave the default setting of 4,
iMPACT will happily download the bitstream and will claim everything was
successful. I can read back the bitstream, read out device ID and
usercode, but the device itself is dead, i.e. none of the IOs are
responding and so on.

With ChipScope you can read out the internal configuration status
register, and as it turns out it seems that using the default bitgen
settings, FPGA configuration stops in cycle 4 when done goes high, but
does not reach the states where the IOs are enabled and so on.

The question is: Why is that? Is it a bug in iMPACT? Does it stop
clocking the configuration logic too soon? If so, why doesn't this
happen on any other boards?

The board itself works flawlessly, I just want to make sure there's no
underlying design issue I'm missing that can cause this.

Does anyone have any insight into this?

cu,
Sean

Sean,

Do you have the "wait for DCM's to lock before releasing DONE" option
set?

Sometimes this gets in the way, as the part is waiting for LOCKED
before it even releases GTS, and GSR.  Easier is to force the DCM's to
reset after DONE goes high by driving reset with a startup signal that
you generate.

By moving DONE till after GTS, you are getting the DCM's to start
up ... or that is my best guess.

Austin

austin wrote:
> Sean,
> 
> Do you have the "wait for DCM's to lock before releasing DONE" option
> set?
Nope. In fact, I'm not even using any DCMs in my test-design. For first
tests in the lab, I'm just driving some LEDs statically. No clock, no reset.

The problem is that in fact "done" IS released, but GTS and GSR aren't
disabled. It looks like configuration stops in the middle of the startup
cycle, i.e. after "DONE", but before GTS and GSR are disabled.

But iMPACT claims everything's fine, and configuration was successful.

> Sometimes this gets in the way, as the part is waiting for LOCKED
> before it even releases GTS, and GSR.  Easier is to force the DCM's to
> reset after DONE goes high by driving reset with a startup signal that
> you generate.
Hmm, how can the DCMs even lock if GTS is still active, i.e. clock
inputs are
still disabled?

> By moving DONE till after GTS, you are getting the DCM's to start
> up ... or that is my best guess.
What I don't get is that iMPACT claims it's done. Seems to me that it just
watches for "DONE", and then stops, even though the startup sequence
isn't finished yet. If it were waiting for DCMs to lock or something
else, I'd expect it would get stuck at 99% or stop after a timeout with
a "failed" message or something.

This just had me stuck for 2 days, measuring ripple on my supply,
checking my clocks, checking the layout and so on. I probably would've
sent the board out for x-rays to check for soldering issues next, hadn't
I by chance run across a colleague in the corridor who had the same
problem 5 years ago.

cu,
Sean

-- 
Replace "MONTH" with the three-letter abbreviation of the current month
and the two-digit code for the current year (simple, eh?).

On Feb 5, 3:59=A0am, Sean Durkin
<news_MO...@tuxroot.de> wrote:
> austin wrote:
> > Sean,
>
> > Do you have the "wait for DCM's to lock before releasing DONE" option
> > set?
>
> Nope. In fact, I'm not even using any DCMs in my test-design. For first
> tests in the lab, I'm just driving some LEDs statically. No clock, no res=
et.
>
> The problem is that in fact "done" IS released, but GTS and GSR aren't
> disabled. It looks like configuration stops in the middle of the startup
> cycle, i.e. after "DONE", but before GTS and GSR are disabled.
>
> But iMPACT claims everything's fine, and configuration was successful.
>
> > Sometimes this gets in the way, as the part is waiting for LOCKED
> > before it even releases GTS, and GSR. =A0Easier is to force the DCM's t=
o
> > reset after DONE goes high by driving reset with a startup signal that
> > you generate.
>
> Hmm, how can the DCMs even lock if GTS is still active, i.e. clock
> inputs are
> still disabled?
>
> > By moving DONE till after GTS, you are getting the DCM's to start
> > up ... or that is my best guess.
>
> What I don't get is that iMPACT claims it's done. Seems to me that it jus=
t
> watches for "DONE", and then stops, even though the startup sequence
> isn't finished yet. If it were waiting for DCMs to lock or something
> else, I'd expect it would get stuck at 99% or stop after a timeout with
> a "failed" message or something.
>
> This just had me stuck for 2 days, measuring ripple on my supply,
> checking my clocks, checking the layout and so on. I probably would've
> sent the board out for x-rays to check for soldering issues next, hadn't
> I by chance run across a colleague in the corridor who had the same
> problem 5 years ago.
>
> cu,
> Sean
>
> --
> Replace "MONTH" with the three-letter abbreviation of the current month
> and the two-digit code for the current year (simple, eh?).

I have seen this exact problem with embedded programming.  The
processor
would stop CCLK (slave serial in this case, but the same idea) as soon
as it saw DONE, but it would only check for DONE starting after the
last bit of the configuration bitstream.  The problem only showed up
for some iterations of the design, because apparently the bitstream
doesn't always end on a byte boundary and the number of extra bits
might or might not be enough to clock the FPGA into the end of the
startup sequence.

Regards,
Gabor

On Feb 5, 3:59=A0am, Sean Durkin
<news_MO...@tuxroot.de> wrote:
>
> This just had me stuck for 2 days, measuring ripple on my supply,
> checking my clocks, checking the layout and so on. I probably would've
> sent the board out for x-rays to check for soldering issues next, hadn't
> I by chance run across a colleague in the corridor who had the same
> problem 5 years ago.

So did you solve your problem then?  The title suggests the problem
was found.

A system which stops generating a clock once the done pin goes high
still needs a couple more clocks with the default Done=3D4 time
position.  Changing to Done=3D6 got rid of the head scratching many,
many years ago.

On Feb 5, 1:53=A0pm, John_H
<newsgr...@johnhandwork.com> wrote:
> On Feb 5, 3:59=A0am, Sean Durkin <news_MO...@tuxroot.de> wrote:
>
>
>
> > This just had me stuck for 2 days, measuring ripple on my supply,
> > checking my clocks, checking the layout and so on. I probably would've
> > sent the board out for x-rays to check for soldering issues next, hadn'=
t
> > I by chance run across a colleague in the corridor who had the same
> > problem 5 years ago.
>
> So did you solve your problem then? =A0The title suggests the problem
> was found.
>
> A system which stops generating a clock once the done pin goes high
> still needs a couple more clocks with the default Done=3D4 time
> position. =A0Changing to Done=3D6 got rid of the head scratching many,
> many years ago.

Just remember that there was a reason for the default setting,
namely to allow an orderly startup of multiple devices.  If
you're only starting up one device on this configuration chain
there's no need to delay startup until after DONE goes high.

John_H wrote:
> So did you solve your problem then?  The title suggests the problem
> was found.
Yes, it just took me awhile to get there.

> A system which stops generating a clock once the done pin goes high
> still needs a couple more clocks with the default Done=4 time
> position. 
As I said, I've never seen this before when using iMPACT. I'd expect it
would know how many clock cycles are needed.

When uploading the bitstream with a microcontroller or something, I
always keep clocking for awhile after the bitfile is transferred, but
with iMPACT (which I use in the lab for quick first tests before the
rest of the infrastructure is up and running) this has never been
necessary. Nor have I ever had to fiddle with the startup sequence before.

> Changing to Done=6 got rid of the head scratching many,
> many years ago.
Well, I've never needed that setting until now. I guess I've done about
ten boards myself and used a dozen others, and never changed that setting.

The question is: why does this happen on this particular board and not
on any others I've ever encountered? Just trying to understand where
this comes from.

cu,
Sean

-- 
Replace "MONTH" with the three-letter abbreviation of the current month
and the two-digit code for the current year (simple, eh?).

Gabor wrote:
> I have seen this exact problem with embedded programming.  The
> processor
> would stop CCLK (slave serial in this case, but the same idea) as soon
> as it saw DONE, but it would only check for DONE starting after the
> last bit of the configuration bitstream.  The problem only showed up
> for some iterations of the design, because apparently the bitstream
> doesn't always end on a byte boundary and the number of extra bits
> might or might not be enough to clock the FPGA into the end of the
> startup sequence.
I've had this happen when using .bit-files, since they include stuff
like date and project name, which I usually auto-generate in a script
wenn running the flow, hence the size varies. But these days I usually
only program bin-files, since then that problem went away at least.

But anyway, shouldn't iMPACT be smart enough to know how many clock
cycles are needed? And why doesn't it complete the rest of the startup
sequence only on this one particular board?

Maybe it's just a bug in IMPACT... :)

cu,
Sean

-- 
Replace "MONTH" with the three-letter abbreviation of the current month
and the two-digit code for the current year (simple, eh?).

Sean Durkin wrote:
>
> With ChipScope you can read out the internal configuration status
>
Note, you can also read the status in Impact 10.1 with:
 Debug->Read Device Status

FWIW another of my favorite Impact 10.1 settings is
 Edit->Preferences->Configuration Preferences->
 Startup Clock->Automatic Correction

>
> The question is: Why is that? Is it a bug in iMPACT? Does it
> stop clocking the configuration logic too soon? If so, why
> doesn't this happen on any other boards?
>
 If your normal method of configuration works fine, I wouldn't
worry too much about curable JTAG issues like that.

 I've seen that same sort of problem on a multi-chip V5
DONE cascade with Impact 10.1:
 http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/2a291d5c38abbd3c

And also on a Digilent S3 board when using their JTAG S/W:
 http://groups.google.com/group/comp.arch.fpga/msg/b06ca9faf716c347
 http://groups.google.com/group/comp.arch.fpga/msg/8f9c895ece739c6e

-------------

Random debug thoughts:

Configuration mode
 - are the chip mode pins set to JTAG, or another boot mode?
 - does changing the mode pins to JTAG affect the problem?

External DONE timing/levels
 - what value of pullup do you have on DONE pin?
 - are you using the "drive DONE" bitgen option?
 - what does the DONE risetime look like on the board?
 - have you tried the 'internal done pipe' bitgen option?
 - what happpens if you lower the JTAG clock rate?
 - is your DONE LED buffered? ( I've seen some boards with
   DONE LED hookups that load down the external DONE signal )

Brian

Hi Brian,

thanks for a lot of useful pointers! See my responses below.

Brian Davis wrote:
> FWIW another of my favorite Impact 10.1 settings is
>  Edit->Preferences->Configuration Preferences->
>  Startup Clock->Automatic Correction
I think that's the default in ISE11 now, as it should be.

>  If your normal method of configuration works fine, I wouldn't
> worry too much about curable JTAG issues like that.
The thing is that I'm using configuration via SPI flash on this board. I
 was planning to use indirect SPI programming for initial flashing, but
it doesn't work. iMPACT downloads the JTAG->SPI-core-bitfile and then
just quits with "Programming failed", without giving any more detail.

I suspect this is because the loading of the JTAG->SPI-core fails
because of the issue I'm having on this board. If the bitfile shipped
with iMPACT wasn't created with the DONE_cyle:6-setting, it won't work
on this board.

Fortunately, I have a dedicated SPI programming connector on the board
as well, so I can use that for flashing. Loading the FPGA through SPI
works fine.

>  I've seen that same sort of problem on a multi-chip V5
> DONE cascade with Impact 10.1:
>  http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/2a291d5c38abbd3c
Only one V5 on this board.

> -------------
> 
> Random debug thoughts:
> 
> Configuration mode
>  - are the chip mode pins set to JTAG, or another boot mode?
>  - does changing the mode pins to JTAG affect the problem?
Mode pins are set to SPI, but changing to JTAG or master serial makes no
difference.

> External DONE timing/levels
>  - what value of pullup do you have on DONE pin?
Originally I had the 300 Ohms Xilinx has in their application notes, but
I've tried different values up to 10k without success.

>  - are you using the "drive DONE" bitgen option?
Nope, I'll try that tomorrow. But of course I can't change it for the
JTAG->SPI bitfile shipped with iMPACT. Or is there a way to manipulate
settings like that in an existing bitfile? Theoretically this should be
possible by changing some bits and recalculating the CRC, but is this
documented somewhere?

>  - have you tried the 'internal done pipe' bitgen option?
Yes, no change.

>  - what does the DONE risetime look like on the board?
>  - what happpens if you lower the JTAG clock rate?
No change.

>  - is your DONE LED buffered? ( I've seen some boards with
>    DONE LED hookups that load down the external DONE signal )
I don't have it buffered, but I have a transistor hooked up to it to
light up a LED when donfiguration is done.

cu,
Sean

-- 
Replace "MONTH" with the three-letter abbreviation of the current month
and the two-digit code for the current year (simple, eh?).