CND 212: Digital Testing and Verification

Introduction
 Contents
❑ Introduction
❑ Digital IC Verification
❑ Verification Approaches
❑ Verification Levels
❑ Verification Metrics
❑ Main Verification Methods
❑ Verification Steps
❑ How Does Testing Work?
❑ Verification Testbench
❑ SystemVerilog

•
2
Introduction
System on Chip (SoC)

3
Introduction

Normal VLSI/Chip design flow

4
Digital IC Verification

❑ Design Verification: the process of checking that a given design

correctly implements the specification and the required
functionality.

❑ Design verification consumes around 80% of the total product

development time.

❑ The complexity of SoC design is constantly growing.

❑ The main SoC design issue shifts to the verification method. Semiconductor Engineering. n.d. Beyond The Water Cooler: 2020 Report On IC/ASIC Design And Verification
Trends. [online] Available at: <https://semiengineering.com/beyond-the-water-cooler-2020-report-on-ic-asic-
design-and-verification-trends/>.

❑ The aggressive reduction in the system development life cycle

implies inadequate time for thorough design review and potential
misunderstanding of specifications and requirements.

5
Digital IC Verification

Verification Most Common Challenges

❑ Shrinking Verification Time
➢ Leaving little time for customized verification efforts.
➢ Indicating the need for verification with high level of scalability and reusability.

❑ Integration And Complexity

➢ The primary focus in SoC verification is on checking the integration between the various components.
➢ The combined complexity of the multiple sub-systems can be huge.
➢ There are many seemingly independent activities that need to be closely correlated.

❑ Specification Capture
➢ SoC design requirements span across multiple documents.
➢ Reconciling the descriptions from the different documents is a highly complex activity.

6
Digital IC Verification

What is to be verified?

Functional Performance
Verification Verification

Timing
Verification

7
Digital IC Verification

Verification Goal

➢ Make Sure the Design does the required function

successfully.

➢ Detecting Bugs, errors, and issues to achieve this goal.

8
Verification Approaches

Verification without knowledge

Black Box of design implementation
Verification

Requires an intimate
knowledge of the design
White Box implementation
Verification

Considered a compromise
Grey Box between the two approaches
Verification

9
Verification Levels

➢ A normal design phase is divided into multiple blocks

including “Board”, “Systems”, “Sub-Systems”, “Core IP Blocks”, “Units” and

“Sub-units”.

➢ verification is also divided into multiple levels:

1. Basic verification: (at Unit/Sub-unit level)

2. Functional verification: (at IP blocks level)

3. System level verification: (at Systems level)

4. Connectivity: (at Board level)

10
Verification Metrics

Metrics are measurements, They help us to track our progress

towards completion and quality of verification. How many tests are being
conducted

how many stimulus are being

returned

what is the pass rate

what is the failure rate

how many bugs are found

11
Main Verification Methods
❑Simulation-based Verification

Vivolo, L.. Transaction-based Verification And Emulation Combine For Multi-megahertz Verification Performance. [online]
Electronicdesign.com. Available at: <https://www.electronicdesign.com/technologies/eda/article/21796417/transactionbased-
verification-and-emulation-combine-for-multimegahertz-verification-performance>.

12
Main Verification Methods

Pre-synthesis and Post-synthesis Simulation

Pre-synthesis Simulation Post-synthesis Simulation

➢ Simulating to verify the RTL code to meet ➢ Simulating a synthesized netlist to verify
the required specifications. that the synthesized design meets the
functional requirements and behaves as
➢ Debugging and fixing issues before using expected.
synthesis tools.

Pass Pass
Pre-synth. Post-synth. Place and
RTL Synthesis Simulation
Simulation Route

Fail Fail

13
Main Verification Methods
❑Emulation-based Verification

Vivolo, L., 2021. Transaction-based Verification And Emulation Combine For Multi-megahertz Verification Performance. [online] Electronicdesign.com. Available
at: https://www.electronicdesign.com/technologies/eda/article/21796417/transactionbased-verification-and-emulation-combine-for-multimegahertz-verification-
performance.

14
Verification Steps

Understand the specs

• Studying the features and specifications required to be

1 implemented in the design.

Create a verification plan

▪ The Design Under Test (DUT) Interface
▪ The Main design features and specifications

2 ▪
▪
The Testbench Architecture
The testing scenarios

15
Verification Steps

Identify the verification methods required, test benches,

coverage, reference models and stimuli
3

Build Verification environment

4

Execute a plan: develop and run tests, find bugs.

5

16
How Does Testing Work?

➢Directed Testing
▪ Directing tests to a specific feature or all features in a design.

▪ Advantage: it doesn’t require extensive coverage coding and works well when the condition space is
finite.

▪ Disadvantages:

• it can only cover scenarios that were thought of during planning.

• It is not suitable for complex designs with many configurations.

• It has a high maintenance cost.

17
How Does Testing Work?

➢Pure Random Testing

