cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Newbie
Newbie
10,626 Views
Registered: ‎07-28-2014

iMPACT XVC broken with multiple devices?

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:

 

TRST OFF;
ENDIR IDLE;
ENDDR IDLE;
STATE RESET;
STATE IDLE;
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?

6 Replies
Highlighted
Newbie
Newbie
10,618 Views
Registered: ‎07-28-2014

Re: iMPACT XVC broken with multiple devices?

I verified this behavior also occurs when running iMPACT 14.6 on Windows.
0 Kudos
Highlighted
Adventurer
Adventurer
9,907 Views
Registered: ‎03-30-2012

Re: iMPACT XVC broken with multiple devices?

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.)

 

 

0 Kudos
Highlighted
Newbie
Newbie
9,775 Views
Registered: ‎12-29-2014

Re: iMPACT XVC broken with multiple devices?

Hi there!

 

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!

 

Thx,

Max

0 Kudos
Highlighted
Adventurer
Adventurer
9,718 Views
Registered: ‎03-30-2012

Re: iMPACT XVC broken with multiple devices?

Bump again to keep this alive. And yeah, I agree, the day or so that I stared at JTAG state machines and data trying to figure out where I was going wrong was REALLY annoying.

Vivado Hardware Manager isn't even an option for pre-7 series devices.
0 Kudos
Highlighted
Newbie
Newbie
9,546 Views
Registered: ‎12-29-2014

Re: iMPACT XVC broken with multiple devices?

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?

0 Kudos
Highlighted
Adventurer
Adventurer
9,534 Views
Registered: ‎03-30-2012

Re: iMPACT XVC broken with multiple devices?

I swear they claimed that critical bugs would be fixed. Apparently "shifting random JTAG instructions into devices" doesn't count as critical, which makes me wonder what would. Exploding chips?

Plus they've never even acknowledged this bug, which means that people have to spend stupid amounts of time debugging and figuring out that oh, no, it's the "unsupported software that I'm forced to use, even though none of the devices I'm using is out of production" that's messed up.

What's this thread got, 1000+ views, and not one comment from a Xilinx employee? Fun.
0 Kudos