> I know many women loved this film ("Titanic") and thought it was
> "romantic" -- I guess that's the heart of romance for many women
> -- seeing what they can get out of men. For me, it was one lame
> movie -- just like that "Bridges of Madison County" where wifey gets
> _bored_ with loyal hubby so she flings with wandering photographer and
> that "English Patient" movie where wifey flings with an English playboy
> because she's _bored_ with her loyal hubby. And all of these sleasy,
> cheesy movies get nominated for Oscars & are big box-office hits?!!
> Geez! (I dunno... I guess it's just a guy thing...)
>
> - John Cooley
> the ESNUG guy
From: Tim Davis <timdavis@tdcon.com>
John, are you telling me, as a full-blooded American male engineer, that
the few seconds of gratuitous nudity didn't make "Titanic" worth seeing? :)
- Tim Davis
Timothy Davis Consulting Broomfield, CO
---- ---- ---- ---- ---- ---- ----
From: Joe Buck <jbuck@Synopsys.COM>
There's a better rap against "English Patient": it's the anti-Casablanca.
In Casablanca, Bogie nobly gives up his great romance because the fight
against the Nazis is more important. Ingrid Bergman is all ready to dump
the hero of the resistance for Bogie and even turn her husband over to the
Nazis if Bogie says to, but he decides to do the right thing at the last
minute. In the English Patient, the male lead (Hungarian, not English)
collaborates with the Nazis, resulting in who knows how many deaths, just
to get back to his lover. He doesn't give a shit about the consequences.
- Joe Buck
Synopsys
---- ---- ---- ---- ---- ---- ----
From: eric@chrysalis.com
I agree on the other two ("Titanic" and "Bridges"), but "The English
Patient" *was* a guy movie - at the end, the hubby-abusing-wife dies a
slow death of starvation and exposure hiding out in a dank, dark cave
in the middle of the desert; a just punishment for ruining the lives of
both her cuckholded husband and her lover who also died a slow and
agonizing death from burns sustained in a plane crash, no?
- Eric Smith
Chrysalis Symbolic Design Campbell, CA
---- ---- ---- ---- ---- ---- ----
From: [ Zigzag, the Bail Bondsman ]
John -- I'm surprised you didn't mention "The Horse Whisperer". It was
the same as "The English Patient". Wife steps out on loyal husband and
falls for cowboy (Robert Redford) who is tending to sick horse. Husband
never did anything wrong. (anon pls.)
- [ Zigzag, the Bail Bondsman ]
( ESNUG 301 Item 1 ) --------------------------------------------- [10/98]
Subject: ( ESNUG 299 #2 300 #1 ) Crappy Chip Express Documentation Cost Us
> Chip Express is, IMHO, composed of rank amateurs and completely
> mis-documented their vector format. Now we need to spin another 2 days
> worth of effort to fix our test bench to re-generate the vectors in a
> completely different mode than what they originally told us. Arrgh.
> Probably don't want to post this w/ my name on it, but I figured you'd be
> interested. I will make damn sure that my company never uses them again.
>
> - [ "FedEx, They Ain't." ]
From: Tsipi_Landen@ln.chipx.com
Dear John,
I was quite surprised to read the "Crappy Chip Express" email in the ESNUG
299. I think it's not right to publish this kind of message from an
anonymous source. Accusing without taking responsibility is not what I
would expect to be an objective of ESNUG.
I don't believe there is one vendor out there who does not have at least
one unhappy customer. So, by letting him voice his opinion you may cause a
real damage to the company. Lets say the complainer is right (we all know
the customer is "always" right...) still the vendor should have the
opportunity to comment on these kind of strong accusations. I'm glad one of
our customers took the initiative to respond.
I would appreciate it if you could give it a though (or two ..) and let
your readers know what is your opinion on this kind of use of your
e-mail newsletter.
- Tsipi Landen
Marketing Communications Director
Chip Express Santa Clara, CA
( ESNUG 301 Item 2 ) --------------------------------------------- [10/98]
From: "Tom Harrington" <tharring@ford.com>
Subject: The New Design Budgeting Features In DC 98.08 Have Serious Problems
John,
If you've got DC 1998.08, and are interested in the new design budgeting
features, let me save you some time and frustration:
* It looks good if you run it from the new budget_shell tool (though I
have not done a detailed analysis of results yet).
* It just plain does not work from dc_shell. Don't bother.
I downloaded the EST update that's supposed to add design budgeting to
dc_shell. I suppose I should have taken it as a bad omen when the EST
file was called "db-1998.08.zip" and I was using a Unix system. Synopsys
support insisted that Solaris 2.5.1 has an "unzip" command. I didn't
find one, and no tool I could find would open it. I went back and forth
with support on this for a week before they decided to send me an unzip
tool.
For the record, the package contains:
* A file called $SYNOPSYS/admin/setup/budget.setup.e, which apparently
contains the code for the budgeting commands.
* Man pages in both Unix "man" format and HTML.
* A couple of support scripts: a new system-wide .synopsys_dc.setup and
one called $SYNOPSYS/auxx/syn/budgeting/scripts/write_gdb.dcscr
I dutifully read the man pages for the allocate_budgets and
allocate_hierarchical_budgets commands. Both said that the commands
"invoke the budget_shell allocate_hierarchical_budgets command". I
wasn't sure what the difference was, so I picked one to experiment with.
I wrote a script that basically tried to reproduce the sample code
contained in the docs. I tried to budget a design with:
dc_shell> allocate_budgets -verbose -db design_name.db -file_format_spec
"characterization/%D_budget.scr"
I got:
Error: unknown option '-file_format_spec' (CMD-010)
Synopsys support told me, despite the man page, "-file_format_spec" is only
available for command "allocate_hierarchical_budgets."'. OK, fine. I
deleted the option:
dc_shell> allocate_budgets -verbose -db design_name.db
<...much output snipped...>
Error: Must specify one of these options: cell_list or -incremental.
(CMD-004)
Huh? Neither of those are on the man page... I wondered if I should be
using allocate_hierarchical_budgets instead:
dc_shell> allocate_hierarchical_budgets -verbose -db iopsm_8.db
Error: Undefined operator on or near line 20 at or near
'allocate_hierarchical_budgets'. (EQN-2)
In other words, "what's 'allocate_hierarchical_budgets', kemo sabe?"
In response, I learned the following from Synopsys support:
* If you have done any manual design budgeting (such as the new
"set_user_budget" command) before using allocate_budgets, you
must budget with the "-incremental" option. Score another for
good documentation, since this was never mentioned. Of course,
since I didn't do any manual design budgeting, this answer
really fails to address the issue.
* Documentation and previous statements from support notwithstanding,
allocate_hierarchical_budgets is only available in PrimeTime. That is,
there's a man page for it under dc_shell, but the command isn't actually
available!
My overall impression is that Synopsys just completely skipped any testing
on the dc_shell -> design budgeting interface. The EST could not be opened
with standard Unix tools. And once installed, the tools either failed to
work or failed to exist. To top it off, they were accompanied by
documentation that, between missing crucial options and adding nonexistent
ones, seem to be little more than bad science fiction.
As I said earlier, though, the commands do seem to work as advertised in
the new budget_shell tool. Hopefully we won't have to wait for 1999.0X
for the dc_shell interface to be fixed.
- Tom Harrington
Ford Microelectronics Colorado Springs, CO
( ESNUG 301 Item 3 ) --------------------------------------------- [10/98]
Subject: (ESNUG 292 #4) My 12-Day Runaround With The Synopsys Hotline
> As manager of Synopsys's North American Support Center, I would like to
> hear directly from any customers having problems with our services. ...
>
> - Vito J. Mazzarino, Manager
> Synopsys Support Center & Automated Services
From: Ihab Mansour <ihab@xlnt.com>
John,
I want to explain to you my situation and please tell me why I should not
be upset from the HOTLINE. These situations happens all the time.
October 1: I called the HOTLINE around noon time and opened a logid 71949.
The lady said "I will call you in an hour or two to tell you
exactly what to do, because I don't remember the exact variable
name that you need." Great!!
October 2: I did not get any call or e-mail. I called the hotline again
and left a voice mail message. Got NO response.
Finally, on Monday, October 5:
Hi Ihab,
(Name Omit) told me that you had explained the problem to him in more
detail. I produced a testcase here to replicate your problem. I shall
give that testcase to (Name Omit) and he can take care of this.
You will hear from (Name Omit) sometime today.
Thanks,
- (Name Omit)
Synopsys Support Center (North America)
No one called me that day.
October 6: I called and I left a message. The Hotline person told me, that
"(Name Omit) is on the phone and as soon as he finishes he will
call you back." After about an hour without hearing from him,
I called one more time. He said "Please give more time to
finish and I'll get back to you". OK. It sounded good....
BUT, Anotther day, then two,... and still NO response back.
October 12:
Hi Ihab,
This mail is in reference to your issue "Instantiated scan cells are
replaced during insert_scan". I did try your problem using a testcase.
I would like to ask you a few things here. You told me that you have
instantiated a scan cell with Q tied to test_input(feed back loop) and
test_enable as grounded.
Did you set any attribute on this cell such that TC does not complain
about this during check_test? Please let me know and this should answer
many of our questions. Sorry for the delay.
Thanks and regards,
- (Name Omit)
Synopsys Support Center (North America)
My point to all of this is that the hotline did not help me in my critical
time EVER. It is the same every time. I spend about an hour explaining
the situation and it never resolved. I always find a solution by long hours
of trial and errors. Please follow the dates on this issue. From October
1st till today October 13 and it is not resolved!
The fact that he sent me e-mail yesterday asking more questions, told me he
*just* started to work on it after 2 weeks. This morning I replied to
him but no answer yet.... (Luckly, I have a different solution to the
problem, BUT, I want this issue to be resolved because it is the ultimate
solution.)
Thanks for listening, John.
- Ihab Mansour
XLNT San Diego, CA
( ESNUG 301 Item 4 ) --------------------------------------------- [10/98]
Subject: ( ESNUG 299 #6 300 #8) The Synopsys "Reuse Methodology Manual"
[ Editor's Note: The ">"s bellow are from Janick Bergeron of Qualis,
commenting on the "Reuse Methodology Manual" (by Kluwer Academic
Publishers). The replies are from Howard Landman of Toshiba. - John ]
Janick Bergeron writes:
> 3.2.1 Synchronous vs. Asynchronous Design Style
> The book politely says, "Anyone using or designing with latches should be
> shot." We agree. The book also fails to mention why flip-flop-based
> designs are superior for timing analysis, formal verification, testability,
> etc.
From: landmh@taec.toshiba.com (Howard Landman)
Gosh, John, I'm taping out a latch-based design at the moment. I thought it
was more like "Anyone using or designing with latches will end up WISHING
someone had shot them". :-) Actually, the situation this year is not nearly
as dismal as it was 2 years ago, but there are still problems. A quick
survey:
SYNTHESIS:
Design Compiler - handles latches OK in 1998.02-02 and later (well,
maybe 1998.02, but there were bugs, so don't use that version).
All older version give extremely poor optimization. Also, there
has been a serious issue with DC being forced to use inaccurate
FF-like "black box" timing models of blocks which actually have
latch-like behavior. This may finally be fixed, possibly, but
you need PathMill 5.2, Primetime, and DC together to find out
(there is supposedly a path from PM to STAMP to PT to db to DC).
We haven't gotten this to work yet, but we just started trying.
And if you're stuck building black box models, the timing of them
depends on the clock frequency, so you need to build a complete
separate set of timing models for every different clock period that
you want to use. (Prior to 1997.08, this was even true for some
standard library cells! Consider the enable pin on an enabled latch.)
This may mean maintaining multiple versions of timing models for
every memory, datapath, etc., and of course multiple PathMill or
HSpice runs to generate them.
Ambit BuildGates - handles latches OK, except that early versions
had some problems with generating gated clocks when synthesizing
enabled latches (didn't read the "clock: true" attribute, tsk tsk).
Latch-like gray box "IP models" seem to work OK.
VERILINT:
Will give you a warning when "a latch is inferred". But in a latch-
based design, you expect lots of these. So, it is harder to find
the if-with-no-else and case-with-no-default bugs. Also sometimes
gives false warnings in complex latch-inferring RTL. But otherwise
works pretty well.
FORMAL VERIFICATION:
Chrysalis (I'm using 2.3) handles latches OK as long as RTL and gate
match precisely. If you have a FF in your RTL and 2 latches in the
gate model (representing the actual transistors), they don't match
automatically; you have to create a guidance file for each such cell.
For comparisons that don't have this issue, latches seem to work fine.
SIMULATION:
No known problems.
TEST GENERATION:
Probably lots of problems, but we don't do it, so it doesn't bother us.
COVERAGE TOOLS:
No real problem in RTL, I think.
LAYOUT:
Most layout tools don't understand latch transparency. But, it's not
clear that this causes any serious problems. Constraints out of DC
are created for each path (from FF/latch to FF/latch), and if timing-
driven layout can meet them, we're OK. Of course, it would be nice to
trade off a speedup on one side of a latch with a slowdown on the other
side ... but eventually you get to do this in analysis.
SEXY NEW TOOLS FROM COMPANIES WHOM I CANNOT NAME:
Well, I saw a few tools I would have wanted to try out ... except that
they don't handle latches yet. So I was prevented from spending (or is
it wasting?) time and effort debugging someone's beta code. But, I
maybe also missed out on useful new functionality. Hard to weight
this category.
There are other areas of incredible pain as well. In theory, latches should
make the design less subject to clock skew problems, but in practice most tools
(including DC and BG) don't understand this correctly, so you don't actually
see any benefit until you get into the transistor timing domain (PathMill,
HSpice, etc.)
Latch enable pins require large setup times. (It's OK for enable to arrive
late, but if disable arrives late ... oops, you just latched data that you
weren't supposed to!) This causes timing problems if designers are not
expecting it.
> 3.5 Verification Strategy
> OK. Now what are the characteristics of a good verification strategy? This
> section should do more to highlight the importance of planning verification
> in the early stage of the design, and the need to change the design to meet
> the requirements for verification.
Yes. On my next project I'm going to *INSIST* on explicitly published
"design for verifiability" guidelines. Designers are like a gas expanding
into an evacuated container; they will do whatever is not explicitly forbidden.
And usually a few things that *ARE* explicitly forbidden. Must be some
kind of quantum-mechanical tunneling effect. :-) Anyway, it's easier to just
not let them do it in the first place, than to try to compress the design
methods later in the project (which creates intense pressure and heat :-).
> 5.5.5 Blocking and Nonblocking Assignments (Verilog)
> The rule states that the non-blocking assignment must be used in
> always @ (posedge clk) blocks. That is true only for regs that are to be
> inferred as FF's. The computation of intermediate values, a technique
> that often minimizes area, requires the use of the blocking assignment.
But it isn't necessary for the intermediate value calculation to be inside
the same always@ block. It's quite simple to adhere to the above rule in
practice. And RTL code which follows it gives more predictable synthesis
(and Verilint) results. So, I agree with this rule 100%. (And it also
applies to latch blocks!)
> Furthermore, the only justification for the rule is that, otherwise,
> simulation results could differ between RTL and gates. If the rule is not
> followed, race conditions will be created and results may differ between
> RTL simulation on different simulators or when using different command-line
> options.
I don't know about you, but that's a sufficient reason for me!
> 10.2.4 Meeting Timing Requirements
> Again, nothing very specific here. What makes a script robust, yet
> flexible? How do I evaluate a macro so I can be assured I will be able to
> meet timing?
Executable timing specs (timing model and constraint file) help.
> A critical chapter that falls too short. Probably the key to a successful
> reuse design methodology. Section 13.1 does not mention the creation of a
> reward system for creating reusable designs, reusing designs, or architecting
> designs so reusable components can be included.
Yes, in my experience this is the biggest problem. Most designs are under
such intense time pressure that no one in management wants to "waste" time
making the design reusable. But they always have time to waste later, when
they're struggling to reuse part of a previous design ...
- Howard A. Landman
Manager, Synthesis & Physical Design
Toshiba America Electronic Components
( ESNUG 301 Item 5 ) --------------------------------------------- [10/98]
From: ( Greg Brookshire ) gbrookshire@peracom.com
Subject: Why Does Synopsys Seem To Give Us Inconsistant Timing Reports?
Hi, John,
We are building a 500k gate chip with LSI. When we do top level timing
reports we see may clk-to-q times of more than 3ns for nets with only a
fanout of 2. We are using the "enclosed" mode for wireloading, but these
nets are contained within small blocks. When we time the enclosing block
the exact same nets have delays less than 0.5ns. (?)
Startpoint: core/atm/at_learn0/learn_fsm/sa_rd_req_reg
(rising edge-triggered flip-flop clocked by pad/clk)
Endpoint: core/ebm/reqq/flow_fifo_reg[0][2]
(rising edge-triggered flip-flop clocked by pad/clk)
Path Group: pad/clk
Path Type: max
Point Fanout Incr Path
----------------------------------------------------------------------
clock pad/clk (rise edge) 0.00 0.00
clock network delay (ideal) 0.00 0.00
core/atm/at_learn0/ln_fsm/sa_rd_req_reg/CP (FD2QC) 0.00 0.00 r
core/atm/at_learn0/ln_fsm/sa_rd_req_reg/Q (FD2QC) 3.69 3.69 f
core/atm/at_learn0/ln_fsm/sa_rd_req (net) 2 0.00 3.69 f
core/atm/at_learn0/ln_fsm/sa_rd_req (at_learning_fsm_1) 0.00 3.69 f
core/atm/at_learn0/sa_rd_req (net) 0.00 3.69 f
core/atm/at_learn0/sa_rd_req (at_learning_1) 0.00 3.69 f
core/atm/sa0_rd_req (net) 0.00 3.69 f
core/atm/mem_sched/sa0_rd_req (at_mem_sched) 0.00 3.69 f
core/atm/mem_sched/sa0_rd_req (net) 0.00 3.69 f
core/atm/mem_sched/U325/Z (N1D) 0.10 3.79 r
core/atm/mem_sched/n479 (net) 4 0.00 3.79 r
core/atm/mem_sched/U572/Z (ND2C) 0.15 3.93 f
core/atm/mem_sched/n454 (net) 2 0.00 3.93 f
core/atm/mem_sched/U374/Z (ND2B) 0.09 4.02 r
core/atm/mem_sched/n561 (net) 1 0.00 4.02 r
core/atm/mem_sched/U574/Z (ND2C) 0.15 4.17 f
core/atm/mem_sched/n467 (net) 2 0.00 4.17 f
core/atm/mem_sched/U567/Z (NR2C) 0.11 4.28 r
core/atm/mem_sched/n466 (net) 1 0.00 4.28 r
core/atm/mem_sched/U321/Z (NR2C) 0.10 4.38 f
core/atm/mem_sched/n328 (net) 1 0.00 4.38 f
core/atm/mem_sched/U378/Z (AO4C) 0.22 4.60 r
Can anyone explain the large difference in clk-to-Q times?
- Greg Brookshire
Peracom Cary, NC
( ESNUG 301 Item 6 ) --------------------------------------------- [10/98]
Subject: ( ESNUG 300 #4 ) VSS Only Supports VHDL'87; Not VHDL'93??! Huh?
> One of our customers popped up with a problem that was so outlandish I
> scarcely believed it. We delivered them a virtual component (aka "core")
> written in VHDL RTL version 1993. After a few days they came back
> and said their VSS system could not process it because *it only comprehends
> VHDL 1987*! They were given these systems on very favorable terms by
> Synopsys as an inducement to by other Synopsys software. The customer did
> not want to use a beta version of 1993 VSS that Synopsys has for the
> obvious reasons of nervousness, and they could not switch to Model Tech
> because they were too far down the road with the rest of their system in
> VSS. Is this for real? Did Synopsys really do that to them?!?!
>
> - Frederick Hinchliffe
> Technical Data Freeway Concord, MA
From: charles@efficient.com (Charles Shelor)
Yes, John,
Synopsys has refused to admit that IEEE-STD-1076 was updated in 1993. I even
have Synopsys paraphernalia from '96 with "Leader in VHDL techology". Ha!
Talk about misleading! It wasn't until this year; with the 1998.02 release;
that they support the "rising_edge" and "falling_edge" functions of the
original IEEE-STD-1164 package. That is 9 or 10 years after the standard
was approved!
Every time that I questioned/requested/demanded VHDL-93 support I received
responses such as:
o There is no feature in VHDL-93 that affects synthesis.
o You are the only user that has asked for 1993 support.
o Most of our users want faster simulation; not standards compliance.
I've even griped about lack of VHDL-93 support in this forum but didn't get
any support. Maybe I am the only user that writes test benches for VSS and
want to use the 'image attribute for printing the names of enumerated types.
I'm glad Fred wrote his letter. Now I know that there are at least two
people that find it unconsciousable that Synopsys would not be supporting a
standard that is already 5 years old.
- Charles F. Shelor
Efficient Networks Dallas, TX
---- ---- ---- ---- ---- ---- ----
From: Gregg Lahti~ <glahti@sedona.ch.intel.com>
John,
If I were in Mr. Hinchlifffe's shoes, I'd take the extra time to switch over
to Model Tech's modelsim.
I've had great success in using modelsim over using VSS. It's a much faster
tool, *much* better interface, with less language-related issues (such as
'93 and even syntax issues from '87). Modelsim also supports TCL/TK as a
built-in scripting language, which allows the user to do very complex
operations within the simulator.
The VSS interface is dismal, compile times are slow, & it's "understanding"
of the 1076 '87 LRM is horrid in a few key areas. Plus, Synopsys has no
true single-core co-simulator (VHDL/verilog) in comparison to modelsim. I
benched it last year and it still was slower in comparison to modelsim, plus
the VSS design viewer was an obvious bolt-on hack that still didn't give me
the flexibility I was able to get with modelsim. Synopsys should get a
wakeup call and fix VSS (or maybe buy a better simulator).
If I have to use a pure verilog simulator, it's VCS. If I need a VHDL
simulator or mixed language co-simulator, it's modelsim hands down.
My $.02 worth, and I am in no way affiliated with either company. I'm
just a really happy user of modelsim. ;^)
- Gregg D. Lahti
Intel
( ESNUG 301 Item 7 ) --------------------------------------------- [10/98]
Subject: ( ESNUG 300 #5 ) Experiences, New Scripts, & Benchmarks with DC'98
> Conversely, if you are running a hold check, the source clock is
> propagated with min conditions and delays, and the destination clock
> is propagated with max conditions and delays.
>
> This is almost certainly *not* what you want. So:
>
> 1. If you are using the min/max timing feature, do *not* propagate
> your clocks
>
> or
>
> 2. When you back-annotate timing and propagate your clocks, make sure
> the same values are annotated onto max and min delays. Use the
> read_timing examples I gave earlier, and use the perl script if
> necessary.
>
> I haven't tried it, but there is a hidden variable to workaround this
> problem:
>
> remove_min_max_pessimism = "true"
>
> Be sure and do an update_timing after you set this variable. See
> Solvit article Synthesis-304 for more information.
>
> - Steve Golson
> Trilobyte
From: Scott Evans <scott@NPLab.Com>
Steve,
I have used the remove_min_max_pessimism variable and it works as
advertised. In 9808, they have gone back to using only one condition at a
time, unless you specify otherwise. Also, I believe this was fixed in
PrimeTime 9802-PT2.1 as well as 9808.
- Scott Evans
NeoParadigm Labs San Jose, CA
---- ---- ---- ---- ---- ---- ----
From: sgolson@trilobyte.com (Steve Golson)
Scott,
If you have separate min and max delays back-annotated, does it use
propagated max delays for *both* the start and end clocks when doing
setup checks?
I think they may do max delays for the start clock, and min delays for
the end clock. This is not what I want.
- Steve Golson
Trilobyte
---- ---- ---- ---- ---- ---- ----
From: Scott Evans <scott@NPLab.Com>
Steve,
From what I have seen, it uses either min or max depending on what you are
reporting on (setup or hold) and does not mix them when you use that
variable. The tool keeps both sets of numbers in the data structures to
calculate whichever is needed.
- Scott Evans
NeoParadigm Labs San Jose, CA
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
From: ryan@dogbert.fsd.com (Ken Ryan)
Hi, John,
I would like to express my sincere appreciation to Steve Golson for his very
informative posting (especially his perl script). I have two designs which I
am working on re-characterizing from SDF files made under revised conditions.
I recently "upgraded" to DC'98, and since my scripts ran with no errors or
warnings I thought nothing of it. It turns out Steve's heads-up saved me a
lot of head-scratching (and possibly in-system failures) later on.
Thank you, Steve, for your time in putting together such a useful message
(and to you, John, for bringing it to me on ESNUG)!
- Ken Ryan
Orbital Sciences Corp. / Fairchild Defense Germantown, MD
( ESNUG 301 Item 8 ) --------------------------------------------- [10/98]
Subject: ( ESNUG 300 #2 ) How To Handle Hierarchical Capacitance Problems?
> I was just wondering if you could answer a quick question for me. I'm
> having problems with violating capacitance constraints on nets in my
> hierarchical design. Performing
>
> report_constraint -max_capacitance -all_violators
>
> gives a number of violators, some I have resolved by doing set_load
> on those ports ... others just won't budge whatever I do. I've tried
> characterizing and re-reporting, characterizing and re-synthing but nothing
> works. Can you tell me what the recommended procedure is to resolve these
> types of violations ????
>
> - Gary Cook
> Sony Broadcast
From: Gary Cook <gc@adv.sonybpe.com>
John,
To further the solution to this problem I've discovered that my output
buffer type is being changed but is still not enough because my bus
(address bus) has a high fanout. (What I need to do then is to get Design
Compiler to insert buffers on the inputs of the sub-designs that the address
bus is connected to.)
I can't seem to be able to get Design Compiler to do this though ... tried
setting the load, capacitance, drive etc. on the input port but it doesn't
insert the required buffer.... any ideas???
- Gary Cook
Sony Broadcast
---- ---- ---- ---- ---- ---- ----
From: "Tom Harrington" <tharring@ford.com>
Have you tried using set_fanout_load and set_max_fanout, to get the total
fanout under control?
- Tom Harrington
Ford Microelectronics Colorado Springs, CO
---- ---- ---- ---- ---- ---- ----
From: Oren Rubinstein <oren@gigapixel.com>
Hi John,
As you know, every now and then my fingers itch and I have to answer one of
these questions. Concerning "What's The Technique To Handle Hierarchical
Capacitance Problems?" Try:
children = find(design, {*}, -hier)
set_max_transition 1.0 children + current_design
remove_attribute children dont_touch /* Just in case you have any */
compile -only_design_rule
And congratulations for the 300th posting of ESNUG! Over the years, you've
done a great job of keeping us all informed.
- Oren Rubinstein
GigaPixel Corp. Santa Clara, CA
( ESNUG 301 Item 9 ) --------------------------------------------- [10/98]
Subject: Race Conditions That Cause VCS To Differ From Cadence Verilog-XL
> OK, I don't think anyone has addressed the concerns of our original
> posting, so I'm going to restate the questions. If you have responses
> based on the details of the IEEE spec, those would be more helpful than
> other responses. BTW, FWIW, one of the posters has been using Verilog
> successfully since 1989; the other since 1994. I'm not trying to say I'm
> a Verilog expert, but I *thought* I understood how to reliably model
> hardware using Verilog. Also, *lots* of designers/verifiers I've talked
> to think this is a VCS bug (I'm not sure at this point).
>
> First, the (abstracted) code that produced the original problem:
>
> assign a = (b!=0);
>
> always @(a or d)
> begin
> if (a)
> c = d;
> else
> c = ~d;
> b = d + 1;
> ...... // Zero or more statements
> end
>
> I made "a" a wire to get rid of a stupid warning from Verilint, a warning
> I will turn off in the future. I generally expect to inline the
> computation of "a" in these cases in the future, as some have suggested.
>
> Having said that, I expected the code to work. Why? Because I expected
> the always block to fire twice, once to update "c" and "b" (because of "d"
> changing), and again to update "c" (because of "a" changing, since "b"
> changed). When I saw VCS *not* refire the always block a couple of weeks
> ago, it was the first time I had to consider abandoning/restricting my
> coding style since I started using Verilog; the above general style has
> always worked.
>
> - John Andrews
> Silicon Graphics Mountain View, CA
From: Ramesh Narayanaswamy <nramesh@ganesh-systems.com>
Strictly going by what is listed here there is a scenario where the
always block will fire only once:
1. 'b' starts as X, so 'a' would go from X to 1
2. the always block fires because 'a' changed
3. 'b' would go from X to a "non zero" value due to "d + 1"
4. the continuous assignment fires because 'b' changed
5. 'a' does not change because ' "non zero" != 0 ' is still 1.
perhaps i am missing other context from your earlier posts ?
- Ramesh Narayanaswamy
Ganesh Systems
---- ---- ---- ---- ---- ---- ----
From: jandrews@windsurfer.engr.sgi.com (John Andrews)
Yea, I should have said I expect the block to fire twice if 'a' changes.
- John Andrews
Silicon Graphics Mountain View, CA
---- ---- ---- ---- ---- ---- ----
From: Ashutosh Varma <ashu@axiscorp.com>
Some basic facts about Verilog-
always@(a or b)
begin
// your code
end
is semantically equivalent to:
always
begin
@(a or b);
// your code
end
This means that having always@(a or b) does not make the always block
*always* sensitive to changes to a or b.
This means that always block will trigger on a or b only when it is
*waiting* on the @(a or b) statement. In other words, if the always
block is already entered and is executing procedurally, it is *NO*
longer sensitive to changes to a or b.
This means that always block execution has to finish executing to its "end"
statement before it is ready to accept changes on its sensitivity list (or
to enter its "begin" code again, if you take the second example above).
Now, the next major point-
assign a = (b != 0);
always @(a or d)
begin
if (a)
c = d;
else
c = ~d;
b = d + 1;
...... // Zero or more statements
end
In case of zero delay assignments, Verilog simulators are at liberty to
propagate the change. There is *NO* such thing as delta delay in
Verilog, unless you use the explicit #0 delta delay in assignments.
Therefore, in the above example, the simulators can choose to propagate
b=d+1 assignment *immediately" to the assign statement AND since the
assign is also zero delay, they can choose to update a also immediately.
If that happens, then your always block will not kick off again because
it has not yet gone back to @(a or d) statement.
This is coding style is bad and is prone to different behavior in
different simulators. If you have been using a simulator for many years
and change simulator and find that code doesn't work, you cannot always
blame the simulator.
- Ashutosh Varma
Axis Systems Sunnyvale, CA
---- ---- ---- ---- ---- ---- ----
From: Chris Spear <spear@viewlogic.com>
Basically you have a race condition between the assign statement and the
always block. In Verilog-XL, if you change a signal which is on the
sensitivity list of a statement (like your assign a=b...), XL will schedule
that statement to be executed after the always block finishes. VCS reduces
scheduling overhead by immediately executing the assign statement when b
changes, then goes back to the always block. Both execution styles are
perfectly legal according to the IEEE spec. Just because XL did it one way
first, does not make it more or less correct than any other simulator.
One way to resolve this would be to put a delay in the assignment to b,
usually with a non-blocking assignment statement, <= This causes the
Verilog simulator to behave more like VHDL, with a delta cycle for
inter-block propagation. It also makes most Verilog simulators run slower
(hint, hint!).
I am a very biased observer, having sold XL for 5 years and VCS for 3.
- Chris Spear
VCS Applications Consultant
Synopsys Marlboro, MA
( ESNUG 301 Item 10 ) -------------------------------------------- [10/98]
From: "Paul.Zimmer" <paul.zimmer@cerent.com>
Subject: Does Anyone, Anywhere Have An "ied" That Runs On SUN Workstations?
John,
Several years ago (through the wonders of ESNUG), I was introduced to a
very handy little program called "ied". ied sits between you and any
stdin/stdout program, and provides ksh-like command line history and editing.
It works on most everything, including ftp, and (ta-da!) dc_shell.
Well, I changed jobs from an all-HP shop (HP) to an all-SUN shop (Cerent),
and discovered, to my horror, that ied doesn't seem to exist on SUN.
So much for, "everything runs on SUN".
I've tried the Solaris news group, but without success. I thought that,
since I heard about ied on esnug originally, and since many ESNUG'ers
are probably multi-platform, perhaps someone in the esnug community
can point me at an ied equivalent for SUN (or LINUX - since then I might
be able to get the source code and compile it on SUN!).
I know many emacs users use emacs to do everything but pour their coffee,
so maybe emacs can do this? Being a vim kinda guy, I'd rather not
learn emacs, but re-typing (or mouse cut/paste) lines in dc_shell
is getting REALLY annoying.
Yes, I know about dc_shell's Csh-like history, and that would be the
cat's pajamas if this were 1978, but my expectations are somewhat higher
than that. I don't want to just recall a line, I want to EDIT the silly
thing!
- Paul Zimmer
Cerent Corporation
|
|
