Zynq Ultrascale+. Vivado reports Incorrect Bitstream Assigned to Device

[josh_tyler]

Hello,

I am currently bringing up a board containing a Zynq Ultrascale+ (XCZU7EG-FFVF1517, -1 speed grade, E temperature grade). The correct device is targeted in Vivado 2017.4 (xczu7eg-ffvf1517-1-e), and the code implements and generates the bitstream correctly.

When I come to configure the device with the bitstream over JTAG with an Xilinx Platform Cable II however, I get error Labtools 27-3303. (Incorrect bitstream assigned to device. Bitfile is incompatible with this device).

I have production silicon (IDCODE_HEX=1473_0093 as detected over JTAG, and I have confirmed this with the 2D barcode on the device case). One slightly concerning thing is that the VARIANT_NAME is reported by JTAG as "zu7ev", whilst I have the zu7eg part.

Does anyone know where I am going wrong?

Many thanks,

Josh

[tenzinc]

Josh_tyler,

Can you verify the device is, in fact, a ZU7EG as you claim it is? If you can scan the barcode then I assume the surface of the package lid is visible. Would be good to post an image of the full top marking. Also, what does the scan say what device it is? What does it say on the purchase order? What does the Moisture barrier bag say?

Regards,

T

[josh_tyler]

Hi T,

I can confirm that the device is a ZU7EG. The text on lid of the device is marked as a ZU7EG, the barcode scan states the device is a ZU7EG, and both the purchase order and moisture barrier bag state that the part is a ZU7EG. I'm not currently at the same location as the device, so cannot post a photograph at the moment. The part was ordered from a Xilinx authorised distributor also.

Many thanks,

Josh

[jmcclusk]

The ZU7EG and the ZU7EV are the same silicon die, with the difference being in the bonding option in the package (probably this is done on the substrate, inside the package).   In the past, external pins could affect the device identity, and the same thing may be happening here.   I suspect a critical ID pin or pins is floating, or at least that's my theory.

Alternatively, the part got mislabeled at the factory, and JTAG is right.  

[josh_tyler]

I've had a read of the information Xilinx provides about device migration between the EV and EG (UG584 Chapter 7) and I can't find anything about setting ID pins differently to migrate between the two variants. In addition the schematic checklist (XTP427) was followed during the design, so having left critical configuration pins floating is unlikely.

I had considered that the device could be mislabelled, and so had considered implementing the design for an EV part in Vivado. However I had two concerns about this. Firstly, I was concerned that it may be possible to damage the part by configuring with a bitstream intended for a different part (if it really is an EG, but accepts the EV bitstream). Secondly I would not know which speed grade and temperature grade to target, since if we are assuming the labelling is incorrect, I have no way to find this information.

[jmcclusk]

My advice is that you should change your design to a ZU7EV, and proceed with the belief that nothing bad will happen. It might have happened that the device identity is set with an efuse, and somehow, a critical efuse "healed" or otherwise reset itself after programming. Now the device believes it's a ZU7EV. So go with it. You shouldn't panic unless all the other proto's start doing the same.

[josh_tyler]

I've tried a simple design to blink an LED, targeting the ZU7EV. The FPGA accepts the bitstream, and the LED blinks. Of the first two boards I've brought up, both have the same behavior, implying something went wrong in the production process, so I will contact our supplier about this.

[kkn]

Hi @josh_tyler,

Can you check on your board the following things 

1.    PS_REF_CLK must receive a free-running clock source that is within operating specifications. 
2.    PS_POR_B must be de-asserted when scanning for the JTAG IDCODE.  (The JTAG TAP works when PS_POR_B is asserted, but a returned IDCODE might not be right.)

--Krishna

[josh_tyler]

Hi @kkn,

1. I've just measured PS_REF_CLK and can confirm that it is a free-running 50MHz clock.

2. I've just measured PS_POR_B and can confirm that it measures 3V3 (it is pulled up to 3V3 with a 10k resistor)

[josh_tyler]

I have done some further testing on this.

Once configured the device changes VARIANT_NAME and reports as a "zu7eg". It will then accept bitstreams targeted towards the ZU7EG until it is power cycled, when VARIANT_NAME will revert to "zu7ev".

Running a diff on the bitstream of same simple design implemented for both EV and EG shows that the only difference Vivado generates between the two is the ASCII timestamp and target device string in the header.

[jmcclusk]

As Mr. Spock used to say,  "Fascinating!"

[marode]

I can see the same behavior on a ZU4EG (toolchain Vivado 2018.2):
The device shows up as ZU4EV after a reset via the XSCT Console. The PL is in "not programmed" state. 

When the PL is programmed (bootmode QSPI) the FPGA shows up as ZU4EG and can be re-programmed via JTAG.

Is there any explanation to this? 

I have the feeling I have to do some further reading to track down this problem.

[simon.beaudoin]

I have the EXACT SAME problem! We have two TE0803-4EG boards from trenz electronic. When I try to program the 4eg bitstream, the error pops out. The VARIANT_NAME is zu4ev at that moment. At some point I don't remember what manipulation I did, but I was able to program the fpga properly and the VARIANT_NAME was zu4eg back again. 

Now after a power cycle I'm back at not being able to program it again.

All the explanations above don't reaaaally solve anything :S

Any help would be greatly appreciated, I can't stand loosing precious time on something so silly

[mansuramin]

Hello 

I too am seeing the variant name of zu4ev.

The FPGA die itself has 4EG written on top.

I am not sure what to do to fix what the hardware manager is reading out, and I would like to target the EG family. 

Any help is appreciated. 

[simon.beaudoin]

Turned out that every power rails have to be good. We had one that was not good, and the fpga was partially powered up. Only when the fpga is fully powered that idying it will function properly. At least, in our case

[mansuramin]

Hello

We too figured out what the problem was. The Boot mode for the FPGA was set to QSPI on initial power up. It seems there is an errata somewhere that explains this. At initial power up if the QSPI is not programmed and the boot mode is set to QSPI then the variant name will show incorrect. Changing the bode mode to JTAG fixed the bug.