04-08-2015 03:26 AM
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.
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))
04-08-2015 07:37 AM
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?
04-08-2015 08:28 AM
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.
04-08-2015 11:05 AM
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.
04-10-2015 06:15 AM
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.
04-10-2015 07:02 AM
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.
11-07-2017 07:42 AM - edited 11-07-2017 07:47 AM
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).
10-10-2018 07:19 PM
10-11-2018 02:33 PM
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.
10-15-2018 07:02 PM
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?
10-25-2018 07:08 AM
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?
11-12-2018 02:17 AM
11-08-2019 10:25 AM
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.