Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!sharkey!rjf001!hpftc!teemc!mibte!gamma!thumper!ulysses!dptg!att!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!ginosko!aplcen!mef
From: mef@aplcen.apl.jhu.edu (Marty Fraeman)
Newsgroups: comp.lang.forth
Subject: Re: Cost of Forth Chips
Message-ID: <2709@aplcen.apl.jhu.edu>
Date: 17 Aug 89 21:24:55 GMT
References: <893@mtk.UUCP>
Reply-To: mef@aplcen.apl.jhu.edu (Marty Fraeman)
Distribution: usa
Organization: Johns Hopkins University
Lines: 57

In article <893@mtk.UUCP> marmar@mtk.UUCP (Mark Martino) writes:
>I was reading an article by Brian Case in the August issue of "Microprocessor
>Report".  He brought up two issues that bugged me a little.  ...
>
>This reminded me of a question for which I still do not have an answer.
>Why are the RTX2000 and the SC32 more expensive than RISC chips?  Despite
>the economies of large volume production, I thought that implementing Forth
>in silicon would be relatively cheap since it takes comparatively fewer
>gates than previous architectures. I realize everyone likes to make up their
>R & D costs, but both of these chips had a lot of their design work done
>before their current developers implemented them.
Perhaps John Hayes (sitting here next to me even as I type this) and I 
(two thirds of the engineering team that designed the SC32) can supply 
some technical information about it.  I believe the major factor 
effecting cost is die size.  The SC32 was designed with the Genesil silicon 
compiler and is big (about 10mm on a side) when built on a 2 micron 
fab line.  Even though transistor count is fairly modest (35,000 
for the SC32) you still can't get many chips that size on a wafer.
I think if we redid the SC32 with full custom we'd get the area 
down 25-50%.  Note that a 1 micron version of chip would be about 
5mm on a side so in high volume production it should cost less.

The RTX2000 is a standard cell design and I believe its almost as large
as the SC32.

>
>The second issue has to do with the near future of Forth chips. In the last
>few paragraphs Brian concludes that in order to operate at clock rates greater
>than the current 10-12 MHZ, Forth chips will have to fall back to using
>pipelining as do RISC chips.  He then says that Forth chips will look very
>much like RISC chips anyway.  Will this really be necessary?
>
I tend to agree with this conclusion.  The reason we didn't pipeline the
SC32 was because of the characteristics of Forth.  Frequent access to the
the top few stack locations will cause resource conflicts that need extra
hardware to resolve.  The high frequency of branches in Forth will generate
lots of delay slots that need filling.  At the time we didn't see how to
do a good job of that and even if we did, the volume of application object 
code would greatly increase.  

>Has anyone else seen this article?  What do you think about his
>arguements?
Generally we found the article technically accurate although there
were some minor points that we had problems with.  The last paragraph
of the section "Why Choose a Forth Chip" was pretty good.  I'd quote
it here if I wasn't scared to death of the copyright police -).  
Except for the comment about one person software teams, it nicely 
summarized our goals when we designed the chip.

	Marty Fraeman

	mef@aplcen.apl.jhu.edu
	301-953-5000, x8360

	JHU/Applied Physics Laboratory
	Johns Hopkins Road
	Laurel, Md. 20707