Orangepath HPR L/S Project: Hardware and Embedded Software Synthesis from Executable Specifications.
Small Examples A series of small BSV examples, complete with source code, to illustrate various language concepts in Bluespec SystemVerilog (BSV) Product information Getting Started. Download as PDF, TXT or read online from Scribd. Flag for inappropriate content.
HPR L/S main library description page.
Status
The main current implementation is in FSharp and held on bitbucket in the hprls2 folder (accessed via the Kiwi and Toy BSVC projects).
Overview
HPR L/S (aka Orangepath) is a library and framework designed for synthesis and simulation of a broad class of computer systems, protocolsand interfaces in hardware and software forms.The Orangepath library provides facilities for a number of experimental compilers.
The aim is to 'seamlessly' model both hardware and software in a formthat suits easy co-synthesis and co-simulation. It also includessome temporal logic for assertions. Software can exist as both machinecode/assembler and a high-level, block-structured, AST form.
VM2 and Plugin
The primary internal representation (IR) is a so-called HPR VM2 virtual machine.
The framework consists of a number of plugins that each input and output components represented in this IR. Hence plugins can be applied in any order.Hence, in type terms at least, all operations are `src-to-src'. But in practice, certain forms cannot be used in certain places: for instance a VM2containing RTL code cannot be rendered directly as C++ (it would have to be passed through the bevelab plugin first).
A characteristic feature of Orangepath is that plugins can potentially, always be applied in any order and often have inverses. For instance a pluginthat outputs RTL is reversed by a plugin that reads in RTL. A plugin that performs HLS from behavioural code to RTL would be reversed that by a plugin thatgives a single-threaded imperative program from a large body of parallel RTL code.
A simulator plugin, called diosim, is able to simulate the IR in any form and, in particular, is able to simulate interactions between parts of the systemdefined in different styles. For instance it can simulate a pair of CPU cores communicating with each other where one is modelled in RTL and the other as a cycle-callable ISS.Asynchronous I/O and network hardware is also modellable with these primitives.
A so-called recipe, which is an XML file, invokes the plugins in a particular order, supplying parameters to them. The input and outputof each recipe stage is a so-called HPR VM2 machine.Loops in the recipe can be user to repeat a step until a property holds.The opath core provides command line handling so that parameters from the recipe and the command line are combined and fed to the plugin components asthey are invoked.The opath core also processes a few `early args' that must be at the start of the command line. These enable the recipe file to be specified andthe logging level to be set.
The Orangepath library has plugins that support a variety of external input and output formats.
An HPR VM2 machine contains scalar and 1-D array declarations, imperative code sections and assertions. And a dataflow/transport-triggered IR form is being implemented at the moment.
Values are signed and unsigned integers of any width and floating point of any width is also supported in the framework but library componentscurrently only work for IEEE 32 and 64 bit formats. Enumeration types are also supported, the most important being the boolean type. For allenumerations, an exclusion principle is applied, in that if an expression is known not to be any but one of the values of enumeration, then it must bethat one value. Booleans are held differently from other enumerations internally but all expressions on enumerations are only storedin minimised form (using Espresso or otherwise). The library supports a great deal of constant folding and identity operation elimination (such as multiplying by zero or one).It has limited handling for strings and string constants, which are mostly treated in the same way that they are handled in Verilog, whichis as an expression or register of width 8 times the string length in characters. (But the Kiwi front-end can map a fixed set of strings toan enumeration type of a suitable width with the strings stored only once and indexed by the enumeration.)
Expressions are held memoised, and in a normal form, as far as possible, that makes identity checking and common sub-expression reuse easier. This is especially useful to be able to rapdily confirm, as often as possible, index expression equality or inequality, to avoid name alias RaW/WaW dependencies on arrays and loop value forwarding for sequential access patterns.
The imperative code is in any mix of RTL and DIC forms. RTL contains register transfer assignments, partitioned into clockdomains, where all assignments in a clock domain run in parallel on the active edge of the clock. There is also a combinational domain that has no clock. The DIC imperative form (directly indexed code) is an array of statements indexed by a program counter, where the main statements are: scalar assignment, 1-D array assignment, library call and conditional branch within the array.Code sections can be in series or parallel with each other, using CSP/Occam-like SER and PAR blocks. Assertions are coded in temporal logic and associated with a clock domain, just like PSL (property specification language).
Dynamic storage allocation is also being added.
Message-passing, CSP-like channels are another thing that should perhaps be added as a primitive form but currently these are constructed out of thread synchronisation primitves in a shared-variable paradigm.
Variable Declarations
Variables are signed and unsigned integers of various precisions,single and double precision floating point and 1-D arrays of suchvariables. A small amount of string handling is also provided. Allvariable are static (no dynamic storage) and must be unique in asingle namespace that spans the system. The variables are declaredinside a given VM and may be global or local. Global variables may beaccessed by code and assertions in any VM and local ones should (notenforced) only be accessed in locally (or in son machines?).
Expressions
Expressions commonly use the hexp_t form and commands use the hbev_tform. Single-bit variables have hbexp_t form. A library of 'ix_xxx'primitives can be called as functions or procedures from hexp_t, hbexp_t andhbev_t respectively. Expressions are all stored in a memoising heapusing weak pointers.
Imperative Code Forms
The executable code of a VM has several basic forms (dic, asm, rtl, cmd,fsm). All code and assertions access the variables for read andwrite (but assertions don't tend to write!) regardless of form.
The executable code may be clocked or non-clocked. Fragments may beput in serial or parallel using the SP_par and SP_seq combinators.There are two variants of SP_par, for lockstep and asynchronouscomposition.
Dataflow/transport-triggered Code Forms
... TBD ...
Plugins
Other descriptive text ...
Under Construction/Editing
Source Files and Plugins
HPR L/S is written in FSharp.
Main/core files describing the VM:
Synthesis/Elaborate Plugins:
Measurement pluginsOutput plugins:
Misc libraries and framework infrastructure
Links
Kiwi Scientific Acceleration (FPGA High-Level Synthesis from dotnet/CIL ByteCode):Kiwi and Kiwic.
Bluespec compiler:Toy BlueSpec Compiler
Experimental specification language (old) H2Spec.
UIA Processor Use and Synthesis.
Multi-FPGA logic partitioner, instantiator and structural wiring generator:HPR System Integrator .