Subject: Re: Suggestion for "implicit variables"
From: Steve Grout (grouts@flash.net)
Date: Wed Aug 29 2001 - 21:19:24 PDT
A couple of points re the current conversation:
Typing:
Strong vs weak typing should really be resolved by following the paradigm
need for real design. Signals (the information/energy that flows through
ports and is carried by nets) really have the 'typing', and we type
ports/nets in anticipation of the characteristics of those signals that
the rest of the system will produce and drive towards those ports/nets.
The typing we allow/impose then should be natural/apropos to the
practice of the designers. As a designer, when I'm zooming along
trying to get a circuit to run, it often is a hassle to first do
all the declaration details, but everything should pretty much work,
and I can put up with some rough edges. But LATER, when I think I'm
all done, THAT's when I should have a way to not have ANY part of my
design description that isn't crystal clear...and even forces me to
find where I described something in a way different from what I
MEANT to.
- So I am a fan of early/easy/implicit, and later fully declared.
As a Verification Engineer (which is a skill/art I've recently become
really quite good at), I shouldn't be spending my time resolving all the 'funny'
characteristics of the circuit, but instead resolving the designer's
architecture, time lines, sequences, observability/controllability,
proper use of the IP/macros/building_blocks, process and mfg
variations, and correct implementation of protocols/standards
the design targets.
Schematics:
> On the issue of "isn't schematic capture dead". Schematic capture of designs is > quite alive and well in the IC market.
> It is used for custom IC design and for high level system design (engineers still like drawings)...
I agree of course with the rest of David's remarks.
But let me make it much more crystal clear.
- As a designer (or as a CAD
guy supporting designers), there is a TIME/PLACE where I HAVE to see
the design/circuit as a schematic: Analog circuits, architecture,
dataflow, petri nets, state machines, big register/pipe/cache/IO, etc.,
its JUST NOT POSSIBLE to grasp the design in words.
- And also a TIME/PLACE where block diagrams are completely in the way:
Take 10,000 control equations for instance...actually take any control that
is not 3-4 terms in a local area, and you have to line it all up, with
my/designer's long clear names, just to keep it all straight. So there
ARE very large HDL text files around, and including when its all hierarchical.
- So BOTH paradigms have to be used for most designs. When you get
to be the Verification guy, if you don't have the schematics you need
to understand the design, you stop and make them. If you don't have
the control part of the schematics in clean, pretty-printed HDL (or auto
GnuEmacs color annotated like Michael and I use), then you stop and
make them.
One final comment:
>... Your suggestion of really tight integration between the schematic system and the > language environment is not a bad one but I do not believe anyone does it !
I haven't had to time to describe to guy's like Michael
what I pulled together doing full-chip
verification at Tality, but, using Michael's GnuEmacs verilog-mode,
with a bunch of additional GnuEmacs defuns and key-stroke macros, I
was able to work from a single full-design Verilog-AMS HDL file, but
where each module/block in the HDL hierarchy was also editable within
a set of schematics and/or companion Verilog-AMS views. I was able
therefore to do a lot of really fast sweep editing, copy/paste,
macro-expand, etc., while still being able to keep the schematic
for the block consistent on a two-way basis.
- I'll be glad to share those macros with anyone who would like.
They also include a fairly full set of services to quickly migrate
HDL designs across SpectreHDL, Verilog-A, and Verilog-AMS.
> Of course, they do not do it in the simulator either so you can argue who should do it.
Maybe we are little closer to doing it at the 'community' level, who
knows.
But we need to get back to the issues about level/use of implicit...
Regards,
-- --Steve Grout CAD Methodologist, Architect, Manager, Individual Contributor - CAD System, Database, Flows, Tools, Integration, and Support for both digital and Analog/Mixed-Signal. 101 Kenneil Court Apex, NC 27502 Phone: 919-303-5066 email: grouts@flash.net http://www.flash.net/~sgrout/Personal/resume2001.txt (or doc,rtf,pdf)
This archive was generated by hypermail 2b28 : Wed Aug 29 2001 - 21:20:34 PDT