System on Chip Platform Based on OpenCores for Telecommunication Applications

Transcription

1 System on Chip Platform Based on OpenCores for Telecommunication Applications N. Izeboudjen, K. Kaci, S. Titri, L. Sahli, D. Lazib, F. Louiz, M. Bengherabi, *N. Idirene Centre de Développement des Technologies Avancées Lotissement 20 Août 1956, Baba Hassan, Alger * Université de Bourgogne, Laboratoire LE2I, UMR-CNRS 5158, Aile Sciences de l'ingénieur, BP DIJON Cedex, France Abstract In this paper, we present a platform for system on chip (SoC) implementation that is suited for telecommunication applications. To build the platform, we have adopted the OpenCores-Openhardware design concept. The benefit of using the OpenCores methodology is flexibility, reuse and accessibility of the cores at free cost. We demonstrate how the open hardware trend can help designers to build complex integrated circuits such as the SoCs at low cost. To test the platform, our first application is a SoC implementation of a Voice Over IP (VoIP) Gateway. The first preliminary results show that the whole SoC can be implemented in the field programmable gate array (FPGA) XC2V1000 circuit which can integrates up to 1Million of logic gates. I. INTRODU CTION Today with the evolution of technology, it is possible to integrate in a single chip, complex systems of many million of gates using multiprocessor architectures, communication systems as well as DSP circuits for digital and image processing algorithms. Thus, a new concept which is gaining a great interest is the System on a chip (SoC) design. Designing a (SoC) is relatively complex, requiring expertise in algorithmic, hardware and software levels. The major problems are: Complexity and size of the project. Hardware and software partitioning between different tasks that execute the algorithm. IP cores must use a standard interface. The design effort is moved from the functionality level of the circuit to the communication between different IP cores in the SoC. Test of the whole SoC. Power management Physical and technological effects In order to deal with these problems, designers need new techniques to handle the increased complexity inherent in these large chips. One such emerging technique the SoC platform design methodology. Definitions of SoC Methodology vary to some degree. Most practicing, though would agree that a platform based SoC design is one that can handle the software and the hardware part of a SoC project. Architectures, IPs cores, Connectivity are reused within a structured, repeatable design environment, with the goal of minimizing design cycle time. Existing synthesis and simulation platforms have been designed to support traditional ASIC/FPGA Design flow. New versions for SoC design are proposed to the research/industry Community but they are very expensive and still at their young age. In the other side, a new concept that is gaining interest is the Opencores SoC design methodology which is based on publishing all necessary information about the hardware. The design specification, HDL files, simulation testbenches, interfaces to other systems should be documented [1]. Usually, all this information is not available for free without any restriction. There are several groups that try to define the Open hardware in terms of available information such as the OpenCores [2] and OpenCollector [3] organizations. This new design concept is proposed as a bridge for the technological, educational and cultural gaps between developing and developed countries. A project that is going on in the CDTA/Microelectronics research laboratory is the design and implementation of a SoC platform for telecommunication applications using the OpenCores design methodology. The objective is double: First by using the OpenCores design methodology, we aim to gain expertise in the SoC domain area with free cost and second the chose of telecommunication domain is because this last is playing a strategic role and therefore a SoC Platform that can minimize the design cycle time and time to market constraints is very helpful. Section II deals with the proposed SoC development platform. In section III, presentation of the hardware SOC architecture. In section IV simulation and synthesis results are given and finally a conclusion. II. PRESENTATION OF THE OPENCORES SOC DEVELOPMENT PLATFORM Using the OpenCores design methodology, we have developed our own SoC platform for telecommunication application. Figure 1 gives an overview of the whole platform. Creation of the platform begin by creating a library which is composed of

