carry4 primitive simulation inconsistency

@sawaak
It would be very difficult to observe such delay in simulation.
Have you used the Vivado STA tools to check for the specific paths?
The tool can report the individual path delays and you can check if your desired delay is being applied or not.

Thank you for your comment dpaul.

dpaul said:

It would be very difficult to observe such delay in simulation.

Click to expand...

Even with a simulation timestep of 1ps? I am sure the delays would be bigger than that.

dpaul said:

Have you used the Vivado STA tools to check for the specific paths?
The tool can report the individual path delays and you can check if your desired delay is being applied or not.

Click to expand...

How to do that? Would greatly appreciate if you could give me a pointer to a relevant example.


Thank you,
sawaak

Even with a simulation timestep of 1ps? I am sure the delays would be bigger than that.

Click to expand...

Analyzing/measuring signal delays from waveforms is not the correct way to proceed.

How to do that? Would greatly appreciate if you could give me a pointer to a relevant example.

Click to expand...

You need to generate a Timing Path Report.
Read UG906 v2022.1, page 78, in which it says how would you analyze a timing path report.
In such a detailed report, you can see which path adds what amount of delay.

Read all relevant Xilinx documentations!

If I understand right, post#1 shows an RTL schematic. It's not necessarily implemented exactly as shown, redundant logic may be eliminated if not "frozen" by synthesis attributes. You can check the gate level schematic.

FvM said:

If I understand right, post#1 shows an RTL schematic.

Click to expand...

I do not think the OP has synthesized the design. It ilooks like a pre-synthesis netlist, commonly generated by the step "Elaborate Design" in Vivado tool.

dpaul said:

You need to generate a Timing Path Report.
Read UG906 v2022.1, page 78, in which it says how would you analyze a timing path report.
In such a detailed report, you can see which path adds what amount of delay

Click to expand...

Thank you dpaul. I will go through it and get back soon.

FvM said:

If I understand right, post#1 shows an RTL schematic. It's not necessarily implemented exactly as shown, redundant logic may be eliminated if not "frozen" by synthesis attributes. You can check the gate level schematic

Click to expand...

Thank you FvM for your reply.

The schematic in post#1 was generated after synthesis and the simulation results are generated using post-synthesis timing simulation. cwire[7:0] signal was preserved using keep attribute. As far as I understood, even if the logic is removed after implementation step (need to check this), the cwire [7:0] signal is there in the synthesized netlist and should behave as per specification.

I will run implementation and get back with the results soon.

dpaul said:

I do not think the OP has synthesized the design. It ilooks like a pre-synthesis netlist, commonly generated by the step "Elaborate Design" in Vivado tool.

Click to expand...

I had synthesized the design and its post synthesis netlist. The elaborated netlist doesn't include IBUF, BUFG, OBUF primitives

sawaak said:

I will run implementation and get back with the results soon.

Click to expand...

I have implemented the design and the schematic looks almost identical as attached. The simulation is slightly changed with respect to post-synthesis simulation in that the delay arrangement of COUT signal is a bit different. Other than that, cwire[7:0] signal still behaves the same and as shown, is present in the post-implementation netlist and not optimized away.

Hi sawaak,

Educated guess here (if I correctly understand what you´re trying to measure):
carry_4_test_0 and carry_4_test_1 have 1x input to 4x outputs which seems to have the same delay (for example, way from carry_4_test_0 output 3 => carry_4_test_1). Thus, the delay from signal_i_BUF => carry_4_test_0 output[3:0] are the same (note: the naming is confusing, out and in0 seems to be inverted? not sure), as timing from carry_4_test_1 input => carry_4_test_1 output[3:0]. These delays seems to be the same because they are generated by similar circuits (which transforms 1 input in 4 outputs).

On other hand, each output from carry_4_test_0 and carry_4_test_1 are connected to 8x individual primitives OBUF and thus, have 8 individual and different length delays.

But are you sure that carry_4_test_0 and carry_4_test_1 are really primitives? They do not look as primitives, and CARRY4 have different inputs/outputs - specially, CARRY4 should have 4x inputs. You may try to extend the carry_4_test_0 and carry_4_test_1 block and check the circuit inside.