Power dissipation of current low-power embedded MCUs still remains orders of magnitude too high for many potential applications of WSN (Wireless Sensor Network). We believe that hardware specialization is an interesting way to reduce the power consumption of WSN nodes. In short, instead of running the application/OS tasks on a programmable processor, we propose to generate an application specific micro-architecture, tailored to each task of the application at hand.
We call these application specific micro-architectures hardware micro-tasks. A micro-task can be seen as a small datapath micro-architecture, driven by a control FSM that sequence/executes the micro-code corresponding to the task at hand. It is therefore not programmable, in the general sense.
We implemented a full flow to generate a VHDL representation of such a micro-task from C Level specifications, this page provides a short tutorial to use our flow.
The following PDF files contain the installation details and some user guide lines for exploiting LoMiTa design-flow:
Here is a sample C file that has been processed to generate its corresponding micro-task:
Open the Gecos script file, called benchmarks.cs present in fr.irisa.cairn.wsn.benchmarks/benchmarks/
There are several Gecos front-end passes (that you would be already familiar with), like RemoveCSpecific, ConstantPropagator, removeArray, FlattenScope etc.
We will talk about the back-end passes (highlihted in the above figure) that have been written to generate the assembly and VHDL descriptions for an application code using an unconstrained set of instruction-patterns. These passes are discussed below:
We use a specialized code selector pass MemRegMIPSCodeSelector that has been written to perform the code selection for direct memory-operand-based instructions. It also generates an assembly code that has typed-register information. The BURG-description file (mini-mips-reduced.brg) used for instruction selection looks like this:
Here you can see that the rules written to generate assembly instruction can involve direct memory operands (the indir type of variables).
A sample assembly code output has been shown in the following snapshot where we can see the highlighted typed assembly instructions:
These are the two passes used to convert the 32-bit and 16-bit wordlength instructions to multiple byte or short-level instructions. The output of LI2S has been shown in the following snapshot that converts all the Long-type instructions to series of short-level instructions. These passes can be found in software/pasha/updated_passes/hardwareTask/fr.irisa.cairn.hardwaretask.generic/ repository present at Loparsenno's SVN.
The source code of the LongInt2Short pass is shown in the figure below, it iterates all the instructions of a procedure and converts them appropriately to a set of short-level instructions. As an example, the highlighted piece of code converts a shriL instruction (involving an immediate shift right by one place of a long-level operand) to two shr instructions each having a short-level operand.
The output assembly code of the LI2S pass is shown in the figure below, where we can see that the movLL instruction has been converted into two mov instructions each having a 16-bit operand instead of a 32-bit operand of the original instruction.
This pass interlinks the assembly-level data-structure of Gecos with the Datapath EMF-model and generates the corresponding datapath model which until now consists of only the FSM part. This pass can be found in software/pasha/updated_passes/hardwareTask/fr.irisa.cairn.hardwaretask.example/ repository present at Loparsenno's SVN.
The source code of the GecosFSMBuilder pass is shown in the figure below:
It generates the object of HTDatapath class, that in turns generates the FSM type object of HTUserFSMFactory class. The HTUserFSMFactory is basically the class that is used to convert the Gecos assembly level data-structure to the Datapath EMF-Model data-structure. Some glimpses of these classes are shown in the snapshots below:
The name tells everything … This pass is used to generate an XML description of the datapath-model. These descriptions can be found in fr.irisa.cairn.wsn.benchmarks/benchmarks/models directory.
Similarly, this pass is used to generate an VHDL description of the datapath-model. These descriptions can be found in fr.irisa.cairn.wsn.benchmarks/benchmarks/models directory. Several examples of VHDL codes generated for micro-task FSM can be found in the same directory. Here is an example: crc16.vhd.tar.gz
The snapshot below shows the details of the GecosFSMD2VHDL class, where the DatapathVHDLGenerator class is used to generate the VHDL description of the Datapath EMF model created by the GecosFSMBuilder.
Steven Derrien has developed a DSL for describing small controllers, the details can be found at Sequencer DSL
We generated an intermediate pass, called SequencerBuilder, that extracts a DSL-specific output file using the Gecos assembly-level data-structure. An example including this pass in the main Gecos script file is shown below:
The SequencerBuilder pass is available in software/pasha/updated_passes/hardwareTask/fr.irisa.cairn.hardwaretask.generic/ at the SVN of Loparsenno. The following snapshot shows an extract of this pass.
The pass basically iterates the Gecos assembly-level instructions and generates the DSL-specific XText output file with an .fsmseq extension. Then the DSL-based passes written by Steven convert this textual description of FSM into graphical (Dotty) and hardware (VHDL) descriptions.