07-28-2014 03:29 AM
I'm using iMPACT 14.7 on lin64, and I wanted to try using XVC so that I could use iMPACT with my microcontroller-controlled JTAG chain. Unfortunately, it seems like the XVC plugin has a broken implementation of headers (HDR/HIR/TDR/TIR in SVF parlance), making it fail with my chain which has multiple devices. Has anyone else seen this behavior?
My chain has three devices: a CoolRunner2, a Spartan 6, and another CoolRunner2. iMPACT is able to identify the chain correctly using its blind interrogation. If I ask it to get the IDCODE of the first device, it produces this SVF file, which looks correct and works correctly if I send it through my SVF player:
FREQUENCY 1E6 HZ;
//Operation: ReadIdcode -p 0
TIR 0 ;
HIR 0 ;
TDR 0 ;
HDR 0 ;
TIR 0 ;
HIR 14 TDI (3fff) SMASK (3fff) ;
HDR 2 TDI (00) SMASK (03) ;
TDR 0 ;
//Loading device with 'idcode' instruction.
SIR 8 TDI (01) SMASK (ff) ;
SDR 32 TDI (00000000) SMASK (ffffffff) TDO (f6d8f093) MASK (0fff8fff) ;
If I tell it to use the XVC plugin, instead of sending the proper '3fff' header to set the other two devices into BYPASS mode, it sends the bytes '0x00 0x11' for the TDI vector, corresponding to an SVF command of '1100'. Needless to say, those instructions are not BYPASS, so they set those devices into some other mode, and when iMPACT tries to shift out the IDCODE register it gets some garbage instead of the actual idcode.
Has anyone gotten XVC to work with a multi-device chain?
04-17-2015 11:02 AM - edited 04-20-2015 07:10 AM
Bump, I guess, since no one from Xilinx has commented on this, and it is *definitely* broken.
I'm also not sure it's not *dangerous*. As far as I can tell it's shifting in 'random' JTAG instructions... so who knows what it could do. If one of them is EXTEST or its variants... who knows. Especially for non-Xilinx devices it could be 'bad'.
I can actually investigate this pretty carefully (and probably will) since I have board with up to 5 devices (4 Artix-7s, 1 Spartan-6) which can be dynamically inserted/removed from the JTAG chain: that is, I can switch from a chain with "1 Artix-7" to "2 Artix-7s" to "3 Artix-7s", to "1 Artix-7 + 1 Spartan-6", etc. Thankfully this allows me to avoid this problem, but I feel bad for those who have permanent chains!
With 1 device in the chain, everything works perfectly fine. Which is good. When I *add* multiple devices, however, iMPACT just sends complete garbage into the instruction register of the other devices.
*Sometimes*, that works, because apparently instruction code "000000" for Artix-7s is a 1-bit register. Random undocumented information! But lots of other cases don't.
For instance: in a JTAG chain with 3 Artix-7s, if I do "Iniitalize Chain", iMPACT starts out by going to TLR, then Shift-DR, and shifting out 32 bits, then 64 bits, then 96 bits, then 128 bits, until it sees F's start to appear. With 3 Artix-7 200t's, you get:
xvcd: ftdi_xvc_shift_command : TDO data: 936063139360631393606313ffffffff
And it identifies the chain fine. If I then do "Get Device ID" on the *first* Artix-7, it goes to Shift-IR, and does...
xvcd: handle_data: TMS data: 0000 xvcd: handle_data: TDI data: 000d xvcd: ftdi_xvc_shift_command : instruction/data shift: 12 bits. xvcd: handle_data: TMS data: 20 xvcd: handle_data: TDI data: 09 xvcd: ftdi_xvc_shift_command : instruction/data shift: 6 bits.
That is, it first shifts 000000 into the last Artix-7, and 110100 into the *next* Artix-7, before shifting in 001001 (IDCODE) into the first Artix-7.
It then goes to Shift-DR, shifts out 2 bits (although strangely the TDI is weird there- it sends "shift:", 0x02, 0x00, 0x75) and then shifts out 32 bits, looking for the IDCODE. Of course it doesn't get it, because "110100" is apparently *not* a 1-bit register (it shifts out 00001100000100100110000001100000, whatever that is, although it's missing the LSB).
If I try to read the IDCODE from the *second* Artix-7, it actually does 3 6-bit shifts into the instruction register, which is nice, because you can clearly see what it's doing wrong. After going to Shift-IR, it does:
xvcd: handle_data: TMS data: 00 xvcd: handle_data: TDI data: 00 xvcd: ftdi_xvc_shift_command : instruction/data shift: 6 bits. xvcd: handle_data: TMS data: 00 xvcd: handle_data: TDI data: 09 xvcd: ftdi_xvc_shift_command : instruction/data shift: 6 bits. xvcd: handle_data: TMS data: 20 xvcd: handle_data: TDI data: 35 xvcd: ftdi_xvc_shift_command : instruction/data shift: 6 bits.
So here you can clearly see what it's shifting into each of the 3 IRs: 0x00 (random 1 bit register), 0x09 (IDCODE), and finally 0x35 (who knows!). In this case, it works, because 0x00 is only 1 bit long (although who knows what it is), and the "0x35" instruction is upstream of it in the JTAG chain.
So I think it's pretty clear to state that iMPACT, right now, does not work with XVC using multiple devices, and considering it's shifting in 'random' instructions into the other devices, I would really recommend avoiding it. (Although it's worth noting that if you hack around to 'recognize' the invalid instruction codes and force them to be BYPASS, everything works fine. But that requires that you have an idea what iMPACT is trying to do.)
05-05-2015 07:50 AM
I can also confirm that the Impact XVC Plugin must be broken. As mentioned previously it is the BYPASS instruction that it does not use for other devices in the chain. It took me a while to realize that it was not my XVC peripheral that was broken, but Impact ;)
Could anyone from Xilinx tell us if this issue will ever be fixed? I know that Xilinx has abandoned ISE, but Vivado Hardware Manager does not have as many functions as Impact has. It lacks an easy way to import BSDLs and to create SVF, so please fix this! This should be a simple fix!
05-12-2015 10:40 AM
05-14-2015 02:11 AM
Just giving up a toolchain and still selling chips for that toolchain is simply ridiculous! Nobody expects Xilinx to maintain legacy software, but a simple fix for easy issues once in a while?
05-14-2015 07:47 AM