An Example Verification Environment for Different Types of Processor Models

Emrah Armagan, Ericsson Microelectronics (EMDC)
Laurent Dawance, ST-Ericsson
Funda Kutay, Ericsson Microelectronics (EMDC)
Ates Berna, Ericsson Microelectronics (EMDC)

Abstract :

Embedded systems are getting significant attention in current integrated circuits due to their direct control on the overall circuits` performance and functional capabilities. Commonly used processors generally provide various types of simulation models to designers to handle verification of the embedded processor with the related system and to find any erroneous cases in early steps of the design. Throughout the development steps such as system design, hdl design and verification, different teams and even members of the same team may prefer different languages and abstraction level models, which cause a great diversity in both methodology and knowledge sharing. This creates great difficulty for the design, verification and firmware teams, preventing them to present a unified methodology that supports all the needs in the same core. The presented approach is based on the initial interest for making processor system verification independent from vendor specific models and creates a unified system that can handle different models with adaptation wrappers on the coding language. With the aid of presented methodology, a unified structure is developed for firmware tests and design verification tests in C language.

This study describes a C code wrapper that supports ARM DSM functional verification and a TLM based verification with a unified test code on ARM CortexM3 processor.

I. INTRODUCTION

The widespread availability and use of various multimedia content supported by different communication standards or applications has created a great need for faster and powerful processing units in embedded systems. This has driven demand for an optimum performance with available processor configurations and improves the importance on processor sub-system verification through all design steps.

Verification of processor itself and related sub-systems with different models is not a question of preference but a need based on different precision granularity expected from the models. For example, system validation and RTL validation of the processor peripherals will be examined by high level model (TLM), processor throughput and impact of processor cycles will be checked by DSM. Additionally, physical verification of the system will be done by provided ARM processor netlist.

The objective of the work presented in this paper, was to build a unified environment for the processor itself and related sub-system, such that verification through different steps could be executed on a wrapper that handles various types of processor models and improves consistency supported by each model with decreased resource usage.

With the aid of this environment, a widely used test language will be selected at the beginning phase and this could be used in firmware and design verification steps without any modification for any model. We have chosen C language as a common test code language and build the flow from specification to header file generation and test design according to the language dependent constraints. Unification of environment is provided by specific wrapper adaptation interfaces for the available ARM DSM and an internally developed TLM model for CortexM3 processor. The methodology that we followed is not strictly dependent to any specific product and would be easily adapted for other models and interfaces with maximum resource saving in overall verification steps. It is a very practical solution to enhance verification of embedded processors with several models without any impact on time or resource consumption.

II. GOALS AND OBJECTIVES

From idea to realization, it was aimed to build a verification environment that supports many processor models and also can be easily used by other teams with same test code language without any core, TLM - DSM, model knowledge. It was also a short-term objective to deploy this method for the next verification release of the IP in one month.

III. THE SITUATION AT THE START

The project, that the implementation done was a commonly used IP in communication platforms which has some improvements in RTL implementation, processor sub-system and verification methodology. There was a requirement for this project to build a UVM based verification environment with support for multiple processor models. It was also an option to support multiple processor verification model tests with a unified test code. It was a challenge to understand and check if it was feasible to implement this unification without sacrificing any model advantage such as fast execution and easy debugging, but there would be earnings for the whole team by improving efficiency and consistency.

IV. UNIFICATION OF THE ENVIRONMENTS

There are two main parts of the flow;

1. Feasibility Phase: Understanding model behaviors, supported test functions and languages for each model to be used. Developing a common function set consists of generally used and needed functions.

2. Unification Phase: Building the structure and defining the unified functions accordingly. Wrapping separate model environments to support new functions for the unified methodology.

A. Feasibility phase

All the processor models, in the verification environment, needs to be well understood and investigated. That means the functions supported or unsupported by any model needs to be clarified before to prevent any issue in later stages.

Common and needed functions need to be well defined in feasibility phase such as;

• write 32 bits
• read 32 bits
• write 16 bits
• read 16 bits
• write 8 bits
• read 8 bits
• main
• wait for
• wait for interrupt
• print and etc.

Model compilation environment with test codes will also be detailed and listed for smooth integration of additional wrapped environment. Compilation script mechanism and paths will be noted and adaptation of scripts will be done according to the needs of file caching and access mechanisms of the design structure.

Different elaborations snapshots will be defined with some define statements in the scripts to eliminate unwanted behaviors of the design. Those snapshots are needed to provide linking between correct processor instantiated RTL and wrapper interfaces of unification.

It would be first good to have working environments separately and unify them later. We built an environment for ARM DSM in the first place. By using a simple register write/read access test, we verified this standalone environment was ready. Then similarly we built another environment using the TLM instead of ARM DSM and perform similar register access test to verify system behavior was working. The unification part was done afterwards which is defined in the next section. It would also be good for the integrator to have dedicated debugger interface/tool knowledge of the models to overcome problems quickly.

B. Unification phase

Unification is the main step for having a unified test environment supporting different processor models. In our case, ARM DSM and TLM models were used to mimic processor behavior and system interfaces in the design for verification purposes. These two models are different in both operation and structure so we followed the same flow for unification purposes to create a unified environment. Details are given in the following paragraphs for each processor model.

DSM is the model provided by ARM and has its own code compilation and object linking scripts. Initially, we create an alternative list of codes to be compiled by arm compiler to generate instruction list for DSM model. Our wrapper codes are also included in this list that helps the compiler to interpret DSM functions as our defined functions. This could be called as a redefinition of the functions with common names. After this step, writing a new test code with unified functions works properly with arm compiler to compile them as ARM instructions.

Table I includes some example functions of DSM model and their unified conventions. In the implementation period it was decided to keep some DSM functions as the unified naming convention.

TABLE I: EXAMPLE DSM FUNCTIONS FOR UNIFICATION

	DSM Function	Unified Function
Main Function	MainTest	main
32 bit write	write32	write32
Wait for interrupt	WFI	__wfi

Figure 1 is a short overview of unification flow.

Figure 1: Overview of unification flow.

TLM functions were more or less similar to DSM functions in functionality but background operation is different. Since we defined the unified language in feasibility step, it was also a kind of redefinition of TLM functions with a wrapper function interface.

Table II includes some example functions of TLM model and their unified conventions.

TABLE II: EXAMPLE TLM FUNCTIONS FOR UNIFICATION

	TLM Function	Unified Function
Main Function	esw_main	main
32 bit write	esw_write32	write32
Wait for interrupt	esw_sleep	__wfi

Redefinition of the model specific functions is the most important but not the last part. We also adapted our RTL elaboration and model instantiation parts accordingly to use correct snapshot and use correct wrapper for the model in the C test code. Building such configurable environment also helped us not to be affected by the future updates on both RTL and model sides. For instance, any register update in the RTL is handled by register header file and since we are using a unique access function for registers, we did not need to make any update in the test codes. If we were using model dedicated access functions, they may differ in typing and accessing through the addresses.

Figure 2 shows the elaboration period until test run for unified environment.

Figure 2: Elaboration and snapshot selection for unified environment.

Figure 3 is an example redefinition graph of model dedicated functions for unification.

Figure 3: A function redefinition example for unification.

V. CONCLUSION

We have developed a verification environment which can use the same C test code for different processor models. Here is a list of advantages of our work:

• Unification of test code for different models eliminates the need for learning different function codes of the models. This will also help engineers who know C coding in the team to design new tests for the environment.
• It provides flexibility to use many models at the same time.
• Using the same code with different processor models improves the cross checking and consistency of functional test results. For example, one can also integrate the ARM gate level netlist as a different model into this environment, then this environment can also be used for gate level verification purposes.
• It improves hand shaking and knowledge sharing between different teams such as firmware, design and verification teams.

VI. ACKNOWLEDGEMENTS

Thanks to Trefor Southwell and ST-Ericsson Zaventem/Belgium firmware team for their extensive support and feedbacks during this work.