Editor's Note: It's amazing how a single phone call can change one's
life. Four days ago, my brother down in Florida quit his job to start
a new job beginning next week (Oct. 6th). Out of the blue, he phones
and says "Let's have a family reunion! Times when I have time off like
this are rare, John; let's go surprise the parents in Vermont with a five
day visit!" Of course, I agreed, and now I find I'm running around like a
chicken with its head cut off trying to get all sorts of business and
personal stuff done in four days! Panic! Panic! Even as I'm writing
this, I realize I've got to pick my brother up at the airport in less than
two hours -- but I wouldn't change this rush for a million dollars! Damn,
I gotta pack, too! And make two important phone calls. And pay the rent.
And get the car ready for the drive to Vermont. And... Gotta go! :^)
- John Cooley
the ESNUG guy
( ESNUG 267 Item 1 ) -------------------------------------------- [9/97]
Subject: (ESNUG 263 #1 264 #2 266 #5) *WHO* Is Using Behavioral Compiler?
> My goal for the design was to find the shortest schedule for performing all
> the operations in setting up a triangle for rasterisation on the smallest
> number of arithmetic units. BC, in this respect, is very useful since the
> turn-around time for behavioural code change to reschedule is quite short
> (10-15min) which allowed me to experiment with different latencies and
> throughputs for the arithmetic units.
From: Jonathan Liu <jonathan@ikos.com>
Hi, John,
I'd like to respond to the BC thread by letting everyone know
that within a month we will be taping out 2 chips which are partial-BC
designs. Each chip contains one behavioral block of about 5000 gates,
with the rest of the 50K gates or so being purely RTL (or RTL with
BRT). The application is highly control-intensive, with many SRAM
interfaces and a moderate amount of arithmetic operations as well. The
language is VHDL.
The primary reason we chose to use BC for these blocks was for
ease of specification and for peace-of-mind on design correctness. When
we tried to code them in RTL, the result was an extremely complex state
machine with heavy pipelining, many boundary conditions, and several
thousands of lines of code. When written behaviorally, the state
machine, SRAM control logic, and pipelining were all done automatically,
and it only took about 500 lines of code. Most importantly, it was much
easier to satisfy ourselves intuitively that the code was correct (which
is important, even when the design is heavily simulated). The
performance turned out at least as good as we could have expected in
RTL, if not better.
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!)
The reason we didn't use BC on a higher percentage of the design
was mainly because of design reuse -- it just wouldn't have been worth
it to port all the legacy code that only required minor modification.
I would guess this is another big reason in many companies' for not
switching to BC, as it seems rare now for new design starts to be
totally from scratch.
Next time I personally design a new chip, I would definitely prefer to
do most of the complex (non-reused) blocks in BC. However, I might not
feel the same way if I were managing a large team of RTL designers who
were not yet familiar with the behavioral style.
- Jonathan Liu
Ikos Systems, Inc.
---- ---- ---- ---- ---- ---- ----
From: dtkain@CCGATE.HAC.COM (Dan Kain)
Dear John,
I wanted to provide some feedback to your "listeners" on the
Synopsys Behavioral Compiler (BC) tool. The reason why I tried out the
BC tool was that I was hoping to increase my design productivity by
writing fewer lines of VHDL code at a higher level of abstraction. If
you remember back when Synopsys first came out with their Design
Compiler (DC) tool, we slowly learned that we could be more productive
ASIC designers by writing Synopsys compatible VHDL RTL code and
infering gates instead of instantiating gates with a schematic capture
tool. With that in mind, I thought that BC's new capability of
infering memories may result in my next productivity jump by
eliminating the need to instantiate RAM's inside my RTL code.
Well, I was dissapointed. Yes, BC does let you infer memories, but
it is very difficult to do and I think I can be more productive by
simply instantiating the memories in RTL code. After talking to
Synopsys AE's with regard to the large overhead "cost" of inferring
memories, the response I received was that it was very difficult to
support memory inferencing today due to the large quantity of
different types of ASIC memories presently available. My response to
this was that I was personally willing to reduce my choice with regard
to memory types if I could then very easily infer them in my VHDL code
to obtain the productivity improvement I so dearly desired.
Unfortunately, I do not think Synopsys has any near term plans to make
memory inferencing an easy task to perform.
Two features of BC that worked well for me were it's transform_csa
(BOA) and optimize_registers (BRT) commands. Don't ask me why Synopsys
had to come up with two names for each of these commands when one name
each would suffice. I guess from a marketing point of view, saying we
added this new BOA feature to the tool sells better than saying we
added the transform_csa command to the tool. Also, don't ask me why
Synopsys requires you to buy a BC license to run these commands since
they run perfectly find under DC shell (when you have a BC license).
The neat thing about these commands is that they synthesize pipelined
multiplier/adder trees much more efficiently than simply using
Synopsys designware.
In all fairness to Synopsys, they really did not market BC to me as
a memory infering tool or for its BOA/BRT capabitlities. They instead
marketed BC as a architectural trade-off tool for multi-cycle designs.
Synopsys was trying to sell to me that if I used their new BC tool I
would then become a more productive ASIC designer (ie super ASIC
designer) by enabling me to perform architectural trade-offs on
multi-cycle designs at the behavioral level of abstraction. The only
problem was that to date, all my designs have simply been single cycle
designs and so I really did not have a need for BC's architectural
trade-off capability. End of story.
- Dan Kain
Hughes
( ESNUG 267 Item 2 ) -------------------------------------------- [9/97]
From: [ I Can't RTFM ]
Subject: Synopsys Library Developer Documentation Too Ambiguous
Hi John,
Keep me anonymous (due to company politics.)
I am a synopsys library developer. I face problems in interpreting the
synopsys documentation correctly. Frequently - I find contradictions
within the documentation. Sometimes - parts of the documentation are not
updated properly. Example:
At one place doc says recovery/removal is not checked by DC.
Another place - they list a variable that can enable compile to
use recovery/removal information.
Ditto for statetables. I had trouble finding out which synopsys tools
actually use statetables and how. Similarly - whether or not write_timing
writes out conditional delaypaths is unclear. Synopsys says it doesn't
while I see it writing conditional delays in the SDF file.
I wonder why nobody else ever cribbed about synopsys documentation.
Guess everyone just uses solv-it (which, incidentally, is very useful.)
- [ I Can't RTFM ]
( ESNUG 267 Item 3 ) -------------------------------------------- [9/97]
From: "Tom Cruz" <cruz@VNET.IBM.COM>
Subject: Has Anyone Else Used The New Synopsys ECO Compiler?
Hi John -
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
( ESNUG 267 Item 4 ) -------------------------------------------- [9/97]
Subject: ( ESNUG 264 #1 265 #2 266 #4) Synthesizable IP Is *Unprotected* IP
> Here is an idea for solving ASIC vendors "soft" IP being reused with other
> ASIC vendors as a target: As most IP is in ASCII form - EDA vendors need to
> support standard key based encryption for reading/writing ASCII files. The
> technology name that the tool is using must match that encrypted into the
> key. The use of the keys themselves would be licensed using standard unix
> license keys. The ASIC vendor would the license use of the IP for a given
> technology and timeframe using the combination of keys.
From: jon.connell@hl.siemens.de (Jon Connell)
John,
Putting aside the fact that encryption is worthless as ITAR currently
stands, a well timed core dump will leave you with the entire ASCII
data in unencrypted form. As Hank Walker said, this is simply a
licensing issue - and if you can't rely on a license agreement, you're
stuck because you definitely *cannot* rely on encryption.
- Jon Connell
Siemens Semiconductors
---- ---- ---- ---- ---- ---- ----
> On one hand, we want to distribute IP to our customers, so they
> can synthesize them to gates, adjust the synthesis to meet their
> own constraints, and simulate with back annotated information
> the entire ASIC. On the other hand, we want to guarantee that our
> customers cannot copy the IP and make their own, *AND* we do not want
> them to be able to simply re-synthesize to another process after we have
> completed the design stage with them, and then fab it somewhere else.
From: [ Name Withheld By Request ]
John,
You know my sordid history with Synopsys, Inc... keep me anonymous!
Working for a non-TI semiconductor manufacturer, I can feel this guy's pain.
On one hand, the customer is demanding more IP (processors, peripherals,
RAM, ROM, software drivers, BIOS, etc.) and more customer support.
Unfortunately, too many times, the customer is also unwilling to pay any
additional dollars for this IP. The customer views this IP almost like
fab space, as a cost of doing business. Additionally, the customer will
not even commit to a program if the IP is developed specifically for him.
Again, more of that cost of doing business. My company has had customers
where WE developed a complete solution, making marginal NRE dollars for
the effort, only to have the project cancelled with no production.
Protecting the IP from "walking away" is a tremendous problem. I am
generally reluctant to release synthesizable code to the customer. Hard
designs (those with optimized layouts) should not be released in a
synthesizable format. They may have hundreds of hours of physical design
effort in them that is lost of the customer resynthesizes the design.
If a customer walks with my IP to avoid royalties, there is really no
way to track it. I can't call up the other semi house (if I even know
who it is) and say, "Send me XYZ's Super Chip, I want to scope it to
see if my 15000 gate IP is hiding in their 2.5 million gates."
It is my general opinion that there is tremendous pressure to avoid
royalties and 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. Some
customers expect us to run "negative" margins to show how important they
are. In those cases, we try to make it up in volume!
Finally, protecting the investment in IP is critical to ANY business. It
is not at all childish. Perhaps Mr. Lindsay should go ahead and post all
of his design files on the BA-A public ftp server. Semiconductor
manufacturers have the same financial responsibilities to their stockholders
as any other company. With *billions* of dollars in production facilities,
semi companies have a tremendous responsibility to protect that investment
alone. Contrary to the apparent popular belief, you really can't run a fab
on 10% profit margins.
Just my .35 microns.
- [ Name Withheld By Request ]
---- ---- ---- ---- ---- ---- ----
> Financial incentive could also be used to encite customer to stay with TI
> for the manufacturing. For example, royalties could be waved if the IP
> is manufactured with them. ... Encryption and licensing should not get in
> the way of getting value out of purchase. ...
>
> I'm sorry, but from the other side of the world all this IP protection
> stuff sounds really childish. In the end, if there are not enough swings
> and roundabouts for everyone then the least popular kids will just have
> to go and play somewhere else. (Although I suspect, given the way things
> are, they'd organise a protest rally and either get the council to build
> more roundabouts or get the park closed down so nobody could play).
>
> - David Linsley
> British Aerospace Australia
From: dchapman@goldmountain.com (Dave Chapman)
OK, folks, this is a re-run.
Anyone who remembers the IBM PC/XT remembers all the whines from the
software vendors about pirating and how copy protection was necessary
and blah-blah-blah, but the bottom line went something like this:
1. The customers all hate copy protection.
2. The customers will buy copy-protected software if-and-only-if
they cannot get the equivalent in real software.
3. Even if they buy your copy-protected stuff, they will hate you for it.
4. As soon as a competitor with a non copy-protected version
of whatever it is appears, they will desert you en masse.
5. If you subsequently, reluctantly remove copy protection, very
few of those who switched will switch back, because they hate you.
(See point #3, above).
6. The customers all hate copy protection.
If you are asking the question at this point "But, WHY do the customers
all hate copy protection?", then you are desperately in need of a clue.
If you are asking the question "But, do the customers REALLY hate copy
protection?", then you are hopelessly fucked up and need to find another
career.
There are a few ways for foundries to make money on IP:
1. Run it as a stand-alone business.
2. Give it away, as a form of advertising. Copyleft.
3. Offer it not copy-protected, with no royalties for those
who use your fab. (The aggrivation of having the bean counters
pay royalties will cause everyone to use your fab. It is
astounding how much muck, turmoil, and expense a company will
endure in order to not pay $5 in royalities.)
The business model which has been adopted by the ASIC software companies was
used by the mainstream software companies 12 years ago. It failed then.
It will fail now.
Want proof? Borland was selling both a copy-protected version and
a non-copy-protected version of Sidekick for a while. Despite having
a higher price, the non-copy-protected version was over 90% of sales.
As a side comment, I think that the current crop of IP vendors has a bad
case of megalomania. Where are the people supplying IP versions
of a 16550, or a Zilog SIO? What we see are PC-on-a-chip things, or
PCI bus interface modules, which are going to take up 80-90% of the gates
on my chip. Forget it. Unless I am making 500,000 of the thing,
it is cheaper and faster to use an external PCI chip and use the
ASIC strictly for glue logic.
What we need around here are IP modules with no copy protection crap,
incorporating between 1000 and 10,000 gates which do something I need
to have done, WHICH could NOT reasonably be done WITH AN EXTERNAL PACKAGE.
I can rant some more, upon request.
- Dave Chapman
Goldmountain
( ESNUG 267 Item 5 ) -------------------------------------------- [9/97]
Subject: (ESNUG 264 #7 265 #4 266 #3) Cheaper Use of Synopsys Licenses
> This may be helpful:
>
> hdl_keep_licenses = "false"
>
> When this variable is false, hdl licenses are released during execution of
> compile, after compile has completed the subtasks that require the license.
From: Atle Haga <Atle.Haga@nvlsi.no>
Dear John,
I have been trying to squeese (V)HDL licenses for several months but it
was just not worth the effort. Using the hdl_keep_licenses is nothing new,
it was there several years ago. The problem is that compile will need
the license not only during the first part of the compile (for the DW parts),
but sometimes later in the compile phase it can be checked out again!
This is depending on your timing budget and use of DW parts. If the
compiler does not get the (V)HDL license when required, you get a WARNING
that your syntesis results will be of inferior quality. The only way to
avoid this is to ungroup the DW parts before compile which will totally
remove the nice structure of a DW part. This means that for timing critical
and complex aritmetic it will not work to share one (V)HDL license. Anyway,
Synopsys should be able to tell the current status of this topic since
there is no need to get more unhappy customers...
I discussed this very much with the local Synopsys support people, and due
to the undeterministic use of the (V)HDL license the best is to have one
(V)HDL license for every DC license.
( BTW, this was two years ago, in another company, it might have changed
since then. )
- Atle Haga
Nordic VLSI ASA
( ESNUG 267 Item 6 ) -------------------------------------------- [9/97]
From: Scott Nogueira <Scott.Nogueira@sv.sc.philips.com>
Subject: Synopsys Version 1997.08 -- To Use Or Not To Use?
Hi John,
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.
- Scott Nogueira
EDA Plus Inc., working at Philips Semiconductors
( ESNUG 267 Item 7 ) -------------------------------------------- [9/97]
From: Alon Oren <alono@dsp.co.il>
Subject: How Do You Get An ITS Formatted File Out Of Synopsys?
Hello, John,
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?
- Alon Oren
DSP Semiconductors, ISRAEL
( ESNUG 267 Item 8 ) -------------------------------------------- [9/97]
From: Victor_Duvanenko@truevision.com (Victor Duvanenko)
Subject: Tricking DC Into Giving You High Speed Comparitors
John,
A tidbit for the speed-desparate... If you only have the basic DesignWare
license and care about speed then you'll care about this message. If you
compile without "-ungroup_all" then you can use "report_resources" to
find out the implementation that Synopsys chose for every operation (e.g.
ripple, or carry-look-ahead, etc.).
The basic DesignWare gives you CLA implementations for adders, subtractors
and incrementors. However, it does not provide CLA for comparisons (e.g.
"if ( A > B ) then ). If you care about speed, these comparisons
are critical, and as you all know, a comparison is really nothing more than
a subtraction that pays attention to the carry-out bit. So, to speed up
your designs do something like the following:
Tmp := ( '0' & A ) - ( '0' & B )
if ( Tmp( Tmp'high ) = '0' ) then ...
This will result in a faster implementation, since Synopsys will hopefully
choose the CLA for the subtractor, which you're licensed for. I think it is
very unfortunate for the user comunity that Synopsys chose not to provide
the CLA implementation for comparisons (but, provides them for adders and
subtractors). I actually don't quite understand why they even need to do
anything special for comparisons -- they could have just implemented
it as a subtraction and there would be no need for this nonesense at all.
Maybe Synopsys could fix this, or for the VHDL guys, maybe we'll have to
overload the comparisons operators to get around this in a more readable
fashion.
- Victor J. Duvanenko
Truevision
( ESNUG 267 Item 9 ) -------------------------------------------- [9/97]
Subject: ( ESNUG 266 #7 ) Disable "Max Fanout" Warnings Just On Clocks?
> How do you disable max-fanout-exceeded warnings on clocks that show up in
> report files? We care about these warnings only for non-clock signals.
> We've tried a number of things without success. Thanks.
>
> - Bob Alfieri
> SGI
From: Ajoyka@aol.com (Ajoy Aswadhati)
John, Trying
dc_shell> set_drive 0 find(port, "clk")
should fix this problem. This will make synopsys think that the port "clk"
has an infinite drive. You could use this command for any ports that you
do not want synopsys to buffer up, too.
- Ajoy Aswadhati
ASIC/EDA Consultant
( ESNUG 267 Item 10 ) ------------------------------------------- [9/97]
From: Mark Prizant <mprizant@draper.com>
Subject: Why Use Synopsys When There's The Altera Max-Plus II Compiler?
Hi, John,
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.
- Jay Prizant
Draper Lab
( ESNUG 267 Networking Section ) -------------------------------- [9/97]
Austin,TX - LS2 IC design center seeks a CAD Eng. w/ 5+ yrs exp. w/ Cadence
and Synopsys. SysAdmin a plus. Death To Headhunters! "schaefer@ls2.com"
Burlington, VT - Pixel Magic - ASIC Engineers, 2+ years IC design, image
proc/coding, sym, synth exp. No headhunters. "schipani@pixelmagic.com"
|
|
