A Mixed-Signal System-on-Chip Audio Decoder Design for Education

Transcription

1 A Mixed-Signal System-on-Chip Audio Decoder Design for Education R. Koenig, A. Thomas, M. Kuehnle, J. Becker, E.Crocoll, M. Siegel <koenig, thomas, kuehnle, <e.crocoll, Abstract A good harware design requires both competent theoretical as well as practical knowledge in the areas of architecture specification and design. While the theoretical background is given in several lectures gaining practical knowledge is somewhat more difficult. To face this problem a laboratory has been established. Analog as well as digital hardware components have to be realized to build up a mixed-signal System-on-Chip (SoC) for audio decoding within this course. The goal of this laboratory is to make students familiar not only with practical aspects of Hardware/Software Codesign of embedded systems but also with the steps that have to be performed in a typical ASIC design flow. 1. Introduction The progress in modern integration technologies in the last few years and the increase of the applications demands afford more and more complex system designs. This trend will go on for at least the next decade. Due to Moore s Law the integration density gets doubled every two years and so does the complexity of the integrated systems by keeping the used chip area constant. Now, since reached potential in VLSI offers new ways to implement whole systems on one single die and reduce the costs for target devices new challenges raised in terms of development issues. The developer has to take new system aspects into account in terms of being able to design a completely integrated system. Beneath digital system components the designer has to consider analog design aspects as well. Due to cost saving analog HF front-ends or simply communication interfaces with analog parts are getting increasingly integrated on the same silicon die. The resulting physical effects of the digital domain on the analog circuits have to be taken into account otherwise the system won t work properly. Merely the composition of several components of different types to a whole system requires broad knowledge in systems engineering which covers the hardware topics as well as software issues. Therefore the designer has to be familiar with Hardware/Software codesign requirements to be able to meet the right design decisions. Thus at least a minimum expertise in software development is absolutely essential and should be taken into account in the education. Beyond all mentioned design aspects and issues there are still other challenges to be mastered. Established software programming languages are in most cases a well known instrument to build applications. Almost each student has some experiences with it. Unlikely to software programming, hardware description needs a new way of thinking and has to be mastered by gathering experience with hardware description languages. Therefore this aspect should be practiced in every laboratory to keep the students in touch and improve their abilities. Teaching System-on-Chip issues, it is also very important to learn the handling of design and verification tools. Several, mostly very expensive tools are available on the market, e.g. from Synopsys or Cadence, but not reachable for students. Usually, the first contact and first experiences are made during the master thesis, which is obviously far too late to assure a complete System-on- Chip educational degree. The required knowledge in this field is reaching from initial functional simulation over logic synthesis to layout design and post layout verification processes. This contribution introduces a new design laboratory that has been established in the course of a new program of study called System-on-Chip at the University of Karlsruhe (TH). This program includes several lectures considering chip design and CAD issues including digital as well as analog topics. The new laboratory is an opportunity for the students to make first experiences in designing a complete system including simulation, synthesis, layout design and software programming. The next chapter will give a short overview of the system used in our laboratory. Section three discusses the initial SoC implementation, software issues and FPGA prototyping. In section four the standard cell synthesis and layout design will be introduced and the analog design part follows up in section five. A conclusion rounds off this contribution in section six.

