Re: MISC-d Digest V99 #107

[fox@xxxxxxxxxxxxxxxxxxx (Jeff Fox)]

Greetings MISC mail list readers:

>>>F21 works at 100MHz because it can't get faster in 0.35 technology

the speed numbers are always a bit confusing, remember that max
mip ratings are for stack access instructions in sequence with all
of the memory bandwidth given to the CPU.  Coprocessors will rob the
CPU of memory cycles and reduce CPU throughput.

MuP21 1.2u process
internal burst 100Mips, SRAM (1k) 100Mips, DRAM (1m) 80Mips

F21 .8u process
internal burst 500Mips, SRAM (16k) 240Mips, DRAM (1m) 120Mips

The F21 prototypes were done with a similar memory interface to
MuP21 except faster and with more SRAM decoded.  Chuck has examined
the SDRAM interface and by going to an 84 pin package this could
be encorporated rather than the interface to the nearly ten year
old 1Mx4-16 DRAM.  There is more buffering on chips with SDRAM
and there are more variations on timing.  The max throughput
in SDRAM would be about 400Mips.

This is based on a 500Mip .8u core.  Chuck has also done projections
for .6, .5, .35, .25, .15, and .1.   .35u only runs at 3V and that limits
the speed so the conservative numbers Chuck gave were 600Mip in .35u.
Although he said an optimistic prediction might be 2 or 3 times that.
In any event his conservative projections are around 1Kmips for the
smaller processes at the moment.  memory access would still be a
bottleneck since we were talking about SDRAM giving 400Mips in .8u
they can be pushed faster with a faster process but cannot keep
up with 1G or 2 or 3G numbers.

>JZ> Mostly because stack machines are less effective for high level languages.

Mostly 'C'.  As Dr. Koopman points out in chapter 7.2 of his book
http://www.cs.cmu.edu/~koopman/stack_computers/sec7_2.html#723 ,
Stack Computers the new Wave, some high level languages compile
very efficiently and others do not.  Forth/LISP/Prolog/etc.  Vs. 'C' type

>JZ> Advanced compilers can reduce this disadvantage significantly, but stack
>JZ> machines are never architecturally better. For hand coded assembly, this is
>JZ> not necessarily true.

It depends on the definition of better.  If you are planning on
executing a library of code "designed" in 'C' then a register based
architecture will be "better".  If you have other plans for the code
and other architectural constraints such as cost, power consumption,
code size, performance/cost, etc. you may have a different defintion
of what makes better or worse.  And of course the assembly on MISC
processors is a flavor of Forth so it gives both the efficiencies of
assembler and Forth.

>Key features needed by this approach:
> - fast and small CPU core(s) for easy scalability.
> - fast interCPU communication system (FIFO, or associative memory).
> - cache for memory access.

>Languages for this system: Forth or functional languages.
>
>What do you think about it?

F21 has SRAM in addition to DRAM and it can be used very much like
cache memory, except managed through software.  You put code that
has to run fast in the SRAM. Of course your description of the SMP 
is very much the idea of F21.

On another topic.  The latest issue of More on Forth Engines
is quite interesting. it is mostly about P8, with complete
schematics, and descriptions of the schematics, how to compile
it, how to compile the eforth for it, etc.  It covers the
design of FPGA P16 MISC chip with the 8 bit bus and how
Ting got it working over the last year.

I have been thinking that since no one else has done it that
I should post an index to all 25 issues of More on Forth
Engines at my site. Outside of my website that is the main source
of information on MISC chips.

Happy 2000,
Jeff Fox