Meeting Timing Constraint

A design is built to work at 50MHz, but the deisgn when tested works only at 48MHz. What should we do to make the design meet specific timing constraint .i.e. to make the design to make it work at 50 MHz? Thanks

Reply to
Roger
Loading thread data ...

Not an un-common problem. Try just set the constraint slightly tighter. Often P&R tools just try to achieve what is requested and if you set it a bit tighter, say for 55 MHz, you will probably get a design that actually works at 50 MHz.

The root of this issue is that the speed files, used by the tools, don't match the silicon exactly. If you are not on the latest version, or service pack, of software it is usually worth getting the latest.

John Adair Enterpo> A design is built to work at 50MHz, but the deisgn when tested works

Reply to
John Adair

Maybe update your P&R (place and route) software ?

Laurent

formatting link

Reply to
Amontec, Larry

Did the P&R meet the constraints? have you run a post-layout simulation? You said "design is built do work at 50 MHz", but if the place & route did pass the constraints it is probably not uptodate (as John and Larry said).

Al

--
Alessandro Basili
CERN, PH/UGC
 Click to see the full signature
Reply to
Al

Roger schrieb:

Read the report of the critical path. You need to understand, where this path is located (not the placement - I mean the logical connection from one flipflop to an other) and why it is so long. Then think about shortening the path. (Maybe you can insert a pipeline step or move some combinational logic block outside this path.)

Ralf

Reply to
Ralf Hildebrandt

Are you sure all signals are covered by timing constraints? Don't forget connections which connect IO cells to internal flipflops. These should be constrained as well.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

You can try one or more of the following -

  1. Over-constrain your clock frequency in the Synthesis tool - Set the clock frequency to 55-60Mhz and then run it through the P&R tool. This sometime results in better timing for the bitstream (I have myself noticed this with Synplify synthesis + Xilinx ISE on a couple of ocassions).

  1. The P&R tool (Xilinx, Altera, or whichever you are using) will always have options to compile for speed, area, etc. Assuming area (or resources) is not a critical concern you can set the compile option for "compile for speed". Some tools also offer multiple synthesis runs with different seeds and then pick the best result for the bitstream.

  2. As someone has already suggested earlier, make sure that you have the latest speed files (technology) files and/or latest P&R software. However, sometimes an older version can give better results, so you can try runs with one or two tool versions.

  1. If nothing works, then, go back to the source - make changes to the RTL and re-code to optimize for timing.

Hope this helps.

Reply to
VC

Have you properly specified the input/output timing constraints? Most of the effort is spent defining internal timing constraints, but the I/O can be messed up--even if it meet the specifications you've given it, if they aren't correct! (The rate may be correct, but the offset may not.)

What is the clock phase uncertainty for the incoming signals? What is the setup/hold time on the device the FPGA sends data to?

Xilinx FPGAs (4k, V2, probably many others) let you adjust the delay (coarsely) on your inputs; you get to select drive strength and fast/slow on the outputs. Are the settings appropriate for your device's environment?

Also, there are the physical board issues: how far from nominal are the voltages? How noise are the voltage and ground planes? Even at 50 MHz, you could create quite a bit of simultaneous switching noise if the chip isn't bypassed correctly, or ....

Also, "doesn't work" can mean many things; you may want to insert some test circuity (Chipscope, or something similar, perhaps) to characterize the failure. If you identify "where" the failure occurs, "why" might not be far behind. And then it is often (but not always) just a quick jog to "fixed."

Jas>

Reply to
jtw

Thanks Mr. Coesel, Mr Adair, Mr. Amontec, Mr. Basili and Mr. Schreib for taking time and responding to my quiry. I am pleasantly surprised that the spirit of parting knowledge is still alive and healthy.

I went back and I constrained the clock to 60Mhz. Used Chipscope, Mapped for Speed rather than area, constrained DCM and finally it turns out that the tool as of now is not supporting what I am trying to do and it will be fixed in a service pack.

I sincerely appreciate your inputs.

Roger.

jtw wrote:

Reply to
Roger

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.