( ESNUG 335 Item 9 ) ---------------------------------------------- [11/3/99]
Subject: ( ESNUG 334 #8 ) Ten More Letters Doubting C-Based HW Design
> I still think it's a dumb idea... I was in a conference call yesterday
> with the folks from Synopsys talking about this "SystemC" stuff. Some
> parts I like, but others are just too much trouble -- you'd might as well
> just learn VHDL or Verilog (so my theory is confirmed, once again :).
>
> - John Reynolds
> Intel
From: GRIFFIN@slxcg01.csw.L-3com.com
If I use C/C++ to design my ASIC how do I simulate it with the same
capability I get in a Modelsim where I can trace signals, etc?
- Griffin
L-3 Communications
---- ---- ---- ---- ---- ---- ----
From: [ Been There, Done That ]
Hi John -
I have to concur with your comments on C++ as a next generation HDL. I 've
talked with several of these EDA vendors that you mentioned regarding
C->HDL->gates flow. And each time I've come to the same conclusion: "the
emperor has no clothes!"
What I really wanted to tell you about though was that I and many colleagues
were doing C-based synthesis at Bell Labs in the late 80's. The product as
an internaly developed tool called "cones" and was developed by Bell Labs
folks in Murray Hill, NJ. Cones was quite a capable tool, in fact the
project I was on produced 5 ASICs in the then state of the art 0.9 u process
using the tool. There were other versions of the tools as well that were
used to produce many ASICs (Spruce was another similar version). There was
a simulator too (named ATTSIM), that could perform co-simulation with Cones
(restricted) C, true C, and Verilog/VHDL. Bells Labs tried for several
years to market these products, and eventually sold most of its assets in
this area to Cadence in 1997 (Cadence bought Bell Labs Design Automation
group you may recall). I've heard similar stories from folks at IBM, but
apparently IBM internaly is still supporting the internally developed tools.
So basically, the EDA vendors are going full circle because they don't have
anything new to sell with the traditional tools. Wouldn't it be nice if
someone had the source code for a product like "cones" that could get it
into the hands of a group like the MIT GNU folks. With that scenario C
would stand a better chance.
Please keep me anonymous.
- [ Been There, Done That ]
---- ---- ---- ---- ---- ---- ----
From: Nick Okasinski <nicko@mti.mti.sgi.com>
Hi, John,
I shook my head in disbelief when I first read of the recent push to
make C++ the basis for high-level synthesis tools. C++ is totally
unsuitable to this.
As a software developer who has designed commercial HDLs (remember the
SILOS Behavioral Language? I thought not. It was Verilog roadkill a few
months after it was released in the mid 80's) I think I have a unique
perspective on this.
C++ is a cumbersome, complicated language with myriad subtle pitfalls.
The language does so little to protect people from writing patently
invalid programs that I can't image it's going to help people stay
within the "synthesizable subset". Large-scale structure is difficult
to express and can be casually circumvented.
I haven't been following the current debate closely, so I can't speak to
how the goals of the C++ camp might be better achieved.
But I can say this much: I would implore the hardware community to
learn from the experiences of the software community. C++ is
ubitquitous, but it's also clearly late in its lifecycle. Superior
languages have not only emerged, they're already in mainstream use.
If you're a Verilog type who wants to sketch some ideas and watch them
run, you'll be estatic about an HDL based on Python. If VHDL is your
style, you'll feel right at home with the iron-clad interfaces and
abstractions of Java.
There's much to be said for basing an HDL on an existing, popular
language. I learned that the hard way when my languge got trounced in
the market by the very C-like Verilog.
Designing a 100M transistor chip will be complicated enough. We can't
afford to have tools that are unnecessarily complicated, or that don't
adequate support and enforce the designers intent.
- Nick Okasinski, CAD Software Designer
SGI High Performance Microprocessor Group
---- ---- ---- ---- ---- ---- ----
From: "Duncan Walker" <walker@cs.tamu.edu>
I think you do a disservice to academia when you mention corporate CAD
groups, but fail to mention the probably much larger body of work on IC
design using programming languages done in universities. The most obvious
examples would be the chip designs done in Scheme at MIT and Simula at
Caltech (where I was) in the late 1970s and early 1980s, as part of their
general work on "chip compilers". There were many specialized layout
languages developed. I wrote one called GAP in C at CMU, using concepts
from another language GAP developed by Gary Tarolli at Digital. Based on
that experience I even wrote an internal CMU memo titled "IC Design is NOT
Like Programming", essentially arguing that for many things schematic
capture is better, a layout editor is better for cell design, etc. There
were a number of commercial products in the early 1980s, such as the FLEX
cell system, among the earliest of module generators; Silicon Compilers,
Caltech spinoff, etc. In my opinion they died mostly because they were
before their time, and their inefficiency was not affordable given silicon
costs of the day.
My belief is that trying to embed everything in one language is just partof
the eternal quest for the silver bullet. Fred Brooks wrote an IEEE Computer
article on silver bullets (with a cool werewolf picture) many years ago.
One obvious issue that is not mentioned is that the software and hardware
developers are rarely the same person. We don't expect the circuit and
layout designers to use the same tools. What is needed are tools
appropriate to each problem domain, but which enable integration, co-design,
co-simulation, co-verification, etc. One language for everything is another
way of saying lowest common denominator.
- Duncan M. (Hank) Walker
Texas A&M University College Station, TX
---- ---- ---- ---- ---- ---- ----
From: Mark Natale <mnatale@ati.com>
Hey John,
What is up with Petri Nets for such design? I thought they were supposed
to be the way to future design languages and the Holy Grail of formal
design.
- Mark Natale
ATI
---- ---- ---- ---- ---- ---- ----
From: "Scott Sandler" <scott@novas.com>
Hi John,
Regarding your comments in the recent Industry Gadfly, going "back to the
future" might not be such a bad thing if it means free simulators for
everyone! Even if you can't do anything with C or C++ that you can't do
with Verilog or VHDL, wouldn't having simulation capacity limited only by
the number of workstations be a benefit?
Of course, as an EDA vendor I like the idea that budget might be freed up
for tools other than simulation...
- Scott Sandler, Marketdroid
Novas Software
---- ---- ---- ---- ---- ---- ----
From: Lois DuBois <ldubois@batnet.com>
John,
Here's another alternative.
Sunnyvale, Calif. USA; Meylan, FRANCE & Malmo, SWEDEN -- October 18, 1999
Arexsys S.A., the leader in architecture exploration systems, and
Telelogic AB (Stockholm Stock Exchange:TLOG), the leading supplier of
visual tools for system design and test, as well as software development,
today announced the development of an SDL to VHDL interface that enables
electronic system designers to use Arexsys' ArchiMate to perform
architecture exploration of system designs developed with the Telelogic
Tau toolset.
SDL, is the International Telecommunication Union's specification and
description language. It's a formal graphical notation that is expected to
be integrated into the system-level design language (SLDL) which the
electronics industry is currently developing.
- Lois DuBois, PR droid
Cayenne Communication Portola Valley, CA
---- ---- ---- ---- ---- ---- ----
From: [ Life Under The Big Top ]
I have seen one project that did a decent job of the C to logic conversion.
The process was to:
1 compile to remove global variables,
2 convert all code from procedural to functional form
3 perform a laziness scan and infer laziness where it'll help
4 convert functional elements to a data-driven model
5 compact and infer equivalent and/or shared elements
6 map the data flow into computational elements
1,2,3 came out of functional language research as I remember. 4 was the
first half of an optimized functional language compiler. 5 was a student
hack and essentially a creative use of diff! 6 existing and not very good
EDA component.
In a general sense, the difficulty with the system wasn't the conversion
or even the efficiency of the result. When you parallelize the design
after stage 4 above, you essentially have lots of little independent
execution engines. You can either keep them separate and use a huge
amount of silicon to achieve blindingly fast parallel performance,
or you can start to mux data into a shared data engine and demux the output.
This saves most of a data engine's space, but there is going to be an
execution speed penalty unless you can prove low engine utilization.
Evaluating the data engine's utilization is essentially the halting problem.
For a project that implements a repetitive task, the problem is solvable
in an automated way, simply by running the code and making timing notes.
In this way, it did a spectacular job of filters, FFTs, viterbi etc.
Something that was more free-form (such as a parser) made for ugly logic.
The problem with it was when you didn't like the output. There were
so many intermediate languages along the way that it was almost a
research topic in its own right to be able to review what was happening.
- [ Life Under The Big Top ]
---- ---- ---- ---- ---- ---- ----
From: Anna Ekstrandh <annae@extremepacket.com>
John,
A comment on your latest Gadfly:
You are mentioned a future Verilog++. Well, isn't that what the guys at
Co-Design are thinking about with their Superlog language? It's a definite
HW development language, but with some of the features out of C/C++.
I don't have any experince personally with the language. But I've listened
to the sales pitches of all the companies mentioned in your article as well
as from Co-Design. Co-Design seems to have thought a little bit more
closely about HW design issues, such as synthesis, etc. Right now you
can synthesize Superlog only through a translation into Verilog, and I have
no idea how that would work quality wise.
- Anna Ekstrandh
Extreme Packet Devices Inc. Ottawa, Canada
|
|
