EFUSE registers in ZU3EG ES1

[cone83]

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.

[austin]

What version of Vivado are you using?

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

[cone83]

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.

[austin]

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.

[denist]

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.

[cone83]

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

[austin]

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.

[cone83]

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.

[austin]

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.

[cone83]

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.

[austin]

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

[cone83 · Accepted solution]

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:

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