• No results found

System on Chip Platform Based on OpenCores for Telecommunication Applications

N/A
N/A
Protected

Academic year: 2021

Share "System on Chip Platform Based on OpenCores for Telecommunication Applications"

Copied!
5
0
0

Loading.... (view fulltext now)

Full text

(1)

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

(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.

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

(3)

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 schema

Figure 4. OR1200 Architecture

CPU0 sub-module

WISHBONE sub-module

CPU1 sub-module CRC

TAP unit TDI

TD0 TCK TMS TRSTn

Debug Scan chain

(4)

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

(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.

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

Figure

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 Asynchro
Figure 3. WISHBONE interconnect schema
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
Table 2. Synthesis results

References

Related documents

The new AA-T degree, with its four levels of core classes that are only offered once per year will likely see an increase in average years to completion, since if a student

Materials and Methods: This is a comparative study on the head length, head width, and cranial index of 112 children (72 males and 40 females) diagnosed with at least one

The obtained results for the numerically and graphically calculated values of p K BH + using five methods from the absorbance data, at four selected wavelengths, are shown

However, fine-tuning the classifiers with the review metadata, the sentiment scores, NLP, and the tense of the review text increased the precision up to 95% for ratings and

In this study, I wanted to learn about the students’ experiences with transitioning from high school to college, and their personal–cognitive, behavioral, and environmental relations

To acquire this understanding, I sought to answer three primary research questions: (a) What are the first-year NA students’ perspectives and experiences of what influences

She is currently working on several studies related to breastfeeding, including a study to better understand college students’ attitudes and future intentions regarding

Guiding practice focus was evaluated using the PICO system to formulate the clinical question for this systematic literature review: P means- patient/problem: - terminally