Browse > Home / 信息中心 / SNUG / 2007-2008 年论文集 / Improving SoC Development with Synopsys’ Verification Flow

Improving SoC Development with Synopsys’ Verification Flow


Luan Changhai
ZTEIC Design Co., Ltd.

Abstract

In substance, the keypoint of verification is how to improve the working efficiency based upon ensuring the quality of the project. With the increase of chip design complexity and design scale, those old methods and flows can’t satisfy the requirement of the function and power verification for the SoC chip in the RTL phase.

On the basis of a complex SoC project, this paper will evaluate the flow supplied by Synopsys from the module level to the system level. Some cases and experience about RTL function verification methodology, Low Power and CDC(Clock Domain Crossing) Verification will be demonstrated in this paper. As a proposal, the author presents a more efficient front-end verification workflow to the readers, which covers the range of VMM, SystemVerilog, Lower Powe Verification in the RTL phase, and so on.

Keywords: VCS, LEDA, VMM, Static Checking, Low Power, CDC, Coverage

1 Foreword

The increase of the scale and complexity of SoC has made verification a critical part of the design flow. By adopting EDA tools, verification engineers can find out design bugs in the RTL level early in time. Thus, we can reduce the time to market, the potential risk and the cost of the project. How to improve the verification efficiency has become an interesting topic for verification engineers.

2 Verification Challenge

The verification workload will be increased up to 4 times and even more when the design codes doubled. How do we use the resources and tools to set up a more effective verification flow?

It becomes necessary to improve the methodology and use more effective tools. But currently, so many methodology and tools emerge in endlessly. In the meantime, each project leader needs to take the cost to study new methods into consideration.

On the basis of a complex SoC project, this paper will evaluate the flow supplied by Synopsys from the module level to the system level. Some cases and experiences about RTL function verification methodology, Low Power and CDC Verification will be demonstrated in this paper. As a proposal, the author presents a more efficient front-end verification workflow to the readers, which covers the range of VMM, SystemVerilog, Lower Power Verification in the RTL phase, and so on.

3 Verification Flow

Verification can be divided into two processes, plan and execution, shown as Fig.3.1. DUV, Design Under Test; VP, Verification Plan.

Fig.3.1. the Verification Flow

3.1 Verification Planning

Since verification can guarantee the quality of a project but not create a project, the verification plan must be based upon application SPEC, system design SPEC and system user handbook. We may follow the Top-Down mode to accomplish the following tasks:

  • Analyze the feasibility and bugs of the system, in view of application SPEC mapping to system design SPEC
  • Confirm verification spots in view of application spec mapping to block function
  • Establish verification case and the mapping frame from verification spots to verification case

How to establish a complete, feasible and highly effective verification plan is a fundamental element to guarantee a project’s quality. We can profit from Verification Planning of Verification Methodology Manual for System Verilog, which includes planning process and response checking. In the section of planning process, functional verification requirements, verification environment requirements and verification implementation plan are mentioned. The section of response checking offers method of embedded monitors, assertions, accuracy, scoreboarding, reference model and offline checking and relative regulations and suggestions. On the basis of a real complex SoC project, I will talk about my comprehension to verification plan.

Table 3.1. Verification plan example

Number VC-F 0x.0x.0x
Name Xx_xx_CHECK
Application Fast Ethernet FE
Function Measure Ethernet excessively short package
Layer Function Layer
PRI 4
Condition Verification platform is OK, VC-F 0x.0x.0x is done and OK
Step Verification environment variables and DUT variables
1 Set external environment variables: FE_MODE=0，FE_INTF=SMII
2 Write 16’h01 to the register 0
3 Write 16’h02 to the register 1
4 Write 16’h08 to the register 10
5 Read the registers 100~120 in order
6 Send 100 MAC frames (20 Byte) in sequence
7 Read the value of the short frame counter
8 If the value of the short frame counter is not 100, print “ERROR procedure SF_20B_CHECK”; Else print “CORRECT procedure SF_20B_CHECK”
Expect Result The value of the short frame counter is 100

