Opinions, guest opinions, video… where does AgileSoC.com go next? Book reviews, that’s where! The first book I’ll take a look at is Test-Driven Development for Embedded C written by James Grenning. Continue reading
It was recently brought to my attention that I haven’t done a very good job of telling people about the examples that come with SVUnit. That’s unfortunate. The examples are there to help so if people don’t know they’re there or what they do, I think I’m safe in saying they’re not helping anyone!
Let’s change that. Continue reading
SVUnit isn’t just for early adopters anymore!
Anyone can download and start using SVUnit to do TDD of complex ASIC and FPGA designs. For more info on getting and using SVUnit, go to the SVUnit home page.
Bye-bye SVUnit development… hello SVUnit support ;).
When we were writing about TDD back in November 2011 during our TDD month, admittedly I had very little experience with it. The goal with TDD month was to spread the word and drum up a little interest in a technique the the software folks have been using successfully for years. I’d used it on a small scale but lacked the experience to back up a lot of what I was writing.
Over the last few months though, that’s changed. I’ve spent a good amount of time collecting feedback from and supporting SVUnit early adopters. That’s been good for getting a feel for how others in hardware development see TDD. Just as important, I’ve been using TDD myself to build testbenches and it’s been going well… very, very well. I’m at the point where I’m going through a pretty repeatable cycle that I think could be useful for others contemplating TDD. I’ve talked about this cycle before, but it’s worth revisiting now that I’ve been through it. Continue reading
Here’s another post inspired by James Grenning and his “TDD with C” tutorial. Going through an abbreviated version of that tutorial last year in Salt Lake City at Agile2011 was what got me started with TDD. It inspired TDD month on www.AgileSoC.com last November. It encouraged me to get knee deep into SVUnit and TDD of verification IP. It also, in part, motivated my Agile2012 submission: TDD and A New Paradigm For Hardware Verification.
My second time through it was at ESC in San Jose this past March. This time around, I found myself fascinated by some skepticism in the audience when a fellow piped up with the comment “I see the value of unit testing but it’s hard for me to see the extra value of TDD”.
It was easy to see it wasn’t the first time James had seen this kind of skepticism during one of his talks. His response was “My goal is to show the value of TDD… but if all I can do is convince you there’s value in unit testing and that’s as far as you get, that’s great, too. That’s a start.” Continue reading
I can honestly say that as of a couple weeks ago, I’ve gone further with SVUnit than I thought was realistic when I first starting looking at it. Having done more TDD, written more tests and recently finished step 2 of my UVM Express example, I’ve come to the conclusion there’s value in unit testing anything! That includes coverage groups and UVM agents… which I talk about here.
I’ve been putting a lot of time into developing new examples for SVUnit lately and as of wednesday last week, I’ve finished another to show how people can use SVUnit to do test-driven development of verification IP.
This particular example involves development of an APB master BFM. APB isn’t the most complicated of bus protocols but it’s a very good subject for an example like this because the code and tests are easy to understand (there’s an APB example in the latest UVM release also, presumably for the same reason).
UPDATE: for people looking at UVM Express that was announced by Mentor Graphics on Feb 22, this is my interpretation of how TDD can be applied at the lowest layer development of the BFM. Examples showing the addition of functional coverage and completion of an agent that includes sequence generation are still to come. You can see UVM Express on the Mentor website by going here.
Future Directions of SVUnit
This post looks at some ideas for future directions for SVUnit. Both Neil and I put forth our views.
Up until now, we’d been discussing the justification of using TDD in an ASIC development flow. Hopefully, we’ve convinced you to try it. In this post we’ll introduce a TDD framework that has been developed for SystemVerilog to help you use this design technique.
A couple of weeks ago, just after we got started with TDD month, Neil added the link to the posts on several industry forums, and got this comment from Alex Gnusin on the verification guild:
“Is it a Designer responsibility to test each line of code? In this case, there is a need to provide designers with working methodology to verify their code…”
To which Neil responded:
Alex: I’m not sure if you guessed we’d be covering the topic of a working methodology – aka: unit test framework – but if you did, I’d like to thank you for that nice bit of foreshadowing!
Alex is right, a proper framework is pretty important for anyone doing TDD; primarily because it gives you the opportunity to get up and running quickly.
In the software world, there are are number of wildly popular unit test frameworks. JUnit might be the best known (for those doing java development) but there are about a million others (as you can see with a quick trip over to Wikipedia). A unit test framework is critical for TDD, that’s why myself and Rob Saxe (both formerly of XtremeEDA) put one together a couple of years ago for people wanting to do TDD with SystemVerilog.
First presented at SNUG San Jose in 2009, SVUnit is a unit test framework that provides:
- structures for creating and running unit tests
- utilities for reporting test status and results
- a test “runner” that executes a set of test suites and report on their overall success/failure
- scripts to automate the mechanical aspects of creating new unit test code
We’ve looked at why teams should consider doing TDD; we’ve looked at how the roles and responsibilities change between design and verification experts; now let’s look at when everything happens. This is the key to seeing how everything fits together.
Most teams nowadays chose to split their verification effort up as a combination of block level and top level testing. Block level testing is usually applied to every subsystem in a design and intended to exhaustively cover all the features of each subsystem. Once the block level testing is done, the exhaustively tested pieces are integrated and tested in a top level testbench.