I was a PhD student in the Rainbow Group of the Cambridge University Computer Laboratory. I worked in the area of reconfigurable computing - that is, using reconfigurable devices, such as FPGAs, for computation. Processing data with specialised circuits rather than general-purpose CPUs.

Such systems generally require the user to understand the hardware, and create their designs in a hardware description language. These systems would be much more accessible if they could be programmed with software descriptions. This would also simplify hardware/software co-design, if there were a shared algorithm description.

At the same time, synthesis from software should produce efficient hardware. There is no point trying to obtain a speed-up over general-purpose processors through parallelism, if this advantage is then wasted by inefficient compilers. This problem is compounded by the fact that most software is unnecessarily sequential. The elements of an array may be looped over when the programmer really just wanted a map over the elements.

My proposed solution is to synthesise hardware from a functional language. Functional languages generally provide a more abstract way of expressing algorithms, with higher-order operators such as “map” and “fold”. They are of a form that is well-suited to analysis and optimisation. In the long term, it may be unlikely that people will program hardware in traditional functional languages, just as functional languages haven’t taken over mainstream programming, but the languages used could be highly &ld-quo;syntactic-sugared&rd-quo; functional languages that look like imperative languages, with a functional intermediate representation.

My work is most closely related to Richard Sharp’s work on FLaSH and SAFL. This work is on synthesising hardware from a simple functional description, with dynamic arbitration. My work more-or-less tries to extend this, starting with a more complete functional language (although one still subject to static resource limitations), attempting resource-constrained optimisation, and producing pipelined hardware.

The main areas my work focused on were:

  • To handle stream processing. Statically-allocated languages can, to an extent, work on unbounded input and output streams. The synthesis tool should be able to transparently cope with these, producing pipelined designs.
  • To deal correctly with parallelism and pipelining, exploiting the hardware resources to the full.
  • To investigate evaluation models, and their relation to the underlying hardware implementation and its efficiency.

My focus was on stream processing. Streams provide an I/O model suitable for a pure functional language, and can provide a cut-down version of the problems associated with implementing closures. In contrast to normal lazy lists, streams cannot be “rewound”.

Non-PhD Work

For the last few years I have been working in finance, and I’ve had the good fortune to work on a real-world functional-programming project. We have a domain-specific functional language used to describe exotic equity trades, embedded in Haskell, and I’ve spent a while immersed in programming Haskell for my day job. Fun! Moreover, we’ve written a paper on our experiences, to be published in the Journal of Functional Programming, and in the meantime available here (normal pre-print caveats apply).

Last updated 1 May 2015. Mail me at random.user@arbitrary.name.