Compilation Overview

Kermin Elliott Fleming edited this page Apr 22, 2015 · 8 revisions

Compilation Overview

Initialization

LEAP compilation begins with a top level SCons file, located in program build directory:

   WORKSPACE_NAME/build/default/MODEL_NAME/pm/SConstruct

The top level SConstruct contains a representation of the full program source, which is converted by the build pipeline into a ModuleList.

Interface compilation

The first stage of LEAP compilation is producing the interface between host and FPGA, RRR.

Anatomy of a LEAP program

LEAP compilation is somewhat complex. The following picture gives an overview of the Verilog anatomy of a LEAP program.

LEAP programs consist of two parts: the user program and the platform, which contains the various support logic to run the user program.

mk_build_tree_Wrapper: managing the user code

LEAP views user programs as collections of latency-insensitive modules defined by named latency-insensitive communications channels. In some sense, modules are all peers and hierarchy is created by the programmer using naming conventions. On the other hand, Verilog, Bluespec and other HDLs are hierarchical. Thus, some structure is needed to convert between the unstructured view of LEAP and the hierarchical view of HDL. We call this structure the “build tree.” Build tree is constructed at compile time by LEAP, and converts the flat collection of user modules in to a hierarchy. This hierarchy tries to optimize for compilation time — user modules are separated based on heuristics which speed the compilation of the Bluespec compiler. All internal nodes of the tree are compiler-generated. User latency-insensitive modules are leaf nodes in the tree.

mk_platform_Wrapper: the LEAP platform

One of the key benefits of LEAP is managing device interfaces. The “platform” handles this interfacing. Platform differs from user code in that it must necessarily involve wired external interfaces. Because these wired interfaces require some special handling at compile time, the platform is separated from the pure latency-insensitive modules of user program and the build tree.

The platform typically instantiates multiple submodules, each corresponding to a device driver. These submodules simplify timing closure and the creation of physical constraints.

mk_model_Wrapper: tying things together

The top-level mk_model_Wrapper connects the platform and build tree submodules to form a complete LEAP program. This module also exports the top-level, externally connected wires from the platform.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.