Because USR_ACCESSE2 data is stored in the AXSS Configuration register, the data can be dynamically updated through JTAG commands or through the use of ICAPE3. See Configuration Packets for the form of packets that write to the AXSS register. For dynamic updates of the AXSS register, the waveforms from the USR_ACCESSE2 primitive that reflect the update events are shown in the following figure.
UltraScale+ devices add a special internal pin for the timing of the
USR_ACCESSE2 output pins. The internal pin is not visible but accessible through the Vivado get_pins command. To constrain USR_ACCESSE2 in UltraScale+, a clock needs to be
defined on the internal clock pin. The clock definition triggers the proper timing arcs on the
DATA[31:0] and DATAVALID interfaces. Pin descriptions are
provided in the following table.
| USR_ACCESSE2 Pin | Internal Pin for Constraints | Description |
|---|---|---|
| CFGCLK | CCLK | Equivalent to device CFGCLK pin. |
| DATA[31:0] | CCLK | Rising-edge output register. |
| DATAVALID | CCLK | Rising-edge output register. |
The following is an example of constraints for
the special internal USR_ACCESSE2 timing pin, specifically an example for
creating a primary clock on the internal pin. For a 200 MHz (5 ns period), a 50% duty cycle
CCLK clock constraint on the USR_ACCESSE2_inst.CCLK clock
source pin covers the timing paths from DATAVALID or
DATA[31:0] to the destination register clocked by
USR_ACCESSE2.CFGCLK.
create_clock -period 5.000 -name CLOCK [get_pins USR_ACCESSE2_inst/CCLK]Example constraints are shown if USR_ACCESSE2.DATAVALID and USR_ACCESSE2.DATA max delays are required. In some cases, the skew between USR_ACCESSE2 and the first level of registers can result in a difficult timing closure on those paths. The skew is introduced by the clock buffer connected between the pin USR_ACCESSE2.CFGCLK and the clock pins of the logic registers. When such a scenario occurs, it is possible to over-constrain the paths driven by USR_ACCESSE2 by changing the path requirement using a max delay constraint. The over-constraining mechanism forces the logic connected to USR_ACCESSE2 to be placed close to it. You should use this mechanism carefully because over-constraining too much can result in difficulty with timing closure.
In the following example, the path requirement is
changed from a 5 ns (clock period defined on CCLK) to 3.5 ns:
set_max_delay -from [get_pins <USR_ACCESS>/DATAVALID] -to [get_pins datavalid_reg/D] 3.5
set_max_delay -from [get_pins <USR_ACCESS>/DATA[*]] -to [get_pins data_reg[*]/D] 3.5