04-02-2016 11:43 AM
I use the
set_property BITSTREAM.CONFIG.USR_ACCESS TIMESTAMP [current_design]
mechanism to have a build timestamp in the bit file and use
to read the value and make it avaialble on a diagnostic and control bus system in my designs.
The simulation model, at least the vhdl model USR_ACCESSE2.vhd, only returns 'uuuu...'.
Untreated that would create havoc in many simulations, the controls bus engines in general don't like undefines.
I have a catcher in my system, that writes an error message, and continues with an all '0' word.
To get even rid of this distraction I finally packed USR_ACCESSE2 into a wrapper which maps all 'u' and 'x' to '0'. Works now fine for simulation and synthesis.
What I wonder though is why the USR_ACCESSE2 UNISIM model is done in such an, imho, user unfriendly way. The implementation is simply
architecture USR_ACCESSE2_V of USR_ACCESSE2 is
signal CFGCLK_out : std_ulogic;
signal DATAVALID_out : std_ulogic;
signal DATA_out : std_logic_vector(31 downto 0);
CFGCLK <= CFGCLK_out;
DATA <= DATA_out;
DATAVALID <= DATAVALID_out;
so it simply returns uninitialized signals, thus (other=>'u').
What I'd love to have is a more simulation friendly behaviour, e.g. with a generic which allow to specify what the entiry returns in a simulation run.
04-03-2016 02:12 AM
To be more precise:
08-13-2019 12:11 PM
3 years after the initial post, after 8000+ page views and a kudo, this simple module is still in the 'a bit user unfriendly' state. It is apparently too trivial to fix it. That's so sad.
02-04-2021 04:56 AM
The year is 2021. Vivado 2020.2 has been released. The Xilinx primitive USR_ACCESSE2 still insists that 'U' is the generally accepted output value during simulation ... kudos