2 2. The Mixed-Signal SoC An Overview It has been decided that the concept of this laboratory will be based on the development of a Mixed-Signal System-on-Chip architecture realizing an audio decoder. This decision was made for two reasons. On the one hand it was intended to make the laboratory more attractive to the students by realizing a design which comes close to devices currently available on the market. Thus the students should be able to obtain an insight and a basic understanding of the efforts that have to be made to design such a device. One the other hand an architecture had to be found providing analog as well as digital aspects whereas the design s complexity had to be at such a level so that it could be realized within a three week half day laboratory. It appeared that the development of an audio decoder seems to be a good compromise, satisfying all the requirements mentioned above. An investigation was made to determine a codec that finally should be implemented on the architecture. Here it was important that the Codec itself was well documented. Only with the knowledge about all the details it is possible to realize a standard conform software implementation. The documentation also was necessary to identify all those parts of the application, which show computational intensive characteristics. Finally the OggVorbis Codec has been chosen for implementation. The Codec not only provides a very good sound quality it also is very well documented since it is an open source project and can thus be used without paying royalty fees. In advance a deeper analysis of the codec has been performed to evaluate critical parts of the application. Thereby it turned out that the Inverse Modified Discrete Cosinus Transformation (IMDCT) is the most demanding algorithm. From the hardware point of view it was clear, that the architecture would in general consist of a digital to analog converter including an audio amplifier and a microcontroller. Since a good knowledge of the Leon processor is available it successfully is used in several other laboratories as well as research projects at our institute [1] it was decided to use this processor as the main CPU of the SoC. Like the OggVorbis audio codec, the Leon processor is made available under the LGPL and thus free to use. The processor is developed by Gaisler Research [2], originally foreseen for space mission, but meanwhile used in a lot of embedded designs. The processor is compatible to the SPARC V8 instruction set and programmed in VHDL. The design is widely configurable and can simply be enhanced by further modules due to its open structure which is based on the AMBA AHB/APB [3] bus concept, developed by ARM. While the processor is very well suited to handle typical tasks of a microprocessor, it is less appropriate for handling algorithms which are typically dedicated to the DSP domain. Thus the processor itself is not able to decode audio codecs in real time. In order to still being able to handle such scenarios a module accelerating the IMDCT calculation had to be added. In principal an OggVorbis specific solution would have been sufficient. However a more general solution was envisaged, to keep the SoC design more flexible for future use. In general two possibilities exist for IMDCT hardware acceleration. As a first approach the IMDCT could be calculated performing a complex ifft. To keep such a structure generic regarding the size of the IMDCT and thus that of the ifft including the pre and post processing functions is quite complex. E.g., to compute a 960 point IMDCT as used in the AAC Codec of the DRM audio coding part, radix of 3, 4, and 5 would be required. Regarding the handling of the several stages and twiddle factors of the complex FFTs, the design would become too complex. At this point a much more interesting alternative seems to be the algorithms presented in [4]. The calculation performed to obtain a single spectral value from a set of values in the time domain - and vice versa is based on a recursive approach as depicted in figure 1. Figure 1. recursive structure to compute a single value in time from a set of spectral values To obtain a speedup of the IMDCT algorithm, a certain number of the recursive structures also called fingers in the following - can simply be foreseen on a chip to perform a parallel computation of an arbitrary number of time or spectral values. To calculate all the values required, the fingers operate in a time division manner. The control of the time multiplexing is thereby steered by a controller that is part of the implemented IMDCT unit. The controller can thereby be configured to handle an arbitrary IMDCT size which effectively is only limited by the size of the in- and output buffers for storing the time and spectral values. Thus the hardware architecture is very well suited to handle other IMDCT based audio codecs as well, e.g. MP3, AAC or AC-3. Compared to the FFT solution, the recursive version is of increased complexity. Nevertheless the much more simplified design as well as the support of an IMDCT of arbitrary size justifies the decision to use the recursive approach in the context of this laboratory.

