An Automatic Approach to Generate Haste Code from Simulink ...

generated by CodeSimulink, in order to keep consistencybetween the simulation performed at the highest level andthe one used at lower levels.This environment has already been extended to the asynchronouscircuit domain [13], but this work done wasfocused on FPGA development, therefore lacking supportfor the back-ends used in ASIC development. To overcomethis limitation, we used the TiDE flow offered by HandshakeSolutions, which is introduced in the next section.3.2. TiDE FlowThe Timeless Design Environment (TiDE) [14] is a setof tools, provided by Handshake Solutions, that can maphardware descriptions onto a self-timed gate-level netlist,starting from the Haste language. Haste [15] is a high-levelbehavioral language that supports asynchronous communicationusing CSP [16] constructs.Values can be communicated between parallel processesusing channels. Channels are objects on which read andwrite operations are “synchronized,”. So a process that writeson a channel can only complete its communication when thecorresponding reader has read the data.The standard design flow based on TiDE (see Fig. 2) startswith the system description in Haste. This description isconverted by the Haste compiler (htcomp) into a behavioraldescription that can be used to perform functional simulationand can then be mapped onto the desired technology (usinghtmap).Using the tool htlink external Verilog netlists can belinked to the netlist generated from Haste. After this operationthe obtained netlist is optimized and adapted for theback-end part of the flow. (For further details on this, pleaserefer to the TiDE manual [14]).There were several reasons why we chose to integrateCodeSimulink and TiDE:• CodeSimulink can convert Simulink models intoVHDL, but it lacks an ASIC back-end;• Haste is a powerful language which allows you toeasily describe asynchronous circuits using its nativeconstructs;• TiDE can synthesize both RTL code and Haste together.By integrating these two environments we can cover thedesign process from high-level modeling and simulation tothe physical implementation.4. Preliminary AnalysisIn this section we describe some considerations madeduring the implementation of Simulink diagrams in Haste.They are related to the Haste language itself and to thecharacteristics of Simulink.Haste descriptionSynthesis (htcomp)Handshake CircuitsMapping (htmap)Verilog NetlistLinking (htlink)Logical Optimization (htlog)ABSBack−End16163External VerilogNetlistsFigure 2. TiDE flow.*+>x32Behavioral Simulation(htview)Netlist VerificationFigure 3. Small design used to test different coding styles inHaste.4.1. Haste Coding StyleHaste relies on a transparent compiler. This means thatyou will get what you described, and for this reason it isnecessary to take care of the coding styles used in orderto get the most efficient implementation of the design. Tocompare different coding styles, we developed a set of smallmodels. One of these models is depicted in Fig. 3 andrepresents a simple datapath of 6 different operations on twoinputs which can be selected from another input. Althoughthe model is small, it includes several computational blocksthat are often used in Simulink diagrams to describe morecomplex systems.4.1.1. Communication. To pass data between modules wecan use two different modes: shared variables or channelcommunications.The implementation of shared variables is relatively32O3

