Time Killing Post P&R Simulation

Hi, I have a moderately big design (~250K equivalent ASIC gates) in Vertex FPGA. The post place & route simulation in Modelsim takes hours together for simulating about 2-3 ms of input data. This is a time killing step in my product development lifecycle. Moreover if some timing errors occur (evenafter analyzing P&R static timing) more syn-map-par-sim iterations are required with modified timing constraints or higher effort levels etc. There are some recent developments in EDA tools like Mentor Graphics' VStation which cater to problems like I am facing by "actually" simulating on the target hardware. But they are toooooooooo costly (I don't know what makes EDA tool companies to fix such a high price for their products) Is there any alternate way of simulating my design ?

Regards, Nagaraj

Reply to
Nagaraj
Loading thread data ...

Are you implying that you see timing failures in post-route simulation that static analysis doesn't reveal? Have you reported this to Xilinx?

What's your motivation for doing post-route simulation? Why not just simulate your pre-synthesis code, and use post-route static timing analysis to confirm the timing?

I've been doing FPGA design for years, and can count the number of times I've done post-route simulation on the fingers of one hand. It's something I resort to only if I suspect that the place and route tool has a bug that's producing a faulty design. (I mean, this is something I *always* suspect to one degree or another, but usually I can allay my fears in some less time-consuming a way--looking at the post-map trim list, using the FPGA editor, etc.) And if I think the synthesizer is causing problems, I'll do a post-synthesis simulation.

The value (or lack thereof) of post-route simulation has been debated here before; take a look in the archives.

Bob Perlman Cambrian Design Works

Reply to
Bob Perlman

I agree. If an FPGA design is 100% synchronous, sims functionally, and passes post-route static timing, post-synth/route simulation is rarely indicated.

-- Mike Treseler

Reply to
Mike Treseler

We've started doing post route simulation of a design we are working on, and we are finding that xst is being "surprising". It's been not matching pre-synthesis simulation. We've been finding bugs in the synthesis results. Yikes!

--
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
 Click to see the full signature
Reply to
Stephen Williams

Can you provide any specifics? What sorts of errors are you finding? Is the synthesis not right? Are circuits being "optimized" incorrectly by the P&R software? Timing issues?

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

I find it a useful crutch when you don't understand the way the timing constraints work ... and the details of their syntax is not always clear! but that need is reduced with more experience.

OTOH ... when the design is not 100% synchronous ... I have found errors (** mostly mine! :-) crossing clock domains when I synchronised handshake signals incorrectly. It's a useful tool in the armoury, to pull out when things go wrong, but I agree it shouldn't be in the normal development loop.

Related question: if you have one or two FF's in the entire design dedicated to resolving metastability, you want to turn off their Tsu/Th checks, since their whole point is to encounter setup/hold violations!

How do you do that for these individual FF's while leaving all the other checks in place? (to catch any uncovered domain-crossing signal paths) I resorted to inserting To_01() in the relevant signals in the gate-level netlist by hand, which was untidy, but tolerable for the (mercifully few) passes I needed, but there HAS to be a better way...

** but the FIFO solution from Xilinx app note ???(I forget which) also "failed" post-route sim, coming out of reset. It only brings one reset line out, which is used for both clock domains internally. I modified it to bring out a reset in each clock domain, since I ran the incoming reset through a synchroniser for the rest of my logic anyway.

Call me paranoid? In real life I doubt it matters, but in sim, once "reset" put the counters into an indeterminate state, it never recovered.

- Brian

Reply to
Brian Drummond

related thread:

formatting link

Reliability comes from getting the details right. Writing your own code is one way to do it.

-- Mike Treseler

Reply to
Mike Treseler

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.