Editor's Note: Weird week for me. Really weird. I got 104 inquiries
concerning the Flex-LM story and have been going nuts trying to keep my
word telling *only* the EDA vendors the details. For example, when
Richard Jones of Simucad called, I looked up Simucad's phone number in the
DAC'99 Exhibit Guide, call it, and asked "Who's Richard Jones and what's
his extension at Simucad?" -- just to be SURE that I wasn't educating a
hacker posing as an EDA vendor about this crack. (Yea, I know it seems
paranoid, but I wanted to be *sure* and this was the only way that worked.
This also meant I couldn't tell any overseas EDA people because it would
just cost too and be too crazy with differing Time Zones, etc. Sorry.)
On the personal front, over Labor Day Weekend I drove over 300 miles to
and from a cabin in New Hampshire's White Mountains -- and then, two days
later I had to walk 3 miles home because my car just *then* died while I
was at the health club. (Why didn't it crap out during the big trip?)
Now I gotta get the car towed and fixed this weekend. (That will be
"fun", I'm sure.)
On the business front, even after being caught red handed with source code
swiming with *hundreds* Cadence keywords, Avanti was *absolved* by a
federal judge for any trade secret violations this week! ( "Hey! Wasn't
the unoffical story that Gerry Hsu was just legally stalling to delay his
eventual conviction??!! Huh? How did he finagle *that* bagel?" )
And then I remembered that this is the *American* justice system; the very
same "justice system" that found OJ Simpson "innocent". Oh...
Man, this has been one weird week...
- John Cooley
the ESNUG guy
( ESNUG 328 Subjects ) --------------------------------------------- [9/9/99]
Item 1: ( ESNUG 327 #1 ) 13 Of 104 Replies To "Flex-LM Cracked" Story
Item 2: ( ESNUG 326 #2 ) Users React To CynApps' Free HW C++ Class Libs
Item 3: ( ESNUG 327 #13 ) PrimeTime "transcript" Tcl Translator Is Useful
Item 4: ( ESNUG 326 #10 327 #3 ) Metastability 'Z' Is The Same All Around
Item 5: ( ESNUG 327 #11 ) Chronology's QuickBench BFMs In Mentor's Renoir
Item 6: ( ESNUG 326 #4 ) So Called "DesignWare Wireload Bug" Demystified
Item 7: Can I Prevent DC From Replacing The Original Cell Instance Names?
Item 8: ( ESNUG 315 #8 ) Headaches Because PrimeTime Tcl Lacks "Ldelete"
Item 9: ( ESNUG 327 #12 ) In Attempting To Synthesize Fixed Time Delays
Item 10: ( ESNUG 327 #8 ) How Secure PGP IP Encryption Technically Works
The complete, searchable ESNUG Archive Site is at <http://www.DeepChip.com>
( ESNUG 328 Item 1 ) ----------------------------------------------- [9/9/99]
Subject: ( ESNUG 327 #1 ) 13 Of 104 Replies To "Flex-LM Cracked" Story
> But this crack is different. It's a FULL crack. It's not a trick to use
> when you're on a project and your licenses *just* ran out and you need
> something just to get two more weeks, TWO MORE WEEKS! (Hey, I've been
> there before. I *know* what that hot seat is like.) This crack is
> different. It's a *full*, in-your-face, no-possible-redeeming-value,
> no-grey-areas, we're-just-gunna-steal-this-software crack...
>
> And my screwy sense of ethics won't let me support something like this.
>
> - John Cooley
> the ESNUG guy
From: Matt Christiano <matt@globes.com>
John,
From the "Electronic News" website, I see you received over 48 emails on
Friday, after item #1 in Post 327. That's good. :)
What do you think the hackers of the world want? Money? Not likely. Fame?
You betcha. They want nothing more than to have guys like you writing
articles about them.
The good news is, however, you didn't disclose the web site, and will only
give it to honest EDA companies. And I guess we can all rest assured
that none of the people who might want to steal this software, but hadn't
realized that someone had hacked it, know how to use a search engine --
that will keep us safe. :)
John - what were you thinking?
For matters like computer viruses and other items that affect the security
of the public, news reports benefit the public in general, as there are
measures for the public to take to protect themselves to minimize the
damage. At the same time these stories provide encouragement to the virus
developers. One can reasonably argue that the benefits the public receives
by publishing these stories overrules the damage caused by encouraging
further virus development.
I don't see how publishing a story like this helps the public, as they are
not damaged by the problem. Publishing the story just to EDA vendors may
have some merit especially if one believed that GLOBEtrotter would not
respond in a more private conversation. However, if you had called us,
we would have told you that we have already fixed this hole -- in 1996, by
the way, and made it the default in FLEXlm in 1998, but that there are
lead-times for our customers to get these fixes into their production
releases.
So the net result of publishing the story is:
- hackers are encouraged to do more of this because of the attention,
- some dishonest users will find the hack on the net who might not
have otherwise and "steal" EDA software which they probably wouldn't
pay for anyway,
- some of these users will get into trouble w/ their companies or the law,
- you and I will have to answer an avalanche of email and phone calls, AND
- some EDA vendors may "crank-up" the security in ways that will
inconvenience honest users (ie, you and your readers).
I don't see the public benefit. I don't see the benefit for EDA vendors.I
certainly don't see the benefit for you, unless you like the deluge of
email. And most of all, I don't see any benefit for your users. I don't
know who, but I'd be willing to bet that some EDA vendor is now going to
lock down security in a way that is going to severely inconvenience you and
your readers.
If you honestly believe that publishing a hacker story benefits the public,
you should publish it. If you believe that doing so on balance harms the
public or encourage others to harm the public -- you should refrain from
publishing as a matter of personal integrity -- as I believe you would. But
please, please, think of the "law of unintended consequences" when you
publish something like this.
- Matt Christiano, CEO
GLOBEtrotter Software, Inc. San Jose, CA
---- ---- ---- ---- ---- ---- ----
From: [ Name Deleted ]
John,
After talking with you on the phone about this, I downloaded the Flex-LM
cracker software from that URL and ran it on a isolated PC. It successfully
cracked Flex-LM 5.12 all the way to the Flex-LM 6.1F version. It didn't
crack the new (released this week) Flex-LM 7.0C version. The EDA vendors
who read ESNUG should be interested in this news.
- [ Name Deleted ]
[ Editor's Note: On Wednesday, Sept. 8, the http offering the Flex-LM
cracking tool completely removed the Flex-LM cracking tool and any
mention of it. I've done multiple web searches for the specific name
of this tool and found it nowhere on the net. This Flex-LM cracker had
been freely available on that site for 4 weeks (since August 6th.) What
caused it to go & whether it's permanently gone, I don't know. - John ]
---- ---- ---- ---- ---- ---- ----
From: "Richard O. Jones" <richard@simucad.com>
Hello John,
Thank you for publicizing the FLEXlm security problem. Your warning came
just in time for Simucad. We were about to ship a new release of Silos III
and HyperFault tools using Globetrotter's version 6.0.
Based upon your article and after talking with you on the phone about the
exact technical details of how this Flex_LM cracking tool works, we
consigned the freshly minted CDs to the trash. As you can imagine, this
cost us a considerable amount in time and materials. We are now in the
process of creating a new version of our software using the latest version
of FLEXlm.
The remaining problem, from Simucad's point of view, is that all previous
versions of our software have been compromised. Quite clearly, no
retro-active fix is possible.
Thanks for the timely warning!
- Richard O. Jones, VP Sales
Simucad, Inc.
---- ---- ---- ---- ---- ---- ----
From: [ Name Deleted ]
Hi John,
Yes, I am an EDA vendor but, no I don't want to know the sight. It just so
happens that I was in Japan last week, and had meetings with several other
EDA vendors and this is well known to them already. If there are any EDA
vendors that don't know about this, then they are not paying attention. It
appears a lot of pirated software is being sold this way in China and some
of the pacific rim countries.
I read your Posts all the time but I have never replied until now.
Keep up the good work.
- [ Name Deleted ]
---- ---- ---- ---- ---- ---- ----
From: [ Named Deleted ]
Hi John:
Attached is a copy of what I encountered on the DejaNews web site back in
May. It did have a license file attached which did contain a legitimate
license for "ANY" hostid. By tracing it back, I found that it originated
from a university demo license and that the encryption key was brute forced
by incrementally counting from "00000000000000000000" until the one of the
applications "accepted" the key as legitimate.
It probably cost a good deal of CPU cycles, but when you are a university
student with nothing better to do... well, you get the picture. Anyway by
tracing the originator of the email, I found that it originated from a
machine at Tsinghua University in Beijing, China.
Odd mix of American slang and anti-American rhetoric concerning the NATO
bombing of the Chinese Embassy in Belgrade.
Accident occured - [ EDA Product Deleted ] was cracked throughly
Disclaimer
This's a accidental crk releasing coz I mis-pressed the post button,
which is the same accident as the 'accidental' missile attack on the
embassy of China in Belgrade. This accident also happened for the
[ EDA Company Name Deleted ] headquarters locates in the United States.
I don't wanna the same thing happen another time..
Pls do not ask me Q for how to get the software. Cut the contents & save
it as license.dat. Read the online document came with the software for
how to use this shit license. If there're any losts caused to [ EDA
Company Name Deleted ] by this crk, pls ask NATO, the godamned
Neo-nazism on earth, for ur compensation.
Anyway, it was interesting. I had DejaNews remove this crack from their
archives.
- [ Name Deleted ]
---- ---- ---- ---- ---- ---- ----
From: [ Name Deleted ]
John,
Don't reply directly, this is my home email, reply to [ Address Deleted ].
I work for Mentor Graphics, and actually ran across a similar thing on UNIX
about two years ago. Apparently though, it looked like some disgruntled
ex-employee pilfered some key generating software, and sold it. It could
only access Mentor owned products (ie Mentor, Exemplar, Modelsim). They
were so bold they still sent me codes, after searching the web and finding
my other email as mentor.com, and asking me if I worked for Mentor.
A few weeks later the same 'ethical' customer, told me they got another
one for Synopsys. Our legal dept tried chasing them down, but don't
know the results since one e-mail trace ended some where in Romania, and
the other in the South Pacific, where extradition and such have little
meaning in the software biz. Haven't heard from anyone seeing these
codes in about a year and a half, so I guess we found them, or there are
more ethical customers out there than not. Being, the optimist, I
believe ethical customers have shut them down.
- [ Named Deleted ]
---- ---- ---- ---- ---- ---- ----
From: Pallab Chatterjee <pdec@earthlink.net>
John:
Congrats on your position on FlexLM and the latest of many "crackers" fora
license manager. On occassion, I've had to play a few of the "stretch our
current license" games myself in the course of meeting a schedule that
happens to correspond with a holiday weekend -- but I disagree strongly with
the semi guys and consultants who try to operate their business off of
borrowed and/or stolen software. There is a price to pay to be in business;
not being able to afford software is means you can't play in the big
leagues; and if you feel that engaging in illegal activities is the only way
to be on the same playing field as the rest of the people -- means you don't
deserve to be there to begin with.
Please feel free to publish this as you see fit. I just thought it was
important for someone to show that they support your position on playing a
deal fairly.
- Pallab Chatterjee, Vice-President
P&D Engineering Consultants, Inc. Livermore, CA
---- ---- ---- ---- ---- ---- ----
From: "Rob Dekker" <robd@gowebway.com>
Hi John,
This FlexLM crack really worries me.
I am bringing out a verification tool at the end of the year. I was
planning to put FLEX-LM in there for licensing. But if the security hole
that you mention is real, I might have to find another solution. At least
for NT.
I do appreciate it that you do not send the URL to everyone, thereby giving
Globetrotter and EDA vendors a chance to correct the problem.
I don't want to rely on Globetrotter to tell me that everything is alright.
Could you please mail me the URL, so I can check for myself what the risk
is that I am taking by incorporating FLEX-LM into by verification tool ?
- Rob Dekker
(an ex-Exemplar guy)
---- ---- ---- ---- ---- ---- ----
From: [ Name Deleted ]
Is this [ Deleted ]'s site at [ Http Deleted ]? I have a bet riding on this
and that site gives a step-by-step recipe for cracking Flex. It's not a
download like you describe. It's a cracking tutorial instead. Is this your
site, John?
- [ Name Deleted ]
---- ---- ---- ---- ---- ---- ----
From: Brian Turmelle <bturmelle@INTELLITECH.COM>
John,
Being the security buff here at Intellitech I would like to make sure this
technique does NOT work on our keys. I am glad I have been persistent in
not allowing full versions of our software to be downloaded.
- Brian Turmelle
Intellitech Corporation Durham, NH
---- ---- ---- ---- ---- ---- ----
From: Rob Genco <rgenco@synopsys.com>
Dear John,
I want to thank you on behalf of the EDA industry for your handling of the
situation and condemning of these hackers. It's good to know that others
share our concern about this type of crime. I think everyone that could
be affected by this owes you a debt of gratitude.
- Rob Genco, Director of Software Operations
Synopsys, Inc.
---- ---- ---- ---- ---- ---- ----
From: David Chapman <dchapman@aimnet.com>
Well, I'm not a verifiable EDA company yet, so there's no point in sending
the HTTP, and my software doesn't run under Windows NT (yet) anyway, but I
was planning on using Flex-LM for running my software under Windows 98 on
a laptop (!) as a demo. So, my question is: has Flex-LM been compromised
under Windows 98 too? Is GlobeTrotter Software likely to give me a straight
answer on this (or the NT problem, if/when I compile my software for it)?
Is GlobeTrotter working on a solution, or are they stuck with the problem
until Microsoft releases another service pack?
Thank you for telling us about this problem. Now if only we could hang
those hackers by their thumbs... (Or should I blame Microsoft for releasing
such a lame-brained excuse for an OS?)
- David Chapman Santa Clara, CA
---- ---- ---- ---- ---- ---- ----
From: [ Name Deleted ]
John,
Here is the email from the VP of marketing at Globetrotter. It's full of
legal threats about cracking Flex and it starts and ends with a "please
sign up for the EC4S class next week." They want $400 for the class.
Those marketing guys are shameless!
- [ Name Deleted ]
( ESNUG 328 Item 2 ) ----------------------------------------------- [9/9/99]
Subject: ( ESNUG 326 #2 ) Users React To CynApps' Free HW C++ Class Libs
> (Not to be left behind, Synopsys in their NDA suites, discussed 'Scenery',
> a way to standardize C/C++ for synthesis purposes and their C-based
> synthesis tool -- which is almost identical to CynApps' Cynlib approach.)
>
> - from the DAC'99 Trip Report
From: Prabhat Jain <prabhat@glenfiddich.lcs.mit.edu>
Hi John,
Saw your post about Cynapps making their class library public. In fact, the
first paper that was written on such class libraries was published in DAC'97
by a bunch of Synopsys folks -- Stan Liao (an ex fellow grad student), Tjiang
and Rajesh Gupta (professor in U.C. Irvine). That is most probably what
"Scenery" is.
- Prabhat Jain
MIT
---- ---- ---- ---- ---- ---- ----
> Now for the punch line, Why am I sending you this message? Because we are
> going to make the class library, Cynlib, available *freely* under an open
> source license. ... Cynlib will be up at <http://www.cynapps.com> on
> Wednesday, Sept. 1st, free for the taking.
>
> - John Sanguinetti, CEO
> Cynapps, Inc. Santa Clara, CA
From: Tony Bybell <bybell@vnet.ibm.com>
I downloaded the CynLib yesterday and checked it out. Some observations:
1) There's a 9MB solaris executable sitting in there eating up most of
the archive. They really should trim it out..the tgz is 400k then.
2) Few problems with compiling under linux... mainly, I had to change all
of the gcc instances to g++ (otherwise I got "cc1plus missing" errors)
and manually copy some files over to where they belong. No big deal.
It's plain vanilla C++ so it'll probably compile on anything.
3) For the most part, the examples are "weak" and some appear to do nothing.
I don't know about you, but I'm really sick of seeing traffic lights...
The line drawing ones in the instruction manual are nice though.
4) One example created a file named "barf" that had incorrectly writtenVCD.
(Zeros throughout the simulation).
5) The "really neat" Verilog->Cynlib file twister is not present in the
OSS version. I have to look at the license and see if there's anything
that precludes OSS developers from distributing their own. I have
a bare antlr LL(2) grammar laying around for 1364 and this could be a
fun project. Interestingly, cynlib classes could be used as an
intermediate format for verilog compilation. Not the full language,
but a decent synthesizable subset.
As far as the concept goes, it's a decent idea. What they've done is added
pseudoparallel execution to C++ through some class library tricks. By
doing that, HDL simulation is made possible. I give them an A for effort
on this one. (Though I'm wondering if something like cilk can be adapted
to do the same thing..and better b/c it's designed for SMP.)
Most of the problems that I can see would be related to hardware designers
themselves and not cynlib itself. Convincing teams to try out cynlib when
they know verilog/vhdl already "works" may be a tough pill to swallow.
Additionally, the relative newness of the product may scare off a lot of
people because they'd have questions like, "does it really synthesize into
what the cynlib source specs out?"
It looks like it has a lot of potential..if anything, I can see it being
used as a quick and dirty back-end for HDL simulation, even if it never
does get used for its intended use of being an "all in one" solution.
Their distro does need a little bit more work. Non-toy examples would
go a long way to convincing designers that the product has potential.
For "freedom of speech" type fans, the actual source code is quite small and
I don't think it would be too too difficult for someone to eventually make a
GNU knockoff based on the same concept/API. I have to look at the OSS
license for it and see what the development restrictions are. Time to
forward it off to Bruce Perens...
- Tony Bybell
IBM
( ESNUG 328 Item 3 ) ----------------------------------------------- [9/9/99]
Subject: ( ESNUG 327 #13 ) PrimeTime "transcript" Tcl Translator Is Useful
> Does anybody have a practical method for converting constraints from
> dc_shell to PrimeTime tcl? Basically "transcript" is only useful if you
> want to find commands that don't make sense in PrimTime (one cryptic error
> message at a time).
>
> All I want is actual timing constraints like create_clock, set_load,
> set_drive and set_multicycle_path automatically converted into the
> PrimeTime tcl subset. I don't need a script to tell me set_dont_touch
> doesn't make sense in PrimeTime! DUHH! I need a script that ignores
> useless stuff and *successfully* translates the stuff that does.
>
> The "transcript" program fails on the front end when it encounters useless
> things, then generates erroneous code that fails in PrimeTime... now
> *that's* two features for the price of one!
>
> - Rodney Ramsay
> Ford Microelectronics
From: Yossi Rindner <yossir@isdn.net.il>
Hi, John,
Currently, I'm supporting my customer with a set of DC and PT scripts. The
move to PT scripts was pretty simple, using transcript. The approach I used
was to create two sets of DC scripts:
1. First set for synthesizing all sub blocks and linking them to one huge
entity.
2. Second set to check and time the whole design in DC, you want to have
this set too because it provides you with the ability of checking the
integrity of the whole chip, performing ECO's and verifying their
effects.
Once the whole design was timed in DC (you don't want to do it more then
once, PT is 10X faster then DC!), I used transcript to create PT scripts and
started the iterations with layout tools (timing driven placement and back
annotation of SDF) using PT.
All DC timing related commands (set_multicycle_path, set_input/output_delay,
create_clock, set_false_path, set_resistance, set_capacitance, all_fanin,
all_fanout) were translated correctly.
All variable assignments, dc_shell_status and foreach loops where handled
too.
All DC I/O commands (inclusion of other scripts, read -format WHATEVER,
report -WHATEVER, redirection of reports) were translated correctly, as
well.
When there was a need to modify PT scripts, I first modified the DC scripts
and reran transcript. This way I was able to keep a single source of DC
scripts and keep the maintenance of scripts to minimum.
This approach can be used at any level and the criteria at which level to
apply it shall be based on how long it takes to time with DC.
- Yossi Rindner
ASICserve Israel
( ESNUG 328 Item 4 ) ----------------------------------------------- [9/9/99]
Subject: ( ESNUG 326 #10 327 #3 ) Metastability 'Z' Is The Same All Around
> It depends on how the AND or OR gate is implemented. Standard cell or
> discrete logic component gates are implemented straightforwardly, and a0
> on one input of the AND, or a 1 on one input of the OR will block any path
> from the other input to the output.
>
> FPGA gates, however, may be implemented as a lookup table, with the A and
> B inputs selecting one of four programmed values that make up the truth
> table of the gate. During a transition or metastability on an input, it
> may be possible that none of the values are selected, resulting in an
> indeterminate output.
>
> - Greg Dean
> National Semiconductor South Portland, ME
From: Philip Freidin <fliptron@netcom.com>
John,
Metastability 'Z' is no more of an issue in an FPGA than it is anywhere
else. For Xilinx FPGAs, Greg's comment about lookup tables is incorrect.
I don't know the situation for other vendors.
The way it works is as follows:
Let's assume that we have a 4 input LUT, implementing a 2 input and gate.
Of the 4 inputs (address lines to the lut), two are grounded (i.e. never
change) and the other two select 1 of four locations. The locations depend
on which two address lines are used. Of the 4 locations that are
interesting, three are set to '0', and 1 is set to '1'. Unlike RAMs or
other memory structures with word lines, bit lines, sense amps, pre-charge,
and other entertainment, the LUTs are implemented as latches, 16 of them.
They then connect through a tree of pass transistors to the output.
Regardless of which single input is changing, only 2 of the pass transistors
in the tree are involved in the change over from one value to the next.
Since the outputs of all the 16 latches have propagated through the tree as
far as they can, when you change over from one location to another (with
only 1 address line changing), and both have the same value, the transition
does not cause a glitch in the output.
If you care, you can see this structure on page 4 of:
http://patent.womplex.ibm.com/cgi-bin/viewpat.cmd/US04870302__
Clearly, if both inputs are changing, a glitch could occur, but then the
same is true of a real AND gate.
Although my example is for a 2 input gate, the same is true for 3 or 4 input
structures that are mapped to a LUT. The basic rule is that if only one
input is changing, and both the before and after values are the same, no
glitch can occur.
While somewhat more difficult to describe, it can be shown that for
structures like a 3 or 4 input AND gate, with one input held low, you can
have multiple of the remaining inputs changing simultaneously, and not get
glitches in these situations either.
- Philip Freidin
( ESNUG 328 Item 5 ) ----------------------------------------------- [9/9/99]
Subject: ( ESNUG 327 #11 ) Chronology's QuickBench BFMs In Mentor's Renoir
> Does anyone have advice on how to integrate a VHDL Portable BFM generated
> with Chronology's QuickBench Modeler tool into Mentor's Renoir tool? I've
> tried importing the BFM as an external package into Renoir and tried using
> the HDL-to-Graphics converter in Renoir. Both methods result in Renoir
> giving the same error messages of "...invalid VHDL code...", except I can
> compile the BFM code using ModelSim with no errors.
>
> Any suggestions are appreciated.
>
> - Bruce Parker
> Motorola
From: Gene Stuckey <Gene.Stuckey@tellabs.com>
John,
Check out: http://www.chronology.com/support/appnotes.html
They recently added an app note for "Using Portable Models with Renoir".
The way I have been doing it is a method they don't mention in their
applets. I create a Renoir library that contains a "wrapper" component
which is just an "VHDL architecture" that instantiates the QB model
and a Renoir "standard library" into which the QB stuff gets compiled.
This prevents other users from having to know the path to the compiled
library in order to do a foreign instantiation. It also got around the
bug in which Renoir could not parse QB files.
- Gene R. Stuckey, Jr.
Tellabs Operations, Inc. Bolingbrook, IL
( ESNUG 328 Item 6 ) ----------------------------------------------- [9/9/99]
Subject: ( ESNUG 326 #4 ) So Called "DesignWare Wireload Bug" Demystified
> I've found that Design Compiler generated hierarchy (i.e. DesignWare) gets
> the wrong wireload model. I've run into this using 1998.98-1, but I
> checked the problem with 1998.02-2 and 1999.05 and got the same results.
> When using enclosed wireload models, generated DesignWare hierarchy gets
> the wrong wireload. If there is a default_wire_load attribute in the
> library, that wireload is used. If there is no default_wire_load
> attribute set, NO wireload is used. ...
>
> - Bob Wiegand
> Ensoniq Corp. Malvern, PA
From: [ A Synopsys CAE ]
To: Bob Wiegand <rwiegand@ensoniq.com>
Bob,
I might be missing something, but I thought this is the way it's supposed
to work? I believe the order is this when using 'enclosed' wireloads:
1. specifically set wireload, if any
2. wireload chosen from auto_wire_load_selection, if enabled
3. wireload from library default_wire_load, if any
4. first wireload encountered up the design hierarchy
In other words, if there is NO wireload set on the design, it will inherit
it from the next lowest-level enclosing design with a wireload. This means
that if you have no default_wire_load and no auto_wire_load_selection,
synthetic ops will inherently use the parent wireload when they come into
creation during compile! However, doing a report_design on that DW will
still report there's "no" wireload, because there indeed isn't one
explicitly set.
I did a real quick test setting the top level of a design to a certain
wireload, with all the subdesigns having no wireload. The results were the
same as setting all designs to that same wireload. The timing for having
no wireload whatsoever set was different, so this supports that designs
with no wireload do indeed inherit them from parent hierarchy.
- [ A Synopsys CAE ]
---- ---- ---- ---- ---- ---- ----
From: Bob Wiegand <rwiegand@ensoniq.com>
To: [ A Synopsys CAE ]
I agree with the order you present for wireload selection in enclosed mode,
but have to question the order of 3 and 4. I would think you want the
first wireload encounterd up the hierarchy to take effect first, and then
if all else fails use the default_wire_load from the library. Anyway, the
situation with designware was slightly different. I went out of my way to
specify the wireload on the generated designware, and DC went out of it's
way to ignore that information. The thing that led me down this path in
the first place was an OPT-170 message, telling me that the wireload for a
particular DW component was changed from "none" to a 1M gate wireload which
turned out to be the default_wire_load for that library.
I decided to go back and check my facts using two diffent libraries,
compiling a small design without ungrouping the designware hierarchy and
then doing a report_timing on that design. Here's what I found:
Condition 1: No library default_wire_load,
auto_wireload_selection = false.
OPT-170 message: no message
Timing Report: designware not shown
Condition 2: No library default_wire_load,
auto_wireload_selection = true.
OPT-170 message: none to auto-selected
Timing Report: shows designware with auto-selected wireloads
Condition 3: Library default_wire_load present,
auto_wireload_selection = false.
OPT-170 message: none to library default
Timing Report: shows designware with library default wireloads
Condition 4: Library default_wire_load present,
auto_wireload_selection = true.
OPT-170 message: none to library default,
library default to auto-selected
Timing Report: shows designware with auto-selected wireloads
Condition 5: Implementing fix from ESNUG 326 so that library
default_wire_load is equal to parent design wireload,
auto_wireload_selection = false.
OPT-170 message: none to parent wireload
Timing Report: shows designware with parent wireloads
Condition 6: Implementing fix from ESNUG 326 so that library
default_wire_load is equal to parent design wireload,
auto_wireload_selection = true.
OPT-170 message: none to parent, then parent to auto-selected
Timing Report: shows designware with auto-selected wireloads
For condition 1, I tried ungrouping and then report_timing again. The
timing did not change, indicatating that the designware inherited the
parent wireload as you said. After ungrouping and retiming the other
conditions, the timing changed as expected to indicate the designware was
indeed using the reported wireloads.
I previously reported that the auto_wireload_selection value didn't change
the result, but here it obviously did. These results support the order you
specified. I am surprised to find the library default_wire_load has a
higher priority than the parent design's wireload. Condition 1 and
Condition 5 both seem to get around the problem. I prefer to see the
hierarchy and their associated wireloads as they occur in Condition 5.
- Bob Wiegand
Ensoniq Corp. Malvern, PA
---- ---- ---- ---- ---- ---- ----
From: [ A Synopsys CAE ]
To: Bob Wiegand <rwiegand@ensoniq.com>
Bob, just a summary of my experiences from what we discussed:
When you are doing hierarchical compiles, paying attention to how wireloads
are applied throughout the hierarchy is very important. When you synthesize
a design from RTL, any inferred operators (DesignWares) "pop" into existence
during synthesis. Here is how their wireload model is inferred:
* if the wire_load_mode of top is used, the wireload of the
current_design is used, else
* if auto_wire_load_selection is enabled, a wireload is selected
based on area, else
* if a default_wire_load exists on the target_library, this
wireload is used, else
* the wireload of the first parent design with a wireload is used.
Note that in the last case, you will see no wireload when you do a
report_design on these subdesigns. The wireload is not explicitly set when
it inherts; rather, it inherits dynamically. Ideally, you normally want
DesignWares to use the wireload of their parent. This means that you must
set auto_wire_load_selection=false in your DC setup, plus you must remove
any default_wire_load attributes from your libraries after you link:
remove_attribute find(library) default_wire_load
Once this is done, you can simply set a mode of enclosed, and set the
desired wireload on the current_design and any subdesigns. From these
user-specified designs down, the wireload will be propagated automatically.
If this is the desired methodology, it's advisable to set
auto_wire_load_selection=false
in your .synopsys_dc.setup, and use read_db/remove_attribute/write_lib to
create custom libraries without any default_wire_load. Then, this flow is
totally transparent.
- [ A Synopsys CAE ]
( ESNUG 328 Item 7 ) ----------------------------------------------- [9/9/99]
From: Lou Villarosa <louv@paradyne.com>
Subject: Can I Prevent DC From Replacing The Original Cell Instance Names?
John,
In my design .db, I have cell names like "counter_reg(0)". When I write out
the design to VHDL for gate level simulation, the instance name changes to
"counter_reg_0_label".
When I try to back annotate the SDF file from the traget vendor in my VHDL
simulator, I encounter errors because the SDF file used the original cell
name, "counter_reg(0)".
How do I prevent Synopsys from replacing the original cell names?
- Lou Villarosa Jr.
Paradyne Corporation
( ESNUG 328 Item 8 ) ----------------------------------------------- [9/9/99]
From: Gzim Derti <gderti@intrinsix.com>
Subject: ( ESNUG 315 #8 ) Headaches Because PrimeTime Tcl Lacks "Ldelete"
Hi John,
Here's a question for the masses that came up when I was playing with
PrimeTime... By the by, I want to THANK Paul Zimmer at Cerent for his
posting in ESNUG 315 Item 8!!!! I forgot about it until I NEEDED to
get the simple name out of a collection, or his fullname proc!!!!
I was banging my head for about an hour before I re-read his note that I
had saved off.... It was KILLING me, (%#@(*&^#$ full_name....
Does anyone have an answer as to why Synopsys chose to use TCL but
NOT include ldelete in their commands??? By using add_to_collection or
remove_from_collection, you need to create a NEW collection rather than
using a single one and for me that gets to be cumbersome. I can take
a collection named, let's say, input_pins, and by using lappend be able
to add another pin to the collection and use the same name rather than
creating and using another name. When I want to REMOVE an object from
said collection, I tried to use the TCL ldelete command, but PrimeTime
gives me "unknown command". Any one know why??? Or better yet, how
to possibly get around it???
I've also tried the following, to no avail:
pt_shell> set l1 [all_inputs]
{"CARRY_IN", "CLOCK", "CONDITION_CODE", "CONDITION_CODE_ENABLE",
"D[10]", "D[11]", "D[12]", "D[1]", "D[2]", "D[3]", "D[4]", "D[5]",
"D[6]", "D[7]", "D[8]", "D[9]", "INSTRUCTION[0]", "INSTRUCTION[1]",
"INSTRUCTION[2]", "INSTRUCTION[3]", "RELOAD"}
pt_shell> query $l1
{"CARRY_IN", "CLOCK", "CONDITION_CODE", "CONDITION_CODE_ENABLE",
"D[10]", "D[11]", "D[12]", "D[1]", "D[2]", "D[3]", "D[4]", "D[5]",
"D[6]", "D[7]", "D[8]", "D[9]", "INSTRUCTION[0]", "INSTRUCTION[1]",
"INSTRUCTION[2]", "INSTRUCTION[3]", "RELOAD"}
pt_shell> set l1 [lminus $l1 {"CLOCK"}]
{"CARRY_IN", "CLOCK", "CONDITION_CODE", "CONDITION_CODE_ENABLE",
"D[10]", "D[11]", "D[12]", "D[1]", "D[2]", "D[3]", "D[4]", "D[5]",
"D[6]", "D[7]", "D[8]", "D[9]", "INSTRUCTION[0]", "INSTRUCTION[1]",
"INSTRUCTION[2]", "INSTRUCTION[3]", "RELOAD"}
pt_shell> query $l1
{"CARRY_IN", "CLOCK", "CONDITION_CODE", "CONDITION_CODE_ENABLE",
"D[10]", "D[11]", "D[12]", "D[1]", "D[2]", "D[3]", "D[4]", "D[5]",
"D[6]", "D[7]", "D[8]", "D[9]", "INSTRUCTION[0]", "INSTRUCTION[1]",
"INSTRUCTION[2]", "INSTRUCTION[3]", "RELOAD"}
pt_shell> set l1 [lminus $l1 [index_collection $l1 1]]
{"CARRY_IN", "CLOCK", "CONDITION_CODE", "CONDITION_CODE_ENABLE",
"D[10]", "D[11]", "D[12]", "D[1]", "D[2]", "D[3]", "D[4]", "D[5]",
"D[6]", "D[7]", "D[8]", "D[9]", "INSTRUCTION[0]", "INSTRUCTION[1]",
"INSTRUCTION[2]", "INSTRUCTION[3]", "RELOAD"}
pt_shell> query $l1
{"CARRY_IN", "CLOCK", "CONDITION_CODE", "CONDITION_CODE_ENABLE",
"D[10]", "D[11]", "D[12]", "D[1]", "D[2]", "D[3]", "D[4]", "D[5]",
"D[6]", "D[7]", "D[8]", "D[9]", "INSTRUCTION[0]", "INSTRUCTION[1]",
"INSTRUCTION[2]", "INSTRUCTION[3]", "RELOAD"}
Does anyone have an answer as to why Synopsys chose to use TCL but
NOT include ldelete in their commands???
- Gzim Derti
Intrinsix Corp. Rochester, NY
( ESNUG 328 Item 9 ) ----------------------------------------------- [9/9/99]
Subject: ( ESNUG 327 #12 ) In Attempting To Synthesize Fixed Time Delays
> To the best of my knowledge, I've never seen a delay element like this in
> a standard FPGA or ASIC device. If there was one, then you could use VHDL
> to synthesize it.
>
> Most people use one of the two following techniques to solve this problem:
>
> 1) Design your circuit assuming that all gates and nets have a very small,
> but non-zero delay time. For example, you can design a reliable
> synchronous circuits w/o the use of delay elements of any kind. For
> examples of this, you can refer to our 'WISHBONE' interconnection
> system on our website at http://www.silicore.net
>
> 2) If you really need a delay element, then you can add one external to
> the part. There are quite a few companies that make delay line
> devices, which give very precise timing delays. Kappa, Delay Devices
> and Dallas Semiconductor are a few companies.
>
> Also, you can make your own very predictable fixed delay elements with
> inductor/capacitor parts.
>
> - Wade D. Peterson
> Silicore Corporation Minneapolis, MN
From: "D. M. H. Walker" <walker@cs.tamu.edu>
John,
On item 12, respondents implied perhaps inadvertently that fixed delays
are not available on chip. Many papers have been published on accurate
on-chip delay lines, most commonly used in clock and communications
circuits. They typically require referencing to a known clock via a phase
or delay locked loop, which is probably way more circuitry than the
requestor desired. Just adding some extra gate delays and hoping for
appropriate tracking is the way to create bad designs. A recent IEEE
Circuits and Devices magazine article discussed timing chains as commonly
used in memory arrays. It did not adequately address process variation, but
gives a starting point. I would say that at the RTL or logic design level,
you cannot get closer to a target delay than +/- 30% of one typical gate
delay, and if you don't have lots of vendor data you could easily do much
worse. Since presumably the requestor is interested in tracked delays than
absolute delays, they might do better by putting several gates in parallel
and making sure they are spread out during P&R so as to average the
intra-die process variation. But in general such designs have poor
manufacturability unless they were done using detailed knowledge of the
physical design and manufacturing process, i.e. not an ASIC design flow.
- Duncan M. (Hank) Walker
Texas A&M University College Station, TX
( ESNUG 328 Item 10 ) ---------------------------------------------- [9/9/99]
Subject: ( ESNUG 327 #8 ) How Secure PGP IP Encryption Technically Works
> "It doesn't matter what encryption algorithm is chosen, it doesn't solve
> the problem," wrote Steven Sharp of Cadence. "The problem is, who gets
> the key? You can't put the key into some published standard, because
> then anyone could decrypt and steal the code. IP vendors can't give
> their key to their licensed users, because if the user could be trusted,
> the encryption wouldn't have been needed. That means that the key has
> to be embedded in the tools."
>
> "Now the question becomes, which tool vendors do we trust with this key?"
> continues Steven. "Since it is a standard, should we give it to any
> vendor who wants it? What about a vendor whose product is a code decrypter
> to let people steal IP, or is just a front for a company stealing IP?"
>
> "One possible alternative would be for each IP vendor to use a different
> key and provide it to those vendors they consider trustworthy. This would
> complicate the entire process, and is still susceptible to leaks and the
> resulting finger-pointing."
>
> - Steven Sharp of Cadence (from "Why PGP IP Doesn't Work")
From: Matt Christiano <matt@globes.com>
John,
What Steven says is correct.
If the IP is only usable by the (vendor-specific) tool, then they could
license it's use with a FLEXlm feature, just as they license the use of the
tool generically.
On the other hand, if the IP is in some industry-standard format, such that
it's usable by tools from a number of vendors, then a standard encryption
package isn't of much use. Once you give someone the key, they can either
give the key to everyone, or they can give the non-encrypted version of the
IP to everyone.
Encryption packages operate on the priciple that *both* the sender and the
receiver of the encrypted data actually want to keep it secret. Otherwise,
you don't need the encryption in the first place.
We developed our FLEXcrypt product to solve a part of this problem, you can
give a different key to every customer, or even a machine-specific decryption
key. But even so, it doesn't solve the problem that any legitimate person
who has a decryption key could then redistribute the decrypted IP. To solve
that problem, you need some kind of watermarking technology. Of course,
watermarking only solves the "audit-trail" part of the problem, it doesn't
prevent others from gaining access to the IP. With watermarking, you are
depending on the fact that the legitimate user will not want an unlicensed
user to end up with a copy of the IP that is tracable back to them.
- Matt Christiano, CEO
GLOBEtrotter Software San Jose, CA
---- ---- ---- ---- ---- ---- ----
> PGP uses something called "Public Key Encryption" rather than the traditional
> "Private Key" mechanism. Rather than having a single key for the document,
> the PGP uses two keys: 1 public and 1 secret. Data may be encrypted with
> either key, and decryption requires the opposite key.
>
> - David Black
> Qualis Design Austin, TX
From: Lee Bradshaw <lee@sectionIV.com>
Hi John,
Actually there is also a session key. The message is actually encrypted
with this session key using a fast private key algorithm. The slow
public key algorithm is only used to encrypt the session key. If
you're sending a message to several users, the session key will be
encrypted with each of their public keys. The recipeints use their
private key to decrypt the session key and then use that (and the much
faster algorithm) to decrypt the message. So the message size only
grows slightly with multiple recipients and the message itself is only
encrypted once.
For handing out IP, you would probably want to use different session
keys and encrypt the message once per customer as mentioned below. I'm
not convinced that any kind of encryption is reliable when you're using
networked computers. The algorithm may be fine, but there are many ways
to observe the password/passphrase used to unlock the secret key. (Do
your users control access to the display with xhost, MIT magic cookies,
xdm authorization, or kerberos? Are the more secure implementations bug
free?) Companies may want to make a reasonable effort and then admit
that they probably can't stop a determined thief (especially one with
physical access to a customer site.) I'm not saying the the encryption
algorithms have to be broken, but that giving an entire design team the
ability to use an encrypted file opens lots of holes for carelessness,
deception,...
- Lee Bradshaw
Alantro Communications
|
|
