Connecting ForSyDe Models to the CoMPSoC Design Flow

ForSyDe supports modeling of heterogeneous embedded systems using the notion of ModelsOfComputation. A ForSyDe model is an executable model which also contains formal properties that can be exploited for application of formal methods and automatic synthesis. On the other hand, the NoC-Based CoMPSoC platform is able to run such models with predictable properties in a composable manner. The aim of this work is to connect these two flows in order to get a full design flow from top-level specification of the systems down to their implementation on an MPSoC.

The SystemC-based version of ForSyDe has been chosen for this work since the functions provided to ProcessConstructors are already in C/C++ format and hence, easier to be used for compilation tasks.

Generating CoMPSoC-compatible description from a ForSyDe model

The ideal scenario is the following:

  • The designer specifies a system model just based on the natural ForSyDe rules and semantics without worrying about synthesis, etc.
  • The design is verified by simulation
  • The user adds a library call to generate a CoMPSoC-compatible description of the system in the next run before the simulation. Hopefully, this should not need any additional modification to the verified model.
  • The generated files are fed to the CoMPSoC flow as they are for later refinement and synthesis.

Extracting the System Structure

SystemC supports system traversal to some extent. We add some extra information to ForSyDe processes so that they collect the missing information (e.g., token sizes, list of binded channels to ports, etc.) in the elaboration time. Finally, at the start_of_simulation phase of the SystemC simulation kernel, the system hierarchy is traversed starting from the specified top-level of interest and a CoMPSoC-compatible XML file is generated at the output.

Extracting the Source Code of the Functions Passed to the Process Constructors

The source code of the functions passed to the process constructors need to be extracted and saved in separate C files and they should also be also addressed in the XML files.

Instead of parsing the input sources, which can be complicated, we require the designer to annotate the start and the end of interesting functions. This is trivial for the designer but simplifies the source code extraction to a large extent. Giving the source code path of the model to a library call is sufficient to look into the source codes and generate the isolated functions.

Additionally, an easy to follow (but of course restrictive) naming scheme for SystemC modules (or ForSyDe processes) should be followed so that the extracted functions could be refered correctly in the XML system structure file.

A Demonstrative Example

The example we use here is the toysdf example which is depicted below:

This example has the following features

  • belongs to the SDF MoC
  • includes feedback
  • has a delay element (initial token on arc)
  • has hierarchy

But does not include multi-output processes(actors).

The source code for this example resides in TOBEADDED

In order to get the structure in the output as an XML plus a set of CPP files, the user just adds the following code snippet to the start_of_simulation callback of the top SystemC module:

ForSyDe::CoMPSoCExport dumper;
dumper.traverse(this);
dumper.printXML("outfile.xml");
dumper.printSrc("/path/to/the/source/files/","/path/to/the/generated/files/");

In this way, an XML file associated with a set of XML files are produced.

Limitations and Future Work

Right now, the tool has the following limitations:

  • Limited to SDF (no CSDF yet)
  • It is not clear how it is going to support multi-output actors. One solution is to optimize an actor followed by an unzip process to a multi-output actor. (Now it is assumed that each unzip process is preceded by a single output actor to which it should be merged. Merging is done before XML DOM construction)
  • Following the original model, it produces separate actors as delay elements rather than optimizing them to initial tokens on the channels. (delay processes are now converted to initial tokens on channels)
  • Uses the C++ std::vector as the input/output interface of the functions. CoMPSoC requires pointer-based plain C functions. (Now the design rules for the functions are in such a way that only the common operators between std::vector and C arrays should be used so that it could be compiled without STL)
    • But still the generated code should be modified manually since some type information in the generated adaptation interface is missing.
  • The generated XML does not include the argument mapping for actor functions.
  • Since the original model is an SDF (and not TSDF), the execution times for actors (which are needed by SDF3) are missing.

The ForSyDe-CompSOC Design Flow

CompSOC is an MPSoC platform developed at the Eindhoven University of Technology. CompSOC features a predictable and composable hardware and software system allowing quick prototyping on Xilinx FPGAs. The ForSyDe-CompSOC design flow is developed as a Masters' Degree project. The design flow allows the designer to model the system at a high level of abstraction using the MoCs of ForSyDe and it automatically maps the ForSyDe processes to their SDF equivalents to produce the CompSOC executable.

Overview

The application development on the CompSOC platform is typically carried out on the development server. When the developer wishes to run his/her application on the FPGA board that is connected to the board server, he/she executes a make command on this development server. The CompSOC design flow automatically synthesizes the hardware platform, compiles the applications, runs the system on the FPGA board and returns the results of the execution.

The ForSyDe-CompSOC design flow is developed to be able to work in this kind of a distributed environment, where the designer's workstation, the CompSOC development server and the FPGA board server may be different computers that are not co-located. This is advantageous for the designer since the CompSOC design flow has specific prerequisites for correctly functioning and the designer can only worry about the ForSyDe-CompSOC design flow configuration on his/her workstation.

The following part discusses the requirements of the ForSyDe-CompSOC design flow and the basic configurations. An example case study is also shown on this page to give a demonstration of the design process.

Prerequisites and Installation

The installation procedure of the ForSyDe-CompSOC design flow is as straightforward as setting up an environment variable, however it requires some software packages to be installed on the designer's workstation.

Prerequisites

  • GCC 4.7.3
  • LLVM 3.2
  • OPT 3.2
  • libsaxonb-xslt 9.1.0.8J

ForSyDe Dependencies

