CPU/Hardware optimized for Erlang (FPGA)

[Paulo Alexandre Ferreira]

Thomas Lindgren has wrote: 
> FPGAs are very interesting, definitely. I think the
> manufacturers now offer simple migration paths from
> FPGA to ASIC too, if you find you have a winner.

Recycling an old (2003 ) post : 
Really really crazy idea:  :-) :-) :-) 

  Why not "compile Erlang directly into Hardware" ?

   We have usually lots of processes, that could be "mapped" into
   different areas/blocks of the FPGA.

   Each process will have its own hardware, enough to do its own tasks,
   and comunicates with other "processes/hardware blocks" by
   message passing.

  Pattern matching can be easily done in software also ( I presume ) if one chooses 
  the data tags well. 
 Things like this loop are simple and fast in Hardware.

   loop(Counter)->
        receive
           {up,Pid} -> loop(Counter+1);
           {down,Pid} -> loop(Counter-1);
           {query,Pid} -> Pid ! {value,Counter}, loop(Counter)
        end.


   Variants:
   a) At startup, all "processes/hardware blocks" are created and start
      "processing" the messages they receive.  Easier, more inefficient use of the hardware.
 
    b) The "hardware blocks/processes" are "created" at runtime
       reconfiguring dynamically the FPGA. Harder, but more efficient use of 
       the hardware.

   So instead of making hardware that "parallelizes" serial software
   with things like "sliding registers", why not start with software
   that is already "parallel" like Erlang, and put it into Hardware ?

 Low power is a niche, but maybe the question that Erlang answers is not related to low power, 
but how to use to the maximum  the 10^6 of transistors that can be placed today on a CPU. 
  This is also true of FPGAs that have today  more than 10^6 system gates.

  There are several answers on how to use tons of hardware to get performance: 

        RISC/CISCs of today: 
        big caches, pipeline, out of order execution, multiple execution units, 
        The hardware takes care of "parallelizing" the software. It is the 
        processor that at run time, decides (or tries to find) what can be done by the 
        different execution units.  

        EPIC: 
        several independent execution units, whose control is "available" to the software. 
        The software (the compiler) is in charge of the parallelism. The CPU has no initiative. 
        The compiler receives a "high level language" source code, and on the translation 
        to executable code, must discover the parallelism, and take care of it. 
        Usually the compiler does a bad job, and the programmer has to do it instead. 
        :-) :-) 


        "Erlang in hardware"
         All the "control" is available to the programmer. When an Erlang programmer 
         "splits" the work to be done between different processes, he will be already 
         distributing that work among several pieces of hardware. Different processes
        will be mapped  in different areas of the hardware.

   
  Questions/considerations: 
         
      Versatility: Every time the "program" changes we must "change" the hardware. 
                        This is inflexible, and suitable only for embedded systems, but  can be done
                        fast with FPGAs. 
  
      Size of the hardware FPGAs: One could easily use more than one FPGA, because 
        (well almost) all comunication is by message passing. In our Erlang program we
        have the connections between the different pieces of hardware made explicit by
        the sending and receiving of messages. So our "hardware buses" will match 
        the sending and receiving of messages. 
        
     Restarting a process:  This can be done "resetting" the  hardware of that process. 
  
     "(UBF) Contract checkers": can be placed between the processes. 
   
     Formal verification: can go down to the hardware.



This is obviously a  "silly season, thinking out loud" post but, but one interesting
 idea to develop/try would be : 
     Erlang as an Hardware Description Language.

Greetings 

Paulo Ferreira