If you're getting spurious/weird/empty e-mail from the official Synopsys
"Scout" mailer please be patient. (During SNUG '95 it sent out 5 duplicate
copies of "Scout" to everyone; this week it was sent out empty e-mails.)
What's going on is pure Murphy's Law. My contacts tell me they ran into
four major network problems involving e-mail, "Scout" and more -- while at
the same time trying to hook up SolvIt to the Wide World Web! (I can
sympathize; I'm doing my crazy self-employed/independant consultant taxes
and it makes their headaches look trivial!)
- John Cooley
the ESNUG guy
( ESNUG 214 Item 1 ) ---------------------------------------------- [4/95]
From: oren@waterloo.hp.com (Oren Rubinstein)
Subject: SNUG '95 Comments
Hello John. I promised I'd send you my impressions about SNUG, so here goes:
1. It was much more interesting than last year, because they had a lot of
new topics, new tutorials, etc. And this year, they were fair to the
Verilog comunity, by repeating the same tutorials for both languages,
not just saying "It applies to Verilog too". (I think everybody knows
to which other language I'm referring, so I'll refrain from using a
four-letter-word in my email.)
2. One thing that I should mention for the benefit of those who didn't
attend, is that the SOLV-IT database is finally available on-line, at
http://www.synopsys.com. I didn't use SOLV-IT before (not much, anyway)
because it was so difficult, but now it really has a chance. It even
has user's ESNUG posts available for searching!
3. I think SNUG should be held over two days. Personally, I wished I could
attend more of the sessions, but they were happening in parallel and I
had to pick just a few. I don't think there will be any difficulty in
filling up two days.
- Oren Rubinstein
Hewlett-Packard (Canada) Ltd.
( ESNUG 214 Item 2 ) ---------------------------------------------- [4/95]
Subject: (ESNUG 213 #5) "Timing Models/False Paths in 3.2 Latch Based Designs"
> ----------------------
> | |
> | |----| B1 |
> ----|D | in|\ out<--------- three-state driver controlled by rd1
> | | QB|---| O-----|
> ---- | --|E | |/ |
> wr1 | |----| | |
> | L1 rd1 | 1-bit bus
> | |
> | |----| B2 |
> ----|D | in|\ out |
> | QB|---| O-----
> ---------|E | |/ <----------- three-state driver controlled by rd2
> wr2 |----| |
> L2 rd2
>
>...Synopsys doing a timing analysis from wr1 -> thru the bus -> back into a
>latch--> back onto the bus. (DesignTime tries to time a false path from
>wr1 to QB of L1 to out of B1 onto the 1-bit bus and back to the D input
>of L1. This is a false path as this would result in feedback loop.)
From: pane@tubaman.STD.Teradyne.COM (John Pane)
I have a suggestion. Could you use:
remove_annotated_delay -from {L1/E,L1/D} -to B2/out
remove_annotated_delay -from {L2/E,L2/D} -to B1/out
I would think this would make synopsys focus on the prop-delay from
(L1/D or L1/E) -> B1/out and (L2/D or L2/E) -> B2/out.
- John Pane
Teradyne
---- ---- ---- ----
Peh Kheng Boon <kbpeh@tmi.com.sg> replies to the above suggestion with:
My concern is I have many many of these data latches. I have to then go and
figure out which would have this type of problem and set the constraint on
every one of them. Phew! That sucks. Secondly, it seems then I cannot
constraint the design from the HDL source. I must have a preliminary gate
implementation before I can try this method out -- otherwise Synopsys will go
crazy again. If I have special stuff like adders around, I would also have
the new problem that without constraints the adder Synopsys chooses may not
have the right architecture to meet my desired speed later!
Synopsys's on line help: "DesignTime Application Note: 2. Point-to-point and
Path Segmentation" suggested breaking the loop at the output of B1. Assuming
E is active low, one does:
set_output_delay <a number> -clock lclock -clock_fall find(pin, "B1/out")
This sets the timing requirement on the output of the driver rather than the
bus. (Wires wr1, wr2, rd1 and rd2 are all gated by "lclock" here.) This
breaks all existing paths through the three-state output pin. One should
then set realistic arrival time at the pin and appropriate cycle constraints
from the pin:
set_input_delay <a number> -clock lclock lbus set_multicycle_path \
-from find(pin, "B1/out")
One should be able to disable the feedback segment w/o affecting other paths:
set_false_path -from find(pin, "B1/out") -to all_registers(-data_pins)
Note I've assumed that the 1-bit bus is connected to a port called "lbus".
This method should work though I have not tried it out. However, this makes
things very messy because one needs to have a gate implementation before one
can do this.
- Peh Kheng Boon
TriTech Microelectronics International Pte Ltd, Singapore
( ESNUG 214 Item 3 ) ---------------------------------------------- [4/95]
Subject: (ESNUG 213 #1) "DC 3.2a vs. 3.0b -- Smaller But Slower Designs?"
> Design Compiler 3.0b Design Compiler 3.2a
> -------------------- --------------------
> Combinational area: 39,936.000 38,893.750
> Noncombinational area: 27,637.250 27,714.250
|
got larger noncomb area here ---'
From: [ Noisemaker ]
Hi John,
(I don't know if you remember me; you told me that I'm an obvious "Noisemaker"
after a SNUG '95 breakout session... <grin> Anyway don't show my name or CO.)
I have a little problem with the above results, and that's basically the
noncomb logic area has increased. More info is needed here to explain this
increase: is it because Synopsys simply synthesized different cells (i.e.
buffered FF, etc... ) -- or is it because there are unknown additional FF
and/or latches??? I've encountered a few cases where the same HDL code and
scripts synthesized differently. In one specific case between Synopsys v3.0c
and v3.1b, we ended up with extra latches in 3.1b. We traced the source
of the problem to the actual HDL which indeed inferred latches but the
latch's Gate pin was tied high in one level up in the hierarchy with
set_logic_one (i.e. the latch is in pass through mode. This is a no-no I
know, nevertheless it happened) Both versions synthesized the correct logic;
but one with larger area.
My point is DON'T ALWAYS BLAME THE TOOL FOR DISCREPENCIES YOU GET, RATHER
TREAT IT AS MORE INFORMATION ABOUT YOUR DESIGN AND FIND OUT WHY THE RESULTS
ARE DIFFERENT. This can be very annoying and source of headache but it's got
to be done. (This is especially true in design re-use with HDL code written
and modified by previous peers over and over again.)
- [ Noisemaker ]
( ESNUG 214 Item 4 ) ---------------------------------------------- [4/95]
From: rray@poci.amis.com (Russell L. Ray)
Subject: VHDL Full Timing Gate Simulation (FTGS) & Support Center Problems
John,
I'm wondering if anyone else is having problems modeling with FTGS & getting
support from the support center. An FTGS (Full Timing Gate Simulation)
model is the VSS accelerated VHDL model. It is desirable to use these models
over other VHDL models because Synopsys has optimized the packages into the
kernel to improve simulation speed. I have several cells that are
"complex" combinational gates. One in particular has the boolean function
Q = (A and B) nor (C and D). I want to have glitch detection & x-generation
enabled so that when the inputs change to close to each other, I get a
warning and an X injected into the simulation.
My case is this: B='1', D='0' and have for a long time. A rises from '0' to
'1' soon (~5 ps) after C falls from '1' to '0'. Since D has been '0' for a
long time, the C path should be "disabled". However, the FTGS model reports
a glitch and I get an X out. I have tried several times to get responses
from the support center on this one but I seem to have found a "black hole".
(Generally I'm pleased with the support center, but this case is not it.)
- Russell L. Ray
American Microsystems, Inc.
( ESNUG 214 Item 5 ) ---------------------------------------------- [4/95]
From: dtkain@ccgate.hac.com (Dan Kain)
Subject: Specific Reasons Why Synopsys Sucks!
John, Synopsys synthesis sucks because:
1) It's Too Difficult To Use.
This is an entirely qualitative response which I feel needs some
rationale backup. In order to train a novice at our site to learn how
to run Synopsys synthesis, he/she will have to read the Synopsys VHDL
Compiler manual to learn how to write VHDL that Synopsys can read,
read the Design Compiler manual to write the timing & area constraints,
and read the Command Reference manual to really write the timing & area
constraints. After reading these manuals and perhaps taking a Synopsys
training class, the novice then has to find a Synopsys expert in our
organization that can really teach him/her how to run Synopsys. (I
compare this with our methodology of training a novice to run the Vantage
simulator. The novice sits down in front of a workstation with an
experienced Vantage user & learns how to run Vantage in about an hour.
Done.) -- I simply do not accept that synthesis is so difficult of a
process to run that it takes the learning investment that Synopsys
requires in order to accomplish the task.
2) It Consistently Dissapoints.
I have been running Synopsys synthesis tools since version 1.2. After
many years of fighting to get my VHDL code to successfully compile, and
after many years of iteration after iteration of changes to my timing
and area constraints to try to get a reasonable schematic in a reasonable
amount of CPU time, to date I have been continually dissapointed with my
final schematic outputs from the Synopsys synthesizer. (I again compare
this with my Vantage simulator experience. The code always compiles
except for my syntax errors. It always simulates correctly. Finally, it
has always done it in a reasonable amount of CPU time, even for some very
large designs.)
- Dan Kain
Hughes Aircraft Company
( ESNUG 214 Item 6 ) ---------------------------------------------- [4/95]
From: who@vadem.com (Wen Ho)
Subject: Seeking Tools To Translate VHDL To Verilog
Hi, John, -- do you know of any tool that translates VHDL to Verilog?
- Wen Ho
Vadem
( ESNUG 214 Item 7 ) ---------------------------------------------- [4/95]
From: mkphilli@netcom.com (Mike Phillips)
Subject: LSI Logic Synthesis Libraries are Slow
Hi John!
I'm having some problems with the new version of the LSI Logic synthesis
libraries and was wondering whether anybody had also encountered this problem.
The old version of the libraries is 3.1a.1 and the new version is 3.2a. I'm
also using version 3.2b of Design Compiler. The problem is that with the new
libraries, the synthesis compile time increases significantly. I use:
compile_use_low_timing_effort = "true" and get the same results.
By-the-way, ESNUG has been a tremendous help!
- Mike Phillips
E-Systems
( ESNUG 214 Item 8 ) ---------------------------------------------- [4/95]
Subject: Synopsys 1995 Behavioral Design Seminar Series
Synopsys and Sun Microsystems are offering a $95 seminar on behavioral design
in applications such as ATM, high-end graphics, digital signal processing,
and cellular. Dr. Raul Camposano, Synopsys director of research and
development and leading behavioral synthesis expert, will be on-hand at
several seminar locations. (Register at least two weeks before the seminar
and recieve a complimentary registration for a co-worker!)
San Diego, CA -- April 25 Scottsdale, AZ -- April 26
Chicago, IL ---- April 27 Seattle, WA ----- April 27
Burlington, MA --- May 2 Santa Clara, CA --- May 2
Portland, OR ----- May 3 Dallas, TX -------- May 3
Parsippany, NJ --- May 4 Raleigh, NC ------- May 4
To register call (800) 541-7737, x1920, or email "spineda@synopsys.com".
( ESNUG 214 Networking Section ) ---------------------------------- [4/95]
San Jose, CA - Wanted, EDA Manager to enhance interfaces between Altera and
EDA Companies. Good comm skills rqrd. No headhunters. "beach@altera.com"
Sunnyvale, CA - Design Engineer wanted in AMD to be a meth. consultant for
FastScan/Synopsys/Verilog tools. No Recruiters. "jaime.tolentino@amd.com"
|
|
