Overview The goals of a secure IoT device Security - How can I secure my device? Security - Platform Security Architecture Security - Arm TrustZone technology Security - CryptoCell and CryptoIsland technologies Security - Mitigating against physical attacks Security - Implementing additional security IP - What IP do I need to make a secure IoT device? IP - The processor IP - The AMBA components IP - The CryptoCell IP - Power control, timers, Wi-Fi, and display Build - How does the IP fit together? Build - Starting to develop an example TBSA-M system Build - Select AMBA components to link the IP together Build - Connect to RAM, ROM, and eFlash memory Build - Connect the CryptoCell-312 Build - Add power control to the SoC Build - Add the timers as peripherals Build - Add a theoretical Wi-Fi and display component Build - Integrate the IP into the SoC Build - Add your own registers for the SoC Build - Arm subsystems SSE-123 - Exploring the SSE-123 Example Subsystem SSE-123 - SSE-123 features SSE-123 - Working with the SSE-123 SSE-123 - SSE-123 timers SSE-123 - SSE-123 registers SSE-123 - Debugging with the SSE-123 SSE-123 - The SSE-123 I/O port SSE-123 - Ideas for extending the SSE-123 Related information Next steps
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