Due to the high number of requests for extensions (because everyone was
going away for Thanksgiving) for submitting proposals to the upcoming
SNUG '94 meeting, they've moved the E-MAIL proposal deadline to Friday,
Dec. 10th -- that's nine days from now for those who rarely use calendars!
To submit something you'd like to talk about this March at the next SNUG
in California, send your proposal to Willis Hendley, SNUG '94 Grand Poobah,
at "hendley@suneast.East.Sun.COM" on or before this next Friday!
- John Cooley
the ESNUG guy
[ For those who don't know: SNUG stands for the "Synopsys Users Group" which
is an annual meeting completely financed by $100 million annual sales
Synopsys, Inc. ESNUG stands for "E-mail Synopsys Users Group" which is
completely independent of Synopsys, Inc. and is financed by a sheep farmer
in Eastern Massachusetts named John Cooley who occassionaly consults in
EDA & ASIC design while thinking of better ways to heat his drafty farm. ]
( ESNUG 165 Item 1 ) ---------------------------------------------- [11/93]
Subject: (ESNUG 162 #2 163 #1) 3.0a & b FPGA Compiler / Incorrect Logic
> john, please have my name withheld. we have been using the synopsys fpga
> compiler and having all sorts of trouble with it. finally by the end of
> yesterday we figured out that the fpga compiler was creating bad designs.
> i had planned for the next morning to phone the hotline to give them #$@%!
> for this and to write a nasty esnug post to boot. then i got the esnug
> with my exact fpga bad design bug from their quality department with the
> workaround. i totally changed my tune. we tried the fix. it works!
>
> please send an anonymous customer's thanks to your contacts in the synopsys
> quality department for this bug and workaround they reported to esnug. we'd
> like to see more of these on esnug. it saved a lot of pain on our part.
From: Lauren Baker <baker@mer-mail.ctron.com>
I just wanted to suggest that people remember to get hold of the release
notes from Synopsys, since the response posted here to the FPGA Compiler
compile problem (isolating feedback) was a direct copy of the information
in the Release 3.0b FPGA Compiler Release Note (under Known Problems and
Limitations in v3.0b).
- Lauren Baker
Cabletron
( ESNUG 165 Item 2 ) ---------------------------------------------- [11/93]
From: [ Disaster Zone ]
Subject: Synopsys 3.0b Is A Disaster on IBM RS6000 Workstations!
John, for obvious reasons no name no company, OK?
John, using Synopsys 3.0b on IBM workstations is like living in a disaster
zone. I have to constatantly stop whatever I'm doing in Synopsys to write
out .db files because it likes to die at completely random and unpredictable
points during a Synopsys session.
I've spoken with other Synopsys / RS6000 users and they say: "Yea, it does
that. Save your .db files often." When I called the Synopsys hotline, they
said: "Yea, it does that. Save your .db files often. It'll be fixed in a
later rev."
I find this very exasperating to work with at times when I forget to do my
thousandth .db save and Synopsys suddenly dies. Does anyone know how to
automate .db saves every 1/2 hour so I wouldn't have to deal with this?
- Living In A Disaster Zone
P.S. Synopsys R & D sez in ESNUG 157 #2:
> But the most useful information, though, is the long string of following a
> Synopsys fatal because it's a stack trace. e.g.
>
> '8485776 8486060 8704860 3553632 3708536 3708776 3708824 3709200
> 1893304 7698940 7698564 7703452 ... '
>
> It extremely helpful to send the stack trace along with any error codes or
> error ids that appear in a fatal.
The IBM RS6000 version of Synopsys doesn't have stack traces. Hotline says
that, too, will be fixed in a future rev. I'm now wondering: What other
RS6000 "features" are RS6000 / Synopsys customers seeing?
( ESNUG 165 Item 3 ) ---------------------------------------------- [11/93]
From: [ Synopsys Marketing ]
Subject: DC Expert and DC Professional
In ESNUG 160 #2, a customer wrote:
> On a similar note we have 1 dc_expert license and multiple dc_professional
> licenses since we were led to believe that the expert license was mainly for
> back annotation from layout and other "once only" operations. I have since
> found that multi clock designs cannot be compiled without the expert license
> and everything we do has more than 1 clock in it. I would be interested to
> know if many people are able to make efective use of dc_professional without
> dc_expert.
DC Expert is targeted for high performance design, while DC Professional is
targeted at more standard ASIC design. DC Expert's additional features
include:
- multiple frequency clocking [DC Professional supports multiple clocks
of the same frequency] - incremental design editing
- pipeline re-timing - latch-based time borrowing
- critical path re-synthesis - in-place optimization
In order to be as fair as possible when introducing DC Professional and DC
Expert, Synopsys automatically upgraded the entire customer base to DC Expert
without any additional license fee. Further, we provided a 6-month window
beginning December 1992 in which anyone could purchase DC Expert at the DC
Professional price. There is an easy upgrade path from DC Professional to
DC Expert.
- Synopsys Marketing
( ESNUG 165 Item 4 ) ---------------------------------------------- [11/93]
From: viswesh@cirrus.com (Viswesh Ananthakrishnan)
Subject : A Test Compiler Question
Hi John,
When I set the latches in my design to be transparent using the "set_scan"
command, it introduces combinational feedback loops. We are using the
'full_scan' test methodology and 'multiplexed flip-flop' as our scan style.
Any ideas on how to fix this problem ?
- Viswesh Ananthakrishnan
Cirrus Logic
( ESNUG 165 Item 5 ) ---------------------------------------------- [11/93]
From: mepatton@marsha.sanders.lockheed.com (Mark Patton)
Subject: (ESNUG 164 #2, 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
>> does Design Compiler want to seemingly always come up short?
>
>From: gboyer@comanche.ess.harris.com (Glenn Boyer)
>
>What Design Compiler does is first optimizes your circuit to meet the
>optimization constraints, which includes your 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.
John,
In my design, it is the first phase that always comes up short. So this
explanation does not shed light on my problem which is similar to the
orginal poster's description above. Anyone have another idea as to why
this is?
- Mark Patton
Lockheed Sanders
|
|
