cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
11,299 Views
Registered: ‎02-04-2013

dna_port

I am testing the dna_port on Artix7. When i simulate the dna_port, the first bit appear on data output only after 14 clock cycles. I could not find this delay/information in the datasheet. Is this expected output from the dna_port (please see image below)?

Regards
Klemen

 

 

dna_port.png

0 Kudos
6 Replies
Highlighted
Xilinx Employee
Xilinx Employee
11,244 Views
Registered: ‎02-14-2014

Re: dna_port

Hello @fogl,

 

Please check this AR

http://www.xilinx.com/support/answers/64847.html

Regards,
Ashish
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Explorer
Explorer
11,235 Views
Registered: ‎02-04-2013

Re: dna_port

Thank you for your reply.

 

This explains thing a bit more. But i still don't understand why is the DOUT set to X even after the READ was set to 1. The testcase at the end of the AR# 64847 reply does not show that.

 

My dna read procedure is done about 100 clock cycles after the boot up.

 

Regards

0 Kudos
Explorer
Explorer
11,212 Views
Registered: ‎12-06-2013

Re: dna_port

@fogl

 

I ran the simulation and had the expected results (not what you have).

device_dna_artix.png

 

I did re-run the simulation with "din" not initialized to see if I could duplicate your issue. If you don't initialize "din" to zero and your device SIM_DNA_VALUE is not the full 57 bits long (or you used a hex value which would only resolve to 56 or 60 bits) you will inject an unknown value into your simulation.

 

A quick fix is to assign "din" to zero when you declare the signal, i.e. signal din : std_logic := '0';

 

Hope this helps. FYI, I am using VSIM from Vivado 2015.3. I only mention this because my simulation model might be different than yours. Maybe you found an issue with a 3rd party model.

 

-JK

0 Kudos
Highlighted
Explorer
Explorer
11,189 Views
Registered: ‎02-04-2013

Re: dna_port

Thank you for you reply,

 

I am also using the Vivado 2015.3 and I also set the DIN value to '0':

DNA_PORT_inst : DNA_PORT
    generic map (SIM_DNA_VALUE => "110011001111001100111100110011110011001111001100111100110") -- Specifies a sample 57-bit DNA value for simulation)
    port map (
        DOUT => dna_data,       -- 1-bit output: DNA output data.
        CLK => rtnet_clk,       -- 1-bit input: Clock input.
        DIN => '0',             -- 1-bit input: User data input pin.
        READ => dna_read,       -- 1-bit input: Active high load DNA, active low read input.
        SHIFT => dna_shift      -- 1-bit input: Active high shift enable input.
    );

I tried different SIM_DNA_VALUE - the above with 57 bits exactly and also one suggested in hdl library guide (DIM_DNA_VALUE => X"000000000000000"). The simulation result is always the same, as shown in the above image.

 

The sim setings i use:

sim.png

0 Kudos
Highlighted
Explorer
Explorer
11,186 Views
Registered: ‎02-04-2013

Re: dna_port

Now i noticed that my clock frequency (125 MHz) was quite higher than yours, when i decreased the frequency to 25 MHz, everything was as expected :)

 

I checked the datasheet which limits the DNACK frequency to 100 MHz.

 

I was also wondering, are the DNA numbers generated randomly, or is the value incrementing by one, like serial number? I am asking because i would like to use only 10 bit DNA. Is there a high chance that i get the same DNA value on several IC, if i select the wrong part of DNA?

 

Regards

0 Kudos
Highlighted
Explorer
Explorer
11,003 Views
Registered: ‎12-06-2013

Re: dna_port

@fogl

 

Each dna value is a hash result of a sequential number (pseudo random). See this post. Using only 10-bits will allow for collisions which will not guarantee uniqueness.

 

On the frequency.....funny that the model didn't complain but even more peculiar is that the behavioral model broke at 125 MHz. 

0 Kudos