An Idealist’s View of Agile Hardware Development

Something I’ve been meaning to do for a while now is talk about the waterfall v. agile comparison that I’ve been doing in agile hardware talks for a few years now. Finally got around to recording and posting the video.

Here it is… waterfall v. agile development and why we need to start with the idealist’s view of agile hardware development instead of settling for something practical.

Share this:

About nosnhojn

I've been working in ASIC and FPGA development for more than 13 years at various IP and product development companies and now as a consultant with XtremeEDA Corp. In 2008 I took an interest in agile software development. I've found a massive amount of material out there related to agile development, all of it is interesting and most of it is applicable to hardware development in one form or another. So I'm here to find what agile concepts will work for hardware development and to help other developers use them successfully.
I've been fortunate to have the chance to speak about agile hardware development at various conferences like Agile2011, Agile2012, Intel Lean/Agile Conference 2013 and SNUG. I also do lunch-n-learn talks for small groups and enjoy talking to anyone with an agile hardware story to tell!
You can find me at neil.johnson@agilesoc.com.

6 Responses to An Idealist’s View of Agile Hardware Development

Hi Neil. I enjoy reading your perspective on hardware design. I agree with you 100% that we are way too apt to stick with what we’ve always done instead of thinking outside the box and being more agile. I do have a few thoughts on agile and HW design.

– One of the key components of agile methodologies, is the ability to work with your customer and demo on a regular basis. In hardware design, we often don’t know who our customer is. In many cases in my experience, it’s the CTO or marketing department. This isn’t quite the same as working with an end-customer.

– Given we can identify our customer, what exactly do we demo? We can’t actually produce an ASIC so are we demoing a simulation.

– Physical design is the real differentiator here. On a modern design, I’ve generally done the PD in a semi-agile fashion. We don’t wait until verification is done to start the first PD. Instead, we are taking drops from the design team, doing PD work and constantly providing feedback based on timing and routing issues. So in this way, I think any successful, modern chip is doing PD in a somewhat agile way. The flaw in the process is the idea of being prepared to release a chip for fab on any particular week. In order to do this, you’d need a PD team that was large and a huge number of EDA licenses (generally both out of the question).

While I’ve outlined the areas where it is difficult to be agile, I think in the design and verification world, we have tons to gain by being more agile. The idea of working in a way that allows for frequent integrations and constant incremental verification is a huge win. I fear that we are moving further and further away from this model as we get more entrenched in UVM and constrained random. With this methodology, we end up with a large up front cost getting a testbench built, and we end up doing our verification at a level that discourages a detailed understanding of what we are verifying. A more agile methodology would do wonders here at finding problems early and not requiring every simulation to need a complete chip and complex testbench to be built up front.

Sorry to be so long-winded but I wanted to throw out my two cents on agile SOC. I’m looking forward to future posts.

bill, great comments. you make some good, valid points. I’ll try and add my opinion though admittedly, I don’t know how much I can add…

For customer relationships, not sure how realistic it is, but it would nice to be part of a team/customer relationship where people are will to show vulnerability and use it constructively. I’ve been able to do that myself with clients but seeing the same transparency and vulnerabilities between organizations is several levels beyond. Basically, it’d be nice to see “I don’t know” become a discussion point rather than a moment of weakness.

Which leads me to PD… my answer to pretty much every question I’ve ever been asked about how PD fits with agile development is “I don’t know”. I really don’t. I’ve tried to lure pd guys into the conversation but haven’t had much luck. My personal opinion is that a proper starting point would be some of the communication related XP practices. Maybe we create situations where solutions arise that do bring us to the point where we can tape-out on short notice, maybe not. The value there, though, is immense regardless of what people think is possible from a user point of view and also a tool provider. Huge opportunities to both embrace and resist depending on who you are!

For demos, I think you’re right. Simulation is one option. I think better would be emulation where you can demo integrated hw/sw, seeing something happening in real(ish) time. Honestly, I think any kind of functional demo is better than the ‘code complete’ milestones we have now. The code complete milestones are next to useless, sometimes worse.

As for your fears of uvm/constrained random… I think those are well founded. My opinion is that we’re moving in the wrong direction. What makes it difficult is that companies are so heavily invested in optimizing what they do poorly, they don’t make time to see that what they’re optimizing is even working for them! That’s unfortunate. Coming back to people being able to show vulnerability… that’s something that the agile sw people I’ve met are very good at… by wondering aloud whether or not they’re going in the right direction. h/w folks not so much. Hard for us to have public conversations about whether or not we’re wrong.