2 the Wishbone interconnect standard bus, the OR1200 processor and other public cores suited for telecommunication purposes such as the audio and video codec s, the MAC/Ethernet, the USB, the UART, memories, etc. In this library, all the cores are reusable and are described in the VERILOG language. SOC Designer 1 Software Coding Compiling Debug on OR1ksim SOC Project SOC Designer 2 Parent Directory SOC Designer N Hardware Project DOC PCB Layout Synthesize HDL Makefile for synthesize Makefile for simulation OpenCores library for telecom The PCB layout is done using the ORCAD capture Ver9.6 tool. It is recommended to begin the PCB layout and the project documentation early in the design process to allow different members of a team working in the same project communicate and co-operate with each other. For example, each time a change is made within an IP or a new version is created, it is communicated to the PCB and documentation teams and vice-versa. This is done through the use of a common repository called CVS (Concurrent Version Check) [5] III. PRESENTATION OF THE HARDWARE SOC ARCHITETURE Figure 5 shows the proposed gateway architecture which is mainly based on the OR1200 processor MASTER, a debug unit for debugging purpose, a Test access port (TAP), a memory controller that controls an external Flash and SDRAM memory, an Universal Asynchronous Receiver Transmitter (UART), a standard MAC/Ethernet. All the cores are connected through the WISHBONE bus interface. In the following an architecture description of each IP core of the VOIP gateway is addressed. JTAG Download to board Synthesis Tool Simulator Tool Place & Route Tool ROM Boot TAP Debug Interface OR bit RISC Download to board WISHBONE Bus System & Arbiter Figure1. Platform architecture At a high level, a SoC designer specifies the Software and the hardware part of the project. In a SoC Software and hardware are related to each other by the RTOS (Real Time Operating System). The software part includes several packages, like the Gcc Compiler, a debugger and an architectural simulator OR1ksim which is an instruction set simulator. After defining the architecture, different phases can be achieved in parallel for the SoC project. These are: the simulation, the synthesis, the PCB layout and the project documentation phases. Simulation and synthesis are done using the Mentor Graphics ModelSIM simulator and Leonardo Spectrum synthesis tools respectively [4], [5]. These tools are executed at the back end plan of the platform. By using the Make language, a Makefile is created for simulation and another one for synthesis. These files contains the path/directory of the IP cores which are stocked in the library and the synthesis or simulations options (such as target FPGA device, surface/timing constraints, specific input/output, etc.). Thus, for each SoC architecture the Makefile is created once. With this way, a designer concentrate only in his design to avoid errors due to fault manipulation of the tools options, hence the design time and further the time to market factor are reduced. FLASH Memory Controller SDRAM UART Console interface Figure 2. The SoC architecture 10/100 Ethernet MAC/PHY Physique interface A. The WHISHBONE bus Interface As shown in Figure 3, the WISHBONE bus interface uses MASTER/SLAVE architecture. Some signals are specific to the master core, others to the slave one and there are common signals shared between the master and the slave. The MASTER interface could be on a microprocessor IP core, and the SLAVE interface could be on a serial I/O port. In this architecture the WISHBONE uses the shared bus interconnection schema, thus a MASTER initiates a bus cycle to a target SLAVE. The target SLAVE then participates in one or more bus cycles with the MASTER. An arbiter (not shown in the Figure) determines when a MASTER may gain access to the shared bus. The main advantage to this technique is that shared interconnection systems are relatively compact. Generally, it requires fewer logic gates and routing resources than other configurations, exp. cross bar switch [6].

3 C. THE Debug unit and TAP controller The debug unit is used for debugging purposes and is as such an interface between the Test Access Port (TAP) and the submodules that are target (CPU ORAK, WISHBONE). It consists of several blocs: WISHBONE module, two CPU submodules and a CRC sub-module. It receives data from the TAP whenever the DEBUG instruction is active. Data can hold two kinds of instructions: module selection and submodule selection. All data is protected with the 32 bit CRC sub module. The TAP, connects to the core via a fully IEEE compatible JTAG TAP port which is made of five signals (tck, tms, tdi, td0 and trst) [ 7]. TDI TD0 TCK TMS TRSTn TAP unit Debug Scan chain CRC CPU0 sub-module WISHBONE sub-module CPU1 sub-module Figure 3. WISHBONE interconnect schema B. The OR1200 processor The OR1200 (Figure 4) core is a 32-bit scalar RISC with Harvard micro-architecture, 5-stage integer pipeline, virtual memory support (MMU) and basic DSP capabilities. It includes debug unit for real-time debugging easing software development, a high resolution tick timer, a programmable interrupt controller and a power management support [7]. OR1200 runs at 33 MHz on a Virtex FPGA. Other version of processor RISC, called OpenRISC 1000 is also available for high performance Industrial and telecommunication applications and runs at 80 MHz in a Xilinx Virtex FPGA. In our application we use the OR1200 processor, as it is well documented. Figure 4. OR1200 Architecture Figure 5 Debug and Test access port (TAP) units D. The Memory Controller The memory controller supports a variety of memory devices; flexible timing and predefined system start up from a Flash or ROM memory. Figure 5 illustrates the overall architecture of the core. It consists of a 32 bit bus WISHBONE interface, a power-on configuration, a refresh controller, an open bank and row tracking, an address MUX and Counter, a data latch packet and parity, a memory timing controller a memory interface and a configuration and status register. The poweron block latches the value of the memory data bus during reset. The value read, determines initial configuration of the Memory Controller. The refresh controller block is responsible for generating refresh cycle requests for the attached SDRAMS. The open bank and row tracking block remembers which bank and which row within a bank is already open. This feature allows for very fast access to already open rows within a bank and row. The address MUX and counter bank block is responsible for generation of proper addresses. The data latch packet and parity block is responsible for the data bus connections between the Memory bus and the WISHBONE bus. The memory timing controller is responsible for memory timing and control. It performs the appropriate cycles to access various memories. The Memory Interface block provides simple synchronization for IOs. All outputs and inputs are registered at the rising edge of the Memory Clock. The Memory Controller utilizes two clocks: the main wishbone clock; and the memory clock. For optimal operations, the memory clock must be derived from the WISHBONE clock by dividing the WISHBONE clock by two and phase synchronizing it to the WISHBONE clock. The configuration and status block holds all the registers in the Memory Controller and decode the chip select signal [7].

