[LMH]FPGA / microcode

Robert Swindells rjs@fdy2.demon.co.uk
Fri Mar 5 11:00:01 2004


Eric Blossom wrote:
>> On 4 Mar 2004, at 18:57, Dan Moniz wrote:
>> >On Thursday, March 04, 2004 7:01 PM +0000 Robert Swindells 
>> ><rjs@fdy2.demon.co.uk> wrote:
>> >>I was only half joking about translating it to VHDL.
>> >>[...]
>> >>The whole CPU would fit into a $15 FPGA using current technology, add
>> >>a couple of 16bit SDRAMs and some boot flash and you have a 10x faster
>> >>microExplorer.
>> >
>> >[...]
>> >Of course, there's the longer term problem of getting a monitor and 
>> >input devices to talk to it, which would be painful, and disks, file 
>> >systems, a running install, oh my!
>> >Probably, now that I think about it, an FPGA-based Explorer processor 
>> >on a PCI card, with some interface glue would be the way to go.

>I've considered the FPGA idea myself a few times.  It would be fun ;-)

>One thing to remember, is that by today's standards, the Explorer's
>have dinky address spaces.  24MW if I recall correctly.  I think that
>a blind re-implementation of the architecture would be a waste of
>time.  Why spend all the time and end up with something with a dinky
>address space?

The attraction of a LispM over a Lisp system on stock hardware is
the integrated environment.

It is a lot easier to migrate to a larger address space when you
have a running system.

>Another thing to consider is the basic "back of the envelope
>calculation".   For the sake of argument, assume that you're using a
>Spartan 2E or Spartan 3 (The spartan 3 has bunches of embedded
>multipliers.  You could really speed up your bignum multiplies with
>them ;-)).  Using the lower speed grades (much cheaper!) you can
>probably run them at about 125 MHz (hands waving wildly...).  This
>gives you a 125 MHz microinstruction cycle.  Of course, you're free to
>build your memory subsystem as wide as you like, so make it 40-bits or
>48-bits or 64-bits...

The Spartan 3s are cheap in any speed grade. They are in rather short
supply at the moment though.

>Now, on the other hand, you're competing against 3 GHz Pentiums or
>AMD64s or Opterons running at 2.6GHz or so.  All of these have an
>incredible amount of internal parallelism.  You can easily get 4 or 5
>operations going per cycle (this includes address generator
>updates, ALU ops, floating point adds, mults, loads, etc).  Without
>working hard, this gives you an easy 6M ops/second.  It's going
>to be really hard to get your 125 MHz FPGA implementation to even
>begin to keep up with these monsters.

I'm not suggesting that a FPGA LispM will compete with a native lisp
running on the fastest desktop or server CPUs.

The fast CPUs require a lot of cooling and won't run for long on
batteries.

Think instead of competing with PDA class CPUs, these are 400-500 MHz
in-order RISC processors that use ~500mW.

I think you are going to see a lot of products released over the
next year that use soft CPU cores in FPGAs for embedded applications.

Most of these will run something based on Linux, but they could run
something else.

>Perhaps the way to go would be do define
>yet-another-lisp-virtual-machine, or figure out what symbolics used (or
>just use Common Lisp with lots of declarations!) and target the AMD64
>architecture.  It's got twice as many registers as the x86, lots of
>address space, they keep getting faster and cheaper all the time, and
>you can order one today, and have it delivered tomorrow.

Rather than define another one, why not follow KMP's suggestion and
make a business proposal to new Symbolics.

Someone, or a small group, could offer to port the VLM to AMD64 in
exchange for X number of licences to use the finished product.

Robert Swindells