SoC front-end (ARM) embedded system development and implementation (Part 1)

Introduction: In the RISC reduced instructions, it contains multiple meanings, so it is difficult to understand. However, under the full transparency of the debugger to the CPU, you can clearly see the execution of instructions and deepen your understanding of the CPU. In order to watch the execution of instructions and assembly language, we will open a window to explain the meaning of each window.

The core of an embedded system is the CPU. Once the CPU is selected, other issues can be gradually resolved. The implementation of SoC embedded systems can be divided into two types: application-oriented SoC embedded systems and development-oriented SoC embedded systems. The software and hardware development of these two types is quite different, but the first thing to encounter is the selection of the CPU. Here, the author will explain their similarities and differences, and then describe ARM CPU, instructions, system management, development practice training platform (PreSoCes), Linux and programs, etc., to establish the overall outline concept of SoC embedded systems, and cultivate and train development skills and innovation capabilities in practice.

Application-oriented SoC embedded systems refer to adding software (or OS) to an existing SoC component to make it a system; while development-oriented SoC embedded systems refer to SoC components that are still under construction. They will select only applicable IP packages and perform underlying software testing to facilitate the establishment of OS in the future and achieve the most competitive combination. The problems faced by application-oriented SoC embedded systems include: choosing a turn-key solution or building your own solution, CPU selection, OS selection, and the selection of development tools, ICE, debugger, compiler, etc. Each of them is related to each other, so it is necessary to consider from the perspective of system product development.

If you choose the Turn-key solution, you only need to modify the software you want. Most of these products are mass-produced and have the characteristics of rapid market response. Software is the display of system product functions. Most systems will have an OS installed, because the design of ARM CPU is designed to install OS, because CPU has several execution modes to facilitate task switching. Software can be divided into BIOS, Kernel, Device driver, Application S/W, etc.

The Linux OS has a debug function that facilitates software debugging. This is convenient for application software, but it is not enough for BIOS and Device driver. It is just like the early product development, where you have to burn the program and then think about where the error is. This is so inefficient. Therefore, if you have ICE and Debugger tools, it will be more efficient.

As for development-type SoC embedded systems, most of them are developed by SoC IC design companies. The content of SoC is determined by market demand, and IP components are added one by one and verified. But the problem is that pure software verification is really difficult to fully achieve 100% verification of Co-design. Before there is a more perfect solution, other methods have emerged. Due to the rapid advancement of FPGA technology, it is used as a hardware component for adding IP function verification. Not only that, it is more convenient for the front-end functional verification of Co-design to integrate software and hardware, and the development of IP has an extra layer of protection.

In terms of software, BIOS and Device driver are closely connected to the hardware. At this time, when the entire OS is not established, ICE and Debugger are needed to help debug the CPU driver program to verify whether the program execution drives each IP component normally. The design of SoC IP is another big subject, which will not be described here. After the initial functional verification, the SoC IC gradually takes shape, which is convenient for adding OS after production in the future.

In the above two types of SoC embedded systems, the key points are nothing more than ARM CPU, OS, ICE and Debugger, FPGA, and SoC. Of course, you don't have to use ARM CPU, you can also use MIPS or others, but the current global CPU IP market share is still dominated by it. The following author will describe these key points and show the development and training steps of each key technology on the practical training platform (PreSOCes). First, a simple description of PreSoCes is given to facilitate the connection of each key technology in the practical description.

PreSoCes

What are the practical functions of PreSoCes? It is a platform designed specifically for SoC embedded system development and training. It is a combination of ICE (Pocket ARM ICE or Carrier ARM ICE), Domingo Debugger, and Creator. System features: 1. Linux system can be operated in WINDOWS environment, without the need for a separate Linux PC, that is, a PC can develop Embedded Linux. 2. Debugger with Linux OS Debugging.

Creator has many features, but the main features are: (1) On Creator, the CPU module can be replaced, such as using different ARM CPUs, or FPGA modules with ARM Core, and other MIPS CPUs are also considered. (2) On Creator, the peripheral IP FPGA module can be replaced, such as: Create Ph-FPGA-XC2S. (3) Current measurement, can measure CPU, Memory, LCD, Compact Flash, CMOS Sensor, USB, Ethernet, etc. Other functional features are as follows:

CPU:

˙ARM7TDMI S3C4510 (Factory out standard)

CPU module replacement: (optional)

˙Create-ARM922T board (optional), Altera EPXA1 100K Gates

˙ARM9 TDMI S3C2410 CPU board (optional)

