ARM System on Chip

This walkthough aims to introduce you to a simple ARM SoC and the hardware/software design flow.

Overview of a Simple ARM SoC

A very simple ARM System on Chip has been designed:

The design includes four slaves:

ROM
16K bytes for program memory
RAM
256 bytes for data memory (including stack)
Switch Interface
Occupying a single 32-bit memory location
Output Interface
Occupying two 32-bit memory locations

Memory Map

The memory map is sparsely populated with the unused areas being filled with secondary images of the real slave devices:

The secondary images are an artefact of the partial address decoding which only uses the top 4 address bits (HADDR[31:28]) in order to decide which slave is being accessed.

Files

In order to build the ARM SoC, we need SystemVerilog files to model the hardware plus C program files and other support files to build the software. Further files are required to support simulation:

Hardware
- arm_soc.sv
Software
- C Program Code
- Support files
Simulation

Preparation

Create a new directory for the lab (e.g. ~/design/system_on_chip/example) and change to the new directory:
```
    mkdir -p ~/design/system_on_chip/example
    cd ~/design/system_on_chip/example
```
Copy the design files (not including the Cortex-M0):
```
    init_soc_example -here
```
Download the obfuscated Cortex-M0 file and place it in the behavioural subdirectory:
- cortexm0ds_logic.sv

Compile C Program

In the software sub-directory, the compile_and_link script, the makefile and the designstart.ld linker script are used to compile the three C language files main.c, vectors_designstart.c and crt.c.
Running the compile_and_link script:
```
    cd software
    ./compile_and_link
```
should create a Verilog hex format file named "code.hex" which can be used in simulation and synthesis.
Open the "code.hex" file in a text editor to check that it has been created.

Simulate ARM SoC

In the main directory (~/design/system_on_chip/example), simulate a simulate script exists to simplify the task of running the simulation:
```
    cd ..
    ./simulate &
```
Consult the HADDR and HSEL_... signals in the waveform window and satisfy yourself that the correct active HSEL_... signal is being selected based on any particular address value. (Identify at least one address for each of the HSEL_... signals and confirm that it is in the correct range)
Look at the Console output and the main.c program. Can you explain the sequence of "DataOut" values that you see in simulator console?
Add the contents of the RAM to the waveform window and work out how much of the RAM is in use with this program. (You will have to 'rewind' and re-run the simulation in order to see the contents of the RAM).
Note that because the stack grows downwards, the higher memory addresses are used before the lower ones.

Change the program

The following actions should be possible without closing the simulation.

In the software/code/main.c file, replace this line:
```
    if ( switch_temp < 8 ) {
```
(which limits the range of number for which a factorial is calculated) with this line:
```
    if ( switch_temp < 16 ) {
```
and re-run the compile_and_link script.
Now use the
```
    Simulation -> Reinvoke Simulator...
```
dialogue to re-run the simulation using the newly updated code.hex file.
Is the system able to calculate the factorial of 15?
Look again to see how much RAM is being used.
Talk to someone helping in the lab about what has gone wrong.

Change the amount of RAM

Increase the amount of RAM to 1024 bytes (256 32-bit words) either by editing the behavioural/ahb_ram.sv or the behavioural/arm_soc.sv file.
Re-run the simulation and confirm that you can see the increased memory size. (You will most likely have to remove the memory from the waveform window and then add it again in order to see all 256 words of memory).
Has the behaviour of the simulation changed?.

Update the linker script

In the software/designstart.ld file, replace this line:
```
   RAM   (rwx) : ORIGIN = 0x20000000, LENGTH = 256
```
(which tells the linker how much memory is provided) with this line:
```
   RAM   (rwx) : ORIGIN = 0x20000000, LENGTH = 1024
```
Before recompiling you should clean the software directory to ensure that a new version of code.hex is generated:
```
   make clean
   ./compile_and_link
```
Now re-invoke the simulator.
Has the behaviour of the simulation changed?.
Check with the aid of a calculator to see if any result given each of the factorial calculations is correct?

At this stage you can experiment with other changes to the system but you should try to make only small changes between simulations to increase the chances of being able to debug the system.

Iain McNally
22-2-2017