Table 2. Comparisons among different block using channels,shared variables, with state or without state implementation.(These results refer to a different implementation of thedesign depicted in Fig. 3 and are in number of gates.)Implementation choices Area [µm 2 ]Registers Channels Variables Memory C-gates TotalX X - 15857.6 1441.0 54829.1X - X 15857.6 490.6 54140.9- X - 0 1134.4 44470.9- - X 0 367.9 43683.8Table 3. Comparisons among different coding styles for thedesign depicted in Fig. 3.Design Tuple Registers Area [µm 2 ]Not Used Used Not Used Used Total/C-gatesX - - X 11454.9/4804.4Datapath- X - X 11883.8/4792.2X - X - 4067.3/438.3- X X - 3670.3/254.5cheap, but they require explicit synchronization betweenreaders and writers in order to avoid data miss and dataduplication, since registers are shared between the writerand the readers.Channels on the other hand automatically synchronizeinput and output actions of modules running in paralleland thereby guarantee a correct timing relationship betweenthe read and write actions. Their implementation is moreexpensive in terms of area than a shared variable (around1.5%, see Tab. 2 for further details). To keep the conversionof the Simulink model to Haste straightforward, we wouldlike to avoid explicit synchronization between modules.Therefore we choose to use channels instead of sharedvariables.A channel is a communication mechanism shared betweendifferent objects with at least one transmitter and at leastone receiver. The implementation of a channel relies on thebundled data approach. This implementation consists of adata part and a control part. The control part takes care ofthe communication protocol and the required delay matchingof the data part.The simplest way to describe the way the blocks communicatein a Simulink diagram is using separate channelsfor each input/output. This solution is straightforward toimplement, but it can be more expensive since every inputhas its own control logic.Haste allows the user to group together data channels,thereby sharing handshake control circuitry. Such a multipledatachannel is called tuple channel. This solution requiresless area. Deadlock can be introduced however due to theIo!IAi?v ; o! A(v)Bi?[[ao,io]]; o! B( ao, io )Figure 4. Example of a Simulink model that can lead to adeadlock (see Fig. 5)fact that all the input communications are synchronizedtogether, therefore not allowing individual completion.A typical example is the one depicted in Fig. 5: blockA needs to have a complete handshake on its inputs tocompute; block I needs to wait until all the blocks fed byits output have captured its value before continuing. Forthis reason, before concluding the communication with A, itneeds to wait for the completion of the communication withB. However, B cannot finish its communication with I untilit receives data from A and this can never happen, sinceA cannot compute until it finishes its input communicationwith I. So the system is stuck waiting for a condition thatwill never happen.4.1.2. Functions or Procedures. A module in Haste canbe described as a fully combinational block or as a blockwith registers (Fig. 6). Data-flow networks usually do notinclude stages (since data is processed from input to outputcontinuously). However, in order to to increase systemthroughput decoupling stages (i.e. registers or latches) canbe required. The results presented in Tab. 3 show a largedifference in terms of area for the two implementations. As adesign trade off exists between area and speed, it is possibleto choose the desired implementation.4.1.3. Register Placement. As previously mentioned, Simulinkmodels do not have the concept of registers as is usualin digital design. Most standard blocks perform operationsregardless of the concept of time. Only a few blocks arerelated to timing events. We will come back to these blockslater.Registers are necessary to achieve performance, but wehave to decide where to insert them. Since each Simulinkblock has only one output, whereas it can have more thanone input, it is natural to insert registers on the outputin order to optimize area. Using the Haste language it isdifficult to describe such an implementation, since when youget data from one or more input channels you have to storethem into registers, and this results in latching the inputs.In the present version of the TiDE flow (5.2) the compilerwill put registers where the designer has inserted them in theHaste description. In the future release (6.0), the compilercan optimize the number of registers automatically given therequired number of decoupling stages. For this reason weOi?v4

B: process( i0?chan [0..255]& i1?chan [0..255]& o?chan [0..255]).begin& ao : var [0..255]& io : var [0..255]|forever do( i0?ao || i1?io ); o! b( ao, io )odendo!IR1+A1+R1−A1−(a)i?v o!A(v) i?[[ao,io]] o!B(ao,io)R2+R1+A2+ A1+A2−(c)R1−A1−R2−R1+A1+R1−A1−B: process(& i?chan [0..255]& o!chan [0..255]).begin& ao : var [0..255]& io : var [0..255]|forever doi? [[ ao, io ]]; o! b( ao, io )odendR+Ra+(b)o!I i?v o!A(v) i?[[ao,io]]waiting forAb+R+Ra+ cannotbe generatedInput HS notyet completed(d)waiting forRa+o!B(ao,io)Figure 5. A valid Simulink-like diagram 4 can be described using separate input channels (a) or with a tupled input (b); thelatter can lead to a deadlock as we can see in the sequence diagram that describes its behavior (d), while the former workscorrectly (c).choose to use the more common way to describe modules(with input registers) and let the compiler decide where toput them.4.2. Sampling BlocksThere are three main blocks in Simulink that deal witha fixed sampling time: the “unit delay”, the “zero orderhold,” and the “rate transition” (Fig. 7). These blocks areoften used to change the input-to-output data rate of agiven function, especially when the system has to deal withinterfaces providing (or requiring) data at slower (or faster)data rates. Such blocks are also used when it is necessaryto explicitly insert a storage element in a design (e.g. for anaccumulator).The “unit delay” block acts as a memory element, whichcan also oversample the input data in order to increase theoutput data rate. The “zero order hold” block can reducethe output data rate. Finally the “rate transition” block is asuper set of the previous one. There are also other blocks(like Buffer and Unbuffer) that are not taken into accountnow, since these are used less frequently than the previouslycited ones.These blocks are often used in Simulink diagrams for twomain purposes:• introducing an explicit storage element in a design (e.g.an accumulator, a decoupling register in loops, . . . );• an adaptation to different rates in multi-rated systems(e.g. high-speed ADC or DAC interfaced with lowerspeed circuitry or vice versa).In the synchronous implementation, these blocks need toboth sample and generate data at a given time, accordingto their parameters (input and output sampling time) toguarantee the same behavior of the Simulink model. Alsoin the asynchronous version we need the same behavior andthis can be achieved in two different ways:• to introduce, in each of these blocks, a clock signalwhich can be used to derive the desired timing relationships;• to move the clock interface only to the input blocks,5

