will Synopsys Design Compiler automatically collect common s

W

walala

Guest
Dear all,

I have the following code fragment and I want to ask will Synopsys Design
Compiler be able to automatically collect common sub expression to do
intelligent optimization? For example, "ZZ(0)(index2)+ZZ(4)(index2)" is in
fact a common expression wich appear here and there...

Can Synpopsys DC do that? The reason that I want to leave to DC to do that
is that I don't want to compromise structure and readablity...

I can do common sub-expression collection myself... but then the expression
loses its original form and meaning...

Thanks a lot,

-Walala

t15:= (ZZ(0)(index2)-ZZ(2)(index2)+ZZ(4)(index2)) *(2**7)
- (ZZ(6)(index2)) *(2**6)
- (ZZ(0)(index2)+ZZ(4)(index2)) *(2**5)
+ (ZZ(6)(index2)) *(2**4)
+ (ZZ(2)(index2)) *(2**3)
- (ZZ(0)(index2)+ZZ(4)(index2)) *(2**2)
+ (ZZ(2)(index2)) *(2**1)
- (ZZ(0)(index2)+ZZ(4)(index2)+ZZ(6)(index2));
 
Walala,
It is uncommon for a synthesis tool to do this.
Synopsys may or may not have it by now. If you are not
making area or timing, I would definitely recommend
coding it yourself.

You can do an experiment and see what it does do.
Before your experiment, do a baseline to establish
how big one adder is. Then it is simple algebra to
figure out how many adders are in the result and
if it actually did the factoring.

Cheers,
Jim Lewis
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


walala wrote:

Dear all,

I have the following code fragment and I want to ask will Synopsys Design
Compiler be able to automatically collect common sub expression to do
intelligent optimization? For example, "ZZ(0)(index2)+ZZ(4)(index2)" is in
fact a common expression wich appear here and there...

Can Synpopsys DC do that? The reason that I want to leave to DC to do that
is that I don't want to compromise structure and readablity...

I can do common sub-expression collection myself... but then the expression
loses its original form and meaning...

Thanks a lot,

-Walala

t15:= (ZZ(0)(index2)-ZZ(2)(index2)+ZZ(4)(index2)) *(2**7)
- (ZZ(6)(index2)) *(2**6)
- (ZZ(0)(index2)+ZZ(4)(index2)) *(2**5)
+ (ZZ(6)(index2)) *(2**4)
+ (ZZ(2)(index2)) *(2**3)
- (ZZ(0)(index2)+ZZ(4)(index2)) *(2**2)
+ (ZZ(2)(index2)) *(2**1)
- (ZZ(0)(index2)+ZZ(4)(index2)+ZZ(6)(index2));
Click to expand...
 
"walala" <mizhael@yahoo.com> writes:
Can Synpopsys DC do that? The reason that I want to leave to DC to do that
is that I don't want to compromise structure and readablity...
Click to expand...
Give it a try. Don't bother optimizing stuff where not
necessary. Synopsys DC supports resource sharing since at least
version 1999.10, which happens to be the oldest version I have access
to.

I think resource sharing is one of the easier tasks of the Synthesis
process.

Let the tools do what you paid for! If you design doesn't meet timing
or area constraints, you can still change the code.

I can do common sub-expression collection myself... but then the expression
loses its original form and meaning...
Click to expand...
Yes. You certainly don't want that. Think of this scenario: 1. You
spent time and effort to break up the structure and "optimize" it,
making the code unreadable as a result. 2. You figure that your
equation contains a typo which happens to change the structure. 3. Go
back to 1.

