cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
josh_tyler
Contributor
Contributor
3,292 Views
Registered: ‎04-10-2018

Zynq Ultrascale+. Vivado reports Incorrect Bitstream Assigned to Device

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

0 Kudos
Reply
15 Replies
tenzinc
Moderator
Moderator
3,281 Views
Registered: ‎09-18-2014

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

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Reply
josh_tyler
Contributor
Contributor
3,273 Views
Registered: ‎04-10-2018

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

0 Kudos
Reply
jmcclusk
Mentor
Mentor
3,266 Views
Registered: ‎02-24-2014

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.  

Don't forget to close a thread when possible by accepting a post as a solution.
0 Kudos
Reply
josh_tyler
Contributor
Contributor
3,257 Views
Registered: ‎04-10-2018

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.

0 Kudos
Reply
jmcclusk
Mentor
Mentor
3,230 Views
Registered: ‎02-24-2014

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.
Don't forget to close a thread when possible by accepting a post as a solution.
0 Kudos
Reply
josh_tyler
Contributor
Contributor
3,172 Views
Registered: ‎04-10-2018

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.

0 Kudos
Reply
kkn
Moderator
Moderator
3,135 Views
Registered: ‎01-15-2008

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

0 Kudos
Reply
josh_tyler
Contributor
Contributor
3,124 Views
Registered: ‎04-10-2018

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)

0 Kudos
Reply
josh_tyler
Contributor
Contributor
3,119 Views
Registered: ‎04-10-2018

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
Mentor
Mentor
2,394 Views
Registered: ‎02-24-2014

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

Don't forget to close a thread when possible by accepting a post as a solution.
marode
Observer
Observer
2,004 Views
Registered: ‎04-27-2009

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.

0 Kudos
Reply
simon.beaudoin
Adventurer
Adventurer
1,470 Views
Registered: ‎05-08-2018

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

0 Kudos
Reply
mansuramin
Adventurer
Adventurer
651 Views
Registered: ‎12-04-2019

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. 

0 Kudos
Reply
simon.beaudoin
Adventurer
Adventurer
625 Views
Registered: ‎05-08-2018

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

0 Kudos
Reply
mansuramin
Adventurer
Adventurer
619 Views
Registered: ‎12-04-2019

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.