home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The AGA Experience 2
/
agavol2.iso
/
software
/
diskmags
/
miggybytes
/
docs
/
mb_7.txt
< prev
next >
Wrap
Text File
|
1996-02-14
|
12KB
|
237 lines
===== 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
---