From: ghelbig on
On Feb 9, 8:36 am, Sean Durkin <news_MO...(a)tuxroot.de> wrote:
> 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/2a291...
>
> 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?).

FWIW: I spent 3 days debugging an isse (see: "XST is driving me
crazy" in this usenet group) that was resolved by adding one more
clock to the startup stream.

In my configuration, done would go high and all of the combitorial
logic would word, but none of the sequential logic would work.

One more (extra) CCLK, and everythig went working.

G.
From: Brian Davis on
Sean Durkin wrote:
>
>> 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.
>
Values lower than 300 ( down to maybe(?) 100 ohms ) would help
if DONE is rising too slow, although 330 should be fine with
just one FPGA.

What do you measure on the actual board for risetime and
high/low voltage levels on the DONE pin ?

>
>> - 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.
>
Transistors normally fall within my definition of 'buffer' :)

Unless a hypothetical assembly house stuffed, say, a 1.2 ohm
(1R2) where a one Kohm (102) NPN base resistor was supposed
to go, lighting the DONE LED just fine but clamping the DONE
voltage seen at the FPGA pin to one VBE drop such that the
FPGA thinks DONE never went high.

>
> 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.
>

IIRC I'd get a 'Programming Failed' error box after the
'downloading core' stage was reported in the 10.1 log
window, if DONE didn't go high on the board.

Not sure it'll help any, but here's another post of SPI
related stuff from previous application note trawls:
http://groups.google.com/group/comp.arch.fpga/msg/797303edfd4e7cac

>
> 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.
>
<snip>
>
> But of course I can't change it for the JTAG->SPI bitfile
> shipped with iMPACT.
>
It is a major nuisance that Xilinx doesn't provide the JTAG-SPI
core for iMPACT in either source or black-box synthesizable form.

This forces customers to reinvent the indirect SPI FLASH wheel.

If you ever need to do this, I'd suggest starting with either the
Ken Chapman Picoblaze flash example (S3E) or the Avnet V5 SPI
flash eval board example, which demonstrates the V5 logic needed
to do user access to the internal configuration logic.

Also of note, command line 10.1 PROMGEN has an undocumented-in-
the-manuals " -spi " option that will let you generate an .mcs
file for SPI proms with the proper bit order.

This is quite helpful, for instance, when iMPACT 10.1 crashes
and burns each time you try to define a multiboot, multi-FPGA
daisy chain SPI PROM from within the iMPACT GUI.

Brian
From: Sean Durkin on
ghelbig schrieb:
> FWIW: I spent 3 days debugging an isse (see: "XST is driving me
> crazy" in this usenet group) that was resolved by adding one more
> clock to the startup stream.
>
> In my configuration, done would go high and all of the combitorial
> logic would word, but none of the sequential logic would work.
>
> One more (extra) CCLK, and everythig went working.
I know about THAT issue, but I had problems programming via iMPACT. The
thing is that I have no influence on how many CCLK cycles iMPACT
generates. It should be smart enough to know how many are needed but
obviously is not.

The only thing that helped was changing the DONE_cycle-setting, which is
something I've never had to touch before, hence it took me awhile to get
there...

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: Peter Van Epp on
<snip>
>And another question is: what else did the assembly house mess up on
>this board? Lot of 0402 bird seed on this one, no way to tell by looking
>at it... But at least all supply voltages are correct and so on.
<snip>

This reminded me of an article I saw in Circuit Cellar on Smart Tweezers
(http://www.smarttweezers.com) which might help you out. I expect there may
be some problems in circuit with parallel paths though, I think it is more
meant for identifying mystery components in isolation.

Peter Van Epp
From: Gabor on
On Feb 11, 2:50 pm, van...(a)sfu.ca (Peter Van Epp) wrote:
> <snip>>And another question is: what else did the assembly house mess up on
> >this board? Lot of 0402 bird seed on this one, no way to tell by looking
> >at it... But at least all supply voltages are correct and so on.
>
> <snip>
>
>         This reminded me of an article I saw in Circuit Cellar on Smart Tweezers
> (http://www.smarttweezers.com) which might help you out. I expect there may
> be some problems in circuit with parallel paths though, I think it is more
> meant for identifying mystery components in isolation.
>
> Peter Van Epp

We've got a set of these in our production area here, which is also
the test and rework area (small company). You can often get
information
in-circuit, especially in cases like this where you might see a much
lower
impedance than you were expecting. They're also great for comparing
two boards when one doesn't work, since whatever you measure on the
good board (R L or C) is just a relative reference point rather than
the presumed component value.

Regards,
Gabor