3 The IMDCT unit is integrated into the SoC via the AHB and APB bus, see figure 2. The APB bus connection is used for configuration and control of the IMDCT unit. This task has to be performed rarely and the amount of data is limited, so that the APB is the first choice. In contrast the AHB is needed for DMA-like transfer of spectral and time values from and to the main memory, where the IMDCT unit has to act as master on the bus. This task is crucial for reaching real time performance and thus a high speed bus is needed. The analog part of the SoC is connected to the Leon processor via the APB. The performance of the bus is still sufficient so that the quality of the audio signal is not limited. 3. SoC implementation on FPGA Generally speaking, a good methodology in education is always to start with something touchable. For this reason, the decision has been made to commence this laboratory with the development of a SoC and its implementation on a FPGA platform. A XUPV2P board from Xilinx has been chosen for design prototyping. As already mentioned in the overview chapter, the SoC contains a microcontroller, its bus peripherals and a reconfigurable coprocessor module. The goal of this part of the course is to finally have the multimedia application running on the provided board. Therefore hardware and software has to be developed. Adaptations in VHDL of the processor and its peripherals, its synthesis and analysis are be done using the Xilinx ISE 7.1 Software - a complete FPGA development environment. The simulation containing waveform analysis will be done using Modelsim 6.1 from Modeltech. The intention is to raise the student s awareness of two main topics. On the one hand the students have to become familiar with the standard tool chain of FPGA design, including simulation, verification, debugging and synthesis. On the other hand it is important to provide an idea about the design methodologies for parallel systems nowadays, where the main design issues can be found in hardware software interfacing and synchronization. Future SoC designs will more and more export highly computational algorithms to dedicated hardware modules. These hardware software co-design strategies are studied within the SoC laboratory in practice. The system will be integrated on an FPGA as shown in figure 2. Starting from a software reference design, where the complete multimedia application is executed on the microcontroller, the traditional von Neumann idea is being recalled and illustrated. The student s first task is the extraction of the most computation intensive algorithm, the IMDCT, from software C-Code and its implementation in hardware (VHDL). Figure 2. SoC after co-processor integration A wrapper module that handles the LEON commands and the AMBA interfacing is provided to speed up the development. The students have therefore to open the wrapper module and to integrate the IMDCT algorithm into the wrapper using the Xilinx ISE tool. Thus they get in touch and explore the FPGA tools for the first time. They have to take into account that the algorithm has to be fixed point compliant. Further more memory modules are essential to intermediately store cosine values and to buffer data transfers through the busses. These are going to be designed with the help of the Xilinx core generator utility. So, the students learn how to instantiate template modules in their design. The newly developed IMDCT module has further to be connected to the existing LEON system, hence the AHB and APB bus configurations of the SoC have to be adapted by the students. Subsequently, the challenge is the modification of the driver in order to be able to communicate with the IMDCT module. This Software is also used for test purposes, i.e. it resembles the system s test bench. Therefore, the students have to explore the programming interface of the IMDCT wrapper module, which is its controller implemented as a FSM and its registers. Surely, debugging and verification will play a major role during the whole system design, particularly in terms of time consumption. Thus system simulation will follow now in the design flow. However, before a simulation can be launched, the hardware as well as the software have to be compiled. For hardware compilation, scripts are available, that can be executed in Modelsim. The software will be compiled by a gnu cross compiler for the Leon architecture. Finally, to top off the SoC development process, FPGA synthesis and a system analysis with respect to performance constraints will be accomplished. Here a critical path analysis has to be done, where the students have to countercheck in the simulation results of

4 Modelsim how the timing within their IMDCT implementation can be improved. This may result in the necessity of VHDL re-design. If the constraints are met, the FPGA has to be set up and the bit-file has to be synthesized and downloaded though a JTAG link. A RS232 connection serves as debugging and user interface. From there commands can be entered and finally the students can listen to their developed SoC, an OggVorbis decoder. As it can be seen, the first part of the laboratory tries to cover all aspects that are relevant for SoC architectures, interfaces and the corresponding design flow for FPGAs. Concluding, the students get a detailed insight and handle each step of the development process of state-of-the-art FPGA system design. documentation and have to perform an analysis of the IMDCT unit in order to generate a list of all those parts that need special treatment. Finally, not all the adjustments have to be made by the students; only the register file of the Leon processor has to be realized using the Leon documentation and the memory documentation of the technology provider. Afterwards the correct instantiation of the register files has to be verified by performing a test bench run under ModelSim. 4. SoC Realization using Standard Cells In contrast to an implementation using FPGAs, a standard cell based realization of the design requires much more user interaction as well as detailed knowledge of the individual steps of the design flow that have to be performed to create a fault free layout. While most of the EDA tools for FPGAs hide a lot of the design flow s complexity - a single mouse click in the XILINX ISE tool chain could be sufficient to obtain a FPGA configuration bit file an engineer performing a standard cell design has to be aware that the clock tree will not be generated automatically by the tool, he has to know that the clock tree synthesis is a critical step in the design flow that has to be performed manually, just to give a simple example. Thus the focus of this part of the lab lies on teaching the basic steps of a standard cell design. Therefore the students themselves have to perform the synthesis and layout of the SoC. It can be assumed that most of the students did not have access to state of the art design tools prior to this lab. Aditionally, using those tools for the first time is difficult as they are complex to handle and less self-explaining as one might be used to. Thus a detailed tutorial explaining each tool-step is given to the students to ensure that handling the tools does not lead to an unnecessary delay so that the students can concentrate on the main work flow. In addition scripts have been prepared that are used at critical steps of the design. This will reduce the risk of mistakes made by the students, saves time consuming iterations and thus allows for steady progress. As the first task towards synthesis and layout of the SoC the students have to port the design to the standard cell technology used. Often the students assume that a design is technology independent since it is written in VHDL or Verilog. So it is important to develop an understanding that shows that there are parts of a design that have to match with the under laying technology. Therefore the students have to read the Leon Figure 3. Steps of the layout process As soon as the testbench reports that all tests have been performed successfully, the students are ready to go for the next step, the generation of the SoC s netlist. Since it can not be expected, that someone who never made a synthesis before is able to write a compile script on its own, a set of scripts are available and are used in combination with the Design Vision tool of Synopsys. To ensure that the students make themselves familiar with the subject in detail, they have to analyze the scripts and write down their findings in the lab report. The design of the SoC is thereby very well suited to show several synthesis strategies. While the fingers which perform parts of the IMDCT in parallel, as is could be seen in figure 1, are instantiated several times from the same module, they are subject for a bottom up compile approach. Later on, a top down synthesis strategy will be used for generating the final netlist, including the Leon processor as well as the IMDCT unit where the already synthesized fingers are embedded as don t touch modules. This will lead to a simplified layout flow later on. However, the scripts do not cover all steps of a typical synthesis flow. So the critical path analysis as well as the generation of further timing and area reports have to be done by the students. Additional documentation like synthesis primers as well as lecture notes are accessible, so that the students are able to fulfil this task. When there

