Mismatch between simulation and implementation.

[kimjaewon]

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.

[bruce_karaffa]

It looks like you have a 333MHz clock.  Do you have timing constraints?  Does your design meet these constraints after routing?

[drjohnsmith]

I'd guess the pre synthesis simulation works ?
which points more to a constraints problem,

you could try simulating just that bit of the code stand alone ,
just to check,

[markg@prosensing.com]

@kimjaewon 

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

[kimjaewon]

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.

[markg@prosensing.com]

@kimjaewon 

     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

[kimjaewon]

markg@prosensing.com 

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.

[markg@prosensing.com]

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

[kimjaewon]

markg@prosensing.com 

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.

[markg@prosensing.com · Accepted solution]

@kimjaewon 

     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:

1. A rising-edge (launch-edge) of the clock, clk_out1_clk_gen, occurs at time, 0.000ns (line 27)
2. This launch-edge travels through routes, IBUF, MMCM, and BUFGCE (lines 26-41) to reach ha_count_reg[4]/C at time, 3.471ns.
3. The data-input to ha_count_reg[4] this then clock to the data-output of ha_count_reg[4] and travels through routes, LUT4, and LUT6 to arrive at data-input, overflow_d1_reg/D, at time, 4.452ns (line 52).
4. A rising-edge (capture-edge) of the clock, clk_out1_clk_gen, occurs at time, 2.500ns (line 57). Note that 2.500ns is the period of clk_out1_clk_gen.
5. This capture-edge travels through routes, IBUF, MMCM, and BUFGCE (lines 57-71) to reach overflow_d1_reg/C at time, 6.255ns (line 71).
6. So, from 3) and 5) we find that the data entering overflow_d1_reg/D has arrived (6.255 – 4.452 = 1.803 ns) before overflow_d1_reg is clocked by the capture-edge. This data arrival time is well before the setup requirement of 0.025ns (line 76) for overflow_d1_reg.  So, the timing path from ha_count_reg[4]/C to overflow_d1_reg/D has passed setup timing analysis.

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