The 90% Done Myth

Since posting The Great Agile Hardware Myth last week, I tried to think of some obvious myth that exists in the mainstream; some claim that we’ve all made that, without fail, turns out to be absolutely and entirely false. Took a while but I think I found it. We could have called it The RTL Done Myth, but I chose to call it the The 90% Done Myth.

Myth Reality
We’re 90% done. If everything goes well, all that’s left is testing and debugging this last 10%. The gant chart that says we’re 90% done is lying to us. We know it’s lying to us because it’s lied to us before, many times. We’d rather not use this gant chart but because tracking development progress is so important and we haven’t figured out a better way to do so, we feel like we have no other option than to keep trying to believe it.

Continue reading

The Great Agile Hardware Myth

What’s completely clear is that agile was created by software developers for other software developers that write software. Agile was not created for hardware developers that build hardware so there can be no such thing as agile hardware, right?

Nope. Wrong. I’ve heard a few comments to that effect over the years from people that are just mildly familiar with agile. I’ve heard similar comments from others honestly trying to wrap their heads around it while tripping over preconceived notions and losing themselves in hearsay. Truth is, what it means to be agile is not cut-and-dried, even within software nevermind hardware. I figured it’s finally time to take a step back to clear a few things up so that people new to the discussion can form a healthy definition for “agile hardware”. Continue reading

Agile2014 Demo – 1 Step Back… 1 Step Forward

With the arrival of our board last week, I figured now would be a good time for a quick update on how our Agile2014 software/hardware co-development demo is coming along…

2014-06-02 10.41.33Our starting point was a reference design that is similar to what we’re trying to do in that it sends video frames to an HDMI port. We’ve relied pretty heavily on that reference design to build our hardware abstraction layer that connects our application to the device drivers. We threw away the application from the reference design – which is basically just a loop that sends coloured bars to the HDMI.

So far, Soheil and I have focused all our time on the software side. We’ve written our software application code and we’re almost finished the hardware abstraction layer. When the software is DONE, our Conway’s Game-of-Life application will send a grid of characters to the hardware abstraction layer; the hardware abstraction layer will convert the grid into pixels; and the pixels will be sent as frames to the hardware.

Because the reference design includes everything on the hardware side necessary to fetch frames and push them out to pins on an HDMI connector, we’ve been able to ignore the hardware for now. Our board was on back-order through april and may led us to do a lot of mocking. That let us model the interaction with the hardware without the hardware.

All our software code is C++ and we unit tested it using GoogleTest and GoogleMock. As I said, some of our code comes directly from the reference design (i.e. we imported and unit tested existing features) while other parts are newly written for the demo (i.e. TDD of new features).

That takes us to about 2am last Wednesday… which is when I got home for the university. It was cold and rainy.

photo1With the postman delivering our Zedboard, we’ve changed focus to take a few unknowns off the table, the primary unknown being the quality and reliability of the reference design as a starting point. So from late last week to last night,  Soheil has been installing tools on an old laptop I borrowed from work so we can build and run the reference design; it’s not the goal but we’re calling it a proof of concept that helps us learn about the board and validates our starting point.

The good news, as of about an hour ago, is that Soheil has the reference design building and running. That’s the picture with the board and the multi-coloured bars on the monitor. It doesn’t look like much, but we’re pumped to get over this hurdle!

Now we’re off to polish and deploy the real demo!


SVUnit Scripting Proposal Version 2

I’ve had people asking about the SVUnit new scripting proposal I posted a few months back. I forgot about it for a while but now I’m back. I’ve taken some of the feedback I’ve received and folded it into a new version. Slightly different in that I’ve added switches for compile and runtime options.

Here’s the help. Take a look and let me know what you think…

Screen Shot 2014-06-05 at 8.54.54 PM



This is ready to go. I have a couple people trying it out. If you’d be willing to test-drive the new scripts before an official release, I’d sure appreciate it. Just let me know at and I’ll ship you a copy. If all goes well, I’d expect to release this within a month or so as version 3.0.