5 are no errors reported in the log files of the elaborate and synthesis phase, the functionality will have to be tested once more by a testbench run in ModelSim, now including more realistic timing information by using the sdf file generated during synthesis. To make the more accurate timing visible, the students have to show the differences of waveform snapshots from behavioural level and after synthesis with a good example. discussed whereas the outcome of the investigations has to be explained reasonably. Finally, when all steps of the layout process have successfully been passed, the design has to be checked for design rule violations. Also a Verilog netlist as well as the timing information have to be reported. Once more a simulation run is necessary, now including information about post place and route delay. A layout of the SoC, as it has been developed within our last lab, is shown in figure Full-Custom Analog Design Figure 4. Layout of the SoC In the last step the layout has to be created using the SoC Encounter tool of Cadence. Before the Verilog netlist is ready to be imported into Encounter, the students have to add the power pads to the top level of the netlist according to the given directions. Afterwards the students have to go through the complete design flow, as shown in figure 3. To prevent frustration - the tool is quite complex and there is no undo button to correct wrong input - the individual tasks that have to be done in order to fulfil a single step are once more described in detail. In addition the students are advised to save the design frequently, to have a save state to return to. Further more the core utilization is reduced to less than 65%. This has no impact on the design flow at all but reduces the tool time a lot, especially for the computation intensive parts of the flow as the placement, clock tree synthesis and the route process. To ensure that the learning targets are met, the students have to describe and document the steps that are performed in their own words. Thereby special focus lies on the timing behaviour of the design and its change during the layout process. For this purpose several end path slack diagrams have to be prepared before and after major steps in the design flow. The results will have to be The objectives of the analog design part of the project are to design and simulate a CMOS operational amplifier using the AMS-C035 process, to practice the layout of the amplifier and to perform DRC, extraction, LVS, and postlayout simulation, as well as to apply the amplifier in a low-pass filter and in an audio amplifier with low THD. This part of the lab is a "Bottom Up" or "Full-Custom Design" using cadence design tools. The digital to analog interface is a digital delta sigma modulator, which is not a part of this laboratory. The idea is to design analog standard cells for an automated placement. The intention is to give the students basic knowledge of analog circuit design specifically the design of a simple operational amplifier at low supply voltage levels. Students taking the course should already have basic theoretical knowledge in analog design. The specifications of the amplifier are listed in table 1. Supply Voltage 0 V, 3,3 V Load 5 pf, (8 Ω) DC Voltage Gain > 80 db Unity Gain Bandwidth >100 MHz Phase Margin > 45 Slew Rate > 100 V/µs THD < 1% Table 1: Amplifier Specifications The schedule of this part of the project is set during a 4-full-day period. This is not much time for a practical introduction to analog design, so it has been decided to prepare a fully guided description of all design steps. The students have to provide detailed hand design procedures and hand calculations for each step of the design. The results are further discussed with the students each day before the design task starts. The authors decided to write a text book with instructions to guide the students through all the tasks. Additional texts like chapter 6 of Allen-Holberg [5] and a Texas Instruments [6] application report should be used for the theoretical parts of the tasks. First the students have to run a cook-book like tutorial "Full-Custom Design with Cadence" to get familiar with

