Software Architecture for IP verification in Operating System environment

Ravi Kumar V, Sheeja, & Raghavendra Reddy
Samsung India Software Operations
Bangalore, India

Abstract

Contemporary FPGA verification methodologies lack definitive software verification standards in verifying an IP. This forces the IP verification engineers to re-work on their verification environments every time there is a change in the IP operating platform thus spending most of the time on establishing a verification environment rather verifying the IP. This paper presents versatile software architecture for IP verification in an integrated system environment. The proposed architecture is re-usable across various IP’s and operating platforms. This software architecture speeds up the IP verification process by identifying common ground work required for various IP’s. Further the paper defines standards for the FPGA verification software and develops a prototype on a particular operating platform based on the suggested standards.

1. Introduction

Superior technology and time to market are two important driving factors that contribute to the changing dynamics of semiconductor business. Numerous protocols have been designed and developed to address the present digital world requirements resulting in the genesis of a new branch “IP design and verification”. Though IP design methodologies have been stabilized for a while, IP verification is one intriguing area which is still evolving. IP verification happens at multiple stages (as in Ref1) and verification models like FPGA verification, system C verification etc each address specific verification requirements of IP at different stages. The modern and the much applauded FPGA based verification has addressed most of the testing requirements ensuring the quality of the IP in a lesser time frame compared to other verification methodologies.

Despite FPGA verification being one complete verification methodology, it lacks certain clear standards on the software frame work that should be used to verify the IP in various environments. The obscurity in standards include software verification architecture that clearly defines rules to address some of the below mentioned pivotal requirements.

1. Versatility in software framework to handle different IP’s.
2. Software framework to verify the IP’s through various interfaces like PCI, AHB, APB, AXI or IO etc with minimal efforts when change in interface.
3. Software framework to verify the IP in standalone environment or in an SOC envi-ronment.
4. Definite rules listing the functionalities of the software framework etc.

The developmental activities required in verifying an IP can be classified to three broad categories.

1. Platform specific
2. IP specific.
3. Test case implementation and execution.

Platform specific activity is the software that needs to be done to bring the verification environment up on a particular operating platform. Typical work that needs to be done for any IP include IP identification and mapping to processor address space, establishing communication channels between the test application and test driver, developing the background for handling the test cases and developing necessary user interface etc.

IP specific activity is the driving software that understands and drives the IP to be verified. Test case implementation and execution is one step that involves development of test scenarios for the IP and involves necessary execution steps.

The drawback in the current verification methodology is every step of the above mentioned activities are done for each IP that need to be verified at each stage thus increasing the verification time line. It would be a great value addition if the commonalities in the IP verification stage are identified and re-used. These reusable modules in the verification suite accelerate the development of a complete verification environment thus improving overall efficiency and productivity for verification engineers.

The purpose of this paper: The intention of this paper is to address some of the above mentioned unattended items in the IP verification methodology through innovative approach of conceiving standard software frame work architecture. The software frame work is expected to offer the following

1. Isolation of IP interfaces from the IP verification software.
2. Providing standard interfaces to access IP core functionalities such as IP configuration etc.
3. Layering of the IP verification software and its functionalities to ensure a portable, versatile frame work that could be used with various IP’s in various environments.
4. Defining functionalities for each layer of the frame work to cater to various IP verification stages.

Also the paper is intended to develop a generic IP verification suite based on the above rules. The frame work is implemented on the Linux operating system. Developing such a generic frame work would benefit the IP verification engineers to evaluate any IP in a lesser time frame irrespective of the hardware platforms ensuring the quality.

Strategic fitness: Developing such a verification suite would be of tremendous value-add for all the IP development and verification teams empowering them with verification capabilities at every stage of IP devel-opment from IP conception to product realization as explained below.

1. The IP development team can use the verification suite with minimal effort to conduct unit testing on different modules of the IP under development ensuring the quality of the IP from the point of conception.
2. The IP verification team can use the verification frame work with minimal effort to cover test scenarios at various stages of verification like basic verification, functionality verification, protocol verification, error and recovery functionality verification and finally stress/regression stage verification concentrating on the IP functionality rather on the test environment required. Also the IP verification team can leverage the versatility of the suite in verifying different IP’s in lesser time frame without compromising on the quality.
3. The next level in the IP usage chain SOC teams can use the verification suite and the test scenarios developed by the stand alone IP verification team to verify the IP in their environment avoiding the re-work of test environment required.
4. The driver writers for the IP’s can verify the advantages of their logic prior to complete implementation of the driver logic, leveraging the flexibility of the verification frame work.

Considering the various advantages mentioned above, the verification frame work finds its use at every stage of system LSI business, from the point of IP conception to realization, eliminating time being spent on re-work at various stages. This allows the respective stake holders to focus on the quality of the IP at every stage pushing IP vendor’s one step towards the theme of “superior technology and shorter marketing time frames”.

