Editor's Note: Although it's quite common to find all sorts of EDA
customer experiences (both good & bad) in ESNUG, every now and then
my readers will send me an unexpected "scoop" -- a story that no one
has mentioned before -- and my pompus Holier-Than-Thou side cheers.
Why? Because I'm fulfilling ESNUG's sacred mission to tell my readers
the "rest of the story" -- you know, the stuff that the EDA salesdroids
fail to inform you of right before you're about to sign that Purchase
Order form...
And, I'll also admit that I'm a little bit part "Bart Simpson" who's
saying "Oh, Baby! Forbidden knowledge! Cool!", too, when I get one of
these "scoops". (Hey, I'm only human.)
One such scoop happened when Synopsys released Test Compiler and ESNUGs
133 to 190 were swimming with Test Compiler bugs for months. (And, to be
fair, when Synopsys R&D finally cleaned up Test Compiler, ESNUG 212
reported TC 3.2a's vast improvements.) Another scoop happened when a
Synopsys user reported finding 800 pages of Synopsys on-line docs about
something called "Protocol Compiler" -- an unannouced product! And,
proudly, ESNUG 260 had an anon user paper critiquing Protocol Compiler!
I'm now proud to announce that today's ESNUG contains a detailed anon user
critique of another unannounced pair of Synopsys products: CoreBuilder
and CoreConsultant (see Item 1 below). I laughed when I read the user
review because these two new Synopsys tools were obviously the result of
the Synopsys DesignWare PCI fiasco. Essentially, in mid-1995, Synopsys
and Intel made a big hoopla in the trade press about their new, joint
DesignWare PCI part. "It's the wave of the future of design!", yada,
yada, yada... A few months later, and after some major customer buy-in,
ESNUG 229 & 230 had users (another scoop!) openly reporting in technical
detail their horror stories using the DW PCI part. It simply didn't work!
Synopsys pulled the part from the market. The 20 or so Synopsys R&D
engineers responsible eventually left the company. Aart De Geus, the
CEO of Synopsys, took personal responsibility and made sure that each
customer who had foolishly bought the DW PCI part had a working PCI
implementation in their respective chips. An honorable recovery, but
in the end there was still no way to transfer complex IP to buyers.
So what's CoreBuilder and CoreConsultant? They're a new way for
IP makers to ship really complicated IP to users. Scoop! Yeah! :^)
- John Cooley
the ESNUG guy
( ESNUG 314 Subjects ) -------------------------------------------- [3/99]
Item 1 : One User's Critique Of The CoreBuilder & CoreConsultant Tools
Item 2 : (ESNUG 313 #17) Should I Go To SNUG'99 Or To DAC'99?
Item 3 : (ESNUG 311 #8) Diff Port Maps w/ 2 Levels Of VHDL Wasn't Flagged?
Item 4 : A Rose In Not A Rose Is Not A Rose -- Comparing Gate Counts In DC
Item 5 : (ESNUG 311 #1) Crack FLEX-lm? Go To Jail, Directly To Jail
Item 6 : (ESNUG 311 #10) Engineers Doing 'Chip Doodling' On The Raw Dies
Item 7 : (ESNUG 311 #6) Incremental DC Compiles Wrecks My Timing !!!
Item 8 : (ESNUG 308 #1) Regarding The New TCL Interface To Design Compiler
Item 9 : Want Opinions On Summit vs Escalade For Design Capture, Sim, FSMs
( ESNUG 314 Item 1 ) ---------------------------------------------- [3/99]
From: [ The Horse With No Name ]
Subject: One User's Critique Of The CoreBuilder & CoreConsultant Tools
John,
Please keep me very anonymous in this post. Very anonymous.
I've just spent the a couple of days working with Synopsys' CoreBuilder and
CoreConsultant tools. I've seen the presentation a few times now, so was
looking forward to trying them out. As part of my job I have to deliver
IP to customers, so it's important to me how the IP is delivered. The
easier I can make it for them, the less time I spend on the phone sorting
out tedious problems.
What did I think of it?
Well, it's cool. I liked it. Not something I often say after the first
use of an EDA tool.
So, what happened? I was given an alpha version of CoreBuilder and beta
version of CoreConsultant, and 5 days worth of training course slides to
explain what I should be doing with it. That suits me fine - I'd much
prefer to be given something to play with, rather than sit and learn all
about it before being allowed to play with it! They basically work like:
IP Maker IP Buyer
---------- ----------------
(e.g. MIPS ) (e.g. Hewlett-Packard)
CoreBuilder --> CoreKit files --> CoreConsultant
captures IP into (encrypted in converts CoreKit files
CoreKit files .kb format) into gates
I jumped in at the deep end and decided to use the CoreBuilder (The IP
developer tool) to package up a block that I'd worked on in a recent project.
I fired it up, which incidentally looks just like the CoreConsultant tool,
dove into the first of the configuration stages -- blam!, the tool crashes!
Damn. Which brought me neatly to my first conclusion: it sure is an Alpha
version of the tool. But then, it was described as Alpha.
It turns out that it was a minor problem mapping working directories onto
physical directories. Once I stopped trying to be clever it worked fine.
Onto the second step: including the RTL blocks that make up our design.
My first pass complaint about some of the stages of CoreBuilder was precisely
that it is a graphical tool. Going through entering all of the RTL blocks
was dull. Most days I'd trade Emacs for almost any GUI for repetitive data
entry. However having done this the hard way the first time round, I've now
figured out how to make a lot of it easier on most of these stages by
importing things from files. (OK, OK, I should have read the documentation
and spotted that there's a Tcl command line interface.)
It's in the next set of stages that things get clever. By including pragmas
in your design you can put configuration options into your CoreBuilder RTL,
and have them appear as dialogue boxes in the CoreConsultant tool.
CoreBuilder reads the pragmas and presents you with a little spreadsheet
to adapt these as required for CoreConsultant. You can chose between check
boxes, radio buttons, and parameters with allowable ranges. It's good stuff.
Setting up something reasonably complex with all the different types of
options was pretty simple.
In subsequent stages more of the design intent is captured. Identifying the
clocks, identifying any asynchronous reset signals -- all the usual stuff
that you'd have to do writing the DC synthesis scripts -- except I didn't
have to write a single line of script -- anywhere. By specifying a few
attributes about the design while in CoreBuilder (e.g. does it have muxes?
does it have arithmetic stuff?) CoreConsultant then later automatically
drives Design Compiler to get good results. After that, you then capture
the I/O set-up and hold times. The tools are (as far as I can see) very
much configured for top-down constraints -- not that that's a bad thing.
Parameters can be either specified as absolute times, or my preferred way,
as a percentage of the cycle time.
The later stages of the CoreBuilder process are all about determining what
should go into the design kit, if you need help URLs and putting together
the whole kit, but I'll skate over that to get onto the other side of the
tool, CoreConsultant. At the end of the CoreBuilder checklist you have
yourself a 'knowledge base' (Synopsys-speak for all of these things you've
entered captured into their strange encrypted CoreKit file format.)
Now the moment of truth -- it's all very well capturing this information,
what can you do with it? The CoreConsultant tools runs like an automated
unzip process, unpacking the design and then dropping into a checklist of
stages that the IP buyer has to go through to be able to synthesize the IP.
Here's what the checklist looks like:
Specify Target Technology X
Specify Configuration X
Specify Context Information X
Specify Design Intent X
Specify Port Intent X
Verify Budgets X
Specify Synthesis Strategy O
Synthesize O
Analyze Results O
[ Express Lane ]
[ OK ] [ HELP ]
All of the things that you'd have had to edit the scripts to change you're
led through by the tool. Target Technology == selecting libraries, wiring
load models, operating conditions. One of the good things about
CoreConsultant is that it is sensible about doing this. Having selected the
library, it doesn't give you a blank choice of models, but a pull down list
of the available options. It's not rocket science, but it's a good
practical way of avoiding those silly mistakes that cause scripts to crash
just after you turn your back on them. Configuration == the implementation
specific parameters. (e.g. "RAM size: 64 kbyte or 128 kbyte?") There's
parameter checking and it disables parameters when appropriate. Once you're
done with the configuration, CoreConsultant generates your specific RTL,
testbenches for the RTL, and documentation. Context == clock and reset
signals in your chip. Design Intent == block by block info for synthesis.
(e.g. synth for speed on block X and for area on blocks Y & Z.) Port
Intent == top level I/O constraints. Verify Budgets == makes sure everything
is constrained for synthesis and these constraints make sense. The rest
of the checklist (Specify Synthesis Strategy, Synthesize, Analyze Results)
is mostly just fancy, multi-choice GUIs driving Design Compiler.
Personally I don't get a kick out of writing or hacking Synopsys DC scripts
(sorry, John) so I like the CoreBuilder/CoreConsultant combination because
it lets me get on with the business of designing interesting things, in a
style which will synthesize well.
All in all, despite being an Alpha/Beta release of the tool -- and it sure
shows in some places -- I'm impressed. A lot of thought appears to have
gone into the tool to make sure that you're lead through the process that
you'd have to go through anyway, but with less opportunity to get things
wrong. If you want to go the whole hog and have help files and the works,
then that's fine, too -- there are options for help URLs in all kinds of
places. As someone who does have to hand off IP to other people (and has
learned the hard way that, if someone can get it wrong, someone will), I
think I'd much prefer to deliver IP packaged this way.
It's good stuff. I think IP buyers will look forward to the end of grubbing
round in someone else's RTL and scripts, trying to figure out where they've
hidden that last parameter.
- [ The Horse With No Name ]
( ESNUG 314 Item 2 ) ---------------------------------------------- [3/99]
Subject: ( ESNUG 313 #17 ) Should I Go To SNUG'99 Or To DAC'99?
> I'm a self-employed consultant who has to pay his own way to any conference
> I attend. Should I spend my money going to the upcoming SNUG'99 or on
> DAC'99 in June? I'm interested in "technical", not "industry" stuff. Are
> either of these conferences worth it?
>
> - Greg Bell
From: "Clifford E. Cummings" <cliffc@sunburst-design.com>
John -
I too am a self-employed consultant (like you and Greg) and I believe SNUG
is the best technical conference, period.
It also happens to be one of the more affordable conferences. I must admit
that I am on the SNUG technical committee, but I only joined last year
after attending SNUG for the past four years. The quantity of good papers
that have been submitted this year is great.
My take on conferences is:
SNUG - by far the most technical and the best. Great focus on HDL and
synthesis techniques and issues.
IHDL (former IVC) still pretty good, but a fair number of marketing and
purely academic presentations.
DAC - best trinkets conference, a big party, lots of secret vendor
suites, interesting ESNUG follow-ups, but the papers are all over the
map. There are some good papers if you look hard enough.
Just one opinion.
- Cliff Cummings
Sunburst Design Beaverton, OR
---- ---- ---- ---- ---- ---- ----
From: David C Black <dcblack@qualis.com>
John,
I was surprised recently when a client told me that they recommended SNUG
to their verification co-workers as the best technical conference to
attend. I believe they are planning to attend. That's quite a statement
for a group that doesn't use synthesis.
- David Black
Qualis Design
---- ---- ---- ---- ---- ---- ----
From: jcooley@world.std.com ( John Cooley )
Greg,
OK, I fully admit that I'm going to be a very biased person on this because
of all the user noise I regularly direct at Synopsys, Inc., but that's
exactly why I go to SNUG. That is, for years we've kept SNUG *user* driven
and *expressly* forbid any Synopsys sales or marketing people in to "smooze"
the customers. Also, we've kept the papers and presentations very *user*
biased -- customers are encouraged to share their "success" *and* real life
horror stories at SNUG. (Heck, last year Howard Landman of Toshiba gave
such an embarrassing talk about Design Compiler's unpredictibility (complete
with detailed benchmarks) and Synopsys wrote a rebuttal!)
On a personal level, I've recently become very curious about creating low
power designs. Why? Because, on an engineer-goes-artsy-fartsy level,
they have this unique elegance you don't find in everyday bread & butter
FASTER-FASTER-FASTER designs. So where will you find me at SNUG'99?
"Automatic Clock Gating For Power Reduction"
by Zia Khan and Gaurav Mehta of Intel
"Power Optimization in the Real World: Do's and Don'ts for
System-On-Chip Designs"
by Mike Gladden of Motorola and Iandraneel Das of Synopsys
"New Clock Gating Feature in Power Compiler 1999.05"
by Roberto Zafalon of STMicroelectronics
And I'll also be at quite a few other talks, too. Hope to see ya there.
- John Cooley
the ESNUG guy
( ESNUG 314 Item 3 ) ---------------------------------------------- [3/99]
Subject: ( ESNUG 311 #8 ) Diff Port Maps w/ 2 Levels Of VHDL Wasn't Flagged?
> ... resulted in inconsistent VHDL port maps between the two levels of
> VHDL code. Neither vhdlan nor -spc_elab generated even a warning. Is
> this legal? ... I can understand not mapping outputs in the
> instantiation, but shouldn't the component declaration be checked?
>
> - Wayne Miller
> Symbol Technologies, Inc.
From: "Janick Bergeron" <janick@qualis.com>
John,
It is perfectly legal VHDL to have an unconnected output, either during
configuration (which he had) or during instantiation. It's similar to
not using the Qbar output on a Flip-flop. VSS is fine. A linting tool
could catch this as a warning. (VHDLLint? or DC's check_design command?)
- Janick Bergeron
Qualis Design
---- ---- ---- ---- ---- ---- ----
From: Andrew Maccormack <andrewm@bristol.st.com>
John,
I couldn't find this in the LRM, but I know that it is the case. Unmapped
output ports are equivalent to mapping them to the "open" keyword. It's
like in C, where you can easily ignore the return value from a function...
It's not a Synopsys bug, it's a VHDL "feature"
- Andrew R MacCormack
STMicroelectronics
( ESNUG 314 Item 4 ) ---------------------------------------------- [3/99]
Subject: A Rose In Not A Rose Is Not A Rose -- Comparing Gate Counts In DC
> I have a synthesized a design using Synopsys. The area report gives me a
> cell area of 3245. Is this the gate count? If not, how can I extract the
> gate count from Synopsys?
>
> - Quek Kai-Hock
> National Technical University Singapore
From: david@rogoff.cnchost.com (David Rogoff)
It depends how the library was built. Here's what you do. Read in this
design:
module one_gate(q,a,b);
input a,b;
output q;
nand2 u0 (q,a,b);
// NOTE: may need to change nand2 to whatever your library calls it
endmodule
Read this into Synopsys and run an area report. This will be the area of
one gate in whatever units you library is defined.
- David Rogoff
---- ---- ---- ---- ---- ---- ----
From: muzok@pacbell.net (muzo)
But one needs to be careful about the drive capability of the said nand.
There are usually more than one nand with different drives and different
equivalent gate sizes. You need to chose the one gate equivalent which
is usually the smallest.
- Muzo
Kal Consulting
---- ---- ---- ---- ---- ---- ----
From: tcoonan@mindspring.com (Thomas A. Coonan)
Right.
My 0.35 library has the ND2 cell (2-input NAND) listed with an area of 54.
In the same vendor's 0.25 library, the same cell reports as 27 units (this
vendor lists sq-um). Therefore, for my particular libraries, I divide
'area' by either 54 or 27 respectively. Your design should almost surely
have either a 2-input NAND or NOR in it, so hopefully you don't need to do
the benchmark circuit -- just look through your report_area output (you'll
surely see even smaller Inverters or Buffers cell, so make sure its the
low-drive NAND/NOR and not an inverter).
- Thomas A. Coonan
---- ---- ---- ---- ---- ---- ----
From: Jason Doege <jdoege@centtech.com>
Other are pointing you at equivalent gate count, a derived value based on
area. This, however, is not what you asked for. To find out how many
gates you have in your design, using dc_shell:
count = 0
cell_list = find (cell -hierarchy, "*")
foreach (cells, cell_list){
count=count+1
}
echo "The total number of instances in this design = " count
This is from "Logic Synthesis Using Synopsys 2nd ed." By Pran Kurup and
Tahaer Abbasi, a very worthwhile book. That script will include flops
and latches in the gate count. This book has other scripts that give a
better report showing counts of gates, flops and latches.
- Jason Doege
Centaur Technology
( ESNUG 314 Item 5 ) ---------------------------------------------- [3/99]
Subject: ( ESNUG 311 #1) Crack FLEX-lm? Go To Jail, Directly To Jail
> I hate to sound like an EDA company lackey, but please cease and desist.
> We're all engineers, whether software or hardware. Publishing articles
> like these to facilitate theft of one engineer's work by another doesn't
> seem to me like a legitimate productivity enhancer.
>
> On the other hand, since the senior execs at the EDA companies now all
> seem to read your ESNUG newsletter, perhaps publishing these security
> holes at the beginning of your column is the best way to get them patched.
>
> With that in mind, feel free to publish, withold, or edit as you see fit.
>
> - Dan Lutes
> Cirrus
From: [ The German Guy ]
John, no name please, call me [ The German Guy ] if you wish to.
When I started my business career 15 years ago, we had a similar discussion
in our (then) new start-up company.
We had a test installation of a top-notch CAE software with no security
mechanism yet, as it was beta. Based on a gentleman's agreement we were
allowed to use it for a specified period of time, and had to delete it
afterwards. Unfortunately we were not able to take advantage of all
features during that time period, and our time schedules made it unlikely
to make up for within days.
After discussions my superior decided not to "extend" that license, but to
immediately delete the software, just because it would be illegal. He
convinced the team with the argument, that you cannot control and keep the
knowledge of illegal software use for about 35 years, which an engineer's
career typically lasts.
How wise his decision was!
Now, about 15 years later many of my former colleagues work at different
companies, some at CAE software vendors, and one is even in the position to
order the generation of license keys.
Can you control the (spreading?) knowledge of former personal or company's
wrongdoing? Would one of the knowing persons forget the personal
(un)reliability concerning software licensing / license-tampering? Isn't
this even more dangerous if someone knows that you actively had "hacked" a
licensing scheme in order to save your company's money?
The (then) external and thus uncontrollable knowledge may destroy your
personal integrity even decades later -- when you may be a senior business
professional in a promising position you perhaps had never dreamed of....
I admit, that I may have a slightly different opinion on privately owned or
copied software/shareware/games. But as soon as I use software for business
("to make money with it"), I would never ever use it unlicensed or even
actively "hacked".
John, thank you for bringing up that discussion on licensing and hacking.
- [ The German Guy ]
---- ---- ---- ---- ---- ---- ----
From: Matt Christiano <matt@globes.com>
John:
I saw the discussion on ESNUG and thought that I should reply.
I'm the president of GLOBEtrotter, the company that makes FLEXlm.
FLEXlm is not intended for use as a high security product, but as a means
for helping honest customers stay honest and receive flexible licensing
terms. At the same time, governments around the world and the World
Trade Organization are making the use of hacked and cracked software a
serious crime.
I belive that it makes more sense that those who hack or use hacked software
be inconvenienced through the legal system, rather than GLOBEtrotter
inconveniencing honest end-user customers by going to extraordinary means
to add security to FLEXlm. (Here's an example: FLEXlm has the ability to
check for the system clock being set back. It's not perfect, but it works
reasonably well. While this feature has been in FLEXlm for several years,
most of my FLEXlm EDA customers do not use it because it inconveniences
their own legitimate customers because it screws up Y2K bug testing.)
Can FLEXlm be cracked? Certainly. It's software. Most importantly, our
philosophy is "keep honest users honest", in other words, we're not trying
to make a foolproof system, we're just trying to make a system which will
prevent inadvertent overuse by legitimate customers. Our belief is that
"revenue leaks" come from honest corporations who use more software than
they have purchased, but truly don't know that they are doing that. If
they knew, they would purchase the actual number of EDA licenses they are
using. Crooks aren't going to pay, no matter what protection you build
into the software -- they will find some way of being crooks -- even if the
way is to steal a different software package.
We've run into a few people like this, and when we find how they've done
it, there is usually a new version of FLEXlm out shortly which makes the
particular attack more difficult or impossible. But the world is full of
people with time on their hands, and they'll always find some new way to
crack software protection systems. So my message to them is this: if you
think you're clever because you can hack FLEXlm, you're not. If you use
the result, however, you are a criminal.
Now, on to the technical issues.
Here's the description of how to disallow access to your license servers,
even if you have access to the port numbers allowed across your firewall:
How To Set Up FLEXlm With A Firewall
------------------------------------
Most companies that are connected to the internet use a firewall for
security purposes. A firewall allows communications for only designated TCP
"ports", identified by numbers in the range 0-64000. FLEXlm uses a set of
these TCP ports, one for the lmgrd process, and one for each vendor daemon.
In order for a user outside the company's firewall to run software
controlled by a license server inside the firewall, access to these ports
must be allowed across the firewall.
The firewall administrator must know the port numbers in order to allow
access to them through the firewall.
The first port number, used by lmgrd, appears on the SERVER line in
the FLEXlm license file, e.g.,
SERVER myhost.mycompany.com 12345678 1234
^^^ ^^^ ^^^
hostname hostid port-number
If there is no port number, then it's using the "default" FLEXlm ports,
27000-27009, and access to all 10 of these ports should be allowed.
Normally, the vendor daemon port numbers are chosen by the OS at runtime,
and is different each time. However, since a firewall requires a fixed port
number, FLEXlm allows the administrator the option of fixing these port
numbers (with lmgrd v5.0 or higher). This is done by adding "port=n" (where
'n' is a number in the range 1025 to 32000) to the DAEMON or VENDOR lines
in the license, e.g.,
change: DAEMON gsi /path/gsi
to: DAEMON gsi /path/gsi port=5678
The keyword VENDOR may appear instead of DAEMON, and the number of arguments
is variable, but you can always add "port=n" to this line. This must be
done to each DAEMON line, and access to each of these port numbers must be
allowed through the firewall. Remember to use a v5+ lmgrd; we always
recommend using the latest lmgrd anyway, obtainable at www.globetrotter.com.
How To Prevent Others On The Internet From Using Your Licenses.
---------------------------------------------------------------
If your license server is available across the internet, then any user with
software that requires a license that your server has may run the software
by using your license server if they know the hostname of that server, and
the port number lmgrd is using. These may not be hard to obtain through
trial and error, and once found, may be published to other hackers.
To prevent this, we recommend using INCLUDEALL in the end-user options file.
First, if you don't already have an end-user options file, you'll need to
make one for each vendor daemon in the license file. Specify the path
to a different file for each vendor daemon, on the DAEMON (or VENDOR) line
in the license. If the license says DAEMON, you append a path, by placing
it before the port=n field:
change: DAEMON gsi /path/gsi port=5678
to: DAEMON gsi /path/gsi /path/gsi_options port=5678
If it says VENDOR, append:
options=optionspath
to the VENDOR line, where "optionspath" is the path to a file that you
are going to make.
Now we need to create a file in the location you've specified (or edit the
existing one), and specify the INCLUDEALL line(s).
The syntax for these lines is:
INCLUDEALL USER username
INCLUDEALL HOST hostname
INCLUDEALL INTERNET n.n.n.n (where n is a number in the
range 0-255, or '*' wildcard)
When present, only specified users, hosts or IP-addresses can use any of
the software for this vendor. Remember that these files apply only to one
vendor daemon. For example, if all the IP-addresses in your company are
in the range:
123.*.*.*
then you'd use
INCLUDEALL INTERNET 123.*.*.*
Anyone not in that ip-address range would be denied a license. If you have
several ranges in your company, you can list each of them:
INCLUDEALL INTERNET 123.*.*.*
INCLUDEALL INTERNET 124.*.*.*
INCLUDEALL INTERNET 125.*.*.*
INCLUDEALL INTERNET 126.*.*.*
A complete description of the end-user options file is contained in the
FLEXlm end-user manual, available at www.globetrotter.com/manual.htm
- Matt Christiano, President
GLOBEtrotter Software, Inc. San Jose, CA
( ESNUG 314 Item 6 ) ---------------------------------------------- [3/99]
Subject: ( ESNUG 311 #10 ) Engineers Doing 'Chip Doodling' On The Raw Dies
> Hi John - It's Craig Matsumoto from EE Times. I've got a wacky story
> assignment and figured you might be the guy to turn to (uh, nothing
> personal....)
>
> I'm writing about microdrawings found on silicon chips. Whereas designers
> used to put their initials in the blank spaces of a design (so I'm told),
> some have now graduated to doing some elaborate pictures. Cartoon
> characters are popular -- Dilbert, Mickey, Waldo -- but some look like
> actual drawings. You know, drawings done by someone with real artistic
> talent.
>
> One thing I'm trying to find out is how common this is. Does everybody
> do it, sort of an EEs' graffiti? I'm also curious whether companies
> condone it.
>
> Finally, I've come across two nice urban myths that might amuse you: 1)
> Chip designers communicate with one another through hidden micromessages on
> the silicon ; 2) Companies will put their own logo on a chip, within the
> active circuitry, as copy protection -- so if you try to copy the design
> but remove the logo circuitry, the chip fails.
>
> Like I said, wacky stuff. Your readers have any thoughts or suggestions?
>
> - Craig Matsumoto
> Associate Editor, EE Times
From: Andrew Maccormack <andrewm@bristol.st.com>
John,
Our company has now banned doodles on chips, because we had a chip a few
years ago that was screwed up by some inductive effect of one of these
doodles. However, one of my RAM designer colleagues tells me that he signs
his name in his designs still, except he does it vertically, perpendicular
to the plane of the wafer, so that you'd need a cross section to spot it!
(i.e. the vertical lines in the writing are vias...!)
And we wonder why our projects are always late....
- Andrew R MacCormack
STMicroelectronics UK
---- ---- ---- ---- ---- ---- ----
From: [ The Cat In The Hat ]
John,
True stories about logos on chips: Back in the 'old days" Intel (and others)
not only built their logo into the actual wiring, but sometimes left
half-completed contacts. There used to be (maybe still are) companies that
would reverse engineer chips (especially memory chips) by slicing and
photographing. The logos would keep them from just generating new masks
(as does registered mask copyright now), and the fake contacts would make
the reverse engineering much more difficult.
Another true story: I knew someone who was reverse engineering a design and
they were having trouble photographing a mask. They found a copy of the
mask on some of the company's promotional literature and used that as the
basis to complete the reverse engineering of the chips.
In the 80's at at least one large mini-computer company, some of the mask
designers were really good sketch artists, and occasionally had time on
their hands. As a result, all sorts of pictures (including Santa Claus
stomping lobsters) made their way onto various dies. (Usually these
pictures had something to do with the characteristics of the design team.)
This probably still goes on, but probably only in full-custom environments.
Copyrighted likenesses (Mickey Mouse, etc) became "uncool" to use in the
early 80s after Disney sued someone (maybe Intel?) for using Mickey's
likeness on a die.
Initials are still quite common - most ASIC design houses will put yours on
if you ask.
Of course, please protect my anonyminity.
- [ The Cat In The Hat ]
---- ---- ---- ---- ---- ---- ----
From: Steven Cochran <scochran@sr.hp.com>
Hi Craig/John,
Here's some info for your EE times article. Back in the days when I was
an analog GaAs IC designer, engineers would put logos on chips all of the
time. They ranged from landscapes to cartoon characters. The only
restriction was that if there was a copyright on the logo, then it had to
be removed when the circuit went to production.
Well everybody was happy with this arrangement until our internal fab
started rejecting *every* wafer of a particular design. It seems that the
people doing process inspections mistook the "head" that was part of a beer
stein logo for a fab defect. That pretty much put the kibosh on special
logos.
Nowdays the only thing that a designer can do to personalize his chip is
to name it. Designers name circuits for ex-lovers, New Testament
characters, their favorite ghost towns and so on.
- Steven Cochran
Hewlett Packard Microwave Technology Division Santa Rosa, CA
---- ---- ---- ---- ---- ---- ----
From: [ A Knight Who Formerly Said "Ni!" ]
John,
We have been putting "whimsical geometries" on chips since the dawn of
silicon planar processing, i.e. forever. Layout designers, who often fancy
themselves artists anyway, love it the most, but others also get into the
act. I put "Duke" from Doonesbury in metal before 1980. (There was only
one layer of metal then.)
"Art" is what you like. It's best if it embodies some aspect of that
development. Often we put our impression of the customer as an icon, or
of the product functionality.
Every place I've worked on custom chips has done it (ok, short list).
Most companies realize it doesn't hurt anything and tolerate it, although I
wouldn't be surprised if the more authoritarian, "we want obediance more
than creative thinking" companies, (like Moto) might forbid it.
> Finally, I've come across two nice urban myths that might amuse you: 1)
> Chip designers communicate with one another through hidden micromessages on
> the silicon ; 2) Companies will put their own logo on a chip, within the
> active circuitry, as copy protection -- so if you try to copy the design
> but remove the logo circuitry, the chip fails.
I think the myths are myths. I haven't even heard of people spending time
on anti-copy "gotchas" since the early days, now that we have adequate
copyright protection. The old "buried contact" was good for that then.
One notable improvement I have seen my collegues do recently is make the
image pass all Design Rule Checks (DRCs), yet still be visually appealing.
That way we don't have to remove the whimsical cell during DRC checks, which
is a reliability issue.
John, you may summarize my comments or excerpt them. Please remove my name.
I sent them to you and not Craig because you deserve the fun of all of them.
It's a fun subject, and I wish I read EE Times enough to see the final
article.
- [ A Knight Who Formerly Said "Ni!" ]
---- ---- ---- ---- ---- ---- ----
From: "Robert Milby" <Robert_Milby@Maxtor.COM>
I had just come across www.chipworks.com/SiliconGallery/07main.htm when I
was searching for an specs on an IC. I have, on my wall, a color print out
of "COWS on a 486DX4-120" (www.chipworks.com/SiliconGallery/07cows.htm)
Have you collected other links to chip art?
- Rob Milby
Maxtor
---- ---- ---- ---- ---- ---- ----
From: Russell Ray <rray@msai.mea.com>
A friend of mine was showing me a page the other day of this. He
can't remember where it was, but it was called silicon zoo or
something like that. I just did a search and found this.
http://micro.magnet.fsu.edu/creatures/pages/groucho.html
- Russell Ray
Mitsubishi Semiconductor Durham, NC
---- ---- ---- ---- ---- ---- ----
From: "Bryan J. Hunt" <bhunt@NTRnet.net>
John
By some strange coincidence, a friend of mine at Moto sent me this link
today ... http://micro.magnet.fsu.edu/creatures/
- Bryan Hunt
---- ---- ---- ---- ---- ---- ----
From: charles@efficient.com (Charles Shelor)
John,
I assume that you have visited this site. But if you haven't; it is a
"must-see".
http://micro.magnet.fsu.edu/creatures/index.html
On one chip, I have personally placed my initials in an unused area. I
know a designer that did a 'tree-carving' type heart and intials of he
and his girlfriend.
- Charles F. Shelor
Efficient Networks Dallas, TX
( ESNUG 314 Item 7 ) ---------------------------------------------- [3/99]
Subject: ( ESNUG 311 #6 ) Incremental DC Compiles Wrecks My Timing !!!
> Yeach! A second compile apparently wrecks timing under certain conditions.
>
> We have found that the area-reduction phase of an incremental compile
> either ignores timing violations, or incorrectly calculates timing, IF
> there is a design rule violation at the start of the incremental
> compile AND the max_area attribute is over constrained.
>
> The result is that a design that met timing before the incremental compile
> is turned into a design that is smaller, but no longer meets timing. Not
> what you want. (Definitely not what you want.)
>
> Our flow is as follows for module "jpt":
>
> 1) read -format verilog jpt
> 2) set_max_area jpt 2500
> 3) apply custom wire load model to jpt
> 4) compile jpt
> -- generates designware submodule "DW01"
> -- timing met
> -- design rules met
> -- area 6500
> 5) apply custom wire load model to DW01
> 6) compile DW01 with overconstrained timing
> 7) report constraint -all_violators for jpt
> -- timing met
> -- area not met (okay)
> -- fanout design rule violation (due to step 6)
> 8) compile -incremental jpt
> -- timing *apparently* met (0 delta delay)
> -- design rules met
> -- area 6200
> 9) report constraint -all_violators
> -- timing NOT met (VERY BAD)
> -- area not met (okay)
> -- design rules met (good)
From: Jeffrey Ebert <ebert@sonicsinc.com>
John,
This doesn't answer Sol directly, but this is another approach that he
could try:
I think that Sol should characterize the DW01 instance between steps 4
and 5. This would provide proper input drive and output load
characteristics for the DW01 pins. He can still overconstrain the timing
without introducing design rule violations.
Of course, if timing is met in step 4, why is he overconstraining DW01?
I used to do things like this in old Synopsys versions, but I have found
it unnecessary lately.
- Jeffrey Ebert
Sonics, Inc.
---- ---- ---- ---- ---- ---- ----
From: Andrew Maccormack <andrewm@bristol.st.com>
John,
When Synopsys had a seminar on their new 98.02 version of DC early last year
I remember them saying that they knew that to get the best out of DC in the
past you had to over-constrain it, but now over-constraining it (especially
in area) was *BAD*. Part of this was probably to sell PrimeTime's timing
budgeting to people, but also it is the "intuitive" approach... we're just
used to rubbish synthesis tools!
I would be interested to know what effect using the "set_critical_range"
command has, especially if you make it large enough to include the amount of
violation you end up with.
- Andrew R MacCormack
STMicroelectronics
( ESNUG 314 Item 8 ) ---------------------------------------------- [3/99]
Subject: ( ESNUG 308 #1 ) Regarding The New TCL Interface To Design Compiler
> I just saw this new tcl/tk environment (my Synopsys Salesdroid punching bag
> brought it in when he was demoing something else). These are my opinions
> of the new Synopsys tcl/tk only after an hour's play...
>
> If you think that this environment is going to bring some of the cool
> features of PrimeTime, you will be disappointed. In reality, it is
> just a Tcl/Tk shell wrapped around dc_shell so the features and limitations
> of dc_shell are still there. For instance, ....
>
> I'm not saying Synopsys is going the wrong direction. It is that they are
> trying to save some of the dc_shell scripts for now by not *integrating*
> Tcl/Tk, just wrapping Tcl/Tk around dc_shell.
>
> - Larrie Carr
> PMC-Sierra, Inc. Vancouver, B.C., Canada
From: [ A Synopsys DC CAE ]
John,
I am writing to clarify some user misunderstandings that may have arisen
from this recent post regarding the new TCL interface to Design Compiler.
DC Tcl is a native Tcl interface to dc_shell. Tcl is purely a scripting
language. The Tk language extends Tcl's features by providing an easy way
to create GUIs for applications created with Tk or other programming
languages. The DC99.05 DC TCL interface supports Tcl, not Tk.
The introduction of DC Tcl expands the scripting capabilities in dc_shell
by providing a standardized interface that supports parameterizable user
defined functions. DC99.05 supports both dc_shell and dc_shell Tcl. At
the beginning of the session, users can choose to use either the existing
dc_shell by typing dc_shell or dc_shell -tcl_mode to start on DC tcl. A
translator program dc_transcript is also available to translate from
dc_shell scripts to equivalent Tcl scripts.
Currently, Design Compiler, PrimeTime and Formality support Tcl. The Tcl
interface provides an alternative way for users to create their own scripts
to automate the flow. However, some commands and options are unique to each
tool. For example, a DC command such as compile will not exist in PrimeTime
since this is a function that is unique to DC. Therefore, we should
separate distinction between tools command and Tcl language.
Our goal was to make commands having the same function equivalent across all
Synopsys tools. In this first release some commands incompatibilities
exist between PrimeTime and Design Compiler. We will strive to remedy these
inconsistencies in future releases.
- [ A Synopsys DC CAE ]
( ESNUG 314 Item 9 ) ---------------------------------------------- [3/99]
From: Sam Ambalavanar <sama@eng.mc.xerox.com>
Subject: Want Opinions on Summit vs Escalade For Design Capture, Sim, FSMs
Hi John,
We are about to evaluate Summit's Visual HDL and Escalade's DesignBook. We
are looking for a front end tool for high level design. Mainly to document
and capture designs at the module level. Some here like the hooks into the
simulator and also for FSM generation. I was wondering if the other
features are of much use. Hopefully there are some users out there who are
using these tools and are willing to give their opinions.
- Sam Ambalavanar
Xerox
|
|
