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
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
nizeboudjen@cdta.dz
* Université de Bourgogne, Laboratoire LE2I, UMR-CNRS 5158, Aile Sciences de l'Ingénieur, BP 4787021078 DIJON Cedex, France
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.
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.
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.
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].
Debug Interface
WISHBONE Bus System & Arbiter
OR1200 32 bit RISC TAP
ROM
Boot
10/100 Ethernet MAC/PHY UART
16550
Console interface Physique interface JTAG
Memory Controller
FLASH SDRAM
Figure 2. The SoC architecture Parent
Directory
SOC Designer 1
OpenCores library for
telecom SOC Designer N
SOC Project
Hardware
Project DOC PCB Layout Synthesize HDL Makefile for
synthesize
Makefile for simulation
Synthesis Tool
Simulator Tool
Place & Route Tool Software
Compiling Debug on OR1ksim Download to
board Coding
SOC Designer 2
Download to board
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.
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 sub-modules that are target (CPU ORAK, WISHBONE). It consists of several blocs: WISHBONE module, two CPU sub-modules 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
sub-module selection. All data is protected with the 32 bit CRC sub module. The TAP, connects to the core via a fully IEEE 1149.1 compatible JTAG TAP port which is made of five signals (tck, tms, tdi, td0 and trst) [ 7].
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 power-on 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]. Figure 3. WISHBONE interconnect schemaFigure 4. OR1200 Architecture
CPU0 sub-module
WISHBONE sub-module
CPU1 sub-module CRC
TAP unit TDI
TD0 TCK TMS TRSTn
Debug Scan chain
E. The MAC/Ethernet unit
Ethernet core is a 10/100 Media Access Controller MAC). It is designed to run according the IEEE 802.3 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 802.3 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].
F. The UART unit
The UART is very similar to the standard 16550 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].
IV. SIMULATIONAND 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 16550 UART core.
Figure 6. Memory controller architecture
Figure 7. MAC/ Ethernet architecture
SRX_I
STX_O
INT_O
RTS_O
CTS_I Divisor
Latch Registers
Line Status Register
Modem Control Register Line Control
Register
Interrupt Enable Register
FiFo Control Register
Interrupt ID Register
Modem Status Register W
I S H B O N E
Receive r FIFO
Transmi t FIFO
Baud Generator
Receive r Shift registar
Transmi t Shift registar
Interrup t Logic
Modem Signal
Logic
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.
V. CONCLUSION
After synthesis, we use the ISE 6.1 place and root tools [8] for implementation. Figure 10 shows the layout of the circuit.
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.
V. REFERENCES
[
1] Mohamed A. Salem, Jamil Khatib, “An Introduction to Open-source Hardware Development”, EEDesign.com [2] OpenCores project site http://www.opencores.com[3] OpenCollector site http://collector.hscs.wmin.ac.uk
[4] Mentor Graphics reference manual
http://www.mentor.com
[5] R. Jeffery, S. Zhong Zhang, “Version Management For Team Design in FPGA Advantage”,http://www.technoline.
[6] WISHBONE System-on-Chip (SoC) Interconnection Architecture for Portable IP Cores. OpenCores, September 7, 2002
[7] OPENCORES – Project: OpenRISC 1200. http://www.opencores.org/projects/or1k/ [8] ISE 6.1 user manual, www.xilinx.com
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 324 41% 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% Table 2. Synthesis results
Figure10. Final FPGA Layout Figure 9. Simulation results