Changes between Version 8 and Version 9 of ForSyDeToCoMPSoC


Ignore:
Timestamp:
08/18/13 22:08:43 (4 years ago)
Author:
altinel
Comment:

The ForSyDe-CompSOC Design Flow additions

Legend:

Unmodified
Added
Removed
Modified
  • ForSyDeToCoMPSoC

    v8 v9  
    4747dumper.printSrc("/path/to/the/source/files/","/path/to/the/generated/files/"); 
    4848}}} 
    49  
    50  
    5149In this way, an XML file associated with a set of XML files are produced. 
    5250 
     
    5856 * ~~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) 
    5957 * ~~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) 
    60   * But still the generated code should be modified manually since some type information in the generated adaptation interface is missing. 
     58   * But still the generated code should be modified manually since some type information in the generated adaptation interface is missing. 
    6159 * ~~The generated XML does not include the argument mapping for actor functions.~~ 
    6260 * Since the original model is an SDF (and not TSDF), the execution times for actors (which are needed by SDF3) are missing. 
     61 
     62 
     63= The ForSyDe-CompSOC Design Flow =  
     64CompSOC 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. 
     65 
     66== Overview == 
     67The 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. 
     68 
     69The 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. 
     70 
     71The 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. 
     72 
     73== Prerequisites and Installation == 
     74The 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. 
     75 
     76==== Prerequisites ==== 
     77* GCC 4.7.3 
     78* LLVM 3.2 
     79* OPT 3.2 
     80* libsaxonb-xslt 9.1.0.8J 
     81 
     82==== ForSyDe Dependencies ==== 
     83* SystemC  
     84* Boost Library 
     85* ForSyDe 
     86 
     87==== Preliminaries ==== 
     88* SSH connectivity must be configured to access the CompSOC development and board servers 
     89* The dependencies for the simulation and the automated design flow must be installed 
     90* The tools must be compiled 
     91* The needed environment variables must be set 
     92 
     93==== The Directory Structure ==== 
     94* '''bin:''' Linked binaries for experiments and tools 
     95* '''doc:''' Output directory for reports 
     96* '''etc:''' Integration files 
     97* '''flow:''' Scripts for the automated design flow 
     98* '''include:''' C++ utilities for ForSyDe simulation 
     99* '''lib:''' ForSyDe and SystemC libraries 
     100* '''reports:''' LaTeX files for reports 
     101* '''tools:''' Source code for tools 
     102* '''workspace:''' The primary working directory for development 
     103 
     104==== Environment Variables ==== 
     105The environment variable FCF_HOME must be set to point to the directory where the README file resides. 
     106 
     107 export FCF_HOME=/home/<username>/<path>/<to>/<the>/<readme> 
     108 
     109==== Configuration ==== 
     110* flow/compsoc.mk : This makefile contains the user information for CompSOC connectivity. The three important variables that need to be set are the following. 
     111 * COMPSOC_DEV_SERVER = co11 
     112 * COMPSOC_USER_NAME = ealtinel 
     113 * COMPSOC_DEV_DIR = /home/ealtinel/compsoc 
     114  
     115* flow/global.mk : Contains the global settings for the tools to use. 
     116 
     117== Using The ForSyDe-CompSOC Design Flow == 
     118The designer is expected to use the workspace directory for development. The workspace directory contains three sub-directories. These are: 
     119 
     120* 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. 
     121 * A generic path:  $FCF_HOME/workspace/backends/<platform>/<platform_instance>/makefile 
     122 * An example path: $FCF_HOME/workspace/backends/compsoc/xilinx2tile3dma/makefile 
     123 
     124* forsyde : This directory contains the ForSyDe applications. Each sub-directory represents a ForSyDe application.\\ 
     125 * $FCF_HOME/workspace/forsyde/<application>/src 
     126 * ex: $FCF_HOME/workspace/forsyde/susan/src 
     127 * Make targets in this directory 
     128  * default: compile\\ 
     129  * run: runs the simulation 
     130 
     131* 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.\\ 
     132 
     133 ex: $FCF_HOME/workspace/systems/susan_2tile/makefile 
     134 
     135An example system instance containing two applications and a 2 tile instance of the CompSOC backend is specified with the following makefile variables:  
     136 
     137 APPS = susan jpeg_decoder\\ 
     138 BACKEND = compsoc\\ 
     139 PLATFORM = xilinx2tile3dma 
     140 
     141=== A Simple Use Case === 
     142The 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. 
     143 
     144The 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. 
     145 
     146[[Image(fsd_model.png, center, 600px)]] 
     147 
     148The 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. 
     149 
     150{{{ 
     151#!cpp 
     152typedef std::tuple<std::vector<MCU_BLOCK>, std::vector<EdgeStrength>> SusanUsanOutputType; 
     153typedef std::tuple<std::vector<MCU_BLOCK>, std::vector<EdgeStrength>, std::vector<EdgeDirection>> SusanDirectionOutputType; 
     154typedef std::tuple<std::vector<MCU_BLOCK>, std::vector<EdgeDirection>> SusanThinOutputType; 
     155 
     156DEFINE_SIGNAL_TYPE(SusanUsanOutputType) 
     157DEFINE_SIGNAL_TYPE(SusanDirectionOutputType) 
     158DEFINE_SIGNAL_TYPE(SusanThinOutputType) 
     159 
     160DEFINE_STRUCT_TYPE(MCU_BLOCK) {} 
     161DEFINE_STRUCT_TYPE(EdgeStrength) {} 
     162DEFINE_STRUCT_TYPE(EdgeDirection) {} 
     163 
     164... 
     165 
     166void direction_func(std::vector<SusanDirectionOutputType> &out, const std::vector<MCU_BLOCK> &inp1, const std::vector<EdgeStrength> &inp2) { 
     167        out = V(1, T(C(1, MCU_BLOCK), C(1, EdgeStrength), C(1, EdgeDirection))); 
     168         
     169        FLATTEN_INPUTS(inp1, inp2); 
     170        FLATTEN_OUTPUTS(out); 
     171 
     172#pragma ForSyDe begin direction_func 
     173 
     174        susanDirection(&I(0, 0), &I(1, 0), &O(0, 0), &O(1, 0), &O(2, 0)); 
     175 
     176#pragma ForSyDe end 
     177} 
     178 
     179}}} 
     180 
     181The 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.  
     182 
     183With 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. 
     184 
     185[[Image(fsd_model_flattened.png, center, 600px)]] 
     186 
     187The flow continues with the conversion of the process network into the SDF graph shown below. 
     188 
     189[[Image(fsd_model_converted.png, center, 600px)]]