timing simulations during FPGA design flow

EDAboard.com Forum Index -> PLD, SPLD, GAL, CPLD, FPGA Design -> timing simulations during FPGA design flow

Author

Message

delay

Joined: 11 Jun 2004
Posts: 219
Helped: 3
Location: Van Allen Belt

23 Jun 2004 9:31 timing simulations during FPGA design flow

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)

Google
AdSense
Google Adsense

23 Jun 2004 9:31 Ads

Ohh

Joined: 31 May 2001
Posts: 51

23 Jun 2004 10:39 Re: timing simulations during FPGA design flow

I personally do the timing simulation after P&R.

bibo1978

Joined: 01 May 2004
Posts: 229
Helped: 6

23 Jun 2004 14:28 Re: timing simulations during FPGA design flow

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

dkk1980

Joined: 17 Sep 2007
Posts: 4

18 Jul 2008 5:37 Re: timing simulations during FPGA design flow

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

saikat

Joined: 21 Oct 2005
Posts: 47
Helped: 4
Location: mumbai

18 Jul 2008 13:36 Re: timing simulations during FPGA design flow

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.

dkk1980

Joined: 17 Sep 2007
Posts: 4

18 Jul 2008 20:30 Re: timing simulations during FPGA design flow

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

bibo1978

Joined: 01 May 2004
Posts: 229
Helped: 6

20 Jul 2008 14:04 Re: timing simulations during FPGA design flow

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