Thanks again for the comments. glad to have you following. Any more talk on the PD side would be appreciated from you or colleagues… or anyone else following along!

Hi Nril,
Thanks for the response. I’ll give you a bit of my background. At my core, I’m an automation guy. I love making things work and avoiding manual, error prone steps. So for most of my career, I’ve been putting together automated processes around chip design. Much of this work has been in the back end. I also spent a few years doing hands on verification work and am now supporting and automating the verification process.

So I love software and strongly believe that the agile approach has huge paybacks. I also think that modern software folks tend to be more nimble and open to change than most hardware people I’ve come across. I’m always fighting to try to get people to think outside the box and not stick with the old methods without good reason. So I enjoy your blog as I think we have a lot in common.

I’ll throw in a few cents on the backed. In the old days when most of us did gate arrays and standard cells, we were truly trapped in a waterfall world. We finished up RTL and synthesis and then threw the design over the wall to a vendor where they took over and eventually fed us back timing information (which we hoped didn’t cause us to rearchitect things). A lot of companies still do things this way. If you don’t have an in-house PD group you are stuck in that mode.

For projects that do have in house PD groups, we have much more opportunity to be agile and I think most projects do work in a semi-agile wy without using those words. A design (or block) will go into the PD realm a number of times before it is complete. It’s normal for an incomplete and partially verified design to go into PD. this is how valuable feedback is obtained to help optimize the design. This overlap is key to getting to market (and this looks a like like the stair step diagram in your video).

The big difference between this and a true agile process is that these handoffs are almost never on a complete design that could be taped out and shipped as they are being handed off in a known bad state. In order to get to the real agile nirvana, the whole design and verification paradigm needs to shift to creating “shippable” releases on a regular basis.

In the big picture, this is unrealistic. Given the cost to tape out a large ASIC these days, we know that these incomplete designs are never going to be shipped. We are going to wait until most or all of the features are in before we ship. We don’t get multiple tapeouts to add incremental features like we can in software.

Now this may sound like I’m arguing against agile HW design but I’m really not. I’d contend that even if we were to just pretend that we could ship a design, it would force us to tie off a lot of loose ends earlier and plan the order we add features much more carefully. In fact, if we were to just change our view to add features in order from most important to least important, we would likely end up with a shippable design much sooner.

I think I may be arguing both sides of the issue here but I truly a believe that if we were to take a more wholistic view of chip development and align development, verification and PD to operate in a more incremental fashion, we might just ship the final product sooner even if we don’t end up in that agile nirvana of being aout to tape out on any particular Friday afternoon.

I really appreciate your openness. One of the big reason that software design has become more nimble is be sues of the embrace of openness and sharing between companies. In general hardware folks are so concerned with being proprietary and keeping secrets that we miss out on the positives of interacting with other smart, motivated people outside of our own companies.

Bill, If we had a best comment award on agilesoc.com, you’d have won it with this…

Now this may sound like I’m arguing against agile HW design but I’m really not. I’d contend that even if we were to just pretend that we could ship a design, it would force us to tie off a lot of loose ends earlier and plan the order we add features much more carefully. In fact, if we were to just change our view to add features in order from most important to least important, we would likely end up with a shippable design much sooner.

I don’t see this as arguing against agile, I see it as you acknowledging the limitations *and* value of agile, then offering a smart opinion for how we put them together! This has been my feeling as well, incidentally. Who cares if we actually ship something to a customer, having it as a possibility (like you say) would help us prioritize and tie off loose ends as we go until waiting until the end. Makes complete sense to me 😉

Another excellent point you make…

I think most projects do work in a semi-agile way without using those words

This will always be true for any team, some more than others obviously, but it’ll always be true. Now I’ve heard several people make that point and it always feels to me that that comment is used to avoid taking agile more seriously (not suggesting you’re in that boat b/c it seems you’ve put some thought into this, but from others… yes). Now the step I’m hoping that teams make is, instead of assuming they’re agile’ish and figuring that’s enough, pick specific XP practices and try them. 1 at a time, 2 at a time, whatever. Make an informed attempt at moving in an agile direction and see what happens.

BTW… entirely possible some of your comments turn into a new post later this week or next. If you’ve got any other points to make, keep going. Gives me more to write about 🙂