& sum2 = func (& A ? var [255..0]& B ? var [255..0]): [511:0].( A + B ) fit [511..0](a)& sum2 = proc (& A ? chan [255..0]& B ? chan [255..0]& Y ! chan [511..0]).begin& a : var [255..0]& b : var [255..0]|forever do( A?a || B?b ); Y ! (a+b) fit [511..0]odend(b)Figure 6. Examples of fully combinational logic (a) and logicwith registers (b).1zUnit Delay(a)Zero−OrderHold(b)Rate TransitionFigure 7. Simulink blocks related to signal sampling: UnitDelay (a), Zero-Order Hold (b), and Rate Transition (c).after which the following sampling block will just haveto up-sample (or to down-sample) the incoming data,which was already synchronized.Since the first solution introduces much interaction withthe clock, it will result in more area overhead, whereasthe second one maintains clock interactions only on theboundary of the system. For this reason we prefer the latterchoice, even though both options are available and can begenerated from the same model automatically.5. Simulink to Haste Conversion5.1. Proposed FlowOur aim is to integrate TiDE and CodeSimulink togetherin order to automatically synthesize Simulink models withoutdescribing them in Haste by hand. Fig. 8 depicts theproposed integrated tool flow.Input to this flow is a description of the desired algorithmin Simulink, using either pure Simulink blocks or(c)CodeSimulink blocks (from the CodeSimulink libraries). Atthis level of abstraction both simulation and architecturalexploration are well supported with a fast design-evaluationloop. In particular this support is based on the Simulinkenvironment being very suitable for dataflow design (e.g.filters, streaming data processing, control systems, . . . ) andthe availability of simulation libraries which help in evaluatingsystem’s behavior (e.g. with respect to the numberof bits used in the implementation of each block, theusage of integer, fixed point or floating point representation,the presence of signed or unsigned numbers, . . . ). Thesechoices can be modified at Simulink level and they affectthe simulation, providing the designer with a powerful wayto evaluate (manually or with user developed scripts) theoptimal implementation for each block. All these parametersare fully tunable and accessible to the designer who caneasily find the best trade-off between circuit complexityand accuracy required by the system under development.In case of using pure Simulink blocks, a script can convertsuch model into a CodeSimulink-compliant one, introducingall the hardware-specific parameters necessary for ourenvironment in order to simulate and synthesize the desiredhardware. If specified, during this conversion step our scriptscan automatically estimate the best characteristics of eachblock used in the design according to the simulation set inthe model.From this point CodeSimulink scripts will generate:• a Haste language file which describes the structurepresent in the Simulink model;• a list of all the library files needed for the synthesis;• a set of VHDL files describing the functionality of eachblock in the model;• a set of Cadence RTL Compiler scripts which willinclude all the library files needed and will generatefrom them a synthesizable Verilog version in order toinclude them in the standard TiDE flow.With these files the standard TiDE flow can start, so wecan first use htcomp and htmap to generate the Verilognetlist implementing the system structure after which we cansynthesize all the RTL VHDL files into gate-level Verilogones and finally link them together. After this part theTiDE back-end flow can continue optimizing the design andperforming the timing analysis necessary to insert the delaychains required in the control path.At the end of this process, the final netlist is availableand can be used to verify the system behavior at this levelof abstraction, a step necessary to also analyze systemperformance.In the next sections we describe how each block is convertedinto Haste and VHDL to allow automatic synthesis.6

