home .. forth .. misc mail list archive ..

Re: never enough


On Wed, 01 Nov 2000, Jeff Fox wrote:
> Hi MISC readers,
> 
> Wayne Morellini wrote:
> 
> > Well I have to hand it to Dr Ting he is comming through, good on him! I
> > actualy suggested to Chuck that a 24-bit design was better than a 20-bit
> > design in 1988.
> 
> Well the reason for our doing 20 bit vs 24 or 32 bit was the number of
> pins
> as I have said many times.  Adding an extra pin would have cost me
> an extra $40,000 or $50,000.  It is easy to say that a 24 bit chip
> would be a better choice than a 20 bit chip but it only makes sense
> if you assume that an extra $40,000 doesn't matter.  Maybe you have
> a few hundred thousand extra disposable dollars sitting around, I
> didn't. 

I know this very well with my own chip design, which is running in the hundreds
of pins.  I'm using FPGA for prototyping, but tooling up for production will be
a big expense.

> 
> But we have heard many times that 32 bit chips are fashionable and
> that no one except a few DSP designs use 20 or 24 bits.  But these
> folks often miss the fact that we are not Intel, DEC, TI, or Motorola.
> If you work on that scale then let me know if you need someone to 
> work for you.

Hehe, if I were funded I'd hire you in a heartbeat.  I love your work.  Got a
resume' I could look at?

>  
> > Using programmable silicon designs that could be converted
> > to mass production in 1996, and a cheap 160*160 screened PDA, with low end
> > and powered processor, with simple Organiser functions would actually work
> > (when they said it wouldn't) around 94-96.  Three good ideas in 12 years is
> > ok.
>  
> I still consider going to FPGA a step backwards.  Chuck decided to go
> from PGA to custom silicon in 1989 to get an order of magnitude or
> two speedup and two orders of magnitude improvement in production
> cost.  This is a 1000/1 or 10,000/1 ratio in price performance.
> It is a very big hit to take.  The only justification that I can
> see would be not having enough money for custom which is more
> expensive.  But the 1,000/1 or 10,000/1 ratio is hard to ignore.

Agreed 100%.  It's hard to convince people that a 400Mhz FPGA is equivelewnt to
maybe a 14Mhz chip.  The timing is all off.

> 
> Ting is working with a company that can afford million gate
> $10,000 FPGA for experiments but they make you realize the real 
> value of being able to do production for under $1 as well as
> being able to run ten times faster. This is still a long ways 
> away from the billion gate designs that you suggest.

Indeed.  This has been a crux of many arguements I've had with several people
over the years, that implimenting my design in FPGA for production is
impractical, since I'd need a $1800 Altera FPGA to just meet the minimum gate
count.

> 
> > But I have oftened toyed with the idea of hooking a 32 bit misc up to one of
> > the portable Graphic/3D processor with on chip memory (upto 32 MB on chip
> > now, I think).  Would certainly give enough memory for the program and the
> > graphics.  How possible would this be?
>  
> It is completely possible, but not with programmable hardware as far as
> I can see.  A memory bit requres 1+ transistor for DRAM and 4 to 6 for
> SRAM.  32MB is 256 mega bits, and that could be 1.5 billion transistors!
> There are no FPGA with 1.5 billion gates.   If a million gate FPGA costs
> $10K would a billion gate FPGA cost $10M?

I've already implimented this kind of solution in my Eddas design, a hybred
MISC/RISC chip (stack-based but with registers for storage) paired with a DSP,
FPU (not IEEE complient by a long shot), video pipe, audio system and I/O
controls, for a low-cost production unit.

> 
> It would be possible for custom.  Costs are generally speaking
> proportional 
> to transistor count although since you are talking about up to 1.5
> billion 
> transistors in a somewhat regular grid the development cost would be
> somewhat
> lower.  But then again those memory designs ususally require more exotic
> fab
> processors such a vertical transistors.  Prototype fabs don't usually
> offer
> that stuff so you might have to purchase your own fab, not a big expense
> for you.  As a rule of thumb $5 per transistor, so it is entirely
> possible as long as you have about 8 billion dollars in your
> budget.  That would put you on a scale with Intel, DEC and
> others who spend that kind of money on developing the biggest
> designs around.  I guess you have deeper pockets than I realized.
> I thought $100,000 was a lot of money and that $1,000,000 would
> be in another league but $8,000,000,000.00 is really in
> another ball park all together.
>  
> To tell the truth, if I had 8 billion to invest it would be a
> quite different picture.  I might not even bother with silicon
> if I had that kind of development funds to manage. I would be
> inclined to leapfrog to a pure optical 3D packaging design
> to make things 1M times faster and put 1K more nodes in the
> same space.
>  
> But even with silicon I think there is still the ratio of the
> number of transistors in the processor to the number of transistors
> in memory.  Now you are talkinga about a CPU and a 3D processor
> to be mated to lots of memory.  When you start talking about 32MB
> of memory you are talking about enough silicon that a fairly large
> CPU is normally justified.
>  
> The idea of the F21 design is to get a few hundred mips per megaword
> of memory or per 32K words or memory depending on the configuration
> of nodes.  So for 32MB of memory you might get a few hundred billion 
> instructions per second.  To attach that much memory to one CPU looks 
> like a bottleneck from our standpoint but if all you want is to 
> control a 3D chip...

Agreed 100%.  I should show my design solution, people might be impressed with
how you can avoid bottlenecks in Eddas.(my design's name)

>  
> We are currently (in one project) looking at reducing the design by
> making I/O register based (no mems) and integrating a small amount
> of memory on chip and multiple nodes connected together on a chip.
> With wafer scale integration it looks like the upper limit is
> somewhere around 15 million Forth mips from a "chip" in production
> silicon today.  Of course I personally don't have the money to
> do the design so "feasability" depends entirely on finding
> the money like most other things.

I got more than that.

>  
> > I actually was meaning to send you some names of new video compression stuff
> > so that you could put the lot on one DVD, or send it over the net.
>  
> People have suggest that I need a new camcorder as my old one has worn
> out from making tapes and copies.  People have suggested that I need to
> buy newer and better compression equipment.  People have suggest that
> I need to upgrade my website and pay ten times as much for a site
> that can hold gigabytes and provide more streaming video bandwidth
> for users.  These are all nice ideas.  But who is paying for it?
>  
> > I have
> > heard of a few groups offering upto around 1000:1 compression ration (one
> > video over a 33.6 kb/s modem with sound, then the Israelies announced they
> > had been secretly using a 600:1 military method for years).  The only one I
> > can remember is Adam's Platform in Australia.  Wavelets (being brought into
> > jpeg/mpeg standards) and Mpeg 4 (DVD onto a CD-R) are available and not too
> > far beind in the compression rate.
>  
> I did a lot of studying of compression techniques in college but things
> were still primitive in the sixties. ;-)  One of the teams interested in
> the
> MISC multiprocessors are interested in compression/decompression and
> have the best software out there at the moment.

DSP is better for this I've found, but a MISC CPU alongside of a DSP allows
both to make up for the shortcomings of the other I've found.

>  
> As for consumer grade stuff, yes I could use a new computer, a DVD-
> writer, new video equipment, new digitizing equipment, as well
> as a working car and money to pay for rent and food.  I'll do what
> I can but I am operating on a very restricted budget.
>  
> Jeff Fox

Nate Downes
member Phoenix Platform Consortium.