Recommendation 2-7 —Requirements need be ranked. As verification engineers, our responsibility is to find out all bugs in the design. However, each project has the pressure to consider Time-to-Market, especially for consumable SoC product. Therefore, it is necessary for verification engineers to primarily consider how to ensure the function of the project with great competence in a limited period.

Recommendation 2-18 —Error injection mechanisms should be defined. Verification engineers usually consider how to verify whether these functions can work normally according to user guide, but they pay less attention about error injection mechanisms. When the chips are applied for the market, all kinds of error injection occur. It is impossible to simulate all false operations by the users, but we need think over error injection mechanisms as soon as possible.

However, it still confuses us how to verify all functions. Besides referring to VMM rules and recommendations, we usually need rely on the arguments between design engineers and verification engineers.

3.2 Verification Execution

How do we execute the verification plan? In this section, I would like to recommend the combination of LEDA+VCS+SystemVerilog+VMM analyze the advantage of this combination.

3.2.1 Traditional SoC Verification
3.2.1.1 Flow Summarization

In the SoC verification process, a lot of data communications occur frequently in many data paths , such as data communication between Ram and Ram or between RAM and external devices. The method of comparison file is usually adopted as Fig 3.1. In the beginning, inputted data is generated by Input Pattern and communicated through a series of modules in SoC system. An output result comes out through the communication and be compared with Expected Output to verify whether the SoC system works effectively. This method is usually used for verification of module and system.

Fig.3.2. Self-checking Testbench of SoC system
3.2.1.2 Bottleneck Analysis

The SoC verification flow mentioned in the section 3.2.1.1has many bottlenecks as follows:
 Due to the difference of technical capacity among the designers, RTL codes can’t be guaranteed to be synthesizable, simulatable and reusable before simulation. These problems greatly reduce working efficiency.

  • In a complex SoC system, Input Pattern is usually various and complicated. It is difficult to cover all functions on the expected schedule by manual work.
  • Reusability and replantability of traditional verification environment usually reply on the experience of engineers. There is neither theoretic nor systematic support
  • Traditional verification schedule is usually under control of the project leader, however, with the increase of the complexity and of the scale, it’s hard for the leader to know clearly about the detailed schedule and the workload left..
  • With the increase of the demand for energy-saving devices, low power design is becoming a mainstream. For example, the SIM card needs more longer battery using time, and this requires much lower power. The corresponding low power design needs equivalent static checking and other advanced verification technique.
  • Multi-Clocks generally are defined in our design, but traditional RTL simulator can’t simulate metastable state output, and Post Layout Simulation can’t verify the relationship among all signals and clock. STA can check Setup/Hold time warning only in condition that many clocks have fixed phase relationship in the design. So, potential metastable state still exists.
3.2.2 Efficient Verification Flow

These bottlenecks will be readily solved by using more efficient verification flow. We need finish some jobs as follows:

  • Static Checking RTL design codes with LEDA
  • Build coverage-driven and controlling-random testbench based on VMM
  • Verify functions and technique targets, simulate application
3.2.2.1 LEDA Check

Leda is a programmable design and coding guideline checker that delivers full chip mixed-language (Verilog and VHDL) and mixed representation (RTL & gate) capabilities to speed development of complex system-on-chip (SoC) designs. Leda’s pre-packaged rules greatly enhance a designer’s ability to check HDL code for synthesizability, simulatability, testability, reusability, and RTL/gate signoff. Leda detects clock synchronization-related bugs, isolates hard-to-time circuits, verifies layout considerations and improves DFT for higher ATPG coverage.

Except using LEDA to check coding rules, we use its static checking feature in low power design by aiming at the project’s requirement to guarantee no logic bug. LEDA can execute state holding registers’ mapping checking to verify level translators in different VDD and power interconnection and switch in power-gating whether right or not.

