This week, as a hardware designer, I got to see some professionally
depressing news: Thinking Machines is filing Chapter 11 - bankruptcy.
There's the usual rash of executive defections, investor lawsuits and
general badmouthing by industry columnists going on when a high tech
company fails. This didn't surprize me. What bothered me was that this
was a company based on a unique hardware design philosophy -- one of
connecting thousands of processors to make a computer instead of trying
eke out more horsepower from one processor (like what everyone else was
doing.) Although I don't want to go into a discussion on which design
philosophy is better -- I want to note that it's these unique approaches
to design problems that cause the real breakthroughs in technology. What
I fear is the paranoid "let's do it the safe way" mentality that
beancounters, investors & narrow minded engineering managers like to cite
in situations like this. Taking well thought out risks is what
diferentiates temporarily successful businessmen & engineers from the ones
who are wildly successful. And fear of taking risks is one sure way any
company can eventually fall to its competitors.
- John Cooley
the ESNUG guy
( ESNUG 193 Item 1 ) ---------------------------------------------- [8/94]
Subject: (ESNUG 192 #5) Can Synopsys Fix Hold Time Violations?
>We have been having a very difficult time getting Synopsys to properly fix
>hold time violations. "set_fix_hold" currently seems to be a poor
>implementation. Here are some of the reasons why:
>
> 1. It does not insert delay based upon best case conditions, where hold time
> violations can be the worst - it uses whatever operating conditions are
> set at the time. If your default is worst case, hold time will NOT be
> fixed under best case conditions. Synopsys needs to time using both
> best case and worst case conditions in order to correctly fix design
> rule violations.
---- ---- ---- ----
From: Oren Rubinstein <oren@waterloo.hp.com>
Hello John,
I have been using the set_fix_hold command for a while, successfully.
Its use is much easier now, after Synopsys fixed one major problem that they
had in earlier versions (see ESNUG Post 125, item 1).
The above complaint is true, but there is a way around it. If you use the
set_timing_ranges command, Synopsys can take into account both worst AND
best case.
The only problem with this is that one of the cases is scaled by a constant,
instead of having accurate numbers, but if you make your scaling factor
a little pessimistic you can be sure that it will fix the hold times.
> 2. It often inserts delay into the path in such a way that can affect a
> completely different critical path, possibly making the worst path worse!
> Synopsys needs to intelligently insert the delay element, impossible
> since it fixes design rule violations at the end, without regard for the
> original timing constraints.
Not true. If you use the set_timing_ranges command, Synopsys is aware of
both cases. Combined with set_fix_hold, it will add delay where needed,
as much as it can without breaking the worst case paths, unless you use the
compile -prioritize_min_paths variation.
> 3. It inserts delay haphazardly in paths that cross module boundaries,
> unless you always do top-down compiles - rarely feasible!
Check your constraints. By definition, set_fix_hold tries to fix hold time
violations. If it does it for the design outputs, it must think it has a
violation there, and how would it know unless you told it ?
- Oren Rubinstein
Hewlett-Packard (Canada) Ltd.
---- ---- ---- ----
From: Lee Bradshaw <bradshaw@hprnd.rose.hp.com>
>1. It does not insert delay based upon best case conditions, where hold time
> violations can be the worst - it uses whatever operating conditions are
> set at the time. If your default is worst case, hold time will NOT be
> fixed under best case conditions. Synopsys needs to time using both
> best case and worst case conditions in order to correctly fix design
> rule violations.
It's been a while since I've done this, but the way around the problem
is to use set_timing_ranges with set_operating_conditions:
set_operating_conditions wc
set_timing_ranges {wc_2_wc wc_2_bc}
These are how the timing ranges would need to be defined in the library.
Remember you can do this without Library Compiler:
timing_range("wc_2_wc") {
faster_factor : 1.0
slower_factor : 1.0
}
timing_range("wc_2_bc") {
faster_factor : 0.30
slower_factor : 0.30
}
Of course you could use them as standard timing ranges at the same time:
timing_range("wc_2_wc") {
faster_factor : 1.0
slower_factor : 0.96
}
With this procedure, the timing ranges are used to simulate different
operating conditions. The range wc_2_wc scales by 1.0 and leaves
everything at worst case, while the range wc_2_bc scales all delays to
best case and should fix the hold problems at best case.
You might want to compile without the ranges, and generate the reports
with the ranges. If there are errors go back and recompile. [Adding
timing ranges doesn't help your compile times :^) ]
This process worked and was needed on a project using Synopsys 1.2.
There was a bug in 3.0c (well, synopsys didn't scale the clock network
just as the new manuals stated) which made this unusable for me. 5ns
delays to the clock pin at worst case became 5ns delays to the clock pin
at best case. Guess how many false hold problems were seen. STAR
17165 was filed and the problem was supposed to be fixed in 3.1a, but I
haven't checked it. You might want to check the timing reports
carefully the first few times to make sure you are getting what you
expect.
- Lee Bradshaw
Hewlett-Packard, Rosemont
---- ---- ---- ----
From: KEVIN.C@AppleLink.Apple.COM (Christiansen, Kevin)
>We have been having a very difficult time getting Synopsys to properly fix
>hold time violations. "set_fix_hold" currently seems to be a poor
>implementation.
There is an even more fundamental problem which causes me to NEVER ask Design
Compiler to fix hold time violations:
When DC inserts gates to fix hold violations the delays which are calculated
are based on the statistical wire-load model being used. However, the layout
tool is going to do its best to minimize the interconnect between the gates.
It will most likely be very successful in doing this. Thus, the actual delay
will be considerably less than DC's estimate, and hold violations will still
appear in the post-route analysis. To make matters worse, I usually see DC
insert simple inverters to create the delays. These tend to have very little
intrinsic delay, and fairly weak outputs, resulting in higher estimated
interconnect delay.
To do a good job of fixing hold time violations, DC would need to:
1) Ignore interconnect delay when calculating how many gates to insert in
the path.
2) Use gates which have a high ratio of intrinsic delay to interconnect
delay. (Ideally, ASIC vendors would provide a cell expressly for this
purpose.)
3) It should consider both min and max operating conditions.
I have pointed this out to both Synopsys and our ASIC vendors, but I also
get the impression that it will not be addressed soon.
So, for me, the answer is to try to avoid potential hold time violations in
the design by keeping the clocks squeaky clean. When necessary (e.g. to meet
PCI's 0 ns. hold specs) I instantiate cells which provide the necessary
delay through their instrinsic delay plus the pin loading, then I do both
min and max timing analysis runs to ensure that there are no hold or setup
violations.
- Kevin Christiansen
Apple Computer
( ESNUG 193 Item 2 ) ---------------------------------------------- [8/94]
From: "michael (m.m.y.) hui" <myhui@bnr.ca>
Subject: (ESNUG 191 #2) "Anyone Using The Synopsys Static Timing Analyzer?"
Watch out for the following flags. Setting them wrong could definitely
result in Design Time reaching the wrong conclusion. With T.I.'s CAD
tools in their TGB2000 ASIC methodology, we use the following settings,
which happen to be the defaults chosen by Synopsys:
read_cell_transition "true"
read_net_transition "false"
Since the SDF file contains best, nominal, and worst case numbers,
be sure to set the following flags appropriately before reading in
the file. The filtering action is done *while* the file is read in.
If you want worst case delays, set the flags as follows:
sdfin_fall_cell_delay_type "maximum"
sdfin_fall_net_delay_type "maximum"
sdfin_rise_cell_delay_type "maximum"
sdfin_rise_net_delay_type "maximum"
- Michael Hui
BNR
( ESNUG 193 Item 3 ) ---------------------------------------------- [8/94]
From: anand@lsil.com (Vijayanand Ponukumati)
Subject: Question for Verilog & VHDL Synthesis Buffs.
John:
While translating a piece of Verilog code into VHDL, I stumbled across
the following variant of a "case" statement
case ( 1'b1 ) // synopsys full_case parallel_case
x[0] : temp = y[0];
x[1] : temp = y[1];
x[2] : temp = y[2];
default : temp = 1'b0;
endcase
Synopsys interprets the comments parallel_case and generates a mux type logic
for this, evaluating all the expressions x[1]=='1' x[2]=='1' and x[0]=='1'
in parallel. This generates a very fast design. However, I was unable to
translate this case statement into equivalent VHDL code (any construct), that
would give me the same sort of logic. Any ideas anyone?
- Vijayanand Ponukumati, Software R&D Group
LSI Logic Corp.
( ESNUG 193 Item 4 ) ---------------------------------------------- [8/94]
From: don@westford.ccur.com (Don Monroe)
Subject: Interpreting Overlapping Verilog Casex Sectors
Does Design Compiler define how they implement overlapping selectors in a
Verilog "casex" statement? For example:
casex(var)
3'b1xx: action1;
3'bx1x: action2;
3'bxx1: action3;
3'b000: action4;
endcase
This is the syntax one would like to use for a one-hot state machine. Does
Synopsys ALWAYS generate the correct logic? If so, where is it documented?
- Don Monroe
Concurrent Computer Corp.
( ESNUG 193 Item 5 ) ---------------------------------------------- [8/94]
From: fredt@amcc.com (Fred Tarverdians)
Subject: How To Encrypt VHDL?
Hello John,
Interested to know if you or any other Synopsys users know how to encript
a VHDL code. We are chip makers, and a few of our customers have been asking
us to provide them with the VHDL models of our chips. They want to run
system simulations on their entire design, that is coded in VHDL. Obviuosly,
we don't want to distibute our proprietery VHDL codes in a read-able format.
I know that Synopsys 3.1 supports three simulation engines: Behavioral,
Compiled, and gate level. Does the "Compiled" VHDL give us the protection
that we need?
- Fred Tarverdians
AMCC
|
|
