( ESNUG 164 Item 1 ) ---------------------------------------------- [11/93]
Subject: (ESNUG 153 #6 154 #3 156 #1 157 #1 158 #1) "Are Wire Areas Used?"
> The increased area is showing up in the optimization cost, therefore
> in the cost function -- but I think this is an artifact. The cost
> function is not tuned to know that the area is due to a net and is
> using a misleading area cost for a gate, but only after selection.
> I don't think that the net area is used when deciding what gates to
> use for initial mapping or during optimization (the rule base does
> not understand net area). The rule base is correcting for the
> increase in area after the selection is made and may or may not be
> able to do anything about it. In fact the corrections may be in
> different parts of the design. (Could some of the Synopsys R & D
> people comment on this theory?)
From : [ Synopsys R&D, CAE, and Semiconductor Vendor Program Staffs ]
The general theory described above is exactly correct. Without going into
too many details about the problem, there are some places during optimization
that do take the net-area into account (the rule-base does, contrary to what
is implied above), and there are others that don't.
Cindy Eisner clearly and accurately demonstrates that net area is used in
area optimization in ESNUG 154 #3.
But, our current area-optimization strategy is not tuned specifically for
net-area optimization. We are working on ways of enhancing our optimization
for net-area. The new v3.1a routability feature may help with this problem.
When is net area taken into account? During technology independent
optimization and technology-mapping stage, the Verilog and VHDL Compilers
and Design Compiler DO NOT take net area into account. However, during
gate-level optimization, the tool definitely takes net area into account.
The net area is ADDED to the total area of the design and this number is
used in the area cost-function.
If you look at an "Area Report" generated by Design Compiler, you will see
something like this:
Combinational area: 46.00000
Noncombinational area: 12.00000
Net Interconnect area: 2.35000
Total area: 60.35000
It's Synopsys' experience that the total cell area is usually far much larger
than the calculated wire load net area. IMPORTANT NOTE: When a design is
constrained for area, it is the "Total area" that is constrained and
calculated into the total OPTIMIZATION COST that is seen during the mapping
stage of "compile" -- that is, net area is given no special treatment!
Conclusion: Design Compiler currently does not have any specific optimization
techniques which are *focused* on minimizing net area or the total number of
networks in a design. Design Compiler does consider net area when optimizing
designs that have an area constraint but only as part of the total area.
Because usually total cell area is generally much much larger than the
calculated wire load net area, it difficult for users to discern whether not
net area really does make an overall difference in optimization results.
- Synopsys R&D, CAE, and Semiconductor Vendor Program Staffs
( ESNUG 164 Item 2 ) ---------------------------------------------- [11/93]
Subject: (ESNUG 163 #6) "Why Does Design Compiler Always Come Up Short?"
> I take a simple design, say register/adder/register, create clock with
> period 20 ns and compile. I get a circuit that runs at 26 ns. With the
> same source code, I relax the period to 40 ns and compile. I get a circuit
> that runs at 43 ns.
>
> Obviously the compiler can make a circuit that runs at 40 ns, since it had
> successfully made a circuit that runs at 26 ns. Why then does the compiler
> stop at 43?
>
> The hotline tells me to set my clock "a lot faster than it needs to be".
> This seems ridiculous. What's really going on here? Why does Design
> Compiler want to seemingly always come up short?
From: gboyer@comanche.ess.harris.com (Glenn Boyer)
John,
The Synopsys design compiler reference manual says the following about the
mapping process (gate-level optimization):
"Constraints are divided into two groups: optimization constraints and
design rule constraints. The mapping process is also divided into two
phases. In the first phase, Design Conmpiler works on optimization
constraints. In the second phase, it works on design-rule constaints.
While working on design-rule constaints, Design Compiler TRIES to fix
all design rule violations without affecting optimization constraints.
If no other way can be found, Design Compiler fixes design rule
violations at the EXPENSE of optimization constraints."
So what Design Compiler does is it first optimizes your circuit to meet the
optimization constraints, which includes you clock period. Then it fixes
the design-rule constaints (MAX_TRANSITION and MAX_FANOUT) that it violated
in the first phase. The flaw to this approach is that your clock period,
which was ok during the first phase, is now hosed during the second phase.
One work-around is to crank down the clock period. Also, the compile command
has a "-prioritize_min_paths" option. This causes the Design Compiler to
"treat hold constraints as design constraints". But I have not played with
this option.
- Glenn Boyer
Harris
( ESNUG 164 Item 3 ) ---------------------------------------------- [11/93]
Subject: (ESNUG 163 #4) "Synopsys Marketing's Response to 'Licencing Wars'"
> The HDL Compiler family began as simple translators from an HDL to a
> gate-level description for logic optimization. We have since added
> significant high-level optimization capabilities to the HDL Compilers.
> Implementation selection of synthetic components is now a major part
> of high-level optimization.
--- --- --- ---
From: [ B.S.-ed into Being Anonymous ]
( John, as always, because of my company's own internal B.S. this
needs to be anonymous... )
This must be standard answer #1 in the Synopsys marketing excuse book. We get
the same answer whenever we ask a license or general tool question, "we added
so many new features, {insert list here}, that we have to subdivide your
licenses and charge more."
I guess we must be very lucky. Most of our other vendors don't treat
us this way. Being under maintenance has gotten us many tool improvements,
enhancements, and even totally new functionality. All without requiring
new licenses and/or more cost.
And this still dosen't address one of the main aggravations, when the design
compiler is finished with the HDL optimization IT SHOULD LET GO OF THE
HDL LICENSE. Even if users accept the rational in the above referenced
Synopsys note, there is no reason for the design compiler to keep the
HDL license locked up.
Another note. If the a tool gets to a point where it needs a license
and one is not available, it should allow the user to either wait for
a license, or exit gracefully (saving work to that point), not just die.
- B.S.-ed into Remaining Anonymous
--- --- --- ---
> Synopsys has always advertised high-level optimization as part of HDL
> Compiler. In fact we intended to license V2.2 to require HDL Compiler's
> use during compile in order to get timing-driven implementation selection.
> In V2.2 we accidentally did not license it that way. Since it was our
> mistake we have made the V2.2-type functionality available without requiring
> an HDL Compiler license during compile. NOTE: This only affects Synopsys
> customers that have more Design Compiler licences than HDL compiler
> licences (which is a relatively small number of Synopsys users.)
From: victor@truevision.com (Victor J. Duvanenko)
John,
As a reply to the Synopsys Marketing about HDL licenses. Their point is
well made and understood. However, they missed the entire point of the
problem. It is not that the HDL license is required at the begining of our
scripts when the HDL source is compiled and then again sometime later and
maybe several times in the dc_shell script. We do want the best possible
results. It is that there is no way to manage the limited resource of the
HDL licences. We believe that most Synopsys customers would be perfectly
happy if a dc_shell script would wait for the "limited resource" (in this
case an HDL license) and when it obtained the "limited resource" would
continue to run. It is as simple as that! For instance, once the "design
ware" modules have been compiled/optimized the design_compiler goes on to the
mapping stage (which takes a long time). It is done with the HDL compiler
at this point and does not need it at all during the mapping stage. All it
would have to do is give the HDL license up, and then go on with the mapping
stage.
The reason for the complaint, is that the "problem" is embedded too deep
inside to be fixed with a dc_shell script - the "problem" occurs when you
say "compile", and the user with a time critical design has no way of knowing
if his script will finish reliably or not.
We've been asking for a simple license management capability for over two
years now - that simply waits for license until it obtains one and then gives
one up whenever it is done (no fancy queueing is needed). Synopsys needs to
think of "limited resources" as any license that a customer pays for. If I
had to guess at it, the trouble comes from Synopsys R&D running and testing
with unlimited licenses (which is not how a user operates), so they miss a
"bug" completely. I hope this makes the point clearly!
- Victor J. Duvanenko
Truevison
( ESNUG 164 Item 4 ) ---------------------------------------------- [11/93]
From: sgolson@trilobyte.com (Steve Golson)
Subject: A Thermonuclear Ungroup Script
Here's a dc_shell script that will completely ungroup current_design right
down to library cells, NO MATTER WHAT. First the script removes dont_touch
from all designs used, then removes dont_touch from any cells.
/* remove dont_touch from designs in hierarchy */
remove_attribute -quiet find(-hierarchy design) dont_touch
/* and ungroup */
ungroup -flatten -all
/* keep going until everything is ungrouped */
while (find(-hierarchy design)) {
sh echo '#### finding hierarchical cells on this level ####'
hier_cells = filter(find(cell),"@is_hierarchical==true") > /dev/null
sh echo '#### removing dont_touch from cells ####'
remove_attribute -quiet find(cell,hier_cells) dont_touch
sh echo '#### and ungrouping ####'
ungroup -flatten -all
}
- Steve Golson
Trilobyte Systems
( ESNUG 164 Item 5 ) ---------------------------------------------- [11/93]
From: uunet!fmicos!joker!martin (Martin Gravenstein)
Subject: Seeking Cheap Ways To Translate VHDL to Verilog
Anyone have a VHDL to verilog translator? I am thinking of using Synopsys
to do this but I don't currently have a VHDL compiler license. Anyone know
of a cheaper way?
- Martin Gravenstein
Ford Electronics
|
|
