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/).
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
“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 firstname.lastname@example.org!
…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.
Q. Have any experiences that you’d add to a day like this?