Nitin Ahuja, Agnisys Technology Pvt. Ltd
In the previous article titled “Automatic generation of Register Model for VMM using IDesignSpecTM ” we discussed how it is advantageous to use a register model generator such as IDesignSpecTM, to automate the process of RALF model generation. Taking it forward, in this article we will discuss how to close the loop on register verification.
Various forms of coverage are used to ensure that registers are functioning properly. There are three coverage models in VMM. They are:
1. reg_bits coverage: this model is used to make sure that all the bits in the register are covered. This model works by writing and reading both 1 and 0 on every register bit, hence the name. This is specified using “cover +b” in the RALF model.
2. field_vals coverage: field value coverage model is implemented at the register level and supports value coverage of all fields and cross coverage between fields and other cross coverage points within the same register. This is specified using “cover +f” in the RALF model. User can specify the cross coverage depending on the functionality.
3. Address map: this coverage model is implemented at block level and ensures that all registers and the memories in the block have been read from and written to. This is specified using “cover +a” in the RALF model.
We will discuss how coverage can be switched on/off and how the type of coverage can be controlled for each field directly from the register specification.
Once the RALF model is generated, the next step in verification is to generate the RTL and the SystemVerilog RAL model using ‘ralgen’. The generated RAL model along with the RTL can be compiled and simulated in the VMM environment to generate the coverage database. This database is used for the report generation and analysis.
Reports can be generated using IDesignSpecTM (IDS). IDS generated reports have advantages over other report in that it generates the reports in a much more concise way showing all the coverage at one glance.
Turning Coverage ON or OFF
IDesignSpecTM enables the users to turn ON/OFF all the three types of coverage from within the MS Word specification itself.
Coverage can be specified and controlled using the “coverage” property in IDesignSpecTM which has the following possible values:
The hierarchical “coverage” property enables users to control the coverage of the whole block or at the chip level.
Here is a sample of how coverage can be specified in IDesignSpecTM:
This would be the corresponding RALF file :
The coverage bins for each CoverPoint along with the cross for the various CoverPoints can also be defined in the specification as shown below:
This would translate to the following RALF:
Now, the next step after RALF generation would be to generate the RAL Model from the IDS generated RALF.
RAL MODEL AND RTL GENERATION FROM RALF:
The IDS generated RALF can be used with the Synopsys ‘ralgen’ to generate the RAL (VMM or UVM) model as well as the RTL.
RAL model can be generated by using the following command:
If you specify –uvm above in the fisrt ralgen invocation above, a UVM Register Model would be generated.
COMPILATION AND REPORT GENERATION:
Once the RTL and the RAL model are generated using the ‘ralgen’, the complete model can be compiled and simulated in the VMM environment using VCS.
To compile the model use the following command on the command line:
vcs -R +plusarg_save -sverilog -o “simv1″ -ntb_opts rvm+dtm +incdir+<directories to search `defines> <files to be compiled> +define+RAL_COVERAGE
The compilation and simulation generates the simulation database which is used for the generation of the coverage reports.
Coverage reports can be generated in various forms but the most concise form can be in the form of the graphics showing all the coverage at a glance. For this, a tcl script “ivs_simif.tcl” takes up the simulation database and generates the text based report on execution of the following command:
% ivs_simif.tcl -in simv.vdb –svg
For running the above command set the environment variable “IDS_SIM_DIR”, the text report are generated at this location. This will also tell IDS where to look for the simulation data file.
A detailed graphical view of the report can be generated from IDS with the help of this text report. To generate the graphical report in the form of “scalable vector graphics” (SVG) select the “SVG” output from the IDS config and regenerate.
Another way of generating the SVG could be by using the IDS-XML or the Doc/Docx specification of the model as the input to the IDS in batch mode to generate the graphical report of the simulation by using the following command:
% idsbatch <IDS_generated_XML or doc/docx specification> -out “svg” -dir output_directory
IDesignSpec generates two types of reports from the input database.
1. Field_vals report
2. Reg_bits report
Field_vals report gives the graphical view of the field_vals coverage and the address coverage of the various registers and their respective fields.
The amount of coverage for the field (CoverPoints) is depicted by the level of green color in the fields, while that for complete register (CoverGroup) is shown by the color of name of the register.
The address coverage for the individual register (CoverPoint) is shown by the color of the address of the register (green if addressed; black if not addressed), while that of the entire block (CoverGroup) is shown by the color of the name of the block.
The coloring scheme for all the CoverGroups i.e. register name in case of the field_vals coverage and block name in case of the address coverage is:
1. If the overall coverage is greater than or equal to 80% then the name appears in GREEN color
2. If the coverage is greater than 70% but less than 80% then it appears in YELLOW
3. For coverage less than 70% name appears in RED color
Figure1 shows the field_vals and address coverage.
Figure: Closed loop register verification using RALF and IDS
The above sample gives the following coverage information:
a. 2 registers, T and resetvalue, are not addressed out of total of 9 registers. Thus the overall coverage of the block falls in the range >70% &<80% which is depicted by the color of the Stopwatch (name of the block).
b. All the fields of the registers are filled with some amount of the green color which shows the amount of the coverage. As an example field T1 of register arr is covered 100% thus it is completely filled and FLD4 of register X is covered only about 10%. The exact value of coverage can be obtained by hovering over the field to get the tooltip showing the exact coverage value
c. Color of the name of the register, for example X is red, show the overall coverage of the whole register , which is less than 70% for X.
Reg_bits report gives the detailed graphical view of the reg_bits coverage and address coverage.
Address coverage for reg_bits is shown in the same way as for the address coverage in field_vals. Reg_bits coverage has 4 components, that is,
1. Written as 1
2. Read as 1
3. Written as 0
4. Read as 0
Each of the 4 components is allocated a specific region inside a bit. If that component of the coverage is hit then the corresponding region is shown as green else it is blank. The overall coverage of the entire register is shown by the color of the name of the register as in the case of the field_vals.
The above sample report shows that there is no issue in “Read as 1” for the ‘resetvalue’ register. While other types or read/write has not been hit completely.
Thus, in this article we described what the various coverage models for a register are and how to generate the RALF coverage model of the registers automatically with minimum effort. An intuitive visualization of the register coverage data will ease the effort involved in deciphering the coverage reports from simulation lengthy log files. This type of closed loop register verification ensures better coverage and high quality results in less time. Hope you found this useful.. Do share with me your feedback on the same and and also let me know if you want any additional details to get the maximum benefits from this flow..