From: Brian Fuller <bfuller@cmp.com>
Dear John,
After viewing your DeepChip website today, I see that you (again) scooped
my guys, Goering and Santarini, with that Synopsys conspiracy story.
You're showing some top-notch investigative reporting there. I hope to
see you at DAC in 2 weeks with your meds correctly adjusted by then.
- Brian Fuller, Executive News Editor
EE Times & EETimes.com
( ESNUG 353 Subjects ) ------------------------------------------- [5/24/00]
Item 1 : ( ESNUG 343 #1 344 #7 ) More On The "set_dont_touch_network" Bug
Item 2 : ( ESNUG 352 #1 ) Handling Scan Test Issues With Ultima ClockWise
Item 3 : Cliff Cummings Disagrees With Goering Over C-Based Hardware Design
Item 4 : ( ESNUG 350 #6 ) DC Synthesizing To Fewer, Bigger, Richer Cells?
Item 5 : Techie Physical Design Talk Overheard On The Yahoo CDN Chat Board
Item 6 : ( ESNUG 348 #5 ) SDF & `resetall & `uselib & VCS & Verilog-XL
Item 7 : Unhappy Newbie Struggling With Escalade DesignBook Learning Curve
Item 8 : Books, Papers, URL's On Fault-Tolerant System Design Strategies
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 353 Item 1 ) --------------------------------------------- [5/24/00]
Subject: ( ESNUG 343 #1 344 #7 ) More On The "set_dont_touch_network" Bug
> The following is from the Synopsys Support Center on logid 100418:
>
> The problem with set_dont_touch_network not working correctly in 99.10
> has been recently reported. The STAR number for your reference is
> 95299. Here are the 2 possible Workarounds for the problem.
>
> Workaround #1
>
> Do NOT specify set_dont_touch_network at all. Starting with DC 99.05,
> DC will infer the clock net as ideal. By default, Design Compiler
> treats all clock networks as ideal nets. Ideal nets are networks of
> nets that are free from max_capacitance and max_fanout design rule
> constraints. (For more info see command set_ideal_net)
>
> No buffers are added on the clock network.
>
> As a Side Note: ideal_net attribute by default does not propagate through
> gating logic. So if you had a gated clock, you would have to explicitly
> set the ideal_net attribute at the output of the gate.
>
> Workaround #2
>
> There is another workaround provided by the R&D team. You can keep the
> set_dont_touch_network in your script and set:
>
> compile_map_for_delay = true
>
> This is a hidden variable, so use it with caution.
>
> I chose Workaround #1, since I am phobic of hidden variables that have no
> documentation in SOLD. I noticed a new Solvit aritcle that says to use
> Workaround #1, but doesn't mention the hidden variable.
>
> I'm told they have fixed this bug in 1999.10-5 plus Star 95299 and 93201.
> I have not been able to confirm this since our DesignWare libraries go
> toes up with this release.
>
> - Kayla Klingman
> Tektronix, Inc. Somewhere, Oregon
From: Robert Wiegand <rwiegand@nxtwavecomm.com>
Hi John,
I have a few tidbits to add about the set_dont_touch_network bug. On a
recent design, I was running with workaround #2, and found a particular
module that wound up with a buffered clock tree. I decided to bite the
bullet and variablize my scripts to exclude the set_dont_touch_network on
clocks when using version 99.05 or newer, effectively implementing solution
#1. I removed solution #2. This change fixed the problem with that module.
HOWEVER, another module which had previously compiled successfully with
solution #2, now had a buffered clock tree! Huh? So I put solution #2
back, and kept solution #1 as well. NOW, all my clock buffering problems
were fixed.
If the intent is to bag the usage of set_dont_touch_network for clocks in
favor of the ideal_net attribute, I'm not happy about it. As Kayla explains
in her side note about solution #1, ideal_net wont propagate through clock
gating elements. You have to explicitly set the ideal_net downstream of any
clock gating logic.
I found another limitation of the ideal net attribute on a recent very large
COT project I was involved in. As of the 9905-2 version, ideal_net makes
max_capacitance and max_fanout violations go away, but not max_transition.
Without a special cell to drive the high fanout clock net,
set_clock_transition must be used to overcome the max_transition violation.
Same as it ever was. The problem is that this command only works on clocks.
What about internal resets, scan enables, and other high fanout nets that
could also be taken care of in layout tools. I have self-buffered scan
enables and resets in the past, or had the benefit of a library macro to
drive the high fanout nets. Here, the desire was to let the layout tools
deal with the high fanout nets, but a driver macro cell was not available
do to schedule pressure, etc. The ideal net command won't overcome the
max_transition problem, especially when thers signals are driven from
internal gates. In order to run compile -top to fix other things, these
bogus problems have to be out of the way. I tried set_load 0 on the high
fanout net, but that doesn't overcome the load of all the input pins
attached to the net, so the transition time is still outrageous. In order
to get around the problem, I had to get ugly and resort to "scratch and
sniff" techniques. I created a bogus input port, disconnected the high
fanout net from it's source, and connected it to the new bogus port. I
could then set_drive 0 on the bogus port and eliminate the transition time
problem. After performing the compile -top, I had to restore the original
connections and clean up the mess. Here's a script example:
create_port bogus_test_se -direction in
disconnect_net test_se clkmux/test_se
connect_net test_se find(port,bogus_test_se)
set_drive 0 find(port,bogus_test_se)
set_resistance 0 find(net,test_se)
set_dont_touch_network find(port,bogus_test_se)
set_dont_touch clkmux/U38
compile -top
disconnect_net test_se find(port,bogus_test_se)
all_connected find(pin,clkmux/test_se)
if (dc_shell_status) {
temp_net = dc_shell_status
disconnect_net temp_net find(pin,clkmux/test_se)
remove_net temp_net
}
connect_net test_se find(pin,clkmux/test_se)
I had to set_dont_touch on the cell that drives the net to prevent it from
being optimized away(I was using compile_top_all_paths = true, I wanted to
be sure), but somehow a net was attached to the output pin of clkmux where I
disconnected the test_se net. I had to remove this bogus net before I could
re-attach the test_se. There must be a better way, anyone?
- Rob Wiegand
NxtWave Communications Langhorne, PA
( ESNUG 353 Item 2 ) --------------------------------------------- [5/24/00]
Subject: ( ESNUG 352 #1 ) Handling Scan Test Issues With Ultima ClockWise
> I recently taped out a design on which I inserted clock trees using the
> Ultima ClockWise tool and really liked it. In the past I have used
> intentional skew in special situations to help improve timing, but it was
> difficult time consuming hand work...
>
> - Jon Stahl, Principal Engineer
> Avici Systems N. Billerica, MA
From: Tim Dunnington <Tim.Dunnington@motorola.com>
Hi, John,
I found Jon Stahl's discussion of Ultima ClockWise in ESNUG 352 #1 to be
the best I have seen yet. I have some questions about how this relates to
scan testing though. Did he insert the clock trees before adding scan
logic or after? I have to assume the useful skew for functional mode is
not useful for scan testing. Did he then go back in the netlist to add
delays to the scan paths to fix hold time problems?
- Tim Dunnington
Motorola SPS Chicago, IL
---- ---- ---- ---- ---- ---- ----
From: Jon Stahl <jstahl@avici.com>
Hi John,
We have a slightly involved methodology for scan related issues.
Our ASIC vendor LSI has "enhanced scan hold" flop equivalents for most of
the flops in thier library. These have scan data in port hold times of up
to -700 ps (nominal) at the cost of a little extra area. We limit
synthesis to the subset of flops that have these equivalents.
Post-synthesis we transform all flops into thier enhanced scan hold
equivalents, perform placement, and re-stitch the scan chain using nearest
neighbor flops. This will give you the minimum routing impact for scan
but is guaranteed to create some hold problems even with the enhanced flops.
At this point we do timing analysis, functional and test modes, and start
work on automated/manual ECO's to meet placed timing.
And here is where I am a little unclear as to the best course of action when
ClockWise is brought into the picture. On my latest design I just did the
automated upsizing/buffering that my tools were capable of, which brought me
to -1.2 ns of slack worst path. In the past, assuming that the number of
violations were reasonable to the degree that I could see an end in sight,
I would have worked at manual ECO's and placement alterations to fix them.
Or gone back to synthesis (or arrgh ... RTL) and iterated.
This time I just let ClockWise rip, and was happy to see it get rid of ~90%
of the setup violations. This will of course not always be the case. But
anyway, a *little* bit of post-clock insertion work got me all the way to
placed timing. This included adding in the necessary delay cells to fix
scan hold problems, something which we have automated (a PrimeTime script
spits out a set of commands for another tool to add the delay cells in the
appropriate spot.)
I should note that our telecom designs are mostly I/O limited in die size
and medium volume in any case (i.e. I feel that it is more than worth it to
burn the area for the enhanced hold flops and delay cells in order to
improve time to market.) This might not be acceptable to others, and it
might be hard to merge in the necessary delay cells on really dense designs.
I (what the hell) ran ClockWise using only worst case libraries (it can take
best/worst and do both analyses) to have it focus on setup and ignore holds
which I fixed with delay cells later. If I hadn't, it would have looked at
the best case scan arcs and been forced to build a tree so as not to violate
them. This would have impaired it's ability to fix setup's, hold being
it's dominating constraint.
- Jon Stahl, Principal Engineer
Avici Systems N. Billerica, MA
( ESNUG 353 Item 3 ) --------------------------------------------- [5/24/00]
Subject: Cliff Cummings Disagrees With Goering Over C-Based Hardware Design
> From: Richard Goering <rgoering@cmp.com>
>
> In the interests of stirring up a little controversy, I would like to
> briefly state three reasons why hardware designers might be drawn to
> C/C++ language design.
>
> 1) System-on-chip complexity forces a higher level of abstraction.
> RTL is too low for multi-million gate chips.
From: Cliff Cummings <cliffc@sunburst-design.com>
Wrong! RTL with a few instantiated cores works great for multi-million
gates chips. Many of those gates are instantiated cores and memories.
Other gates take the form of 64-bit registers instead of 16-bit registers,
where the only difference in the RTL code is the declaration size of the
variables, the rest of the code remains unchanged. Early abstraction will
not speed up the gate-level simulations at all!
> 2) Increasing percentage of system functionality is in embedded
> software. Hardware and software designers should speak the
> same language, and the software guys speak C/C++.
Concerning hardware and software engineers speaking the same language, will
that help? No!
Software: print ("hello, world!");
Hardware (the C-equivalent of): @(posedge clk) q <= d;
Does not simulate together nor synthesize to anything I am interested in!
Software writers create algorithms that compile to bit patterns that are
loaded into memories that are read and executed by hardware processors.
Asking hardware and software writers to use the same language will not
increase productivity any more than asking hardware and software writers to
do their jobs on the same PCs. Software languages and PCs are tools, not
magic!
The next step: are we going to ask the board-layout people to start
designing all circuit boards using C++? Maybe then we can simulate the
cross-talk effects of our early architectural explorations!! ;-)
> 3) A growing number of systems designers may not even know or care
> if the functionality they're describing will be in hardware or
> software. C is the easiest starting point.
C-language is useful in some applications (such as DSP) for early
architectural exploration. The big problem with architectural modeling is
that testbenches are not reusable on RTL and gate-level versions of the
same design. Verilog has had architectural and queuing system tasks for at
least ten years but almost nobody uses them. Why? Because and testbench
you write for an architectural model is useless at the RTL or gate-level.
Architectural modeling proves a concept but does not advance the generation
of RTL and gate-level verification.
When coding for synthesis you have got to "think hardware" (thanks to Jim
Lewis for the quoted motto). When Verilog engineers code algorithms and the
say "I wonder what this is going to be!!" you know you are in trouble!! You
better have a block diagram when you start coding the RTL.
> I think the movement to C/C++ will be gradual, but will eventually happen.
I believe C/C++ exploration will have a niche but will not be the
mainstream. Reminds me of the Behavioral Compiler (BC) craze a few years
ago. Everything was going to be done with BC. BC also has an important
niche, but is far from the mainstream. Synopsys' SystemC in-part seems to
be the reincarnation of BC.
- Cliff Cummings
Sunburst Design, Inc. Beaverton, OR
( ESNUG 353 Item 4 ) --------------------------------------------- [5/24/00]
Subject: ( ESNUG 350 #6 ) DC Synthesizing To Fewer, Bigger, Richer Cells?
> I was wondering how I could use that 23 percent white space for a few
> bigger, richer cells (e.g. AND-OR-INV) and reduce the wiring overhead. My
> idea is while the cell area increases, the routing overhead decreases,
> and the overall design area should shrink (wishful thinking?)... We tried
> editing the .lib file to increase the wire area in wireload model. The
> idea being that each wire now should have an "area penalty" associated.
>
> wire_load ("my_wire_load") {
> resistance : 0.000083 ;
> capacitance : 0.000116858 ;
> area : was: 1.319252 is: 5.319252; <== but didn't help a lot
> (0.3% less nets)
> slope : 101.342461 ;
> fanout_length (1, 149.84) ;
> ... more entries here ...
> }
>
> To me it seems that this number is primarily used for the report_area
> output but for nothing else. Correct?
>
> We were also thinking about making nets artificially longer, so that each
> wire has a timing-penalty associated (I have no synth results yet) but I'm
> somehow not convinced that that's a good strategy. Any suggestions?
>
> - Christian Bohm
> Analog Devices B.V. Somewhere, Europe
From: [ One Of The 47 Ronin ]
Please keep me anon.
About 6 years ago, I investigated the effect of "wire area" attribute. At
that time we were using 0.5 um process technology and 3 layer routing was
popular. Now most are using 0.18 um technology and 4+ layer interconnect
is common. So I'm not sure this is still valuable, but we are still using
the same data though...
- If you assign reasonable or realistic values for wire area, there
is no influence on the synthesis result.
- Assign bigger value for wire area, the synthesis result is
1) 10% less net number
2) 5% gate count increase
3) 3% less layout size
This shows us that even the gate size is increased, the net number is
decreased, eventually the cell utilization is increased and final layout
size is smaller than the result with "no wire area". Again my evaluation
data is very old, DC has many update and enhancement, but he is using 3
layer metal, so this info may be useful to him.
I also investigated the DC "porosity" attribute at the same time. But I was
not able to find the effective result from them. If someone has recent
evaluation result, I would also like to see it.
- [ One Of The 47 Ronin ]
( ESNUG 353 Item 5 ) --------------------------------------------- [5/24/00]
Subject: Techie Physical Design Talk Overheard On The Yahoo CDN Chat Board
[ Editor's Note: Usually the Yahoo EDA stock chat boards are a sea of
anonymous letters from people pushing very obvious agendas to get a
specific stock price to change in their favor. But sometimes even a
broken clock is right twice a day. Enclosed below is a very rare
meaty tech conversation that I saw yesterday in the Yahoo CDN chat
board on the current issues around physical design tools. - John ]
From: [ Tall Thin Dude ]
I have to agree with [ EDA Veteran ] in terms of the longer term potential
for physical/logical tools.
The potential strength of Cadence or other full RTL2GDS solutions in this
area is much better than Synopsys.
Synopsys real problem is they have never been able to make any headway in
the physical backend and are instead piggybacking on Avanti for the real
block based P&R. Sure they bought a top level bus router with Everest, and
a firesale of the Gambit remains, but still no story on block designs.
When we get into dealing with real problems in the future like Signal
Integrity having a common infrastructure between frontend and backend will
allow some vendors to pace themselves laps ahead. I am involved in some
very high speed designs and the designers are panicked about being able to
control noise in 0.18 at about 400 MHZ. For future process noise, noise,
and noise, will be one of the biggest challenges.
Another key area is in achieving concurrent timing/noise closure. While we
hear stories of success in correlation between the Synopsys frontend and
backend Avanti tools the bottom line is different estimation, timing, and
routing engines never will correlate unless they are the same piece of
code. Sure we will hear of the few cases where it was "close enough".
Trust me on this one _your_ design will not be one of them.
While Cadence still has numerous timing engines (despite their vapor claims
of a common timing engine), at least the products are owned by the same
company and attempt to share some pieces of code.
Concerning all these stories about IC Craftsman and FlexRoute being the next
generation tools for hierarchical designs, I think these tools are not going
to even be players. The key issues with these tools are multiple.
One key issue (and perhaps the biggest) is the impact on Signal Integrity.
Bus routes are a nightmare from a Signal Integrity perspective and offer
little in the way of repeater insertion methodology. In terms of the noise
issue, the companies try to sell the idea that for most busses matching
characteristics are desired. In most cases a random routing as obtained by
SE is much better in terms of noise. Repeater insertion is also easier in
a random route approach.
Another key problem is that both these solutions lack true timing/noise
engine hooks and are standalone tools. They have their own db and all
constraints are pre-translated to physical constraints rather than being
able to look at timing/noise on the fly. Also has anybody out there tried
using SE & IC Craftsman together? It seems to me IC Craftsman integrates
with Opus, but on the SE side they seem to be lacking synergy. Don't know
that much about the FlexRoute but it still seems to be a mostly physical
constraint based stand alone tool.
I plan on using my current Cadence SE/DP solution. I still hope Cadence
gets their act together in getting a PKS/DP/SE flow working soon but
somehow I have a feeling it will not be soon!!
- [ Tall Thin Dude ]
---- ---- ---- ---- ---- ---- ----
From: [ nilgiri94 ]
Your concern about how signal integrity is crucial when the operating speeds
go up is well taken. I often hear people working at the back-end dismiss
any front-end physical tools which do not have a proper router or do not
take into consideration detailed physical information. Coming from the
front-end side, I find this "summary dismissal", amusing. The purpose of a
physically sensitive front end tool is to provide a better starting point
for the back-end tool; any tool which tries much more than that is offering
a solution which most front-end designers are not trained to use; and hence
will not use unless it becomes a bread and butter question.
More so, the value of a front-end tool which is "highly consicious" of the
back-end decisions, IMHO, not clearly proven. I understand why signal
integrity, cross-talk, noise considerations are important; what I do not
understand is what front-end tool needs to do to tackle this problems.
Present generation of physical front-end tools do some estimates of
congestion, top-level detailed routing etc. to get a picture of physical
design to guide them. That is an attempt to distill out enough information
to permit a hand-off to the back-end tools which is much more likely to
converge. The other option is to actually go into detailed physical desing
issues during front-end design itself. IMHO that is an overkill: the
complexity of the tool goes up exponentially, the run-time and capacity of
the tool is severly degraded; plus there is not enough evidence that it is
better to spend so much time on the integrated flow rather than go through
a few iterations of the FrontEnd plus BackEnd flow in the same time. The
last point is significant because in the real-world it rare to get a design
absolutely right the first time; iterative refinement is the norm rather
than the exception. In the present flow iterations were being driven by
timing closure; but there are a host of other considerations which drive
iterations (test, power, Clock Tree skew issue, reliability, cross-talk,
etc.) True, a truly integrated front-end plus back-end may eliminate some
of the causes; but I very much doubt if it can eliminate iterations not
because of technical causes but because of human factors. Given this "real
world" environment, I personally feel that a loosely linked flow with a
fast enough turn-around time to permit some iterations would be more
acceptable than a tightly linked one-shot flow where it would not be
possible to iterate since it takes too much time.
Of course, then there are market driven concerns (who will convert Avanti
licenses to Cadence licenses; who will convince Synopsys faithfulls to dump
Synopsys, etc...) which load the dice against the "super integrated" flow.
- [ nilgiri94 ]
---- ---- ---- ---- ---- ---- ----
From: [ Tall Thin Dude ]
The problems we have seen in the nonintegrated solution have to do with
lacking Signal Integrity feedback early in the back end physical synthesis,
and P&R. Perhaps combining RTL integration does not offer much, but
current flows are clearly lacking in providing correction at the logic
optimization and early routing stages. We found many problems could not be
fixed with detail routing alone & required iterations to early in the flow.
The lack of a tight extraction/DC/STA/Noise analysis capability were major
limiting factors in making our flow work and required the most integration
effort. Aside from the mechanics, lack of real time on the fly analysis
severly limited us in the effectiveness of each iteration and what could be
done.
Bottom line, a backend post P&R fixup as is currently offered as vaporware
by the big vendors sounds good on slides but would never have worked for us
in 0.18 um.
In most homebrew Signal Integrity flows I have seen, obtaining even a good
noise report and knowing which nets are victims involves writing out the
design in DEF/GDS, getting design LVS final routed, LVS clean, running
extraction, STA (perhaps iterate to get proper timing windows), feed all
into a homebrew analyzer. This is only for one iteration to find out the
problem victim nets. Using this flow it may take numerous iterations to
finally converge on a noise free design. If you throw other issues like
timing closure IPO iterations, antenna, this process can easily take months.
If you look at any available "Signal Integrity Options" beware to read the
fine print. Most are overpriced vaporware. While there is some truth that
setting them up is difficult and justifies a more expensive option, in most
cases I think the big price tag is to scare away potential users until the
solution actually (if ever) works.
Also be sure to see if and how the "Signal Integrity options" will work with
and integrate to your other point tools, libraries, and data files. Below
are the point tools I have seen in most homebrew Signal Integrity flows.
o) Synthesis (Ambit BG, DC)
o) Floorplanning (DP, Apollo, Aristo)
o) Advanced routing (ARO, DP, ICC)
o) PhysOpt Saturn, PKS, QPopt
o) P&R (SE, Apollo)
o) Extract (Star-RC, QP, Hext, Simplex, Columbus)
o) Delay Calc (Ultima, CDC, Pearl, PrimeTime, proprietary in house)
o) STA (Ambit, PrimeTime, DC, Pearl, QP, Motive)
o) Noise Analysis (Cadmos, Simplex, Apollo)
If you think putting together such a flow was easy, think of how much
hacking is required just to even make tools from the same vendor work
together in a flow :-)
Given the progress of the big three, I think I will be finding many future
contracting opportunities when sub 0.18 um becomes mainstream.
- [ Tall Thin Dude ]
---- ---- ---- ---- ---- ---- ----
From: [ nilgiri94 ]
I empathize with you regarding the problems you guys are facing. So many
different tools from so many different vendors must be hellish.
I guess it all boils down to whether you can model UDSM effects at a
high-enough level so that they can be addressed early enough in the design
flow and cut down on the iteration you can need to go through. As you
mention, the current tools are nowhere close to achieving that even at the
physical level; forget about modeling the effects dynamically or at a high
level. Cadence is better positioned in this area than Synopsys due to their
back-end expertise. However, this is a challanging, if not an infeasible
task; plus the market window of opportunity is not too large. I am not
aware of how the dynamics inside Cadence are, but I am curious to how much
are the back-end folks willing to yield to the newer front-end guys (Ambit);
it would require a very well focused, synergistic effort to get this to work
well. It has to work much better than the Synopsys solution to be an
effective challanger. Unless Cadence comes up with something good and fast,
the Synopsys front end domination may lead to their Physical Front End
domination also.
This gap in the capability of tools will lead to a greater value to
experience and good engineering decision-makers (and I guess will make you
rich).
- [ nilgiri94 ]
---- ---- ---- ---- ---- ---- ----
From: [ firfilter ]
You smell like a Cadence consultant, [ Tall Thin Dude ]. This is obvious
from the way you order your lists:
> point tools I have seen in most homebrew Signal Integrity flows.
>
> o) Synthesis (Ambit BG, DC)
> o) STA (Ambit, PrimeTime, DC, Pearl, QP, Motive)
knowing that 90% of designers can't even spell Ambit...
- [ firfilter ]
---- ---- ---- ---- ---- ---- ----
From: [ Tall Thin Dude ]
I am in not a Cadence employee, but I do end up doing alot of consulting
work around Cadence tools. It seems the Cadence tools need the most "glue"
to put together a working flow.
I am continually amazed at how the Cadence Sales droids try to sell their
collection of non-integrated point tools to customers making it sound like
you can buy them all and use them together. I love to hear "we just bought
DP, SE, PBopt, PKS, and OPUS", Cadence is going to send somebody out to
show us how to use the "flow". I just leave them my card and say "call me
if you need any help".
We all hear the marketing crap. "We will take the best features of all the
tools and merge them together into a super duper nano genesis flow".
Translated: "We will put together an ugly file translator system behind the
scenes to make it look like the tools share a common database/timing engine,
we will encrypt all the hidden files so if we corrupt the data along the
way, the user will not know. We will pray that the vapor story will delay
customers from purchasing other solutions until we can aquire and kill some
more new technology when we fail to deliver. If you do have somebody that
knows how to integrate the tools into a working flow, please let us know,
cause we don't."
So as you can see, I believe Cadence has it's issues, too. Many of the
customers in the most pain are Cadence customers. Avanti has done a much
better job of wrapping together its point tools in a more seamless flow.
Because of the legal/ethical issues with Avanti, many people are stuck with
Cadence flows. To be honest, after Costello left and the heirs "sold out
the company", I have my doubts Cadence is any more ethical. In any case
this means more glue business for me.
I still doubt Synopsys will be able to enter the backend area and be able to
recruit good people in this area. The internal politics of a company with
front-end guys in all the upper managenent levels conflicts with this goal.
Front-end guys (don't get me wrong their intentions may be good) will not
understand and appreciate the difficulties in backend. When things don't
go well, the back-end guys will take the fall. When rewards are handed out,
the front-end guys who are visible to management will reap the rewards.
Eventually any good back-end guys will go to a company "where they are
appreciated". This is just the fact of life in a front-end company.
- [ Tall Thin Dude ]
( ESNUG 353 Item 6 ) --------------------------------------------- [5/24/00]
Subject: ( ESNUG 348 #5 ) SDF & `resetall & `uselib & VCS & Verilog-XL
> It appears that with VCS a `resetall compiler directive causes the search
> path for levels below the current hierarchy to be a empty set. This
> applies to all files except those in the current file. Verilog-XL does
> not change search enviornment as a result of `resetall.
>
> Verilog-XL and VCS behave differently in another way. I've found that
> with Verilog-XL when a uselib directive is used in a model that
> instantiates parts, all searches at that level will honor that uselib
> statement. In other words, if a module instantiates parts and uses a
> `uselib statement to control the search path, then all searches at that
> level will use that search path until another uselib statement is
> encountered. For example, suppose I had a module in a `uselib enviornment
> of liba (`uselib dir=liba libext=.v) and suppose I instantiate two parts:
> a1 and b1. If I put a `uselib statement inside the code for a1 to control
> the search for sub-part a11, then all parts at the second hierarchical
> level would use the second enviornment. In other words part b11 which is
> instantiated by part b1 which is in the top level search enviornment will
> ONLY be searched in the second level enviornment that the uselib statement
> in a1 specified.
>
> Interestingly enough VCS5.1 behaves identically, but VCS5.0 maintains the
> top level environment for the second part.
>
> - John Russo
> Lucent Technologies Allentown, PA
From: John Russo <jfrusso@lucent.com>
John,
Here is an update on ESNUG 348 #5 about VCS. One of the Lucent guys dealt
with this and wrote me:
I have been working with Synopsys to resolve the problem. At this point
Synopsys has acknowledged, found, and fixed the problem in VCS 5.1 and
5.2. Patch releases are available for both VCS 5.1 and 5.2. Furthermore,
Synopsys has agreed to raise this issue, along with related issues I found
while creating test cases for this problem, to OVI for standardization.
However, I recently discovered another bug in both VCS 5.1 and VCS 5.2
with SDF. Synopsys is currently working on the problem and will notify us
when a patch is ready. Synopys staff recommends the use of the +oldsdf
command line option until the bug is fixed.
Hope this helps others out there using VCS.
- John Russo
Lucent Technologies Allentown, PA
( ESNUG 353 Item 7 ) --------------------------------------------- [5/24/00]
From: [ From The Land Of Hello Kitty ]
Subject: Unhappy Newbie Struggling With Escalade DesignBook Learning Curve
Hi John,
I've just started using Escalade DesignBook on Solaris 2.6. While testing
several cases, I've got serveral questions that couldn't overcome as far as
reading PDF documents. The questions are:
1. The Help doesn't work. The format of help file seems to be Windows
help format(.hlp), so can't I use Help on Solaris? Why?
2. When I check a block with Ctrl-F9 in the block editor, a small window
appears and reports only Error/Warning counts. Is there any way to
get further information?
3. I set the header information from the menu (Options)- (code generation)
- (copyright) - (Use Project Copyright). But the properties such as
$name, $date aren't expanded.
4. When I rotate a block with wire and connector 270 degree, the port
description and connector description faces the opposite side. I can
correct it by rotating only connectors, but it's troublesome. How
can I move the port/connector/wire description?
5. How to set the Printer and printing size? Although I can set the
working page size in the menu (Option)-(Edit Preference)-(Page),
printing page size seems fixed to A4 Portrait.
The version of DesignBook is 3.8a/1.1a and using Solaris 2.6. I appreciate
any help. Thanks. Please keep me anonymous.
- [ From The Land Of Hello Kitty ]
( ESNUG 353 Item 8 ) --------------------------------------------- [5/24/00]
Subject: Books, Papers, URL's On Fault-Tolerant System Design Strategies
> Does anybody know of a resource (web, book or article) describing
> architecture design for systems, storage or logic, whose components are
> prone to very high rate of failure, along the line of 0.1%-1%?
>
> - Greg Deych
From: Terje Mathisen <Terje.Mathisen@hda.hydro.com>
You start with the component failure rate and the target failure rate.
Then you decide if you need error correction or if error detection and
retry is feasible. If every single component, including the error
checking/voting hardware has the same, extremely high, error rate, then it
becomes _very_ hard.
What about the failures themselves? Are they silent, soft, hard?
Will a faulty component stop working altogether, or will it just produce
wrong answers? It helps a _lot_ if you can assume that some components,
are much better than the worst parts. :-)
- Terje Mathisen
---- ---- ---- ---- ---- ---- ----
From: Greg Deych <gdeych@my-deja.com>
That could be the case, but I think I'll start off with hardware which
has more or less regular failure rates.
Actually, it's easier if the component just fails altogether. That
way, you can ignore it, rather then accounting for unpredictable
values it may output.
- Greg Deych
---- ---- ---- ---- ---- ---- ----
From: Philip Koopman <koopman@cmu.edu>
You'd really need to express that failure rate in terms of failures per
unit time and then contrast that to expected "mission time". Do you mean
failures of 1% per hour? How long until you get to repair it -- 1 hour or
10,000 hours?
The usual tool to deal with this is redundancy, and there are shelves and
shelves of books that deal with that. But it only works for "moderate"
failure rates with a lot of caveats and a lot of money in many cases.
- Philip Koopman
Carnegie Mellon University
---- ---- ---- ---- ---- ---- ----
From: Greg Neff <greg@microsym.com>
OK then, you might want to check out:
"Fault Tolerant System Design" by
Shem-Tov Levi and Ashok K. Agrawala
McGraw-Hill
ISBN 0-07-037515-1
Good book.
- Greg Neff, VP Engineering
Microsym Computers Inc.
---- ---- ---- ---- ---- ---- ----
From: janm@penfold.transactionsite.com (Jan Mikkelsen)
A few books:
"Transaction Processing: Concepts & Techniques"
By Gray & Reuter
Morgan Kaufmann Publishing
"Reliable Computer Systems: Design and Evaluation", Third Edition
By Siewiorek & Swarz
"Atomic Transactions: In Concurrent and Distributed Systems"
by Lynch, Merritt & Weihl
Morgan Kaufmann Publishing
"Fault Tolerance in Distributed Systems"
By Pankaj Jalote
Tandem have (or had?) a thing called Tandem Information Manager (TIM) where
you could get the Tandem documentation on CD for around $150. That might
also be useful.
- Jan Mikkelsen
TransactionSite Pty. Ltd. Sydney, Australia
---- ---- ---- ---- ---- ---- ----
From: "Daryl Bradley" <dwb105@nospam.ohm.york.ac.uk>
Take a look at
http://www.amp.york.ac.uk/external/media/cal/welcome.html
bits of 'something a bit different' on fault tolerant design
- Daryl Bradley
University of York York, UK
---- ---- ---- ---- ---- ---- ----
From: Mark Brehob <brehob@cse.msu.edu>
This might be well known to those of you in the FPGA world:
"A defect-tolerant Computer Architecure: Opportunities for Nanotechnology"
by J. Heath, P. Juekes, G. Snider, R. Williams.
Science, 12 June 1998, pages 1716-1721.
Note it is _defect_ tolerant, not fault tolerant per se. That is it finds
the errors in the system _then_ starts to do work. It assumes that it is
working with highly-broken components, but that they aren't in the process
of breaking as time goes on.
- Mark Brehob
Michigan State University
---- ---- ---- ---- ---- ---- ----
From: Brian Drummond <brian@shapes.demon.co.uk>
I wonder if it's worth trawling for information from the vacuum-tube and
mercury delay line days (ACE, EDSAC, LEO etc), the late 1940's and very
early 1950's. They faced these problems and usually, certainly LEO (Lyons
Electronic Office) did, developed strategies to deal with them ... e.g.
regular checkpointing, running test patterns with over/under voltage to
catch marginal performance, etc.
As a start I'd search for M.V. (Maurice) Wilkes and see what turns up...
- Brian Drummond
---- ---- ---- ---- ---- ---- ----
From: Greg Deych <gdeych@my-deja.com>
That sounds very promising. I went searching for those kinds of
references yesterday, but without much success. Unfortunatley, ACM's and
IEEE's digitial library goes back only till 1988 or so.
- Greg Deych
---- ---- ---- ---- ---- ---- ----
From: eee@netcom.com (Mark Thorson)
I vaguely recall a paper with a title something like "On Building A Reliable
System From Unreliable Nodes" by von Neumann. Does anyone remember that
more clearly?
- Mark Thorson
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 11,086 other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
|
|