Preliminaries

  • SSH connectivity must be configured to access the CompSOC development and board servers
  • The dependencies for the simulation and the automated design flow must be installed
  • The tools must be compiled
  • The needed environment variables must be set

The Directory Structure

  • bin: Linked binaries for experiments and tools
  • doc: Output directory for reports
  • etc: Integration files
  • flow: Scripts for the automated design flow
  • include: C++ utilities for ForSyDe simulation
  • lib: ForSyDe and SystemC libraries
  • reports: LaTeX files for reports
  • tools: Source code for tools
  • workspace: The primary working directory for development

Environment Variables

The environment variable FCF_HOME must be set to point to the directory where the README file resides.

export FCF_HOME=/home/<username>/<path>/<to>/<the>/<readme>

Configuration

  • flow/compsoc.mk : This makefile contains the user information for CompSOC connectivity. The three important variables that need to be set are the following.
    • COMPSOC_DEV_SERVER = co11
    • COMPSOC_USER_NAME = ealtinel
    • COMPSOC_DEV_DIR = /home/ealtinel/compsoc

  • flow/global.mk : Contains the global settings for the tools to use.

Using The ForSyDe-CompSOC Design Flow

The designer is expected to use the workspace directory for development. The workspace directory contains three sub-directories. These are:

  • backends : Contains the resources and files needed by specific backends. Since, as a backend, currently there is only CompSOC, this folder contains the compsoc directory. This directory may contain a number of directories each representing an instance of this backend as shown in the example below.
    • A generic path: $FCF_HOME/workspace/backends/<platform>/<platform_instance>/makefile
    • An example path: $FCF_HOME/workspace/backends/compsoc/xilinx2tile3dma/makefile
  • forsyde : This directory contains the ForSyDe applications. Each sub-directory represents a ForSyDe application.
    • $FCF_HOME/workspace/forsyde/<application>/src
    • ex: $FCF_HOME/workspace/forsyde/susan/src
    • Make targets in this directory
      • default: compile
      • run: runs the simulation
  • systems : This directory contains the system instantiations. Systems contain a number of applications from the forsyde directory and a platform instance from the backends directory. The applications and the platform instance are specified in a makefile.

ex: $FCF_HOME/workspace/systems/susan_2tile/makefile

An example system instance containing two applications and a 2 tile instance of the CompSOC backend is specified with the following makefile variables:

APPS = susan jpeg_decoder
BACKEND = compsoc
PLATFORM = xilinx2tile3dma

A Simple Use Case

The ForSyDe-CompSOC design flow can be used to generate a working prototype of the application modeled as the following ForSyDe process network. The dashed lines in this figure represent the ForSyDe composite process boundaries and as can be seen there are two sub-components(or composite processes) of the top level module.

The designer uses the workspace/forsyde directory to develop and test the ForSyDe application. And the systems directory contains the makefile where this application and the CompSOC instance under the backends folder are defined.

The original ForSyDe model

The source code generation requires the designer's annotations in the original source code using the C++ pragma keyword. Additionally the designer must declare the types of the tokens used in the design by using the macros DEFINE_SIGNAL_TYPE and DEFINE_STRUCT_TYPE for tupled signals and user data types such as structs respectively.

typedef std::tuple<std::vector<MCU_BLOCK>, std::vector<EdgeStrength>> SusanUsanOutputType;
typedef std::tuple<std::vector<MCU_BLOCK>, std::vector<EdgeStrength>, std::vector<EdgeDirection>> SusanDirectionOutputType;
typedef std::tuple<std::vector<MCU_BLOCK>, std::vector<EdgeDirection>> SusanThinOutputType;

DEFINE_SIGNAL_TYPE(SusanUsanOutputType)
DEFINE_SIGNAL_TYPE(SusanDirectionOutputType)
DEFINE_SIGNAL_TYPE(SusanThinOutputType)

DEFINE_STRUCT_TYPE(MCU_BLOCK) {}
DEFINE_STRUCT_TYPE(EdgeStrength) {}
DEFINE_STRUCT_TYPE(EdgeDirection) {}

...

void direction_func(std::vector<SusanDirectionOutputType> &out, const std::vector<MCU_BLOCK> &inp1, const std::vector<EdgeStrength> &inp2) {
        out = V(1, T(C(1, MCU_BLOCK), C(1, EdgeStrength), C(1, EdgeDirection)));
        
        FLATTEN_INPUTS(inp1, inp2);
        FLATTEN_OUTPUTS(out);

#pragma ForSyDe begin direction_func

        susanDirection(&I(0, 0), &I(1, 0), &O(0, 0), &O(1, 0), &O(2, 0));

#pragma ForSyDe end
}

The FLATTEN_INPUTS and FLATTEN_OUTPUTS macros allow the designer to access the inputs and outputs in a linear fashion whereas the normal way would require the designer to extract tokens from nested tuples and vectors. And by using the I and O macros, the designer can access the individual tokens in inputs and outputs. The output variable is normally left to the designer to assign a value. However in case of complex nested types this becomes tedious, hence V, T and C macros are provided to the designer for instantiating empty vectors and tuples as illustrated in the listing given above.

With a single make command the ForSyDe-CompSOC design flow is started and the first step in the design flow is to flatten the hierarchy which brings all the sub-modules under a single top level module to carry out the conversion.

The flattened ForSyDe model

The flow continues with the conversion of the process network into the SDF graph shown below.

The converted SDF equivalent of the original ForSyDe model

Attachments