cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Adventurer
Adventurer
3,972 Views
Registered: ‎04-23-2014

EFUSE registers in ZU3EG ES1

Jump to solution

I want to read / program the EFUSE registers of a ZU3EG ES1 device. However, in Vivado 2017.1  EFUSE is not listed in the registers section of the hardware manager (see screenshot). Also there is no option to program the registers in the context menu. Running the following tcl command:

get_property [lindex [get_hw_device] 0] REGISTER.EFUSE.FUSE_DNA

produces this error:

ERROR: [Common 17-161] Invalid option value 'REGISTER.EFUSE.FUSE_DNA' specified for 'object'.

Do the ES1 device not contain EFUSE registers? I was able to read the device DNA through a PL design, but I can't verify whether the DNA is actually correct.

efuse.png
0 Kudos
Reply
1 Solution

Accepted Solutions
Adventurer
Adventurer
4,909 Views
Registered: ‎04-23-2014

I got it running after all. It seems like it works without the mysterious hardware module mentioned in UG643. In case someone else faces the same problems, here is the hardware design I used:

 

jtag.png

The two slice blocks extract bit position 1 and 2. The master_jtag_wrapper is just a simple wrapper IP for the master jtag.

 

I'm still a bit confused on how the xilskey library actually works, given that it is never told the address to which the AXI GPIO is mapped. But at least it works and I didn't brick my board :-)

View solution in original post

0 Kudos
Reply
11 Replies
Scholar
Scholar
3,967 Views
Registered: ‎02-27-2008

What version of Vivado are you using?

 

https://www.xilinx.com/support/answers/68832.html

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Reply
Adventurer
Adventurer
3,964 Views
Registered: ‎04-23-2014

I'm using 2017.1. I also have 2016.4 installed. I just tried that and here the EFUSE registers are visible. But after reading through the AR, I would rather not use 2016.4 for programming.

0 Kudos
Reply
Scholar
Scholar
3,959 Views
Registered: ‎02-27-2008

Agreed,

 

I do not see other answer records, but this may be that the ES parts do not support efuse...

 

Perhaps someone who knows the answer will reply.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Reply
Xilinx Employee
Xilinx Employee
3,938 Views
Registered: ‎10-11-2011

In order to program eFUSE in ZU+ devices you have to use the software XilSKey library.

See UG1137 (v4.0) Zynq UltraScale+ MPSoC Software Developer Guide.

I like the example in the SDK installation: \SDK\2017.1\data\embeddedsw\lib\sw_services\xilskey_v6_2\examples

 

NOTE: The "MUX" described in UG1137 is only needed for zynq-7000.

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Reply
Adventurer
Adventurer
3,876 Views
Registered: ‎04-23-2014

Thanks, I will take a look at it. Will the GUI for programming ZU+ EFUSE registers be added back to Vivado? Perhaps 2017.2?

0 Kudos
Reply
Scholar
Scholar
3,866 Views
Registered: ‎02-27-2008

Probably not,

 

As these features are seldom used, it makes more sense to solve it by using c code and RTL designs.  That way, we add little or no fixed capabilities to the devices, and allow the software versions of tools and IP to provide the features.

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Reply
Adventurer
Adventurer
3,857 Views
Registered: ‎04-23-2014
Does it really happen that seldomly that people program e.g. the AES key through Vivado rather than creating a complex RTL and Software design? That used to be quite easy with the old Zynq generation.
0 Kudos
Reply
Scholar
Scholar
3,854 Views
Registered: ‎02-27-2008

c,

 

Just because it was easier doesn't indicate use.

 

In general, the security features are used by fewer than a percent or so of our customers.  I would argue that in future, 100% of safety critical applications will at least use authentication.  Following that, only loading valid bitstreams should be widespread.  The use of encryption may still remain small for perhaps a very long time.

 

The issue is simple:  what are you protecting?

 

If it is your design, reverse engineering starts with your own user manual (documentation).  If a competitor wishes to compete, they will design and offer their own competing product.  It is unlikely they just clone yours, as that is not a good model (they may be sued, etc.).  Typical cloning is done on a small scale, skimming profits.  While annoying (and likely illegal), it seldom leads to much.  If over-building or cloning is the concern, the solution is first to get a trusted supply chain.  Encryption might be part of a solution, but by itself, it is not THE solution.

 

If you are trying to meet a safety standard, authentication is a must (to verify you are doing what was designed to to).

 

If you are a security system sub-system or component, we have all the features you need for that.  But, that is a specialized market, with many fewer sockets.

 

Quite simply, you do not put a $5000 lock on a $500 bicycle.  In fact, bicycles are sold without locks.

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Reply
Adventurer
Adventurer
3,740 Views
Registered: ‎04-23-2014

Is there a reference design available for the solution of UG1191? On page 180 it is stated that a hardware module (HWM) needs to be added to the design and connected to AXI GPIO. In Vivado's IP catalog, however, there is no hardware module. I also couldn't find anything with that name in the UltraScale Architecture Libraries Guide.

0 Kudos
Reply
Scholar
Scholar
2,264 Views
Registered: ‎02-27-2008

c,

 

OS and Libraries Document
Collection
UG643 (2017.1) April 5, 2017

 

Has the details. Starting page 180.

 

Code:

https://github.com/Xilinx/embeddedsw/blob/master/lib/sw_services/xilskey/examples/xilskey_bbram_example.c

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Reply
Adventurer
Adventurer
4,910 Views
Registered: ‎04-23-2014

I got it running after all. It seems like it works without the mysterious hardware module mentioned in UG643. In case someone else faces the same problems, here is the hardware design I used:

 

jtag.png

The two slice blocks extract bit position 1 and 2. The master_jtag_wrapper is just a simple wrapper IP for the master jtag.

 

I'm still a bit confused on how the xilskey library actually works, given that it is never told the address to which the AXI GPIO is mapped. But at least it works and I didn't brick my board :-)

View solution in original post

0 Kudos
Reply