The "old-fart" syndrome, which is very common among hardware
designers, is extremely annoying. Don't let people tell you that
synthesis tools are completely dumb and you should rather code every
gate by hand. Too bad that VHDL doesn't support transistor-level
descriptions. Remember, when these designers were young (typically
about the same time you were still in diapers and often enough "last
time they checked"), few synthesis tools did not crash when reading
the most trivial HDL code. And if the tools managed to write out a
complete netlist, it was never of the same quality as a good old
hand-drawn one.

Code using a high level of abstraction (but of course not without
thinking about the resulting hardware :^), focus on code quality and
let the tool figure out what to do with that stuff. Step down a level
*iff* the tool fails to meet your constraints. Works for me. So far I
have never had to step down a level.

Best regards,
Marcus
 
Marcus Harnisch wrote:

Code using a high level of abstraction (but of course not without
thinking about the resulting hardware :^), focus on code quality and
let the tool figure out what to do with that stuff. Step down a level
*iff* the tool fails to meet your constraints. Works for me. So far I
have never had to step down a level.
Click to expand...
Nor I.

Well said.

-- Mike Treseler
 
Dear Marcus,

Thank you for your comment. But how to instruct Synopsys DC to have a try?

Do I just use "compile area_effort high" to let it pay more attention to
resource sharing?

Thanks a lot,

-Walala

"Marcus Harnisch" <marcus_harnisch@mint-tech.com> wrote in message
news:h2yy8wp26k7.fsf@mint-tech.com...
"walala" <mizhael@yahoo.com> writes:
Can Synpopsys DC do that? The reason that I want to leave to DC to do
that
is that I don't want to compromise structure and readablity...

Give it a try. Don't bother optimizing stuff where not
necessary. Synopsys DC supports resource sharing since at least
version 1999.10, which happens to be the oldest version I have access
to.

I think resource sharing is one of the easier tasks of the Synthesis
process.

Let the tools do what you paid for! If you design doesn't meet timing
or area constraints, you can still change the code.

I can do common sub-expression collection myself... but then the
expression
loses its original form and meaning...

Yes. You certainly don't want that. Think of this scenario: 1. You
spent time and effort to break up the structure and "optimize" it,
making the code unreadable as a result. 2. You figure that your
equation contains a typo which happens to change the structure. 3. Go
back to 1.

The "old-fart" syndrome, which is very common among hardware
designers, is extremely annoying. Don't let people tell you that
synthesis tools are completely dumb and you should rather code every
gate by hand. Too bad that VHDL doesn't support transistor-level
descriptions. Remember, when these designers were young (typically
about the same time you were still in diapers and often enough "last
time they checked"), few synthesis tools did not crash when reading
the most trivial HDL code. And if the tools managed to write out a
complete netlist, it was never of the same quality as a good old
hand-drawn one.

Code using a high level of abstraction (but of course not without
thinking about the resulting hardware :^), focus on code quality and
let the tool figure out what to do with that stuff. Step down a level
*iff* the tool fails to meet your constraints. Works for me. So far I
have never had to step down a level.

Best regards,
Marcus
Click to expand...
 
"walala" <mizhael@yahoo.com> writes:
Do I just use "compile area_effort high" to let it pay more
attention to resource sharing?
Click to expand...
You have to understand how synthesis tools generally work. They keep
optimizing the design according to the constraints you set until it is
"good enough". A synthesis tool doesn't normally have a switch to
force all possible components to be reused or not. If the netlist
matches your constraints, stop. There isn't a switch (that I know of),
saying "make it as fast/small as possible". The only way to sort of
direct the tool to do that is applying unreasonable (For google
groups: at the time of writing) constraints, e.g. 1ps clock cycle time.

For academic purposes it might be interesting whether a synthesis tool
has the capability to reuse structures or apply other fancy methods.
As an ASIC designer, however, I don't really care what it does as long
as the resulting netlist is small/fast enough for my purposes. And of
course that it works.

Best regards,
Marcus
 
Marcus Harnisch wrote:
"walala" <mizhael@yahoo.com> writes:

Can Synpopsys DC do that? The reason that I want to leave to DC to do that
is that I don't want to compromise structure and readablity...


Give it a try. Don't bother optimizing stuff where not
necessary. Synopsys DC supports resource sharing since at least
version 1999.10, which happens to be the oldest version I have access
to.

I think resource sharing is one of the easier tasks of the Synthesis
process.

Let the tools do what you paid for! If you design doesn't meet timing
or area constraints, you can still change the code.
Click to expand...
I may be an "old-fart" but in my humble opinion things are a bit more
complex than that. I agree that design productivity requires you to use
your synthesizer's "smart features", that is, code at a higher
abstraction level and code faster, in a more readable and less error
prone style. Good point. But:

1) Logic synthesis is not architecture synthesis. Logic synthesis is a
rather mature technology while the latter is still an active research
field. Don't think your logic synthesizer will consider the function and
the number of available cycles to compute it and automagically select
the right and minimum resources and allocate and schedule the
computation on the resources. A logic synthesizer just can't do anything
good with:
for I in 0 to ROWs-1 loop
for J in 0 to COLs-1 loop
F := F + A(I, J) * X(J, I);
end loop;
end loop;
wait for ROWs * COLs * CLOCK_PERIOD;
S <= F;
The resource sharing features that some logic synthesizers provide is
much more basic and, as many other features, sometimes interesting and
sometimes not. Anyway, the gain will not be so great that you absolutely
need it. Logic synthesis is still stuck at a very low entry level.
Something not so different from a structural description, if you
mentally unroll the loops, replace ifs and cases by muxes and
RISING_EDGE(CLOCK) by DFFs.

2) Design reuse is a key weapon in order to keep an acceptable design
productivity on large and complex ICs. If you rely on some specific
feature of some specific tool you're compromising the portability and
reusability of your designs. So before enjoying because syntesizer A has
a very nice and comfortable feature available it's sometimes useful to
verify that syntesizers B and C have similar capabilities. Just in case
the next project uses the same DDR controler you're designing but
another design flow...

Best regards,
--
Renaud Pacalet, GET/ENST/COMELEC/SoC
Institut Eurecom BP 193, 2229 route des Cretes
F-06904 Sophia-Antipolis Cedex
Tel : +33 (0) 4 9300 2770
Fax : +33 (0) 4 9300 2627
Fight Spam! Join EuroCAUCE: http://www.euro.cauce.org/
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top