˙Other CPU boards (optional)

˙Other large capacity FPGA boards (optional)

Memory:

˙2MB Bytes Flash ROM

˙16M Bytes SDRAM support byte, half-word, word size

˙Access Compact flash card (compact flash card optional)

˙SDRAM Memory Expansion connector

Communication:

˙RS232C port for Debug Console

˙RS232 port for Application

˙RJ-45 10/100 Base-T Ethernet interface

˙USB 1.1 interface

Human-Machine Interface:

˙Codec function with Speaker, Microphone circuit

˙CMOS Camera Module

˙4×4 Keypad

˙LED Lamp X 8; ７-Seg LED X 4; 8 Pin DIP Switch

˙Graphic LCD Display by 4 Level

System Support (Board System):

˙1*system reset switch

˙1*JTAG connector

˙Real time clock by I2C interface

˙EEPROM 128×8 Bit

˙Clock changeable for CPU

˙Can measure current for CPU, Memory, LCD, Compact Flash, CMOS sensor, Codec, USB, UART, EtherNet, etc.

Peripheral IP FPGA module replacement: (optional)

˙Create Ph-FPGA-XC2S board (optional)

˙Other FPGA or CPCD modules (optional)

Operating System:

˙Running uClinux

˙Others

ARM CPU

After a preliminary understanding of the functions of PreSoCes, let's take a look at the core ARM CPU of the embedded system. Here, we will use the ARM Core S3C4510 component as an example. Why do we need to learn about ARM CPU? Because the embedded system is the integration of software and hardware, it has BISO and Device driver, so how can we not understand the CPU? In addition, if we want to enter the SoC IP design in the future, we must understand it even more, so the author will only explain the key points.

■The main components of the ARM7TDMI core

〈1〉. Register bank: ARM7TDMI uses register banks to store the operation domain and CPU status of various operation modes inside the microprocessor. All registers in the register bank have at least two read ports and one write port for accessing the registers. R15 is more special, with three read ports and two write ports.

〈2〉. Barrel shifter: ARM7TDMI uses barrel shifter to perform bit shift or rotation, which is one of the commonly used functions of general DSP.

〈3〉. Arithmetic Logic Unit (ALU): ARM7TDMI uses ALU to perform arithmetic and logic operations.

〈4〉. Address register and incrementer: ARM7TDMI uses address register and accumulator to select and maintain memory addressing functions to generate continuous or non-continuous memory addresses.

〈5〉. Data register: ARM7TDMI uses data register to store data for communication with memory.

〈6〉. Instruction decoder: ARM7TDMI uses an instruction decoder to generate control signals corresponding to instructions.

Figure 1 ARM core

Pipeline structure

1. Pipeline operation of complete instruction execution

2. Three-layer pipeline operation process

In this case, one Cycle executes one instruction.

■CPU data execution diagram

Figure 2 CPU data execution

CPU Data Execution Diagram Description

This article uses a simple addition operation with two registers (Rm and Rn) to illustrate:

1. Send (Rn and Rm) to A BUS and B BUS respectively.

2. After the Rm on the B BUS is shifted by the Barrel Shifter, the result is integrated with the Rn on the A BUS in the ALU for the operation.

3. The final calculation result will be sent back to register Rd via ALU BUS for storage.

4. The program counter result is updated through the Address incrementer and the value is written back to the program counter.

5. At this time, the Address BUS updates the data address and proceeds to the next step of command capture; the memory will send the instruction to the Data BUS for further instruction decoding and execution preparation.

■Programmer Mode

Register

There are 37 ARM Mode registers, including 31 32-bit general registers and 6 status registers. Different registers are available for use in different operation modes.

Table 1 ARM Mode Register

The THUMB Mode register is a subset of the ARM state registers, which consists of 21 32-bit general registers and 6 state registers. Users can directly use R0-R7 and PC, stack pointer register (SP), link register (LR), CPSR and SPSR.

In the register groups of the two states, there are shared registers and individual registers, which is convenient for the program parameter conversion of the OS task switch.

■Memory format

ARM7TDMI accesses data in memory in bytes, starting from 0 and accessing linearly upwards. That is, byte0~byte3 will be accessed as a word first (in ARM, a word is equal to 32 bits; that is, 4 bytes), followed by byte4~byte7... and so on. Which of the 4 bytes of a word stored in the memory will be placed at the highest position? Which will be placed at the lowest position? At this time, ARM provides two formats for designers to use---Big Endian and Little Endian.