Test Driven Development: Introducing the SVUnit Framework

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

Applying Agile To IC Development… Coming To A Webex Near You!

“Applying Agile To IC Development… We’re Not That Different After All” is part of the program for Agile2011, Aug8-12 in Salt Lake City, UT. I do plan to make video available to www.AgileSoC.com visitors… but video never seems to be as good as the real thing!

If you’re part of a group that’s interested in hearing the talk, feel free to get a hold of me at neil.johnson@agilesoc.com!

-neil

If Developing Hardware Was Like Going On A Hiking Trip…

…where do you think you’d end up?

Here’s a goofy story I put together as part of an AgileSoC article that likens some of the daily trials and tribulations of hardware development to a day out in the wilderness. Seems some of the odd things we end up doing never look odd until you see them done somewhere else!


Imagine yourself on a day-long hiking trip with your team. It is early morning and everyone has gathered at the office, each with a backpack with a day’s worth of food and water. A driver in a 15-passenger van pulls up. The team piles into the van and heads out to point A, a secluded little place just south of the middle of nowhere. The goal for the team is to lay claim on behalf of the company to point B then call in for a ride home.

From point A, point B is about 102,000 paces at a bearing of 43.7 degrees. Since no one on the team has ever been there, your executive team–which coincidentally has never been there either–has held information sessions to describe point B. Only half the team has attended these sessions due to conflicting responsibilities.

After arriving at point A, the first thing the team does is split into four small groups. Based on their understanding from the information sessions, each group devises a plan for how it intends to get to point B: one group draws a map, two others write detailed, step-by-step directions and the last team talks about how to get there but does not end up with an exact plan. There is some chatter and discussion between groups, but in the end, each decides independently on how best to get to point B. Plans in hand, everyone agrees to meet at point B at 5:00pm and the groups strike off.

Just as they get started, a company executive speeds out to point A (in his Ferrari) and calls one group back. He needs them to stay behind for an hour to clean out the van so it can be returned to the rental agency. As they clean the van, the executive makes a comment about point B being 5,200 paces north of where was originally suggested though he also admits he cannot be certain. He then jumps back in his Ferrari, offers his best wishes to the groups and speeds off.

And so it follows that each group makes its way toward point B, one starting an hour later than the others and each following its own plan. The groups do not see each all day.

Only one group shows up at point B by 5:00pm. At 6:00pm, a second group shows up. Shortly thereafter and out of breath after having sprinted the final mile, the third group arrives. The last group, however, never arrives.

At 8:30pm, the three groups at point B scramble around nervously until eventually they stumble into the final group–which coincidentally was waiting roughly 2,500 paces away. It is now 10:00pm and darkness has set in. The newly rejoined team resigns to the fact that it will not be able to find its way back to point B, nor lay company claim to point B, so they call the executive team with their new coordinates for a ride home.

The next morning, a different driver in a different van finally shows up to take the team back to the office (changing companies saved 20% on the cost of the rental!). Your team, now ragged, tired and hungry, staggers into the van and heads back. The team arrives at the office to the deflating news that point B was not point B at all (it was actually point C). Your executive team has decided that you and your team will be leaving the next morning to lay claim to what is now certainly and undeniably point B; no question about it.


neil

Q. Have any experiences that you’d add to a day like this?