Introduction to ARM-based SoC design [zz]

Article 1Article, Explains the basics of SOC design!

Address: http://blog.163.com/gene_lu/blog/static/64025421201111872144184/

 

We skip all the descriptions of arm and directly go to the questions most concerned by engineers.
To design an ARM-based SOC, we must first understand an ARM-based SoC structure. Figure 1 shows a typical SOC structure:
 
Figure 1
From figure 1, we can understand the basic structure of the SOC:

• ARM core: arm966e
• AMBA Bus: AHB + APB
• Peripheral IP (peripheral IPS): Vic (vector Interrupt Controller), DMA, UART, RTC, SSP, wdt ......
• Memory blocks: SRAM, flash ......
• Analog IP: ADC, PLL ......

If the company has decided to start designing an ARM-based SOC, we will face a series of issues related to these basic components. In the following sections, we will try to discuss these issues.

1. Which kernel should we choose?
Indeed, arm provides a lot of options for us. From table-1 below, we can see different features of different arm kernels:
 
Table 1
Arm has provided the following basic references:

• If you are developing embedded real-time systems, such as automotive control, industrial control, or network applications, you should select Embedded Core.
• If you are developing an applicationProgramSelect application core as the primary operating system, such as Linux, Palm OS, Symbian OS, or Windows CE.
• If you are developing a system that requires security and confidentiality like a smart card, SIM card, or POS machine, you need to select secure core.

For example, if we need to design a Soc for VOIP phones today, because this application does not need to use the operating system, we can consider using a kernel without MMU. In addition, because network protocols require high real-time performance, we can consider the kernel of the arm9-series. And because VOIP has voice codec demand, so need to have DSP function expansion kernel, so ARM946E-S or ARM966E-S should be more suitable for choice.
Of course, the problem in actual work is much more complicated than in this example. For example, in the previous example, we can also select the ARM7TDMI kernel and add a DSP Solution, arm is used to control the system and process network protocols, and a separate DSP is used to complete the speech codec function. We need to compare the advantages and disadvantages of different solutions in terms of area, power consumption, and performance. At the same time, we also need to consider issues such as cache size, TCM size, actual kernel operating frequency, etc. Therefore, we need a tool that can build Rapid modeling to help us decide these problems. The current EDA tool provides us with such a possibility, such as Synopsys? CCSS (cocentric system studio) and axys? Company maxsim? And other tools can help us achieve rapid modeling, and provide a software simulation platform before the hardware is implemented, so that we can perform soft-hardware joint simulation on this platform, assess whether the hardware we envision meets the requirements.

2. What type of bus structure should we choose?
while providing the kernel to us, arm also provides a variety of bus structures. For example, ASB, AHB, AHB lite, Axi, etc. While defining what bus to use, we also need to evaluate what bus frequency can meet our needs, at the same time, it will not consume too much power consumption and On-chip area. This is what we usually call architecture optimization.
similar to the previous issue, we also need to use a quick modeling tool to help us make a decision. Usually, these tools can provide us with a very high abstract Tlm (transaction level models) model to help us with modeling. Common IP addresses can be found in the libraries provided by these tools, for example, various ARM core, AHB/apb bfm (bus function model), DMAc, and various peripheral IP addresses. These tools and Tlm models provide 100 faster than RTL simulation ~ It has 10000 times of soft-hardware performance, and provides system analysis functions. If the system architecture cannot meet the requirements, what is the bottleneck in the system? Is the kernel speed insufficient? Is the bus frequency too low? The cache is too small? Or is there too much interruption response overhead? Do you need to add DMA? And so on. We can solve such problems with the help of tools.
of course, the machine is not omnipotent. Don't expect a tool to tell you where the problem is and how to solve it. What the tool can provide you is just some statistical data, our engineers need to analyze the problem and come up with a solution. Therefore, it is necessary to be familiar with the AMBA architecture and ARM kernel.

