Funny thing happened today.

After reaching out to people last week for SVUnit success stories, to my pleasant surprise I found one in my inbox this morning. It was from SVUnit early adopter Manning Aalsma of Intel (formerly of Altera). When I say early adopter, I mean early. Looking back, I found the first email he ever sent me still in my inbox requesting an early version of SVUnit. Timestamp on that was Jan 8, 2012!

I’m happy to have people like Manning using and advocating for the framework and the techniques that go with it. Here’s what he had to say about he and his teammates using SVUnit.

Thanks Manning!

-neil

---

Hi Neil,

Catching up on a little reading, I came across your post from a week ago or so:

http://agilesoc.com/2018/06/11/is-svunit-a-legitimate-verification-framework/

I thought I’d share my experience so far.

On a customer FPGA design, our designers have built their own unit testbenches and testcases, most of them based on SVUnit 3.26.  Due to history, one such RTL block did not use SVUnit.  Among the RTL blocks that do have SVUnit-based testbenches, they still differ from each other in many ways.  And, there is a clear violation of the F.I.R.S.T.principles of unit testing that some of these have randomization (not Repeatable), too much functionality in the module-under-test (not very Isolated/Independent), and even lack of use of the `FAIL assertion macros (not Self-validating).  However, it’s all still better than nothing.

Our verification engineers are starting to eat our own dogfood by practicing TDD and using SVUnit to verify our verification code before letting embarrassing bugs escape into integration-level verification.  At least I am trying to take charge by example when bringing up a redesign of a PCIe verification component.  I have tried to use similar VCs previously on this project where the model was procured from somewhere else with no unit tests available.  I had spent a lot of time and effort debugging those VCs in system-level simulations when augmenting them with basic PCIe features that the design required but missing.  With my redesign, I set forth determined to develop in a TDD flow.  My SVUnit framework for this VC targets bus-level operations in the interfaces and the various TLP models, which are sequence items.  I also do have a separate UVM testbench for agent-level testing.  Compared to previous experience, bring-up was much smoother since a lot of silly bugs were ironed out during my TDD cycles.  I will continue with enhancing the VC looking to use SVUnit to test assertions and coverage in the interfaces, and analysis components to be added to the agent.  If this example does not spur others on my team to give TDD and SVUnit serious consideration, then I don’t know what will.

Our next step is to actually incorporate unit tests into our overall verification strategy that is automated in scheduled regression test sessions.  To achieve this, we have to first unify all of the RTL unit tests to SVUnit and ensure they use the assertion macros consistently to facilitate log scanning and pass/fail identification by the regression manager.

We are basically striving for the Test Pyramid.  The unit tests will serve as the foundation of this strategy.  This also alleviates the system-level verification effort from the burden of closing coverage in areas better suited to a leaner and more focused strategy.  And, with a common platform, we could also throw in unit tests of verification code into the base of the Test Pyramid.

So, the short answer to your question is, yes, SVUnit is as much a legitimate framework for verification as UVM, formal verification, and FPGA prototyping or emulation.

It’s not perfect, and there are lessons learned here, including:

• As with any other DFx (Design for X) strategy, DFUT (Design for Unit Testing) should very much be a part of the process early in the project life cycle.
• Automation can help grease the skids for designers to effectively use SVUnit for RTL unit testing.
• A library of mocks can also help with rapid unit test development and deployment, though for RTL it’s largely design dependent what will be in the library.
• Verification should continue to lead by example with disciplined practice of TDD and unit testing with SVUnit for all SV/UVM based verification collateral, and educate/support the designers in their use of SVUnit.

Manning