Re: MISC-d Digest V99 #68

[theFox@xxxxxxxxxxxxxxxxxxx (Jeff Fox)]

Dear MISC reader:

>>If you need more documentation to get started you might want older
>>things that have had more time to be documented.
>
>The point was that the documentation should come *first* --
>professional design requires a product specification, and the spec
>req's that the product's features, behavior, and physical +
>functional characteristics be fully defined -- *beforehand*.

Yes of course.  However not all people seem to be able to read
techncial specifications.  For instance I have published everything
in several formats.  Chuck's original specs are complete, but are
difficult to read unless you read it several times and study it
to see how much is said in so few words.  Just translating it to
standard type technical documents makes it ten times bigger.  Still
many people don't seem to be able to read these either and seem
to need something 10x bigger yet on the order of the Norton's
Guide to F21 or F21 for dummies.

>This is never a perfect process, and certainly iterative revisions
>occur, but at least it provides a clear target, and permits several
>people to work in parallel, both during the product-definition
>brainstorming, and the dog-work of implementation -- for instance
>test software can be written, and an evaluation PCB designed, even
>before the silicon layout is finished...

Of course.  That is why I published the specifications and a complete
set of tools years ago.  You could study the specs, write code, debug
it on the simulators and emulators, make ROMs, drop them onto real
chips and watch them run.  They never provided such nice tools at
Patriot. All the information needed to lay out F21 boards has been 
published for several years.  

>>If you want to be out in front then hopefully
>>you will write some documentation for those
>>who may also want to move to more modern designs.
>
>Good idea!  But this requires being invited onto the team during the
>earliest conceptual phase, and a continous, fully-informed
>involvement during the development process -- no-one enjoys writing
>doc'n that is simply wrong, and has to be scrapped.  Worse yet,
>customer faith is shattered if the product fails to live up to it's
>published design info.

For almost ten years I have done all I could to invite other people
to join the team.  I have published most of what has been published
and I have answered people's phone and email questions for years.
I published almost all the information for years so that anyone who
could read could be fully-informed and involved in the development
process.  Of course since I had to design the chip, write simulators,
simulate variations on the design, write 30 compilers, compare the
code, write assemblers and cross development tools, write several
megabytes of web documentation, develop applications, design boards,
test chips, answer a megabyte of email each month for years, and 
in the spare time earn a few hundred thousand dollars to pay for
chip development.  Most of the mail is people suggesting other things
for me to do such as rewriting the documentation into a different format.

>>I know one of the designers claims that
>>in order to make ShBoom II more attractive to Java and "C"
>programmers
>>that some of the operations that are important to Forth were
>degraded.
>>In a  way it is a little like what was done to Forth in ANS Forth.
>
>Maybe so, but I can't see it;  it seems a very well thought-out
>compromise to me.

I was John Rible's lab assistant in his UCSC extension class on
CPU design and am in the current session at the SVFig meetings.
I have sat in on many many discussions between John and Chuck
about design tradeoffs and heard John talk about the changes
that he was making to ShBoom in his consulting work for Patriot.
You haven't worked on the design for years like John.  I think the
changes are nice, don't get me wrong.  They are nice overall because
they seem to make the chip more attractive to 'C' and Java 
compilers.  That is a nice compromise if you plan to write code in
'C' or Java and don't really care about Forth.  Extra machine
cycles have been added to many important Forth functions to make
the other languages happy.  John says it is now "brain damaged"
but that is just the Forth point of view. I know few people care
about the Forth code.

I think it is a nice chip, but I think you can make one about as
good on FPGA yourself and add the I/O circuitry that you really 
want if you really want to go that route.  But I guess that 
most people will never consider that.

Jeff