Agile Hardware is More Than Verification

Choosing a domain name for a blog can be tricky, no? You want to pick something that describes what you’re doing, but also something catchy that people will relate to and remember. In the days before AgileSoC.com, I remember choosing between 2 domain names. It was a short discussion via email between Bryan and I and the decision came down to agileverification.com or something more inclusive…

Screen Shot 2015-11-06 at 2.57.16 PM Screen Shot 2015-11-06 at 2.57.27 PM

Screen Shot 2015-11-06 at 2.57.37 PM

It’s fun for me to read through this email almost 7 years later, to see that all we were after initially was a wiki for jotting down ideas!

As well, in terms of scope I’m proud to see we had it right from the beginning. Agile isn’t something that can be pinned to a single hardware discipline. Even though Bryan and I are verification specialists, we knew it wasn’t just for verification. Agile applies to products and the entire teams that build them. Experience from people in design, physical design and embedded software is starting to prove that.

So if you’re a verification engineer that thinks agile is meant specifically for you, don’t trap yourself into thinking the software’y’ness of verification means it’s the only area where agile hardware works. While you may think agile hardware starts in verification, lot’s of developers are demonstrating it doesn’t have to end there.

-neil

2 thoughts on “Agile Hardware is More Than Verification

  1. I can only holeheartedly agree to this, although I am a verification engineer, too. I think there is a huge potential by only looking at Continous Integration. This can include a fully automated workflow to check synthesis results, create timing results, run power analysis, run design rule checker, create releases and of course kickoff simulation runs. See what got better what got worse.
    For example the designer gets immediate feedback, which paths got worse in timing, what is the change in power consumption. I think Continous Integration is an integral part of Agile Hardware, which will also bring Design and Verification closer together to maybe in the future not only cover the front-end path of the Hardware Development process.

    But specifically building Xfunctional teams of design and verification will drive a lot of synergy since they (should) already share a lot of time consuming tasks such as running structural design rule checks, design exploration, writing assertions, coverage events, deterministic tests and last but not least debugging. So even furthermore, if Xfunctional agile teams are built and sit side by side coding assertions and debugging fails, will this be then called “Extreme Hardware Programming”? Or even share writing specs? And then one part develops the testbench and the other the RTL?

    And then … from Continous Integration to Continous Delivery. 🙂

    1. bodo, I like this comment b/c you’re referring to 2 specific practices from agile development (continuous integration and xfunctional teams). I think it’s easy to generalize “agile” and say it can’t be used across the team. dig deeper though with arguments like yours and it becomes very obvious it can.

      -neil

Leave a Reply

Your email address will not be published. Required fields are marked *