BACKGROUND
When I build my project, I get only a single class of timing errors. The negative slack is small, but unfortunately negative. I remembered an example which shows analyzing a basic model of synchronous design using a single clock with the help of timing diagram (http://www.kynix.com/Blog/439.html), and then I looked at the worst route and develop an understanding of what's going on. For the Source Clock Path, a slow/late worst case timing is calculated. For the Destination Clock Path, a fast/early worst case timing is calculated. Then, the Data Path in question needs to be faster than the difference in the Source and Destination clock paths. (That's my correct understanding. The tool itself adds the Data Path slow/late worst case timing to the Source Clock Path, and wants the result to be less than the fast/early worst case Destination Clock Path. The numerical result of what the tool does and my sentence of correct understanding is the same.)
QUESTION:
I have an IOBUFDS and BUFG between my SYSCLK_P/SYSCLK_N pins and my internal SYS_CLK. There's delay through there. Even though my Data Path is from SYS_CLK to SYS_CLK, the timing analysis is calculating from SYSCLK_P to SYSCLK_P. As a result, the difference in slow/late and fast/early timing through those initial clock buffers is lessening the allowed time for my Data Path. I know this is improper, because timing variations shouldn't matter when they are prior to the SYS_CLK shared by the source and destination of my Data Path.
My understanding is that Vivado automatically generates clocks. I figure it should be generating a SYS_CLK from my SYSCLK_P. I believe Vivado should be calculating Source Clock Path and Destination Clock Path from SYS_CLK, not SYSCLK_P. If it did this, it would indeed correctly omit the initial clock buffer timing difference (slow/late vs fast/early). But it's not.
In order to get what I know should be correct, is it necessary for me to explicitly put in my own clock constraint for SYS_CLK?
The timing in question is shown below. I've added red bubbles that point to the shared SYS_CLK timing point. However, the Source and Destination Clock Paths differ for this point by 4.761ns. They should have no slow vs fast timing skew and should differ by 5ns. I've been shorted 0.239ns. That's time I could use in my failing path. In fact, my failing path would pass.
In addition, I can see that the name "SYS_CLK" is not explicitly listed(where I believe it should be listed). This should probably tell me something as well!
RECOMMENDATION:
I'm still using Vivado 2017.1, You know, Vivado should really automatically recognize the common portion of any Source Clock Path and Destination Clock Path and remove those common portions from the timing analysis.
FAILING RESULTS:
So I tried. I already had a constraint for SYSCLK_P. I added one for SYSCLK per below:
However, it didn't help. Also, the specific path timing still doesn't show "SYS_CLK". I suspect my intent is correct, but that I specified the create_clock incorrectly.
Now I need assistance, please. Thanks in advance.
When I build my project, I get only a single class of timing errors. The negative slack is small, but unfortunately negative. I remembered an example which shows analyzing a basic model of synchronous design using a single clock with the help of timing diagram (http://www.kynix.com/Blog/439.html), and then I looked at the worst route and develop an understanding of what's going on. For the Source Clock Path, a slow/late worst case timing is calculated. For the Destination Clock Path, a fast/early worst case timing is calculated. Then, the Data Path in question needs to be faster than the difference in the Source and Destination clock paths. (That's my correct understanding. The tool itself adds the Data Path slow/late worst case timing to the Source Clock Path, and wants the result to be less than the fast/early worst case Destination Clock Path. The numerical result of what the tool does and my sentence of correct understanding is the same.)
QUESTION:
I have an IOBUFDS and BUFG between my SYSCLK_P/SYSCLK_N pins and my internal SYS_CLK. There's delay through there. Even though my Data Path is from SYS_CLK to SYS_CLK, the timing analysis is calculating from SYSCLK_P to SYSCLK_P. As a result, the difference in slow/late and fast/early timing through those initial clock buffers is lessening the allowed time for my Data Path. I know this is improper, because timing variations shouldn't matter when they are prior to the SYS_CLK shared by the source and destination of my Data Path.
My understanding is that Vivado automatically generates clocks. I figure it should be generating a SYS_CLK from my SYSCLK_P. I believe Vivado should be calculating Source Clock Path and Destination Clock Path from SYS_CLK, not SYSCLK_P. If it did this, it would indeed correctly omit the initial clock buffer timing difference (slow/late vs fast/early). But it's not.
In order to get what I know should be correct, is it necessary for me to explicitly put in my own clock constraint for SYS_CLK?
The timing in question is shown below. I've added red bubbles that point to the shared SYS_CLK timing point. However, the Source and Destination Clock Paths differ for this point by 4.761ns. They should have no slow vs fast timing skew and should differ by 5ns. I've been shorted 0.239ns. That's time I could use in my failing path. In fact, my failing path would pass.
In addition, I can see that the name "SYS_CLK" is not explicitly listed(where I believe it should be listed). This should probably tell me something as well!
RECOMMENDATION:
I'm still using Vivado 2017.1, You know, Vivado should really automatically recognize the common portion of any Source Clock Path and Destination Clock Path and remove those common portions from the timing analysis.
FAILING RESULTS:
So I tried. I already had a constraint for SYSCLK_P. I added one for SYSCLK per below:
Code:
create_clock -period 5.000 -name SYSCLK -waveform {0.000 2.500} [get_ports SYSCLK_P]
# Below, add SYS_CLK directly to try and reduce timing analysis skew between fast/slow cases that both go through SYS_CLK_intermediate
create_clock -period 5.000 -name SYS_CLK -waveform {0.000 2.500} [get_ports SYS_CLK]However, it didn't help. Also, the specific path timing still doesn't show "SYS_CLK". I suspect my intent is correct, but that I specified the create_clock incorrectly.
Now I need assistance, please. Thanks in advance.