Maximum number of devices in JTAG chain with USB Blaster

[Altera_Forum]

Hello everyone, 

 I'm designing a new board for a particle physics detector. The board has a 1 Gbit parallel flash chip (CFI) that I have to reprogram in situ. This chip holds LUT data that needs to be reprogrammed after calibration from time to time. The board will also have a Cyclone III.  One of the options I am thinking on is using a MAX II chip and Parallel Flash Loader together with the USB Blaster cable for programming the 1 Gbit flash LUT.   However, in the final setup, I will have not just 1, but 8 to 16 of these boards in racks. I would like to program all of them together using just one USB Blaster cable. For that I should connect 8 to 16 MAX II (plus same number of Cyclone III) in a JTAG chain.  I assume cabling can be properly handled in a point-to-point fashion so that JTAG signals are cleanly transmitted between the boards. Eventually I would use LVDS transceivers between the boards. However, as data is shifted serially through the TDI-TDO chain, it will inevitably accumulate propagation delays at each stage. At some point data on TDO will be too much delayed for the USB Blaster cable to clock it on time.   Therefore, I have tried to find out what is the clock cycle time of USB Blaster cable, and if it can be varied (slowed down) to adapt to long chains of devices. But I could not find that piece of information :confused:. Does anyone know where to find it?  Also, I will greatly appreciate if some of you have experience in similar setup and can advice on the maximum number of devices it is reasonable to connect on one JTAG chain.  Thank you a lot in advance!

[Altera_Forum]

The USB Blaster is working at a fixed 6 MHz TCK. It's using a shift register in the CPLD that is not providing programmable frequencies. In principle, it would be possible to modify the CPLD design. Also changing the crystal should basically work. But it's not neccessary for your purpose I think. There's no TDI/TDO delay chain issue, because the timing is regenerated at each chain device by a DFF, shifting the data one clock cycle. 

 The only problem is TCK and TMS fanout, which can be easily overcome by buffering. You should however care for correct source side series termination of TCK. The JTAG circuitry of FPGAs has fast logic elements, they can detect ringing TCK edges as double clocking.   The 6 MHz TCK JTAG chain has room for several 10 ns of additional delay. If the TCK to TDO delay at the USB blaster exceeds 1/2 TCK cycle, it fails however.  P.S.: In addition, there's a maximum length of chained IDCODE registers accepted by the Quartus Programmer when initially identifying the chain. But I have in mind a size of at least 512 bits, may be 2 or 4 times more. It should be documented somewhere.

[Altera_Forum]

Thank you FvM for your helpful and clear answer :). 

 I have one additional question on the behavior of the Quartus II Programmer software. In my application I will have a JTAG chain with 8 (but potentially up to 16) MAX II devices configured as Parallel Flash Loaders. Each MAX II device will be connected to a CFI flash of 1 Gbit. The time for erasing and writting 1 Gbit of flash is quite long, in the order of 2000-3000 s. Therefore it would be an advantage if the programmer could perform the operation concurrently on all chips, not waiting to complete one chip to start with the next.  Does anybody know how the Quartus II Programmer behaves (sequentially or concurrently) when programming a batch of CFI flash chips (each chip connected to a MAX II PFL, and all the MAX II in a JTAG chain) ?  Thank you in advance, Best regards,

[Altera_Forum]

I don't think that the Quartus Programmer supports any kind concurrent programming. Batch programming should be possible by tcl sripting. Generally, you should use the enhanced PFL version (if it fits your MAX II design) because it's considerably faster in programming. The enhanced PFL utilizes a data fifo and state stae machine to speed up programming, but it's too small for effective concurrent programming, I fear. You would also need to write your own PFL programming tool to achieve it.