UT SoC Architecture Overview

SoC ARCHITECTURE OVERVIEW

The growing feature size of the transistor and the capacity available in the current integrated circuits opened up a new possibility of system design called system-on-chip (SoC). These systems allow multiple systems on the same die, including analog circuits, digital systems, sensors, processor and memories. The SoC design can use a combination of the pre-designed blocks or IP-blocks (or cores) along with embedded software. The SoC design techniques are more focused on analyzing the required tasks for hardware and software partitioning for efficient, low power and low cost implementation of various algorithms.

The LEON processor in particular is very helpful in initiating an open source SoC architecture development. This processor is SPARC compatible and with the availability of cross compilers and real-time operating systems for this processor it is surely a good candidate platform for SoC development.

The above figure show the overview of the system. The various components in the SoC design are classified into blocks. The whole system is either implemented on an FPGA or ASIC. The LEON processor core along with the custom IP-Blocks or the cores interfaced to LEON processor form the hardware architecture of the SoC. The software controlling the hardware is represented in the top block. Embedded operating systems can be used for task management and hardware resource abstraction. The most popular operating systems that can be used in this context are open source RTEMS, LEOX (micro-linux for LEON ), and ECOS (Redhat port for micro controllers).

The cross-compilers for LEON, LECCS, are available from Gaisler Reaserch. These cross-compilers can be used to generate the binary or the assembly as required. The compilers should be installed in /opt/rtems of your system. LECCS can be used for generating standalone C/C++ applications to be used along with an O/S or ROMable(non-rtems) C-application. Both C-programs and RTEMS applications are linked to run from beginning of the RAM. However to make a boot prom to run from the prom on a standalone target a utility mkprom is used. This utility will load the application to the beginning of the RAM, initialize certain LEON registers and finally start the application.

Once the SoC is developed with LEON it can be allowed to boot, either from the internal PROM (slow) or from the external memory (fast). The internal on-chip boot loader can be developed using the PMON provided with LEON . PMON is a simple monitor that can be placed in an on-chip boot prom, external prom or cache memories (using the boot-cache configuration). Two versions are provided, one to be used for on-chip PROM or caches (bprom.c) and one for external PROMs (eprom.c). On reset, the monitor scans all ram-banks and configures the memory control register 2 accordingly. The monitor can detect if 8-, 16- or 32-bit memory is attached, if read-modify write sub-word write cycles are needed and the size of each RAM bank. It will also set the stack pointer to the top of RAM. The monitor writes a boot message on UART1 transmitter describing the detected memory configuration and then waits for S-records to be downloaded on UART1 receiver. It recognizes two types of S-records: memory contents and start address. A memory content S-record is saved to the specified address in memory, while a start address record will cause the monitor to jump to the indicated address. Applications compiled with LECCS can be converted to a suitable S-record stream with:

sparc-rtems-objcopy -O srec app app.srec

See the README files in the pmon directory for more details. After successful boot, the monitor will write a message similar to:

LEON-1: 2*2048K 32-bit memory

LEON is available with a instruction level simulator called TSIM. An evaluation version of LEON is available at Gaisler research. The user can write the expected hardware modules or IP-blocks s/he is planning to put together with LEON in software and profile it before implementing it in hardware. This proves to be a useful tool for doing hardware/software partitioning of the given algorithm to be implemented.

In this class project, different IP blocks are interfaced to LEON using the AMBA AHB and APB bus ses. The IP blocks include FIR, FFT, DES, and AES. These can be added as 'masters' to interface to the AMBA AHB bus. The AMBA APB bus is used to connect slow speed peripherals. It is used for exchanging hand-shaking signals. It cannot be used for block data transfer.