08-06-2019 12:20 AM
I designed a small PCB that daisy trained four JTAG devices as the below figure.
I can successfully perform configuration on both the NOR flash attached beside xc7k325t, however, if I try to perform configuration on the NOR flash beside xc7a200t I got error as below :
I have tried to slow down TCK frequency to 10MHz and even 1MHz, but still got exactly the same error. Below is the waveform at 1MHz(yellow : TCK / green : TDI / blue : TDO), I believe this is not a signal integrity problem.
It is strange that If I remove one of the xc7k325t on the JTAG train, configuration on both of the xc7a200t is normal.
I am sure the NOR flash attaced beside xc7a200t is S25FL128Sxxxx0, not S25FL256Sxxxx1, so why Vivado would detect the wrong flash part in some cases that preventing the configurtion process ?
08-06-2019 01:41 AM
Please show here the schematic of your pcb with 5 JTAG connectors (which appeared in another of your posts). Please tell us:
08-06-2019 03:12 AM
schematic as below
Appreciate for any futher suggestion, thanks !
08-06-2019 05:10 AM
…about the voltages:
-just to be clear, I understand from your comments and other post that VREF=J2=J3=3V3. Is that correct?
Typically, VREF is read by the programmer module and used to configure digital IO of the programmer. Please use oscope to verify digital IO levels coming out of U1, which will probably be 3.3V CMOS levels (because VREF=3V3). However, U1 driving 2V5 side of U2. You should check compatibility of 3.3V CMOS and 2.5V CMOS logic.
Since, VREF=J2=J3=3V3, do you really need U2? It now seems that everything is 3.3V CMOS. Can you simply remove U2 and wire TMS and TCK straight through?
It matters where in the circuit you measure things. TCK to TDO should be measured at U1. TCK to TMS and TCK to TDI should be measured at the J2-J6. I suspect that U2 was skewing TCK to TDO timing, which is another reason to get rid of U2 if you can. Did you measure T(TCKTDO) at U1 and find it to be less than the 7ns max?
08-06-2019 08:53 PM
I removed U2, but still got similar error, then I measured TCKTDO at U1 side at TCK=10MHz as below (yellow : TCK / green : TDO)
Since the rising/falling edge of TCK is not sharp enough(I added a EMI bead on TCK in series to filter out glitch signal on TCK) the waveform is possibly violating the 7ns timing requirement(?).
However, I would like to understand the meaning of TCKTDO first, from datasheet of Xilinx FPGA
Since TDO is an output signal from FPGA, does the time period "TCKTDO" means FPGA outputs its TDO signal within 7ns max after the falling edge of TCK signal ?
Also from datasheet of DIGILENT JTAG-SMT2 module :
T_HD is 0ns, does this means the JTAG-SMT2 module samples TDO signal right at the falling edge of TCK signal, no hold time is required ?
If the above description is correct, it looks strange to me that FPGA output TDO and JTAG-SMT2 samples TDO at the same time(ie. TCK falling edge), it is not a reasonable design.
Note that the TDI signal of JTAG-SMT2 is connected to TDI signal of FPGA, and TDO signal of JTAG-SMT2 is connected to TDO signal of FPGA
Really appreciate for the help.
08-07-2019 05:38 AM - edited 08-07-2019 05:42 AM
I would like to understand the meaning of TCKTDO..
I understand TCKTDO to be a clock-to-out time for JTAG. That is, JTAG is clocking out data on the falling-edge of TCK and the time from this falling edge to the data-change time is a maximum of 7ns. It is OK if clock-to-out time is less than 7ns.
…it looks strange to me that FPGA output TDO and JTAG-SMT2 samples TDO at the same time..
Yes, the labelling is strange and confusing. I think we must refer to inputs and outputs at a JTAG port (and not use the symbols, TDO, TDI etc). For an output, the JTAG port must obey the clock-to-out time (ie. it can be no more than 7ns). Remember, clock-to-out time for JTAG is measured from the falling-edge of TCK. For an input, the observed setup and hold times must be greater than the minimum specified values - and they are measured from the rising-edge of TCK.
The following document describes timing of JTAG in detail.
Perhaps you can again verify that clock-to-out for outputs and setup/hold for inputs is satisfied at all JTAG ports on your board.
I removed U2, but still got similar error..
Rats! Table 45 of the datasheet for your flash gives Manufacturer ID (01) and Device ID (hex(18) or hex(17)). When trying to program the flash, watch the Tcl Console for lines like the following to see what IDs are being reported.
program_hw_cfgmem -hw_cfgmem [get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices] 0 ]] Mfg ID : 20 Memory Type : ba Memory Capacity : 18 Device ID 1 : 0 Device ID 2 : 0
08-07-2019 09:15 PM
In datasheet of S25FL125/256S the Devie ID is 0x17 / 0x18
In Vavido I believe the "Device ID" maps to the "Memory Capacity" from TCL console, though its value offsets by 1, 0x18 and 0x19, I guess this is fine.
program_hw_cfgmem -hw_cfgmem [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xc7a200t_0] 0]]
Mfg ID : 1 Memory Type : 20 Memory Capacity : 18 Device ID 1 : 0 Device ID 2 : 0
program_hw_cfgmem -hw_cfgmem [ get_property PROGRAM.HW_CFGMEM [lindex [get_hw_devices xc7k325t_2] 0]]
Mfg ID : 1 Memory Type : 2 Memory Capacity : 19 Device ID 1 : 0 Device ID 2 : 0
After many trail tests, I may find a clue about this error :
At initial all four FPGAs are corretly recognized on JTAG, so I manually assign SPI flashs(S25FL128S on xc7a200t and S25FL256S on xc7k325t) as below :
FPGA configuration on both of the SPI flashes are successful.
At this time, if I unplug the USB cable of DIGILENT JTAG-SMT2, then pulg back the USB cable again, Vivado automatically re-scan the JTAG chain, and smartly remember the settings(flash ROM type, configuration ROM file...) so the above screen shot appear again without any manual setting.
At this time, if I try to perform configuration on the S25FL128S flash ROM, I got the wrong part selected error as above, then I tried :
I tried many times so I can confirm the consistency of the phenomonon, just for your reference and thanks for your help !