Below are some of the software projects that I made contributions to.

Dataflow programming and CAL - Open Dataflow, ACTORS, MPEG RVC

The Open Dataflow project is creating a parallel programming toolkit based on dataflow as a programming model. Dataflow actors  are written in the CAL actor language and composed in a number of ways. The software provides an Eclipse plugin with untimed, functional simulation, as well as code generators for C and Verilog/VHDL.

One interesting aspect of the implementation is its extensive use of XML for representing just about anything that is being manipulated by the software: actors, compositions of actors, programs computing compositions of actors, intermediate forms that feed into code generation backends, dataflow execution traces, configuration files etc. Also, a lot of the actual code implementing the tools is written in XSLT, as transformations on those XML documents. A lot of the "heavy lifting" (i.e. primarily the simulation and the code generation) is still to a large extent written in Java, of course, and the Java code makes interesting use of the XML/XSLT/XPath facilities in a number of places.

The Open Dataflow project is being used as part of other efforts. The ACTORS project is an EU-funded project led by Ericsson that sets out to build tools and infrastructure for resource control in embedded systems (such as, just for example, wireless terminals)---based on dataflow. In fact, much of the software work that happens in ACTORS is checked into the Open Dataflow repository, so these days the ACTORS project has become a major contributor to the Open Dataflow code base. Most notably, the folks at Ericsson have built a C backend for CAL, and also a runtime infrastructure for ARM multicores.

MPEG's Reconfigurable Video Coding (RVC) initiative is trying to create a new way of specifying video standards, and a new way of building video codecs. It is using the Open Dataflow software as its tool infrastructure, and the CAL language as a vehicle for describing video coding components.

Background

While in the Ptolemy project, Johan Eker and I designed a language for writing dataflow actors called CAL. In it, actors, the computational kernels of a dataflow program, are described as making discrete steps called transactions or firings. In each such step they can consume input tokens, produce output tokens, and modify their state if they have any. Token passing between actors is generally assumed to be asynchronous, meaning that the consumption of a token is not synchronized with its production, unlike in models such as CSP, where the producer and the consumer of a piece of data rendezvous when they communicate.

The dataflow model underlying CAL is that of dataflow with firing. CAL extends the basic model of firing rules and iring functions (see here) in three ways:

1. State. Actors may contain state, which they can use and change during a firing. This state is perfectly encapsulated, i.e. no two actors can share state.
   
2. Multiple non-joinable rules. Actors are described as collections of firing rules, called actions, which define the production and consumption of tokens, and also how the actor state changes. Action may also add conditions, called guards, that need to be satisfied before they can execute. When all its conditions for firing are satisfied, an action is called enabled. In general, any number of actions may be enabled at any point in time, giving rise to the possibility of non-determinism. Whenever an actor fires, it selects one of its enabled actions and executes it.
   
3. Priorities. Priorities are a way to control the action selection process by establishing a partial priority order among actions. When two enabled actions are ordered in this manner, only the higher-ranked one is firable.

A related property of this style of actor description is that it can be implemented efficiently both in software and in programmable hardware.

Behavioral synthesis - OpenForge

OpenForge is a tool that translates an intermediate format (intermediate between a source program and the compiled result, that is) into Verilog. That intermediate representation is an XML format called XLIM and essentially represents a program with one or more threads in SSA form. The generated Verilog can be synthesized into implementations on Xilinx FPGAs.

The OpenForge infrastructure makes it much easier to produce behavioral compilers targeting FPGAs. It is not a complete behavioral synthesis engine, since it does not perform many of the common high-level program transformations, such as loop transformations and parallelization based on affine loop analysis. It does, however, perform numerous low-level optimizations that are essential for high-quality implementations. It has been tested extensively as the HDL backend of the Open Dataflow tool chain, where we used it to produce FPGA implementatons that frequently beat hand-written HDL.

To get an idea of what this could be used for, check out this small example. It represents a transformation (written in XSLT) that translates an XML-dialect representing a simple while-language into XLIM. A few hundred lines of XSLT, and you got your own behavioral synthesis engine! (Albeit a very, very simple one.)

The Open Dataflow project contains a much more sophisticated example. The chain translating CAL actors into XLIM consists of around 20 XSLT transformations, each performing some analysis or program transformation step.

Discrete event modeling and simulation - Moses