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
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
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).
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.)
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).
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.
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.
If nothing works, then, go back to the source - make changes to the RTL and re-code to optimize for timing.
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."
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.