( ESNUG 362 Item 8 ) --------------------------------------------- [11/30/00]
From: "Janick Bergeron" <janick@qualis.com>
Subject: Janick Pisses On Superlog; Supports Vera And Verity's "E" Instead
> So what may be its key selling point is that the Superlog revolution isn't
> revolutionary at all. Unlike Vera or C/C++ HW design, using Superlog
> doesn't mean you have to start over by throwing away all your old legacy
> Verilog code. "The beauty of Superlog as I see it is that it is an
> evolutionary path from Verilog," concluded Anders. "I can start out with
> 100 percent Verilog and then add as much Superlog as I want. Superlog has
> some very useful constructs such as structures, queues, re-entrant tasks,
> protocol checkers and pointers which are lacking in Verilog."
>
> - from John Cooley's "The Superlog evolution" column in EE Times
[ Editor's Note: Janick Bergeron, a man who I greatly respect, moderates
the "Verification Guild" newsletter. (OK, so we disagree!) - John ]
From: Janick Bergeron <janick@qualis.com>
Hi, John,
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.
Where's the constrainable random generation? And I do not mean trivial
random generation as in Verilog's $random task, nor TestBuilder's trivial
constraint mechanism. I mean a REAL constraint solver, with sets of boolean
equations that describe relationships between randomly generated fields and
values. And adding constrains should ideally be done WITHOUT modifying code
that is known to work.
Where's the functional coverage? And I do not mean simple dynamic processes
that append to files. I mean a REAL statistics/distribution collection
engine with incremental data collection, cross-analysis, goal definition
with user-friendly reporting. In the SystemSim datasheet, there is no
mention of code coverage capability. I hope this is because, in 2000,
this now goes without saying...
Where's the object-orientation? And I do not mean simply hierarchically
accessing tasks and functions in a module instance. I mean REAL
inheritance, variant structures, virtual members, and polymorphism. There
was more to Java to borrow than the "byte" pre-defined type.
I'm curious about the "protocol checking" bit. Does it mean there is a
temporal language extension?? That would be cool. If it is more procedural
checking mechanisms (like FSMs), excuse me while I yawn.
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?
Evolution is an acceptable business strategy. It minimizes discomfort,
allows incremental adoption of new technology and reduces training cost
and initial inefficiencies. Superlog fullfils that need and has a viable
future. However, you should not plan on an evolutionary plan in the long
term: evolution has been known to reach dead-ends. We are in the
Jurassic era of electronic design. I want to bet on the flyers who will
eventually transform into birds, not the current top-of-the-food-chain
Tyranosaur. Actually, I would rather be smart enough to be able to
identify the pond scum that will become homo sapien - and make a killing
in the ensuing IPO.
Revolutions are NECESSARY. Show me the companies that, today, are using
an evolution of the schematic capture methodology prevalent in the late 80's
and early 90's. Those who survive today embraced the logic synthesis
revolution.
There is one VERY BIG problem with revolutions: they are disruptive.
What you knew no longer applies. You have to learn new ways of thinking.
You have to change to way you do things. You have to accept initial
inefficiencies for the promises of future gains. That's not easy to
overcome. Politicians play on and use these feelings all the time with
their talk of "the good old days" and "traditional values" and "national
identity". Change, especially revolutionay change is painful. Introducing
logic synthesis into the design process was a traumatic experience for the
older, experienced schematic-based designers. Fortunately, there are
companies who can help with the transition through training and support
services.
Time will tell which solution will survive: technical merit alone is not
sufficient to guarantee success. I, for one, hope for the revolutionary
one.
- Janick Bergeron on loan at
Qualis Design Corporation Grenoble, France
|
|
