VLSI CAD was Re: Unified Forth

[jfox@xxxxxxxxxxxx]

In article <GOwv2.3416$Ba.3840@newsr1.twcny.rr.com>,
  "John Passaniti" <jpass@rochester.rr.com> wrote:

> That's not the point.  Regardless of if you, I, or anyone else thinks the
> feature set in modern VLSI CAD packages is worthwhile, the point is that
> they have features not found in OKAD, and thus to compare OKAD to the
> *totality* of those larger CAD packages is stupid.

I have been in John Rible's VLSI Design class this semester so I am learning
more about VHDL and Verilog design tools.  There are lots of amazing
features available in these tools that cost hundreds of thousands of
dollars.  I never had chance to play with them before just as many
other people have never had a chance to play with OKAD.

Since I had never worked with those tools myself I could only report what
Chuck said about unneeded features getting in his way and features that
he needed not being there for what he wanted to do.  I am getting a
much better understanding of the conventional tools.  John was saying
last week that the push at the moment is to tie everything together in the
GUI and offer all the version control and project control etc integrated
into the software.  I can certainly see how just the number of features
available requires a large learning curve.

OKAD is to Verilog what Chuck's Forth is to more social programming
languages. You can limit what people can do so that they can be a small
replaceable component in a project and the majority of their work and
many of their tools will relate to coordinating work.  Chuck's
idea of Forth is to get all restrictions out of the way so that one
person can have complete control over hardware or software design.

OKAD does do less than the big expensive tools.  But OKAD also does things
that those tools can't do.  They can provide support to limit the scope
of what people can do so that many people can work on the same design
at the same time.  They provide support to let the software do lots of
things the way everyone else does it.  The user doesn't work with solid state
physics in their software, they work with high level representations
and let the machine make standard and conservative transformations
of the representation.  OKAD does not even provide a schematic representation.
OKAD provides only a geometric representation so there is no automatic
translation from high level language to schematic or from schematic to
layout for a particlar part.  Chuck has been tuning the equations in the
OKAD simulation to get it to accurately model the actual circuits that
are produced by fabrication.  If you are willing to live an order of
magnitude away from the theoretical edge is then you can live with the
SPICE equations because the will work accurately with the very conservative
circuits laid out by the big software.  But the big software cannot
model Chuck's designs.  When pushing closer to the edge he had to use
a different approach to thermal modeling as he explained in his
fireside chat last year.  It is a feature that his chips cannot be
reverse engineered with conventional tools.  That is not because they
have too many features, it is simply because they must limit the scope
of what people can do to more conservative things.

> I am not a VLSI designer.  I did however spend a significant amount of time
> in my last job studying the tools.  Using the VLSI CAD tools I had
> available, I could express designs in VHDL, graphically as a schematic, as
> tabular logic tables, and as state machine diagrams.

They also support a different mindset.  John was saying in class that one
part of his chip could be specified with very little high level code or
with a little more code that detailed some key features.  The smaller code
produced something three times larger and twice as fast.  The larger code
could produce something smaller and slower but that fit on a smaller FPGA.
The reason the more general high level code was faster is that it defaulted
to a more expensive adder with look ahead circuits while the smaller circuit
had only used a simple slower adder.  John said that the reason the circuit
that was three times as large was faster was the better adder.  One of the
students added, "bigger is faster."  When you let the machine make the
design decisions then that is the mindset.

Chuck has said that adding more transistors can't make things faster
because it just adds more gate delays.  I know if you add a bunch more
transistors serially it does get slower and you have to use pipelines
and caches and branch prediction and other very expensive techniques
to regain the lost speed.  Whether he is talking about transistors or
code Chuck would say that what you take out is more important than
what you put in.

> I'm not the first person to note the irony that iTV has VLSI designers using
> VHDL and/or Verilog.  Clearly, even in a business that is predicated on
> Chuck's processor design, his own OKAD tools don't do all the job.  That's
> not an insult, just an observation.

I am sure that many people reading this group are well aware of the
business pressures to satisfy investors expectations.  There are many
buzzwords that are needed to make them happy.  'C', Java, Verilog and
other such things must be shown to some people for credibility.  The
investors and upper level managers may not know anything about the
technical details but they do have certain expectations.  They often
get upset by some Forth let alone everything in Forth.  They usually
want to see something that they recognize to reduce their sense of risk.
According to Chuck the conventional tools have added almost nothing to
the project other than perceived credibility to some investors and
partners.

I have been enjoying learning more about the conventional VLSI design
tools in John's class.  I will able to make more informed observations
after I have done a lot more work.  At this point I would say that I
would enjoy having my own copy of the software to work with but it is
just way too expensive.  I also think that a version of OKAD for an
FPGA target would be a fun and productive tool for me too.

John Rible was saying that many CMOS fabs are now producing FPGA parts because
they are easily characterized and can be made in the volumes to make
the fabs happy.  The result is that parts should continue to get cheaper.
The problem is ... who can afford hundreds of thousands of dollars
for the CAD software except well established companies or very rich
individuals.  I will also have to learn more about what other cheap tools
are available.  But I do like the idea of a simple program like the game
Rocky's Boot with a print FPGA button that could be given away.

I always liked the hands on interactive nature of Forth.  When working
with a real Forth system there is a sense of doing something simple
like playing with blocks.  I find playing with the circuits and simulations
in OKAD very much like that.   In high level CAD or high level programming
languages where one has little control over the compiler there are many
layers of abstraction.

Since all the menus and features in OKAD were documented in More on Forth
Engines Volume 16 along with the transistor models and simulation
equations that Chuck was using at the time other people can experiment
with the OKAD approach if the wish.  I did get permission from Dr. Ting
to publish part of some of his books at my web site and I will post
more OKAD information.

Jeff Fox   Ultra Technology
www.UltraTechnology.com