Designing with ARM Cortex-M based System-On-Chips (SoCs) - Part I: The basics - Embedded.com

Designing with ARM Cortex-M based System-On-Chips (SoCs) – Part I: The basics

Editor’s Note: In this first of a two-part Product How-To article series, Tushar Rastogi and Subbarao Lanka of Cypress Semiconductor describe the fundamentals of developing processor-based system-on-chip designs using the company’s PSoC architecture.

In this series we will cover several facets of designing multicore-based system-on-chips (SoCs), including the typical architecture of an SoC; how the design of mixed signal embedded systems is simplified; how design changes can be easily implemented without negatively impacting time to market; the tools available for developing complicated applications; and key business advantages of using SoCs.

We will use ARM Cortex M processor cores as our basic building blocks, widely used because of their low cost, low power operation capability, configurable processors, and simple design. They are based upon a RISC architecture that requires a low transistor count, resulting in reduction of power dissipation, thermal dissipation, and cost. And while most of our discussion will deal with issues that could apply to all system-on-chip designs, it will also make reference to features only available on programmable SoCs, such as the Cypress PSoC architecture.

The system-on-chip (SoC) architecture
A system-on-chip (SoC) is an integrated circuit which packs multiple peripherals of an electronic system (memory, connectivity, analog, and digital peripherals) on a single substrate with a processor at its heart. The processor can be a microcontroller, microprocessor, or DSP core. SoCs are becoming popular because of their smaller size, reduced power consumption, and reduced assembly costs compared to traditional microcontroller architectures.. Figure 1 shows a standard SoC with multiple peripherals connected by a data bus.

Figure 1: General SoC Architecture

Now let’s look at the details of hardware components of SoC shown above. On the hardware side, an SoC can be thought of as a Lego board. It is easy to utilize the blocks which are required in the application and leave the other blocks. The hardware portion of a SoC consists of components like:

Core Processor This is the most important component of the SoC as it controls all other peripherals on the SoC apart from general processor tasks.

System Memory This is divided into Flash memory for code storage, RAM for data, ROM for boot-code of the device, EEPROM, and an External Memory Interface (EMIF). The ARM architecture provides easy method for mapping memory and peripherals, leading to a reduction in SoC design time.

Digital peripherals Generally, SoCs are integrated with digital peripherals like counters, PWM, Timer, digital filters, etc. Some SoC also provide basic logic gates, flip-flops, multiplexers, and de-multiplexers, etc.

Analog peripherals Along with digital peripherals, SoCs also come with a lone list of analog components to provide mixed signal capabilities. Analog peripherals like ADCs, op-amps (comparator, amplifier, TIA, mixer, etc), current and voltage sources, etc. generally form the analog portion of the SoC.

Communication peripherals SoC are fitted with multiple communication interfaces like USB, UART, I2C, I2S, Ethernet, SPI, CAN, Bluetooth, etc. SoCs use these interfaces to communicate with external devices like another SoC, a base station, or a server.

Special I/O systems Some SoC also provide special I/O systems like capacitive touch detection and LCD and LED drivers.

Direct Memory Access Controller (DMA) To improve data access performance, DMA is also included in the list of peripherals. DMA frees the CPU from data-related tasks and hence improves overall data throughput of the SoC. DMA controllers can be configured for single/burst data transfer requests, interrupt signal on completion of data transfer, etc. Transfers of data can take place between:

  • Memory to peripheral
  • Memory to memory
  • Peripheral to memory
  • Peripheral to peripheral

Programmable Digital Blocks For applications that require digital capabilities that cannot be built using the components that exist in the SoC, some SoC vendors provide the option to build your own digital application using configurable PLDs and ALU to offload tasks from the CPU. With this functionality, the developer can make his/her own custom digital application suiting his requirement. Programmable digital blocks are known as Universal Digital Blocks (UDBs) in the Cypress’ PSoC architecture .  Each UDB is made up of two PLDs, status and control logic, and a datapath module. The datapath module is capable of performing simple arithmetic functions. Developers can describe their digital block in Verilog and have the PSoC Creator tool compile, synthesize, place-and-route, and automatically build it as part of the system.

Programmable Analog Blocks Vendors provide analog programmability using Switched Capacitor blocks. These blocks follow mimic resistance using a capacitor. Different op-amp configurations like inverting amplifier, non-inverting amplifier, filter, integrator, and differentiator can be created using a single op-amp by varying the input and feedback configurations using switched capacitances.

