TDD In Hardware Development: Who Does What?

Posted on November 6, 2011 by nosnhojn

Welcome back for TDD month round 2! In our first post, Test Your Own Code!, we laid out some of the motivation for using TDD with some general discussion of the mechanics and benefits. If you read Test Your Own Code!, hopefully you’ve put some thought into where it actually fits into hardware process because that’s the topic we’re tackling today. I don’t think it’s trivial, but we can definitely squeeze TDD in. Here are my thoughts. Continue reading →

Posted in Functional Verification, TDD | Tagged | 3 Comments

Test Your Own Code! (I’ve Got Better Things To Do)

Posted on October 31, 2011 by nosnhojn

November is TDD month on AgileSoC.com. This is the first of a few installments where we look at the potential of Test Driven Development (TDD) in hardware development.

If you’re unfamiliar with TDD, the first and most obvious thing you’ll notice is that TDD breaks a boundary that many hardware teams – ASIC teams in particular – consider absolutely unbreakable.

With TDD, the person that writes the code, tests the code.

[Gasp]

Before you rattle off all the reasons why it doesn’t make sense for people to test their own code, let me give you some background and attempt to explain where we’re going, both in this post and with our wild scheme to introduce TDD to hardware engineers!

Continue reading →

Posted in TDD | Tagged | 3 Comments

Does Constrained Random Verification Really Work?

Posted on October 25, 2011 by nosnhojn

Being that we’re a week away from TDD month on AgileSoC.com, I thought that an appropriate way to get people thinking in a different direction – yes… test-driven development would take us in a different direction – would be to dig up a functional verification article from a couple years ago that I co-wrote. A good part of the article focused on legacy process and it opens by taking a few shots at constrained random verification.

Constrained random verification is pretty mainstream in ASIC and FPGA verification these days, though it does mean different things to different teams. The argument for constrained random verification has always been that it’s a more productive way to cover the state space in increasingly large and complex designs. I used to believe that wholeheartedly. But after seeing and hearing about it fall short – from an efficiency point of view – many times, my current impression of constrained random verification is that it just doesn’t work as well as we all want it to.

Continue reading →

Posted in Functional Verification | 5 Comments

Guest Blog: I Tried It (Operation Basic Sanity) And I Liked It!

Posted on October 24, 2011 by nosnhojn

We’re happy to have another guest contributer to the AgileSoC blog. This one is special because it’s a case study on an exercise I’ve written about before and presented as part of my talk at Agile2011. I’ve called it The Steel Thread Challenge to reach the software crowd and Operation Basic Sanity to reach the hardware crowd. These are 2 different names for achieving on goal: finding ways to help hardware developers think in terms of early functionality and tangible milestones.

Catherine Louis, a long time agile coach and trainer, has tried the exercise on more than one occasion with SoC development teams. I’m happy to report she’s had some success with it and has agreed to take us though what she’s done (Note: I like the way she uses the term “tangible outcome”).

With that, I’ll turn it over to Catherine. Thanks again!

—

I’ve had some great success taking Neil’s Basic Sanity presentation (Agile2011, available here) as a retrospective exercise for hardware teams interested in learning about adaptive hardware development. (a.k.a “Agile”.)

If others have not tried it, it is time you give it a whirl.

Continue reading →

Posted in guest blog | Tagged | Leave a comment

November is TDD Month On AgileSoC.com

Posted on October 4, 2011 by nosnhojn

It’s the biggest thing we’ve done on AgileSoc.com to date. We’ve been planning it for a while. Finally it’s going to happen (in about a month from now)!

November is TDD month on AgileSoC.com

Starting November 1st, we’ll be taking a closer look at how test-driven development fits into hardware development. We’ll have an overview of TDD, give our opinions with respect to how it fits in to the development/verification paradigm most of us follow now and hopefully have a few examples and expert opinions. It’s 1 full month dedicated to TDD!

All this and more rolls out through the month of November so be sure to join the discussion!

-neil

Posted in TDD | Tagged | 1 Comment

