[SOLVED] Mismatches in behavioral and post PAR simulations

[punit1053]

Hi
I am finding mismatches in Behavioral and Post PAR simulations. Because of that I am getting different outputs in both of the simulations. Also the Post PAR simulation is not clean. I have attached the behavioral and Post PAR results. The difference in the outputs are marked be the arrows in the images. Please help in fixing this issue and let me know reason behind it.

Best regards
Punit

 

[TrickyDicky]

Looks like some asynchronous logic/glitches thats affecting the design. An easy way to ensure a simulation/hardware missmatch. Is your design fully synchronous and latch free?

Please post the code

 

[punit1053]

Looks like some asynchronous logic/glitches thats affecting the design. An easy way to ensure a simulation/hardware missmatch. Is your design fully synchronous and latch free?

Please post the code

There is no latch generated in the logic, I checked all warnings and the synthesis report. Could you tell me how to make design fully synchronous.

 

[TrickyDicky]

Make sure all signals are registered (ie. everything is clocked). Then this kind of error does not occur.

 

[ads-ee]

It shouldn't, but it really surprises me how someone could think anyone can tell someone how to fix a problem with a design between RTL and post-PAR behavior based on two screen captures of a small number of input and output signals of the design.

You should expend more effort on tracing the signals back through the design starting at the output you have marked. And determining when they started to mismatch, and what signals caused the mismatch, that has always worked for me in the past.

 

[K-J]

Hi
I am finding mismatches in Behavioral and Post PAR simulations. Because of that I am getting different outputs in both of the simulations. Also the Post PAR simulation is not clean. I have attached the behavioral and Post PAR results. The difference in the outputs are marked be the arrows in the images. Please help in fixing this issue and let me know reason behind it.

- You didn't indicate that any static timing analysis was performed. You did perform this step, correct?
- How are your input signals modeled? By that I mean are they meeting the setup and hold time requirements that are output from the static timing analysis from the previous step. Is the clock running at a speed no faster than that reported as Fmax in the timing analysis?

Until timing analysis is successful, your inputs are correctly modeled and the clock is not running faster than Fmax there is no point in even starting a post-route simulation. Unless you are willing to put in this effort, nobody is really going to be able to help you fix anything since you won't have the relevant information needed to diagnose.

Kevin Jennings

 

[ads-ee]

K-J, good point....

I was (probably wrongly) assuming their STA timing report was 100% passing and they had some simulation/synthesis mismatch they are tracking down.

 

[punit1053]

Hi Kevin Jennings,

No, I didn't perform STA. Could you please tell me how to do STA, I haven't done this anytime. Please let me know which documents I should refer.

During PAR simulation I noticed that there was a timing violation in resetting FIFO(Xilinx IP core), that too it appeared in the beginning only and thereafter no timing violation appeared in the console. I have used three clocks in my design (40, 160 & 800HMz). The Fmax for the design was estimated 300.82MHz by ISE XST. Will it be a problem for the design ?...actually only a counter in running at 800MHz that too of 4bits only. I had done PAR simulation for each module of the design and individually there was no timing violations and there was no big difference between the behavioral and post PAR simulations.

 

[TrickyDicky]

You have no chance running a counter at 800 MHz.
for intro to timing analysis. Read this: https://www.xilinx.com/support/docu...xilinx14_4/ise_c_timing_analysis_overview.htm

 

[dpaul]

I have used three clocks in my design (40, 160 & 800HMz). The Fmax for the design was estimated 300.82MHz by ISE XST. Will it be a problem for the design ?...actually only a counter in running at 800MHz that too of 4bits only. I had done PAR simulation for each module of the design and individually there was no timing violations and there was no big difference between the behavioral and post PAR simulations.

You have said it yourself.....Fmax 300.82MHz vs 800MHz, it is not going to work out! There is no point in individually doing PaR if you are going to use all the modules as a single unit. Choose an optimum Fmax, re-synth & PaR and then try out post-layout simulation.

 

[punit1053]

You have no chance running a counter at 800 MHz.
for intro to timing analysis. Read this: https://www.xilinx.com/support/docu...xilinx14_4/ise_c_timing_analysis_overview.htm

Thanks for replying.
I am running counter at 800MHz for calculating fine delay. This is my design's essential requirement. Can you please tell me what should I do to increase my design performance.

- - - Updated - - -

Hi dpaul,

Running counter @ 800MHz is an essential part of my design as it is used to calculate fine delay. If I reduce the clock the accuracy of the output will be compromised. Please tell me what should I do to increase the design performance.

 

[dpaul]

There might be (we don't know your design) long combinatorial paths in your logic for the 40M and 160M clock domains. See if you can optimize something there (you need to go back to RTL here).
Try to reduce the 40M and 160M clocks to a lesser value (if that would suite your spec.). Then instead of using 800M clk, use 300M clk for your counter/whatever. Again I don't know if 300M clk would be sufficient to achieve your desired fine delay.
I have never tried anything like this in any practical scenario, so also look for suggestions from more experienced members.

 

[ads-ee]

As you never stated what device you are using (other than it being Xilinx, i.e. ISE XST). Assuming the fastest speed grade (-3) of Virtex 7 the regional clock buffer (BUFR) maxes out at 600 MHz, the horizontal clock buffers max out at 741 MHz, and the global clock buffers max out at 741 MHz. So the top end device that can use ISE XST doesn't even have the capability to clock at that frequency. And forget about Spartan 6 the frequencies are much lower than that.

Now you might be able to do this in a Virtex Ultrascale part (Vivado) as it's maximum clock frequency for the clock networks is 850 MHz in the 1.0V -3 speed grade part. But expect to pay a huge premium for the parts, they aren't cheep.

If you made the decision to implement this in an FPGA, then you made the wrong decision and didn't do the due diligence necessary to ensure a successful design. I would go the the manager of the project and let them know you screwed up and it can't be done.


Now I could suggest something like using a 200 MHz clock and producing 0, 90, 180, 270 degree phase shifted versions of the clock and using four counters each of them on one of those clock domains, which you then sample the other three counters on each clock domain. You would then have to figure out if that can give you enough information to obtain the resolution you want and how you would use the information. Things like deciding which phase has the correct information may require large amounts of redundant logic running on all four clock domains, until there is some way to determine which clock domain has the "correct" value. Given your abilities (not know you should do STA on a design, not knowing how to write constraints, not knowing what is in the data sheet and DC/AC switching characteristics) I would strongly suggest NOT doing the above, as you will need to fully understand the items mentioned. Even as a highly experienced professional I would be hesitant to commit to doing a design like this as it's likely to bite me in the rear and result in my having to work long nights and weekends trying to fix it when it starts to misbehave right before we start shipping units to customers.