System Resources The system resources block is the controller block which deals with:

  • Clocking sub-system
  • Power and Operational modes
  • Power supply and monitoring sub-system
  • Watchdog timer, etc.

These blocks are connected to each other by a data bus which can be vendor proprietary or using the industry standard ARM’s Advance Microcontroller Bus Architecture which includes the Advanced High Performance bus (AHB), Advanced Peripheral Bus (APB), etc. This bus architecture promotes modular system design, provides higher performance, and reduces power dissipation in on-chip communication.

The peripherals mentioned above are highly configurable and their properties can be modified easily to suit the needs of the application. This can be done using firmware by writing to peripheral registers or using a vendor’s proprietary software GUI to modify the configuration settings of the peripherals. For example, PSoC Creator Software Suite allows developers to configure these components while designing an application using PSoC.

Figure 2 below shows a snapshot of a design built using PSoC Creator Software.

Click on image to enlarge.

Figure 2: Application built using PSoC Creator software

These GUIs also provide a schematic approach to circuit design. The circuit can be designed by dragging and dropping components from a component list onto the schematic. After this, they can be connected using virtual wires from the GUI. On the hardware level, this is managed by the interconnect system designed in the SoC. This interconnect system is highly configurable and can route any signal to anywhere on the silicon. As can be seen from the diagram above, this is an actual design to showcase low power modes but it looks like a normal paper-based design following a block-level approach.

Designing a mixed signal system: traditional vs SoC approaches
Let’s begin by exploring how SoCs have changed the way embedded systems are designed by taking an example and comparing it with traditional design approaches. Consider a basic gas sensing application which detects the concentration of CO in the environment. Figure 3 shows a functional block diagram for this application.

Figure 3: Functional block diagram of gas sensing system

In this design:

  • a hardware gas sensor is required to detect the concentration of CO gas
  • an op-amp is needed to amplify and convert the current signal obtained from the sensor output to a voltage
  • an ADC converts the voltage signal to digital value
  • a pulse width modulator (PWM) generates an alarm tone from the buzzer when the gas concentration crosses the defined threshold limit determined by the processor

Traditional system development approach
As shown in Figure 4 , generally, to design any system the developer takes the following steps:

  1. Schematic design
  2. Complete the schematic design and verify functionality theoretically before proceeding further.
  3. Component selection

Aftercompleting the design on paper, select the components needed toimplement the design. This requires substantial effort given that thedeveloper has to choose a component carefully by matching it against thedesign’s specific requirements.

PCB manufacture and assembly
Thenext step to design is to build the system on a PCB as per thetheoretical design. Assembly should be dealt with care because of highcomponent count in the design.

Firmware development
Nowthe developer moves to the next step by writing the required firmwarefor the processor. The firmware development process is fairly standardand has evolved over time. The major concern for the system developer isto write optimized code with the smallest memory footprint and no bugs.

Debugging the system
Thisis one of the most crucial parts of embedded system design. Generally,applications do not work at first go and it is critical to debug andfind what is breaking the application. Debugging a large board with manycomponents can be a challenging task because the developer has toverify signal continuity and appropriate signal presence at every testpoint to find what is breaking the application.

Mass production
After this long process to design and fix the design on a few initial boards, the design can proceed to mass production.

Figure 4: Design flow of an Embedded System

Duringany point of the development process, requirements might change leadingto a need to re-work the entire process. There might be a need tointroduce new functionality that requires adding new interfaces and/ornew components to the design.

There might be a scenario in whichthe scope of the system is changed and the developer has to replace acomponent with a more precise component. Changes like these introducedelays for the product to reach the target market and can lead to lossesfor the OEM.

SoC-based system development approach:
The traditional way of designing an embedded system is greatly simplified by the advent of the SoC. As shown in Figure 5 , all the steps of the design process become simpler and provide more flexibility in the hands of developers.

Figure 5: Component selection options in SoC

Now let us see how SoC addresses the issues faced in the traditional way of developing embedded application, as follows:

Schematic design
ASoC approach makes schematic design simpler because of a reduction inBOM. The high integration of the SoC replaces many components in theschematic, leading to a substantial reduction in complexity. The designcan then be completed using the software suite provided by the SoCvendor. This design includes all components that are required and areavailable on the SoC. Additional components/interfaces can be connectedto the SoC externally on the PCB like buzzer, LCD display, or USBhardware port.

