It’s my opinion that are are some very basic techniques that create great value, and should be re-stated and reinforced as good practices from time to time. I also contend that they are strongly related to agile methodologies that we’re promoting here at AgileSoc.
I’ve been learning Clojure over the past few months. But that’s only slightly relevant to this post. As part of my learning process, I’ve been listening to recorded lectures from several Clojure conferences. There was one lecture by by Rich Hickey (creator of the Clojure language) called Hammock Driven Design which I found quite interesting. It’s about 40 minutes long, but I think it’s well worth a viewing.
About a year ago, Mike Thompson said that as much as he liked what Neil and I were doing with the AgileSoC, he just didn’t think the agile methodologies fit all that well with hardware. He then said that he wanted to find the time to write to us with his thoughts. I encouraged him to write a post for the AgileSoC blog promising that we would definitely post it. My reasoning is that while Neil and I are quite pro-agile, we realize that it is not a great solution for every team (just most teams). I very much wanted to hear opposing views pointing out the problems so that we could create an open discussion to either a) accept that those problems are limitations of agile; and/or b) find solutions to address those issues raised.
Thanks very much to Mike for starting this discussion. If you haven’t seen it yet, you should read it here before you read this post! I’ll stop pestering him now for the article. We’d encourage any others to consider posting. If we let Mike have a go, we’ll likely let you too!
A few weeks ago I had the pleasure of having lunch with Alan Dunne from Alcatel-Lucent here in Ottawa. Alan has commented on a couple of our AgileSoC blog posts in the past, and is a shining example of someone who has been using agile techniques with good results in his team’s FPGA development. Over the years Alan has been diligently refining the typical software agile techniques for his FPGA team. It was Alan that introduced me to the “definition of ready” (let’s call it DoR from here on in). A DoR is a corollary to the “Definition of Done” (aka DoD) which Neil blogged about a while ago (review it here http://www.agilesoc.com/2011/07/31/by-example-done-vs-done/).
Future Directions of SVUnit
This post looks at some ideas for future directions for SVUnit. Both Neil and I put forth our views.
All the best to you and yours for 2012.
Neil and I want to wish everyone following AgileSoC a very Happy New Year!
AgileSoC has grown tremendously over the past year, and we’ve received many appreciative and insightful comments about what Neil and I are trying to do.
We look forward to 2012 — where our conversation with you about AgileSoC will continue to grow and develop.
Bryan & Neil
In this (very late) post, I attempt a look at why RTL designers should use Test Driven Development (TDD) to create each of their modules.
For this topic espeically, I’d like to hear your experiences with TDD, whether you think TDD is an appropriate methodology for RTL, and if you’ve been following along with our TDD-month(-and-a-half), whether you agree with Neil’s and my position that TDD is a great addition to our ASIC/FPGA development toolbox.
In my last posting, I gave a brief overivew of the SVUnit framework, and it’s usage model. This post will look at how to use this framework in your workflow: how it can be integrated into your existing verification methodology to help develop new verification components, and extend existing environments.
At this point, I’ll state that the key determinant for a successful introduction is attitude. The developers must see merit in using this approach, or at least trying the approach with an open mind. Otherwise, it will very likely not be successful.
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
Whenever I describe the agile practice of pair programming I usually get the same general reaction,which is something like “I don’t think I’d like to do that”. My usual attempt to convince someone that it could be an interesting tool to try is to suggest that verification team could do it for the complicated sections of code, or to have the designer and verification pair program to develop the drivers. While good reasons, these were never enough. This posting will be another attempt on my part to show the value of pair programming, and to provide some suggestions on where programming could be effective for you, and some reasons on why pair programming may not be effective.