Simulink ModelHDL CodeCodeSimulink Front−End FlowmodelConvertCodeSimulinkModelDigHwCompileFunctionalBlockProtocol ControllerHaste CodeFigure 9. Structure of a Simulink block described in Haste.RTimeless Design Environment FlowRTL VHDLRTL CompilerVerilog NetlisthtlinkTiDE FlowBack−EndHasteDescriptionhtcompHandshakeCircuitshtmapVerilog NetlistFigure 8. Proposed Simulink to Haste flow.5.2. Block StructureThe structure of a Simulink block implemented in Hastewill be the one depicted in Fig. 9. In that figure we can seehow the block can be divided into:• a functional circuit, which implements the combinationallogic function of the block;• a protocol controller, which coordinates all the operationswithin the block and describes the elements usedfor storage.The automatic conversion of Simulink models into Hasteand Verilog descriptions is based on the CodeSimulinkenvironment. Thanks to this we reuse all the things alreadydeveloped for such environment in order reduce both developmentand debug time.Each Simulink block is automatically converted into Hastecode (for controlling the data flows) and into Verilog code(for data elaboration). Haste is used to describe the topmodule and the communication infrastructure among blocks.The TiDE flow uses Haste as main specification language,but it is also possible to insert Verilog components, whereasCodeSimulink uses VHDL as specification language forits implementation. CodeSimulink uses a library-based approachin which each block has a parametric descriptionthat is called when needed in the top module. In order toreuse this extensive library we decided to use a commercialsynthesizer to convert its VHDL behavioral descriptions intogate-level Verilog netlists.The proposed flow merges the CodeSimulink and theTiDE one, as depicted in Fig. 8. We start from a Simulinkmodel (developed with pure Simulink blocks or with Code-Simulink ones), using the scripts developed such a modelis converted into Haste and Verilog, which are processeddifferently along the TiDE flow.In order to reuse the RTL libraries available in CodeSimulinkand to guarantee modularity and maintainability, eachblock is divided into different files. In this way the commonpart can be shared among blocks without having the burdenof rewriting code already existent. Each module is composedof:• a structure definition of the design, made of a singleHaste file;• a set of VHDL files, one for each block in the diagram,that describes the RTL behavior of the block;Not all the blocks will have this structure, since thereare interfaces with synchronous environments and samplingblocks that are quite different since their function is morerelated to the protocol than to the processing part (whichis usually not present). For this reason such blocks havecompletely been described in Haste. The following sectionsprovide details on these categories after having described thecommon parts:5.2.1. The Haste Shell. According to the ideas exposed inSec. 4 the skeleton on which a block will be built needs tointerface input data with the desired logic function and theresults returned by such logic function to the block output.Figure 10 shows the Haste shell structure for a two-inputsadder, as we can notice the structure is straightforward. Eachblock is represented by a Haste procedure in which each7

& sim_sum2 = proc (& Y1 ! chan VECTOR_17& A1 ? chan VECTOR_16& A2 ? chan VECTOR_16). begin& v_A1 : var VECTOR_16& v_A2 : var VECTOR_16| forever do// input acquisition( A1 ? v_A1 || A2 ? v_A2 )// output generation// (sim_sum2_f is imported); Y1 ! sim_sum2_f(.A1( v_A1 ), .A2( v_A2 ) )odendFigure 10. Haste shell for a 2-inputs adder.input and each output is listed as an input or an outputchannel respectively. In the body of the procedure onlythe interface operations are performed: inputs are read andoutputs are generated by the external function associated tothe block itself. Please mind the order of execution, indeedthe inputs are collected in parallel and obviously when allof them are available, the outputs can be generated.5.2.2. Sampling Blocks. Sampling blocks can have differentimplementations synchronized with a global clock, in orderto slow down the circuit operation (to make it operate ata certain Sampling Time) or completely asynchronous (seeSec. 4.2). In both modes the input data rate can differ fromthe output one. Using these blocks it is possible to make amulti-rate system in which the data rate is increased (usinga unit delay block) or decreased (using a zero orderhold block). Figure 11 shows the Haste description of suchblocks.5.2.3. RTL Processing Part / Parametric RTL Description.Each block has a set of parameters that can be configuredto make the module able to deal with different scenarios(serial or parallel input/output representation, different datawidth,. . . ) and all these parameters can be configured inthe VHDL description. For each block a HDL file will begenerated with all the desired parameters set and an RTLCompiler script that can synthesize it into a Verilog netlist.5.3. Simulink to CodeSimulink ConversionThe typical approach used to develop a design that shouldbe converted into hardware is to build a diagram using Code-Simulink blocks from the start. The advantage of startingwith CodeSimulink blocks instead of Simulink blocks isthat their simulation behavior matches that of their hardwareimplementation. Since the CodeSimulink block set is oneto-onecompatible with the standard Simulink one, we also& sim_ud = proc (& Y1 ! chan VECTOR_16& A1 ? chan VECTOR_16). begin& v_A1 : var VECTOR_16| forever do// output generation (oversampled)for 5 do ( Y1 ! v_A1 ) od// input acquisition; A1 ? v_A1odend(a)& sim_zoh = proc (& Y1 ! chan VECTOR_16& A1 ? chan VECTOR_16). begin& v_A1 : var VECTOR_16| forever do// input acquisitionfor 5 do ( A1 ? v_A1 ) od// output generation (undersampled); Y1 ! v_A1odend(b)Figure 11. Haste description of a “unit delay” 11(a) and ofa “zero order hold” 11(b) blocks both with a over- undersamplingratio of 5.provide a conversion utility which automatically converts apure Simulink model into a CodeSimulink one by settingthe parameters needed for the implementation according tothe simulation results of the model.5.4. System DescriptionNow that we have introduced the structure of each blockin the design, we will explain how the whole system isdescribed.The main Haste file is composed of different sections (SeeFig. 12):• the definition of the types used across the design;• the definition of the system interface;• the external RTL functions import;• the Haste declaration of each block;• the block instance and connection.6. Case Study: a Commercial Audio CODECTo test our methodology we apply it to a Simulink modelof a commercial Audio CODEC. Such a model describes oneof the two channels in a stereo audio chip implementing aSigma-Delta modulator [17].8

