Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

timing simulations during FPGA design flow

Status
Not open for further replies.

delay

Full Member level 4
Joined
Jun 11, 2004
Messages
206
Helped
6
Reputation
12
Reaction score
3
Trophy points
1,298
Location
Van Allen Belt
Activity points
2,221
My understanding is that timing simulations should be done at the following levels for an FPGA design process.

Post Synthesis (behavioral)
Post Translation
Post Mapping
Post Place and Route

Is this sequence correct? Also, where does the gate level simulation fit in this picture?

delay (delayed by technology)
 

I personally do the timing simulation after P&R.
 

I usually do two simulations one on the RTL level and the other post PAR this saves time
 

after PAR, if all the timing constraints are met, is it necessary to do timing simulation ?
 

Engineers generally run the timing simulations after P&R.
Use assertions in test benches to determine whether the timing parameters (like setup time, hold time, protocol paramets (if any!) etc. ) are met or not.
 

hi saikat
thanks for the reply.
After PAR, through STA we will be able to know whether all the timing parameters (like setup, hold time etc) are met or not.
Then what additional information do we get by running timing simulations after PAR?

Thanks
 

usually the PAR have all the assertions yet if you are interacting with external components extra delay time is introduced to the system one that can't be measured and have to be introduced through models of your external components and delays in your PCB.
I just want to note that usually the PAR results are inaccurate regarding timing it is usually within +10% or -10% (I haven't seen the -10% alot)

If you found that your PAR works fine but the real design doesn't work fine most likely this is because of some violation (10 percentage error) in your critical path, I have to note that this isn't a trivial problem to solve (usually you have more than one path that can have this problem), on the other hand if you get a relaxed time then usually your code is more likely to succeed with no error on real implementation, as a first step I recommend that you contraint the design with over 120% your actual clock speed if it passes well then it is more likely to succeed on implementation, but if your time constraints are tight and you just met it with your Post PAR then your design is most likely to fail in real implementation chipscope might help but it is time consuming (I find it a very useful tool if you had a very tight constraints) RPM also might help but it is hard to implement.
Good luck
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top