Browse > Home / 信息中心 / SNUG / 2005论文集 / A VIP based SoC architecture evaluation methodology

A VIP based SoC architecture evaluation methodology


LIN Yinfang, ZHOU Li
(Freescale Inc, SuZhou Design Center, China)

Abstract

Rapid growth of application field and complexity of System-on-Chip(SoC) require efficient system-level design methodology. To design complex embedded SoC system, several issues should be addressed: 1) Establish SoC architecture topology after defining appropriate application requirement. 3) Define connectivity architecture between different components. 4) Evaluate system performance in different application situation, find bottleneck point in architecture. 5) Re-structure SoC architecture to meet performance and application requirements. Establish and evaluate SoC architecture to meet it is the most key point of chip success. But different MCU architecture, mixed bus component, diversity memory controller, various re-use plan, etc., all parts has tight relationship with each other. It is hard to estimate system performance when putting all SoC parts together. This paper presents a Verification IP (VIP) based SoC evaluating platform design methodology. It reuses Synopsys VIPs to setup SoC evaluation environment, applies Constrained Random Testing (CRT) methodology to obtain closer performance estimation. Based on it, SoC system architecture can be structured and evaluated efficiently.

Key words － SoC, architecture, evaluation, VIP, CRT.

I. Introduction

Quickly developing consumer electronics and multimedia markets desire more parallelism and powerful System-on-Chip (SoC) systems. The main characteristics of SoC are its complex architecture components and its various application fields. To integrate abundant application function together, system performance evaluation becomes the most important and critical task for system design.

Two questions, how to evaluate system performance on a planning SoC architecture, how to build SoC architecture by analyses, should be solved firstly. Based on these requirements, a VIP based SoC architecture evaluation platform is designed and implemented. It can produce reference data to assist SoC system design, including:

● Determine how architecture organized can gain highest system performance.

● Determine whether structured architecture can meet application performance requirements

The rest of this paper is organized as follows. Section Ⅱ illustrates current SoC architecture and system performance evaluation methods. Section Ⅲ outline a Verification IP (VIP) based SoC evaluation methodology. A real design case of VIP based SoC architecture and evaluation platform is described in section Ⅳ. Experiments results and test data are reported in section Ⅵ. Section Ⅶ concludes the paper.

II. SoC evaluation method

Conventional system architecture design method cannot do performance evaluation before whole RTL design built up. If system architecture and performance cannot meet application requirement, much more effort have to spend on modifying RTL design, even abandon whole system architecture, and start a new project design process. Obviously, this method will put SoC company to an incompetent situation.

Another system architecture and performance methodology is Transaction-Level Modeling (TLM), which is commonly used to setup SoC evaluation environment. One typical tool is System Studio, which can be used to build up SystemC behavior functional models to evaluate SoC architecture and performance. The main advantage of System Studio is its abundant functionality integration and systemhigh-level description. But these advantages are in cost of developing many SystemC models to setup the environment. It is hard to imagine how many works would be spent to build such complex SystemC SoC from very beginning.

To build SoC evaluation system, the most efficient way is to re-use some mature RTL modules, integrate them with high-quality VIP to compose a SoC. With more and more diverse IP and VIP model library, this method can not only reduce SoC design cycle sharply, but also can imitate a real system as much as possible.

III. Outline of VIP based SoC evaluation system

1. Background

The general architecture of SoC includes MCU core, memory controller, Application IP (AIP), and peripherals. The most important parts are MCU and memory controller, which determine system performance. All AIP, such as multi-media processing, Ethernet accessing, USBOTG, etc., can all be connected to MCU core or memory controller as bus masters.

To some extend, establishing SoC architecture is to arrange AIP appropriately in whole system. There are mainly three arrangement plans:

● Directly connect all AIP to MCU core, through one bridge between MCU core and memory controller to access external memory.

● Directly connect all AIP and MCU core to memory controller for accessing external memory.

● Allocate AIP to MCU and memory controller.

For the first choice, system design is simplified, but at the cost of low performance. Because when using external SDRAM, accessing different page in same SDRAM bank will have many clock cycles latency. The SDRAM accessing latency has no way to be hided except two or more channels send data requests to SDRAM simultaneously.

So there has the second choice. Memory controller has several input channels. SDRAM accessing latency can be hided between different channel accessing. But the number of input channel in memory controller is limited, which confines available AIP number on its interface.

The best way to balance these perplexities is two level accessing hierarchies, as shown in Fig.1 (ARM core is used), which includes AHB arbiter and memory controller. This architecture not only can increase SDRAM accessing efficiency, but also can connect more application request channels. Higher system performance and functionality can be realized based on this architecture.

In such two-level system architecture, several issues have to be solved:

● How to allocate application oriented resources.

● How to optimize the performance.

● Whether determined architecture can meet system performance requirement.

2. VIP based SoC evaluation system

VIP is well-verified simulation model of industry standard busses and protocols that generate or respond to stimulus. With increasing of system complexity, VIP is playing an important part in modern system verification methodology. Besides its verification purpose, VIP can also be used to setup SoC evaluation system. First, efficiently implemented VIP can be used to model SoC core blocks and rapidly architect the system before RTL are available. Second, Synopsys DesignWare VIP provide the function such as Constrained Random Testing (CRT), which is capable of quickly implementing block interfaces and generating concerned bus traffic to create complicated testbenches.

VIP based SoC evaluation system is shown in Fig2, where ARM platform, Memory controller are integrated together with VIP. Since these AIP perform AHB transactions at AHB arbiter and memory controller interface, AMBA AHB VIP can be used to model their functions. Due to VIP’s CRT functionality, AIP’s different AHB behaviors can be modeled well.

After establishing such evaluation environment, system engineers can do validation work for system performance, like data throughput, required memory structure etc. In this way, system architecture and performance estimation can be performed in advance, which make more confidence and assurance to continue following design stage and reduce product development time.

IV. Solutions

1. Test environment.

Based on architecture proposed in Fig.2, test environment was built and implemented using Verilog, DesignWare Verification IP and Denali memory models running on VCS simulator. Where, ARM platform, memory controller and some other blocks are mature RTL modules, which can be reused from other SoC. All AIP apply Synopsys’ AMBA2.0 AHB Master VIP to model their AHB transactions. Fig.3. shows the test environment and test flow is illustrated in Fig.4.

2. VIP modeling methodology

Different AIP has its own read/write characteristics. Various application parts in SoC have specific memory accessing feature, data throughput, and particular transfer type and function priority. All parts determine AIP’s transaction behaviors. Table.1 gives some AIP features used in SoC.

Although these AIP have different function characteristics, they are all AHB bus masters. This provides the possibility to model their functions by customizing suitable random constraints for AHB VIP. CRT is the functionality that is provided by VIP to realize it. There are three types of CRT objects can be used to generate complex stimulus, including protocol transaction generator, transaction sequence generator and transaction choice generator. For example, AHB Master VIP supports 14 CRT protocol transaction attributes, including Transfer Type, Transfer Size, Burst Type and Starting Address etc. Combined with transaction sequence or transaction choice generator, random constraints can be generated based on AIP various functions, which is the key point to build VIP based SoC evaluation system.

Common constraints for all AIP can be described in expression (1). Table 2 shows its related parameters.

(1)

According to features presented in Table 1, different AIP models can be created by setting the corresponding constraints. Actually AIP’s behaviors are much complex than this. For example, MPEG processing usually reads one macro-block (e.g. bytes) from non-sequential memory address, then writes back and repeat the whole process. This behavior can be created by CRT’s protocol transaction and sequence generator. Fig.5 shows a CRT example which MPEG AHB transactions are generated.

Using the same methods, other AIP can be modeled as well. With these VIP models, an evaluation system can be established based on two-level SoC architecture.

3. AIP allocation plan

An allocation plan should be considered firstly based on different accessing demand of AIP, including priority, data throughput, etc.

Based on above requirement, LCDC should be connected directly to memory controller with highest accessing priority. Multi-media processing part, such as MPEG, will have deep influence on system performance because of their heavy data-loading requirement, and also connected directly to memory controller. Other AIP, like USB, DMA, have lower accessing priority and performance influence, can be connected to AHB arbiter part. Initial allocation plan is shown in Fig.6.

4. Architecture optimization scheme

Some optimization scheme is raised to improve system performance as well. Memory controller IP can not hide SDRAM accessing latency when modules perform transaction because it’s Unspecified Length Burst (ULB). It can be hided only when several masters send fixed burst length data requests to it. While many AIP (including LCDC, DMA etc.) use for simplicity of design. If these transactions are transformed into fixed burst length, more SDRAM accessing cycles can be saved. An OVERRIDE module can be

used to transfer

to　　

without any changing of present module design. OVERRIDE is expected to increase bus utilization of SDRAM and improve system performance. This optimization can be evaluated in VIP based SoC evaluation system efficiently.

VIP based SoC evaluation system can not only assist architecture design, but also can be used to estimate system performance, calculate data throughput. VIP constraints obtained from real application function can realize these cases well. Through modifying different constraint conditions, SoC architecture can be validated and optimized.

V. Experiments and Analyses

According to above solution scheme, experiments are implemented on VIP based SoC evaluation environment, which validate: 1) AIP arrangements in architecture are reasonable; 2) OVERRIDE is effective to improve system performance; 3) system performance requirement can be met.