6 the needed analog environment design, simulation and layout tools of the Cadence Design Framework. The lab starts with a guided design of a folded cascode operational amplifier. The first task is the design of a single-stage differential amplifier. The students have to provide detailed hand calculations using the standard equations for gain and slew rate to get the drain currents and the parameters of the transistors. At this point the first analog design experience for all students starts. Drawing the schematics of the differential amplifier, doing the different dc, ac and transient simulations and discussing the results to find out how to improve gain, bandwidth or slew rate of the amplifier stage leads to usable results of all designs. Some students got quite ambitious to do the best possible design. The next step was to find out, how a biasing circuit works and how it has to be designed. After solving that part, the amplifier input stage should be expanded to a folded cascode stage to improve gain and bandwidth. After simulation and optimization the gain was still to low, so the students had to design a high gain output stage. They had to find out, by studying [5], that in this case, a CMOS output stage will be suitable to solve the problem. Finally the width of the transistors had to be calculated, to get the load current at the output of the amplifier. Another important part was to show that the frequency response and phase margin will meet the specifications. Figure 5 show one result of the amplifier design. The next step is the layout of the amplifier to design a standard cell that can be used for the following design steps. Because of very extensive layout rules for standard cell design and little time, it has been decided to cut this part of the lab for this first run and to continue with the next task, the filter design. The students had to design a 2nd order low pass filter applying the designed folded cascode amplifier. They had to choose whether to use a multiple feedback or Sallen Key architecture. Furthermore they had to check out which type of filter, Butterworth, Bessel or Chebyshev will fit best for audio signals. They also had to calculate the passive components for the chosen filter design. Some of the students found that Texas Instruments has a filter calculator ready for download on the web. The final design part was the audio amplifier. It must provide 250 mw output power for an 8 Ohm headphone. Some of the students already designed the output stage of the operational amplifier for that load, the other ones had to redesign the stage. The students had to select one of three different amplifier configurations used for audio signals: a single ended amplifier, a fully differential configuration and a bridge-tied load amplifier. They had to choose the bridge-tied load type and to check out how the amplifier had to be designed. Figure 5. Schematics of the final operational amplifier To ensure that the educational targets are met, the students have to describe the performed design steps and simulation results in own words writing a final report. 6. Conclusion This paper described the concept and the realization of a Mixed-Signal System-on-Chip laboratory applied to education. It allows students to gain experience and knowledge not only in practical digital and analog SoC design. Also the FPGA based realization of the system provides a good base to study Hardware/Software Co- Design techniques in hands-on fashion. Although the content of the laboratory deals with complex topics, which require a good preparation and concentrated work of the students, the feedback was throughout very positive. References [1] C. Bieser, J. E. Becker, A. Thomas, K. D. Müller-Glaser, J. Becker: Hardware/Software Co-Training by FPGA/ASIC Synthesis and programming of a RISC Microprocessor- Core [2] Gaisler Research, the home of the Leon Processor [3] Amba-Bus (AMBA AHB/APB), ARM Ltd., UK, [4] Vladimir Nikolajevic and Gerhard Fettweis: New Recursive Algorithms for the Forward and Inverse MDCT [5] P. Allen and D. Holberg, "CMOS Analog Circuit Design", 2nd Edition, 2002,Oxford University Press, ISBN [6] Jim Karki, "Active Low-Pass Filter Design", Texas Instruments Application Report SLOA049A- October 2000