Timing problem in ModelSim, Post-Route Simulation.

Dan,

What kind of speeds are you pushing through your external I/O's and the fabric itself? Depending on the clock period of your external I/O's and the input port delays of your fabric components, it may be a Verilog/ModelSim pulse-swallowing simulation issue. You can, however, set path and transport delays to fine-tune the post-PAR simulation.

I was having a (somewhat) similar problem before, and it turned out that my internal routing was not an issue, but my external I/O's were. In my case, the facade was that fast bit transitions appeared to take about twice as long, and the data was often wrong. This was ultimately traced back to chip's multi-gigabit pins being too fast for ModelSim to handle without special parameters... it was essentially swallowing pulses on MGT pins and missing bit-by-bit transitions on the input. This may or may not be the same issue as yours, but it could have the same solution.

This is a Xilinx page, but it addresses the Verilog/ModelSim issue of pulse swallowing on fast transitions:

Julian Kain

Thanks for your explanations.

The clock is not that high, 60 MHz is the maximum frequency. Moreover, the problems come out for internal signals, slice to slice propagation time.

I really don't understand how ModelSim estimate the propagation time...

I know that backannotation usually provides worst-case timing into the simulation but why I cannot find the same propagations times on the .SDF file?

Maybe the .SDF file is not the only input that ModelSim use for timing estimation?

Dan.

-- Mike Treseler

Dan,

I don't think the .TWR example is complete since I'd expect to see some additional delay like clock-to-Q of the first synchronous element in the list. But in general I'd expect to see ROUTE delays of the TRACE report that match the INTERCONNECT delays of the SDF.

I wonder if the SDF file is simply out of synch with the TRACE report? Or maybe you're overriding the speed grade with TRACE? See Tools >

TRACE Options... in the Project Navigator. Also check the SDF setup in ModelSim. See Simulate > Start Simulation... and the SDF tab where you can specify the Min|Typ|Max delay to be applied.

Troy Scott Lattice Semiconductor TME

Hello,

Indeed, the route delays of the Trace report matches the interconnect delays of the SDF. That is OK.

I will investigate this Multi-Source Delay options on the SDF tab. Thanks for all the suggestions.

Dan.

If you have no multcycle path or false path constraints, then yes, STA plus RTL simulation are all you need.

But... If you have any multicylce or false path constraints, you either need a tool that will verify their validity, or you must run sim with full timing to verify them. Otherwise, what you thought was a multicycle or false path may not really be so (or more commonly: not properly specified), but the RTL sim and STA would indicate all was well. Note that the full timing sim can be reduced to cover only sections that have such constraints.

Andy

Yes. I pipeline multicycles and cover synchronization without false path constraints.

A full timing sim is a good release check-off item, but I keep it out of the detailed design loop.

-- Mike Treseler

Mike,

I'm pretty sure you understand this, but others may not:

The problem is not in having multicycle or false paths in a design; it is in having constraints that relax timing requirements on those paths that is the problem. If the entire design p&r's and meets STA without any of the above constraints, great, problem solved. But if it does not, and you include the constraints, then there is a problem in that the constraints may relax timing on paths that really are not multicycle (or false), and then only a full timing sim will reveal it (and then only if that particular path is exercised by the sim!). In fact even if you don't include constraints to pass static timing, but just review the violations and rationalize them as false/multicycle paths, you really have the same problem in verifying the rationalizations.

There are some cases where including multicycle and false path constraints prior to synthesis can resolve timing issues elsewhere in the design, by not consuming critical resources where they are not needed, thus reserving them for truely critical paths. Whatever the reason/result of including these constraints, they must be verfied just like the RTL code, but the only way to do it (without a custom formal analysis tool) is with full timing sim, excersizing the paths so constrained.

Your point about detailed design loop vs release check-off is a good one. I assumed we were talking about check-off, since I never run full timing until then anyway.

Andy

I agree with your posting. My preference is to constrain only Fmax and to meet STA by design only. You are correct that this can consume some resources, but it also saves time and reduces stress.

-- Mike Treseler