Hey Buddy, Can You Spare a Keyboard

Posted on September 25, 2011 by Bryan Morris

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.

Continue reading →

Posted in Agile Development, AgileSoC, Pair Programming | Tagged | 3 Comments

Sir! Hands On Your Head And Step Away From The RTL!

Posted on September 12, 2011 by nosnhojn

A handy bit of guidance that I’ve gleaned from books on lean product development comes via the recognition that unfinished work sitting in someone’s in queue, which in lean manufacturing lingo is called inventory, is waste in your development process. Lean software practitioners take things a step further to describe untested and/or unreleased code sitting on a file server as inventory. I reckon doing the same can benefit us in hardware development.

It makes sense to me that built up inventory can be responsible for poor productivity or quality. Why? Think about it… do you do a better job when the amount of work in your queue is manageable or overwhelming? Do you work better when someone shows up at your cube with 10 feature requests or 1? Do you work better under the weight of 25 outstanding bug reports or no bug reports?

I’ll take manageable over overwhelming any day so I can see minimizing the amount of untested and/or unreleased code… I mean inventory… in your development process over time is a good thing. Minimize inventory and you’re minimizing waste. Minimize waste and you’re maximizing productivity and quality.

How about an example that applies to hardware development.

Continue reading →

Posted in Agile Development | Tagged , , , | 6 Comments

Dear Agile Hardware Skeptic

Posted on August 31, 2011 by nosnhojn

This post is a little different than what I’ve been doing here so far because it’s directed at only 1 person. This person is new to agile. We have talked about it a few different times and last time we talked she mentioned:

“most of what you have on AgileSoC.com seems to assume you already know about agile… I wish you had some stuff for beginners.”

Point taken. Here’s a post just for you… and any other beginners that want to stick around.

Continue reading →

Posted in Agile Development | Tagged | Leave a comment

8 Ways To Avoid Ignorance Based Exploratory Testing

Posted on August 28, 2011 by nosnhojn

Exploratory testing is a term I heard several times at Agile2011 in Salt Lake City a couple weeks ago. As I heard people talking about it, exploratory testing seemed to be something that verification engineers should be familiar with. Admittedly, it was new to me so for anyone else new to exploratory testing, here’s a description from good old wikipedia:

Exploratory testing seeks to find out how the software actually works, and to ask questions about how it will handle difficult and easy cases. The quality of the testing is dependent on the tester’s skill of inventing test cases and finding defects. The more the tester knows about the product and different test methods, the better the testing will be.

From that definition and other things I’ve read since Agile2011, it seems that exploratory testing is more easily pondered relative to it’s antithesis: scripted testing. In scripting testing all the thought is put in upfront; a tester would do all their research first, build the test plan and then they or someone else would execute the test plan. With exploratory testing, the tester assumes its impossible to deduce everything up front and that the goals of the testing will change over time. He/she starts with a more basic plan and then thinks their way through the test process, learning and shaping the test plan as they go along.

Continue reading →

Posted in Functional Verification | 2 Comments

Guest Blog: What’s All This Hardware Scrum Sprint Demo Stuff, Anyhow?

Posted on August 21, 2011 by nosnhojn

By: Rolf V. Ostergaard

If you read about Scrum from the software world, you learn how important it is to make the sprint demo as close as possible to the real product in a realistic user scenario. Some obsess over it to a point, where this becomes a problem for adapting Scrum to hardware development. I want to change that – a demo need NOT be the working product, in order to be valuable and useful.

In device development, where products often combine custom hardware, test systems, embedded software, FPGA/ASIC code etc. etc., making a demo after the first 3 week sprint that looks anything like the real product seems dead impossible. I agree, but that does not mean you shouldn’t try or can’t benefit from Scrum.

You can easily get many – if not all – of the benefits of Scrum simply by adopting a broader definition of what a good sprint demo is. I know this is very difficult envision at first, but take a look at what we considered good demos along the way in some example projects.

Continue reading →

Posted in guest blog | Tagged | Leave a comment