Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!uunet!portal!cup.portal.com!bcase From: bcase@cup.portal.com (Brian bcase Case) Newsgroups: comp.lang.forth Subject: Re: Cost of Forth Chips Message-ID: <21351@cup.portal.com> Date: 16 Aug 89 19:51:06 GMT References: <893@mtk.UUCP> Distribution: usa Organization: The Portal System (TM) Lines: 80 >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. I was >wondering what the rest of you think about his ideas. Hi. I am the author of that aritcle. I will add some comments in my reply here, but feel free to send me mail if you have short, direct questions. Maybe I can learn something too. >After a fairly even-handed comparison of Forth chips versus RISC chips >(with a slight bias towards non-Forth languages), he asserts that >using a Forth based system will end up being about as expensive as a RISC base d > system. I found it hard to disagree with him, even though I would like to >use Forth and Forth chips. The system cost is highly variable. My comment was based on the cost of CPU chip and SRAMS to make it run. A RISC might require more stuff after that, but so might a FORTH chip. If you are going to use a lot of CPU chips, you might be surprised how much lower the prices for RISCs can go. On the other hand, if you are going to use a lot FORTH chips, you might be able to arrange a really good deal with an independent foundary too. Also, some RISCs are VERY expensive: 88K, i860, e.g. Some are cheap: 29K, i960, and some SPARC implementations. >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. I don't know the true answer to this question (why are FORTH chips as expensive as RISC chips), but I can make some very educated guesses. First, there's volume. Second, a large part of the cost can be in the package, which is the same for almost everyone (the Japanese might have an advantage here). Third, the number of gates in the *processor* of a FORTH chip is small, but the implementations in the RTX and SC32 have some on-chip RAM. Thus, the die sizes are not all that small. Forth, the RISCs are often implemented in 1.2 micro and smaller technology, which the FORTH chips are forced to use available independent technology, which is typically 2 micro. This is another reason die sizes are not that small. Chip cost = Package + die cost + profit_margin. >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? When I started writing the article in the uP Report, I began by reading the data sheets, skimpy as they were. I was appalled when I added the clock-to-address stable and data setup times together: At 10 MHz, there were 18, yes eightteen, nanoseconds left for RAM access. That means, if you design a system to spec, you need 18 ns RAMs to use the particular chip that that data sheet described (I now forget which it was, probably the SC32). I called Silicon Composers to make sure I wasn't making a mistake; they said, "Oh, yeah, we never noticed that. You are right, but the chips we get are much better than that." Why is such fast RAM required? Because of the chip design: they are probably using generic pad drivers and the clock-to-address-out path includes a lot of on-chip logic. RISCs use custom-designed (optimized) pad drivers to minimize the time to drive signals off-chip, and they use pipelining to take the on-chip logic out of the critical path. The upshot is that at 20 MHz, even with great pad drivers, you might need -10 ns SRAMS for the FORTH chips. The solution? Pipelining. But with pipelining, you can't do single-cycle instruction execution without introducing warts. Without single-cycle instruction execution, the advantages of the FORTH chips are diminished. In short, until the entire memory system can be on-chip (that's coming, but don't hold your breath), the FORTH chips will be second-class citizens in raw performance. However, for the byte counters and cycle counters among you, a FORTH chip can be a good choice: it is easy to say how many bytes and how many cycles something will take (although compiled FORTH makes this harder). If you want the best performance, you need pipelining, caches, registers, and three-address operations. etc. etc. etc. Enough for now. I'll try to answer more questions about my reasoning.