Software-to-hardware conversion: automating the ...

604

SOFTWARE-TO-HARDWARE CONVERSION: AUTOMATING THE PROCESS D.P. Noel, TA. Kwasniewski and A. Castongury Department of Electronics, Carleton University W.P. Leblanc and SA.Mahmoud Department of Systems and Computer Engineering Carleton University, Ottawa, Canada synthcskr

Design automation has become an increasingly imporrant link in the development of integrated circuits. CADKAE systems have enabled designers to reduce the project time, errors and thereby cost The automation has been limited to development tools capable of emulating hardware, synthesizing the appropriate structures and performing the layout of these structurts and muting the interconneaions. Generally each tool operates independently while generating outputs that are not readily uscable by other CAD tools. The development of a process by which a design team may convert soffware to a hardware platform would enhance the available automated CADXAE tools.

for schematidnctlist generation. Simulations using the VHDL will “ hpotential errors in the next step. This step wiU be the generation of a physical device to complete the automation process. This final step may involve the production of an application specific integrated circuit or a field programmable gate m y .

The development of such an automated design process is proposed and will be verified by converting a standard algorithm for voice coding from sofhvam to hardwarc. several main features of this pmposal will be the ability of the designer to perform an acNatt feasibility study of the power and area requirements of the algorithm once implemented in hardware. The perfonnancc of the algorithm undcr the rrstriaion of hardware will also be verified before commitment to silicon.

Initially the research behind the automation methodology proposed was more VLSI for communication orientated than CAD for VLSI. The algorithm for a highly complex low rate speech coder had been developed by researchers at Carleton University [l]. Inquiries were made as to the feasibility of generating a low-powwcd, slngle chip device based on this algorithm for use in mobile radio, indoor wireless systems and possibly the personal communications seMce (PCS). Based on the complexity of this algorithm it was decided to first attempt to create an ASIC based on less complex, similar typc coders fccflltly standardized in the communications world. The CCIlT rtcommendation G.728[2] for implcnkenting a law-delay 16 kWs code excited linear predictive coder (LD-CELP) was chosen as an algorithm close to that developed in [l] but with reduced complexity.

1. Introduction

2. DeveloDment Tools

Starting with a common software development language such as C, the designer must make minor modifications to the code to accommodate the restrictionsimposed by hardware. The software must be partitioned based on function (ie: correlation, recursion, etc.). The performance must be verified extensively at this stage. Partitioning of analog and digital circuitry, if required, may be optimized at this point. This software is then modified to accommodate fixed point arithmetic (if not already so). Once the fixed point version of s o h a r e is verified the conversion to a synthesizable VHDL is undertaken. This VHDL is then used by a

The design tools were chosen for the development process. Figure 1 illustrates the tools selected and how each is Linked into the design process. Comdisco’s Signal Processing Worksystem (SPW) with its Block Diagram Editor @DE) [3] was selected as the high level simulator. Synopsys [4] has been selected as the synthesis and VHDL simulation tool. The VHDL link is a manual process while the development of an automated Ccode-to-vKDL (synthesizable) interpreter is pending. There are several options for the hardware implementation tool. For the FPGA system the Motorola open architecture CAD system (OACS) [5 ] has

Authorized licensed use limited to: Carleton University. Downloaded on July 13, 2009 at 14:38 from IEEE Xplore. Restrictions apply.

605

been chosen as has a Motorola FPGA ttchnology. The Cadence Opus (formerly age) [6] place. and route package is utilized for the ASIC development utilizing the Northern Telecom CMOSQSpiocessing technology.

Thmugb the development and use of the custom aided blocks qresenting the original sofhvare the designer will quickly learn the optimum analog/digital partitioning of the circuit based on minimizing the hardware interference influences on the signal processing. Once the designer has verified the performance of the system, the code contained within the custom coded blocks is converted to MJDL. Note that at this point the designer may decide that the simulated performance of the system is not acceptable due to the of the hardware induced interference and conclude that a hardware! implementation is not feasible bascd on the chosen technology.

High-level Simulation

SPW Custom Coding

4 C to VHDL Conversion

r

Circuit Level Simulation

SPW will generate VHDL for the designer if

Synopsis

the custom coded blocks are converted from code to the SPW basic building blocks. This process can be very

Cadence opus

I

4 Fabrication

it is decided to partition the algorithm with both analog (to minimize area) and digital circuitry (to minimize power consumption). An optimal partitioning of analog and digital components will optimize the overall area rcquiremcnts and power consumption of the resultant integra!ul circuit.

Motorola OACS J

14

J

I

Development FPGA

