08-31-2019 03:20 AM - edited 08-31-2019 03:24 AM
Hello.
Below figure is fraction of my VHDL code.
Between signal overflow and overflow_d1, there is a flip-flop as below figure.
After Implementation, figure2 is instantiated as below figure.
But after Post-Implementation Timing Simulation, I got the below result.
My question is why does the signal overflow_d1 changes before the clock rising_edge?
If figure2 is instantiated, should signal overflow_d1 be activated after the rising_edge of the clock? (after the vertical yellow line?)
Thanks for your help.
09-11-2019 12:42 PM
The first solution you mentioned …. made an error; ERROR: [Vivado 12-4739] report_timing: No valid object(s) found for '-from [get_pins inst_tdc/cmp_controller/overflow_reg/C]'.
You are getting this error because the signal called “overflow” does not come from a register. Instead, it is a signal coming from combinational logic (LUTs) where several signals are combined. This is not a problem. Rather, it is just me guessing (incorrectly) what the rest of your circuit looked like.
So I followed your second solution, which is the below code, and it worked.
Yes, this Tcl command generated a timing report for a signal that originates at register, ha_count_reg[4], travels through combinational logic (LUTs) to become signal “overflow”, and finally enters register, overflow_d1_reg. Note that the timing report is for a timing-path that starts at the clock-pin, ha_count_reg[4]/C, of the source-register (line 4) and ends at the data-pin, overflow_d1_reg/D, of the destination register (line 6). This clock-pin to data-pin path is typical for a timing-path between two registers.
Here is what the timing report is telling us:
You can always trust Vivado timing reports to tell you exactly what is happening with clocks and data as data is passed from one register to another register inside the FPGA. Note that the interpretation we get from the timing report is similar to the interpretation that you showed us in your 09-01-2019 post above. So, kudos to you!
As you have found, it is sometimes difficult to interpret things from post-implementation timing simulation.
Mark
08-31-2019 03:26 AM
It looks like you have a 333MHz clock. Do you have timing constraints? Does your design meet these constraints after routing?
08-31-2019 05:57 AM
09-01-2019 04:22 AM
You are showing us what appears to be negative clock-to-output (C_Q) time for register, overflow_d1_reg. Note that this C_Q time is a very small number, -0.0002ns, which could be due to numerical limitations of the tools. Note also that simulation has not told you where the clk_i waveform is measured. That is, the clk_i waveform is probably not as it appears at the clock-pin of overflow_d1_reg. Instead, it is probably the clk_i waveform as it appears at its source. So, what you see as negative C_Q may be caused by skew/deskew of the clock through the clock distribution network.
Perhaps you could “Open Implemented Design” for your project and type the following command in the “Tcl Console”.
report_timing -from [get_pins overflow_d1_reg/C] -setup
This will give you a timing report. In this report, you will find a line that looks like the following, which is telling you the C_Q time (0.198ns in this example) of overflow_d1_reg.
SLICE_X0Y171 FDRE (Prop_fdre_C_Q) 0.198 -1.626 r overflow_d1_reg/Q
Thus, from the timing report, you can see whether overflow_d1_reg actually has a negative C_Q time.
Mark
09-01-2019 07:27 PM - edited 09-01-2019 07:31 PM
Thanks for your help.
I want to know if I understood correctly.
In the above figure, the purple line is the rising_edge of the clock source.
After the clock path delay, the rising_edge arrives at the FF.
The green line is when the actual rising_edge of the clock signal arrives at the clock port in the FF.
After the clock-to-output time, The output port of the FF activates.
The yellowish green line is when the output port of the FF (overflow_d1) is asserted high.
After hold time, the input port (overflow) is de-asserted.
Is my explanation correct?
Thanks for your help.
09-02-2019 04:21 AM
Is my explanation correct?
We can verify your explanation using a timing report. You can get this timing report after you "Open Implemented Design" and type the following command in the lower-part of "Tcl Console" window.
report_timing -from [get_pins overflow_reg/C] -to [get_pins overflow_d1_reg/D] -setup
The command will cause the timing report to be shown in the upper-part of the Tcl Console window. Please copy and paste this timing report into your next post to us - and we can talk about it.
Mark
09-08-2019 07:11 PM - edited 09-08-2019 07:20 PM
Hello.
Thanks for your advice.
I followed your instructions to figure out the problem (I'm using Vivado 2018.02 and my board is KCU116).
First of all, the FF looks like below figure.
I opened my Implemented Design and typed below command in the "Tcl Console" as you told in your first reply.
report_timing -from [get_pins inst_tdc/cmp_controller/overflow_d1_reg/C] -setup
I got the following result
Through line 41, 42, 44 and 45, I found out that clock-to-output (C_Q) is 0.078 ns which is not negative.
So as you told, it is probably the clk_i waveform as it appears at its source and what I see as negative C_Q may be caused by skew/deskew of the clock through the clock distribution network.
After that, I typed the below command in the "Tcl Console" as you said in your second reply (I'm not sure what you mean in lower-part of "Tcl Console" window so I just wrote it in the normal Tcl Console).
report_timing -from [get_pins inst_tdc/cmp_controller/overflow_d1_reg/C] -to [get_pins inst_tdc/cmp_controller/overflow_d1_reg/D] -setup
But the result is like below.
Timing Report No timing paths found.
So I changed the command /D to /Q in the last part but the result was same.
report_timing -from [get_pins inst_tdc/cmp_controller/overflow_d1_reg/C] -to [get_pins inst_tdc/cmp_controller/overflow_d1_reg/Q] -setup
I think I got that result because I didn't type the following command in the lower-part of "Tcl Console" window as you said.
What does the lower-part and upper-part mean in the "Tcl Console" window?
Thank you very much.
09-09-2019 05:02 AM
The above screenshot shows upper-part and lower-part of Tcl Console window. Tcl commands are typed into the lower-part and when you hit “Enter” the results of the Tcl command are displayed in the upper-part.
In the lower-part of the Tcl Console, please type the following command and hit “Enter”. The timing report that we need should then be displayed in the upper-part of the Tcl Console. Please show us the timing report.
report_timing -from [get_pins inst_tdc/cmp_controller/overflow_reg/C] -to [get_pins inst_tdc/cmp_controller/overflow_d1_reg/D] -setup
If the above Tcl command does not produce the timing report, then try the following Tcl command.
report_timing -to [get_pins inst_tdc/cmp_controller/overflow_d1_reg/D] -setup
09-10-2019 07:45 PM - edited 09-10-2019 07:54 PM
Hello.
Thank you for your advice.
The first solution you mentioned, which is the below code, didn't work and made an error; ERROR: [Vivado 12-4739] report_timing:No valid object(s) found for '-from [get_pins inst_tdc/cmp_controller/overflow_reg/C]'.
report_timing -from [get_pins inst_tdc/cmp_controller/overflow_reg/C] -to [get_pins inst_tdc/cmp_controller/overflow_d1_reg/D] -setup
So I followed your second solution, which is the below code, and it worked.
report_timing -to [get_pins inst_tdc/cmp_controller/overflow_d1_reg/D] -setup
The result is as below figure.
Through line 52, 53 and line 71~76, I found out that there is no problem in timing.
From my above reply, clock-to-output (C_Q) is 0.078 ns which is not negative.
And it is probably the clk_i waveform as it appears at its source and what I see as negative C_Q may be caused by skew/deskew of the clock through the clock distribution network.
As below figure, the overlapping part between overflow and overflow_d1, I guess, is related to hold time or other reasons.
Logically, when the clock signal arrives at the clock port in FF, overflow_d1 asserts ('0'->'1') and overflow deasserts ('1'->'0').
However, To avoid hold time problem, the overflow deasserts ('1' -> '0') a few moments after the clock.
So that is why there is a term when both overflow and overflow_d1 are '1'.
Another reason is, maybe the combinational logic to make the overflow '0' takes some time due to net and cell delays.
Thank you for your help.
09-11-2019 12:42 PM
The first solution you mentioned …. made an error; ERROR: [Vivado 12-4739] report_timing: No valid object(s) found for '-from [get_pins inst_tdc/cmp_controller/overflow_reg/C]'.
You are getting this error because the signal called “overflow” does not come from a register. Instead, it is a signal coming from combinational logic (LUTs) where several signals are combined. This is not a problem. Rather, it is just me guessing (incorrectly) what the rest of your circuit looked like.
So I followed your second solution, which is the below code, and it worked.
Yes, this Tcl command generated a timing report for a signal that originates at register, ha_count_reg[4], travels through combinational logic (LUTs) to become signal “overflow”, and finally enters register, overflow_d1_reg. Note that the timing report is for a timing-path that starts at the clock-pin, ha_count_reg[4]/C, of the source-register (line 4) and ends at the data-pin, overflow_d1_reg/D, of the destination register (line 6). This clock-pin to data-pin path is typical for a timing-path between two registers.
Here is what the timing report is telling us:
You can always trust Vivado timing reports to tell you exactly what is happening with clocks and data as data is passed from one register to another register inside the FPGA. Note that the interpretation we get from the timing report is similar to the interpretation that you showed us in your 09-01-2019 post above. So, kudos to you!
As you have found, it is sometimes difficult to interpret things from post-implementation timing simulation.
Mark