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

[Student]

Hi, there:

My clock is 40MHz, but I have complicated FFT operations and other DSP
stuff.
The longest path is 25.8ns, though after I set the constraints at
23ns...Previously it
was 27.5ns at constraints of 25ns...

What may I do now? How far can over constraining go? The source codes are
from
other people so I can't change a lot of it.

Besides -opt_mode Speed in XST, what else controls can I use in ISE6.1?

Does Synplify optimize for speed? How does it compare with XST?

Kelvin

 

[ALuPin]

"Student" <student@nowhere.com> wrote in message news:<40b2f02e@news.starhub.net.sg>...

Hi, there:

My clock is 40MHz, but I have complicated FFT operations and other DSP
stuff.
The longest path is 25.8ns, though after I set the constraints at
23ns...Previously it
was 27.5ns at constraints of 25ns...

What may I do now? How far can over constraining go? The source codes are
from
other people so I can't change a lot of it.

Besides -opt_mode Speed in XST, what else controls can I use in ISE6.1?

Does Synplify optimize for speed? How does it compare with XST?

Kelvin

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

 

[Jon Beniston]

My clock is 40MHz, but I have complicated FFT operations and other DSP
stuff.
The longest path is 25.8ns, though after I set the constraints at
23ns...Previously it
was 27.5ns at constraints of 25ns...

What may I do now? How far can over constraining go?

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

The source codes are
from
other people so I can't change a lot of it.

Besides -opt_mode Speed in XST, what else controls can I use in ISE6.1?

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.

Does Synplify optimize for speed?

Yes.

How does it compare with XST?

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

 

[Shalin Sheth]

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

For more ideas check out this Tech Tip from Xilinx:
http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=&sSecondaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=rw_tim_closure

Shalin-

Jon Beniston wrote:

My clock is 40MHz, but I have complicated FFT operations and other DSP
stuff.
The longest path is 25.8ns, though after I set the constraints at
23ns...Previously it
was 27.5ns at constraints of 25ns...

What may I do now? How far can over constraining go?


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


The source codes are
from
other people so I can't change a lot of it.

Besides -opt_mode Speed in XST, what else controls can I use in ISE6.1?


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.


Does Synplify optimize for speed?


Yes.


How does it compare with XST?


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

 

[Symon]

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.

 

[Peter Alfke]

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
======================

Shalin Sheth wrote:

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

For more ideas check out this Tech Tip from Xilinx:
http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=&sSecondaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=rw_tim_closure

Shalin-

Jon Beniston wrote:
My clock is 40MHz, but I have complicated FFT operations and other DSP
stuff.
The longest path is 25.8ns, though after I set the constraints at
23ns...Previously it
was 27.5ns at constraints of 25ns...

What may I do now? How far can over constraining go?


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


The source codes are
from
other people so I can't change a lot of it.

Besides -opt_mode Speed in XST, what else controls can I use in ISE6.1?


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.


Does Synplify optimize for speed?


Yes.


How does it compare with XST?


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

 

[Student]

Thanks for your advice.

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

Kelvin






"Peter Alfke" <peter@xilinx.com> wrote in message
news:40B3870C.FE839F7E@xilinx.com...

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
======================

Shalin Sheth wrote:

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

For more ideas check out this Tech Tip from Xilinx:

http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=&sSecondaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=rw_tim_closure

Shalin-

Jon Beniston wrote:
My clock is 40MHz, but I have complicated FFT operations and other DSP
stuff.
The longest path is 25.8ns, though after I set the constraints at
23ns...Previously it
was 27.5ns at constraints of 25ns...

What may I do now? How far can over constraining go?


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


The source codes are
from
other people so I can't change a lot of it.

Besides -opt_mode Speed in XST, what else controls can I use in
ISE6.1?


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.


Does Synplify optimize for speed?


Yes.


How does it compare with XST?


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

 

[Student]

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




"ALuPin" <ALuPin@web.de> wrote in message
news:b8a9a7b0.0405250502.385b73b0@posting.google.com...

"Student" <student@nowhere.com> wrote in message
news:<40b2f02e@news.starhub.net.sg>...
Hi, there:

My clock is 40MHz, but I have complicated FFT operations and other DSP
stuff.
The longest path is 25.8ns, though after I set the constraints at
23ns...Previously it
was 27.5ns at constraints of 25ns...

What may I do now? How far can over constraining go? The source codes
are
from
other people so I can't change a lot of it.

Besides -opt_mode Speed in XST, what else controls can I use in ISE6.1?

