English
Generic and Automatic Specman based Verification Environment for Image Signal Processing IPs
By Abhishek Jain, Mahesh Chandra, Arnaud Deleule and Saurin Patel
STMicroelectronics
Abstract :
In this paper, we present a generic and automatic Specman based verification environment for the verification of the image signal processing IPs. Specman based coverage driven random verification is very powerful methodology for the verification of IPs. However, it requires strong knowledge of ‘e’ language. The main aim of development of this verification environment is to more efficiently verify each image signal processing IP (both at module level and sub-system level) which have standard register interface(s) and video data interface(s). To use it, only basic knowledge of ‘e’ language is required and even the design engineers can develop the verification environment for their own IPs within a very short time. IP-XACT API clients are used for automatically configuring the environment for various IPs.
1.0 Introduction
Image signal processing algorithms are developed and evaluated using ‘C’ or Matlab before RTL implementation. Once the algorithm is finalized, ‘C’ models are used as a golden model for the IP development. To maximize re-use of design effort, the common bus protocols are defined for internal register and data transfers. A pool of such configurable image signal processing IP modules are assembled together to satisfy a wide range of complex video processing SoCs. An image signal processing IP has following interfaces as shown in figure 1.
Figure. 1 Interfaces of image signal processing IP
As image signal processing IPs have common bus protocols for internal register and video data pipelines, memory and output interrupt interfaces, the verification environment for such IPs can be automatic. To build such environment, there were many challenges. These challenges were as follows:
2.0 Generic Verification Environment
In an image signal processing IP, there are N input video data interfaces, T output video data interfaces, M memory interfaces, S output Interrupts and Q register interfaces, where M, N, Q, S and T values can be from 0 to any arbitrary number. For verifying these interfaces, dedicated eVCs are used. In case of register interface(s), register interface eVC and ‘vr_ad’ register model are used. Similarly for video data interface(s),video data interface eVC is used. For memory interfaces, memory models (in ‘e’ language) are used and for verification of interrupts, generic interrupt checker is used.
Note that there can be multiple instances of these eVC’s in a verification environment. Each agent is configured separately and any combination of agent configurations can coexist in the same environment. Therefore in above case, Q instances of register interface eVC agents, P (P = max (N,T)) instances of video data interface eVC agents, S instances of interrupt checker and M instances of memory model are used to interface with a DUT. T instances of data checker are used in environment. Figure 2 illustrates the basic blocks of generic verification environment.
Figure. 2 Basic blocks of Generic Verification Environment
In Generic Verification Environment, register description file for ‘vr_ad’ register model, configuration files to configure the eVC’s, constraint file to generate constrained random data sequences, functional Coverage file, data checker file to compare the output of IP with output of ‘C’ model and test cases for registers and video data interface(s) are IP specific which need to be modified for every IP.Therefore, IP-XACT API clients are used for generation of these files.
First, the register map description has to be provided in XML-based IP-XACT view.
In Data checker file, there is invocation of executable of ‘C’ model containing command line arguments thus, automatic generation of data checker file requires the mapping between the registers/register-fields/parameters of IP and the command line arguments of ‘C’ model. Thus, in IPXACT API clients, there are two input files
Figure. 3 Generic and Automatic Verification Environment
2.1 Register Verification
Standard ‘vr_ad’ eVC is used for efficient register verification. It contains built-in mechanisms with predefined types for efficient modeling. Figure 4 shows the register and address management aspect layered on top of the Register Interface eVC including the address map, register file and register sequence driver. ‘vr_ad’ eVC is used in conjunction with the register interface eVC, so that whenever the IP registers are read/written, the associated ‘vr_ad’ eVC pre-defined registers are also updated and IP register contents will be verified by a selfchecking scheme.
Figure. 4 Registers in the Register Interface eVC Architecture
2.2 Image Processing Algorithm Bit Accurate Verification
For the purpose of output video data checking, the generic verification environment integrates the ‘C’ model. Output of ‘C’ model is compared with the output of the IP in data checkers which are part of generic verification environment as shown in figure 5. Note that separate data checkers are used for the register interface eVC and video data interface eVC. These data checkers of register and video data interface eVC’s are automatically generated by IPXACT API clients.
Figure. 5 Data Checker and C Model
2.3 Handling Different Algorithms
In a verification environment, ‘vr_ad’ register definition file, configuration files, constraint file, functional coverage file, test cases and data checker files are IP dependent and they need to be modified for every IP. Therefore, IP-XACT API clients are used for generation of these files using the register map description in XML based IP-XACT view.
2.4 Interrupts Verification
An IP can have one, more or no output interrupts. This can be configured using the configuration file. Generic interrupt checker can automatically check the interrupts for their timing of assertion. These timing parameters are configured by the user in the video data interface eVC configuration file.
2.5 Memory Interface Verification
Image signal processing IP’s may use memory to store intermediate data, to store output results or to read the input data. Memory models in ‘e’ language are implemented to avoid the need to instantiate Verilog/VHDL model test bench file.
3.0 Usage of Verification Environment at Sub-System Level
Generic Verification Environment can be used for the verification of Image signal processor (at subsystem Level).Generally, all the R IP’s in Image signal processor pipe are connected serially. Output data interface of one IP is connected to the input data interface of another IP.Thus, at sub-system level, as shown in figure 6, only one input data interface and one output data interface is required for the whole pipe (one special case) and R register files (of vr_ad register model) are required for R IP’s. R register files can be added to the address map (by setting the absolute base address for each register file). This can be done at runtime or at postgenerate.
‘C’ models of the corresponding image signal processing IP’s should also be connected serially in the same order as the corresponding Image signal processing IP’s. Input image Data will be driven to the first image signal processing IP and ‘C’ Model and output data of Rth image signal processing IP and ‘C’ model will be compared as shown in figure 6.
Note- All the IP’s have there own ‘e’ register file which are reused at the sub-system level environment. Thus, R register files are used in figure 6.One register file can also be used for the system level verification if one combined design specification file is available for the system level register map.
Figure. 6 Environment for Verification of Image signal processor pipe (Sub-System Level)
Conclusion
We presented a generic and automatic Specman based verification environment for verification of image signal processing IPs. IP-XACT API clients are used for the automatic generation of IP dependent ‘e’ files. This verification environment is very easy to use and users don’t need a very strong knowledge of ‘e’ language. This verification environment is already used for the verification of many image signal processing IPs. Same concept can be extended for non image processing IPs for which ‘C’ models exist and the interface are standardized. Though this environment was built using ‘e’ language, ‘e’ language is not mandatory for building such environments. It can also be built using any other HVL languages.
References-
1. Spirit information, http://www.spiritconsortium.org
2. Specman eRM User Guide
3. The Register and Memory Package(vr_ad) User Guide
STMicroelectronics
Abstract :
In this paper, we present a generic and automatic Specman based verification environment for the verification of the image signal processing IPs. Specman based coverage driven random verification is very powerful methodology for the verification of IPs. However, it requires strong knowledge of ‘e’ language. The main aim of development of this verification environment is to more efficiently verify each image signal processing IP (both at module level and sub-system level) which have standard register interface(s) and video data interface(s). To use it, only basic knowledge of ‘e’ language is required and even the design engineers can develop the verification environment for their own IPs within a very short time. IP-XACT API clients are used for automatically configuring the environment for various IPs.
1.0 Introduction
Image signal processing algorithms are developed and evaluated using ‘C’ or Matlab before RTL implementation. Once the algorithm is finalized, ‘C’ models are used as a golden model for the IP development. To maximize re-use of design effort, the common bus protocols are defined for internal register and data transfers. A pool of such configurable image signal processing IP modules are assembled together to satisfy a wide range of complex video processing SoCs. An image signal processing IP has following interfaces as shown in figure 1.
Figure. 1 Interfaces of image signal processing IP
- Register interface(s) to configure the register(s) of image signal processing IP.
- Video data interface(s) for receiving/ sending video data.
- Memory interface(s) to access the external memory cuts.
- Interrupt interface(s) to generate interrupts.
As image signal processing IPs have common bus protocols for internal register and video data pipelines, memory and output interrupt interfaces, the verification environment for such IPs can be automatic. To build such environment, there were many challenges. These challenges were as follows:
- Significant time was spent in porting the environment for an image signal processing IP as all the IP dependent ‘e’ files were needed to be written by the verification engineer manually.
- Verification of register testing was not efficient and automatic as small change in the register description caused manual rework in the verification environment and testcase(s).
- Verification engineer needed to have strong knowledge of ‘e’ language as many components like register description file, data checker, test-cases etc. were IP dependent and had to be written manually.
- Output of an image signal processing IP can be image(s) or/and the status information in status registers. Manually, it was difficult to handle all different configurations of IP outputs.
- It was difficult to align design specification with corresponding RTL implementation and verification environment.
2.0 Generic Verification Environment
In an image signal processing IP, there are N input video data interfaces, T output video data interfaces, M memory interfaces, S output Interrupts and Q register interfaces, where M, N, Q, S and T values can be from 0 to any arbitrary number. For verifying these interfaces, dedicated eVCs are used. In case of register interface(s), register interface eVC and ‘vr_ad’ register model are used. Similarly for video data interface(s),video data interface eVC is used. For memory interfaces, memory models (in ‘e’ language) are used and for verification of interrupts, generic interrupt checker is used.
Note that there can be multiple instances of these eVC’s in a verification environment. Each agent is configured separately and any combination of agent configurations can coexist in the same environment. Therefore in above case, Q instances of register interface eVC agents, P (P = max (N,T)) instances of video data interface eVC agents, S instances of interrupt checker and M instances of memory model are used to interface with a DUT. T instances of data checker are used in environment. Figure 2 illustrates the basic blocks of generic verification environment.
Figure. 2 Basic blocks of Generic Verification Environment
In Generic Verification Environment, register description file for ‘vr_ad’ register model, configuration files to configure the eVC’s, constraint file to generate constrained random data sequences, functional Coverage file, data checker file to compare the output of IP with output of ‘C’ model and test cases for registers and video data interface(s) are IP specific which need to be modified for every IP.Therefore, IP-XACT API clients are used for generation of these files.
First, the register map description has to be provided in XML-based IP-XACT view.
In Data checker file, there is invocation of executable of ‘C’ model containing command line arguments thus, automatic generation of data checker file requires the mapping between the registers/register-fields/parameters of IP and the command line arguments of ‘C’ model. Thus, in IPXACT API clients, there are two input files
- IP-XACT view of register map, containing the register description.
- Map file for mapping between the registers/register-fields/parameters of IP and the command line arguments of ‘C’ model.
Figure. 3 Generic and Automatic Verification Environment
2.1 Register Verification
Standard ‘vr_ad’ eVC is used for efficient register verification. It contains built-in mechanisms with predefined types for efficient modeling. Figure 4 shows the register and address management aspect layered on top of the Register Interface eVC including the address map, register file and register sequence driver. ‘vr_ad’ eVC is used in conjunction with the register interface eVC, so that whenever the IP registers are read/written, the associated ‘vr_ad’ eVC pre-defined registers are also updated and IP register contents will be verified by a selfchecking scheme.
Figure. 4 Registers in the Register Interface eVC Architecture
2.2 Image Processing Algorithm Bit Accurate Verification
For the purpose of output video data checking, the generic verification environment integrates the ‘C’ model. Output of ‘C’ model is compared with the output of the IP in data checkers which are part of generic verification environment as shown in figure 5. Note that separate data checkers are used for the register interface eVC and video data interface eVC. These data checkers of register and video data interface eVC’s are automatically generated by IPXACT API clients.
Figure. 5 Data Checker and C Model
2.3 Handling Different Algorithms
In a verification environment, ‘vr_ad’ register definition file, configuration files, constraint file, functional coverage file, test cases and data checker files are IP dependent and they need to be modified for every IP. Therefore, IP-XACT API clients are used for generation of these files using the register map description in XML based IP-XACT view.
2.4 Interrupts Verification
An IP can have one, more or no output interrupts. This can be configured using the configuration file. Generic interrupt checker can automatically check the interrupts for their timing of assertion. These timing parameters are configured by the user in the video data interface eVC configuration file.
2.5 Memory Interface Verification
Image signal processing IP’s may use memory to store intermediate data, to store output results or to read the input data. Memory models in ‘e’ language are implemented to avoid the need to instantiate Verilog/VHDL model test bench file.
3.0 Usage of Verification Environment at Sub-System Level
Generic Verification Environment can be used for the verification of Image signal processor (at subsystem Level).Generally, all the R IP’s in Image signal processor pipe are connected serially. Output data interface of one IP is connected to the input data interface of another IP.Thus, at sub-system level, as shown in figure 6, only one input data interface and one output data interface is required for the whole pipe (one special case) and R register files (of vr_ad register model) are required for R IP’s. R register files can be added to the address map (by setting the absolute base address for each register file). This can be done at runtime or at postgenerate.
‘C’ models of the corresponding image signal processing IP’s should also be connected serially in the same order as the corresponding Image signal processing IP’s. Input image Data will be driven to the first image signal processing IP and ‘C’ Model and output data of Rth image signal processing IP and ‘C’ model will be compared as shown in figure 6.
Note- All the IP’s have there own ‘e’ register file which are reused at the sub-system level environment. Thus, R register files are used in figure 6.One register file can also be used for the system level verification if one combined design specification file is available for the system level register map.
Figure. 6 Environment for Verification of Image signal processor pipe (Sub-System Level)
Conclusion
We presented a generic and automatic Specman based verification environment for verification of image signal processing IPs. IP-XACT API clients are used for the automatic generation of IP dependent ‘e’ files. This verification environment is very easy to use and users don’t need a very strong knowledge of ‘e’ language. This verification environment is already used for the verification of many image signal processing IPs. Same concept can be extended for non image processing IPs for which ‘C’ models exist and the interface are standardized. Though this environment was built using ‘e’ language, ‘e’ language is not mandatory for building such environments. It can also be built using any other HVL languages.
References-
1. Spirit information, http://www.spiritconsortium.org
2. Specman eRM User Guide
3. The Register and Memory Package(vr_ad) User Guide
|
||||||
Related Articles
- Digital Signal Processing (DSP) Verification
- System Verilog based Generic Verification Methodology for IPs/ASICs/SOCs: A Case Study
- Artificial Intelligence and Machine Learning based Image Processing
- A Generic Solution to GPIO verification
- A RISC-V ISA Extension For Ultra-Low Power IoT Wireless Signal Processing
New Articles
- Quantum Readiness Considerations for Suppliers and Manufacturers
- A Rad Hard ASIC Design Approach: Triple Modular Redundancy (TMR)
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- UPF Constraint coding for SoC - A Case Study
- Dynamic Memory Allocation and Fragmentation in C and C++
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)
|
E-mail This Article | 
|
|
Printer-Friendly Page |