HardCaml Design Flow

I will start with an overview of designing a complex IP core in HardCaml. Later I will discuss some specific techniques that can be employed to help raise the level of abstraction over standard RTL design flows.

IP Core Design Flow

Reference Model

One of the key advantages to designing hardware with HardCaml is the ability to keep both a reference model and the hardware model in the same language. Indeed in the same program.

This offers the designer the ability to cross check between the models at almost completely arbitrary points.

In contrast many standard design flows use a different language for the reference model (probably C) and hardware design (Verilog or VHDL).

When iterating between models removing the language barrier, and associated trace or debug files, is a big win for HardCaml.

New Abstractions Levels

A further advantage to bringing the software model and hardware design together is that it allows a both to be iteratively refined towards the final goal.

1. Using the combinatorial API shallow embedding a number of architectural aspects of the hardware design can be resolved before any detailed work on the internal timing of the design.
2. In the extreme a complete combinatorial version of a core can (sometimes) be developed, then reused for the timed version.
3. A mixture combinatorial logic to bit accurately describe the design and OCaml control code can be used to find an appropriate timed model.
4. Hardware sub-modules can be developed and integrated back into the software model.

Example

Here's an example design flow recently used to develop a Reed-Solomon ECC core.

1. Develop reference model while learning algorithm.
2. Refinement of Galois field code; unify the hardware/software.
3. Development of hardware submodules: syndromes, berlekamp-massy, forney, chein. Test each within reference model.
   1. Testing combinatorial logic
   2. Some simulation
4. Integration - simulation

Other techniques

Fixed point data paths

Efficient hardware usually requires conversion of floating point to fixed point arithmetic. Ensuring enough precision is a task resolved by either

1. Matlab or it's various cousins
2. Hacking within the reference model
3. Creating parametrised data paths and testing in simulation

HardCaml includes a Fixed point library making tasks 2 and 3 much simpler. Fixed points can be tracked throughout computations by the library along with precise control of rounding and overflow modes.

It's possible to go further, however, by augmenting the fixed point library. One example is self sizing data paths. Given knowledge of the ranges of input values the computations can track the input/output ranges of intermediate values and size buses appropriately. This approach was used to implement an IEEE compliant DCT with the only variable the precision of the sin tables.

In addition for heavily arithmetic circuits it's possible to imagine a way of tracking and specifying the error tolerances of certain arithmetic nodes and having the circuit optimise itself.

Specialised Domain Specific Languages

Probably the most interesting possibility is the ability to write spcialized domain specific languages. At their simplest something like the fixed point library can be considered a DSL. At their most complex a high level synthesis compiler could be written with HardCaml as a back end.

In between these extremes are various specialized DSL's that can leverage a little bit of compiler like technology to solve specific problems.