Does Synplify optimize for speed? How does it compare with XST?

Kelvin

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

 

[RobertP]

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

--
RobertP.

 

[General Schvantzkoph]

On Tue, 25 May 2004 15:12:45 +0800, Student wrote:

Hi, there:

My clock is 40MHz, but I have complicated FFT operations and other DSP
stuff.
The longest path is 25.8ns, though after I set the constraints at
23ns...Previously it
was 27.5ns at constraints of 25ns...

What may I do now? How far can over constraining go? The source codes are
from
other people so I can't change a lot of it.

Besides -opt_mode Speed in XST, what else controls can I use in ISE6.1?

Does Synplify optimize for speed? How does it compare with XST?

Kelvin

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.

 

[Peter Alfke]

If the simulation says that you are within a few percent of desired
performance, then I am sure that it will run under "normal" condition.
Simulation parameters assume worst-case temperature (hot), voltage (low)
and processing (slow). It is very unlikely that all this comes together
in one particular board.
For production, you should absolutely always obey the simulation
results, but in the lab you can "cheat".
Peter Alfke

Student wrote:

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

"ALuPin" <ALuPin@web.de> wrote in message
news:b8a9a7b0.0405250502.385b73b0@posting.google.com...
"Student" <student@nowhere.com> wrote in message
news:<40b2f02e@news.starhub.net.sg>...
Hi, there:

My clock is 40MHz, but I have complicated FFT operations and other DSP
stuff.
The longest path is 25.8ns, though after I set the constraints at
23ns...Previously it
was 27.5ns at constraints of 25ns...

What may I do now? How far can over constraining go? The source codes
are
from
other people so I can't change a lot of it.

Besides -opt_mode Speed in XST, what else controls can I use in ISE6.1?

Does Synplify optimize for speed? How does it compare with XST?

Kelvin

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

 

[Jim Granville]

Peter Alfke wrote:

If the simulation says that you are within a few percent of desired
performance, then I am sure that it will run under "normal" condition.
Simulation parameters assume worst-case temperature (hot), voltage (low)
and processing (slow). It is very unlikely that all this comes together
in one particular board.
For production, you should absolutely always obey the simulation
results, but in the lab you can "cheat".

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.

Student wrote:
Thanks.

The frequency is fixed and RTL is documented to operate at 40MHz.

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

 

[Kelvin]

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





"Matthew E Rosenthal" <mer2@andrew.cmu.edu> wrote in message
newsine.GSO.4.58-035.0405262118560.3574@unix3.andrew.cmu.edu...

When you say the design is set to run at 40 Mhz, does that mean 40 Mhz on
a specific xilinx fpga or on some generic fab process or what?

On Thu, 27 May 2004, Jim Granville wrote:

Peter Alfke wrote:
If the simulation says that you are within a few percent of desired
performance, then I am sure that it will run under "normal" condition.
Simulation parameters assume worst-case temperature (hot), voltage
(low)
and processing (slow). It is very unlikely that all this comes
together
in one particular board.
For production, you should absolutely always obey the simulation
results, but in the lab you can "cheat".

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.

Student wrote:
Thanks.

The frequency is fixed and RTL is documented to operate at 40MHz.

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

 

[Hal Murray]

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.

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.

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

 

[Matthew E Rosenthal]

When you say the design is set to run at 40 Mhz, does that mean 40 Mhz on
a specific xilinx fpga or on some generic fab process or what?

On Thu, 27 May 2004, Jim Granville wrote:

Peter Alfke wrote:
If the simulation says that you are within a few percent of desired
performance, then I am sure that it will run under "normal" condition.
Simulation parameters assume worst-case temperature (hot), voltage (low)
and processing (slow). It is very unlikely that all this comes together
in one particular board.
For production, you should absolutely always obey the simulation
results, but in the lab you can "cheat".

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.

Student wrote:
Thanks.

The frequency is fixed and RTL is documented to operate at 40MHz.

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

 

[Petter Gustad]

General Schvantzkoph <schvantzkoph@yahoo.com> writes:

Synplify usually does a 10% better job then any other synthesis tool

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:

http://www.deepchip.com/items/0427-01.html

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

http://www.deepchip.com/items/0427-02.html

Petter // Synopsys DC-FPGA user
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[Jon Elson]

Kelvin wrote:

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...



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

 

[Kelvin]

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




"Jon Elson" <jmelson@artsci.wustl.edu> wrote in message
news:40B65FC2.3040900@artsci.wustl.edu...

Kelvin wrote:

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...



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