Xilinx DNA seems wrong

[maleadt]

I'm trying to use the Xilinx DNA (device identifier) to differentiate between devices, but it seems like the value as read by litepcue_util is wrong. After adding an DNA instance to my build:

self.submodules.dna = DNA()
self.dna.add_timing_constraints(platform, sys_clk_freq, self.crg.cd_sys.clk)

I'm seeing:

$ ./litepcie_util info
FPGA identification: LiteX SoC on Fairwaves XTRX 2022-08-29 12:25:45
FPGA dna: 0x01c01c1c1df01f1f

That already looks suspiciously regular for an identifier, and indeed Vivado (using the get_dna.tcl script I found here) reports something different:

****** Vivado v2022.1 (64-bit)
  **** SW Build 3526262 on Mon Apr 18 15:47:01 MDT 2022
  **** IP Build 3524634 on Mon Apr 18 20:55:01 MDT 2022
    ** Copyright 1986-2022 Xilinx, Inc. All Rights Reserved.

source /tmp/dna.tcl
# set HW_SERVER localhost:3121
# open_hw
WARNING: 'open_hw' is deprecated, please use 'open_hw_manager' instead.
# if {[llength [get_hw_servers]] == 0 } then {
#     connect_hw_server -quiet -url $HW_SERVER
#     set disconnect_en 1
# }
WARNING: [Labtoolstcl 44-132] No matching hw_servers were found.
# refresh_hw_server -quiet
# foreach TARGET [get_hw_targets] {
#     if { [get_property IS_OPENED $TARGET] } then {
#         close_hw_target -quiet $TARGET
#   }
# }
# foreach TARGET [get_hw_targets] {
#     open_hw_target -quiet $TARGET
#     refresh_hw_target -quiet $TARGET
#     foreach DEVICE [get_hw_devices] {
#         refresh_hw_device -quiet $DEVICE
#         if { [get_property PROGRAM.IS_SUPPORTED $DEVICE] } then {
#             set DNA_HEX [get_property REGISTER.EFUSE.FUSE_DNA $DEVICE]
#             puts "FUSE_DNA: $TARGET=>$DEVICE = DNA(hex)=$DNA_HEX"
#             set DNA_HEX [get_property REGISTER.EFUSE.DNA_PORT $DEVICE]
#             puts "DNA_PORT: $TARGET=>$DEVICE = DNA(hex)=$DNA_HEX"
# }
#   }
#   close_hw_target -quiet $TARGET
# }
DNA_PORT: localhost:3121/xilinx_tcf/Digilent/210249B06F39=>xc7a50t_0 = DNA(hex)=10445867A084854
FUSE_DNA: localhost:3121/xilinx_tcf/Digilent/210249B06F39=>xc7a50t_0 = DNA(hex)=2A12105E61A2208F
# if {$disconnect_en == 1 } {
#     disconnect_hw_server -quiet
# }
INFO: [Common 17-206] Exiting Vivado at Mon Aug 29 14:35:50 2022...

This is on an XTRX SDR which contains an Artix 7.

Some sources also say I should be using FUSE_DNA (64 bits) instead of DNA_PORT (57 bits, may be shared across devices), but I'm not sure how to access that from Verilog. Naively substituting DNA_PORT with FUSE_DNA in dma.py (and adjusting the size) doesn't work.

[enjoy-digital]

Hi @maleadt,

strange, this is a feature that is used on various designs and has been validated. I'll do a test with the XTRX.

[enjoy-digital]

I just did a verification on an SQRL Acorn and get the expected DNA:

With Vivado:

With LiteX/LitePCIe:

Since the issues does not seem to be seen with other XTRX, this would need to be investigated on the XTRX integration and see if there is something specific.

[maleadt]

The DNA is wrong on the other XTRXs as well, we only thought that the wrong values were still unique so that we could use them as serial numbers (even though they differ from DNA_PORT). Turns out that's not the case as well, and they seem to sometimes change across reboots.

So I think we should re-open this?

[maleadt]

And just to confirm that what I reported above with the TCL script is correct, I also checked the GUI:

vs. litepcie_util info now on latest LiteX:

$ ./litepcie-user-library/litepcie_util info
[> FPGA/SoC Information:
------------------------
FPGA Identifier:  LiteX SoC on Fairwaves XTRX 2022-08-31 22:01:10.
FPGA DNA:         0x00c01c1c1cf00f0f
FPGA Temperature: 61.5 °C
FPGA VCC-INT:     0.93 V
FPGA VCC-AUX:     1.77 V
FPGA VCC-BRAM:    0.93 V

As you can see, the DNA reported here is different from what I reported earlier (0x01c01c1c1df01f1f). Or is that because the DNA is only 56 bits, so the upper couple of ones are bogus and should be masked out? In that case litepcie_util probably shouldn't print them.

[enjoy-digital]

@maleadt: I'll do a test on the XTRX and try to fix if I also see the issue.

[maleadt]

Confirmed that https://github.com/enjoy-digital/litex/commit/b24d744f8ed553c023e6ab54e05d237de3dadbb7 fixes this.