To work around the issue, ensure that the data and tristate do not switch within the problematic window (dataValidBeforeTristate = 0.550ns and dataValidAfterTristate = 0.200ns).
In Vivado 2021.2 and later versions, a DRC will flag this issue to users:
[DRC RPBF-8] HDIO buffer out T and I constraints check: Missing set_data_check constraint to ensure there is a minimum skew between IOBUF I and T pins of cell IOBUF_I connected to port IOBUF_IO_IO_0[0] (IOSTANDARD is LVCMOS25). Resolution: please check AR76846 for more information on how to address this violation.
The following are possible approaches to ensure that the data and tristate are not switching within the problematic window:
1) Design systems that offset tristate and data switching by a cycle.
2) Registered Data and Tristate signals can leverage a logical OR of Data and Tristate into the I input of the IOL Flop to avoid the issue.
Replace
With 
Example Timing Diagram:
3) Ensure that Data and Tristate nets are skewed enough to ensure that both data and tristate avoid the race condition using the set_data_check constraints through the Tcl script.
Note: the issue will only occur when both data and tristate toggle. Open Drain interfaces maintain constant ‘0’ on the Data pin, so common 2.5V and 3.3V interfaces, such as I2C, will not be impacted.
You can wave the DRC with the following commands only if the data or tristate are tied off.
create_waiver -type DRC -id RPBF-8 -description {Waiver for AR#76846} -object [get_cells IOBUF_inst]
create_waiver -type DRC -id RPBF-9 -description {Waiver for AR#76846} -object [get_cells IOBUF_inst]
For Vivado 2022.1 and prior versions you can use the attached script fixHDIO.tcl to assess the impact and potentially fix the issue with routing.
The script will check the design for IOBUF or OBUFTs and check for the delays between the tristate and data and flag if they switch within the problematic window.
If they do, the script will unroute the nets and reroute with the set_data_check set and will report the results.
To run the script, open the Implemented Design or DCP.
In the Tcl console, source the script:
source -quiet fixHDIO.tcl
Once the Tcl script has been sourced, several procedures can be run to analyze the design:
- getHDIOTristateBuffers - Lists all buffers with tristate control in HDIO banks powered at 2.5V or 3.3V that can be impacted by the tristate/data race issue.
- reportHDIOTristateBuffers - Reports all buffers with tristate control in HDIO banks powered at 2.5V or 3.3V that can be impacted by the tristate/data race issue as well as description of the mechanism for why they are reported.
- validateHDIOTristateBuffers - This command will analyze the design to see if there is sufficient timing margin to avoid the race condition when fixHDIOTristateBuffers has not yet been run. If violations occur, fixHDIOTristateBuffers must be run to resolve the issue.
- waiveHDIOTristateBuffers <buffers> - The command should only be used to waive the DRC violations for the registered buffers that implement an OR gate between the tristate/data pins or that are known not to be impacted (i.e. data and tristate control are offset in the design). The DRC violations for these buffers should be automatically suppressed after running fixHDIOTristateBuffers. This procedure should ONLY be run on buffers where the issue is known not to exist. fixHDIOTristate buffer will resolve the issue by changing the timing and should be used for all buffers where the problematic scenario might exist.
- fixHDIOTristateBuffers <buffers> - Reroutes data and tristate nets for buffers that do not have sufficient data and tristate skew. The command does not fix registered buffers that require an OR gate between the tristate/data pins. Timing relationships are reported at the conclusion of this procedure. At the conclusion of this procedure, "report_route_status" should be run in Tcl to verify that the script was able to successfully reroute the nets. Failure to do this can result in the script incorrectly reporting that all timing paths are met.
- timeHDIOTristateBuffers <buffers> - Reports the timing relationship between the data and tristate pins. The command should be run after fixHDIOTristateBuffers inserts the necessary timing constraints. Only positive slacks are expected if the tool is able to find a routing solution.
Analyzing the results:
fixHDIOTristateBuffers and timeHDIOTrisateBuffers will report the timing on the buffers provided. A positive slack value indicates that the script was able to successfully re-route the Data (I) and Tristate control (T).
In order to properly time this scenario, either data or tristate will be given a requirement of 1000ns. It is expected that one net will have a large skew requirement. As long as both nets are positive, the HDIO tristate collision will not occur.
Messages similar to the one below indicate that the router was unable to re-route the design with sufficient skew if the Tcl script was unable to resolve the issue with a new route.
Note: this is a scenario where this warning might still be OK if there is positive slack reported:
WARNING: [Route 35-348] Router failed to meet '-min_delay' requirement of…
The script will not make any attempt to resolve cases where the IOB flip flops register data and tristate, although it will flag them.
These pins will require the implementation of a logically equivalent circuit change described above, OR the data and tristate nets that drive the input pin of the IOB data register.
If the Tcl script is unable to successfully reroute the Data and Tristate pins in a manner that avoids the issue, the design will need to be modified. Common modifications around the issue include:
• Registering the data and tristate control signals and OR’ing the Data Control with the tristate control as described above
• Adjusting the design such that tristate and data assertion are offset by a cycle
In the unlikely event that the script is not able to resolve the issue, please assess Option 1 "offset tristate and data switching by a cycle" and Option 2 "logical OR of Data and Tristate" and make the necessary changes to the design.
If you require further assistance please contact Xilinx Technical Support.
- 09/30/2021: Initial Release
- 10/28/2021 : Added clarification that tristate and data need to be switching in opposite directions for race condition to cause issues.
- 12/13/21 : Updated script with new validateHDIOTristateBuffers command and added validateHDIOTristateBuffers description. Updated figures.
- 05/30/22 : Updated Vivado version for script to include 2022.1
- 06/18/23 Updated devices that include HDIO