& VECTOR_16& VECTOR_17& VECTOR_32= type [0..2ˆ16-1]= type [0..2ˆ17-1]= type [0..2ˆ32-1]Table 4. Synthesis result comparisons of the same Simulinkmodel in different implementations. The designs have beenimplemented using a 180nm technology library.& datapath = main proc (& O ! chan VECTOR_32& A ? chan VECTOR_16& B ? chan VECTOR_16).begin// Internal channel declaration& Y1_6 : chan VECTOR_16 broad// ...// External function declaration& Sum = func (& A1 ? var VECTOR_16& A2 ? var VECTOR_16): VECTOR_16. import// ...// Haste shell description of each block& Sum_sh = proc (& Y1 ! chan VECTOR_17& A1 ? chan VECTOR_16& A2 ? chan VECTOR_16).begin& v_A1 : var VECTOR_16 := 0& v_A2 : var VECTOR_16 := 0|forever do( A1 ? v_A1 || A2 ? v_A2 ); Y1 ! Sum( .A1(v_A1), .A2(v_A2))odend// ...|// Block instance and connection// ...|| Sum_sh ( .Y1( Y1_6 ),.A1( Y1_8 ), .A2( Y1_3 ))// ...endFigure 12. Example of the Haste code generated for the mainprocedure.This model is quite complex, since it is composed of about150 blocks, including: about 30 16-bit wide multiplicationby constant values, 15 8-bit wide multipliers, and 30 16-bit wide adders. It has been used to develop a hand-writtenimplementation in Haste. Thanks to the collaboration withan industrial partner we had access to synthesis resultsof this asynchronous hand-written version and we couldcompare this with the Haste version generated by our tool.Comparisons for both versions are based on optimized prelayoutnetlists mapped onto the same technology library.The results of this analysis are reported in Tab. 4. Inthis table we compare the hand written Haste code withtwo versions of the automatically generated one: the first isDesign Hand written Automatic GeneratedTool TiDE 5.2 TiDE 5.2 TiDE 6.0Sequentialµm 2 32018 89792 11632Logic 138244 357368 152468Totalµm 2 173694 468746 164100Overhead — +170% -5.5%Coding time about 1 week 20 minutespassed through version 5.2 of TiDE flow, while the secondhas been processed with the new pre-release version (6.0).Unfortunately it was not possible to compile hand-writtenversion with the TiDE 6.0 flow, since it does not supportanymore some low level constructs available in the oldrelease. We can notice a number of differences between thethree versions proposed. The designs are not architecturallythe same, since the number of registers is not the same inall of them. This is due to the code generated (or written):• for the hand-written code, most of the blocks in theSimulink model have been implemented using Hastefunctions [15]. The number of blocks for which thedesigner decided to insert registers is small comparedto the total number of blocks.• for the TiDE 5.2 version, each block has registers onits inputs, which results in a high overhead, since manyof them are not required.• for the TiDE 6.0 version, the compiler automaticallydecides the minimum number of registers required forthe described circuit.For the reasons above, we can conclude that at the momentthe code generated automatically and compiled with theTiDE 6.0 version represents the lower bound with respect tothe number of registers. On the other hand the same designcompiled with the 5.2 version is the upper bound, since thegranularity at the Simulink level is very fine-grained.Since our work was targeted for the TiDE 6.0 version,the results shown in Tab. 4 are promising. The achievedimplementation based on this new flow 2 requires less areathan the hand-written counterpart.In order to guarantee the circuit equivalence, we simulatethe netlist generated from TiDE 5.2 of the hand-writtencode and the automatically generated one with the sametest bench. Since we had not access to the testbenchesused to develop the original version, we had to create anew tesbench based on the data streams derived from theSimulink simulation. Because we are still working on afeature which generates input patterns directly from the2. At the moment TiDE 6.0 is not complete; indeed some operationshave to be performed by hand, but the optimizations performed by the toolare stable and will not change significantly with the official tool release.9

