===== Dr. Hepler on Hombre [he was the one in charge of it]===== I have seen a lot of discussion over the past months on the pros and cons of various RISC processors and the future of the Amiga. Since it was my responsibility to make some of these decisions in the past, and now that Escom has announced their decision, I thought that some of you may find it interesting to hear some of my views as I remember them and get some insight into how decisions like this are made... or at least how I approached things. From what I have seen on the net, many folks out there have no clue as to how things like this are really done :-) Remember that much of this happened well over two years ago... and my memory is not as good as it perhaps should be... Take all of this to be my opinion.... you may disagree with whatever you like... First, you have to put this into context. In order to make a decision like this, one has to have a strategic plan for the future. This plan then drives the decision process. As such I had some ground rules to start with: a. Only one chip set would be developed... We only had enough R&D money for one... so it had to address the low-end (game console, set-top-box) to high end (work-station, A4000 style machine)... The requirements for low-end systems are so different than those of high-end systems that this is quite difficult... b. It had to be capable of supporting Windows-NT sometime in the future. Amiga-DOS would be ported (at least the micro-kernel for game systems, set-top-boxes)... the rest later (for low-end systems).... but it was felt (at the time) that NT would be the emerging OS... and compatibility would be necessary for market acceptance outside of the traditional Amiga market. Having support for a "more main stream" OS would have made getting main stream applications ported to the machine *much* easier. This ground rule meant that we wanted a platform which had some NT porting activity at least started... It also had some implications on the type of memory management needed. No flames please. c. I knew that we could not support a *complete* line of products within Commodore with our resources... But I felt that we could not have a product line which did not have a link of some kind to more powerful machines like those used in business. Most people like to have something at home which is in some way compatible with what they use at work. I wanted to select a platform which gave Hombre users a growth path for the future. We wanted to have a strategic partnership with a company which had a *complementary* product line... and perhaps cross-promote, etc. d. I wanted to be able to include the integer core of the processor on one of the Hombre chips. We also wanted to be able to add a few instructions to aid in graphics setup, etc. e. I was targeting a 0.6 micron, 3-level metal CMOS process. Of course cost was a major concern. I have seen many people on the net discuss RISC chips *without* considering the cost as it applies to the overall system. In order to build a system like the A1200, hit the price point that we wanted, and make a profit, the CPU chip, custom graphics chips, etc, have to cost about $20 (total!!). Many folks forget about all the other costs involved in producing a product. This alone eliminates many of the candidates that some have proposed and cheered for... Our cost objective for the Hombre chip set was a little more liberal than this since I was integrating more onto the chips... but the cost target was not much more!! Certainly not some of the prices I have seen bantered about some of the groups here. Remember, we wanted to be able to put this into a game console or set-top box. You can't spend 1/3 of the retail price of the product on the CPU chip!!! I looked at many (almost all the commercially available) architectures (my favorite from a purely computer architect (my primary training) viewpoint was the MC88100)... and narrowed down to three: MIPS, PowerPC, and PA-RISC. Lew E. and I talked to all the companies involved: MIPS: MIPS was interesting because their parent company is Silicon Graphics. Wouldn't it be nice to have a strategic partnership with the premier high-end graphics company!!! We could have built the low end "home-version" of their machine, made great games, etc. Lew and I talked with one of the founders and he asked lots of questions, etc., but didn't sound too interested... The 4200 series MIPS chips where too expensive and they didn't seem too interested in making any changes for us... The R3000 series was in the right cost area, but was not viable for Windows/NT. As I said above, we felt at that time that it would be important for this chip set to be able to support NT in the future. We dropped them from the list and found out shortly thereafter that SGI/MIPS had signed an agreement with Nintendo for their next generation. It was obvious then that they knew when they had talked to us that they were in discussions with Nintendo... It must have been interesting for them... By the way, at that point, we were 9 months to a year ahead of them... PowerPC: Motorola talked to us about PowerPC (IBM may have come in too, I don't remember)... We had a good working relationship with Motorola as a vendor. I had earlier done a study to integrate AA type functionality onto a die with an MC680x0 core. I had a number of problems with the PowerPC: a. An early version of the instruction set documents (received under NDA) caused me to have a real concern about using this part in our product line. Lew E. agreed. I can't really discuss this any further. b. They were unwilling to do a full-custom version for us (with our graphics enhancements) and their time-table for core-versions was too far out. c. There was no good strategic relationship from a systems point of view. It seemed unreasonable to approach Apple: they were competitors... their line was not complementary. The same was true of IBM, and Motorola did not have a strong systems presence. d. A small, embedded version of PowerPC (the one that we could afford for the low end... (which was being developed for use in automobiles)) did not have a memory management option... something required for both Windows/NT and set-top-boxes. e. The core version that they did promise would have required that we add our logic as standard cells. A standard cell implementation of Hombre would have been far too large - and therefore expensive. We intended to do a custom layout of the datapaths involved and merging these datapaths with their logic was viewed as a problem... f. I felt the instruction set had some problems... for example, the only way to get information between integer registers and floating point registers was through memory! PA-RISC: HP presented the PA-RISC. We had a rather good working relationship with HP. They had fab'd the LISA chips and had done all the foundary work for the AAA project. The PA-RISC: a. It had one of the most powerful RISC instruction sets I had evaluated. It created very dense code (for a RISC) - and the dynamic cycle count was very good. It also had an instruction (SFU) which allowed customization without interfering with compatibility... I had defined some instructions which would aid in the 3D graphics that had been planned for Hombre. b. Other PA-RISC partners had already shown that a low-cost version was feasible. c. HP had a totally complementary product line - their low end workstations were more powerful than our high end Amigas. d. HP seemed interested in the current Amiga chipset for use in a set-top-box and seemed interested in the Hombre chipset for a next generation set-top-box. This made good business sense and allowed us to propose a rather nice agreement... By the way, Commodore died before the agreement could be signed. e. HP was willing to license Commodore to design and build our own version of a core for use in Hombre. I had designed the integer core of the CPU and showed them (HP) simulations of it (to prove our competence). (This was done with only the instruction set reference manual - no proprietary information or design was received from HP.) I'm not sure that the license was really necessary... I had in effect created my own implmentation of a published instruction set... Many others have done this with other instruction sets without a license... but having the license would have been nice and their cooperation would have been useful. f. While the HP chips were not available on the open market, other partners of theirs did have chips that could be put into systems. These other processors would have been used as the external processor on the larger systems I proposed. The architecture that was proposed by me (and approved by Lew) was a two chip set. One chip was a video buffer for the most part... the other chip held the internal cpu, blitter, and other goodies, etc. By the way, the internal datapath was a full 64 bits. There were two bonding options to get a lower costing 32 bit memory interface for game-consoles and set-top boxes, and a slightly more expensive 64 bit option for higher ended systems (VLSI packaging costs can be significant for large pin counts). The wider memory was not really necessary for the very low end systems which only had to produce NTSC or PAL level video, and was less expensive... Low end products used the internal processor as *the* processor. Higher end systems used the internal processor as a peripheral/graphics processor. While it made a lot of sense to have the external processor be a PA-RISC processor, there was nothing that required it. The architecture also made use of the PCI bus. Again, on low end systems, the PCI held peripherals for use by the internal processor. For higher end systems this was also true. But the PCI bus could also be turned around... this allowed the chip set to be used *as a peripheral* to any PCI based system. This was intended to allow this chip set to be used as a peripheral to PCs. Also, this was the "link" to the HP workstations. It was hoped that this chip set could be configured onto a PCI card for incorporation into HP workstations... This would allow software which ran on our systems run on HP workstations... I had written a simulation of the CPU, enhanced blitter/renderer, and memory interface in C to test instruction sequences and rendering performance. (The simulation even had a Tcl/Tk GUI!). I had also modelled many of the blocks in M (a behavioral simulation/synthesis language - similar in function to VHDL or Verilog). Some of the datapath had started transistor level design... Then things fell apart and the couple of people I had just gotten assigned to work on this either quit to take other jobs or were laid-off... Remember before you flame me... Most of this happened over two years ago. Had we remained solvent, gotten the resources that had been promised and remained on our original schedule, we would have had first silicon at the beginning of 1995! I believe that given the strategy, ground rules, information at the time, etc., I made the correct decision. I don't know what strategy Escom has, what their ground rules were or how they made their decision, so I can't comment on their selection... I hope this insight has been interesting and educational.... :-) Again, all of the above is my opinion... not to be taken as the policy or beliefs of my employers, etc. Dr. Edward L. Hepler Former: President, Director of VLSI and System Architecture VLSI Concepts, Inc. Architect of Hombre, Designer of Andrea (AAA) VLSI Architecture, Commodore Design, CAD Adjuct Prof. ECE Department, Villanova University ECE-8445 Graduate level Advanced Computer Architecture ECE-8460 Graduate level Introduction to VLSI Design elh@ece.vill.edu END ---