( ESNUG 266 Item 4 ) -------------------------------------------- [9/18/97]

Subject: ( ESNUG 264 #1 265 #2 )  Synthesizable IP Is *Unprotected* IP

> On one hand, we want to distribute IP to our customers, so they
> can synthesize them to gates, adjust the synthesis to meet their
> own constraints, and simulate with back annotated information 
> the entire ASIC.   On the other hand, we want to guarantee that our
> customers cannot copy the IP and make their own, *AND* we do not want
> them to be able to simply re-synthesize to another process after we have
> completed the design stage with them, and then fab it somewhere else.


From: walker@cs.tamu.edu  (Duncan M. "Hank" Walker)

John,

The problem is even worse than described.  This topic was discussed at
the VLSI Test Symposium in the context of how do you make cores testable in
their embedded environment, without giving too much information to the
user.  There was one paper from LSI on trying to do this for full scan
designs, and scanning from 0 to 100% of the core I/Os.  A bunch of IBM
people in the audience said that they had studied this, and found that if
your design was full scan, it was straightforward to reverse engineer the
logic, so you had no gate-level IP protection.  At best you had protection
for the higher-level meaning of the core algorithms, RTL, etc.  But
documentation may help the user figure them out too.

It sounds like you are more concerned about having the user synthesize to
gates, and then tech map to a non-TI cell library.  As you mentioned, this
is fundamental unless the synthesis procedure uses some sort of encryption
to prevent the IP from being synthesized to a non-matching library.  But is
this the real issue?  It would seem to me this is only the case for
commodity-type library elements.  I thought the whole point of TI's shift
to being an IP provider was that their value added was complex cores such
as DSPs, DRAM, etc., that are not easily replicated.  I have a hard time
believing many people will be able to take a TI DRAM macro and fab it at
another vendor reliably.

After spending the summer working on gigahertz microprocessor issues, I
guess I believe that a high-performance, library-independent, soft macro is
an oxymoron.  This will work for toaster ovens and slow, low power things.
But anything fast must have its physical design tuned to a specific process.

And can't this whole "fab only with us" thing be taken care of by a license
agreement?

  - Duncan M. (Hank) Walker
    Texas A&M University

         ----    ----    ----    ----    ----    ----   ----

From: krag@lsil.com (Kevin R. Grotjohn)

John,

Here is an idea for solving ASIC vendors "soft" IP being reused with other
ASIC vendors as a target: As most IP is in ASCII form - EDA vendors need to
support standard key based encryption for reading/writing ASCII files.  The
technology name that the tool is using must match that encrypted into the
key.  The use of the keys themselves would be licensed using standard unix
license keys.  The ASIC vendor would the license use of the IP for a given
technology and timeframe using the combination of keys.

  - Kevin R. Grotjohn
    LSI Logic



 Sign up for the DeepChip newsletter.
Email
 Read what EDA tool users really think.


Feedback About Wiretaps ESNUGs SIGN UP! Downloads Trip Reports Advertise

"Relax. This is a discussion. Anything said here is just one engineer's opinion. Email in your dissenting letter and it'll be published, too."
This Web Site Is Modified Every 2-3 Days
Copyright 1991-2024 John Cooley.  All Rights Reserved.
| Contact John Cooley | Webmaster | Legal | Feedback Form |

   !!!     "It's not a BUG,
  /o o\  /  it's a FEATURE!"
 (  >  )
  \ - / 
  _] [_     (jcooley 1991)