Forum Discussion
Timing constraints for external logic that takes input from, and outputs to an FPGA
The internal delays would be set up based on the external delay. That's how set_input_delay and set_output_delay work. If you define the external delay with set_max_delay and set_min_delay, it should work the same way.
I added the following constraints.
set_max_delay -from [get_ports output_port] -to [get_ports input_port] 10.368 set_max_delay -from [get_ports output_port] -to [get_ports input_port] 0
After rerunning compilation and checking timing, Delays and the Clock Skews for the Registers immediately before the output ports and after the input ports are as follows:
- Clock Delay for the output register is 8.263ns
- The data delay from the output register to the output port is 8.302ns
- The maximum external propagation delay is 10.368ns
- Clock Delay for the input register is 7.773ns
- The data delay from the input port to the input register is 9.817ns
- The clock is running at 120MHz = 8.333ns
The question is, what kind of analysis is being performed on this path now? The ports are currently unconstrained so it is not doing a synchronous analysis.
Doing the math here, there is a negative slack of:
Data Required Time - Data Arrival Time = Slack
(8.333+7.773+9.817) - (8.263+8.302+10.368 ) = -1.01ns
It's not doing that analysis nor reporting the "violation". I expect it to report the violation because the maximum external delay would cause the data to arrive after the latch clock edge.
- sstrell2 years ago
Super Contributor
Why do you have two set_max_delay constraints with different values? The second one should be set_min_delay.
Your data required calculation is incorrect. It should be (8.333 + 7.773 - tsu), whatever the setup timing requirement of the input register is.
Your data arrival time calculation is missing the data input delay. It should be (8.263 + 8.302 + 10.368 + 9.817) but that obviously makes things worse. The input and output delays and clock delays are way too big. The input and output registers are getting placed very far from the I/O to have data delays over 8 and 9.
Are you using a PLL? Have you tried using the fast I/O register assignments to use the registers located directly in the I/O cells?
And you're saying the tool still says these I/O are unconstrained?
- TuckerZ2 years ago
Occasional Contributor
Typed the command twice. The first is the correct one.
Yes, thank you for the corrections. It is even worse than what I originally typed out.
The implementation details are not of importance since I am working on those still. The tool should have certainly caught the timing issues at this point considering such abysmal timing.
The tool does say these I/O are unconstrained.
I'm not sure the set_max_delay command did what I wanted it to do considering it didn't catch this. Any Insight?
set_max_delay -from [get_ports output_port] -to [get_ports input_port] 10.368