Prev: Issue with Altera flash programmer
Next: Quartus II - Generating Verilog from MegaWizard plugins
From: Sean Durkin on 4 Feb 2010 12:49
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
From: austin on 4 Feb 2010 17:33
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
From: Sean Durkin on 5 Feb 2010 03:59
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?).
From: Gabor on 5 Feb 2010 13:40
On Feb 5, 3:59 am, Sean Durkin <news_MO...(a)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 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?).

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
From: John_H on 5 Feb 2010 13:53
On Feb 5, 3:59 am, Sean Durkin <news_MO...(a)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=4 time
position. Changing to Done=6 got rid of the head scratching many,
many years ago.
 |  Next  |  Last
Pages: 1 2 3 4
Prev: Issue with Altera flash programmer
Next: Quartus II - Generating Verilog from MegaWizard plugins