1) Respectively connect MPEG models to memory controller and ARM side, data throughput testing results for image data are shown in Table.3.

Condition Data throughput(Mbytes/s)

memory controller side 28.88

ARM side 12.25

Typical requirement 18.43

Note: MPEG typical data throughput requirement is calculated by . Here, suppose using VGA image, 30fps, Y:U:V=4:2:0, 1.5byte represent one pixel, after encoding, one pixel is approximately compressed to 0.5 byte.

Table 3 indicates that these two choices have much different performance behaviors. To meet MPEG application requirement, it is really better to put it straightly to memory controller.

2) Add OVERRIDE architect to AIP using ULB. According to various ULB characteristics for AIP (such as Incr1~4, Incr1-8) shown in Table 1, bus utility ratio of SDRAM transfer applying respective OVERRIDE bypass, Incr4, Incr8 and Incr16 are shown in Table 4.

From Table 4, Incr4 OVERRIDE reach best result for Incr1~4, Incr1~8 is benefited more with Incr8 OVERRIDE. Incr16 OVERRIDE obtain obvious performance advantage over Incr1~16 and Incr8~16. Therefore, OVERRIDE can be added to AIP with specific ULB behaviors. For example, by adding Incr4 OVERRIDE to MPEG, Incr8 OVERRIDE to Pre/post Processor, and Incr16 OVERRIDE to LCDC, DMA, USBOTG, more efficient SDRAM transfer can be realized and improve bus utilization with smaller additional hardware cost.

3) Test in worst scenarios, whether system performance can meet AIP requirements. In some real multi-media applications, many AIP would work together at the same time. For example, there is an application case like:

● Image coming from CMOS sensor and sent to memory ( through DMA)

● MPEG encode/decode image data from memory, and store back to memory.

● Pre/postprocessor get image data from memory and then write back.

● Encoded bitstream is output through USBOTG.

● Encoded bitstream is transferred in by Ethernet.

● LCDC get decoded data from memory and display it.

In this situation, many AIP work together as shown in Fig. 7. Data throughput of AIP is shown in Table 5.

Note: Here, using image case same with Table 3.

1. Data throughput of pre/postprocessor is

2. Data throughput of LCDC is .

3. Data throughput of USBOTG is .

4. Data throughput of DMA is .

5. Data throughput of Ethernet is .

Compared tested results with required data throughput, such architecture design can meet SoC application performance requirement.

VI. Conclusion

Fast growing application oriented SoC system urgently request efficient method to evaluate its architecture components, system performance, bus loading, and so on.

A VIP based SoC architecture and performance evaluation system is launched which combines advantages of VIP and two-level SoC architecture.

Maturity, easy-to-use, and CRT are excellent qualities of Synopsys DesignWare VIP. The combination of VIP and abundant IP vender library can constitute efficient SoC evaluation system. This concept is based on a new design philosophy, which offers new opportunities for SoC evaluation and performance estimation.

Through VIP based SoC evaluation platform, system performance and architecture optimization based on under-designed architecture can be easily obtained before real RTL design finish. It provides an efficient methodology to assist SoC design and evaluation in early design phase, which will further bring advantages in time-to-market, and competent capability.

This method is particularly suitable for SoC system development phase, which has less prophet ion about whole system behavior. It has been successfully used in one of our SoC design project, and obtained very good and useful design references.

Acknowledgments

VIP based SoC evaluation system is owned by Freescale, SuZhou design center. We thank the entire design group for their creative and great contribution. Their hard efforts are high appreciated.

References

[1] T. Michael, Horne, Verifica LLC, Portland, “Verification IP Qualification and Usage Methodology for Protocol-Centric SOC Design”, Design & Verification Conference, Feb.15, 2005.

[2] S. Sudharsanan, “Performance evaluation of a DVD processor using transaction level models”, Consumer Electronics, 2004 IEEE International Symposium, pp. 375-380, Sept. 1-3, 2004.

[3] Synopsys, “Vera User Guide”, Version 6.2.3, Dec. 2003.

[4] Synopsys, “DesignWare AHB Verification IP Databook”. Version 2.45b, Aug. 2004.

[5] ARM, “AMBA Specification”, Version 2.0, May.13, 1999.

LIN Yinfang Master in the department of information science and electronic engineering at Zhejiang University, Hangzhou, China. Now working in Freescale, Suzhou Design Center as IC design engineer, responsible for SoC verification methodology etc.

ZHOU Li Ph.D graduated from the department of information science and electronic engineering at Zhejiang University, Hangzhou, China. Now Working in Freescale, Suzhou Design Center as IC design engineer. Interests include R&D of system on chip, etc.