[ Editor's Note: I got a chuckle from this. Enjoy. - John ]
"The Engineers Song"
(Sung to the tune of THE BEVERLY HILLBILLIES)
Come and listen to a story bout a man named Jed,
A poor College Kid barely kept his family fed,
But then one day he was talking to a recruiter,
He said "They'll pay ya big bucks if you work on a computer",
VAX that is... CRT's... Workstations...
Well the first thing ya know ol' Jed's an Engineer,
The kinfolk said "Jed move away from here",
They said "Arizona is the place you oughta be",
So he bought some donuts and moved to Ahwatukee,
Intel that is... dry heat... no amusement parks...
On his first day at work they stuck him in a cube,
Fed him more donuts and sat him at a tube,
They said "Your projects late but we know just what to do,
instead of 40 hours, we'll work you fifty-two!"
OT that is... Unpaid... Mandatory...
The weeks rolled by and things were looking bad,
Some schedules got slipped and some managers were mad,
They called another meeting and decided on a fix,
The answer was simple, "We'll work him sixty-six",
Tired that is... Stressed out... No social life...
Months turned into years and his hair was turning gray,
Jed worked hard while his life slipped away,
Waiting to retire when he turned sixty-four,
Instead he got a call and they escorted him out the door,
Laid-off that is... Debriefed... Unemployed.
-- author unkown
( ESNUG 264 Item 1 ) -------------------------------------------- [9/3/97]
From: Steve Korson <skorson@asic.sc.ti.com>
Subject: Synthesizable IP Is, By Definition, *Unprotected* IP
John,
I have a few questions/comments about IP protection which were not directly
covered in your article in the Dec. 96 issue of "Integrated System Design"
titled "SPY vs. SPY: the VMC Story". [I know its an old article, but I have
just recently transferred into this role.]
In your article, you consistantly refer to the lack of ability to be able
to synthesize protected IP as a drawback. I would agree with that if there
were a way to allow the user of my IP to *only* synthesize the IP into my
technology.
As a foundry *and* a supplier of IP, we are finding ourselves in the IP
Protection arena being pulled towards two seeming mutually exclusive goals.
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. We would rather not have to perform the synthesis
of our various IP. That would require much effort to maintain the
IP on the various technology nodes, for various power/area/speed
tradeoffs etc.
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.
These two 'wants' are mutually exclusive. I would like to hear
about how 'protected' synthesizable protected IP really is. Given
the two, I think we would rather give up on the Synthesis portion
than risk the production to someone else. Hence why I am leary
of protection schemes which are synthesizable.
Perhaps, with VCM and Synopsys working together, a method of encrypting IP
with a target synthesis library isn't far off. However, the problem then
becomes that in order to synthesize IP, the designer needs access to the
various paths and structure of the design. If a designer has this, he can
dump out the gate level structure and ... we are back where we started.
Anyone have any thoughts as to how a customer could have access to enough
information to synthesize protected IP without having access to the entire
structure?
Finally, since the task seems quite daunting, perhaps our 'wants' are what
needs to be changed? Is there another way?
- Steve Korson
Texas Instruments ASIC
( ESNUG 264 Item 2 ) -------------------------------------------- [9/3/97]
Subject: (ESNUG 262 #4 263 #1) Exactly *WHO* Is Using Behavioral Compiler?
> Dear John,
>
> I do not believe the synopsys advertisements about the performance and
> results of its behavioural compiler.
>
> - David Barda
> CAST laboratory
From: [ Afraid Of My Motorola Bigwigs ]
Hi John,
My name is [ deleted ]. I work at the [ deleted ] division of Motorola.
I heard about the ESNUG posting that dismisses Synopsys Behavioral Compiler
as not being real yet and felt compelled to respond. Our network has a
firewall so I don't have direct access to ESNUG. Would you please post my
response below anonymously. It is very key that my name not be used nor
my division's name used associated with this posting because our bigwigs
have a policy against vendor endorsement.
I understand that Synopsys Behavioral Compiler has recently been dismissed
as not being "real" yet. Based on my experience for the last year working
with Synopsys Behavioral Compiler (BC), I strongly believe that BC is now
sufficiently reliable and efficient to produce low-power, area-efficient
high-volume ASICs. BC did not meet our needs for production ASICs one year
ago, but it does now and we plan to tape out a chip in @ 1 month with the
biggest and most complex block on the chip generated using BC.
I have done an extensive evaluation of BC over the past year, comparing
manual RTL to BC output for 5 blocks that have significant amounts of
datapath, memory, and control. The blocks generated using BC were within
@ 5% of manual RTL in terms of both area and power. But the true strength
of BC is that it enables the designer to spend more time in architectural
exploration and find the best architectural trade-off. Using BC I had
time to develop an architecture that was @ 25% less power than the best
architecture that I had implemented in manual RTL.
BC still requires hardware design expertise to produce very high quality
ASICs (@ 5% of manual RTL), but if the application is less cost-sensitive,
then less hardware design expertise is needed with BC. There is room
for further improvement in BC documentation, error diagnostics, and analysis
information. But from my experience, I found that BC now gives @ 2X
productivity improvement over manual RTL and BC can give area and power
within @ 5% of manual RTL.
- [ Afraid Of My Motorola Bigwigs ]
---- ---- ---- ---- ---- ---- ----
From: [ Texas Instruments, Too! ]
Hi John.
I saw your latest ESNUG mail about BC.
I just wanted to let you know that we just taped out a 270K ATM device
running at 58Mhz that was designed with BC.
Amazingly we had 1st pass layout success, easily achieving the customer's
timing.
Quote from customer: "All Postlayout timing was better than Prelayout
timing".
Please treat this anonymously.
- [ Texas Instruments, Too! ]
---- ---- ---- ---- ---- ---- ----
From: [ I Don't Like Lawyers ]
Hi John:
I've heard a lot of people asking about Behavioral Compiler. Here's my
experience, for the record.
In 1994, I brought in BC with the intention of spending four weeks trying
to apply it directly to my current ASIC design. I worked with an
Application Engineer and spoke quite a bit with Synopsys BC guru's on the
West Coast. After 4 weeks I had produced nothing useful so I abandoned it.
Synopsys was apparently very shocked. They claimed that BC was being used
by all of our competitors. They also blamed the lack of results on the
fact that I did not attend proper training.
I waited 3 years. I was starting a new project and brought BC in again.
It seemed to have matured a bit and the AE's were competent. They
also had an example design similar to my architecture. The deal was
that I would go to a BC training class (which I did). Then I would write
the behavioral code and testbench (which I did). They would "BC" it and
give me back an RTL model and gate netlist which passed the testbench. At
that point I would be obligated to purchase the tool (as long as there were
no surprises). Everyone agreed that this was a perfect target design for BC.
For 6 months they worked on the design. They said over-and-over that they
almost had the RTL working. I finally ended it. Again they were surprised.
I never received a report or explanation for the lack of results.
This is a very honest statement of what happened.
You can draw your own conclusions.
I can only conclude the tool does not work. I am not out to slander
Synopsys - I just felt obligated to share my experience with this tool.
By the way, even if the tool worked ... After writing BC-compliant code
and a testbench, I am not convinced yet that my algorithm is more readable
or compact. We went through many iterations of recoding in order to try
to get BC to correctly handshake with the testbench. The code was difficult
to debug since the entire algorithm was executed in a single cycle. This
forces you to insert lots of debug statements and use source code debug
tools. With RTL it's very easy to see intermediate results between clock
cycles.
Please keep me anonymous.
Thanks.
- [ I Don't Like Lawyers ]
( ESNUG 264 Item 3 ) -------------------------------------------- [9/3/97]
From: Terry_Hussey@3com.com ( Terry Hussey )
Subject: DC -- 1.5 Hours Of "Design Rule Compile" Now Takes Over 24 Hours!
Hi John,
I am experiencing a problem in 97.01 (also in 97.01-01_44683) that I am
hoping someone else might understand (or at least have seen).
I have a design, the top level of which compiled under synopsys3.4b in
roughly 1.5 hours. The top level compile is very simple; I've simplified it
further so that it is just a "link" followed by a "uniquify", followed by a
"compile -only_design_rule". In 3.4b, most of that 1.5 hours is used
fixing design rule violations.
In both 97.01 and 97.01-01_44683, that same compile takes over 24 hours
(basically 24 hours fixing design rule violations). I have tried this
using vendor libraries which were designed for 3.4b and new vendor libraries
designed for 97.01. Again, most of the time (basically 24 hours) is spent
fixing design rules.
I am wondering if anyone has seen this type of thing or can suggest any
experiments. I've tried a number such as always using "best case tree",
turning off automatic wireload selection which chose a chip level wire
load (enclosed mode) and instead chosing a very small wire load.
Thanks,
- Terry Hussey
3Com Switching Division
( ESNUG 264 Item 4 ) -------------------------------------------- [9/3/97]
Subject: (ESNUG 263 #5) Seeking Tips For Efficient Adder Carry Out Designs
> A question for ESNUG readers. In February, at SNUG, I learned about the
> "hdlin_use_cin = true" switch to coerce Design Compiler to use the
> carry-in input on synthesized adders. Is there a similar switch to coerce
> Design Compiler to use the carry-out output on adders? How do ESNUG
> readers get better carry-out results when HDL coding for adder-inference?
From: Zia Khan <zkhan@pcocd2.intel.com>
John:
In your recent ESNUG someone mentioned that using the hdlin_use_cin flag
is helpful. Can you throw more light on it? (e.g. what does it do, what
are the benefits, any particular info on the most appropriate time
to use it?)
Thanks,
- Zia Khan
Intel Corp
( ESNUG 264 Item 5 ) -------------------------------------------- [9/3/97]
From: [ A Synopsys DC CAE ]
Subject: A Heads-up On DC v97.01 Generating Incorrect Logic
Hi John,
I just want to give you a heads-up on 1997.01. Just in case you have users
writing to you about this problem. Below is a Solv-It article posted that
describes the problem. We are also planning a cluster release for 1997.01
(a group of STARs have been fixed) which will replace the original 1997.01.
The first customer ship date was 6/97 and the release was called
1997.01-44683. Subsequent releases already have this fixed.
PROBLEM:
v1997.01 might generate incorrect logic when using the new
boolean structuring algorithm.
DESCRIPTION:
A problem was found with the new boolean structuring algorithm,
which might cause incorrect logic to generate using Design
Compiler v1997.01. If you use v1997.01 without boolean structuring,
you will not encounter this bug. There are two reported cases and
the problem has been isolated and fixed. The problem only happens in
the new boolean structuring code and has no effect on the overall
quality of Design Compiler v1997.01. The problem cannot be characterized
to a specific design style.
SOLUTION:
If you use boolean structuring in v1997.01, please be sure that
you use the "-verify" option of compile or compare_design to
validate the logic generated.
The problem is fixed in v1997.01-44683. The date of this release
is 5/97. This release will be shipped to all Synthesis customers
starting mid-June 1997. An early release will be made available
through Electronic Software Transfer (EST) starting early June.
Contact your account team for more information. Synopsys apologizes
for any inconvenience this might have caused.
Hope this helps.
- [ A Synopsys DC CAE ]
( ESNUG 264 Item 6 ) -------------------------------------------- [9/3/97]
From: "Frederick K. Best" <fbest@slr.orl.mmc.com>
Subject: Code Reuse Going Verilog to VHDL Using Synopsys & Summit Design
John,
I want to reuse some Verilog code that meets timing that uses the same clock
and technology as my design. The problem is that my design and testbench
are both in VHDL. So I wrote out the Synopsys elaborated verilog code as
VHDL. Then I used it in my design in a Summit Visual HDL enviroment with
no problems. In Synopsys, it analyzes with no problem, then it has errors
in elaboration. What methodology do you suggest I use for reusing Verilog
in a VHDL design? This is the script I used:
analyze -format verilog ./VEH_SIM.v
elaborate VEH_SIM
current_design DOWNLINK_0
change_names -rules "vhdl" -hierarchy
write -format vhdl -hierarchy -output "Downlink_0.vhd"
And here's what I got:
Imported Downlink_0.vhd into Summit Visual HDL and instantiated it
into HL_IF
Imported all needed GTECH VHDL source code into Summit Visual HDL
Sucessfully testbenched imported code
Exported code to Synopsys
Sucessfully analyzed code
Error in elaboration:
elaborate HL_IF
Information: Building the design 'DOWNLINK_0'. (HDL-193)
Information: Building the design 'Downlink_FSM_0'. (HDL-193)
Error: Cannot determine type of the aggregate
in routine Downlink_FSM_0 line 1459 in file
'/synopsys/vhdl/HL.vhd'
(This error can occur if an aggregate and a generic appear in the
same component instantiation.) (HDL-206)
Warning: Unable to resolve reference 'Downlink_FSM_0' in 'Downlink_0'.
(LINK-5)
Regards,
- Fred Best
Lockheed Martin Electronics and Missiles
( ESNUG 264 Item 7 ) -------------------------------------------- [9/3/97]
From: Ori Chalak <oric@actcom.co.il>
Subject: Using A Creative Mix Of Synopsys Licenses To Save $$$
Hi Jhon,
Thanks for the articles the Q, A and fun in ESNUG.
I have a "thrifty" question: Do you know if the HDL-Compiler licenses are
used only during the "read" and "write" in dc_shell or is it sometimes
invoked during "compile"? My thought is of saving some $'s by buying one
HDL-Compiler for several Design-Compiler licenses. Will this work or have
some of your readers found some problems with this approach?
Thanks,
- Ori Chalak
Analog Devices Israel
( ESNUG 264 Networking Section ) -------------------------------- [9/3/97]
Houston, TX - Texas Instruments - DSP Design Seeks ASIC Engineer 3+ years exp
with VHDL & Synopsys. 200mhz designs. No agenices "males@micro.ti.com"
Mountain View, Ca - Acuson seeks CAE eng. for Verilog/VHDL design, capture
& simulation for ultrasonic imaging. No headhunters. "mikem@acuson.com"
San Jose, CA -- 3Dfx Interactive seeks ASIC Engineer with 2+ years exp.
w/ Verilog & Synopsys. No agencies. "winner@3dfx.com"
|
|
