What can I do if my chip can't meet timing?

Hi Kelvin,

if the source codes are from other people and you cannot change it you should assume that is has been optimized for 40MHz, isn't it? ;o)

You have to clarify for which clock frequency the original design has been developed.

So basically the best possibility is to think about pipelining your design. By doing so you will not have to worry about constraining.

Rgds

Keep going until the results don't get any better.

I think there is -opt_level (or something) that makes it work harder.

Also, you can set the P&R optimisation level.

Note: Estimated frequency after synthesis is not necessarily what you will get after P&R.

Yes.

I have found it to be better. The extra performance is often very heavily design dependant. More often than not, for me, it performs much better with large designs.

Cheers, JonB

You may want to try to run map with the '-timing' option.

For more ideas check out this Tech Tip from Xilinx:

Shal>>My clock is 40MHz, but I have complicated FFT operations and other DSP

Hi, As you're pretty close to meeting the timing, your best bet may be to read up about the Floorplanner. You just(!) need to place your critical logic. Also, you may be able to persuade Synplify to work better, this has worked for me in the past, especially if the design is pipelined. Be careful with over-contraining, it can often make things worse. Read the CAF archive to find out why. Mr. Andraka gripes about this a fair bit! ;-) Other less practicable alternatives include freezing, using a faster speedgrade, and turning up the supply voltage a bit! The Xilinx tools let you specify the temperature and supply voltage, check out Speedprint. HTH, Syms.

Here are some hardware ideas to boost performance a few percent: Buy a higher speed-grade part (usually improves performance by 15% per speed grade) Kep the internal supply voltage at or slightly above nominal. That gives you another 5%. Somehow keep the chip from getting hot...

Peter Alfke ======================

Shal>

Thanks for your advice.

I have no control over chip and board... The speed is 40MHz and it is fixed too.

Kelvin

ISE6.1?

Thanks.

The frequency is fixed and RTL is documented to operate at 40MHz. I will tamper with the tools for a while instead of havocing with the codes. Codes change will be my last resort...

Kelvin

are

design.

You can try multi-pass place and route as well.

Synplify usually does a 10% better job then any other synthesis tool so it might fix your problem. You could also try ISE6.2sp2. XST is an immature tool so three are significant improvements with each release at this stage. The final thing to try is floorplanning.

You can also test for actual margin in the lab, by control of two of those corners (Temp,Voltage), and if you can vary the clock, you can get close to the third.

You might want to get a full copy of 'documented to operate at 40MHz' for details of the tool chains, and test interfaces, as well as timing results.

-jg

The original author tested the RTL on a Virtex2...Now I am still V2 but I need to split the chip into RX & TX and compile them in partial reconfigurable mode...In full V2 chip compilation, it satisfied timing at 24.5ns...in partial compilation, timing is 25~26ns...

I am aware partial reconfigurable compilation introduces long wire delays...Since the interface signals between RX/TX are registered, so I don't have effictive control over the offset delays...

TX/RX(with FFT) shares FFT & trigonormetric functions, which contain critical paths...

Kelvin

(low)

together

Only if you have an environment setup in your lab that generates test cases for all of paths through your design.

It's generally easy to get most of them. But that doesn't mean your whole design will run at that frequency.

Synplify is an excellent synthesis tool, but have you benchmarked against all available synthesis tools, including DC-FPGA?

It's been I while since I used Synplify, but it appears that some users are less than happy with the later developments of the product:

Other users (including myself) are very excited about DC-FPGA:

Petter // Synopsys DC-FPGA user

I think this is the key, here. If you have the space, you may need to duplicate these shared functions, giving place/route the freedom to put these resources close to where they are needed, rather than having one or the other sections (RX or TX) having to reach all the way across the chip to get to them.

If you don't have the space to duplicate these functions, then you have a big problem. If there's a faster speed grade of the chip, that might help.

Jon

unfortunately I have no space to duplicate the shared modules that is why I am a little worried now.

I think I still have a few variables to play with, for example the Synplicity, floorplanning, yeah thanks, speed grade etc.

Best Regards, Kelvin

sections