Verification of Parameterised FPGA Circuit Descriptions with Layout ...

CHAPTER 2. BACKGROUND AND RELATED WORK 16
The Quartz framework is also intended as a platform for experimenting with language and
CAD algorithm design. The relative simplicity of the language and the modular design of
the compiler simplifies experimentation with new language constructs and processing stages.
A workflow exists to take Quartz designs from an abstract specification through to real
hardware using a compiler which transforms Quartz into Pebble then into VHDL.
Quartz higher-order combinators allow circuits to be described quickly and concisely by
having libraries of common circuit structures available such as rows and columns as well as
more complex structures such as trees. Quartz designs can also be parameterised by integer or
boolean input variables and the combination of these features leads to an expressive language
which puts the power of the Ruby calculus within a practical VHDL-inspired framework.
2.3.1 Type System and Overloading
Quartz has three basic signal types for wires, integers and booleans. Integers and booleans
are used for parameterisation to control the circuit description while wires are a primitive
type which are not evaluated by the compiler during elaboration. Assignment to wires is
overloaded allowing both boolean and integer values to be statically assigned to wires as
well as wires being connected together. Although an integer assignment to a wire clearly
has no meaning in terms of pure hardware it can be very useful for simulating word-level
descriptions of a design where a wire type signal can represent a data word.
The language supports both tuples and vectors of signals. While tuple size is fixed by the
designer at coding-time the length of a vector can be parameterised. Blocks also have a block
type and can be passed as parameters to other blocks. Any valid polymorphic operation can
be carried out on blocks, for example it is acceptable to build a vector of blocks.
Quartz uses implicit typing and infers most types using the Hindley/Milner type system
[14, 27, 53], however designers are required to enter type signatures for each block entity.
This requirement contributes to the documentation of the code and allows clear and localised
feedback on type errors. Combined with the use of tuples rather than lists for fixed-arity
groups of signals, this substantially accelerates design development by eliminating time spent
chasing confusing type errors.