Instantiating USR_ACCESS_VIRTEX5 for FPGA Timestamp bricks my design

[tjsimms]

I am trying to use the Virtex-5 User Access Register to read the FPGA Timestamp from the bitstream.  I have followed XAPP497 for instantiating the USR_ACCESS primitive and setting the BigGen USR_ACCESS switch to TIMESTAMP. 

Without this primitive in my design, I am able to communicate with my FPGA over Ethernet and everything works properly.  When this primitive is instantiated in my design, it appears not to even program propperly as basic LEDs on the board do not come on and I am unable to even ping the board.  I do not get any synthesis errors.

I use the unisim library as follows:

library unisim;
use unisim.vcomponents.all;

And the primitive instantiation as follows:

  inst_USR_ACCESS_VIRTEX5 : USR_ACCESS_VIRTEX5
  port map (
            CFGCLK      => open, -- Config logic clock 1-bit output
            DATA        => timestamp,
            DATAVALID   => open
           );

The timestamp signal is captured in a register in my design.

Is there something I'm missing?  Are there additional configuration properties that need to be changed other than the -g USR_ACCESS property set to TIMESTAMP?

[drjohnsmith]

what you have works in my designs,
check you have unisim in your libs may be.

[tjsimms]

Thanks for your reply. 

I have since done a very simple build for a Virtex-5 LX110T.  The top level file only has a clock and a reset input, a heartbeat counter, the USR_ACCESS primitive, and 7 LED outputs.  I also added a Chipscope file that should show me the heartbeat counter and the value for the timestamp signal.  I program the FPGA via iMPACT and it says that it programmed successfully; however, none of the LEDs come on.  When I try to view the Chipscope signals, Chipscope says no valid units or devices are available.

[drjohnsmith]

I think you might have a much larger problme than timestamp then !

[tjsimms]

With the simple configuration I mentioned, the startup clock in the BitGen configuration parameters was set to CCLK.  If I use the JTAG Clock the USR_ACCESS primitive works. 

In my full design, I changed the startup clock to JTAG Clock and I was able to get the timestamp in the USR_ACCESS primitive to work.  It appears that the USR_ACCESS primitive will cause an entire design to brick if the CCLK is used.  The problem is, I need to boot from a PROM in my system; I won't always be able to program via JTAG.

[drjohnsmith]

does user access need a clock input ?

look in the docs

oh your right, the docs dont say !!!!

amazig bad documentaton ,

You dont need a clock into user_access just to read out the timestamp.

[pratham]

@tjsimms While configuring device using JTAG your clock should be changed automatically to the JTAGCLK from CCLK. You can check the same in the log but the original bitstream remains unchanged,

INFO:iMPACT:2257 - Startup Clock has been changed to 'JtagClk' in the bitstream stored in memory,
but the original bitstream file remains unchanged.

I am surprise to know that even simple program isnt working because of this change.

[tjsimms]

@pratham I agree that the start up clock is changed automatically to JTAG if programming over JTAG without changing the bitstream. I verfied the iMPACT info comment.

I have attached my simple program. I am targeting a xc5vlx110t-1ff1136. I am using ISE 13.3.

I've also included a Chipscope file that displays the heartbeat and the timestamp. You can see when the startup clock is JTAG, you are able to view the timestamp in Chipscope. If the startup clock is CCLK, Chipscope can't find the core.  Currently, the project is set to CCLK as the startup clock.

[pratham]

@tjsimms Thanks for the project. I am affraid if i have this part but will create another design or will take same design and modify it  for my part and will get back to you.

[pratham]

@tjsimms I had a chance to create a design and run it on KC705 board.

Here are my observations

1) You dont need to have JTAGCLK set when USER_ACCESS is used in the design

2) I have seen your design, what i suspect here is you might have some problem with the clock or clock enable or any other. There is no need to assign DATA to register. You can directly probe the dataout of user_access.

Value read from the USER_ACCESSE2 is

00111_0001_010000_01110_0010000_000000

Where: dddddd = 5 bits to represent 31 days in a month MMMM = 4 bits to represent 12 month in a year yyyyyy = 6 bits to represent 0 to 63 (to note year 2000 to 2063) hhhhh = 5 bits to represent 23 hours in a day mmmmmm = 6 bits to represent 59 minutes in an hour ssssss = 6 bits to represent 59 seconds in a minute

Timestamp

07 _01_2016_2:16:00

Please check the snapshots attached.

I believe the behaviour should be same for 

• Virtex-5: USR_ACCESS_VIRTEX5 • Virtex-6: USR_ACCESS_VIRTEX6 • Artix™-7: USR_ACCESSE2 • Kintex™-7: USR_ACCESSE2 • Virtex-7: USR_ACCESSE2

[tjsimms]

@pratham thank you for trying the project.

I also tried this simple project on an ML506 developement kit (xc5vsx50t) and discovered the same issue as I described originally. The design does not load properly when the startup clock is CCLK and you program the FPGA over JTAG.  The design does load properly with the startup clock set to JTAG CLK.

What I tried this time is generating the programming file with the startup clock set to CCLK and programming one of the PROMs with the .mcs file rather than programming the FPGA.  After cycling power, the design loaded properly.  So I tried this method with my original design and verified that the timestamp is read properly from my design.  What I like to do, though, is verify my changes by just programming the FPGA over JTAG before loading the PROM with a new build.  If I use the USR_ACCESS_VIRTEX5 primitive, however, I will just have go directly to programming the PROM rather than the FPGA.

Maybe this is issue only occurs with a Virtex 5 since you were unable to reproduce the problem with a Kintex-7?

Thanks for your response.

[pratham]

@tjsimms I am suspecting the same. If i get chance i might try this on V5 as well meanwhile let me know how it goes.