~

Figure 1:Software-to-Hardware Conversion

SPW provides a graphical interfact to a highlevel simulator representation of a designed system. Standard SPW models exist for most commonly used hardware building blocks and system designs (ie:adders, multipliers and communications /radar systems). Using the graphical interface custom coded blocks may be created and the designer‘s original code modified to create a SPW model of its function. The designer must functionally partition the original software. A block diagram of each functional module is created and the software associated with this module is linked to it. The blocks may be developed to function with either fixed or floating point values to simulate digitavanalogcircuitry. The inclusion of noise and technology related interference models may be made once the developed simulation system has been verified against the original code. The noise model will depend upon digtal or analog circuits. Both types of models will be present if

tedious and time consuming not to mention increasing the probability of errors. The proposed development of a Cde-to-VHDL converter or the manual conversion of C codc to VHDL would be more suitable than using the SPW VHDL generation scheme. This step is at present a major impediment to the development process. Synopsys has been chosen as the logic synthesizer. This package will use the VHDL input to generate a schematic representation of the algorithm. This schematic may be larger than requid if the VHDL conversion in the previous step had not been optimized. Once the designer has synthesized a schematic from VHDL it should be checked thoroughly. In the C to VHDL conversion process any variable assignment transferred directly to the VHDL will result in unnecessary hardware for intermediate storage of these values. This will be the most common problem in the conversion and is easily eliminated. The Synopsys synthesis tool will also permit the designer to run simulations using the synthesized schematic. This simulation must not include the noise andor interference models as used with the SPW simulation. Synopsys utilizes the models of the standard cells contained in its database for the simulation. The performance of the system should be verified again at this level to ensure that designer induced errors have not been introduced. As with the SPW simulation the designer may perform several iterations of the


606

simulation changing key ofthesystcmto a p t i m i Z c ~ and 0 ~to lninhh tbt adpower COMllllptiOEL

The designer is now at apoint to proceed with FPGA or ASIC development or to halt the pnrccss. Tbe gcntrationoftheFPGA at this point will be technology dcpeDdantand will mostlilrelybeposriblefbronlyafW digital implcmartatl'on. Ifthcpowcrquhanmtsand areaeaimatd provided by synopsys are too great for the desiredlhl product it would not k feasible to

pmccedtohardware. The OACS system is one of Motorola's ASIC development tools. It uses a Synopsys genaatcd nctlist to first generate a Motorola formatted EDIF nctlist. Using this netlist the layout timing information for the proctssing technology (it may be any of the Motorola processing technologies but the FPGA data is ofintcmst hat) is added and a Motorola design netlist is genmkd. This is passed to the OACS layout and routing tools for the developmtnt d a FPGA programming file. The OACS system will permit the designer to optimize the placement of the previously partitioned (in the SPW systcm) modules as well as the routing between modules. With the appropriate p

r

o

~ equipment ~ g

consumption estimates based on the proassing technology and the indicated placement and routing. Based on this i n f o d o n the design may be traaslated to the appropriate system for fabrication. 3. ADDliCttiOII to Sirma1Processine of Soeecb

As mentioned in the intduction a CCI" standard (LD-CELP) was usedas a tcst ofthe proposed conversion and verification process. The goal of this txcrcisc was to test the wnvcrsiodvdication metbodoiogy while dttcnnining the feasibility of implementing the LD-CELP algorithm in hardware. The algorithm detailed by standard G.728 had been programmed in ANSI-C for experimentation. Further research lead to the optimization of portions of the algorithm and C a d e to reduce the computational complexity while mainraining the integrity ofthc algorithm [7]. As the end product would btahardware device further modifications were made to the C code to remove portions ofthe original code which might cause problems in the later hardware implementation. An attempt was made to eliminate any mathematical division from the software. In hardware the mathematical function of division is expensive in terms of complexity and chip real estate thereby increasing die size and power consumption.

the original software may now be implemented in hardware and thoroughly tested. Any crron/p"s may be corrected by looping back into the dewelopment process (SPW, Synopsys, or OACS) to change the appropriate software andor syntheskd hardware. Area requirements and power consumption may d y be verifxd fkom the FPGA device.

If the designer is satisfied with the h a l FPGA design, the commitment to silicon is the final step. The overall circuit area requirement may be reduced by proceeding to silicon as there is the possibility of auny unused gates within the FPGA. This might also serve to further reduce the power requirements. The Cadence OPUS system is atlother tool for use in placement and routing of ASICs. OPUS uses the Synopsys generated netlist to generate its own schematic

