As the scale and functionality of SOC chips continue to expand dramatically, SOC verification can account for more than 60% of the entire project, making verification a bottleneck in the development of SOC chips. Insufficient chip verification can lead to severe losses, such as re-taping, wasting time and capital, and in severe cases, depletion of funds and company closure. In the chip industry, there are also “seven weapons”; when used correctly, these seven weapons can maximize the assurance of adequate chip verification and reduce the risk of tape-out failure.
1: UVM
UVM is not a programming language; UVM (Universal Verification Methodology) is a verification methodology.
Although UVM is not a language, it is presented as a verification platform framework based on SystemVerilog classes and libraries, as it is very popular in the chip verification field, becoming a de facto standard for verification platforms.
As the saying goes: “If you don’t know UVM, you are just a hero in vain.”
Boss Jia established an AI chip company to develop an AI chip and asked a UVM master how to ensure the chip’s correctness.
The UVM master said, “I know nothing about your chip and cannot tell you if it is correct, but I can verify A=B;” by verifying numerous vectors comparing chip A with reference model B, checking if their outputs are consistent. If they are consistent, then A=B; thus, the verification conclusion is that chip A and reference model B function consistently, and chip A meets design requirements, thereby ensuring chip correctness.
Boss Jia was completely confused; how did B come into the picture?
(Note: A and B have the same functionality, but that does not mean A and B are equal; in this article, we use A=B to simplify this concept.)
Boss Jia asked: “Isn’t it like software testing, where there is a test outline, and we test each item to see if the functionality is correct? Isn’t UVM like this?”
The UVM master replied: “Not at all. We introduce a variable B, and the functionality of A and B outputs consistently under various stimuli to infer A=B; this is one of the essences of the verification methodology.”
A is the chip under test (DUT), which is designed by engineers who have racked their brains and lost their hair to create the chip (or IP);
B is the reference model, RM (reference model), also affectionately called “Dog Sheng” (Golden).
Upon seeing this, Boss Jia had a first question: Where does the reference model B come from?
The UVM master said: “Since Boss Jia asked this question, it naturally comes from you; causality is fixed.”
Boss Jia established an AI chip company, hired an AI master, who pondered and realized a new algorithm that effectively improved performance and reduced storage costs, published at CVPR (the top conference for computer vision and pattern recognition), and then the AI master implemented this algorithm in Python; then Boss Jia recruited a group of IC design engineers to turn this algorithm into a chip (IP);
The UVM master said, “Look, this chip (IP) is DUT, which is A, while the original AI master’s algorithm description in Python is the reference model, which is B;”
The job of UVM is to verify A=B; if the functionalities are different, it indicates that the chip design A is wrong; if A=B is verified, then the UVM master has fulfilled his duty, and the chip can be taped out.
Now, isn’t this process much clearer?
The algorithm master designed the algorithm, the design engineer created the chip, and the UVM master verified the consistency of both through the verification methodology (UVM); perfect, and it can be taped out.
But wait, the second question: How to verify A=B?
The UVM provides a portable ready-made architecture that can simultaneously send test vectors to A and B. By constructing test vectors, we send them to both A and B and collect their outputs to compare if the results are consistent. If the comparison results are consistent, the verification is successful; otherwise, it fails.
If only for one test vector CASE1, the output results of A and B are consistent, it cannot prove A=B; it can only indicate:
IF (CASE1) A=B
So, the verification master needs to design N test vectors, from CASE1 to CASE N.
IF (CASE1->CASE N) A=B
The process of sending these test vectors (stimuli) is similar to a Gatling gun, sending different types of ammunition to A (DUT) and B (RM); these ammunition can be regular bullets, grenades, shells, or missiles.
Design various types of ammunition and assign them different characteristics such as size, firepower, distance, etc., each different, but these ammunition inherit the characteristics of the original ammunition, no need to develop from scratch, simple and convenient;
On one hand, this ammunition can be set as random ammunition; that is, the same ammunition but different every time it is fired, possessing randomness, for instance, one ammunition can have a random initial speed, and each time it is fired, we can check if the target device performs normally at any initial speed; similarly, other random characteristics can be set;
On the other hand, it cannot be completely random; after all, completely random lacks purpose; we need to constrain (constraint) this randomness of ammunition. For example, to hit a mosquito, we don’t need a cannonball; to hit an aircraft carrier, a hand grenade is also unreliable; it cannot be completely random. By constraining the randomness, we can increase the purposefulness of the ammunition;
Construct various types of ammunition and see if the responses of A and B are consistent; if consistent, everything is fine; if inconsistent, then there is a bug, and we need to debug to see why A and B are inconsistent, and feed back to the designer to modify the original design (DUT) until both are consistent.
Now, the third question arises: How many CASEs must be constructed to prove A=B?
The sage said: “Verification time is finite, while verification cases are infinite; using the finite to address the infinite is perilous.”
However, Boss Jia doesn’t care; he will directly ask: “Although the master has constructed so many verification cases, can these cases prove A=B? Verification has no end.”
The UVM verification master said: “Boss Jia, please see, the AI algorithm master has described 100 functional points, and I have designed 100 verification cases based on these points, and all comparisons have been successful, indicating full functional coverage; additionally, every line of the chip design, each state machine state, every branch, and every condition has been covered, indicating there’s no need for additional test CASEs.”
Seeing Boss Jia seemingly understand, the UVM master explained: “The UVM master has already used a Gatling gun to attack the DUT from all angles; bullets, grenades, pistol bullets, machine gun bullets have all been used; now A and B have performed the same under these attacks, thus proving A=B.”
Boss Jia said, “I understand, it seems A and B can both be killed thoroughly, there’s no need to shoot again.”
(Note: 100% functional coverage and code coverage are not the end of verification; some functional points cannot be guaranteed by functional coverage, such as considering boundaries, exceptions, special checks, etc., which will not be elaborated on here; code coverage mainly guides verification engineers on where to add cases.)
Having a reference model is better than not having one; if there’s no reference model, create one for comparison; a verification item without checks and comparisons is a dud (invalid case) and cannot serve its purpose; there’s a counter-effect where one might think verification coverage is achieved, but in reality, it’s not, which is a major taboo in UVM.
Understanding the UVM philosophy, it is actually not limited to using SystemVerilog for verification; UVM’s platform architecture and various libraries are very mature, and by transplanting this architecture, a verification platform that meets each chip’s requirements can be quickly built; additionally, through the UVM platform, external languages such as Python, C, C++, etc. can also be used to design ammunition, and the outputs of A (DUT) and B (reference model) can also be compared through the UVM platform, making the UVM platform a complete conduit where both ammunition (test vector generation) and comparisons can be completed using other languages (like Python, etc.). There are no fixed strategies in warfare, and water has no constant form; the philosophy of gaining the way is to use it as one wishes.
2: VIP
For example, the purchased DDR, PCIe, MIPI, UFS, AXI interfaces, or AMBA buses, are very complex, whether in terms of verification cases or reference models. It far exceeds the workload that a beginner design company can handle from scratch. In short, according to the existing project plan, it simply cannot be completed. Now Boss Jia has two choices: one is for the team to slowly explore and gradually familiarize themselves, which would make the product launch time uncontrollable; the other is to spend money to buy VIP.
This VIP is not Boss Jia’s status symbol at the airport or KTV, but rather an IP specifically for verification; doing SOC not only requires purchasing IP but also VIP; Boss Jia feels he has boarded a pirate ship, as everything in chip development costs money.
These VIPs are directly native System Verilog/UVM, built-in verification plans and coverage, as well as some test suites, complying with these protocol specifications; all standard peripheral chips such as DDR, HBM, eMMC, UFS, AMBA, MIPI, SDIO, SAS, SATA, PCIe, USB. There’s nothing you can think of that VIP providers can’t do.
This is similar to Boss Jia wanting to advance to become a hero; he bought a Dragon-slaying Sword (interface IP) and also needs to buy a Book of Eighteen Sword Techniques (VIP); otherwise, the cost of exploring and familiarizing himself with this treasure sword would be too high. As long as he runs through this Book of Eighteen Sword Techniques (VIP), it proves that the Dragon-slaying Sword (IP) is problem-free, and he can venture into the world.
The money spent on VIP is not wasted; it can achieve twice the result with half the effort. After each high-speed IP is integrated into the entire SOC, running through all the cases provided by VIP confirms two things: first, this IP is problem-free, and second, the integration of the IP is also problem-free. It is quick and efficient, speeding up verification and convergence.
Standard things have standard practices; standard interfaces have corresponding VIPs that meet the standards. Starting verification from scratch is neither wise nor time-efficient. Maximizing the use of existing experience and achievements (IP and VIP) is the cornerstone of making chips increasingly complex. Doing everything from scratch, especially in the design and verification of standard interfaces, is self-indulgent and deviates from the original intention of chip design to create value for customers.
3: Hardware-Software Co-design
Boss Jia asked engineers to develop the most powerful terminal AI chip in the world, which includes CPU, DDR, buses, AI processors, MIPI, and WiFi networks, with processing performance requirements reaching the world’s first, so Boss Jia can boast.
The self-developed AI processor has been verified by UVM to prove A=B, perfect;
The peripherals can be verified through VIP, running through the VIP process, no problems, perfect;
But is that enough?
This situation faces a problem: where is the reference model for this large SOC chip? Do you remember the B needed by UVM? Who can create a reference model B for comparison? Not every situation has a perfect reference model for comparison; the core application scenario of the chip is that images captured by MIPI are cached in DDR, identified by the AI processor as potential criminals, and then the images of the criminals are uploaded to the backend via the CPU. All components are involved; how to verify this?
All of this requires software and hardware collaboration to achieve scene verification.
In complex SOC system design, conducting hardware design verification and software design verification simultaneously, and achieving interaction design and verification between hardware and software becomes the key to shortening the design cycle and completing system design as early as possible. By using the software of the CPU and the AI processor in conjunction with the UVM platform, the entire design process is implemented through software, and then the software runs on the entire verification platform.
Hardware-software co-simulation sounds very impressive; in actual operation, the UVM platform builds a software testing platform. The work done by UVM is minimal; a common practice is to sneak the software compilation files into the system (UVM also needs to sneak in, backdoor, which is a UVM term; it does not increase verification time, directly writing the BIN file to RAM); then the software engineer’s performance begins.
The software process here can be programming for MCU, MPU’s Linux, or even Android, regardless of complexity. This hardware-software collaboration allows many software engineers to participate in SOC chip verification; that’s the reason.
The purpose of hardware-software collaboration is to let software developers enter the scene early. It’s like designing a new house; the furniture and soft furnishings must be arranged during the design phase, so they don’t find out after the house is built that there’s no space for installing furniture and soft furnishings. If the owner doesn’t buy it, the designer will have a big problem.
In addition, the efforts of software developers are not solely for chip verification; this software can also be provided as SDKs for users, becoming part of the entire chip product. Hardware-software system verification is a contradictory set; it verifies hardware through software and verifies software through hardware.
1: Verifying Hardware through Software;
This is easy to understand; software engineers program the business scenario, implementing the process where images captured by MIPI are cached in DDR, identified by the AI processor as potential criminals, and then the images of the criminals are uploaded to the backend via the CPU. This entire testing process demonstrates that each module of the hardware can work normally under the scheduling of the software, according to the expected functionality and performance, ensuring that this process works normally, verifying that the SOC integration’s bus connection is correct, functionality is correct, performance meets requirements, and user scenarios can be fully covered.
2: Verifying Software through Hardware
Still referring to the previous process, if the process of capturing, identifying, and sending encounters issues, it could be due to a chip design error or a software error. If there’s a software error, it needs to be modified to achieve the desired effect. The software also gradually improves, iterating and maturing. This is the process of verifying software through hardware.
Note:
a: The AI processor IP layer proves A=B through the reference model, possessing more black-box testing characteristics;
b: The hardware-software collaborative verification on SOC has more white-box testing characteristics; software personnel must deeply understand the functions and mechanisms of each module to conduct comprehensive scenario testing.
4: FPGA
If chip designers consider area, power consumption, frequency, etc., then one important aspect for chip verifiers to consider is verification time; nothing tests a chip design company’s capabilities more than not delaying the product’s time to market.
Boss Jia is working on an AI chip, and each verification case takes 30 minutes, which can process one image; in one day, it can process 48 images from the image library. With 100,000 images in the verification image library, it calculates that it will take over 2000 days to complete the verification; if using 10 servers in parallel, each running 10 verification cases simultaneously, it will still take 20 days to iterate once.
Boss Jia is very anxious; is there any way to iterate quickly? The market does not wait for anyone; if missed, competitors will take over.
Using FPGA testing is an efficient solution: migrate the entire project to FPGA and simulate the entire chip operation state on FPGA to achieve rapid testing results; such high-capacity FPGAs are very expensive, generally ranging from hundreds of thousands to over a million; they are also very large, but such useful devices are typically purchased by chip design companies.
The frequency of FPGA can reach actual operating frequencies of tens to hundreds of MHz based on the length of the critical path; currently, the FPGA used for verification is monopolized by XILINX’s large-capacity FPGAs; it can accelerate iteration, allowing for rapid problem discovery and large data volume testing.
After Boss Jia decided to purchase this FPGA verification platform, he could get results for the 100,000 images in just a few minutes; the efficiency of chip verification greatly improved, accelerating the iteration of large data volumes. Additionally, the FPGA can serve as a prototype, directly demonstrating results to Boss Jia, who feels that this FPGA verification prototype board was worth buying, even though it was a bit expensive and cost him a Cayenne, the money was not wasted.
Meanwhile, the efficiency of software running on the FPGA will also greatly improve, accelerating the software/firmware iteration process, uncovering many issues that cannot be found on the simulation verification platform.
However, a problem arises: if FPGA verification discovers a bug in the chip design, for instance, the recognition of a large number of images is sometimes unresponsive, is it an issue with MIPI, the CPU, the AI processor, or the DDR memory? The likelihood of discovery in UVM simulation may be low; such a large volume of data errors may only surface after several days to weeks of simulation.
FPGA makes it easy to discover problems, but sometimes locating the issue can be quite challenging; it is not uncommon for a single problem to take a week or several weeks to resolve. Each iteration is counted in days, improving the speed of problem localization and accelerating convergence is a challenge in FPGA debugging.
5: “Accelerators”
Accelerators: A heavy sword without a sharp edge, great skill in simplicity;
FPGA requires figuring out which areas are problematic, adding signals to embedded logic analyzers to view waveforms. An accelerator can directly display all waveforms like simulation, eliminating the need for FPGA to recompile for waveform verification, which can take a day for each iteration;
For example, when Boss Jia swims and drops his ring in the pool, FPGA debugging requires him to hold his breath and search each spot one at a time, which is inefficient; however, an accelerator is like installing cameras around and at the bottom of the pool, allowing him to find the problem by checking the footage.
An accelerator possesses the speed of FPGA, albeit slightly slower; it also retains the flexibility of simulation, allowing visibility of all signal states. Accelerators can significantly enhance iteration cycles; if the chip is too large, simulation speed is too slow, for example, cloud-based AI chips, which are large, with hundreds of billions of transistors, making it hard to fit into FPGA prototypes; simulating everything is very slow; if in a UVM simulation environment, loading Android would take seven days to check, which is simply too late.
Currently, there are only three manufacturers of accelerators:
Mentor’s Veloce;
Synopsys’s Zebu;
Cadence’s Palladium;
Accelerators are relatively expensive; depending on the configuration and license, they typically cost several million; they require dedicated personnel for maintenance, and if you can’t afford one, you can rent it, with costs calculated based on usage hours; actually, small chip development generally doesn’t require accelerators; large chip (over 100 million gates) companies with strong capabilities might have one; after all, even someone as wealthy as Boss Jia wouldn’t easily spare the money to buy one.
6: Formal Verification
If a bug appears in the chip verification before the project enters the backend design phase, and the backend does not allow re-synthesis at this point, because re-synthesis would lead to backend rework, for example, if the DFT chain has already been inserted, then re-synthesizing the netlist could result in inconsistencies in the number of registers (each synthesis’s netlist is generally hard to keep consistent); much of the backend layout and routing (PR) work has already been done, and if the netlist is re-synthesized, the backend PR engineers and DFT engineers will go crazy, having to redo a lot of work, taking weeks or even months; this is especially true for large chips, while smaller chips are somewhat better. At this point, it is necessary to make modifications to the netlist (ECO).
At this time, how to ensure that the ECO netlist modifications are correct? This is where formal verification comes into play; without formal verification, if we were to re-add the ECO netlist as DUT to the simulation platform, the simulation would be immensely slow, making it difficult to verify the ECO netlist adequately.
Formal verification mainly compares whether the ECO netlist and the modified RTL are equivalent; if they are equivalent, then the modified RTL can be directly returned, although simplification is still time-consuming.
Formal verification has many other functions as well, such as ensuring the code and synthesized netlist are consistent during synthesis; during ECO, ensuring that the netlist, DFT netlist, and PR netlist are all consistent with the modified RTL.
Formal verification is like a great transfer of power; originally A (netlist) was modified and needed verification, but now through formal verification, A (netlist) and B (code) are equivalent, so we only need to verify B (code), which significantly reduces the difficulty of verification and improves efficiency, making it faster than simulating the netlist directly by an order of magnitude.
7: Process Specifications
The author of The Wandering Earth, Chinese science fiction writer Liu Cixin, describes two types of people in his book The Three-Body Problem: wall-facers and wall-breakers; wall-facers must defeat the plans of the Trisolaran against Earth by designing a series of counterattack plans; while wall-breakers mobilize all resources to use the wisdom of the sophon to monitor the wall-facers’ every move, analyzing every public and secret behavior to crack their true strategic intentions. Each wall-facer has a wall-breaker targeted at them; wall-facers and wall-breakers are like chip designers and verifiers; the wall-breakers in the Three-Body Problem have no specifications, but chip verification must have many specifications to constrain it.
Without verification specifications, the quality of verification will be uneven, and the quality of the chip depends on the short board of the barrel; verification specifications also rely on human execution. A complete verification specification includes several categories, whether it’s module verification specifications (module level), integration verification specifications (SOC level), FPGA testing, etc.;
1: Verification plans: functional point decomposition, including scenarios, functionality, performance, exceptions, boundaries, etc., and check strategies for each point;
2: Verification execution: constructing verification cases, debugging, problem iteration processes, etc.;
3: Verification output: verification report output and review, etc.;
4: Verification management: verification segmentation, bug list, bug review, regression testing, etc.;
As chips become increasingly complex, the teams involved in chip development are growing larger, facing rising challenges; due to the time window for product launches, verification progress is a process of solving under limited resources, not a reckless attack under infinite resources.
1: Complexity:As chip scale increases, chips with billions or hundreds of billions of gates are not uncommon; chip design is one of the most complex designs of the human species, for example, Apple’s M1 processor has 16 billion transistors. This is only the complexity of hardware scale and does not include the software running above it; the software running above is also becoming increasingly complex, with CPU software, GPU software, NPU software, etc.; it may require multiple software and various programming language systems to operate as a whole.
2: Communication:While design and verification personnel can communicate through documents, circuit diagrams, meetings, and various means, it is challenging to fully synchronize their understanding. Like the wall-facers and wall-breakers in the Three-Body Problem, finding bugs in wall-facers isn’t too difficult; the key is to find all bugs, 100% of the bugs, because even leaving one can significantly impact the chip; as the chip team grows, the communication costs among members also increase significantly, leading to many management issues, and poor communication can result in much information loss.
“Having heard many great truths, yet still unable to live well in this life.”
Even if all these “weapons” are used, can the chip have no issues? Certainly not enough; from product definition, design, verification, backend, tape-out, packaging, testing, every link may introduce risks; these “weapons” are merely means to reduce risks, but cannot eliminate them 100%; “deploying before fighting, the basics of military strategy, the cleverness of application lies in the heart.” Chip development is inherently a practical science; only by combining these weapons with real-world problems, iterating and improving, can we truly solve problems.
E课网(www.eecourse.com) is a professional integrated circuit education platform under Moore Elite, dedicated to cultivating high-quality integrated circuit professionals for the semiconductor industry. The platform is oriented towards the job needs of integrated circuit companies, providing a practical training platform that fits the corporate environment, quickly training students to meet corporate needs through online and offline training methods.
E课网 has a mature training platform, a comprehensive course system, and a strong teaching faculty, planning 168 high-quality courses for the Chinese semiconductor industry, covering the entire integrated circuit industry chain, and has four offline training bases. To date, it has deeply trained a total of 15,367 people, directly delivering 4,476 professionals to the industry. It has established deep cooperative relationships with 143 universities and has held 240 corporate-specific IC training sessions.