V5 JTAG download weirdness

[brim...@aol.com]

Has anyone out there sucessfully brought up a V5 download
chain ( LX50 w/SPI serial master, four LX30 slaves) over
JTAG using 10.1i SP3 ?

I'm bringing up my first V5 board design, and I'm seeing
issues that are reminiscent of older software and JTAG
startup bugs of years past; searching the Answer Records
didn't turn anything up specifically for V5.

The JTAG chain itself seems quite robust, I've buffered
things near the JTAG connector, and can run looped JTAG
ID tests all day long without any errors.

There seem to be some startup related issues, with devices
not quite completing configuration, and download order
dependent variations in supply current ( when loading
static test design files that just tie off all the I/Os ).

When downloading the bit files on-by-one through IMPACT,
the download completes to the point of DONE being released
by all devices in the chain, but the last slave device loaded
acts odd.

I've got other things to try tomorrow, just thought I'd ask
here to see if anyone had already banged into any of these:

1. Mode of Master/SPI interferes with V5 JTAG download???

2. JTAG download order dependent supply current

JTAG chain device programmed last draws ~1W extra current
and doesn't seem to have completed startup

3. indirect SPI flash programming not working
( M25P128 device ID reads wrong )

4. Note: 10.1i SP3 IMPACT no longer sets startup clock to
JTAG if the bit file being JTAG downloaded was originally
created for PROM download with CCLK as startup clock

More detail below.

thanks,
Brian

1. Mode selection of Master/SPI interferes with JTAG download???

I suspect this is the cause of some of my problems; I used
zero ohm R's to set the mode pins, my first change tomorrow
will be to switch the mode pins to JTAG.

2. JTAG download order dependent supply current

Whichever one of the Slaves ( JTAG chain 2-5 ) is
programmed last draws ~1W extra current and doesn't
seem to have completed startup.

The Master (also the first device in the JTAG chain) does
not exhibit this problem.

3. indirect SPI PROM programming not working

After downloading the indirect SPI core, IMPACT errors
out saying the M25P128 SPI flash device ID read back as zero.

(This may be related to #1)

4. Note: 10.1i SP3 IMPACT no longer sets startup clock to
JTAG if the bit file being JTAG downloaded was originally
created for PROM download with CCLK as startup clock

This is just a nuisance factor- IMPACT no longer pops up
the "changed startup clock to JTAG" box, you have to manually
generate a different bit file for JTAG or PROM download.

[brim...@aol.com]

Yesterday, I wrote:
>
> 1. Mode selection of Master/SPI interferes with JTAG download???
>
> I suspect this is the cause of some of my problems; I used
> zero ohm R's to set the mode pins, my first change tomorrow
> will be to switch the mode pins to JTAG.
>

Update:

Switching from Master/SPI mode to JTAG mode during
the indirect SPI programming cleared up the problems
with recognizing and programming the M25P SPI FLASH
via indirect mode from the V5LX50.

{ Also note that before using IMPACT indirect SPI
programming with a chain of FPGAs, one must first
configure all the other FPGAs via JTAG before
attempting to program the SPI flash, otherwise
DONE is never released for the indirect SPI core
to startup in the Master FPGA. I'd done that
yesterday as well, but indirect download still
had failed with the mode pins set to Master/SPI }

The FPGA download chain still doesn't configure
properly from the SPI flash after setting the mode
pins back to Master/SPI and power cycling, but that's
probably some other issue to discover.

Brian

[Gabor]

If you have trouble with the common DONE pin on several
devices, consider setting the "enable internal DONE pipe"
check box in the bit file generation properties. This
causes the V5 to ignore the DONE pin and use the internal
DONE signal to complete the startup process. I found that
this also fixes a problem when the startup clock is fast
enough to cause sampling of DONE for the startup pipe to
happen while the DONE pin was still slewing towards high
due to the limited pullup strength of the external resistor.
This can lead to DONE being sampled while in the logic
threshold region and messing up the remainder of the
startup pipe. My system uses slave serial configuration
mode with a 100 MHz CCLK and 330 ohm pullup with no other
chips sharing the DONE signal, so with multiple chips
this problem may show up with a slower clock as well.

Regards,
Gabor

[brim...@aol.com]

Gabor wrote:
>
>> Also note that before using IMPACT indirect SPI
>> programming with a chain of FPGAs, one must first
>> configure all the other FPGAs via JTAG before
>> attempting to program the SPI flash, otherwise
>> DONE is never released for the indirect SPI core
>> to startup in the Master FPGA.
>

> consider setting the "enable internal DONE pipe" check box
> in the bit file generation properties. This causes the
> V5 to ignore the DONE pin and use the internal DONE signal
> to complete the startup process.
>

Thanks for pointing that out; I'd noticed that option before,
but thought it just delayed the internal DONE by one startup
clock cycle, without realizing that it also switched to an
internal DONE signal instead of looking at the DONE pin.

That should be helpful in diagnosing a variety of chain
startup problems.

In the specific case of the IMPACT indirect SPI core
download process, I don't know of any way to check/change
the settings of the indirect SPI core being automatically
downloaded by IMPACT, so I think I'll have to continue with the
load-dummy-design-bit-files-before-programming-flash shuffle.

>
> I found that this also fixes a problem when the startup
> clock is fast enough to cause sampling of DONE for the
> startup pipe to happen while the DONE pin was still
> slewing towards high due to the limited pullup strength
> of the external resistor. This can lead to DONE being
> sampled while in the logic threshold region and messing
> up the remainder of the startup pipe.
>

I don't think the DONE risetime is the cause of my
problem #2 JTAG download order variations, but I haven't
yet measured the actual DONE risetime for this new design.
( I've tried both 6 or 12 MHz TCK for JTAG download,
and the slowest CCLK setting for MASTER SPI boot )

The post-download status registers ( AR #24024 ) say all
systems are go with DONE/GWE/GTS/GHIGH set properly no
matter the order of download; but I still see the order
dependent variations in static supply current.

I'll have a look Monday to see if that DONE pipe bit has
any effect.

thanks,
Brian