CBG-BSV Toy Bluespec Compiler

The Bluespec System Verilog language is increasingly seen as a viable and productive alternative to conventional RTL coding
for hardware design. For compiler writers like myself, the best way to learn a new language was to write a toy compiler for it. Also,
where there's a lack of formal semantics for a language, writing a compiler is a good way to learn about the important and/or arbitrary decisions that have
to be made. (These seem to be in the scheduler and in the way implicit guards of implicit guards are processed)

The user manual from Bluespec Inc may have restricted circulation,
so this informal study was based on a couple of published studies:
`HARDWARE LANGUAGES AND PROOF' by Dominic Richards of Manchester
University and `A Unified Model for Hardware/Software Codesign' by
Nirav Dave when at MIT.

This article gives the essence of a compiler for Bluespec. This
toy compiler was coded in F Sharp using the HPR/LS library. This
library provides various logic manipulation facilities and output
functions for SMV, SystemC, Verilog and so on. Rather than initially writing a
Bluespec parser, the test abstract-syntax trees were manually entered
as separate F Sharp source files. This is actually an attractive
approach but needs tidying up from what is here. The attraction is
that Bluespec has a static elaborator which is basically a Haskel
interpreter, but by embedding our constructs in F Sharp instead, we
have the power of the ML dialect of F Sharp to do exactly the same kind of
elaboration. All of the higher-order iterators and functors are
exactly the same, modulo inserting 'fun () -> ' in a few places to get
lazy behaviour. The good work needed is to use the domain-specific
language (DSL) embedding facilities of F Sharp for the elaborated
leaves. I might do this if I update this page.

I shall put a version of the Toy Bluespec Compiler on the following link for your own experiments: HERE.

Note that I have reversed the spoons to philosopher number 2. This stops the system from deadlocking straightaway!

Verilog Output

The Verilog RTL output looks as follows (note: this was the very first run and there might be some bugs in this, but it
seems to work!) HERE.

Does this deadlock? The HPR library can output also an NuSMV file of this design. We can give SMV the -ctt
command line flag and it will check for deadlock (eventually?).

The above toy compiler has a default rule precedence based on the textual order of the
rules in the source code. It's not hard to add priorities.

The above compiler does not have the interlock that BSV defaults to ON for each rule
that stops it firing more than once per cycle. This can be added where the comment says.

Finally, the above compiler does not check alternate compositions of rule pairs to
see if they have the same effect, but a simple approach based on textual equivalence
of effect would work quite well because the expressions are all converted to a normal
memoized form by the HPR library, so most minor artefacts arising from alternate compositions,
such as operator association and operand interchange in commutative operators are eliminated.

The online Bluespec examples define a simple microprocessor that is provided with an assembly coding of Euclid's algorith.
The above plot shows the toy compiler can now parse and correctly execute the processor and the example algorithm: the GCD of 27 and 15
is 3 which is printed from R1 at the end of the computation. The delay at the start is the download of the program into the
processor by the testbench. Mind you, this hardly stretches the interesting parts of the Bluespec scheduler.