In the SoC design cycle, 70% of design resources are spent on verification
Many verification engineers struggle to achieve coverage closure
Coverage closure 100%, stimulus optimization is the key


As edge devices take on various roles due to the development of 5G, AI, IoT, etc., the requirements for the SoCs they are equipped with are naturally increasing.

In a typical SoC design cycle, 70% of design resources are spent on functional verification, and as designs become more complex, SoC verification is also becoming more difficult. If an error occurs during the verification process, the previous design flow must be repeated, which inevitably increases design time and cost.

This is why efficient verification methodologies and technologies are needed.

According to a 2016 survey by Wilson Research and Mentor, a Siemens business, many verification engineers cited creating sufficient and appropriate test cases to achieve coverage closure as the most challenging aspect of the verification process.

Previously, the directed tests method was used for SoC verification, but due to low productivity, the constrained random test method was introduced. However, this method has the problem that it is not easy to test for various environments because it randomly generates random variables, or stimuli.

To complement this, PSS (Portable Test and Stimulus) emerged.

Modeling test scenarios through PSS allows engineers to focus on verification requirements for what they are testing, and enables automation to create valid, specific tests. In addition, it allows these tests to be used in a variety of validation environments.

So how can PSS be used to change the existing SystemVerilog/UVM verification environment from 'How should I verify?' to 'What should I verify?' We asked about this plan to Sungjin Park, a deputy manager working as an FAE at Siemens Business and the creator of the portable stimulus test bench automation solution 'Questa® inFact.'


Q. As chips grow in size and complexity, the importance of verification is also increasing. I know that many engineers are investing a lot of time in verification, and in particular, are striving to achieve coverage closure. Please explain coverage closure.
A. The coverage we are talking about here means verification coverage.

Verification coverage is usually divided into code coverage and functional coverage. Functional coverage is a method of numerically expressing how much of all the operations that the design should perform in terms of functionality are performed according to the design specifications. Coverage allows verification engineers to determine how far testing has progressed and whether testing is sufficient.

Therefore, coverage closure is a process of performing verification until the target coverage value established in the verification plan is reached, and when coverage closure is achieved, the design design is considered to have been verified. Usually, coverage closure is performed with a goal of 100%.


Q. So what are some of the problems that occur when coverage closure is not achieved or coverage is low?
A. Low coverage means that verification has not been completed. This means that when the completed design is made into a semiconductor, it may not operate according to the design specifications.

Therefore, only when the coverage defined by the verification engineer can be fully achieved can the repetitive work of modifying the design for defects discovered after the semiconductor is manufactured and manufacturing the semiconductor again be reduced.

Achieving 100% coverage is a process that requires a lot of time and effort, so the reality is that semiconductors are being manufactured without 100% verification within the planned development period.


Q. What makes the process of achieving coverage closure particularly difficult?
A. Functional coverage is conducted using constraint random testing, which is a method of defining constraints in the code and randomly generating stimuli within that range to test.

Due to the nature of random testing, as the test progresses, there are cases where coverage does not increase, and in such cases, engineers have no choice but to intervene and repeatedly modify constraints considering target cases that were not covered. In this case, the remaining coverage can be increased a little more, but 100% coverage cannot be achieved. Therefore, for the remaining targets, stimulus is directly injected to achieve coverage closure.

Engineers try to increase coverage through this process, but sometimes they cannot achieve 100% coverage due to time or technical issues. Many of the stimuli generated in this process are duplicated tests, unnecessarily increasing verification time.


Q. What does Quest Impact support to achieve coverage closure?
A. There are three main things that Questa Impact provides.

First, it optimizes the stimulus to achieve coverage closure quickly, and second, it provides an environment where engineers can verify constraints of constraint random tests in advance before testing. Finally, it provides an environment where users can automatically create cover groups according to their purposes based on the described constraints. Therefore, it provides an environment where coverage closure can be accelerated overall by verifying the coverage model in advance without performing duplicate tests.


Q. What is stimulus and why should we optimize it?
A. The stimulus mentioned here is a vector value for testing the design. In the case of a constrained random test, you can think of the values of random variables as stimulus. As the test progresses, the simulator interprets the constraints defined by the constraint random solver to generate random values. At this time, it may generate stimuli that exceed the coverage target or generate duplicate stimuli.

For Quest Impact, the generated stimulus is optimized and provides non-duplicated stimulus and stimulus that matches the coverage target first.


Q. What is the newly emerging PSS (Portable Test and Stimulus)?
A. PSS is a standard developed by Accellera that is a standardized input language for describing test objectives for various verification platforms. This is an environment where you can test all platforms and design sizes, from block level to SoC level, and from simulation platform to emulation, with a single test intent.

Here, Quest Impact supports the easy and quick application of PSS modeled test intent into existing environments.


Q. What are the strengths of Questa Impact compared to other solutions?
A. Quest Impact can reuse existing UVM environments and system Verilog test environments. You can use the constraints and cover groups already described as they are, and apply them directly without PSS modeling or additional impact rules.

In addition, as I mentioned earlier, I would like to tell you that the function of pre-analyzing constraints before simulation and automatically generating cover groups is a big difference.


Q. Which engineer do you think needs Quest Impact?
A. I've heard that most verification engineers are experiencing a lot of pain and difficulty in achieving coverage closure. The main reason is that they have to continuously modify constraints and conduct repetitive tests, which takes a lot of time and effort.

For those who want to achieve coverage closure a little faster, have trouble adjusting constraints, or want to verify constraints before simulating, Questa Infect will be a great help.