( ESNUG 318 Item 4 ) --------------------------------------------- [5/21/99]
Subject: ( ESNUG 314 #1 315 #1 ) A Synopsys Rebuttal About Design Reuse
> Design reuse largely fails for one main reason: motivation. Engineers
> (myself included) do not want to reuse somebody else's design. Engineers
> want to "create" and for the most part, they do _not_ want to modify
> another engineers code to do it. The prevailing attitude is: "I'm the
> design engineer now, I'll do it my way!"
>
> Since we all know that the verification effort is growing much faster than
> design complexity, why is the EDA industry focusing so much effort on the
> _easy_ part of the job (reuse) and not on TESTING? New, fluffy,
> IP-oriented EDA tools like Synopsys CoreBuilder and CoreConsultant are a
> waste of everyone's time. What we engineers _really_ want are EDA tools
> that make _testing_ more and more effortless!
>
> - Cliff Cummings
> Sunburst Design Beaverton, OR
From: [ John Chilton, VP/GM Design Reuse at Synopsys ]
John,
I read with interest the postings from Cliff Cummings (Design Reuse is myth)
and Dave Brier (coreBuilder uses proprietary encryption) in ESNUG 315.
We're especially pleased to see significant interest and discussion about
our reuse tools, both in ESNUG, and after our public announcement at IP'99.
I am the VP/GM responsible for Synopsys' reuse activities (including the
coreBuilder/coreConsultant tools that Mr. Cummings says "Kinda Suck"), so I
thought I should respond to some of his points as well as clarify Mr.
Brier's misconception about encryption in our reuse tools.
Mr. Cummings obviously is not a proponent of reuse, but he brings up a lot
of great points that are still shared by many engineers. He mentions the
Reuse Methodology Manual--I'm convinced that some people still think that
the RMM is some sort of an evil Synopsys conspiracy. Actually, we,
together with Mentor Graphics, published the RMM last year, because we
really thought that many people who were actively trying to institute reuse
practices kept spinning their wheels. There was a crying need for a common
understanding of the most basic principles. It's not the be-all/end-all of
design, but it covers a lot of good engineering practice (note that one of
the first observations of the RMM is that the first step toward
"design-for-reuse" is solid "design-for-use!" Some engineers out there must
like it because the RMM, because it constantly sells out at Amazon.com (no,
this is not a big source of revenue for Synopsys).
Having talked about reuse with hundreds of engineers over the last two
years, I can assure everyone that reuse is not a myth. It's a practical
reality and just common sense. I agree with Mr. Cummings that engineers
don't want to reuse someone else's design if the alternative is to design
something interesting if it's easier to do this than to reuse an existing
solution. What I don't understand is why anyone would want to create a new
CPU if an existing one would do, or why they'd want to sit down with 600
pages of standards documentation and design the world's ten-thousandth PCI
core, USB, MPEG, vector-multiplier or 8051. This is especially true if you
are responsible for a million gate design to be delivered in one year. It
would take a very special engineer, with a very understanding significant
other, to want to write those 300,000 lines of RTL, scripts, testbenchand
documentation from scratch.
What nobody wants to do is mess with someone else's design that either does
not work or is hard to figure out. That's where coreBuilder and
coreConsultant come in. These tools are not just fluff. They started out as
the vision of one of our best synthesis engineers about four years ago. He
put together a team of experienced DC engineers and developed a tool with
pretty deep technology. For example, one feature of the tool is that it
automates synthesis. This was necessary, because you can't require someone
to write and debug synthesis scripts for a piece of IP that they didn't
design (makes a lot of sense - that's the part that nobody wants to do).
They worked pretty hard to put into the tools strategies that an expert DC
user would employ, and it works. For example, we make an 8051 core, and we
thought that the scripts that we had written for it were pretty good.
It's either very good news (great tool) or very bad news (terrible scripts
to begin with), but when we ran the part through coreBuilder and
coreConsultant, it synthesized substantially smaller. We've seen similar
results with other cores with well structured designs. We've also seen no
improvement on designs that are poorly structured (those darn computers
aren't good at random tasks). coreBuilder guides the user to enter all the
information necessary for quality (and process-portable] synthesis; in each
case so far, it's detected problems with the existing core information
(e.g., missing or inappropriate constraints).
I'm not going to degenerate into a sales pitch here, but Mr. Cummings
mentioned that the main problem is testbenches. Here we have some good
news... One of the features of coreBuilder/coreConsultant is that it can
automatically configure the testbench along with the core. This is how we
ship our DWPCI macrocell in the Foundation library. You tell coreConsultant
(no licence needed for this tool--it's free like Adobe Acrobat reader) what
you want (64 bit, 64 MHz, xyz parameter, etc) and out spits an optimal
technology mapped netlist and a configured VERA testbench (which you can
run with VERACORE - again, no licence needed).
> I'm not too happy about the new Synopsys IP delivery tools. The problem
> I have with them is that they are tied to proprietary formats once again.
>
> Yuck.
>
> Rather than sit around complaining, my engineering group discussed the
> IP delivery problem and came up w/ the following solution. Our idea is to
> use a true encryption engine, with _no_ proprietary anything, to create
> secure source files for the exchange of IP via PGP. PGP is readily
> available around the world and easily used. We are proposing is that all
> EDA tools be able to call the PGP algorithm when they read a file if
> required.
>
> - Dave Brier
> Texas Instruments Dallas, TX
Regarding Mr. Brier's observations on encryption for IP -- his comments are
interesting and worth investigation, but are, in fact, based on
misinformation about our tools. To set the record straight, encryption of a
coreKit and the files that coreConsultant produces (e.g., RTL) is
**strictly optional**. It's done only if the **provider** of the core
chooses this option when using coreBuilder to create the coreKit. We put
this feature into the product based on consistent customer demand.
Specifically, core designers want to preserve the black-box nature of the
reusable core; hence, they want to keep core end-users from modifying the
source. In addition, they asked for a level of *basic* (lightweight)
protection of their RTL to "keep honest people honest," and to satisfy
legal IP protection requirements. Synopsys core competency isn't
encryption, so we welcome Mr. Brier's suggestions that we (and the EDA
industry) consider PGP (or perhaps other industrial encryption like RSA).
- [ John Chilton, VP/GM Design Reuse at Synopsys ]
|
|
