EE 198: EECS151 Tapeout
Lecture 5: SoC Verification
University of California, Berkeley
IEEE Student Branch
University of California, Berkeley
IEEE Student Branch
Permanent Logistics Slide
University of California, Berkeley
IEEE Student Branch
Timeline Reminders
Happy Halloween!!
University of California, Berkeley
IEEE Student Branch
Last Last Last (??) Week Tonight
Last last week: project “lecture” & support
University of California, Berkeley
IEEE Student Branch
Summary of Today
University of California, Berkeley
IEEE Student Branch
Verification.. The Right Way
University of California, Berkeley
IEEE Student Branch
Verification The Right Way Is Hard
University of California, Berkeley
IEEE Student Branch
You will see this graph a dozen times
The gap has only grown!!
University of California, Berkeley
IEEE Student Branch
And this one
University of California, Berkeley
IEEE Student Branch
Most of industry time is spent on it..
Although we don’t have that luxury here..
University of California, Berkeley
IEEE Student Branch
.. yet they’re always behind schedule (relatable xd)
University of California, Berkeley
IEEE Student Branch
Why does it matter?
Why bother with verification when you can:
✅ Let your customers find the bugs for free!
University of California, Berkeley
IEEE Student Branch
Read more: https://www.righto.com/2024/12/this-die-photo-of-pentium-shows.html
<<<Just a few missing entries from their look up table …..
University of California, Berkeley
IEEE Student Branch
Summary of Today
University of California, Berkeley
IEEE Student Branch
Key Components of a Plan
“Functional verification”
“Constraints verification”
“Prototype validation”
University of California, Berkeley
IEEE Student Branch
IP-Level Functional Testing
What people may be most familiar with from 151/SW..
University of California, Berkeley
IEEE Student Branch
The Resume Booster: System Verilog
University of California, Berkeley
IEEE Student Branch
System Verilog (In One Slide)
Verilog was initially developed as a simulation language..
SystemVerilog is the de-facto industry standard
University of California, Berkeley
IEEE Student Branch
System Verilog for Design
Take 251b (or intern in DV) to learn more..
University of California, Berkeley
IEEE Student Branch
System Verilog for Design
Take 251b (or intern in DV) to learn more..
University of California, Berkeley
IEEE Student Branch
System Verilog for Verification
Take 251b (or intern in DV) to learn more..
University of California, Berkeley
IEEE Student Branch
System Verilog for Verification
Take 251b (or intern in DV) to learn more..
University of California, Berkeley
IEEE Student Branch
System Verilog for Verification
Take 251b (or intern in DV) to learn more..
University of California, Berkeley
IEEE Student Branch
System Verilog for Verification
Take 251b (or intern in DV) to learn more..
University of California, Berkeley
IEEE Student Branch
Try yourself!
Here’s a sample interview question I had before.
https://www.edaplayground.com/x/TiUL
And more! https://www.edaplayground.com/x/CK
University of California, Berkeley
IEEE Student Branch
Summary of Today
University of California, Berkeley
IEEE Student Branch
The (Im)Perfect Testbench..
A testbench is made up of multiple interconnected components..
University of California, Berkeley
IEEE Student Branch
A (SV) UVM Testbench Architecture
UVM is a method for architecting modular, reusable testbenches
University of California, Berkeley
IEEE Student Branch
A UVM Testbench Architecture
Test: Top-Level UVM component (instantiates top-level & env)
Environment: groups hierarchically other components
Scorecard: check a DUT’s behavior
Sequence: stimulus-generating behavior
Driver: takes stimulus, drives DUT
Monitor: samples DUT interface
Agent: groups a DUT’s verif components
University of California, Berkeley
IEEE Student Branch
Want more? There’s more.. And more..
Way more. Way way more. But let’s move on for now.
(get an internship and get paid to learn it!)
University of California, Berkeley
IEEE Student Branch
Are there alternatives? Yeah! Kinda
Languages: e/Specman (Verisity), VERA (Synopsys), Rave (Chronology..)
Methods:
Ever heard of them?
University of California, Berkeley
IEEE Student Branch
Language-level guarantees/’correct by construction’
“Modular Hardware Design with Timeline Types” PLDI 2023
Proves that a design compiles = (most) modules only read semantically valid values
University of California, Berkeley
IEEE Student Branch
Either way.. You can’t escape the testbench
And regressions (ie running the test suite over and over again..)
Typically in the form of constrained / exhaustive randomized testing
University of California, Berkeley
IEEE Student Branch
What about Constraints Verification?
NOT the same as constrained verification / SV constraint blocks
We also need to verify, generate, and manage SDC constraints
University of California, Berkeley
IEEE Student Branch
Constraints Files - It’s “Just” Files (and TCL)
Clock latency, false paths (or not), max fanout, in/out delays..
From synthesis to PaR, all tools eat them up!
Nom nom nom
University of California, Berkeley
IEEE Student Branch
Wait, so it’s all software? Well, so far..
But simulators only approximate reality: discrete, semantical..
Event driven sims: Never as fast as light :(
What if we do cycle-based? No timing info at all :(
A lot of “co-simulators” today are both
University of California, Berkeley
IEEE Student Branch
Not just software: Prototype Validation
Miss EECS151LB FPGAs? We’re (you’re) so back (again)!
FPGA are great for parallel processing - great functional verif speeds
But also enable software co-development & complex emulation
University of California, Berkeley
IEEE Student Branch
Some would say Prototyping is Peak Perf
But maybe FPGAs are just really cool and we are biased :)
University of California, Berkeley
IEEE Student Branch
Can we really test everything?
University of California, Berkeley
IEEE Student Branch
How Do We Verify??
University of California, Berkeley
IEEE Student Branch
Let’s consider an example
For example, let’s consider a 2D Convolution Engine
X
=
Source: https://github.com/npcarter2025/TileAlgorithms
Input Matrix
Output Matrix
University of California, Berkeley
IEEE Student Branch
Plan
University of California, Berkeley
IEEE Student Branch
High Level Approaches
University of California, Berkeley
IEEE Student Branch
University of California, Berkeley
IEEE Student Branch
Insert Example of JasperGold
University of California, Berkeley
IEEE Student Branch
C-Test IP-Level Verification
(what we do in EE194)
University of California, Berkeley
IEEE Student Branch
Golden Model with Constrained Randomized
University of California, Berkeley
IEEE Student Branch
Directed Edge Cases
- Boundary Conditions:
- Explicitly test padding, stride values,
University of California, Berkeley
IEEE Student Branch
Sounds Easy. What’s the Challenge here?
Any Ideas?
University of California, Berkeley
IEEE Student Branch
Sounds Easy. What’s the Challenge here?
University of California, Berkeley
IEEE Student Branch
Summary of Today
University of California, Berkeley
IEEE Student Branch
SoC-level Verification
(~Integration Testing)
University of California, Berkeley
IEEE Student Branch
University of California, Berkeley
IEEE Student Branch
Reusing IP-level VIP as much as possible..
We talked so much about functional testing & testbenches..
A bit about “constraints verification”, “prototype validation”..
Can we reuse any of it?
We definitely want to (and people will sell you their VIP solutions to help..)
University of California, Berkeley
IEEE Student Branch
…but is hard
How long are you willing to wait for build & compilation & sim?
T_T
University of California, Berkeley
IEEE Student Branch
And it only seems to get worse :(
Multi-physics, hardware and software, system, board, IC package, interposer, chip, and IP block issues all at once...
System-level issues now include security, performance, power…
University of California, Berkeley
IEEE Student Branch
Interconnects and Intercommunication
Interconnect delay dominates - timing closure & estimation hard :(
But verification of data movement between modules is also hard
Those sub-blocks and IP also need to be stitched together at the top-level for both sim and tapeout (sometimes not the same)
Sometimes referred to as subsystem verification or gray-box testing
University of California, Berkeley
IEEE Student Branch
Are we doomed to gamble with our chips?
With only 50-50 chances?!
University of California, Berkeley
IEEE Student Branch
Not if industry has anything to say about it!
Formal and static verification - not just weird math
Automated Test Generation
FPGA+HW acceleration for simulations
(More) Prototyping & Emulation
Mixed Signal Simulators
etc
*stockholders
University of California, Berkeley
IEEE Student Branch
Formal Verification
University of California, Berkeley
IEEE Student Branch
An Algorithmic Perspective..
University of California, Berkeley
IEEE Student Branch
Formal Verification
How do we verify every possibility without a testbench?
And how in the world do we make this scalable for SoC-level when non-exhaustive testbenches are too much even for IP-level?
The answer: Math
University of California, Berkeley
IEEE Student Branch
Formal Verification (and pseudo-formal..)
Formal places its bets on early detection and optimization
“Yeah, in the worst case these problems are NP-hard*… But I’m not a pessimist. I will be the lucky one.” - my imaginary friend Forma L
*shoutout to Lucy for the jokes
University of California, Berkeley
IEEE Student Branch
Formal Verification in Reality
In reality “formal” ecompasses a huge amount of methods
They make use of models - mathematical representations of the system, to be analyzed by an algorithm
University of California, Berkeley
IEEE Student Branch
Combinational SAT algorithms
To apply these, some methods convert circuits (CircuitSAT) to boolean expressions and apply satisfiability (SAT) algorithms
University of California, Berkeley
IEEE Student Branch
Combinational SAT algorithms
While NP-hard in the worst case, most industry SoC problems happen to fall into very solvable, and very efficiently, classes
So the impossible exhaustive search.. Becomes the secret sauce?!
University of California, Berkeley
IEEE Student Branch
Equivalence Checking with Golden Models
The two are a (sometimes) hidden part of most verification
University of California, Berkeley
IEEE Student Branch
What’s the point?
Okay, so I can model my circuit as a graph and do magic algorithmic math to verify circuits faster even for SoC level testing
(let’s pretend it’s that simple)
Is that all I can do?
Of course not!
University of California, Berkeley
IEEE Student Branch
Another problem: test search space
More gates - more toggling - more test vector possibilities
University of California, Berkeley
IEEE Student Branch
Automatic Test Pattern Generation (ATPG)
Wouldn’t it be great if I could apply these same methods to my traditional verification, like testbenches?
The same deterministic algorithm (branch and bound), in a new data structure, allows you to generate test vectors for your circuit
Can be hard to scale though (industry secrets)
University of California, Berkeley
IEEE Student Branch
Emulation & Prototyping & Regressions..
You can still apply IP-level methods with less granularity
Firmware & UVM hybrid sequences at the chip level are possible
Hardware emulation is preferred
Now verif engineers work more with designers!
University of California, Berkeley
IEEE Student Branch
SystemC - the SoC-level test language
It’s not just the choice of HDL: workloads + kernels in industry are often written in SystemC, an event-driven sim extension of C++
SystemC is a set of C++ classes and macros which provide an event-driven simulation interface (see also discrete event simulation). These facilities enable a designer to simulate concurrent processes, each described using plain C++ syntax. SystemC processes can communicate in a simulated real-time environment, using signals of all the datatypes offered by C++, some additional ones offered by the SystemC library, as well as user defined. In certain respects, SystemC deliberately mimics the hardware description languages VHDL and Verilog, but is more aptly described as a system-level modeling language. -> https://en.wikipedia.org/wiki/SystemC
University of California, Berkeley
IEEE Student Branch
Analog Macro Verification at SoC Level
We briefly mentioned golden models before
At the SoC level, a digital reference model is needed for analog blocks to do SoC-level functional tests
University of California, Berkeley
IEEE Student Branch
Analog Mixed Signal (AMS) Sims
You can’t create digital models for everything .. studies show that SoC interfaces have significantly contributed to chip failures
University of California, Berkeley
IEEE Student Branch
A ‘real’ AMS verification setup (Spectre AMS + Xcelium)
RTL required to drive the PHY
University of California, Berkeley
IEEE Student Branch
Quick Note on Validation
Verification vs Validation - what’s the difference?
University of California, Berkeley
IEEE Student Branch
Of course, everyone’s also adding ML to everything, verification included
tru story
University of California, Berkeley
IEEE Student Branch
Closure & Sign-off
University of California, Berkeley
IEEE Student Branch
Final Sign-Off - remember that verif plan?
Fulfill all the initial criteria
University of California, Berkeley
IEEE Student Branch
The Most Familiar Metric: Coverage
The amount my testing covers, right? But what does that mean?
Functional + code coverage closure is one of the major milestones
Functional =/= code coverage - why?
University of California, Berkeley
IEEE Student Branch
Infrastructure IP (I^2P)
Separate from functional verification - Design for Test techniques
University of California, Berkeley
IEEE Student Branch
Summary of Today
University of California, Berkeley
IEEE Student Branch