[ For some weird reason, the Cadence newsgroup gets a post every so
often from an arts & crafts type person. Why? I don't know. What
I do know is a great opportunity for mischief when I see one!
(Joe Costello personally "thanked" me for this one.) ;^) -John ]
Newsgroups: comp.cad.cadence,alt.cad,alt.cad.autocad,alt.cascade,
trial.rec.metalworking,rec.crafts.metalworking,mcnc.cad
Subject: Re: Help! Urgent!
jaguar@r-node.io.org (Glen Mead) writes:
>I am currently in need of information regarding embossing and printing
>plates (like those used for business cards, currency, raised logos on
>cigarette packages etc) and I'd appreciate it if somebody could help me
>or at least point me in the right direction. I need the following info:
>
> - Names of manufacturers/fabricators of embossing plates by hand or
> otherwise. (Specially in Canada)
> - Uses of embossing plates (cards, packaging, etc.)
> - Names of a few customers who use embossing and why they use it.
> - Cost of purchasing a set of plates, various sizes (please indicate).
> - Are there different qualities of plates for different applications,
> different medias, or different production runs.
Glen, you may want try looking into using Cadence's Composer product. I
know of a few people who have made some great looking business cards using
this product! (These people at Cadence really do know the embossed plate
business!)
For the best service you should call Joe Costello at Cadence and ask about
their Composer product. (Joe's a cool guy -- tell him "John Cooley" sent
you.) I don't have his phone number handy because I left my Cadence Crafts
catalog in my car but they're based near San Jose, CA. Just call
information there and they should help you.
- John Cooley
the ESNUG guy
( ESNUG 180 Item 1 ) ---------------------------------------------- [3/3/93]
From: brien@acuson.com (Brien Anderson)
Subject: Change How A Module's Named And Synthesis Results Change !?!
John, we have recently discovered that we receive different timing from
different compilations using the same code, but with different module names!
Sometimes timing is met, sometimes not. (?) We don't seem to have control
of which iteration of compile will produce results that will meet timing in
a consistent manner.
I'm using the same script for each compile; just changing the module name.
current_design "freq_fa1"
max_delay 10 out
compile
In my example file I have four identical modules named freq_fa1, freq_fa2,
freq_fa3 and freq_fa4 as follows:
module freq_fa1(out,in1,in2);
input [22:0] in1,in2;
output [22:0] out;
assign out = in1 + in2;
endmodule
For module named "freq_fa1" Synthesis results in: slack (VIOLATED) -0.38
For module named "freq_fa2" Synthesis results in: slack (VIOLATED) -0.01
For module named "freq_fa3" Synthesis results in: slack (MET) 0.01
For module named "freq_fa4" Synthesis results in: slack (MET) 0.00
There does not seem to be a way to predict the non deterministic approach that
Design Compiler is using to produce seed values. This bug is repeatable with
Synopsys 3.0b and 3.0c using two different vendor's libraries and does not
occur in Synopsys 2.2b. Any suggestions?
- Brien Anderson
Acuson
--- --- --- ---
From: [ The Synopsys Sythesis Team ]
John, Synopsys' synthesis tools are all deterministic in that if they get
identical input, they will generate an identical result (i.e. the same start
point, the same Verilog/VHDL executable, and the same sequence of events).
In the example described above the start point is not the same because all
of the designs were read in at the same time resulting in different operator
names. The results would be the same if each case is read in, then compiled
individually.
In this case the difference in the two approaches has to do with naming
conventions. In order to make mapping between operators and the Verilog/VHDL
easy for a designer, Synopsys synthesis uses a naming convention based on the
line number. In 3.0 this affected the compile search path. (As it turns out,
in 3.1 this variation did not affect the search path in the cited example so
the results would be the same for all cases.)
In the general case, designers should not count on this level of "determinism"
because there will be minor variations in timing given different inputs.
These minor variations are not a bug but a fundamental limitation in complex
optimization tools such as synthesis. Design partitioning, coding style,
compile strategy, constraints, sequence of events, and naming all affect the
output. Therefore designers should not count on reaching identical results
when varying these factors. However, they can expect timing variations to be
small for minor input changes.
It is important to keep all of this in perspective. This same set of issues
arises in other complex optimization tools, including place & route tools
(many of which rely on random number generators). Despite this, synthesis
tools and place & route tools have been used to produce thousands of designs.
To understand why minor variations should be expected, you have to consider
what a synthesis tool is doing. Synthesis is an extremely complicated process
in which a tool searches for the optimal solution. In fact, it is rare that
a tool actually finds the optimal solution -- primarily because with the
complexity of today's designs, this could take a very, very long time. So
tools have to settle for near optimal solutions. To do this they rely on a
large number of complicated algorithms and heuristics. Many of these are
sensitive to search orders which can be driven by many things such as instance
names, locations in memory, randomness, etc. Synopsys specifically stays
away from approaches that use randomness because they are not deterministic.
Determinism is desirable because it makes designs reproducible and, hence,
debugable.
Understand, however, that by limiting ourselves to deterministic approaches,
we limit the efficiency of our search for the optimal solution. In fact, we
don't lose much by not considering random algorithms. However, the more
restrictive that tool designers are in their choice of algorithms, generally
the poorer the quality of results and the longer the compile times. So there
is a tradeoff between user controllability and tool effectiveness. Generally
we lean towards giving the highest quality of results, i.e. finding better
near optimal solutions.
Synopsys works hard to make sure that we can give fairly consistent results
between runs by driving the tool with constraints at all levels. Minor
variations in a design, such as naming typically result in a very small change
in quality of results. Larger variations such as compile strategy or coding
style can have a considerably larger effect. Many designers use the latter
variations to perform multiple compiles on the same design to find the best
results. We feel that today our synthesis tools are far more efficient than
designers in finding near optimal solutions, which is why so many designers
use synthesis.
- [ The Synopsys Sythesis Team ]
( ESNUG 180 Item 2 ) ---------------------------------------------- [3/3/93]
Subject: (ESNUG 179 #5) "std_logic vs std_ulogic for VHDL"
>I have been wondering why Synopsys have decided to write their SIGNED and
>UNSIGNED VHDL packages using std_logics instead of std_ulogics. ...this was
>done because Design_Analyzer has a built in function that checks on multiple
>outputs on one wire anyway. This, in my opinion, is a weak defense. ...
>they state VHDL resolution functions are executed each time an event
>occurs on a source of a resolved object. This means, for example, that the
>simulation of an adder, that makes use of the std_ulogic_signed package,
>executes a lot of unnecessary resolution functions (in fact: one for every
>input change!)
--- --- --- ---
From: [ Anon ]
John, (Anonymous, please), Synopsys has claimed to me that the resolved types
do not slow down simulation a bit. My own experiences show the same thing,
there is no difference in simulation speed whether I use resolved type or
unresolved type.
- Anon
--- --- --- ---
From: lewis@protocol.zycad.com (James W. Lewis)
Hi, John, -- actually the package std_logic_arith.vhd is configurable. See
the file: "$SYNOPSYS/admin/install/syn/bin/install_vhdl" A note to Synopsys:
it would be nice if this script created two packages: std_logic_arith and
std_ulogic_arith. This would give designers a choice. This is particularly
useful for designers that are working on different projects.
- Jim Lewis
Zycad
--- --- --- ---
From: emery@vnet.IBM.COM (Emery Gedeon)
I had the same question at one time. Then I read this somewhere in the
Synopsys literature:
The "reflexive" attribute has been defined in the std_logic_1164 package
and controls the bus resolution function. When a signal has a single
driver, the bus resolution function does not need to be invoked. The
signal value becomes the driven value. The function is called when a
signal has multiple drivers and needs to be resolved.
This means that you do not have to pay a simulation performance penalty
for using std_logic vs. std_ulogic signals on VSS.
- Emery Gedeon
IBM Boca Raton, FL
( ESNUG 180 Item 3 ) ---------------------------------------------- [3/3/93]
Subject: (ESNUG 179 #1) "Building Your Own Library" (Was "Inverter 'Happy'!")
>John, one thing you could try to effect the use of inverters over buffers is
>to build a wire load model yourself which does not zero out the wire load
>*area* parameter. This can be done by building the wire load model and doing
>an 'update_lib' command which will add the wire load model to your vendor's
>library....
>
> wire_load("EXAMPLE") {
> resistance : 0 ;
> capacitance : 1.0 ;
> area : 0.0 ; <------ Change this value
> slope : 0.046254 ;
> fanout_length(1, 0.108657) ;
> }
--- --- --- ---
From: brad@hdls.COM (Brad Eltman)
John, this idea of modifing the library works quite well. We have tried it
since Synopsys version 1.2. It does not give you the consistent results
you want however. As a a digression we also create multiple versions of the
library. One of which is used for the initial compile eliminates the gates
you don't want to see in you design. The second is used for an incremental
compile uses all the gates but with altered area numbers to distract the cost
function. This works somewhat better than just altering the area numbers and
doing the synthesis in one compile step.
We have found that with version 3 this is pretty much unnecessary, and the
dont_touch is the best way to eliminate cells in the first compile that
you know you don't want to see in your design. We still have hopes to use
the wire area parameter but don't have consistent results with this. You may
want to try this next as a less drastic solution.
- Brad Eltman
HDL Systems Corp.
( ESNUG 180 Item 4 ) ---------------------------------------------- [3/3/93]
From: Matthew_Wishek@smtp.esl.com (Matthew Wishek)
Subject: Synopsys Test Compiler w/ LSI Logic
John,
Does anyone have experience using Test Compiler's Custom Test Vector tool for
scan vector generation for LSI Logic ASICs? Does it work? What were the
problems? Please share experiences on ESNUG. Thanks in advance.
- Matthew Wishek
TRW Military Avionics & Electronics Division, San Diego
|
|
