This section demonstrates how to build top level SoC RTL
using Components Collected/Configured.
Now that all the component level RTL
has been collected, its time to stitch these components together to
build the Stage 1 SoC.
A simple SoC as shown in the figure in Section 1.
It has a Cortex-M3 as the processor, with 2 memory components
connected to it via a AHB
Multilayered Bus Matrix:
One memory component connects to the AHB Bus Matrix Master Port M0.
It has a address decode region of 0x0000_0000 - 0x0000_FFFF (64 KB)
The other memory component connects to the AHB Bus Matrix Master
Port M3. It has a address decode region of 0x2000_0000 to
0x2001_0000 (128 KB).
The Cortex-M3 processor has 3 AHB Lite Interfaces
ICODE -> Connects to AHB Bus Matrix Slave Port S0
DCODE -> Connects to AHB Bus Matrix Slave Port S1
System -> Connects to AHB Bus Matrix Port S3.
The AHB Bus Matrix Slave Ports S4, S5 are tied to constants, and
hence will not be used.
The AHB Bus Matrix Master Ports M1, M2 are tied to constants, and
hence will not be used.
These unused ports may be used in further stages eg. Stage 2,
Stage 3 etc. of the tutorial as we add more capabilities to the SoC.
Integration is the easiest activity of this tutorial.
All the user has to do is to make connections between the
The SoC will be called 'cortexm3_soc'.
The corresponding verilog file is 'cortexm3_soc.v'.
This file will be placed in the following directory:
It instantiates the following:
The ARM cortex-m3 processor (Integration Level). This
component will come from the following file:
The AHB_to_SRAM designs. The component rtl will come from the
instance will be called cmsdk_ahb_to_sram_A, and the second
one will be called cmsdk_ahb_to_sram_S
The SRAMS. The component verilog will come from the following
instance will be called cmsdk_fpga_sram_A, and the second
one will be called cmsdk_fpga_sram_S
Following the instantiation of the above and making the connections
to the effect of diagram shown in Section 1, you will get your top
level Verilog RTL file cortexm3_soc.v If you so wish you can
download this file from here
You will be asked to provide your email ID, and a download link will
be automatically sent to you. Watch out, it might just land in your
The connections of the above components are shown in the figure 3.1
below. Note the following:
The DCODE bus is connected to Bus-Matrix Port S0, and the
ICODE is connected to S1. This has been done so that the DCODE
bus has higher Priority than the ICODE bus. This is an important
recommendation by ARM.
The Bus Matrix Ports S4, S5, M1, M2 are tied to constants.
It is important that the HREADYs that are going into the Bus
Matrix at the port M1 and M2 must be tied to '1'.
The HWDATA on port S1, i.e. the port connecting to the ICODE
bus is tied to 0. This is because the ICODE is a read-only bus.
There is no S2 slave port on bus matrix. This is OK, its just
a name. Though it could have been easily avoided.
All the input ports on the ARM-Cortex M3 processors except the
3 AHB Lite interface input ports, clocks and resets are tied to
All the output ports on the ARM-Cortex M3 processor except the
3 AHB Lite interface output signals are left open.
To tie the unused input ports of Cortex-M3 processor, use
constant value of 0s except for those input ports which have a
small 'n' suffix in their names e.g. ISOLATEn, RETAINn.These are
active low signals and must be tied to '1'.
All the Reset input ports on the Cortex-M3 processor are
sourced from a single reset i.e HRESETn for this tutorial.
All the Clock input ports on the Cortex-M3 processor are
sourced from single Clock i.e. HCLK for this tutorial.
HRESETn and HCLK are generated in the testbench file, which is
Figure 3.1 ARM Cortex M3 Stage 1 SoC
Now write a very simple testbench for generating clk & reset,
and instantiate the SoC in it:
Cut+Paste the following code and save it as 'cortexm3_soc_tb.v'
in the following directory asic_design/xilinx/cortexm3_soc/top/tb/cortexm3_soc_tb.v
(You may have to create the tb directory)
All the RTL
code and Testbench is now in place. Next section will deal with
generating a software binary file which the verilog sram model (cmsdk_fpga_sram.v)
can read at the start of the simulation (using $readmemh verilog
function), and the processor can execute it, at the reset release.