3. How do I select a peripheral IP address and use a ready-made IP address or custom it?
the biggest advantage of using IP addresses is time to market. Arm provides a large number of peripheral IP addresses for us to choose from. The peripheral IP address set (primecell? IP addresses) include the vast majority of commonly used peripherals. For more information, see table 2:
Table 2:
primecell? The number of IP addresses has been increasing. Arm will occasionally publish the latest available primecell on the website? IP, details reference:
http://www.arm.com/products/solutions/PrimeCellPeripherals.html
arm in addition to providing RTL for these IP addresses, it also provides drivers and testing programs for these peripherals.
it makes it easy to use a ready-to-use IP address, but it also limits flexibility. For example, when we need an SPI bus interface, we should use the arm SSP (Synchronous Serial Interface) IP address, but in order to provide, ti SSP and NS Microwire are compatible with each other and sacrifice the on-chip area, resulting in increased IP complexity. If our application only needs to be compatible with the Motorola SPI standard, why should we need such a complicated IP address?
although custom IP addresses have the advantage of flexibility, design engineers must complete their own verification and develop drivers for this IP address. My suggestion is to analyze the specific situation. When selecting an IP address, you can also consider the AMBA-based standard IP address provided by a third-party company, such as Synopsys?? There are many AMBA-Based IP addresses available in the IP library. Sometimes these IP addresses provide better flexibility than arm IP addresses and use less on-chip area and power consumption at the same time. For example, memory controller, designware? The dw_memctl of is more flexible than the mpmc (multi-port memory controller) of arm, and more parameters can be customized. About designware? For more information about IP, see
http://www.synopsys.com/products/designware/designware.html

4. How to verify the self-designed IP address connected to the AMBA bus?
If we do need to design the IP address connected to the AMBA bus by ourselves, it is necessary to be familiar with the bus standard of AMBA. But the design is often not a problem. The question is, how can we verify that our IP addresses comply with all the behaviors defined by AMBA standards?
As an IP address verification, we often use the so-called component-based verification, as shown in-2:
 
Figure 2
In Figure 2, we want to verify a usb ip address. This USB Module is directly connected to the AHB Bus. In our testbench, we need various verification IP addresses as shown in ), to simulate all the situations that a USB Module will encounter in the real bus structure. These VIPS can be provided by EDA vender or written by engineers. However, generally these VIPs are not written in the HDL language, but in the HVL (hardware verification language) language. E ?, Vera and other languages, of course, also need to use tools that support these languages, such as verisity? Specman ?. Because the behavior on the system high-speed bus (usually AHB or Axi) is complicated, I suggest that such VIP should not be developed by engineers themselves, and try to use EDA vender to provide a well-tested VIP. For low-speed Peripheral Bus (APB) or SPI, I2C, USB and other bus, it is feasible to develop the BFM model and monitor by yourself.

5. How can I verify the built platform?
We have selected the appropriate ARM core and bus structure, selected the appropriate IP address, and built the building blocks. The top is complete, and the problem also comes. How can we verify top?
The verification of SOC is indeed a big problem. Especially after the emergence of the IP-based SoC design method, there is a gap between the engineer's design capability and verification capability, that is, we can complete the design in a short period of time, but it needs to be verified several times over the design time and manpower. The most time-consuming work generally occurs in the SW/HW co-simulation/Co-verification phase.
As you know, the higher the abstraction level, the faster the simulation, and the slower the reverse. Therefore, if all the modules in our top files are RTL or gate level (including ARM core ), the simulation speed is unacceptable to anyone, so the practical method is to use the DSM (Design Simulation Model) model of ARM core. Method 3:

Figure 3
We can see in Figure 3 that we have used Behavior Models written in advanced languages for both the kernel (processor) and memory controller, and use the PLI (program language interface) language between these behavior models and real RTL interfaces. Of course, all other peripheral IP addresses and bus structures still use RTL (because we want to verify these RTL ). Most DSM models are provided by IP providers. If ARM core is used, it is provided by arm. The software is compiled by the development tool (ads, realview) provided by arm to generate binfiles, and then stored in the memory model.
Now we can start the simulation. The arm DSM model will generate a log during the simulation. EIS file, which records all commands that ARM core has run in sequence. Through this file, we can debug the software.
However, it is very painful to debug the software using this file, because the engineer not only cannot interrupt, track, or execute the software in one step, in addition, you cannot use the semihosting function to transfer file operations and debugging information. If you can use axd or realview debugger to debug the software, it will bring great convenience to engineers. Therefore, EDA also launched related products, such as mentor graphics? Company seamless? And the axys we mentioned earlier? Company maxsim? And other tools can provide interfaces for collaborative simulation with axd or realview debugger. In this way, we can debug the software on the simulation platform just like upgrading the software on the target board.
The simulation speed at this abstraction level is faster than that on the pure RTL platform, which can be approximately 1 ~ The speed of 100 commands per second. It is feasible to verify the driver and startup code on such a platform, but if you want to verify the full functionality of the application, especially for applications with operating systems, such a platform is still too slow. For example, how to start a uClinux instance on a platform like this ?, It usually takes weeks. Obviously, it is unrealistic to verify the application at this speed.
To solve this problem, we have two options:
(1) use hardware accelerators
Some EDA vender will provide related solutions, such as Cadence? Company's Palladium? Accelerator/emulator and mentor graphics? Vstationpro? Emulation System. These are accelerators that can accelerate our simulation, but they are generally expensive. Therefore, for most design houses, this method is not only cost-effective, but also unnecessary.
(2) Use an FPGA prototype for testing
This method is realistic for most companies. This is our next question.

