( ESNUG 261 Item 5 ) -------------------------------------------- [5/22/97]
Subject: (ESNUG 260 #1) Protocol Compiler (Dali), BC & ATM Interface Design
> Dali is an environment for ASIC designers to create designs with complex
> interfaces and structured data streams. The increasing complexity of
> protocols have made existing design methodologies difficult and cumbersome.
> Debugging an initial design to meet performance requirements, and later
> re-engineering the design to accommodate modifications in protocol
> specifications or other changes, is time-consuming if not difficult. Dali
> was developed in response to these and other challenges.
From: dchapman@goldmountain.com (Dave Chapman)
Dear John,
I don't know quite what to say about this one. On the one hand, it is
clearly useful to SOMEONE to have done this work, and the tool seems to be
very powerful, but. . .
There seems to be an attitude of "isn't this cool", which does not pay
enough attention to the hardware/software tradeoff implied by putting so
much functionality into silicon. I figure that this is particular part is
going to wind up looking like Yamaha's ISDN chip which has Layer 2 (LAPD)
built in. On the one hand, it is an astonishing achievment, but on the
other hand, everybody turns off the Layer 2 features. Why? Because it
doesn't quite do what we want it to do and there is no way to fix, change,
or add to it.
This ATM this looks like the first in a long series of highly
sophisticated, unflexible, hard-to-use, and generally crappy "systems on
silicon". A tool which encourages people to built such things is NOT a
technology advance.
The single most important decision in modern system design is which
functions to put in software versus silicon. Because this tool biases that
decision towards silicon, I predict that there will be a few crash-and-burn
scenarios in the near future.
I'm not pessimistic, just experienced.
- Dave Chapman
Goldmoutain
---- ---- ---- ---- ---- ---- ----
From: rramsay1@ford.com (Rodney Ramsay)
John,
In case you didn't already notice, ProtocolCompiler documentation is
also included in the 1997.01 CD for Synopsys Online Documentation. :-o
- Rod Ramsay
Ford Microelectronics Inc.
---- ---- ---- ---- ---- ---- ----
From: Randy Bolling <randy@vela.com>
John,
I can't help but reduce the problem of a "protocol" compiler to a BNF
description of the stream you wish to parse and applications / ramifications
upon parsing that stream. Ever written a tool or two using lex and yacc?
I know this application varies greatly, but the complexity of the parsing
does not. What at first appears to be ground-breaking is really the next
logical step. Not that I am taking away from this step. It is a
SIGNIFIGANTLY important step in the advancement of an often lacking field
of EDA tools. This is one step towards realizing small-team million gate
designs. It's also a transformation of an existing set of problems already
solved in the world; just not applied to EDA tools until recently.
I wonder if it has rules preventing it from suffering from the left vs.
right recursion problem. Need to look closer...
Language =
{ Terminals (terminal),
Non-Terminals (reference & sequential & alternative frames),
StartSymbol (pinout),
Productions (optional & repeat frames, qualifiers and if's) }
I can immagine Salvador would have named the tool "De Geus" or maybe just
"Domenech".
- Randy Bolling
Vela Research
|
|
