Lambda the Ultimate

Please stop posting fascinating, must-read articles to the front page. I am too busy.

Seriously, I am very pleased to see this kind of methodological work, and am looking forward to reading this, together with papers [10] and [12] from the references section.

Hi LtUers. I'm a long time lurker here. The hardware related articles are of particular interest to me since that's what I do for a living. So without further ado, some thoughts:

For starters the author's statement about the economics of FPGAs is incorrect for everything but very low volume (read one-off) designs. For moderate to high volume designs moving down a part can reduce parts cost substantially esp. since FPGAs are now SoCs in their own right and often constitute a large part of the parts cost so efficiency is very important.

The FIM concept is interesting, but whereas in software a single FIM is sufficient because the machine is fixed, hardware seems to require different FIMs for different situations. The req/ack model is not appropriate for all functions or even for most functions. Many data processing pipelines just 'push' data through without any information going backwards through the pipeline for example.

Finally, the whole idea of taking a software-ish algorithm and trying to compile it down to hardware seems flawed. When you design the practical implementation of an algorithm you have to take into consideration the underlying machine, and it's strengths and weaknesses. Even in fairly abstract languages like Haskell you have to consider realities such as cashing and IO buffering.

The way you implement a median filter in an imperative language is entirely different from one in hardware in large part because of the assumptions you make about the costs of different operations. For example, in software, compare and shift have the same cost. In hardware, especially in an FPGA architecture like Xilinx's where you have things like SRL macros, they've very different.

I'm still looking for a better approach. VHDL & Verilog are to hardware what C language is to software but approaching hardware design from a software point of view is also doomed to failure IMO.

I think the functional programming paradigm has a number of things going for it w.r.t HW design. Hardware has a natural separation between pure functions and state (flip flops, FIFOs, RAM) like FP. Strong typing & verification of pure functions are also is a big plus.