carry4 primitive simulation inconsistency

[sawaak]

Hi all,

I am trying to simulate a delay line created using carry4 primitives. I am running post-synthesis timing simulation using Vivado 2021.1 and Artix-7 device. The carry4 primitive includes 4 carry logics and should have a delay associated with each of them. The problem is I am unable to observe those delays in the post-synthesis timing simulation - all carry logics associated with a particular carry4 primitive appear to have changed at the same time. I can see variable delays at the output port when I route the output to output pins which I don't want obviously when creating a TDC.

By definition, I should see the variable delays at the output of carry4 primitives (cwire[7:0] net in attached figure). Any one knows how to achieve this?

Thank you.

 

[dpaul]

@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.

 

[sawaak]

Thank you for your comment dpaul.

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

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

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.

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


Thank you,
sawaak

 

[dpaul]

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

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.

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!

 

[FvM]

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.

 

[dpaul]

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

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.

 

[sawaak]

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

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

--- Updated Aug 4, 2022 ---

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

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.

--- Updated Aug 4, 2022 ---

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.

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

--- Updated Aug 4, 2022 ---

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

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.

 

[pbernardi]

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.