Subject: Re: Racal-Redac Gossip & Boot Camp Report (ESNUG)
> Attendance at this year's VI was estimated at roughly 250-300 people.
> Most people polled felt that the crowd was evenly split between
> VHDL suppliers and VHDL users. In addition, most of the experienced
> attendees said that the crowd seemed about the same size as it was
> the prior year. A few of the vendors privately complained that
> they saw very few new faces and that attendance in the exhibit hall
> was very sparse the second day of the conference. (Free beer & wine
> was only available in the exhibit hall on the first day of the exhibits.)
From: ajoy@cirrus.com (Ajoy Aswadhati)
A couple of us from Cirrus Logic went on the second day evening to take a
look at the exhibits. We were told that the exhibits were free and open to
the public. But to our surprise, people at the registration desk told us
that we need to know some representative from the vendors to get in. This
seemed absurd because if we were interested in buying/evaluating some useful
tool we need to know someone from the vendor companies.
(Fortunately, a representative from a company came by to let us in.)
- Ajoy Aswadhati
Cirrus Logic
> A humorous note at the conference occurred when Yatin Trivedi, a columnist
> who is a strong Verilog advocate, walked around the exhibit hall with his
> name badge giving him the title "Verilog Bigot" followed by a small hand
> written sign that said: "Will write Verilog For Food."
From: trivedi@netcom.com (Yatin Trivedi)
John, how dare you miss out the credits to Larry Saunders for inviting me
out there in the first place so that the dull hallways and empty exhibit
booths can use some "live" entertainment at my expense? I would solicit
ideas for a nice, friendly revenge at OVI conference in March '94.
The other handwritten note "Verilog for food" was by Rich Goldman of
Synopsys. He dreams of being with David Copperfield on a magic show; when
given a magic wand he makes Verilog disappear. And then he ... he ... he
wakes up ... screams are heard because Verilog's still here ... :^)
(Yes, both are good friends and cc'ed on this email. Without these friends,
I wouldn't learn much about VHDL or appreciate how good Verilog is for real
designers.)
- Yatin Trivedi
YT Associates
[ Editor's note: Larry Saunders is the VHDL columnist who is Yatin's friendly
nemisis in ASIC & EDA. Rich Goldman wants Verilog to disappear because
Synopsys, Inc., sells a VHDL simulator but no Verilog simulator. Rich
looks a little like David Copperfield if the light in the room's poor and
you squint a lot. (An awful lot!) ;^) - John ]
( ESNUG 156 Item 1 ) ---------------------------------------------- [10/93]
Subject: (ESNUG 154 #3) Cindy's Response to "(ESNUG 153 #6) 'Too Many Nets'"
> the problem is that for synopsys, the default cost of wire is 0 in both
> timing and area. however, you can use a wire load model to tell synopsys
> how much time (r & c) wire costs, and how much area (routing).
> to see if the wire model you are using contains area, look at the
> "net interconnect area" field of the "report_area" report. if the
> "net interconnect area" is 0, you have a problem.
[ an example demonstrating that Cindy got a smaller area design by
just adding a wire loading model was deleted for brevity. - John ]
> as soon as wire costs area, synopsys recognizes that it is preferable to
> use the single gate instead of lots of smaller gates.
--- --- ---
From: uunet!fmicos!splinter!flieder (Jeff Flieder)
As far as I know, the wire area in the wire load model is NOT use during
synthesis to decide which gates to use. This area is there for forward
compatibility for future versions of the tool. As far as the results that Cindy
posted, which look like the wire load made a difference, I dunno!!
- Jeff Flieder
Ford Microelectronics
--- --- ---
From: huey!bob@apple.com (Bob Eisenstadt)
John,
I just wanted to add to the discussion about using wire load models with
Synopsys to help optimize net count instead of gate count. I've spent the
last 6 months trying to minimize net count, not gate count, and have found
the following:
1.) If constraints are not being placed on Synopsys, such as timing
constraints, using a nonzero wire load models often causes a noticable
decrease in net count. (Unfortunately even under these conditions, the
wire load model is insufficient to induce Synopsys to use more muxes
instead of smaller gates.) Thus it dosen't provide a magic solution
that yields great logic with minimal netcount.
2.) Once timing constraints are placed on Synopsys, the use of non-zero
wire load models appears to have only a marginal (or minimal) effect.
I'd like to know if other people have seen similar results on a real design
using a non-zero wire load models.
- Bob Eisenstadt
Supermac Technology
--- --- ---
> do you have your own library? then make sure that your wire model uses
> area! you don't have your own library? then tell your asic vendor that
> you want the area field of the wire model to be adjusted.
From: neil@hri.com (Neil Halbert)
John, FYI - you do not need a library compiler license to create a wire
load model if you do the following:
1) create a xxxx.lib file that contains your wire load info i.e.
>vi HRIwireload.lib
library(HRIwireload) {
wire_load("HRItest") {
resistance : 0.000000 ;
capacitance : 0 ;
area : 0.0000 ;
slope : 0.0000;
fanout_length( 0 , 0.0000 ) ;
fanout_length( 1 , 0.0000 ) ;
fanout_length( 2 , 0.0000 ) ;
}
}
2) Invoke Design Compiler and execute
dc_shell> read_lib HRIwireload.lib
dc_shell> write_lib HRIwireload
This will create a .db wire load file you can read in and use as your wire
load model. This only creates one model "HRItest", but you can just as easily
define ten different wire loads in the same file.
If you are using a vendor library just do a report_lib XXXXX to extract their
wireload information and add in the area attribute.
- Neil Halbert
Horizon Research
( ESNUG 156 Item 2 ) ---------------------------------------------- [10/93]
From: Jay McDougal <jaym@hpcvcdt.cv.hp.com>
Subject: compile -in_place Bug with Nonlinear Library
Hi John, you can use my name, email etc.
Hopefully this will help some of you in ESNUG to avoid some hair pulling.
I recently started using the 3.0b design compiler and was very excited
to use the new table driven models for my library. Everything was
working great until I tried to back annotate routing capacitance and
run in place optimization (IPO). It turns out that there is a bug in the
"compile -in_place" command that causes it to work incorrectly (It
does not swap gates that it obviously should). This only happens when
two things are true.
1. Nonlinear library with output transition depending on input transition
2. Max_transition violations
I have been able to work around this problem by removing all max_transition
constraints from my library during IPO. The cell swapping then works
correctly and my post-route timing is improved. This does leave potential
max_transition violations that I have to check by re-loading the library with
the max_transition constraints, but so far there have been very few
violations because my library also uses max_capacitance constraints which
keep the max_transition times from getting too large even without constraints.
Synopsys has promised a fix to this bug (STAR 14795) in the next release.
How many people out there are using In-Place-Optimization? How much swapping
do you allow?
- Jay McDougal
Hewlett Packard
( ESNUG 156 Item 3 ) ---------------------------------------------- [10/93]
From: jcooley@world.std.com (John Cooley)
Subject: 3.0b Fatal During Charaterize
One day at a client site, I was happily starting off some hierarchical
compiling and thinking to myself: "Well, the functionality finally checks out.
All you have to do now, John, is to get this baby quickly through Synopsys
and it'll be happy customer time."
Everything *looked* OK when I read in all the subdesigns, linked it and
did some initial characterizations, etc. By the time my dc_shell script
came to the second set of characterizes, I was already mentally writting out
an invoice to the client and thinking what the next customer would want when
suddenly, without warning, I got:
dc_shell> characterize -constraints -connections extraction_0
Performing characterize on cell 'lucifer'.
Information: Updating design information... (UID-85)
Fatal: Internal system error, cannot recover.
Error code=10
Release = 'v3.0b' Architecture = 'sparc' Program = 'dc_shell'
'8485776 8486060 8704860 3553632 3708536 3708776 3708824 3709200
1893304 7698940 7698564 7703452 ... '
37>
Reality has a way of ruining daydreams; especially when you think you're
almost completed an ASIC design. Called the Hotline.
Turns out that "Error code=10" means nothing and the long string of numbers
got me to the point where the Hotline says there's a fatal in Synopsys 3.0b
that causes this during characterize and to map everything in the hierarchy
without constraints first before doing any characterizing.
I tried this and it works but it messes up some clever hierarchical compiling
tricks. Here's what I got when I bounced this problem off Synopsys R & D:
From: [ Synopsys R & D ]
Hi John,
The characterize fatal that you have run into is a known bug in v3.0b.
The problem has been fixed in v3.0c. Because the workaround is
relatively easy, this bug was not considered of a high enough severity
to deserve a special release.
The problem is a memory bug that occurs when characterizing unmapped
designs that contain synthetic parts. This also occurs with certain
kinds of report commands. Whenever we have seen the fatal, it has
occured on the second report/characterize command. Without going into
the specifics of the problem, the root of the bug is an unintentionally
bad memory pointer to some DesignWare structures.
The easiest workaround for the bug is to pre-compile the design to map
it into gates. Because the purpose of this initial compile is to
simply get the design into gates, constraints are not important. In
fact, to get the fastest compile, it would be best to remove all
constraints. The fast-map effectively gets rid of the synthetic parts
which avoids the fatal when you try to do a subsequent characterize on
any part of the design.
1.) compile (fast-map) the design with no constraints.
2.) Apply the full constraints.
3.) characterize each sub-design.
4.) perform a full compile on each sub-design and the top-level.
This will use the characterized constraints.
We know that different customers have different hierarchical compile
strategies because they can be very design specific. We would like
to appologize if this messes up your specific approach. This will be
fixed soon and will be available in 3.0c.
- Synopsys R&D dude-persons
This fix wasn't exactly the approach my original script was trying to take
with this client's design, but I can confirm that this approach was good
enough to get me through.
- John Cooley
EDA & ASIC Design Consultant
|
|
