Integrate the IP into the SoC

We now have a list of IP components to put into the SoC. Next, we need to complete a series of steps before we test the system as a complete entity. This process is known as the integration phase of design and involves the following:

  • Configuring the features that each piece of IP supports
  • Configuring memory
  • Setting up power and clock domains
  • Connecting up SoC IP through master and slave interfaces
  • Creating the IDAU for the Cortex-M23 processor

The following sections expand further on these integration steps:

Configure the features that each piece of IP supports

There are three ways to configure the IPs, as you can see in the following table:

IP configuration Description
Render-time Set the configuration options in a data file, for example an XML file. To then produce the RTL from the configuration, you run a script. This script also configures the testbench for the RTL and any related software. For example, a testbench for RAM might need to know the size that the memory was set to. Knowing the specified options enables the testbench to configure the tests accordingly.
Instantiation-time When the RTL of a piece of IP has been rendered, the next step is to instantiate it. During instantiation of the RTL, you can configure each instance of the IP using Verilog parameters. For example, an SoC could have two processors. During instantiation, the FPU could be enabled for one processor and not the other by changing a Verilog parameter.
Using pin tiles Pin tiles are used to configure features after rendering. However, if the pin tiles exclude certain options altogether, the RTL for those options are optimized out.

Note: You can also configure IP at runtime using registers. However, physical implementations of the options that the registers offer must exist. Therefore, the RTL is always included for any optional features. In other words, a feature must be developed on the die ready to be switched on or off by the related registers.

Configure memory and replace generic Arm memory models

Configuring memory normally just involves setting the size of the memory. You must also replace the generic Arm memory model with a real memory library macro. Real memory libraries are fab process-specific. For example, you could use TSCM 28nm physical RAM. Although the size of the memory is defined within the IP configuration options, for the memory macro, you must still define:

  • The size and number of memory banks
  • Whether the memory is a square or rectangle

You must also consider these factors when arranging the floorplans of the die.

Set up power and clock domains

By defining a power or clock domain, you allow different domains to power down or stop their clock while other domains are still running.

A Power Policy Unit (PPU), which connects to the bus matrix through an APB4 interface, controls a power domain. The PPU provides a standardized software view for power control of a domain. The Power Control State Machine (PCSM) is responsible for switching components on or off. You must implement the PCSM for your system by writing the RTL for it.

A Clock Controller controls a clock domain.

Q-Channels or P-Channels allow:

  • Components on an SoC to communicate their power state and whether they are idle. This information allows a PPU or a Clock Controller to decide whether to power down a domain or stop the clock for a domain.
  • A PPU to make a request that a component change its power state. In response, a component can accept or refuse.

Q-Channels can only communicate two possible states. Clock domains only use a Q-Channel because the clock can only ever be on or off. P-Channels allow you to communicate multiple states to a component. A component can have more than two power states.

If you have one domain that is communicating through an AHB5 bus interface to another domain, you require an AHB5 Access Control Gate (ACG). The ACG stops a transaction entering a domain that is off and can also wake up a sleeping domain. Be aware that implementing power domains has overheads, in complexity and even performance. You must consider these overheads against the power-saving gains.

For example, imagine a smart temperature sensor that wakes up every ten seconds to take a reading. The sensor wakes up when used but spends much of its time asleep. The sensor also has a CryptoCell-312 for security. When the sensor wakes up, it wakes up everything including the CryptoCell-312. In some systems, the CryptoCell-312 is a candidate for putting in its own power domain. However, for the sensor, it does not make sense because the system is only awake for short periods of time.

The secure IoT coffee machine that we are designing might be simple enough to only include one clock and power domain. We might expect a coffee machine to be plugged into the wall plug and not to be running all the time. While the coffee machine is not running, the entire system can power down.

[0]If you require multiple clock domains in your SoC, it is important to make sure that the timers are in the correct clock and power domain. If you do not want a timer to turn off, you must make sure that they are not in a gated domain.

Note: The AHB5 to APB4 asynchronous bridge can also function as an ACG. However, you can still use an AHB5 to APB4 asynchronous bridge within a single domain.

Connect up SoC IP through master and slave interfaces

When you configure an AHB5 bus matrix, you can define how many slave and master interfaces it has. Configure each interface to meet the requirements of the IP that is connecting to it. Be aware that the data width of the bus matrix interfaces is fixed. Therefore, if an interface of a piece of SoC IP has a different width, you must use a converter block. Sometimes, you might be able to configure the SoC IP interfaces so that they match the bus matrix interface width.

You must map each slave interface on a bus matrix to an area in the memory map. You must also decide which masters can access these interfaces.

Create the IDAU for the Cortex-M23

The IDAU must be implemented for each system. This process involves defining the IDAU regions in a look-up table for the Cortex-M23. Each entry in a table contains the following information about a region:

  • Starting and ending address
  • TrustZone Security state
  • Region ID
Previous Next