representation of the hardware. From there it will perform an automatic placemat of the modules and the associated routing. The tool may be assisted in placement by the designer indicating preference of module placement.

As with the OACS system, OPUS will allow the designer to determine the a m and power

The next task of the s o h a r e conversion was the preparation for integration into the SPW system. The C-code modules were originally written based on extensive memory allocation and pointer structures. Each module made access to both global constants and global memory. As stand alone models of each module were desired, each module was converted to function with its own constants and memory arrays. Once completed, pictorial representations were generated in the SPW system and the respective (converted) C-code linked to the appropriate SPW representations. Simulations were preformed on this SPW version of using the exact input structures as used with the original Ccode. Output files generated by the SPW simulator were compared to the C d e output files.The optimum conversion to the SPW models was confirmed. With this functional simulator verified, the algorithm could be easily modified and vefied without much additional effort. An optimum version of the coder could be easily determined through such a process. The original C code was written using floating point arithmetic. Models using this format would be representative of analog hardware. As reduced power consumption is essential a digital implementation would


607

be preferred. A digital implementation would be performal using a CMOS processing technology ( N o m Telecom's CMOS4S process in this case). CMOS has the characteristic of only consuming power while changing logic states. The desire to fabricate in CMOS quires converting the mathematics to fixed point. Further simulation will verify the conversion fiom floating point to &xed point. As the coding algorithm would not have changed at this point performing the same simulations as for floating point math and evaluating the outputs would c o n f i ~tbe ~ conversion. The output (reconsttucted speech) should be of the samc quality. To simulate realistic onchip conditions the appropriate noise models and hardware dependent interference models were researched and included in the SPW simulations. Noise will affect digital and analog circuits in different ways. It is very important to d l the noise in the circuitry as accurately as possible. Improperly simulated hardware injected noise will result in poor performancc of the hardware once fabricated. As the simulations witb injected noise and interference will not create output files the same as the original sofhwuc other means of verifying the performance were devised Once satisfied by the performance generated by the SPW modelling, hardware synthesis began. Because of the complexity of the algorithm (even though it was considered comparatively simple) the conversion to VHDL via the SPW basic building blocks was not pursued. The SPW C a d e is used to manually generate VHDL code. VHDL synthesis code is then transported to S y n o m where it is used to synthesize a schematic. It was noted that several modules wcre much more complex than others and efforts are being made to reduce this. At that time the synthesis will be completed and further simulated using the hardware models of Synopsys. Proceeding to either a FPGA or an ASIC will be fairly straight forward once simulations are verified. For the generation of an application specific integrated circuit (ASIC) the Cadence Opus (Edge) system will be used. The CMOS4S standard cell library was slated as the fabrication technology. To permit the automated placement and routing of the integrated circuit the CMOS4S library in Cadence was manipulated and translated to a Synopsis database. This database creation, when linked to the Synopsis synthesizer will permit the netlist, as generated by the synthesis of the hardware representation, to be directly translated to the Cadence environment. The synthesized schematic netlist is used by the Cadence Edge

environment to generate the chip layout. 4. Results and Conclusions

To aid in the transfix of speech coding algorithms into hard(a chip) several simulators and synthesizers were uscd. Mom importantly a methodology for rapidly converting a speech coding softwale algorithm into hardware is dwiscd. This methodology allows multiple versions of an algorithm to be adapted for hardware simulation before actually deciding upon the optimal hardware implementation. Once completed any speech coding algorithm could be exercised in hardware through the use of the conversion and testing methodology. 5. References

[11 W.P.Leblanc, "Speech Coding at Low to Medium Bit

Rates",Ph.D. Thesis, Department of Systems and Computer Engineering, Faculty of EngineeMg, Carleton University, Ottawa,Ontario, Canada,1992 [2] CCIlT Recommendation G.728, 16 kWs Voice Coding [3] Signal Processing Worksystem User Manual, Comdisco Systems,Inc., 919 E.Hillsdale Blvd, Foster City, California,94404 [4] Synopsys User Manual, Synopsys, Inc.,700 Middlefield Road, Mountain View, California 940434033 [5] Open Architecture CAD System User Manual, Logic and Analog Technologies Group, Application Specific Integrated Circuits Division, Advanced product Operations/Design Automation, Motorola, Chandler, Arizona, US, 1993 [6] Cadence Opus User Manual, Cadence Design Systems, Inc., 555 River Oaks Parkway, San Jose, California 95134

[7]W.P.Leblanc and S.A.Mahmoud, "Low complexity, low delay speech coding for indoor wireless communication", IEEE Vehicular Technology Conference, Stockholm, Sweden, 1994
