Editor's Note: Sorry, folks. No colorful intro this week. Did all my
writing in Item 1 below. If you sell EDA, you just might want to read it.
- John Cooley
the ESNUG guy
( ESNUG 327 Subjects ) --------------------------------------------- [9/2/99]
Item 1: Warning To EDA Vendors/Makers -- Flex-LM Compromised On Windows NT
Item 2: ( ESNUG 326 #1 ) Customers Mixed About New Synopsys Pricing Models
Item 3: ( ESNUG 326 #10 ) Metastability 'Z' Is A Real Issue For FPGAs!
Item 4: Seeking The Design And/Or HDL Code To Internally Multiply A Clock
Item 5: ( ESNUG 326 #9 ) My Nightmare Using >2 Gig of Memory in DC_Shell
Item 6: ( ESNUG 325 #1 ) Avanti Timing-Driven P&R Clashes With Synopsys
Item 7: ( ESNUG 326 #12 ) LINUX For A Cadence File-Locking Daemon Server
Item 8: Four Users Explain Technically How Secure PGP IP Encryption Works
Item 9: Insuring You Get Just One DesignWare Full Adder W/ Design Compiler
Item 10: Synopsys VSS VHDL 99.05 Hogs 2 Gigabyte Of Memory And Just Dies!
Item 11: Trying To Get Chronology's QuickBench BFMs Into Mentor's Renoir
Item 12: Looking For Trouble -- "How Do I Synthesize A Fixed Time Delay?"
Item 13: The PrimeTime "transcript" Tcl Translator Is Pretty Damn Useless!!
The complete, searchable ESNUG Archive Site is at <http://www.DeepChip.com>
( ESNUG 327 Item 1 ) ----------------------------------------------- [9/2/99]
From: jcooley@world.std.com ( John Cooley )
Subject: Warning To EDA Vendors/Makers -- Flex-LM Compromised On Windows NT
There I was, happily minding my own business doing my work when the phone
rang and an EDA vendor buddy I've known & trusted for years called. "John,
you'll love this one. It's a big story. Flex-LM has been compromised
on Windows NT by a group of hackers and they're giving away the software
that does it for free on their web site. It's a 6 Meg download and the
guys at [ EDA Company Name Deleted ] have already tested it. It
successfully created working Flex-LM keys for their software. Ran their
tools and everything. I know you like scoops in ESNUG. Here's a big one."
He told me the http for the hacker site and the name for the Flex-LM
cracking software. He also told me the technical details of exactly how
the software took advantage of a security hole in NT to create keys.
"Oh, and we never had this conversation."
I checked out the web site. Sure enough, there it was with some hacking
propaganda and instructions how to download and use it.
Whoa.
For those who don't know, virtually all of the EDA vendors license their
software using Globetrotter's Flex-LM. This crack would enable anyone
anywhere to use any Windows NT based EDA product for free. And it
gets worst with the fact that most EDA vendors offer "evaluation copies" of
their tools -- suddenly, now, these are technically "free" copies of their
tools for the users who got their hands on this Flex-LM key creator. Plus
networking NT and UNIX systems probably means this crack could enable the
"free" use of UNIX based EDA tools.
Whoa.
In the past, I have published in ESNUG the full details of how Flex-LM was
bypassed by users (setting your system clock back, burn an identical PROM
for all your workstations, plus the details of an Internet hole that, if
your SysAdmin didn't fix would enable others to "borrow" your EDA licenses).
But in each of those cases these details only enabled users who already
*had* paid licenced copies of their EDA tools to do some temporary games,
at best. That is, licensed customers have this need to have to interact a
lot with their EDA tool suppliers. Use these tricks over an extended period
of time, and eventually the sleazy customer would be caught red handed
and they'd be standing right behind Avant!'s Gerry Hsu waiting to go to
jail once his legal stalling tactics all eventually fail...
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.
So, if you're an EDA *developer* (as in you work at a *verifiable*,
checkable actual EDA company), and you e-mail me your complete contact
information, I will tell you the http, the name, and the technical details
of how how this Flex-LM Windows NT cracker works -- so your technical and
legal staff can work on stopping it. And I'll wish you luck.
And if you're another nosey EDA user (like me) wanting to know these
details, I'll have to just say: "Eh?!, no habla... uh. huh? Was ist Das?
Qu'est-ce que what???" :^)
- John Cooley
the ESNUG guy
( ESNUG 327 Item 2 ) ----------------------------------------------- [9/2/99]
Subject: ( ESNUG 326 #1 ) Customers Mixed About New Synopsys Pricing Models
> Your loyal readers urgently need your help. Synopsys is totally changing
> their licensing business model. They have been rolling out the new model
> to most customers over the last few weeks. They had already got feedback
> from their biggest customers over the summer. Of course, they first
> solicited feedback from Wall Street.
>
> They are moving away from perpetual licenses & toward term-based licenses.
> Of course, the prices of perpetual licenses are going up substantially and
> discounts are going down! Please solicit feedback from your readers ASAP
> about these new plans.
>
> They are leaving a window until August 31, 1999 for users to purchase
> licenses uder the old plan. I guess they are hoping for a large influx
> of orders before the window closes.
>
> I can't wait to read ESNUG feedback from this.
>
> - [ Rage Against The Machine ]
From: [ Not In A Panic Yet ]
John,
Please keep me anonymous as I have to negotiate pricing with Synopsys for
my company's field design center, and I do not want this to bite me later.
I can see why your readers are upset, especially the smaller companies.
But overall I think this pricing is advantageous for companies who do
larger, more complicated, DSM ASIC designs. Given the state of flux and
innovative startups pursuing new methodologies in the DSM arena, I feel
like it is impossible to tell exactly which tools will be appropriate
three years from now. So, if the Synopsys model allows me to save some
money now and, three years from now, make a shift in design methodology
when I (maybe) renew my Synopsys licenses, then as a customer I win.
Much as we engineers hate to accept that political reasons enter into
technical decisions, I suspect that many firms will now be more willing
to adopt a new set of design tools if license renewal becomes a routine
part of doing business. You won't have managers saying "Damn...I won't
get promoted if I say that three years ago I made a wrong and expensive
decision, so let's tell the designers they have to do 0.15u design with
0.35u tools..."
And Synopsys did do some things right, most notably adding a WAN option
to their new license models. This is great for ASIC vendors like us,
with design centers across the country with fluctuating license needs.
I am definitely a little bothered by the implied monopoly power, that an
organization feels they can casually raise their prices so significantly.
But paradoxically the fact that users will probably opt for 3-year licenses
means that there will be windows of opportunities for rival EDA vendors at
many of these accounts. If you lose to Synopsys now, but can pass their
technology in three years, you can attack their existing customer base.
It's always tough to unseat the incumbent, but at least the opening is
there without having to ask the customer to trash the existing tool set
(licenses are expiring anyway)! Synopsys might be unwittingly leaving the
door open for new and/or unknown rivals.
So I don't think the new pricing is a disaster. It is definitely an
inconvenience since it pushes some decisions earlier than we would have
liked, but it opens some opportunities down the road.
Please keep me anonymous, but if you need to know for your records that
I am legit and not part of Synopsys' super-secret Misinformation
Department... you can contact me at [ address deleted ] and I'll send
you my company info. Thanks!
- [ Not In A Panic Yet ]
---- ---- ---- ---- ---- ---- ----
From: [ Kenny From South Park ]
John,
Synopsys is going to a "new price structure", which is a thinly disguised
price increase. It may look like you can same money with their "5 year
deal" which locks you into their tools for 5 year, but read the fine print,
you don't. Some tools went up as much as 40% (like Designware-Foundation).
I'm being forced to drop some tools, some of which actually had some
promise, off of maintenance and just go with the core tools to stay within
my maintenance budget (which is fixed). Is there as much "snarling and
gnashing of teeth" about this out there as there is here?
- [ Kenny From South Park ]
---- ---- ---- ---- ---- ---- ----
From: [ Made In Taiwan ]
Hi, John. Please keep me and my company anonymous.
According to SYNOPSYS salesperson, SYNOPSYS' new pricing policy was pushed
out by some big brothers like Intel and Compaq.
I just want to say this pricing policy is pushing me away from SYNOPSYS no
matter how good her tools are. I hope SYNOPSYS can listen to this.
For Design Compiler users, I urge them to go for Cadence AMBIT BuildGates.
Most of our designs have more than 15% off in area with the same Timing
spec. And it runs faster. With BuildGates, you don't need to purchase
different features like HDL-Compiler, Design-Analyzer, HDL-Compiler, ....
You got them all in one package : BuildGates. Plus, you get Scan insertion
option in that package though with a little limitation.
For VCS users, throw it away. We have been using VCS and NC-Verilog for
months. NC-Verilog is much faster now(With 20% speed gain in general).
When they told you VCS is much faster than Verilog-XL. Yes it is true, but
it is unfair. Compare it with NC-Verilog not Verilog-XL !!! (Compiled mode
should compete with compiled mode.)
VCS can not catch up with NC-Verilog now. (Since merged with SYNOPSYS ???)
(And note that how many releases including patches since they merged ??)
For PrimeTime users, try Ambit, too. The Timing Engine is fast and
consistent with the logic synthesizer!!!
And for EPIC, try other circuit level simulators like Star-Time/Star-Sim
from Avanti.
You can name a few for other products. I just want to say to SYNOPSYS
this: 20% is not enough, why not 60% ??!!
- [ Made In Taiwan ]
( ESNUG 327 Item 3 ) ----------------------------------------------- [9/2/99]
Subject: ( ESNUG 326 #10 ) But Metastability 'Z' Is A Real Issue For FPGAs!
> Will metastabily propagate through logic gates even when they're disabled?
> That is, assume I have an AND gate, with two inputs A & B. Input A is a
> signal with a posibility of being in metastable state. (Say, it is the
> output of a flip flop which has an asynchronous input). Now if I make
> input B at logic zero, during the possible period of A being at metastable
> state, what will be the output of this AND gate? Or the question is as
> simple as, if one input of an AND gate is a metastable input and other
> input is a logic zero, what will be its output? What if it is an OR gate
> with the other input at logic one?
>
> - Rejeesh
From: Greg Dean <Greg.Dean@nsc.com>
Hi, John,
It depends on how the AND or OR gate is implemented. Standard cell or
discrete logic component gates are implemented straightforwardly, and a 0 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
( ESNUG 327 Item 4 ) ----------------------------------------------- [9/2/99]
Subject: Seeking The Design And/Or HDL Code To Internally Multiply A Clock
> Will anybody please share to me a simple logic to multiply a clock ( in
> vhdl or verilog). Say 1 Mhz to 2 Mhz. How to keep the multiplied clock's
> duty cycle to perfect or near perfect 50 %.
>
> - ShtlChen India
From: Mark Lancaster <mark.lancaster@motorola.com>
Create two flip-flops. Clock one using the posedge of your clock and the
other using the negedge. XOR their Q outputs. This creates a 50% duty
cycle multiply by 2.
- Mark Lancaster
Motorola
---- ---- ---- ---- ---- ---- ----
From: Mark Lancaster <mark.lancaster@motorola.com>
ACK!! Too early. Haven't had my coffee. Ignore this advice.
- Mark Lancaster
Motorola
---- ---- ---- ---- ---- ---- ----
From: Anup Kadkol <anup@flowwise.com>
try this, might work
reg CLK2;
always @(posedge CLK or negedge CLK)
CLK2 <= 1'b1;
if (CLK2 == 1)
CLK2 <= #delay 1'b0;
The delay can be varied depending on duty cycle will be 500ns in case of
1 MhZ and 50% duty cycle.
- Anup Kadkol
Flowwise
---- ---- ---- ---- ---- ---- ----
From: Rainer Theuer <Rainer.Theuer@sican.de>
Why do you use 1MHz for the master clock ? Implement your design with a
2 MHz master clock and you don't get such problem! :-)
- Rainer Theuer
SICAN GmbH Hannover, Germany
( ESNUG 327 Item 5 ) ----------------------------------------------- [9/2/99]
Subject: ( ESNUG 326 #9 ) My Nightmare Using >2 Gig of Memory in DC_Shell
> Does anybody know ALL the requirements to get dcshell to not crash when it
> wants to allocate more than 2 Gigabytes of memory? Running on Solaris 2.7
> with 'datasize' unlimited. Does the LD_LIBRARY_PATH environment variable
> have to contain /usr/lib/sparcv9?
>
> - Don Monroe
> Tenor Networks Acton, MA
From: Rajen Ramchandani <rajen@jaxom.eng.pko.dec.com>
Hi John,
On the DEC (Compaq) Alpha machines, I've had to increase the vmemoryuse to
unlimited to get it to not crash on the large design I was putting together.
Also one more thing that helped a lot with the final stages of putting the
entire design together was to ungroup and flatten the lower levels of the
design, if I wasnt going to have them in the netlist that we were going to
be handing off to our vendor. They only wanted to see one level of
hierarchy - so all the lower levels were flattened before reading them into
the top level netlist. This helped tremendously in the top level uniquify
step and link step, which used to take hours to complete, now finishes in
minutes.
- Rajen Ramchandani
DEC (Compaq)
---- ---- ---- ---- ---- ---- ----
From: Gerard McCarthy <gerardm@pdd.3com.com>
John,
We've done this on Solaris 2.6.1, so 2.7 should be OK. First you need to
have the correct release. 99.05 or 98.08-1 supports >2G memory. 98.08
or earlier does not unlimit the datasize ( won't unlimit stacksize ).
Make sure you are using a csh, sh will limit the size to 2G.
Nothing else is special unless you are running an odd release.
If you can get hold of proctool -- a SUN process analysis tool -- then you
can see the process limits in Process Properties -> Process Limits
ftp://nce.sun.ca/pub/freeware/SOURCES/PROCTOOL/proctool_1999_04.tar.gz
- Gerard McCarthy
3Com Limited UK
( ESNUG 327 Item 6 ) ----------------------------------------------- [9/2/99]
Subject: ( ESNUG 325 #1 ) Avanti Timing-Driven P&R Clashes With Synopsys
> Currently, we just use the Timing Driven feature of Avanti P&R and it
> turned out to be a nightmare because our frontend designers love the path
> segmentation feature of Synopsys and they create a false path from any
> point to any point by just creating a hierarchy there. Then when you go to
> the Avanti backend tool you have to dig out each net, or cell Input/Output
> and tell it to disable timing through it. OK, it is similar to doing it
> in the front end, but then you have hierarchy in front end, and a flattened
> verilog netlist at the backend.
>
> I hope Avanti Static Timing Analysis can start supporting something more
> then just the CLK pins / input ports and D pin of FF / output ports for
> its start and end points.
>
> - Manish Shrivastava
From: "Paul.Zimmer" <paul.zimmer@cerent.com>
This is just the tip of the iceberg. I work on telecom chips with lots
of muxed clocks and multi-cycle paths. By extensive use of looping and
proc's in tcl, I've managed to keep the primetime script for the current
chip down to about 20 pages.
The timing-driven layout tool MUST understand all of this. If it doesn't
understand it, then it's optimizing with garbage.
Even with simpler chips, the timing-driven layout tool is going to have
to understand quite a lot. Do you really want it spending all of
its cycles, and hurt timing on your critical path, trying to optimize
all your multicycle processor read/write paths because it doesn't
know they're multicycle?
Even if the P&R static timer has all the hooks required, I'm really
not excited about trying to re-do all that PrimeTime code for
another static timer.
My opinion is that the placement tools will have to hooked
directly to the static timing tool. This obviously gives Synopsys
a big leg up, since it now virtually owns static timing.
Synopsys has already announced that it is headed this way. Aart made
it clear several years ago that he considers the common static timing
"backbone" to be a key component.
Unfortunately, the desired backbone is PrimeTime, but their current
backend tools only support DesignTime. If you have complex clocking
situations, the difference is very noticable. But, I'm sure they're
working on this (at least, I hope so!).
- Paul Zimmer
Cerent Corp.
( ESNUG 327 Item 7 ) ----------------------------------------------- [9/2/99]
Subject: ( ESNUG 326 #12 ) LINUX For A Cadence File-Locking Daemon Server
>> Does anyone know if the Cadence cdsd file-locking daemon runs on Linux,
>> i.e. is it possible to use a Linux (RedHat 6) file server when we run
>> Cadence on our Suns?
>>
>> - Philippe Duchene
>> Snake Tech
>
> Philippe,
>
> That should be no problem at all. The main important factor is that the
> server adhere to proper NFS protocol. As long as it does that, no app
> cares where you store it. I am not a Linux person, but from what I know
> about it, it does NFS just fine.
>
> One of my file servers is a 48 GByte file system from Falcon. It's split
> into three partitions, 2 - 12 GBytes and 1 - 24 GBytes. All of our apps
> are stored on the 24 GByte partition and NFS mounted to our Suns and
> compute servers. The file server itself is DOS based PC. I have been
> storing my Cadence (or Valid as it use to be) installs on remote file
> systems for over 10 years.
>
> Some of our applications must support multiple Operating Systems (SunOS
> 4.x and SunOS 5.x) and multiple platforms (Sun, SGI, HP). If you get the
> right software, you can even store PC applications. A generic file
> server, IMHO, is the only way to go.
>
> - Martin E. Meserve
> Lockheed Martin M&DS - Reconnaissance Systems
From: srm@Pacesetter.COM (Steven Ma)
Martin,
Cdsd is only used in Cadence DFII (IC) tool suits. The old Valid tools went
into Cadence Performance Engineering (PE) tool suits. It's true that PE
tools up to today do not require cdsd file locking daemon since they don't
really operate in a framework type of environment. (Valid had tried it with
ValidFrame and it didn't get accepted well.) It was the philosophy of open
system, that came from Valid days -- ASCII database, SCALD methodology, etc.
keeps PE tools running w/o the constraints of storage server architecture.
As long as the files can be referenced by an UNIX path, NFS/AFS or whatever
it doesn't matter where they are resided on the network.
On the other hand, the Cadence IC tools operate in Design Framework II
environment require tight integration of all cell views, libraries with the
applications. That's why a file locking daemon like cdsd has to keep track
of which file is been accessed by which user, on which machine, by which
tool. Once an user fired up icds/icms/icfb and opened a cell view in a
library, the cdsd running on his workstation will send access request to the
cdsd running on the file server, then the server cdsd will place locks on
the files. For non-supported operating systems, other than Solaris, HPUX,
AIX, a proxy server is needed to act as the agent for network storage
devices to perform file locking services for the requesting clients.
- Steven Ma
Pacesetter, Inc.
P.S. We were one of the Valid *IC* customers who had gone thru the pain of
converting from SCALD to DFII.
( ESNUG 327 Item 8 ) ----------------------------------------------- [9/2/99]
Subject: Four Users Explain Technically How Secure PGP IP Encryption 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: "David G. Koontz" <koontz@ariolimax.com>
Hi, John,
How about throwing the key down a well so no one can unlock it. If
you can't protect your IP by contractual obligation, and you are
so afraid of someone stealing it, don't distribute it. The half life
of IP is probably less than 3 years. Its a self correcting problem.
It is possible to steal tools today, yet companies are not going out
of business because of forged licenses. The amount of work is roughly
on par with recovering a key from a tool for encrypted IP. The good
news is that there are probably around 250 people world wide with the
skill and knowledge base to steal licenses or encrypted IP. Amazing
that you don't hear any hints of success stories other than from
the former Soviet Union. You can always limit theft by attacking
re-distribution channels. I remember one Moscovite telling me you
could buy all of MicroSoft's SW on a CDROM for a few dollars. Yesterday
in the newspaper there was an item describing a mountain of CDROMs
containing stolen intellectual property having been destroyed in the
former Soviet Union.
Heck, a network in a simulator is essentially a database. Someone
could write a tool to traverse IP loaded in a simulator. You ever
notice how many vendors limit the distribution of encrypted Software,
IP and intellectual property? Locks keep honest people honest.
Access denial keeps others from stealing.
- David G. Koontz
ArioliMax
---- ---- ---- ---- ---- ---- ----
From: "Dan Oelke" <Dan@oelke.com>
Dear John,
After reading your recent column on Why PGP IP doesn't work, I felt I had to
reply to correct some incorrect statements.
Towards the end, a quote from Steven Sharp states that if the encryption is
built into tools, then people will reverse-engineer it and be able to break
the encryption. This is simply false. The beauty of really good encryption
schemes is that people can know decryption scheme, but if they don't have
the key they can't decrypt the data. The more that is known about the
algorithms, the more trust you can put in them.
Now, even with correcting Steven's one misperception, I must concede that at
some point somebody must be able to decrypt the IP to use it, and that person
might not be trustworthy, resulting in a possible loss of IP.
Then again, since Steven doesn't have a basic understanding of what you need
to trust your encryption, I would like to see details of Dave Brier's scheme,
because it might address this problem as well.
- Dan Oelke
---- ---- ---- ---- ---- ---- ----
From: Howard Landman <HowardL@SiTera.com>
Hi, John,
There's a reasonable solution to this using separate keys for the customer
and IP vendor. Tool vendors get treated like customers in this model.
The IP vendor has an encryption key (call it IPEK) and a decryption key
(IPDK); each customer creates their own encryption key (CuEK) and decryption
key (CuDK).
The IP vendor gives the IPDK to the tool vendors, who incorporate it into
their products. Each tool vendor also makes their own set of "customer"
keys so they can pretend to be a customer. Each customer (and tool vendor)
gives the IP vendor their CuEK.
NOW: The IP Vendor has to encrypt their IP differently for each customer.
They do this in the order IP -> CuEK -> IPEK -> file. Then they give the
encrypted file to the customer.
The customer feeds their CuDK into the tool, which already contains the
IPDK. The tool then decrypts in the order file -> IPDK -> CuDK -> IP.
The IP vendor can use IP test cases with tool vendors which are not the real
IP that they sell. This is adequate to test the encryption/decryption. So,
the tool vendors never have to see any "real" IP unless the IP vendor wants
them to. Because the tool vendor's CuDK is different from any other CuDK,
even if they get ahold of some other customer's encrypted IP file, they'll
only be able to decrypt it halfway, because they don't have that customer's
CuDK.
In order to break this, a tool vendor needs to get both a customer's
encrypted file and also the matching CuDK. Similarly, one customer would
not be able to use another customer's file. Of course, this is still
subject to "social engineering" attacks (e.g. mercenary customer employee
sells key to unethical tool vendor), but what isn't?
- Howard A. Landman
SiTera, Inc. Longmont, CO
---- ---- ---- ---- ---- ---- ----
From: David C Black <dcblack@qualis.com>
Hi, John,
Boy did Steve Sharp from Cadence put his foot in your mouth. Please take
the time to carefully read and understand the following. There are
three sections:
1. PGP EXPLANATION
2. WHERE IT FAILS
3. ADDITIONAL SAFETY MEASURES
4. ABOUT ENCRYPTION SAFETY
5. CONCLUSION.
PGP EXPLANATION
~~~~~~~~~~~~~~~~
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.
Each party in a typical transaction owns a key pair. Thus there are four
(4) keys involved.
Allow me to give a clear example of how this works:
1. EDA customer requests a license from an IP vendor and supplies
his (customer's) public key to the vendor.
2. Vendor processes request (license agreement and money), and
then send's the customer a copy of the IP encrypted with with
the CUSTOMER's own public key and SIGNED with the vendor's secret key.
3. EDA customer verifies the signature using the vendor's public key
and proceeds to use the IP using the customer's secret key.
Thus, nobody except those with access to the customer's secret key can
access the IP (not even the vendor unless they added their own public key
during encryption!). If multiple customer's are involved, the vendor would
have to encrypt multiple times. If the customer gave out their secret key
and the IP, it would be fairly easy to prove who did it.
WHERE IT FAILS
~~~~~~~~~~~~~~~
Now some notes on where this falls down:
A. If customer decides to copy or illegally use the IP (e.g. sell the
decrypted copy to somebody else), the only recourse of the vendor is
legal. If the vendor can establish that it has taken appropriate
measures to secure its IP, they will hopefully win in a court of law.
B. If the customer doesn't take measures to protect the vendor's IP,
it could be stolen from the customer.
Neither of the above is particularly different from traditional issues. The
only thing new is that the IP was transmitted electronically.
ADDITIONAL SAFETY MEASURES
~~~~~~~~~~~~~~~~~~~~~~~~~~~
A sly vendor would take one additional step (which does entail some
additional cost and effort). Prior to encryption, they would perform a
simple transformation on some of the IP that would preserve the function,
but change the order or naming of some components of the IP for a particular
customer such that the IP would be very likely to be identifiable even in
the event of modifications. For example, consider the simple register
implementation:
always @(posedge clock) begin :X_REG
if (reset) begin :RESET_X_REG
x_ff <= 0;
end
else begin :CAPTURE_X_REG
x_ff <= data_in;
end
end
By changing the block labels (not really needed), adding or removing the
begin/end's, grouping some registers in common blocks and rearranging the
ordering of parallel blocks (always & initial), renaming sub-blocks, etc.
one can obtain many "signatures" in the IP itself. This can be automated
relatively easily. Think of this as similar to watermarks on digital art.
Mind you, this last step is only necessary to establish where the code came
from. It doesn't prevent fraud.
ABOUT ENCRYPTION SAFETY
~~~~~~~~~~~~~~~~~~~~~~~~
Your article also complained about the safety of encryption itself. It is
true that over time, various algorithms are subject to breakage. The safety
of a technique comes from a variety of factors including: the algorithm, key
selection, key security (how you protect the keys themselves), and key
validation/exchange (how do you know who's key you have). There are many
good books on this subject. An advantage of PGP is that it's algorthms are
exposed for public inspection and many people are looking for holes. It's
weaknesses are known, but manageable (see the books for this).
Suffice it to say that every technique has a projected "safety". PGP using
keys of 2048 bits has a projected safety of at least five (5) years I
believe. Given the pace of technology, I suggest this is not too bad. As
computer processing power improves, you can always increase the length of
the keys or move to newer algorithms for newer IP. The idea is not to
prevent fraud, but rather to make it improbable and difficult. Criminals
are eventually caught.
- David Black
Qualis Design Austin, TX
( ESNUG 327 Item 9 ) ----------------------------------------------- [9/2/99]
Subject: Insuring You Get Just One DesignWare Full Adder W/ Design Compiler
> I have all the inputs to a full adder. How to write verilog code so that
> after synthesis synopsys uses its own designware fulladder. Now I am doing
> as follows:
>
> assign {cout, sum} = A + B + cin;
>
> But after synthesis it uses two adders from designware library. I want
> cin to go to a "real" Cin.
>
> - Azhar Quddus
> Tampere University of Technology Finland
From: mguthaus@eecs.umich.edu (Matt Guthaus)
In your .synopsys_dc.setup file add this line: hdlin_use_cin = true
- Matt Guthaus
University of Michigan
( ESNUG 327 Item 10 ) ---------------------------------------------- [9/2/99]
Subject: Synopsys VSS VHDL 99.05 Hogs 2 Gigabyte Of Memory And Just Dies!
> I am trying to revive a test environment from an old design using Synopsys
> VSS version 1999.05. The testbench includes several VHDL libraries, a CLI
> model, and several SmartModels.
>
> Under version 1998.08 of the simulator it ran fine, and immediately after
> elaboration occupied a 73MB memory image (on Sparc Solaris 2.5.1). The
> 99.05 version, during elaboration, rapidly grows and grows its memory
> image until the workstation runs out of resources and kills it (somewhere
> over 2GB image).
>
> Has anyone seen this behavior? I seem to recall many moons ago a previous
> version of VSS behaved this way, but I don't recall which version or what
> the solution was (or if that was just a figment).
>
> Further Details:
>
> - VSS 1999.05-SIM1.0 merged with the synthesis 1999.05-4 tree
> and PT 1999.05-2.1 overlaid
> - SmartModel R41 library (model versions as released last spring)
> - SparcCompiler C 4.0 (for the CLI and compiled VSS stuff)
> - All libraries and RTL trees re-analyzed (VHDL) and re-compiled
> (C) for 1999.05
> - tons of disk space and RAM (1GB physical + 2GB swap)
> - verified OS patches include the one mentioned on SolvNET
> - verified all .synopsys_vss.setup files are pointing at the
> right libraries
> - All libraries and code build and runs fine under 1998.08.
> Two very minor patches are needed to switch versions;
> one typo in a CLI structure member in 1998.08 and one
> VHDL leaf module with a VHDL-93 keyword conflict (for
> the 1999.05 version I substitute a source file with
> the conflicting signal name escaped with \sig\.
> The build includes the vendor ASIC library and the
> smartmodel library.
>
> I contacted Synopsys support, still waiting for callback. (I presume they
> are waiting for a testcase -- I'd prefer not to have to tar up ~45,000
> lines of code in 4 directory trees and explain how to install it. And
> since we just sent a huge maintainence check to them I'm not much in a
> mood to pare it down for them if I can avoid it).
>
> - Kenneth Ryan
> Orbital Sciences Corp. Germantown, MD
From: ryan@oscsystems.com (Ken Ryan)
Never mind... I found the SolvNET article that addresses the problem.
Apparently a SWIFT interface bug that was fixed in VSS 3.5a got
reintroduced for 1999.05. Fortunately the SmartModel guys included
a perl script that patches the library descriptions...
- Kenneth Ryan
Orbital Sciences Corp. Germantown, MD
( ESNUG 327 Item 11 ) ---------------------------------------------- [9/2/99]
From: Bruce.Parker@motorola.com ( Bruce Parker )
Subject: Trying To Get Chronology's QuickBench BFMs Into 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
( ESNUG 327 Item 12 ) ---------------------------------------------- [9/2/99]
Subject: Looking For Trouble -- "How Do I Synthesize A Fixed Time Delay?"
> I simply want to add a single buffer to delay a clock for driving a latch
> for a small amount, say, 20ns. Is it possible to synthesize a fixed time
> delay by some VHDL coding?
>
> - Chi Fung
From: Dave Pears <dpears01@harris.com>
Be very careful here. There really is no such thing as a "fixed delay"
in an actual device. Numbers given in the data sheets are most often
_worst_case_ meaning that the vast majority of devices will actually be
faster, hence less delay. Minimum delays are rarely given, so one really
has no way to control the delay created when a buffer is inserted.
Reminds me of that Mark Twain quote: "A man who carries a cat by the tail
learns something he can learn in no other way."
- Dave Pears
Harris Semiconductor
---- ---- ---- ---- ---- ---- ----
From: Loc Mai <loc.mai@dreo.dnd.ca>
Add more buffers then observe the waveform on scope. I did this way in
my design. Good luck.
- Loc Mai
DND
---- ---- ---- ---- ---- ---- ----
From: "Wade D. Peterson" <peter299@maroon.tc.umn.edu>
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
( ESNUG 327 Item 13 ) ---------------------------------------------- [9/2/99]
From: Rodney Ramsay <rramsay1@ford.com>
Subject: The PrimeTime "transcript" Tcl Translator Is Pretty Damn Useless!!
Hi, John,
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 that 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
|
|
