James Swaine:
> the class discussion touched briefly on the recently increasing use of
> functional programming languages (e.g. haskell) as an alternative to
> strictly imperative languages like C, because they (may or may not) offer a
> better alternative for mapping a language description of a function to its
> hardware implementation. this reminded me of this
> article<http://blogs.msdn.com/dsyme/archive/2008/10/24/from-parallel-f-to-p
>arallel-fpgas-from-avalda.aspx>, describing a compiler which produces HDL
> descriptions of FPGA's from source code written in a functional language
> similar to haskell (and including constructs for parallel processing).

There is another language written for the same purpose called Lava
(http://raintown.org/lava/). It is based on Haskell.

> this got me thinking about the possibilities of describing circuits in
> general with a functional language like haskell - because pure haskell is
> side-effect free, the only way you can really code "state" into a function
> is via recursion (so the state of a function being executed is always
> exclusively defined by its inputs). this seems like it would lend itself
> reasonably well to sequential circuit design, where a circuit represents a
> function, and the circuit's outputs eventually become its inputs, and thus
> determine its state in subsequent "runs". but how would you model a
> traditional mealy machine in a language like this?

One possibility would be to express state transitions and outputs
functionally, i.e., express them as functions of state and inputs. That
still leaves the problem of state.

> also, would it even be
> possible to implement a synchronous circuit this way, since then your
> function is dependent on some external state (a clock signal), which
> introduces side effects?

The clock could be handled implicitly, e.g., by flagging some functions as
edge sensitive, or explicitly.

It is possible, but likely very hard, to completely eliminate the problem of
state for some designs by developing a clever synthesis algorithm. For
example, instead of specifying the multi-cycle behavior of a multiplier,
specify its behavior functionally and put decsions abour division into states
into the synthesis algorithm.

> i apologize if this is a little off-topic, but i thought it was interesting
> (maybe like trying to fit a square peg into a round hole).

Definitely not off-topic. Did you think/read more about this? Any
conclusions?

Best Regards,

-Robert Dick-
Received on Sun Jan 4 16:00:59 2009