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.
![](figures/architecture.jpg)
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.
| Abstract | Introduction
| SoC Architecture Overview | Hardware and Software Details | Helpful Hints | Conclusions
| References | Acknowledgements
|