cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Anonymous
Not applicable
8,470 Views

Carry4 delay chain post routing simulation problem

Hello,

 

I'm using Vivado 2014.4, and I'm trying to implement a delay using a chain of carry4 modules, on a Zynq7000. After doing some reading, I expected to see the carry outputs changing out of order, but that's not what I'm getting at all: all 4 outputs change at the same time, as shown below.

 

Simulation

 

I'm simulating with a resolution of 1fs. Between carry4 blocks there are 114 fs, even when I forced some of them to be placed in distant slices, which makes me think something is not working with the simulations. I'm also attaching the verilog module.

 

Thank you for your help.

 

((I had to change the extension of the file because it wouldn't be posted otherwise))

 

 

 

0 Kudos
12 Replies
Highlighted
Professor
Professor
8,455 Views
Registered: ‎08-14-2007

The carry4 doesn't work like a typical daisy-chained carry path that you found in earlier FPGA families.  The individual bits within the 4 don't necessarily change in order from LSB to MSB.  In fact the simulation model is probably closer to the correct behavior.  If you need timing resolution smaller than the delay of a full 4-bit carry, you might need to look at another approach.  In any case routing delays will probably make any use of the carry chain as a delay element very difficult.  You said that moving the location of the second chain element did not affect the timing.  Are you doing a post-route timing simulation?

-- Gabor
0 Kudos
Highlighted
Anonymous
Not applicable
8,449 Views

Hello,

Yes, I'm doing a post-route timing simulation: the fact that there was no timing difference in my tests while forcing the carry4 to be placed in different (and non vertically aligned) slices is what made me suspect of the simulation and not my design.

As said, I was expecting the bits to not change from LSB to MSB, but the problem I present is that all 4 carry outputs change at the same time (with a resolution of under 1 fs), which is strange if we take into account the documentation, which shows the carry line propagating through the MUX.

 

Is it possible that the sdf file containing the delays for the carry4 primitive in this architecture isn't included or corrupted/whatever?

 

Below I include the simulation of the same modules but using ISE and a Spartan6, which shows the expected results.

 

simulation_ise.png

0 Kudos
Highlighted
Professor
Professor
8,439 Views
Registered: ‎08-14-2007

If you have ISE 14.7 you could try the code using Zynq instead of Spartan6 to see if this is a general problem with the Zynq (or 7-series) carry4 simulation model, or just in Vivado.

 

Other than that, the fact that the routing delay didn't show up when you moved one carry4 away from the other suggests that either you are not getting an annotated design in Vivado simulation, or that the placer did not respect your LOC on the second carry4 and placed it in the same column anyway.  You could check this by opening the implemented design to see where each carry4 ended up.

-- Gabor
0 Kudos
Highlighted
Anonymous
Not applicable
8,417 Views

Hello,

 

Indeed, I don't know why but I had the idea 7th family FPGA were not supported by ISE. I tried it and it indeed works as expected there... At least I can keep working.

 

As for Vivado, there's also another error on my side: instead of moving one of the carry4 instantiated by the delay chain I moved another used by another module. Carry4 can't be broken at all: the carry lines connect the slices vertically, so it's normal that between carry4 there's always the same delay, although I still don't believe it's true (it's a propagation delay of 0.1 ps, and it isn't the same delay ISE simulations give).

 

Now what remains to be explained is why all 4 carry bits change at the same time... I tried to search for sdf's which contained the delays for the carry4 primitives, but didn't find anything.

0 Kudos
Highlighted
Professor
Professor
8,412 Views
Registered: ‎08-14-2007

It really sounds like Vivado isn't using a timing model for CARRY4.  0.1 ps is the sort of delay often thrown into behavioral models to make sure that events happen in a given order.  You might want to contact your FAE to see if you can open a case for this issue.

-- Gabor
0 Kudos
Highlighted
Observer
Observer
3,474 Views
Registered: ‎10-08-2012

I would like to refresh the topic as I encounter the same problem.

 

I've implemented simple time-to-digital converter based on carry chain elements inside Kintex-7 device, tried to simulate it in Vivado ISim simulator (Post-Implementation Timing Simulation) and achieved same result as my predecessor. 

So, I did it one more time in ISE Isim (Post Place & Route Simulation) and results are correct!

 

I've checked timing report and observed that THERE ARE some differences in time of signal arrival to succesive flip-flops (so on the outputs of carry chain)! Therefore, I assume that timing model of carry4 element is properly connected to the simulator. So what is the issue?

 

I attach printscreens from Vivado and ISE and Timing Report generated by Vivado. Signal d_buf connects carry chain output to flip-flops. 

 

And whats more, in ISE ISim I can get to each single primitive implemented in my design (by expanding UUT) and check signals on their pins. In Vivado ISim it is not possible (see printscreens).

ISE ISim.png
Vivado ISim.png
0 Kudos
Highlighted
Participant
Participant
2,473 Views
Registered: ‎07-08-2018

Like you said, if i want the right simulation, can't use VIVADO. Right?I want to know if you have finished the project, because I also encountered the same problem as you, and got the same simulation diagram
0 Kudos
Highlighted
Observer
Observer
2,448 Views
Registered: ‎10-08-2012

Finally I did the simulation in ISE and final project in Vivado :). Taking TDC into consideration the ISim simulator shows the problem of carry output changing out of order. However, to get real flip-flops order in carry chain based TDC you should rather consider doing  calibration (e.g. statistical code density test) in your particular design (core voltage, temperature). I do not know how about simulating other elements in Vivado.

0 Kudos
Highlighted
Participant
Participant
2,366 Views
Registered: ‎07-08-2018

You put two pictures up before, you said that the simulation result of the first one was correct, but the result of the first one was not a change in order, why did you say that it was correct?ISE ISim (1).png

 

0 Kudos
Highlighted
Visitor
Visitor
2,177 Views
Registered: ‎10-24-2018

I too am having this same trouble with Vivado 2018.2.2.  I also see that the post implementation timing simulation must not be using sdf annotation since everything looks perfectly synchronized.  I wonder if this is a systemic issue or if it is limited to certain designs.  If post implementation timing simulation does not work with Vivado 2018 I figure it would be in the known issues list.  Several posts so far show that ISE is the only way to go.  I saw that you had to use ISE as well.  Did you ever go back to Vivado or see that there is a work around?

0 Kudos
Highlighted
Visitor
Visitor
2,129 Views
Registered: ‎10-11-2018

Just to refresh on the issue: in the end, for test purposes, I used a functional model to validate the design, since Vivado doesn't properly simulate the carry4 delays.

As suggested before, the best option is to use a density test with the final implementation.
0 Kudos
Highlighted
Visitor
Visitor
913 Views
Registered: ‎06-25-2019

I'm not sure if this is an expected result. As per the carry4 schematic, i think that you should be getting a step type of an output.

Here some signals are reaching before inside a carry4 primitive.

Please clarify. Even i'm getting the same results. Not sure if it is correct.

0 Kudos