Breakthrough point of the research:

1. Identifying the re-work involved in verifying IP at every stage to the point of product realization.
2. Conceiving generic software architecture to handle the common requirements.
3. Reducing the efforts required in verifying an IP with out compromising on the quality.

2. Main Part

To ensure the quality of the IP, every IP should undergo the following verification stages.

1. Basic Testing
2. Functionality Testing
3. Protocol Testing
4. Error and Recovery Testing
5. Stress Testing
6. Regression Testing
7. Compliance Testing
8. System Testing

The protocol complexity of the IP is a decisive factor in choosing the verification platform. The idea of having a single IP verification platform to verify IP’s of different complexities and also addressing the requirements at all the stages of the IP verification listed above would be very beneficial. The proposed IP verification platform automates these testing stages –

1. Basic Testing
2. Functionality Testing
3. Error and Recovery Testing
4. Stress Testing
5. Regression Testing

Figure 1.

The Figure 1 above depicts the effort involved in verifying an IP at each stage in the current and the proposed software architecture. Approximately 66% of the work shall be automated in the proposed IP verification platform. There by only 34% of the total effort has to be put by the IP verification engineer which in turn allows the IP verification engineer to concentrate on the IP specific activities thus boosting the quality of the IP further.

Grouping all the platform requirements and considering all the verification stages, the following system architecture has been proposed to achieve the goals of IP verification discussed above.

System Layering:

As shown in above system architecture, the IP verification components are classified into three categories.

1. Platform specific components.
2. IP specific components.
3. OS dependent components.

Figure 2: System Architecture

All the platform specific functionalities are addressed by the verification suite and exposes relevant services to the IP specific components. Verification engineers can use the services exposed by the verification suite in implementing the IP specific components.

Platform specific Components:

The platform specific components are the generic components required in verifying every IP but are completely independent of IP. The verification suite handles these generic requirements and exports services to the IP specific components. This allows the verification engineers to focus on the IP and its functionality rather on test environment which is very time consuming.

As depicted in the system architecture the functionalities of the generic verification suite are distributed to four layers each layer catering to specific requirements.

1. Test Case Handling Layer
2. Application Interface Layer
3. Verification Driver Layer
4. Hardware Interface Layer

Test Case Handling Layer:

The layer shoulders the responsibility of implementing generic frame work required for every IP verifier to execute test cases in a customized manner. This layer comprises of scripts to execute IP test cases and report the results to the user.

Application Interface Layer:

This layer shoulders the responsibility of implementing the necessary generic frame required by test case implementation layer and IP functionality layer to communicate to the verification driver layer. This layer is a library, exporting its services to above layers isolating their dependency on the operating system.

Verification Driver Layer:

This layer shoulders the responsibility of servicing various generic requests from the above layers or from the IP controller driver. This layer acts as a message translator between the application layer and the IP con-troller driver to service IP specific requests from the above layer.

Hardware Interface Layer:

This layer is responsible for identifying and configuring the IP to the processor address space so that the above software frame work or controller driver can access the IP. The other functionalities of this layer include isolating the IP interface to the software frame work. This helps the IP verifier to evaluate the IP using the same software frame work and test scenarios when change in environment (I.e. From standalone to SOC environment.

IP specific Components:

These components are specific to the IP being verified and the verification engineer is expected to develop these components.

The three main components categorized in this section are

1. Test Case implementation
2. IP functionality implementation
3. IP controller driver

Test Case Implementation Layer: This layer deals with the implementation of the test cases that evaluate the IP and utilizes the services exported by the test case handling layer in executing the test cases.

IP functionality Implementation Layer: This is an optional layer whose responsibilities include configuring and driving the IP for intended purpose. Verification engineer need to implement this layer only in the absence of either controller driver or a particular functionality in the controller driver. IP verifier can use the services exported by the Application interface layer to access and configure the IP.

IP Controller driver:

IP controller driver is the most important component that handles all the functionalities of the IP and should be developed by the IP verifier. The IP verifier can use the services exported by the verification driver layer to communicate to the above layers. Typically this channel is used to collect hardware status of the IP that is generally not exposed through registers.

3. Use Case

Figure 3: Use Case Scenario

From the above use case scenario, the generic verification platform can be used with various IP’s and is completely independent of the bus interface. The color coding in the above figure 3 correspond to the color coding of figure 2 system architecture differentiating the IP specific and generic components of verification platform.

4. Conclusion

The proposed software architecture is of great value for the IP verification business in reducing the time to market an IP. Also the proposed architecture can co-exist with the virtual platforms like Q-EMU available in the market allowing the IP verification engineer to start the IP specific work even before the hardware prototype of the IP is available.

5. References

1. “Verification IP Modeling Architecture” from synopsis published in the year 2002.