Forums

V5 JTAG download weirdness

Started by Unknown December 5, 2008
 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.
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
On Dec 5, 10:39=A0pm, brimda...@aol.com wrote:
> Yesterday, I wrote: > > > 1. Mode selection of Master/SPI interferes with JTAG download??? > > > =A0 =A0I suspect this is the cause of some of my problems; I used > > =A0 zero ohm R's to set the mode pins, my first change tomorrow > > =A0 will be to switch the mode pins to JTAG. > > Update: > > =A0Switching 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. =A0I'd done that > yesterday as well, but indirect download still > had failed with the mode pins set to Master/SPI } > > =A0The 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
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
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