You are currently viewing SemiWiki as a guest which gives you limited access to the site. To view blog comments and experience other SemiWiki features you must be a registered member. Registration is fast, simple, and absolutely free so please, join our community today!

  • Performance Analysis for ARM Based SOCís

    ARM estimates that many SOCís designed today have over 200 IP components. This statistic comes from a recent white paper ARM published addressing the topic of system performance analysis. This number is only going to go up. According the ARM this creates a huge challenge in ensuring the system is designed with adequate performance margins. Conversely, over-design comes with high costs in terms of silicon area and power consumption. Their white paper is the first in a series that talks about how ARM is helping their customers model system performance at the earliest possible stages of the design process.

    System performance in a SOC is in part determined by the following factors:

    • Processor speed (CPU, GPU, Video, Display, etc.)
    • Cache types and sizes
    • Interconnect
    • Memory speed, efficiency and data width
    • Effectiveness of IP integration

    To facilitate their customersí implementation projects, ARM has embarked on a program of developing and utilizing performance analysis methodologies on SOC designs. They are pursuing this internally as well as with customers. They see high value in making sure that performance analysis can be done effectively and systematically. ARM describes a multi-step process that they have developed.
    Article: Kaufman Award Dinner at 50th DAC in Austin-subsystems-min.jpg
    As you might expect the first iteration is done with a spreadsheet. This is where the most fundamental issues such as bandwidth and latency are estimated for the first time. Immediately after this ARM constructs a model of the system including the path from the major IP blocks to the memory. This is exercised with verification IP to simulate traffic first for single IP blocks, then IP blocks in combination. This is where latency and traffic management are looked at. If there are no fundamental bottlenecks and the system is dimensioned properly, the next level of analysis can begin.

    Key master IP such as CPUís and GPUís are run individually to see if they have enough data bus bandwidth with sufficiently low latency. Real world effects like competing traffic, shared resource competition, and other system loads can be modeled for more insight. Code for these tests typically run on bare metal to avoid the complexities of operating system issues. Single and multiple CPU interactions are examined at this stage, including ARM big.LITTLE technology. At this point, there probably are benchmarks or real world test cases to take advantage of.

    Video codec performance in the system is tested for the gamut of encode formats, bit rates, pixel type, frame sizes, etc. These are run in isolation and in combination with other IP components. Due to the real-time nature of this data, the penalty for delays is high. If part of a frame is late, the entire frame might need to be dumped. Stress testing at this phase is essential to proper system function later.

    Other ancillary functions are layered on for system performance analysis. There may be DMA, DSP, security, communications, and other blocks that all need to be factored in. Also modeling will shift to include code running on OS software.

    ARM is running these kinds of analysis internally to validate their IP and the performance levels that finished products incorporating them can achieve. Various levels of abstraction are used Ė everything from static analysis through RTL, gate, FPGA and silicon. Software simulation and emulation are both used as needed.

    ARM also works closely with their licensees, and shares their knowledge and experience in this kind of analysis. The goal is to work early in the process to anticipate system needs well in advance of the point of no return for design decisions. If you are interested in reading this white paper and the upcoming subsequent follow-on piece, look here on the ARM website.

    Read Other Articles by Tom Simon