▪ Making a random test instead of creating a direct test for every single feature in the design,
▪ Using multiple different scenarios in a random manner.
▪ Direct Testing is more useful if the design is at its early stages and you can access every single feature
solely,
▪ Whereas random testing is more useful in complex designs or mature ones at their late stages of
development.
▪ Advantages:
• Random Testing requires less user control,
• Hence saving an Engineer’s time,
• And simple to build,
• Disadvantage: It needs infinite computing cycles to cover all condition space.

18
 How Does Testing Work?

➢Constrained Random Testing

▪ As the number of conditions tends towards infinity,

▪ Random testing can save on the Engineer’s time but at the

expense of compute cycles;

▪ That is where constraints come into places where you can

generate stimulus only around interesting design points.

▪ Advantages:
• It allows us to reach 100% testing in a shorter time.
• Using random stimuli allows us to find unexpected bugs.
• Random testing uses scenarios that the design never
thought of.

19
 Verification Testbench

➢Testbench is implemented to check the functional correctness

of the design under test.

➢Testbench Responsibility
▪ Generating input stimulus

▪ Driving an input stimulus

▪ Monitor design activity at the output and input level.

▪ Compare output transaction correctness based on the driven input stimulus.

▪ Sampling function converges and assertion correctness.

20
Verification Testbench

Direct Testbench
➢ Using Test vectors as input to DUT.
➢ Comparing DUT Output with the expected one.
➢ Not Scalable
▪ Hard to add new test cases.
▪ Hard to add new features.
➢ Not reusable.
➢ Hard for maintenance.

21
 Verification Testbench

Efficient Verification Testbench

➢ Transaction
Top
▪ Class that holds a structure used to communicate with
DUT.
▪ Then converted to pin-level data to be driven to the DUT or
monitored.
➢ Generator
▪ Creates or generates randomized transactions or stimuli
and passes them to the driver.
➢ Driver
▪ Interacts with DUT directly.
▪ Receives randomized transactions from the generator and
drives them to the DUT as a pin-level activity.
➢ Monitor
▪ Observe pin-level activity on the connected interface at the
input and output of the design.
▪ Then, convert the pin-level activity into a transaction packet
and send it to the scoreboard for checking purposes.

22
 Verification Testbench
Efficient Verification Testbench
➢ Agent
▪ Component that holds the generator, driver, and monitor
Top
▪ Deals with a specific DUT interface.
▪ More than one Agent for more than one interface.

➢ Scoreboard
▪ Comparing the received transaction packet from the monitor
with that of the reference model.
▪ The reference module is written based on understanding the
design specification and design behavior to mimic design
functionality.

➢ Environment
▪ Allows a well-mannered hierarchy and container for agents
and scoreboards.
▪ Testbench may have more than one environment.

23
Verification Testbench
Efficient Verification Testbench
➢ Test
▪ The test is at the top of the hierarchy, initiating the Top
construction of the environment components and the
connection between them.
▪ Responsible for the testbench configuration and stimulus
generation process.

➢ Testbench top
▪ The top-level component that includes interface and DUT
instances.
▪ The design is connected to the testbench in the Top model.

24
Verification Testbench

Efficient Verification Testbench

➢ Layered.

➢ Reusable.
Top
➢ Scalable.

➢ Easier to maintain.

25
SystemVerilog

➢ Standardized as IEEE 1800.

➢ Is a hardware language used for modeling, designing, and testing.

➢ It combines the capabilities of both design and verification into one language;

➢ Mainly used for RTL Design, assertions and verification,

➢ But with some key improvements over Verilog.

26
SystemVerilog

In Design
➢ SystemVerilog is an extension of Verilog.

➢ Allows users to define new types, including user-defined data types.

➢ Includes operators reused from C/C++ that can simplify the code while making it easier to understand,
e.g., ++ and break.

➢ Allows Arrays with multiple dimensions.

27
SystemVerilog
In Verification
➢ It has several programming improvements inherited from C language like data types and C
statements, including classes for OOP.

➢ It has a direct programming interface (DPI), a lightweight interface that allows you to call system
Verilog functions from C, and C functions from System Verilog.

➢ It has improved verification due to constrained random testing and verification using classes.
▪ Automatically check the results of the simulation, which is enabled through assertions.
▪ “Are we done?” through functional coverage, a metric that tells us how much verification we
have performed.
▪ We have to somehow direct the stimulus; this is done through a set of constraints to target
corners and interesting cases.

28
Resources
• Mark Zwolinski, Digital System Design with SystemVerilog, Prentice Hall.
• N. K. Jha, S. Gupta, Testing of Digital Systems, Cambridge University Press
• Lun Li , Mitchell A. Thornton, Digital System Verification, A Combined Formal Methods and Simulation
Framework, Springer.
• https://www.scribd.com/document/402666798/Springer-SV-Solutions-Manual
• https://verificationacademy.com/topics/systemverilog/
• https://www.youtube.com/watch?v=imH4CFmVGWE&list=PLBIILfL2t1lnvzw7vF0arlvu36Wj4--D7

29