Fig.3.3 is a low power design plan in some project, including a 3V VDD, a switch-able 1.8v VDD and a continue power supply 1.8v VDD.

Fig.3.3. MV with power gating

We can use LEDA static analysis tool to check the low power design equivalently.

Example: LEDA Low Power check:

The TCL script for low power checking:
## Read verilog file
read_verilog $SIM_SOURCE/*.v
## Elaborate design
elaborate -top Sim_top
## Create Power Nets
## Create Power Nets
create_power_net_info VDD1 -power -voltage_values 3
create_power_net_info VDD2 -power -voltage_values 1.8
## Create Power Domains
create_power_domain PD_TOP
create_power_domain PD_SUB -object_list [get_cells U_ON]
create_power_domain PD_SHUTDOWN -power_down \
-power_down_ctrl [get_ports EN] \
-object_list [get_cells U_OFF]
## Connect Power nets and domains
connect_power_domain PD_TOP -primary_power_net VDD1
connect_power_domain PD_SUB -primary_power_net VDD2
connect_power_domain PD_SHUTDOWN -primary_power_net VDD1
## Reports
report_level_shifters
report_power_domain
report_power_net_info
## Execute Power check
check -config ./config.tcl
## Report check result
redirect -tee -file ./violations.log report
## Quit LEDA Tcl shell
quit

The related Rule configuration file config.tcl is as follows:
rule_deselect -all
rule_select -policy POWER -rule LSINSALL
rule_select -policy POWER -rule LSPINVOLT
rule_select -policy POWER -rule ICINSOUT

In multi-clock design, CDC signals maybe have unexpected effects and propagate unpredictable. So to handle CDC signals, designers fence in potentially metastable logic to ensure logic beyond the fence only needs to handle in–band signals. It’s needed to add synchronizer for CDC signals. Fig3.4 is a typical synchronizer. On the other hand when any signals in the cross over path has more than one drive or any objects in the cross over path has more than one input. CDC signals are always subject to variable delays, even when a proper synchronizer is used. Designer need to check that the crossing clock domain boundaries that is recombined in the receiving logic. Fig3.5 is multi-bit convergence.

Fig. 3.4 A Typical 2DFF Synchronizer
Fig 3.5 Multi-bit CDC Signal Convergence

We check the two cases’ CDC signals in our project.

Example: LEDA CDC check

The related Rule configuration file config.tcl is as follows:
rule_deselect -all
#no synchronization scheme found for signals crossing clock domains
rule_select -rule NTL_CDC01
rule_set_parameter -rule NTL_CDC01 -parameter CHECK_CONTROL_PATHS -value {1}
rule_set_parameter -rule NTL_CDC01 -parameter CHECK_DATA_PATHS -value {0}
rule_set_parameter -rule NTL_CDC01 -parameter GIVE_ONE_EXAMPLE -value {1}
rule_set_parameter -rule NTL_CDC01 -parameter GIVE_FULL_CDC_PATH_INFO -value {1}
#convergence found in clock domain crossing path
rule_select -rule NTL_CDC02
rule_set_parameter -rule NTL_CDC02 -parameter CHECK_CONTROL_PATHS -value {1}
rule_set_parameter -rule NTL_CDC02 -parameter CHECK_DATA_PATHS -value {0}
rule_set_parameter -rule NTL_CDC02 -parameter GIVE_ONE_EXAMPLE -value {1}
rule_set_parameter -rule NTL_CDC02 -parameter GIVE_FULL_CDC_PATH_INFO -value {1}

3.2.2.2 Build Verification Platform

IC engineers have felt the need for a single unified design and verification language that allows them to both simulate HDL designs and verify them with high-level testbench constructs. Synopsys has implemented SystemVerilog, including SystemVerilog for design, assertions and testbench, interface in VCS. This unified language essentially enables engineers to write testbenches and simulate them in VCS along with their design in an efficient, high-performance environment. The unified language makes communicate more expediently between design and verification groups.

Synopsys push SystemVerilog language actively for implementing more advanced DFV and become the leader in providing a single, unified design and verification valication of designs with the desired degree of confidence.

The Discovery Verification Platform provides a unified environment of high performance and efficient interactions among best-in-class components, e.g. system-level verification, assertions, VIP, code coverage, functional coverage, testbenches and formal analysis. Discovery components support Verilog VHDL, SystemVerilog and so on. VCS comprehensive RTL verification environment is the cornerstone of Discovery Verification Platform. VCS provides high performance and capacity along with advanced bug finding technology including full-featured testbench, complete assertions and comprehensive coverage. VCS supports IEEE standards including SystemVerilog, Verilog and SystemC. VCS is supported by broad ASIC vendors and integrated with over many third-party tools. VCS accelerates complete system verification by delivering the fastest an highest capacity Verilog simulation for RTL functional verification. Also, the Direct C interface enables interaction between Verilog designs and applications written in C or C++.

The testbench based on VMM methodology provide layered verification environment, including test layer, scenario layer, functional layer, command layer, signal layer. Each layer provides a set of services to the upper layers, while abstracting it from the lower level details. Signal layer provides signal-level connectivity to the DUT. Command layer typically contains bus-functional models, physical-level drivers, monitors and checkers associated with the various interfaces and physical-level protocols present in the DUT. The functional layer provides the necessary abstraction layers to process application level transactions and verify the correctness of the DUT. The scenario layer provides controllable and synchronizable data and transaction generators. Test layer provides a combination of modifying constraints on generators, the definition of new random scenarios, synchronization of different transactors and the creation of directed stimulus.

Fig.3.6. Layered Verification Environment
3.2.2.3 Block Level Verification

In a complex SoC system, each module must be verified sufficiently before integration to the system to insure that this module can work normally when it communicate with others. The content is as follows:

  • Read and write registers
  • Inside function
  • Bus protocol

The block level verification flow is as Fig.3.7.

Fig.3.7. Block Level Verification Flow
3.2.2.4 System Level Verification

Those verified modules are integrated into the system, some integration problems will be occurred. We need veirfy something as follows:

  • Interconnection among modules
  • Bus competition
  • Bus protocol
  • Behavior among buses

3.3 Build Verification Platform Based on VMM Methodology

3.3.1 Verification of UART Module

UART is a serial data communications module. It connects with APB bus.

Fig3.8 is the block level verification platform for UART.
Fig.3.8. Block Level UART Verification Platform
3.3.1.1 Transaction

VMM methodology defines standards for creating transaction and data descriptions to facilitate their constrainable random generation while maintaining a flexible directed capability. For UART block level verification, the testbench transact two kind of transaction. One is APB bus transaction, modeling APB bus. The other is data transaction, modeling data action. The transactions encapsulate the stimulus for UART, e.g. APB bus transaction reading or writing UART register. VMM provide vmm_data base class for writing generic data processing and transfer components. Verification engineer can extend the class and build all transaction data.

3.3.1.2 Transactor

Transactor is a verification component of a verification environment. A transactor is a static object that autonomously generates, processed or monitors transactions. BFM models are transactors. VMM provide VMM_XACTOR base class for all transactors. It provides a standard control mechanism expected to be found in all transactors. The vmm_xactor base class contains standard properties and methods to configure and control transactors. To ensure that all transactors have a consistent usage model, they must be derived from a common base class. All processing threads shall be started in the extension of the vmm_xactor :: main() task. The encapsulated transactor shall be strarted by calling its vmm_xactor : : start_xactor() method in an initial block in the program block that instantiates it. If calling stop_xactor() method, the transactor will been stopped.

In UART testbench interrupt transactor model the interrupt respond of APB site. The driver of APB site and data site drive the transaction stimulus to UART. The monitor of APB site and data site will monitor the UART input and output signal and transfer the monitor signal to self-check module for compare.

3.3.1.3 Generator

Generator is a proactive transactor that autonomously generates stimulus. The generator classes help to rapidly create VMM-compliant generator components. In scenario layer generators generate individually random or constrained transactions. Fully directed or partially directed transactions can also be easily created. VMM provide macro vmm_atomic_gen for any user-specified class derived from vmm_data, using a process similar to the ‘vmm_channel macro. The atomic generator class is in an extension of the vmm_xactor class.

UART verification testbench has two special transactor, APB bus transactor and data generator transactor. Engineer can call ‘vmm_atomic_gen（APB_TRANS）to generate the transaction and will produce APB_TRANS_atomic_gen generator. APB_TRANS is the class name of the APB bus transaction. If call start_xactor（）function of APB_TRANS_atomic_gen, it will produce APB bus random transaction.

Example: APB_TRANS generator

class APB_TRANS extend vmm_data
…
endclass
`vmm_channel(APB_TRANS)
`vmm_atomic_gen(APB_TRANS, ” APB_TRANS Gen”)

3.3.1.4 Channel

Channel is used to exchange transactions between two transactors. Channel object is the primary transaction and data interface mechanism used by transactors. For APB bus transaction channel, we declared a channel class named APB_TRANS_channel for APB_TRANS class derived from the vmm_data class. VMM provide vmm_channel macro to define the channel class. The macro simplify the syntax of referring to the channel calss type and isolate users from the implementation details of the channel class. vmm_channel provide plentiful method, e.g. vmm_channel :: put, vmm_channle :: get. vmm_channel :: put will put the specified transaction descriptor in the channel at the specified offset. vmm_channel :: get will retrieves the next transaction descriptor in the channel at the specified offset.

Example: Declaring APB_TRANS channel class

Class APB_TRANS extends vmm_data
…
endclass: APB_TRANS
‘vmm_channel(APB_TRANS)

3.3.1.5 Physical Interfaces

SystemVerilog define interface for each signal bundle. It include signals are defined as logic, one clocking block per clocking domain, one modport per agent. Instantiate interface is in top-level module. The physical-level interface of command-layer transactors interact with the signal-layer construct. Physical interfaces are specified using a virtual modport interface as an argument to the transactor constructor. The virtual interface is stored in a public class property and this will let testcases access the physical interface signals expediently.

3.3.1.6 Self-check

The self-checking structure verifies the correctness of the response of the DUT, based on the configuration and stimulus streams. In UART verification testbench self-check include two arrays and a data comparing function. The two arrays save the input data and output data separately. The data comparing function compare the input data and output data in the arrays. If error is produced, the simulating broken down and report error information. In simulation processing the data comparing is performed self-acting by testbench and it improve verification efficiency.

3.3.1.7 Coverage Driven Verification

Coverage values will indicate how thoroughly the design has been verified.

Functional coverage is a measure of values deemed to be interesting and relevant. Since relevance and interest are qualities that are extracted from the intent of the design, functional coverage is not something that can be automatically extracted from the RTL source code. Your functional coverage metrics will be only as good as what you implement. Functional coverage can be used as an error detecting mechanism. The ultimate purpose of functional coverage is to identify what remains to be done.

SystemVerilog provides a set of predefined methods that let a testbench dynamically query a particular functional coverage metric. The testbench can then use the information to modify its current behavior. For example, it could increase the probability of generating values that have not been covered yet. It could decide to abort the simulation should the functional coverage not have significantly increased since the last query.

We define coverpoint and cross coverage based on VMM methodology for UART module. The coverage point is the sampling of an individual scalar value or expression. The object of a coverage point is to ensure that all interesting and relevant values have been observed in the sampled value or expression. Whereas coverage points are concerned with individual scalar values, cross coverage measures the presence or occurrence of combinations of values. Cross coverage involve more than two coverage points.

Table 3.2. UART Function Coverage Point and Cross Coverage
covergroup coverpoint coverpoint cross
Module function
(UART_mode
_register_scan) UART_no_empty_interrupt
UART_half_full_interrupt
UART_full_interrupt
UART_no_empty_inquire
UART_half_full_inquire
UART_full_inquire
UART_in_loop_mode
UART_out_loop_mode
ETU_hardware_delay
UART_even_odd_verify UART_no_empty_interrupt
& UART_no_empty_inquire
& UART_in_loop_mode
UART_half_full_interrupt
& UART_half_full_inquire
& UART_in_loop_mode
UART_full_interrupt
& UART_full_inquire
&UART_in_loop_mode
UART_no_empty_interrupt
& UART_no_empty_inquire
& UART_out_loop_mode
UART_half_full_interrupt
& UART_half_full_inquire
& UART_out_loop_mode
UART_full_interrupt
& UART_full_inquire
&UART_out_loop_mode
Error
Verification UART_rev_buffer_overflow
UART_jitter_offset
System
Function UART_etu_delay_cgu UART_etu_delay_cgu
& UART_baud_rate
& UART_idle_awoken_pd
UART_baud_rate UART_etu_delay_cgu
& UART_baud_rate
& UART_idle_awoken_inter
UART_idle_awoken_pd
UART_idle_awoken_inter
Implement UART_mem_read,
UART_mem_write

Example: Function Coverage Define

covergroup UART_mode_register_scan _cov;

coverpoint UART_no_empty_interrupt;
coverpoint UART_half_full_interrupt;
coverpoint UART_full_interrupt;
coverpoint UART_half_full_interrupt;
coverpoint UART_in_loop_mode
coverpoint UART_out_loop_mode
…
cross UART_no_empty_interrupt, UART_in_loop_mode;
…
option.weight = 0;
endgroup

The function coverage achieve 90 percent in the last phase of UART verification. We analyse the function coverage database and found the coverage hole, e.g. hole of ETU_hardware_delay. So we add directed test. Finally the UART function coverage reached 100 percent.

VCS provide unified coverage API and reporting. Unified report generator can produce an HMTL report for any given hierarchy or module and computes overall coverage score. DVE also provide unified interactive visualization of all types of coverage. All the features are available as part of VCS. Engineers analyse the coverage report and will accelerate the verification convergence.

Fig3.9 & Fig3.10 are the coverage reporting for URAT module in DVE.

Fig.3.9. UART Code Coverage Analysis in DVE
Fig.3.10. UART Function Coverage Analysis in DVE
3.3.2 Reuse of the Verification Platform
3.3.2.1 Reuse the Block Level Verification Platform in the System Level Verification

In the system level, the verification key point is to check interconnection among each modules in the whole chip. After VMM is introduced, the block level verification platform can be reused in the system level. The Embedded CPU can inject the internal chip stimulus through the APB Bus, and external stimulus can reuse the transactor and generator and so on in block level platform. Function coverage and Self-check module needn’t to be modified, verification cases are still be reused.

Fig.3.11. Reuse Block Level Platform in System Level
3.3.2.2 Reusing VMM Verification Platform in other project

The verification platform of one project can be reused in other similar projects by little modification. For example, the APB Port Monitor, Driver, and APB Bus Transaction Processor in UART block platform can be reused in other SoC projects with APB bus.

4 Conclusions

The Verification flow based on LEDA+VCS+SystemVerilog+VMM is portion of the Discovery Verification Platform. This flow can help us as follows:
 Verification plan in VMM can improve the completeness, effectiveness and feasibility
 In front of the simulation, LEDA can check RTL codes by the rules comprehensively and find potential bug as early as possible
 Testbench based on VMM can reuse easily
 Synopsys provides coverage technology from planning to convergence. All coverage features are available as part of VCS and it will accelerate the verification convergence
5 References
[1] Verification Methodology Manual for SystemVerilog
[2] Leda User Guide
[3] Some SIM Card Project
[4] UART Protocol