ModelSim Timing Strategy

Hello Group,

Thank you all for the help with my last question.

I have another issue with the Behaviour vs. PAR models as it relates to FIFOs. I find that in the behavior model the read cycle looks as if it takes two clock cycles to get new data and in the PAR model the data comes more readily, around 11ns, about half a cycle.

I suspect that the Behavior model might be two cycles delay since the Read_Enable sets up on a rising edge of a clock. However the read cycle does not initiate until one cycle later, when the Read_Enable is high, albeit going low. And then there is one more clock delay in the read output.

If I were modeling this on the top level I would delay my clock a tad, so the read enable was already set up, and then the output would come one cycle later, not two. Unfortunetely, this is an instantiated component in a lower level, wherein the read enable is generated by the same clock that runs the FIFO. I guess this is the problem of infinitely fine timing units called deltas?

It would be an ugly and time consuming process to run everything through the PAR and post sim. I suppose I could run a separate clock, down the hierarchy to run just the FIFO, for simulation purposes. But I am hoping that this group knows a better solution.

Thanks,

Brad Smallridge b r a d @ a i v i s i o n . c o m

Reply to
Brad Smallridge
Loading thread data ...

If the design is synchronous, and the design is fully constrained from a timing perspective, it is my expectation and experience that the RTL (behavior) simulations will match the post place and route back-annotated simulations on a clock cycle to cycle basis. If they do not, then either the stimulus from the testbench does not consistently meet the set-up and hold times for the two representations of the design, or the design is not being synthesized/implemented as desired and you have to go in and figure out why. Figuring out why an RTL simulation does not match a fully implemented back-annotated simulation is not a happy place to be and I think it is wise to develop a style where you minimize the amount of time one spends in the unhappy place. It is important to not ignore that unhappy place, because a more unhappy place is having to probe hardware with a scope to figure out why a design is not working as expected, and explain to others why the hardware is not working yet.

-- just my 2 cents

Newman

Reply to
newman5382

From an Xilinx Engineer:

Sorry to hear that you are still having issues with the fifo behavioral model. We have seen cases of this type of behavior where testbenches create a clock by forcing the transitions, rather than actually creating a clocked process. Example:

clk

Reply to
Brad Smallridge

Thanks Newman,

I think you are right. My problem is how I interpret the waveforms not with the FIFO simulations themselves. There is something else wrong with my design, but I now have both the behaviour and the PAR sims working the same way.

Brad

Reply to
Brad Smallridge

Well good for you Brad. Sometimes the simulations can be tricky. In my testbenches, I typically generate a testbench clock

tb_clk

Reply to
newman5382

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.