Bonjour Citizen ESNUGers! On this day, July 14th, a little over 200
hundred years ago, French peasants attacked a prison in Paris called the
"Bastille" -- helping set off the French Revolution. One person adversely
effected by this change in government was Marie Antoinette, then Queen
of France. Her imprint left on history was in being credited with saying
"Let them eat cake!" when told about the starving peasants prior to the
Revolution. A lessor known fact (No, I'm not making this up) was that, at
the Palace of Versailles, Marie had a model peasant farmhouse built in
the backyard where she kept a flock of well fed (hence chubby), regularly
bathed & perfumed sheep with dainty blue ribbons around their necks. The
fate of the flock during the revolution is unknown; but you can guess...
Liberte', Egalite', Fraternite', Mint Jelly!
- Mssr. Jean-Luc Cooley
L'Homme De ESNUG
( ESNUG 190 Item 1 ) ---------------------------------------------- [7/94]
From: victor@truevision.com (Victor J. Duvanenko)
Subject: Rename "set_output_delay" and "set_input_delay"
John,
I just got hit by the same mistake I always make - "set_output_delay 20".
I always forget what this command means (and the other 4 designers here at
Truevision have the identical trouble). The set_output_delay needs a new
name that is more intuive. I propose renaming it to "set_external_delay".
This command would simplify our lives a bunch, since it can also be used
instead of set_input_delay for input ports. For example, you would say
"set_external_delay 10 my_input_port" and this would mean that the logic
external to the current design block takes 10 ns. You would also say
"set_external_delay 10 my_output_port" and this would mean the logic external
to the current design block needs 10 ns. For bidirectionals use
"set_external_delay -in 10 -out 20 my_bidirectional_port".
Please make this command happen.
- Victor J. Duvanenko
Truevision
( ESNUG 190 Item 2 ) ---------------------------------------------- [7/94]
From: [ No Name ]
Subject: Any Traps w/ Synopsys Non Linear Delay Model?
Status: R
Hi John, Please keep me anonymous.
We are considering changing to the non-linear delay model. Is anyone using it?
Does it yield accurate results (compared to the cmos2 model)? How badly does
it affect the synthesis (optimization) performance (compared to the cmos2
model)?
- No Name
( ESNUG 190 Item 3 ) ---------------------------------------------- [7/94]
From: brien@acuson.com (Brien Anderson)
Subject: Things Are Looking Up With Synopsys!
Hello John,
Sometimes good and surprising things do happen such as finding a $20 bill on
the sidewalk -- likewise with Synopsys. I really like Worldview -- the new
Synopsys 3.1 on line documentation. It has taken Synopsys a year, but the
new solvit is great. Now I know what the most asked for reports are etc.
I can get documents directly such as star 14104 without having to play 20
guesses with solvit.
And the big surprise is, "No more lawyers!" according to Aart de Geus at the
EE Times Benchmarking Summit at DAC. The synthesis competition is free to
publish independent benchmarks without the fear of Synopsys lawyers bothering
them. Things are looking up. Thank you Synopsys.
- Brien Anderson
Acuson
( ESNUG 190 Item 4 ) ---------------------------------------------- [7/94]
From: jcooley@world.std.com (John Cooley)
Subject: Summary Listing of Hot Solv-It Articles & STARs
[ Editor's Note: enclosed is a condensed listing of highly popular articles
you can get from the Synopsys Solv-It system. Check'm out! - John ]
NOTE-019401 v1.0a:now Methodology Note: Technology-Independent Boundary
Scan Synthesis Using Test Compiler
TAN-468 v3.1a:now General guidelines to using the Finite State
Machine (FSM) Compiler
NOTE-039404 v1.0a:now Methodology Note: Finite State Machine Synthesis
NOTE-019402 v3.0a:v3.0c Meth Note: A New ASIC Methodology at HP Boise:
Putting the Pieces Together
METHCONT v1.0a:now Meth Notes: contents listing for all issues
NOTE-039401 v1.0a:now Meth Note: High-Level Design Meth Overview
INFO-003951 :current Behavioral Compiler Revolutionizes IC Design
KD-139002 v3.1a:v3.1a Changing color or geometry of Design Analyzer
dialogs and windows
RELN-31a-103 v3.1a:v3.1a Release Notes: Known Problems in SDF Reader
RELN-31a v3.1a:v3.1a Script for Retrieving all v3.1a Release Notes
from SOLV-IT!
TUTOR :current A Beginner's SOLV-IT! Tutorial
--- HOT STARS FROM THE SUPPORT CENTER ON SOLV-IT ---
SYNTHESIS
STAR-18377 v3.1a:now Compiler fatals during sequential mapping when
compiling
STAR-19021 v3.1a:now Design fatals during register inferencing when
using Verilog
STAR-18958 v3.1a:now Quality of results on a latch-based design is
poor
STAR-19209 v3.1a:now Clock and max_transition constraints increase
compile time dramatically over v3.0c
STAR-19130 v3.1a:now Incomplete library causes DC fatal
SIMULATION
STAR-19020 v3.1a-sim594:now Functions With Return Type "real" Fail
STAR-18158 v3.1a:now Tracing Non-Existent Verilog Object Causes
Fatal
STAR-18184 v3.1a:now Procedure with wait statement and call to
another procedure may simulate wrong
STAR-19300 v3.1a:now Timing is always turned on when running
simulation using LMSI
( ESNUG 190 Item 5 ) ---------------------------------------------- [7/94]
From: Carl Wuebker <clw@hprnd.rose.hp.com>
Subject: Mentor Section of ESNUG/DAC Awards
> WHAT DO YOU MEAN:"WHAT'S NEW?": When people in the Mentor booth were asked
> by a long time customer: "What do you have new this year?" After thinking
> a bit they found they couldn't answer with anything other than a simple
> design manager tool.
John, Be glad you didn't have to use the *old* design manager tool... the new
one works much better. IMHO, Mentor is spending their time where I want them
spending their time -- in fixing bugs. Those of us who prize productivity (as
opposed to the latest, whizziest, half-working tools) and know how much
engineering time is wasted in detecting, checking out & working around bugs
look for opportunities to recognize vendors who work to improve their tool
quality... I don't consider myself a big Mentor supporter (we like their PCB
tools, but prefer the more standard Verilog/Synopsys tools to Mentor's
Quicksim/Autologic), but I wish you'd taken the opportunity to complement them
on their much-fewer-bugs 8.2 releases as opposed to criticizing them for not
coming up with anything new. Just my opinion.
- Carl Wuebker
HP Roseville
P.S. Other than that, I usually agree with your helpful, informative &
inexpensive :-) newsletter...
( ESNUG 190 Item 6 ) ---------------------------------------------- [7/94]
From: jand@easics.be (Jan Decaluwe)
Subject: Subtle Misleading Test Compiler "Bug"
John,
Recently we ran into a rather subtle problem regarding test vector generation
with Test Compiler. The problem is not a bug, and can be solved by reading
the manuals (especially between the lines). Rather, the problem is due to
misleading TC command options. From investigations with other TC users we
learned that several had similar problems, so I figured it would be useful to
post the details to ESNUG.
The symptom of the problem is a one-cycle shift between expected results and
actual results during simulation of the ATPG vectors.
The reason lies in the test vector generation procedure. Originally, we
blindly followed the procedure described in the vendor's design kit
documentation, as follows:
/* original, incorrect test vector generation procedure */
dc_shell > create_test_clock ... -period 2000 -waveform {1000, 2000}
dc_shell > check_test
dc_shell > create_test_patterns
dc_shell > write_test ... -strobe 1900 ...
The underlying assumption is that the strobe time value declared with -strobe
will be used in a test protocol according to which the vectors will be
formatted.
However, this assumption is incorrect. In reality, the test protocol is
inferred by the check_test command, which is issued before the test vector
generation. The test protocol timings should be defined before that, using
TC variables as follows:
/* correct test vector generation procedure */
dc_shell > create_test_clock ... -period 2000 -waveform {1000, 2000}
dc_shell > test_default_period = 2000
dc_shell > test_default_delay = 100
dc_shell > test_default_bidir_delay = 100
dc_shell > test_default_strobe = 1900
dc_shell > check_test
dc_shell > create_test_patterns
dc_shell > write_test ...
The explanation for the problem with the original procedure is that the
"test_default_xxx" variables have default values (for a 10 MHz test cycle).
In particular, test_default_strobe equals 95 ns by default. Unless it is
changed, the vectors will work for a strobe time of 95 ns. Thus strobing is
assumed to occur BEFORE the rising edge of the test clock (which occurs at
1000 ns in the 2000 ns test cycle). Redefining the strobe time with
write_test command merely changes the strobe timing, but not the original
test protocol. As the 1900 ns strobe comes now AFTER the rising edge, there
will be a one-cycle shift in the expected response.
Note that it is not necessary run ATPG again to fix the problem. Instead of
the create_test_patterns command, one could read in the .vdb file at that
point.
- Jan Decaluwe
Easics, Inc., BELGIUM
( ESNUG 190 Networking Section ) ---------------------------------- [7/94]
Sr ASIC Leader w/broad exp in Verilog, DC, FPGAs, & ASIC test strategies
wanted in Germantown MD. "sachsa@ccmail.tt.com" Fax: A.Sachs @ 301-353-0734
|
|