Thanks in advance for you comments!


Win A Limited Edition T-Shirt

This is it… and it’s real. It’s the prize your friends and colleagues can only dream of. Your team… your entire company… even your family will wish they had one.

It’s a limited edition t-shirt!

photo 2 photo 1

Here’s how you win: respond with a short comment on why you think agile development works for hardware. Maybe it’s Scrum… or TDD… maybe incremental development… pair programming… retrospectives… whatever… just scroll down to the comments and tell us why it works. To be fair, even if you don’t believe agile has any application whatsoever in hardware, tell us why. A comment either way gets you into the draw.

At precisely 10:13am, Tuesday July 1, my 3 year old daughter will draw a winning name from the list of comments… and that person’s dream comes true.

To repeat, a comment telling people why agile does or doesn’t work for hardware gets you into a draw for a limited edition t-shirt. This shirt will change your life. It’s changed mine. I haven’t taken my shirt off since the day I got it.

…and when I say a limited edition, I mean limited edition. Only 2 people on the planet have one. One lucky comment could turn you into #3.


Why Am I Learning About Agile Hardware?

Here’s a guest post from Soheil Salehian, the fellow at University of Calgary who is helping me out with the Agile2014 co-development demo. It’s been fun working with Soheil thus far so I asked him to jot down a few thoughts on why he’s interested in agile hardware and what he’s hoping to get out of our demo development. Here’s what he had to say…

1980193_4116373203862_5265614512891722028_oI have always been a firm believer that once you start learning a concept at some level, it is often incredibly rewarding (or at least humorous!) to step back and ask yourself: ”why am I learning this? Does learning this concept get me any further in anything?” The interesting thing is not the actual answer but the rewarding process of asking those type of questions. For anyone familiar with Agile concepts, such questions may resemble asking for feedback which is the most valuable part of using the Agile methodologies and processes in the first place. Continue reading

New Agile Engineering Program Launched on

This is a special announcement to let people know that Agile Alliance has launched a new Agile Engineering Program. The purpose of the program is to help consolidate and grow the community of people that are applying agile practices in engineering by providing a platform for sharing short experience reports on why and how they’ve applied agile. In short, it’s a way for us to help each other out.

The Agile Engineering Program is being lead by Nancy van Schooenderwoert with me side-kick. Nancy and I are happy to have Agile Alliance explore the potential for agile development beyond software development… very happy :).

You can find more information about the program on

Thank you Agile Alliance!


Agile2014 Demo – Mocking Device Drivers with GoogleMock

This week, our Agile2014 SW/HW co-development demo took a step closer to the hardware. But considering the real hardware isn’t going to be here for another month or so, we had to get creative to test the code that interacts with the device drivers.

Mocking is a technique I’m starting to get comfortable with to isolate and test specific functions. I’m also getting more comfortable with GoogleMock. It’s only taken 3 weeks, not that I’m an expert or anything, but the basics are pretty straightforward. However, while the basics apply very well to C++ code, they don’t apply as well to C code. Here’s a “warning” on the GoogleMock FAQ to explain… Continue reading

Our To-do list

From time to time I have people asking me how they can help out with the various activities and developments we talk about on It’s not everyday, but it’s often enough that I thought it would be useful to publish a consolidated list of what’s currently on the go to see if anyone is hip to pitching in. When I say anyone, I really mean anyone. There are no agile hardware experts that I know of which means we’re all equally qualified. You could be working now in ASIC/FPGA development, taking a break, studying at university or whatever. If you got the interest with a few hours to spare, you can help.

Projects Currently Under Development


Download the Latest Version of SVUnit from GitHubSVUnit is our most popular SystemVerilog unit test framework. The framework itself is reasonably solid but there’s always opportunities to publish add-ons or examples. If you have an example of how you’ve used SVUnit to solve a problem that you can share with the community, is probably the best place to do that. If you’ve got add-ons to the framework that you think belong in the release package, please contact me, tell me what you have and we can discuss how to get it in there.


