From: kkranen@synopsys.com (Kevin Kranen)
> John, For your DAC review, I'm surprised that nobody reported the most
> romantic DAC story of all: I proposed to my cross-corporate sweetheart,
> Kathryn Moore (VP NA Sales Quickturn), on the Tuesday of DAC, June 4th!
> What's more, she even said "YES" !! Now some may say that DAC is perhaps
> a lousy place for romatic inclinations, but we managed to find:
>
> 1) An all-(well most all) expense paid stay at a glitzy semi-elegant
> hotel with great room service all nite long.
>
> 2) A way to spread the word to some 250 EDA industry friends. (It's
> great to see "people news" still travels faster than EDA gossip!)
>
> 3) A chance to get Harvey Jones (COB, Synopsys) and Keith Lobo (CEO,
> QuickTurn) to bless our union. Harvey quiped: "As long as it is not
> perceived as a corporate merger or acquisition. You know how Wall
> Street is."
>
> We even had Elvis perform a "commitment ceremony" (a wedding ceremony
> without the vows) in one of Las Vegas' elegant wedding cathedrals!
> ("Mom, Dad, you'll never believe what I just did in Las Vegas!")
>
> - Kevin Kranen
> Synopsys Semiconductor Vendor Program
>
> PS: Yes, you can carry this story in ESNUG if you like !!
[ Editor's Note: Congradulations, Kevin! But there's no way I could run
your letter in ESNUG -- it might embarrass your fiancee! :^) - John ]
( ESNUG 243 Item 1 ) ---------------------------------------------- [7/96]
Subject: ( ESNUG 241 #9 242 #4) Will Trade My Secret Switches For Yours!
> I'd like to see more secret switches "exposed" in ESNUG. In trade, here's
> mine: I was having headaches with Synopsys putting in unnecessary buffers.
> (I figured out that there was no capacitance, fannout, or timing problem,
> but I was still getting two inverters on each output.) Here's the fix:
>
> /* clean up unnecessary inverters */
> compile_clean_inverters = true
>
> Sure enough. My extra inverters went away.
From: [ I Am The Walrus ]
John: Anonymous, please.
Thanks for the info on this. It seems to be a relatively new feature.
I found it has no affect for v3.2b while it does seem to for v3.4b.
(v3.2b)
/* clean up unnecessary inverters */
compile_clean_inverters = true
Warning: Defining new variable 'compile_clean_inverters'. (EQN-10)
"true"
1
(v3.4b)
/* clean up unnecessary inverters */
compile_clean_inverters = true
"true"
1
I look forward to hearing what others find while checking out some of those
other undocumented commands!
- [ I Am The Walrus ]
( ESNUG 243 Item 2 ) ---------------------------------------------- [7/96]
From: Oren Rubinstein <oren@waterloo.hp.com>
Subject: Synopsys 3.4b Won't Use 8->1 Multiplexers
John,
I wrote a test case for the infer_mux directive, with an 8-wide input:
module junk(clk, rst_n, e, i, o);
input clk, rst_n;
input [2:0] e;
input [7:0] i;
output o;
reg o;
// synopsys infer_mux "mux1"
always @(posedge clk) begin: mux1
if(!rst_n)
o <= #1 1'b1;
else case(e)
3'b000: o <= #1 i[0];
3'b001: o <= #1 i[1];
3'b010: o <= #1 i[2];
3'b011: o <= #1 i[3];
3'b100: o <= #1 i[4];
3'b101: o <= #1 i[5];
3'b110: o <= #1 i[6];
3'b111: o <= #1 i[7];
endcase
end
endmodule
It works (i.e. it builds MUX trees) but it will not use an 8->1 MUX!
Instead, it builds a 2 stage tree, with the input stage containing 4
2->1 MUXes and the output stage containing a 4->1 MUX. The design is
underconstrained from the timing point of view, and has a set_max_area 0.
From the area point of view, the order of efficiency is:
8->1 MUX ............ smallest area
4 2->1 + one 4->1 ... 21% bigger than 8->1 .... yet this one chosen
2 4->1 + one 2->1 ... 23% bigger than 8->1
- Oren Rubinstein
Hewlett-Packard (Canada) Ltd.
( ESNUG 243 Item 3 ) ---------------------------------------------- [7/96]
Subject: ( ESNUG 240 #4 242 #4 ) Backannotation, Visibility, & 'Characterize'
> I don't think this is true... there's another case. What they're talking
> about is executing the set_load commands from the top level, and their
> effect not being visible when you make the current_design a lower level
> (moving DOWN the hierarchy). ... But we're backannotating lower blocks,
> then moving UP the hierarchy. I found the generalization that the set_load
> commands are only visible from the design where they were run seems
> incorrect. Rather, the tool will propagate their effects up the hierarchy,
> but not down it (use characterize for that).
From: "Russell Ray" <rray@msai.mea.com>
Hi John,
Greg states that the set_load will propagate up the hierarchy but not down.
This is true in the effect, but the only reason he gets the same timing when
at a higher level is that the set_loads are still applied to the lower design
even though he is at a higher level. This can be dangerous if someone
applies the loads at the lower level, runs timing, and later decides to
re-compile but has forgotten that the set_loads are present. Those loads
(or any other design constraint) are still present unless a reset_design is
issued.
So the reason it is "seen" up the hierarchy is the loads are applied to that
design and are therefore visible to all levels above it. The danger is if a
re-compile or other operation is issued and the intent is to not have the
loads taken into account.
- Russ Ray
Mitsubishi Semiconductor America, Inc.
( ESNUG 243 Item 4 ) ---------------------------------------------- [7/96]
Subject: (ESNUG 240 #7 242 #6 ) Simulators Giving Frustrating X's
> If I have a 2-input multiplexer with zero's on both inputs and an 'X' on
> the select line, should I get a zero out? The answer is probably yes, but
> most models of the multiplexer would put out an 'X' if the select line is
> unknown regardless of the inputs instead of handling the special case of
> all inputs being zero (or one, for that matter). ... In some cases the
> 'X' would be the better answer; if the select line was metastable and was
> not at a legal logic level, then the output would be unknown.
From: peer@iis.fhg.de (Dieter Peer)
John,
This is right from a purely logic standpoint. But are you aware, that in
real world an 2-input multiplexer MAY definitely produce a spike if you
leave both inputs on the same level and switch the select line?
Although this spike is not X it can cause lots of trouble in the logic
that is fed from the mux's output.
- Dieter Peer
Fraunhofer-Gesellschaft
---- ---- ---- ---- ---- ---- ----
From: Jeff Nuckols <jnuckols@aircom.com>
John:
I understand the frustration with getting X's from a simulator because one
of the logic inputs is unknown even though I know real gates will give me a
predictable output. At the same time, though, this feature of simulators has
exposed for me an *unexpected* unknown on one of my inputs that would have
been masked if the simulator had behaved more like real gates. So, for me,
this simulation behavior is useful.
- Jeff Nuckols
AirNet Communications Corporation
---- ---- ---- ---- ---- ---- ----
From: victor_duvanenko@truevision.com (Victor Duvanenko)
John,
On the subject of X's in your simulation... About 4 years ago several
of us discovered this, and it took us a while to convince Synopsys that
this was a problem with "synthesis and then gate-level simulation
methodology". Synopsys wrote up a very nice App note that they should be
handing out to every customer. However, the conclusion was that there is
nothing wrong with the circuit and it will work perfectly fine, but that
the problem is with simulation (and as was said before maybe the simulation
vendors will take note and improve the simulators).
- Victor J. Duvanenko
Truevision
( ESNUG 243 Item 5 ) ---------------------------------------------- [7/96]
Subject: (ESNUG 242 #7) What Is IBM Like To Work With As A Foundry?
> John, I am curious as to whether anyone has personal experiences with IBM
> as an ASIC vendor. I am looking for information and opinions about how
> they are to work with as an ASIC vendor with regards to tools support and
> issues, general responsiveness to problems, flexibility to work with their
> customers needs and requirements, etc.
From: dhirtzel@p94asics.geg.mot.com (Douglas Hirtzel)
John,
We utilized IBM as the foundry for several cmos asics in the size range of
200k gates when I was working as a contractor for Teradyne, Semiconductor
Tester Division in Agoura Hills, California. IBM employed a little bit
different philosophy went it came to customer training and support. IBM
hired a third party consulting firm, APK, to interface between IBM and the
local customers.
APK was then responsible for assisting the customer in their day to day
inquiries and the operation of the IBM timing tool Einstimer. The IBM people
were always available for phone contact and responded in a reasonable amount
of time to any questions that APK was unable to answer.
Be warned that you should have a standard sized RAM or "configurable register
arrays" if you intend on having embedded ram on the ASICs. IBM is capable of
building virtually any size "configurable register array" -- but the access
timing is *different* for each depth and width of the array -- each
configuration will require characterization.
- Douglas Hirtzel
Impact Design Services, LLC
( ESNUG 243 Item 6 ) ---------------------------------------------- [7/96]
Subject: ( ESNUG 241 #7) We Like Avant! But Don't Know About The Lawyers
> We've looked at a couple of products and even asked some vendors to try out
> one of our 60K gate designs. Compass still haven't come back with
> Pathfinder results. Cadence Cell3 results are fairly impressive (12%
> smaller than our Cell Ensemble and the job took about 1/30th of the
> original P&R time!) Avant! ArcCellBV and ArcCellXO were both even better
> than Cell3. ... Our problem is how can we do business with the
> Avant!/Cadence lawsuit looming? Is there any way an Avant! customer can
> get burned if they lose?
From: "Guntram Wolski" <gwolsk@sei.com>
Hi John,
I, too, was interested/impressed with Avant! at DAC -- even said so in my
trip report at SEI. This lawsuit is just unfortunate as it does make
everyone I talked to wonder about the tools. Worst case though, might it
not go the way of the Intel/AMD ucode lawsuit where AMD was required to just
rewrite the sections of ucode that were considered offensive? Yea, like I'm
a lawyer... :-)
- Guntram Wolski
Silicon Engineering, Inc.
---- ---- ---- ---- ---- ---- ----
From: jcooley@world.std.com (John Cooley)
This issue got me so curious that I called up some of the long time industry
watchers (EDA users, lawyers, editors, executives, investment bankers, etc.)
and came up with the following 3 possible outcomes:
1.) Cadence Loses Hands Down: Joe Costello resigns and joins the French
Foreign Legion under the assumed name of "D'Artagnan Dumas" never to
be heard from again. Avant! customers go on with business as usual.
2.) Cadence Gets Its Injunction, Etc: Gerry Hsu skips town 10 minutes
before the police come to get him and is last rumored to be living as a
Buddist monk in Tibet. Avant! can no longer sell the products named
in the court order thus leaving its customers in the lurch. Since
I can't find anyone who can think of even one case where customers of
a high tech copyright infringed product were held liable, it seems
unlikely, in my non-legal opinion, that Avant! customers would lose
more than the use of the product. I just can't see Cadence successfully
bringing those Avant! customers with huge legal staffs (like Motorola,
Seimens, Alcatel, AMD, and Toshiba) to court and surviving unscathed.
3.) Most Likely: both sides work the American legal system for what it's
really good at -- dragging lawsuits out ad nauseum. Eventually both
sides get bored and mutually decide either to settle out of court for
a lump of money or to just stop wasting so much money on lawyers.
No, I'm not a lawyer, nor do I work at Dionne Warwicke's Psychic Friends
Network; so my advice is not legal and I can't predict the future. But, if
I believed that the Avant! tool was far better (I can't say; I haven't used
it) I'd buy it after haggling the price way down for fear of suddenly losing
it. That is, I've got to constantly use the most productive EDA tools
because if I don't and my competitors do, I'm in worst trouble.
- John Cooley
the ESNUG guy
---- ---- ---- ---- ---- ---- ----
From: [ The Thin Man ]
Hi John -- Please keep me anonymous.
Let me start by saying that choice of layout tool appears to be a religion
war -- make the wrong selection and you are a heretic! As a designer (rather
than a layout priest) I would have to say that the easiest toolset to use is
either the Compass tool-set or the Cascade tool set, as neither of these
tools require the mysterious incantations required by the Cadence or
Avant! tools. This means that they are accessible to us mere mortals who are
more interested in completing a design rather than spending many hours in
layout ping-pong.
We have over the past few years used/compared the Cadence/Avant!/Compass
and Cascade tools for several benchmarks and real designs and found the
Cascade tools to be the easiest to use, well integrated with a Synopsys based
design flow, and give results comparable to any of the other layout systems.
(In our benchmarks they beat Avant! and Compass on some designs.)
Cascade takes as input a hierarchical Verilog or VHDL netlist (and maintains
the hierarchy throughout the layout operation - including clock tree
generation). It has a built in floorplanner which accepts layout directives
in the same way that Synopsys accepts compile directives in the netlist (or
attributes can be added during the manual floorplanning effort). The initial
floorplan is automatically created and although not always optimal it forms
a good starting point for the final floorplan - in the case of small blocks
(> 10K gates) it usually produces an optimal layout.
There is a Synopsys supported interface to generate custom wire load models,
set_load commands and more importantly the interface takes the output from a
"write_script" command and translates them into timing directives for the
layout timing objectives (i.e set clocks, input delays, output delays, etc.)
Synopsys libraries in either cmos2 or lut are provided as part of the
technology rule-set.
The best feature from a designers point of view is probably the integrated
delay calculation and timing analysis tools, these are linked to the layout
tools so that after a layout is completed the design can be examined for the
usual timing problems.
Timing issues can be addressed by increasing or decreasing the drive
strengths of gates along critical (or specified) paths, this feature (known
as timing driven buffer sizing) means you do not have to return to Synopsys
to fix setup/hold violations or speed up critical paths - buffer sizes are
changed in the layout via commands in the timing analysis tool.
I would reccomend you take a look at the Cascade tools to see if they fit
your requirements - and no I don't work for them I just think they have a
great tool set - there is also more likelihood of being able to complete
your layout without the assistance of a lawyer !
- [ The Thin Man ]
[ Editor's Note: This "Thin Man" letter came from a user's address - John ]
( ESNUG 243 Item 7 ) ---------------------------------------------- [7/96]
Subject: ( ESNUG 241 #10) "Gotchas" Using Mixed Mode Cadence With LMC Models
> I am currentlydoing a mixed-signal simulation using Cadence Concept, Logic
> Work Bench (used in Mixed Signal mode), Leapfrog, and Verilog-XL (all of
> which are from release 9502.)
>
> The Synopsys LMC models I'm using include the old-fashioned Verilog
> Smartmodels (Release 39) and the generic SWIFTModels (Release 40). We are
> in the process of obtaining & installing SWIFTModel Release 40b (this has
> Concept symbols for the devices being modeled) and VHDL SWIFTModel Release
> 8. (I do not intend to use the Verilog models because they will not be
> supported after this year.) ... What are the gotchas in this approach?
From: Randy Bolling <randy@vela.com>
John,
I am not certain of the "mixed simulation" application, as most of the
simulation effort is focused around a digital application. By mixed mode,
I assume mixed VHDL/Verilog/hand-generated gates.
The process is among the best for "generic sign-off", offering up performance
gains for using Verilog-XL's presence at sign-off. Naturally, intensive
regression analysis will notice significant improvements with other Verilog
simulators (even ones offered from Cadence), which may lack the sign-off
status but suffice for voluminous simulation.
Cadence has not been known for their visibility down through Verilog-XL into
Leapfrog VHDL, or visa-versa, down through Leapfrog VHDL into Verilog-XL.
They have previously lacked features allowing debug of the "imported"
code due to the fact that Concept was applying a PLMI interface,
not a complete debug environment. Tracing signals around the Verilog
netlist after synthesis (assuming you sign-off Verilog, and synthesize
VHDL) can be difficult; tasks such as injecting values onto signals and
tracing signals in simulation time. Viewing vectors is no more different
than usual with Verilog-XL.
Finally, debugging a netlist without at least a viewable netlist can be
difficult. Last I checked, there were no direct paths from Synopsys to
Concept schematic diagrams (Composer yes, Concept no.) Thus, you can always
view the netlist in Synopsys Design_Analyzer (as many do) until you become
familiar with the netlist format. A dedicated Design_Analyzer license
becomes valuable at this point.
If you feel comfortable, an alternative approach is ModelTech for the
heterogeneous mix of VHDL/Verilog code during debug, and sign-off on a single
copy of Leapfrog/Verilog-XL/Concept/LMC/Logic Workbench. ModelTech offers a
consistent interface for both Verilog and VHDL simulation and debug.
Optionally, you can create a singular Verilog world thus making the problem
much simpler by eliminating the need for imported or mixed simulation.
This would allow for the use of a number of alternative Verilog simulators.
Hope this helps out in some manner.
- Randy Bolling
Vela Research
( ESNUG 243 Item 8 ) ---------------------------------------------- [7/96]
From: wyamamo@ibm.net (Wataru Yamamoto)
Subject: VHDL Compiler 3.4b Problems With Generics & Aggregates
Dear John,
VHDL Compiler 3.4b doesn't accept a vhdl description where a sub-block
(template) has a generic specifying width of vector ports like:
entity subblk is
generic(N: integer); -- vector width
port(A: in bit_vector(0 to N-1); -- 'N' specifies the width.
B: out bit);
end subblk;
architecture something of subblk is
begin
B <= A(A'left);
end something;
Plus VHDL Compiler hates it when a formal port is divided by vector indexes
in a port map like:
architecture dc_error of top is
component subblk
generic(N: integer); -- vector width
port(A: in bit_vector(0 to N-1); -- 'N' specifies the width.
B: out bit);
end component;
begin
U0: subblk
generic map(4);
port map(A(0 to 1)=>P0, A(2 to 3)=>P1, -- Error!!!!!!
B =>P2);
end dc_error;
It gives the error:
Error: Cannot determine type of the aggregate
in routine top line 55 in file '...../ex.vhd'
(This error can occur if an aggregate and a generic appear in the
same component instantiation.) (HDL-206)
When will Design Compiler (VHDL Compiler) support the above?
- Wataru Yamamoto
IBM Japan
|
|