6. How to complete FPGA prototype verification?
Complete FPGA verification is essential for Chip function verification. At the same time, as we mentioned in the previous question, it is very difficult to complete functional verification without FPGA prototype help. Specific to the ARM-based SOC, we can choose the following methods:
(1) integrator provided by arm? Prototyping Board
Arm provides a set of functions called integrator? The development kit allows engineers to build a verification platform that is as consistent as possible with the design chip on this kit. In short, arm provides integrator? CT (core tile) is used to implement the functions and behaviors of the corresponding ARM core? LT (logic tile) is used to implement all the digital logic (integrator? Lm has an FPGA), using integrator? The IM (interface module) connects the simulator and inserts the three boards into the Integrator as the child boards? AP (ASIC development platform ). In this way, a SoC is installed just like a computer. On this platform, basically all functional verification can be done, as long as you do not have too high frequency requirements (for example, in your application, ARM core runs at 100 MHz ), this platform can complete real-time testing.
(2) FPGA verification platform provided by third-party vendors
For example, aldec? Company's Riviera-ipfpga verification system. The hardware of this system is a PCI interface board. The core of this board is an FPGA. Our digital logic is still in this FPGA. At the same time, can different ARM core integrator be inserted on this motherboard? Cm. This system can provide the same performance as the arm solution, but it has more flexibility than the arm solution.
Riviera provides a function that allows ARM core, FPGA's integrated logic, and integrated RTL third-party collaborative simulation. We can reuse the testbench, incentive, and parameter output used for simulation in the workstation environment, and move RTL to FPGA in the same way as building blocks. That is to say, at the beginning, all RTL and testbench can be simulated on the PC (of course, the simulator provided by Riviera is used), and the simulation speed is relatively slow; once the engineer thinks that the RTL is OK, he can integrate the RTL into the FPGA. As more and more modules enter the FPGA, the simulation speed will get faster and faster. Finally, all the digital logic is integrated into FPGA. Another advantage of establishing interaction between RTL simulation and FPGA is that FPGA Debug brings us a lot of convenience. Engineers who have debugged FPGA often have painful memories. Because FPGA internal signals are invisible and FPGA Debug is often very consumable, Riviera provides RTL and FPGA joint imitation while, it also provides the ability to observe FPGA internal signals, similar to Xilinx? Chipscope. For details, refer to the webpage:
Http://www.aldec.com/products/riviera-ipt/pages/coverification/
(3) self-developed FPGA prototype Board
However, if you design your own FPGA prototype board, engineers will have the maximum flexibility and can place any desired Device on their own development board. The FPGA can be used as close as possible to the actual running speed of SOC. If an analog IP corresponds to an analog device, the coverage rate of function verification will be very small, minimize the risk of unsuccessful projection. The cost of this solution is the design and debugging of the verification board. Sometimes this time exceeds the chip design time and requires engineers to have knowledge about designing high-speed PCB.
The test sample of ARM core is the core of the verification board. This test sample is actually obtained by directly taking the kernel to the stream chip (of course, the necessary PLL must be added ). Generally, foundry authorized by arm provides such a test sample. It should be noted that the test sample can meet the speed required by the application. If not, real-time testing is impossible.
Another issue to be noted is the FPGA capacity. When integrating the AMBA bus structure with FPGA, engineers will find that the RTL Based on the AMBA bus consumes an astonishing amount of FPGA resources, sometimes a 150 K gate count digital logic cannot be integrated into a 1.5 million-gate FPGA (such as Xilinx? Xc2v1500), so you must select an FPGA (or several FPGA arrays) with a margin at the initial stage of the verification board planning ).
Author: Jiang Yanbo
Italian legal office conductor Shenzhen Design Center