Get the latest version of MiniTB from Github

[CSSBUTTON target=”” color=”003366″ textcolor=”ffffff” float=”left” newwindow=”true”]Download MiniTB[/CSSBUTTON]

Our second most popular SystemVerilog unit test framework (aka: the other framework) is MiniTB. Similar to SVUnit, it’s reasonably solid on it’s own but more so than SVUnit, it could use some examples. Since it’s geared more toward RTL testing, we could really use some examples of how different RTL modules are being smoke-tested. Likewise, we could use some interface IP (I already have some AMBA BFMs packaged with MiniTB but they could use some company). If you’ve got anything or are motivated to put something together, let me know and we’ll see if we can get something into the release package.


I tend to forget about UVM-UTest as an option for further development even though it’s probably the project with the most direct link to what’s going on in the EDA industry. UVM-UTest is our project where we unit test components of the UVM library. Seeing as how UVM is so huge and UVM-UTest covers only a small subset so far, there’s a never ending opportunity here to grow the unit test suite, continuing to verify what is a very important and relevant industry framework. Check out the getting started page to see what we’ve done so far. If you want to dive in, I can show you the ropes and help you get started verify a new piece of the UVM.

Agile2014 HW/SW Co-dev Platform

Our Agile2014 Co-dev platform is being actively developed as we speak. I’m quite excited about this project because unlike almost my entire career, it involves hardware that you can actually see and touch and use. For our Agile2014 Co-dev platform, I think a neat opportunity exists for one or more people to build a module that does some basic graphics processing. Ideally, we’d like something that shows how we can use logic on the FPGA to transform software generated video frames. Complexity doesn’t really matter. We’re just trying to impress a bunch of software developers so pretty much anything will do :). This will probably entail inserting a block into a pipeline that uses AMBA AXI4-Stream protocol for the I/O with some basic stuff in between. If it sounds good to you, let me know.

Other Possibilities

Experience Reports

If you want to help the Agile Hardware community, likely the best way is to set a good example, then publish it (the most common Agile Hardware email I get is: “do you have any examples of agile being applied to _fill_in_the_blank_?”). I’ve posted guest posts on before and would be happy to do so again… even from people that criticize the very idea of agile in hardware development. I don’t discriminate 🙂 . Lessons learned, new techniques, anything that others can learn from is good with me.

SVUnit/MiniTB Compatible Mocking Libraries

This would be an interesting way for people to strike off on their own. Mocking is a useful technique for unit testing and TDD. I’ve recently seen first hand how useful a mocking utility/framework can be. Seeing Cadence add a mocking utility to Specman should be enough to convince people it’s not an entirely crazy idea. If you’re new to mocking, you can check out CMock or GoogleMock for two examples from C/C++. If the idea tickles your fancy, you could think about building a SystemVerilog version. That’d be a super idea.

SVUnit Support for OVM

This has come up a few times… there are teams still using OVM and are looking for a framework that supports development and test of OVM components. I’ve talked to people that have tried using SVUnit with OVM so it is possible. It’d just be a matter of packaging an add-on similar to what I’ve done with UVM to make it easy for people to use. Add VMM to the list for that matter. Support for either would be a decent idea.

That’s most of what I can think of. You can get me at if any of it is worth talking about. If you have any other ideas, maybe you’re looking for feedback or someone to help you out, feel free to get a hold of me.


Honey… I’m Being Eaten By A Bear: 10 Need to Know Tips

Last week I stumbled across a verification post that used my favorite verification graphic from the Wilson Research Group Functional Verification Survey that Mentor sponsors every few years. Here it is again for anyone that hasn’t seen it posted here before (I’m sure this makes about a half-dozen times for me. It is, after all, my favorite verification graphic)… Continue reading