Component selection
Components can beselected from the software suite and added to the design. Sincecomponents are configurable, they can be modified to match theapplication. Figure 5 shows the component list provided by PSoC Creator for PSoC 4 devices.

Oncea component is selected, the SoC design tool provides variousconfiguration options that make it easy to match a wide variety ofrequirements. For example, Figure 6 shows the configurationwindow of an ADC component that can be used to modify ADC properties tomatch the requirements of the embedded system.

Figure 6: Configuration window of ADC component

PCB manufacture and assembly
Assemblingthe embedded system on the PCB becomes easier than before because thereare fewer external components and hence a more compact hardware design.Internally, the components are connected through system interconnectswhich are used to route signals within the SoC, leading to a significantreduction in external connections. For example, PSoC uses global andlocal buses to route signals to/from I/O pins or internal blocks. Systemdesign by connecting components using the PSoC Creator IDE is similarto circuit design for simulation in software like PSPICE. Suchflexibility allows developer to improve their designs easily and requireless PCB re-design than conventional microcontroller designmethodologies.

Firmware development
The software suite,used for designing a system with a specific SoC, provides ampleresources to further simplify design for firmware designers. Thesoftware suite generally comes with built-in libraries of functions thatcan be directly used in the main design code. This reduces the work forfirmware engineers to write device-level code. High-level functionsalso reduce code length and improve maintainability and readability ofcode. ARM-based SoCs have certain advantages for writing systemfirmware. Thumb-2 instruction technology, for example, produces firmwarewith a smaller memory footprint while still being able to keep theperformance fairly constant. Apart from this, ARM is backed by efficientcompilers that again optimize code to a higher degree.

Debugging the system
SoCvendors provide many debugging tools which help developers to zero-inon issues and solve them quickly. Generally, all SoCs have some type ofintegrated test/debug block which is used for the debugging purposesafter hardware and firmware development is complete.

ARM-basedSoCs are provided with a JTAG or SWD interface for debugging. JTAG-basedSoCs support boundary scan testing on the device but it come at theexpense of extra pins that could have been used for other purposes.Serial Wire Debug (SWD) is two-wire debug interface that can be used toperform all debug operations with the same speed and functionality asJTAG (minus Boundary Scan capability).

ARM SoCs also provide aDebug Access Port (DAP) that works with JTAG or/and SWD debug protocols.DAP contains debug and access ports. The Debug Port (DP) communicateswith the external world and the Access Port (AP) gives developers accessto SoC resources.

This block can be used for privileged accessto the different on-board peripherals, including the processor. Apartfrom this, ARM provides multiple breakpoints (program flow) andwatchpoints (memory access) to improve step-by-step debug of the design.

Let’s go back to our previous example of gas sensing application and see how using a SoC in the system affects the design.

Figure 7: Functional block diagram of gas sensing system using SoC

Inthis application, an SoC successfully replaces multiple on-boardcomponents. Internal SoC peripherals like an op-amp, ADC, PWM, and mostimportantly a processor core are used to develop the system with theleast number of components on the PCB.

Next in Part 2 , wewill explore how the ARM architecture helps simplify the design ofcomplex applications as well as how to make design changes inapplications without negatively impacting time to market.

Subbarao Lanka is a Staff Applications Engineer working in Cypress Semiconductors onCapacitive Touch Sensing applications since 2007. His responsibilitiesinclude defining technical requirements for new capacitive sensingcontrollers, developing new capacitive sensing controllers, conductingsystem analysis, debugging technical issues for customers, and technicalwriting. He can be reached at .

Tushar Rastogi workedas Applications Engineer in Cypress Semiconductors. He has worked onPSoC based applications since 2012. His responsibilities include PSoCfirmware programming, application development, technical support tocustomers with programming, and boundary scan related issues andtechnical writing. He can be reached at  

2 thoughts on “Designing with ARM Cortex-M based System-On-Chips (SoCs) – Part I: The basics

  1. “We would like to understand the following: We understood that the processor core section of the die of this Soc controls not only the IO functionalities of the SoC but does it also control the code execution CPU functionality ? If yes then would the code

    Log in to Reply
  2. “Hello. We would also like to know how to locate all processor cores on the die of a SoC ? Does the processor core have a unique silicon design signature ? Also where on the die would we find the boot loader which loads the processor core ? If a SoC has mu

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.