Simulink environment, we had to do the verification partiallyby hand. The result of this analysis demonstrates thefunctional equivalence of the two circuits (with respect tothe simulation performed).Results shown do not include any figure on timings.Actually we had not access to this data for the hand-writtenversion. The only timing constraint we had was to be ableto process all the samples provided at a given data rate, andthis was easily achieved by the automatic generated codecompiled with both TiDE flows.7. Conclusions and Future WorkThis paper has shown how we address a complete flowfor generating asynchronous circuits starting from Simulinkdiagrams, using Haste as intermediate description language.At the moment only a subset of Simulink blocks aresupported, but the methodology can easily be extended inorder to cover all blocks. Our proposal has been used on acommercial model of an audio CODEC, showing appealingadvantages (code reuse, time-to-market reduction) withoutarea overhead introduction.Obviously a number of optimizations and improvementscan be added:• high-level optimizations, like block merging, in order toreduce the number of asynchronous controllers insertedin the circuit;• an integration between the Simulink and the RTL simulation,in order to have the same test set for both theabstraction levels and, consequently, reduce the testingphase;• a way to automatically select where to insert pipelinestages in the design.We are looking forward to all these optimizations since theycan further reduce area overhead and development time.Moreover we are working to use different methodologiesexposed here, in [8] and in [13] in order to compare whichone can produce better results.8. AcknowledgmentWe would like to thank Luciano Lavagno who helped usduring the writing phase of this paper with remarks andsuggestions.References[1] E. A. Lee, S. Neuendorffer, and M. J. Wirthlin, “Actororienteddesign of embedded hardware and software systems,”Journal of Circuits, Systems, and Computers, 2002.[2] W. Wong, “Model-Based Design,” ElectronicDesign, March 2006. [Online]. Available:http://electronicdesign.com/Files/29/12086/12086 01.pdf[3] A. Taubin, J. Cortadella, and L. Lavagno, Design AutomationOf Real-Life Asynchronous Devices And Systems. UnitedStates: Now Publishers Inc, 2007.[4] C. Van Berkel, M. Josephs, and S. Nowick, “Scanning thetechnology: Applications of asynchronous circuits,” Proceedingsof the IEEE, vol. 87, no. 2, February 1999.[5] The Mathwork’s. Simulink on-line documentation. [Online].Available: http://www.mathworks.com/products/simulink/[6] Xilinx. System generator. [Online]. Available:http://www.xilinx.com/ise/optional prod/system generator.htm[7] Altera. DSP-Builder. [Online]. Available:http://www.altera.com/products/software/products/dsp/dspbuilder.html[8] The Mathworks. HDL-Coder. [Online]. Available:http://www.mathworks.com/products/slhdlcoder/[9] E. A. Lee and D. G. Messerschmitt, “Dataflow processnetwork,” Proceedings of the IEEE, vol. 83, no. 5, May 1995.[10] L. Reyneri, F. Cucinotta, A. Serra, and L. Lavagno, “Ahardware/software co-design flow and ip library based onsimulink,” DAC, June 2001.[11] E. Bellei, E. Bussolino, F. Gregoretti, L. Mari, F. Renga, andL. Reyneri, “Simulink-based codesing and cosimulation ofa common-rail injector test bench,” Journal on Computer,Systems and Circuits, vol. 12, pp. 171–202, 2003.[12] I. E. Sutherland, “Micropipelines,” Communications of theACM, vol. 32, no. 6, june 1989.[13] M. Tranchero and L. Reyneri, “Automatic generation of selftimedcircuits from simulink specifications,” InternationalConference on Electronics, Circuits and Systems, December2007.[14] TiDE Manual, Internal documentation, Handshake Solutions,2007.[15] A. Peeters and M. de Wit, Haste Manual,Handshake Solutions, 2007. [Online]. Available:http://www.handshakesolutions.com[16] C. Hoare, “Communicating sequential processes,” Communicationsof the ACM, vol. 21, pp. 666–677, 1978.[17] P. Allen and D. Holberg, CMOS Analog Circuits Design.New York: Oxford University Press, 2002.10