4 F. The UART unit The UART is very similar to the standard UART chip. Figure 7 shows the bloc diagram of the UART. It consists of a TX unit, an Rx unit, an interrupt bloc, a modem logic bloc and a WISHBONE interface bloc. The TX unit converts the parallel data into serial form to transmit them to the host. The data from the OR1200 processor or the DMA core interface are stored in buffer registers, converted into a serial form at the shift register and transmitted. The Rx unit process the serial data received from SRX-I. The WISHBONE interface can be 32 bits or 8 bit bus (selectable) [7]. Divisor Latch s Baud Generator Line Status Figure 6. Memory controller architecture E. The MAC/Ethernet unit Ethernet core is a 10/100 Media Access Controller MAC). It is designed to run according the IEEE specification tat defines the 10 Mbps and 100Mbps Ethernet respectively. Figure 6 shows the general architecture of the IP core. It consists of several building blocks: a TX module an RX module, a control module, a management block and a WISHBONE interface. The TX and RX modules provide full transmit and receive functionality. CRC generators are incorporated in both modules for error detection purposes. The control module provides full duplex flow control, according to the IEEE 802.3u standard. Flow control is achieved by transferring the PAUSE control frames between the communicating stations. The management module provides the standard IEEE Media Independent Interface (MII) that defines the connection between the PHY and the link layers. Using this interface, the device connected can force PHY to run at 10 Mbps versus 100 Mbps or configure it to run at full versus half duplex mode. The WISHBONE interface connects the Ethernet core to the RISC and to external memory [7]. Figure 7. MAC/ Ethernet architecture W I S H B O N E Line Control FiFo Control Interrupt ID Interrupt Enable Modem Status Modem Control Receive r FIFO Transmi t FIFO Figure 8. The core UART Receive r Shift registar Transmi t Shift registar Interrup t Logic Modem Signal Logic SRX_I STX_O INT_O RTS_O CTS_I IV. SIMULATION AND IMPLEMENTATION RESULTS Although most of the HDL cores codes are available freely for simulation and synthesis from Opencores, the most difficult task in designing SoC hardware is how to write an HDL code that integrates all the SoC components codes and how these components communicate each with other through the WISHBONE interface bus. To do this, the first step is to define the MASTER from the SLAVE components in the architecture. The OR1200 processor is the MASTER for all components. The memory controller is configured as slave compared to the OR1200 and a MASTER to the SRAM and Flash memory. The UART is configured as a slave to the OR1200. After this, we have created a Makefile for simulation and another one for synthesis. At this time, we have integrated the OR1200 processor, the debug and TAP units, the Memory controller and the UART core.

5 In Figure 8 the last five curves show the simulation results for the TAP outputs (TDI, TD0, TCK, TMS). In this example study the TAP was simulated to activate the debug unit. Other functional simulations for the SRAM and UART were verified successfully. After this, we synthesized the architecture using the Leonardo Spectrum professional synthesis tool from Mentor Graphics. The whole Architecture is mapped into the XC2V1000fg465 FPGA circuit. Table 2 shows the resulting synthesis results. Mainly, the SoC occupies 74% of the FPGA surface and 41% of inputs/output. VI. CONCLUSION We have successfully implemented a SoC Platform which is suited for telecommunications applications, by adopting the OpenCores design methodology. After installing the platform we could successfully implement the proposed SoC architecture for VoIP. Our next objective is to finalise the VoIP gateway integration, to test the some applications through the OR1K simulator (serial transfer data, memory boot, etc.), to build a graphical interface for the platform and to reuse the platform for other telecommunication applications. Table 2. Synthesis results Figure 9. Simulation results Design Information area -pr b -k 4 -c 100 -tx off -o VoIP_map.ncd VoIP.ngd VoIP.pcf Target Device : x2v1000 Target Package : fg456 Target Speed : -4 Design Summary Number of occupied Slices: 3,812 out of 5,120 74% Total Number 4 input LUTs: 6,544 out of 10,240 63% Number used for Dual Port RAMs: 32 Number of bonded IOBs: 136 out of % IOB Flip Flops: 116 Number of Block RAMs: 12 out of 40 30% Number of MULT18X18s: 4 out of 40 10% Number of GCLKs: 4 out of 16 25% Number of DCMs: 1 out of 8 12% V. CONCLUSION Figure10. Final FPGA Layout V. REFERENCES [1] Mohamed A. Salem, Jamil Khatib, An Introduction to Open-source Hardware Development, EEDesign.com [2] OpenCores project site [3] OpenCollector site [4] Mentor Graphics reference manual [5] R. Jeffery, S. Zhong Zhang, Version Management For Team Design in FPGA Advantage, [6] WISHBONE System-on-Chip (SoC) Interconnection Architecture for Portable IP Cores. OpenCores, September 7, 2002 [7] OPENCORES Project: OpenRISC [8] ISE 6.1 user manual, After synthesis, we use the ISE 6.1 place and root tools [8] for implementation. Figure 10 shows the layout of the circuit.