( ESNUG 363 Item 8 ) --------------------------------------------- [01/25/01]
Subject: ( ESNUG 362 #8 ) Janick Spanked For Dissing Superlog & C++ Design
> Taken from co-design's white paper "Evolving the Next Design Language",
> here are the "new features" that Superlog adds to Verilog:
>
> Software aspects:
>
> - User defined types
> - Enumeration
> - Structures
> - Pointers
> - Recursion
> - Stack, heap
> - Strings
>
> System & Verification aspects:
>
> - Dynamic processes
> - Protocol checking
> - Behaviors to I/O ports
> - Extended FSMs
> - Hierarchical accesses
> - Dynamic arrays and queue
>
> Woohoo! Verilog has been evolved to the software engineering standards
> that prevailed in the eighties!!!! Break out the champage! That may
> represent progress on the design side, but for verification, it does not
> even come close to Vera or Specman. I'll stick with real progress,
> thank you.
>
> - Janick Bergeron on loan at
> Qualis Design Corporation Grenoble, France
From: "Simon J. Davidmann" <simond@co-design.com>
John,
I would like the chance to comment on Janick Bergeron's recent SUPERLOG
comment in ESNUG.
I was somewhat surprised by many comments made, given that Janick has no
first hand experience of the SUPERLOG language or products, and has never
even requested that we provide him a copy, unlike many other people in the
industry.
His comments somehow contradict that age old saying "you can't judge a book
by looking at the cover." This is exactly what Janick has done. Clearly,
from the technical comments he makes, he does not know the content of
SUPERLOG, and has therefore made some guesses. Its sort of like announcing
a victor in an election - before even looking at the votes :-)
I do though agree with some of what Janick says with regard to C usage and
moving forward in general. Presumably, if he "discovers" that we do have
many of the capabilities that he brings up, he would look more favorably on
the language that others have started to use productivity.
Just think (and I know Janick would want this): imagine that the features
and technology in Vera and Verisity were included AS PART of your HDL
simulator, with a several X SPEED IMPROVEMENT over your old
simulator/testtool combination, that works SEAMLESSLY WITH C/C++. Then
dream that you already are familiar with most of the syntax, and in fact
that it is the same language that you wrote your design in... That is
SUPERLOG.
What others have done is create a new syntax with some nice capabilities
for verification specifically (and good luck to them). However, this is
one small, slightly sideways, step.
Evolving a language to have all the features for advanced hardware system
design and verification - now THAT'S VISION - and that's what the creators
of SUPERLOG have accomplished. The fact that they have modelled it on
languages that designers already know just makes it easier.
I am sorry that Janick has only glanced at the cover. I will let him have
an early copy of the book when it is published.
- Simon Davidmann, President & CEO
Co-Design Automation, Inc.
---- ---- ---- ---- ---- ---- ----
From: Lauro Rizzatti <lrizzatti@get2chip.com>
Hi John.
I enjoyed reading Janick Bergeron's piece in ESNUG, "Janick Pisses On
Superlog". Janick writes superbly and his pieces are really entertaining.
Still, I believe this time he went over the edge.
Hardware verification languages are evolutionary not revolutionary as he
stated. They are an excellent example of how the human genius can adapt and
come up with interesting ways to overcome obstacles: minimum code for
maximum efficiency.
Should today verification engines (simulators and accelerators) be capable
to process millions of cycles per second on multi-million gates designs
driven by traditional testbenches (Verilog/VHDL), I wonder whether users
would embrace special languages for help. Today, they don't have a choice
if they want to see the results of their verification efforts in their
life-time. Ironically, despite their code efficiency, hardware verification
languages slow down ever further the verification engines.
As for that pond scum turning into an IPO, I would keep an eye on Superlog,
who knows?
- Lauro Rizzatti
Get2Chip
---- ---- ---- ---- ---- ---- ----
From: David C Black <dcblack@qualis.com>
John,
I would like to respond to the Superlog comments. At Qualis, we take
the independent viewpoint on design methodologies/tools, and that
means we get to play devil's advocate from time to time. For example,
I respect Janick's engineering abilities; however, I disagree with
his comment that "revolutions are necessary" and the implication that
Superlog is a minor evolution. Superlog is quite a rich language
extension over Verilog. There are some more basic issues to consider.
First, we know that it's not the language that makes an activity like
verification successful. It's the methodologies and application that
dictate success or failure. At its core we can do everything with
Verilog or VHDL just as they stand. We also know that language and
tool features can greatly simplify the implementation of a particular
methodology. For example, who needs 'for loops', why not just use
while loops? So adding features to a language can be extremely useful.
The other extreme is adding so much syntax to a language that it
becomes difficult to use. Some of these new "verification" languages
tend towards that latter extreme. Some find Specman Elite to be too
much language with an insufficient gain for the large learning
investment required. For example, there's much hoopla about temporal
expressions, but anyone can do similar things in Verilog. With
Superlog's "process" statement (similar to Vera's "fork/join none"
construct) you can have checks overlapping in time (think of it as
firing the same always block concurrently). In many cases, the extra
syntax is just something more to learn, but unnecessary.
Second, evolution is the way of our species. Evolution is a good way
to preserve investments in ideas that are known to work. Too many
companies have spent much good time and money creating designs with
Verilog and VHDL to want to rewrite them. Certainly, new designs
might want to use new language features, but not if they won't
interoperate smoothly with old code. Reuse was a buzzword of the
recent past that continues to make sense. If we evolve our languages,
reuse is more achievable. Simply, extend existing engines to
understand new language features while preserving the old.
Another problem with revolution is due to the heavy investment on the
personnel side of the equation. Those companies that buy into the new
languages may later regret if they have pressure to change back. An
investment is learning a revolutionary language is expensive in both
time and personnel. Is the industry really going to change completely
to the new verification language, or will this be a small blip? Will
the new languages really be standardized? How much do you stand to
lose if you're wrong?
It might be argued that the new verification languages allow the old
code to continue, because they interface to the existing simulators
via PLI and compiler calls. So we can continue developing with the
existing HDL's. On the other hand, it has been shown that these are
the self-same interfaces that have been a bottleneck for some
methodologies that attempted to use the PLI and C code for the
interface.
Also, these new revolutionary languages are narrow in the sense that
they improve only the verification side of the equation. To get more
productive (faster time to market), we need to improve all aspects of
design. There is a definite need to raise the bar. Yes, improve
verification capabilities. In addition, we should raise the synthesis
capabilities.
Behavioral Synthesis is still in its infancy (relative to the use of
RTL). New language constructs will allow this technology to go much
further. Perhaps SystemC is a good way to go. Perhaps we can leverage
all the existing C++ tools from the software industry.
I think more companies will be interested in an incremental evolutionary
change to their toolset and employee investments. In-house tools that
manage aspects of HDL's won't have to be rewritten.
I for one am in favor of evolutionary changes and the approach Superlog is
taking seems good.
- David C. Black
Qualis Design Austin, TX
---- ---- ---- ---- ---- ---- ----
From: Stefen Boyd <stefen@boyd.com>
John,
While I agree that there are currently more advanced features in Vera and e,
I have seen that the value of these features are offset by two factors.
First, there is the language barrier. This is less significant for
companies that have the luxury of dedicated verification teams who are
trained in these languages. But for companies who have their engineers do
both verification and design, getting those hardware engineers to embrace
a completely new language will be slow and difficult.
Secondly, even if the engineers are pushed into using these new languages,
only a few verification oriented engineers will ever exploit the language.
Here lies the problem. A few (sometimes only one) verification engineers
will create a nifty, complex environment that no one else understands.
Worse, that one engineer who understands the environment is a consultant
and the company is left with a wonderful environment that it can't maintain.
I personally don't want to be called back to support something because it
couldn't be maintained by the client. My idea of repeat business is *new*
work, not maintaining an environment they don't understand.
I've done some elaborate Vera environments, but if only one or two engineers
left the company, they would have no one left who would understand it enough
to enhance or adapt it to a new project.
If it had been a Superlog environment, it may not have had all the object
oriented software feel, but it would have been maintainable by the rest of
the team.
- Stefen Boyd
---- ---- ---- ---- ---- ---- ----
> And what is the big deal with C and C++ anyway? C was designed 30 years
> ago. C++ 20 years ago. They may be the most widely known languages
> today, but they are also the most widely abused, spagetthi coded,
> shoot-yourself-in-the-foot, memory-leaking, obsfucated languages ever
> used. I do not find the "I already know the language" argument
> convincing. What you already know is the *syntax*. You do not know the
> intricacies or process for using it within the context of the
> SystemC/Cynlib/whatever class library. THAT you have to learn and THAT
> is what takes time. Learning the syntax of a new language (such as Vera
> or e) takes only a few hours. You won't require anymore time to learn
> how to use it than how to use that other C++ class library. And what's
> a few hours in a 1-year project?? Especially, if you end up with a more
> efficient environment in the long run?
>
> - Janick Bergeron on loan at
> Qualis Design Corporation Grenoble, France
From: Mark Glasser <mxg@cadence.com>
John,
Well, we're getting into religion here and that's not something that
can be supported or refuted on logical grounds. Language wars have
been going as long as computer languages have existed. Way back
assembly programmers would duke it out with Fortran programmers over
essentially the same issues that we have now: which language has the
"better" compute model and which has the "better" set of features.
Apparently Janick Bergeron has taken sides, which is unfortunate
because it muddies his position as an objective industry
observer. John, you, on the other hand, take pot shots at all the EDA
companies equally and don't appear to favor any one over the other.
It's that (appearance of) unbiased editorial that gives your
newsletter the prestige it commands today.
At the risk of escalating the language wars, here are some bullets
about why we think C++ is the "better" choice for testbenches:
* C++ is a general purpose programming language. You can do anything
with it. You can connect any C/C++ based system to it. That
includes golden models, non-synthesizable behavioral models
(memories, queues, custom functions), testbenches, ISSs, etc.
* C++ is truly object oriented.
* C++ is standardized and is in widespread usage all over the computer
industry. You can easily find C++ programmers and you can easily
find books and classes on C++ and related topics. Further, tools
that generate, manipulate, and instrument C++ are also widely
available from many vendors which is not true for proprietary
languages such as Vera or e or Superlog.
Some drawbacks to C++:
* It's not synthesizable (yet). For testbenches that's not necessary
(yet). However, work is going on in this area in both industrial and
academic settings. I don't know if anyone is working on
synthesizing Vera or e.
* The basics of the language are straightforward to learn and use, but
things can get tricky. A C++ programmer needs to have a good handle
on constructors, destructors, operator overloading, inheritance, and
a number of similar topics that may not be familiar to most hardware
designers. Of course, any language that is truly object oriented
will sport similar features and thus require the same level of
knowledge.
Of course, TestBuilder isn't a language, it's a class library for
building testbenches. It supports a large number of features, too
many to list here. You have to look at the whole package and not just
the underlying language to determine if it's going to solve your
verification problem. While no system is perfect, we believe that
TestBuilder in conjunction with the rest of the Verification Cockpit
does a good job of covering the functional verification problem space.
Some comments on Janick's comments:
* While TestBuilder's current random constraint mechanism is fairly
simple, the upcoming December release will have a more advanced
constraint mechanism that supports constraint expressions with the
operators &&, ==, and !=. An even more sophisticated true
constraint solver is under development for release next year.
* Transaction Explorer (TXE), part of Cadence's Verification Cockpit
(as is TestBuilder) is all about functional coverage. It supports
querying for functional coverage from multiple simulation runs. You
can save query results and read them back for display in the GUI.
Query results can be further combined to form queries of arbitrary
complexity. We are adding a sophisticated merging capability that
will merge query results from separate runs. This additional
capability will also be available next year. I like Janick's
succinct description of the requirements. In one sentence he's
captured the essence of TXE.
* The argument that just because an idea is old it's no good is
getting shopworn. Yes, C/C++ is relatively old compared to other
things but I don't think that has any bearing on the applicability
of the language to the problem. Semiconductors were invented in the
1940s. Does that make them obsolete? Fourier transforms were
invented a couple of centuries ago, but we still use them in
designing communication systems. So what? The really good ideas
withstand the test of time.
* His comment is misleading about how learning the syntax of a
language is trivial. He's correct that the syntax is easy to learn
and the semantics and application are more difficult. What he fails
to point out is that's true for e or Vera as well as C++. Since
most engineers have at least C if not C++ in their backgrounds,
learning the additional semantics of TestBuilder will be as easy as
learning e, if not easier. As I see it there's essentially no
difference in the time or effort it takes to learn e or
TestBuilder/C++.
Janick rambles on about revolution and evolution without making a
relevant point. No doubt, new ways of thinking about electronic
systems will necessitate new ways of thinking about the tools to build
them. That doesn't imply anything about the current tools that are
competing in the market place. If we look at the history of computing
languages and systems we see that non-proprietary ideas are more
stable and have more longevity than proprietary ones.
Go to http://www.testbuilder.net and see for yourself.
- Mark Glasser, Engineering Director
Cadence Design Systems, Inc.
|
|
