optimization of vhdl code

[ashu]

hi
i m facing problem in optimization as my code is taking too much
of logic cells & also opreating freq. is very low 8 to 10 Mhz, can
anybody suggest me some gernal problem & remedies for this, i m using
quartus ...

thanks

ashwani anand

 

[Mike Treseler]

ashu wrote:

i m facing problem in optimization as my code is taking too much
of logic cells & also opreating freq. is very low 8 to 10 Mhz, can
anybody suggest me some gernal problem & remedies for this, i m using
quartus ...

The general solution is to cut out some
features or use a larger, faster device.
Synthesis has already done the obvious
optimizations. Pipelining the code will
increase the Fmax but will likely use
more, not fewer logic cells. Good luck.


-- Mike Treseler

 

[jens]

Sometimes there are optimiziation tricks that might help. A counter is
a prime example of something that can be optimized for both size and
speed, e.g. an LFSR counter is much smaller and faster than a standard
counter. However, standard VHDL notation for a counter can't be used,
you'll need to specify the LFSR counter somehow, such as by using a
component.

Check to see if your tools are inferring building blocks that you're
hoping it will infer, e.g. having the tools infer and use a built-in or
optimized multiplier will be better than having the tools construct one
on its own. Also, if the tools aren't inferring BRAM, you might be
wasting logic gates.

There are many more size and speed optimizations that are possible, but
just writing the code using standard VHDL notation might not work.
Having a good understanding of what those optimizations are and writing
your code so that it forces those optimizations to happen could help
you achieve your size and speed goals.

 

[Thomas Stanka]

Mike Treseler schrieb:

ashu wrote:

i m facing problem in optimization as my code is taking too much
of logic cells & also opreating freq. is very low 8 to 10 Mhz, can
anybody suggest me some gernal problem & remedies for this, i m using
quartus ...

The general solution is to cut out some
features or use a larger, faster device.
Synthesis has already done the obvious
optimizations. Pipelining the code will
increase the Fmax but will likely use
more, not fewer logic cells. Good luck.

Thats why it's time for the not so obvious sollutions *g*.
Start with groups.google, as I already gave a short answer to a similar
question a few days ago.

Most designs have optimisation potential left for both speed and area.
But even your synthesis tool has a few options to optimise your design.
If you need to squeeze out the last of your design, you need to try
different contraints instead of believing that one-hot is always faster
an sequential always smaller.
I had code synthesised with Synopsys dc_shell and got something of 30%
variety between area only by changing constraints without getting
relevant differences in speed.
This won't happen if you synthesise a<=b+c, but with complex (and/or
bad) code.

bye Thomas

 

[Ralf Hildebrandt]

ashu wrote:

i m facing problem in optimization as my code is taking too much
of logic cells & also opreating freq. is very low 8 to 10 Mhz, can
anybody suggest me some gernal problem & remedies for this, i m using
quartus ...

Your synthesis tool will report the critical path. Read this report
carefully and try to understand the path. Once you have discovered the
reason you have to modify the design to make the path shorter (e.g.
using a pipeline).

Ralf

 

[john]

Hi,

do u have any combinational feed back loops in ur design check the
error messages. they do make the device go slower. also check for
failed paths in the deisgn. wat device are u using. usually 20MHz is
not a problem. make ur clock global too. Quartus probably giving u that
error. make it global and ignore the warning.
John
Ralf Hildebrandt wrote:

ashu wrote:


i m facing problem in optimization as my code is taking too much
of logic cells & also opreating freq. is very low 8 to 10 Mhz, can
anybody suggest me some gernal problem & remedies for this, i m using
quartus ...

Your synthesis tool will report the critical path. Read this report
carefully and try to understand the path. Once you have discovered the
reason you have to modify the design to make the path shorter (e.g.
using a pipeline).

Ralf