Prev: Issue with Altera flash programmer
Next: Quartus II - Generating Verilog from MegaWizard plugins
From: Gabor on 5 Feb 2010 15:40
On Feb 5, 1:53 pm, John_H <newsgr...(a)johnhandwork.com> wrote:
> 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.

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.
From: Sean Durkin on 5 Feb 2010 17:24
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?).
From: Sean Durkin on 5 Feb 2010 17:43
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?).
From: Brian Davis on 7 Feb 2010 23:04
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
From: Sean Durkin on 9 Feb 2010 11:36
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?).
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Issue with Altera flash programmer
Next: Quartus II - Generating Verilog from MegaWizard plugins