Editor's Note: I've come to the conclusion that God loves a good practical
joke. Or, at least it seems that way for me. I belong to a gaming club
that meets once or twice a year at Cape Cod ( a resort region about 2 hours
from Boston ) during the Cape's "off" season for a weekend. We play games
like chess, Risk, Settlers of Catalan, and various card games. I've been
a member for nine years and each time I've gone to one of the gaming
weekends, I always get assigned the worst possible hotel room available.
Against my choice, I'm usually stuck with the room next to the stairwell
(with everyone walking up & down stairs all night long) or the room with a
great view of a brick wall or the room next to the noisy, half-broken ice
machine that grinds all night long. And, of course, these rooms are really
nothing more than large walk-in closets barely large enough to hold a bed.
I'm talking nine years. And over those nine years, like most humans, I've
had my share of romances and just accepted that it was my sad fate that
these romances must involve staying in reaaally crappy hotel rooms on these
gaming weekends. (It was either that, or no room at all!)
Last weekend was another gaming weekend. This time I was sharing a room
with my brother who's unexpectedly visiting from Florida. I had to call at
the last minute to get a room with 2 beds. Bracing for the worst (but not
really caring because I was with my brother), I *cried* when I opened the
door to the hotel room we were given, at the *last* minute, at *half* price.
The room had 2 beds as expected. Plus a 270 degree picture view of the
ocean. Which was 30 feet from the window & private deck. Plus its own hot
tub! Nine years. Nine years, and I given the *Honeymoon Suite*. And I'm
sharing it with my *BROTHER*!!! <Waaaaaaaaaa!> :^(
- John Cooley
the ESNUG guy
( ESNUG 268 Item 1 ) -------------------------------------------- [10/9/97]
Subject: ( ESNUG 267 #3 ) Has Anyone Used The New Synopsys ECO Compiler?
> I'm curious to know if anyone has used the Synopsys ECO Compiler and, more
> importantly, what kind of luck they've had with it.
>
> We're presently evaluating it and have had mixed results so far. Of
> course, we're wondering if some of our problems are caused by the fact
> that we use an LSSD methodology. Thanks in advance.
>
> - Tom Cruz
> IBM Network Hardware Division
From: gmann@ford.com (Greg Mann)
Hey, John,
We haven't done any real work with ECO Compiler but I have tried it on
a state machine block. I was impressed. I made a small change to the
state machine and recompiled resulting in quite a different circuit.
After running ECO Compiler, only 3 gates were different. ECO Compiler
was also able to see if my modified RTL was functionally equivalent
and give me back the same circuit as my original.
I'd be interested in specific problems people have had with ECO Compiler
so that I'll know what to look out for.
- Greg Mann
Ford Microelectronics Inc. (Now part of Visteon)
( ESNUG 268 Item 2 ) -------------------------------------------- [10/9/97]
Subject: ( ESNUG 267 # 6 ) Synopsys Version 1997.08 -- To Use Or Not To Use?
> Just curious if any of your other readers have "upgraded" themselves to
> version 1997.08 of Synopsys.
>
> We are finding that designs that compiled fine with 1997.01-44683 and 3.4b,
> cause those "friendly" FATAL ERROR ENCOUNTERED in 1997.08.
>
> I've been trying to get a pulse from some of the AE's at Synopsys if this
> 1997.08 release is worth progressing to (from 1997.01-44683) or not. At
> least one AE claimed none of his/her other customers had upgraded, yet, so
> he/she had no other feedback but mine.
From: landmh@taec.toshiba.com (Howard Landman)
Hi, John,
We had similar problems. Most of our attempted syntheses crashed on
1997.08. We filed one bug report, which our AE says has been traced to
the code which handles connection_class. We do some funny (but legal)
things with connection_class in our current library, so that may be the
cause. I'm going to try removing the connection_class statements and see
if it still crashes after that.
- Howard A. Landman
Toshiba America Electronic Components
---- ---- ---- ---- ---- ---- ----
From: charles@efficient.com (Charles Shelor)
I've been working with 1997.08 Synthesis since a couple of days after
we received the CDROM. I resynthesized a 280K gate device with the .08
release. About 1/3 of the blocks changed size. Of those, it was about
50/50 mix of getting smaller and getting larger by 0.1% to 3%. The final
result was 3 gates smaller. However, TC fataled during the "insert_scan"
operation. I am restructuring my synthesis scripts to mix .01 and .08
processes to achieve the smallest design and get a successful TC run.
One advantage of .08 was a reduction by 15% of the number of test vectors
for the full-scan design while increasing coverage by 1%.
I also prefer the organization of the 1997.01 documentation. The useful
"man pages" are removed from the collection to which they apply and are
all mixed together in their own "man pages" collection.
- Charles F. Shelor
Efficient Networks, Inc.
---- ---- ---- ---- ---- ---- ----
From: Troy J Dye <tdye@poci.amis.com>
John,
We have been experiencing some of these same problems with version 1997.08.
One of our customers has also been experiencing similar difficulties.
- Troy Dye
American Microsystems Inc.
( ESNUG 268 Item 3 ) -------------------------------------------- [10/9/97]
Subject: ( ESNUG 265 #2 266 #4 267 #4) Synthesizable IP Is *Unprotected* IP
> It is my general opinion that there is tremendous pressure to avoid
> royalties & marginally higher production prices by re-spinning the design
> with a low price fab that is not offering any IP. (Been there, done that.)
>
> It's not just design IP that is the issue here either. No matter how
> much is costs to develop, nor the advantages to the customer, the customer
> will always want a device in a 500 high performance BGA package for the
> same price of a 208 QFP.
>
> From the inside, I view the IP issue as a huge problem for the silicon
> industry. I personally don't see how semi houses can continue to offer
> this limitless cornucopia of IP with no ROI. Many of your responses have
> indicated that you have to make the production "attractive" enough to
> keep the business. The only way to do that is to bomb the price.
From: Eric Ryherd <eric@vautomation.com>
Hi John,
I'm replying to "Synthesizable IP Is *Unprotected* IP" while at 30,000 feet
on the redeye after the VSI meeting on IP protection (among other things).
As an IP vendor we ONLY ship the HDL source code. We rely on the
trust and honesty of the organization which is purchasing the core to honor
their contractual obligations. We can trust organizations since they
have quite a bit to lose given the legal system in the states. We can't
always trust individuals but that's just the way the world is...
Trying to encrypt the IP or otherwise "hide" the underlying nature of the IP
will only cause infinite support headaches. We've all had our share of bugs
in ASIC simulation libraries that are quicker to fix ourselves than wait for
the ASIC vendor to correct themselves. But if the library is ecrypted, all
we can do is scream at the vendor! I've been in this position myself
several times and certainly don't want to inflict it on any of my customers.
Two interesting points were made at the VSI meeting. First, there is
new technology which was announced which will encode a "signature" into the
unused states of a state machine. This in effect applies a "watermark"
to the design and would allow an IP provider to identify it's IP and
possibly even the path the IP followed to it's final silicon destination.
Thus, the IP provider could prove that it's code is in a particular design.
This is not unlike certain typos in error messages used to prove a certain
unnamed EDA software copyright lawsuit that has recently been in the press.
The second point was that at some point, no matter how good the encyption
of IP is, unencrypted forms of the IP are available to the world. In the
best protected case, you can always peel the lid off a chip and reverse
engineer the polygons (and there are companies making quite excellent livings
doing just this!). More often, netlists of the IP are released to ASIC
vendors or programmed into FPGAs that can easily be retargetted into other
technologies. So encryption doesn't solve the problem of protecting IP.
To sum up... Everyone has to realize the IP has value. You need to pay for
the IP seperately from the silicon costs. If your ASIC vendor has IP you
want, pay for it up front. If they have the best silicon costs, buy it. But
no one wins by trying to lock a customer to a silicon process with IP.
- Eric Ryherd
VAutomation Inc.
---- ---- ---- ---- ---- ---- ----
From: dchapman@goldmountain.com (Dave Chapman)
Dear John,
The psychological abnormality which causes corporations to have royalty
phobia should be exploited, not struggled against. However, I think that
the best bet is to distribute IP as a form of advertising.
- Dave Chapman
Goldmountain
---- ---- ---- ---- ---- ---- ----
From: Dyson.Wilkes@swi055.ericsson.se (Dyson Wilkes)
John,
All of this discussion so far has been about encryption as a mechanisim
for enforcing licensing (or thats how I read it). I am not a lawer so I
am working from an intuitive standpoint. It seems to me there are two
appraoches to licensing: copy protection and copy detection. Is we look
at other forms of IP both mechanisms are used. Is there scope for some
form of watermarking of RTL code? Idealy the watermark would "show through"
in the physical realisation (the ASIC component). The watermark needs to
be incorporated into the logical structure of the design in such a way that
removing distorys the design. There are comparable patented machanisms
for protecting digital images.
- Dyson Wilkes
Ericsson
( ESNUG 268 Item 4 ) -------------------------------------------- [10/9/97]
Subject: ( ESNUG 267 Item 10 ) Synopsys Vs. Altera Max-Plus II For FPGAs
> I am planning a design using large Altera Flex 10K parts. I was planning
> on using Synopsys with VHDL, which we have at our company. I recently
> attended a training class at Altera on Max-Plus. The Max Plus tool
> seemed so outstanding with the Graphic editor, Paramaterized Megafunctions,
> etc that I am having second thoughts on using Synopsys/VHDL in favor of a
> combination of the Altera Graphic Editor and AHDL (Altera's HDL). With the
> paramaterized megafuncions, the schematic design entry does not seem as
> arcane and low level as one would think, and I was told that AHDL would
> probably give me the most efficient synthesis for the Altera Parts. Using
> Synopsys here would seem to make my job much more complicated. I would not
> be able to use all the Max-Plus compiler, LPM, and other features that I
> was so impressed with. Having to deal with cross application interfacing,
> edif files, and having synopsys/Altera point to each other if a problem
> arises scares me. I do plan on simulating in ViewSim, so I cannot avoid
> cross applications totally. I do realize that VHDL would help over AHDL if
> I planned on re-porting the design to a different Vendor's IC, however for
> this I would consider Altera's VHDL package. I would appreciate any user
> feedback.
From: "J. Darren Parker" <darren.parker@tempe.vlsi.com>
I really like the Altera Graphic Editor. You should use it for all parts
of your design that are specific to this project, e.g. address decoders.
Also, the top-level of your design should be a Graphic Editor file that
connects all your schematic and HDL blocks together.
Any part of the design that is generic and can be re-used should be
written in VHDL and compiled with Synopsys Design Compiler. Try to limit
the levels of hierarchy to 2 or 3, so Synopsys will be able to optimize
it easily. Writing VHDL isn't nearly as fun as drawing a schematic with
Altera's Graphic Editor, but your end-product can be re-used on many
future designs.
I wouldn't buy Altera's VHDL package since you already have Synopsys,
and it won't give you the vendor independence that Synopsys does.
The Synopsys sales rep. will want you to buy FPGA Compiler which is
supposed to give better results than Design Compiler for Altera designs.
Stick with good ole' Design Compiler. The extra expense and hassle of
FPGA Compiler isn't worth it.
- J. Darren Parker
VLSI Technology, Inc.
( ESNUG 268 Item 5 ) -------------------------------------------- [10/9/97]
Subject: (ESNUG 264 #2 266 #5 267 #1) *WHO* Is Using Behavioral Compiler?
> Of course, we had to learn the BC coding style, which is not entirely
> straightforward and definitely takes getting used to. One does also
> give up some control when moving to a higher level, which is not easy
> for most engineers. In my opinion, the difficulty in adjusting to the
> style is probably a big reason for slow market acceptance, just as
> adopting RTL was difficult at first for many long-time schematic
> designers. (However, when RTL synthesis first came out, many designers
> were already used to writing PAL equations, which is really a form of
> RTL. Since BC coding is radically different from RTL, I believe it's a
> bigger leap!)
From: "Janick Bergeron" <janick@qualis.com>
Hi, John,
The discussion about the merits and inadequacies of Behavioral Compiler
brought back some vivid memories:
Ottawa, Bell-Northern Research (now Nortel) CAD group, November 1988.
My first job, fresh out of Univerity of Waterloo: write a
standard-cell/gate-array mapper and optimizer for the in-house logic
synthesis tool then in development. Six months later, through a superb
team effort, we had a tool that could translate our proprietary HDL into
gate-level netlist. My module was ugly, bulky and slow - but it gave
better results than Synopsys 1.0 and Trimeter (anybody remember
Trimeter? :-). That was also before the regular calls from Synopsys
(and later Ambit) offering jobs... but I disgress.
Our group was actively trying to promote its use by logic designers
but reactions were mixed: "I can't edit the netlist to fix bugs? I
have to fix the HDL code?", "I implemented the same function in half
the gates last year!", or "but I want *these* gates!". I still
remember fondly the call from a designer, trying to translate a truth
table into HDL, asking me "how do I compare to don't care?": after two
hours, I'm not sure I had succesfully explained that you simply don't.
Others were overjoyed: a designer - who later became my manager - was
working on memory BIST and pleased to be able to describe his test
procedure in HDL, then quickly get gates, with only minor modifications
required for memories of different size and depth. His comments and
feed-back greatly improved the subsequent releases and helped shape
the RTL synthesis methodology that was later migrated to Synopsys.
The comments I see about BC (and behavioral synthesis in general) are
along the same line. It is still a (relatively) young tool. The
current uses are helping to shape future features and improvements.
Methodologies are evolving as well as design practices. You can't
expect to get as good a result with BC that you can get with manual
RTL coding - that is not its purpose. It is a time-saving device that
let's you implement your functionality faster, with less errors, at
the cost of some area and clock speed. You can't expect to bring BC
into your design process and see benefits overnight. Companies that
are just now making the switch to RTL and logic synthesis, with well
established tools and methods, aren't seeing benefits until the 2nd or
3rd project. BC moves design to another level of abstraction which
means you need to rethink how to capture a design - and that can't
happen without effort and time: with the enormous time pressure and
work load engineers are often under, there is little room for taking
the necessary time to learn a new way to design.
BC - and other application-specific synthesis tools like test synthesis
and protocol synthesis - is a taste of how designs are going to be done
in the future.
- Janick Bergeron
Qualis Design Corporation
( ESNUG 268 Item 6 ) -------------------------------------------- [10/9/97]
Subject: ( ESNUG 267 #7 ) How Do You Get An ITS File Out Of Synopsys?
> These last few days, i have been tring to find a way of getting an
> ITS (Interface Timing Specification) format file out of synopsys, do U
> know a way to do it ??? or where can i get the specific format of ITS?
From: landmh@taec.toshiba.com (Howard Landman)
Am I missing something? There's a command called "model" ... same command
for DC or PrimeTime.
- Howard A. Landman
Toshiba America Electronic Components
( ESNUG 268 Item 7 ) -------------------------------------------- [10/9/97]
From: "Andrew MacCormack" <andrewm@bristol.st.com>
Subject: DC's Choice Of Flip-flops & Optimization Trashes Design Testablity
Hi, John,
I have a problem with Synopsys's logic optimisation. How do I stop it
generating logic that is slightly faster than the stuff I want but breaks
certain design rules we have. For example, our library has some Flip-Flops
with Q and NotQ outputs and some with just Q. If we are only using Q then
we should always use the cell with only a Q output, otherwise our testability
figures drop to the floor. Synopsys, however, calculates that using the
two-output cell is faster in some conditions and may also optimise out an
inverter so we have the NotQ output used but the Q output hanging. Can I
get it not to do this?
Also, sometimes, it calculates that a reset flip-flop with its reset tied
off is faster than a non-reset flip-flop. This is also a testability no-no,
so can we stop it doing this, too?
At the moment our non-ideal solutions are:
1. In a given design where the (intermittent) problem occurs, set_dont_use
on the problem cells in the library. (This is what we tend to use.)
2. In a given design, solve the second problem by turning off Synopsys's
latest logic optimisation (obviously the design might lose out in other
ways from this.)
3. We could hack the cell library to guarentee these cells are always
slower, but that fraught with problems.
Anyone have any suggestions?
- Andrew R MacCormack
SGS-Thomson Microelectronics
( ESNUG 268 Item 8 ) -------------------------------------------- [10/9/97]
From: George Lambidakis <lambo@sei.com>
Subject: Seeking HP, DEC, UltraSPARC Workstation Benchmarks Using Synopsys
John,
At our company we have historically used SparcStations and UltraSparcs as
our Verilog and Synopsys engines. Given the nosebleed prices of *certain*
EDA tools, we are curious if other hardware platforms might deliver better
Synopsys performance and, as a result, improve the utilization of our
Synopsys licenses. Sooo.... Has anyone out there benchmarked HP,
Dec-Alpha, and Ultra Sparc's running Synopsys. Could you please share them
with us on ESNUG?
- George Lambidakis
Silicon Engineeing Inc.
[ Editor's Note: As usual, feel free to be anonymous (if you need to) in
responding to anything in ESNUG. Just say it in your reply. - John ]
( ESNUG 268 Networking Section ) -------------------------------- [10/9/97]
Spokane, WA - Packet Engines - ASIC Engineers, 3+ years IC design, gigabit
ethernet experience a plus. Death to headhunters! "daver@packetengines.com"
San Jose, CA - Toshiba: several openings (synthesis, verification, design) in
embedded MIPS uP project. VCS, Synopsys, Chrysalis, etc. "LandmH@taec.com"
|
|
