The Goal Of An Agile Hardware Team

Considering there’s been lots of new visitors to the last few months, I figured now would be a good time to (re)welcome everyone with a reminder of why we’re all here!

Where Does Agile Come From?

Agile is a development philosophy we’re borrowing from the software crowd. We’re using it to transform the way we build hardware. We start with the 4 values of the agile manifesto:

  • Individuals and interactions over processes and tools
  • Working software (hardware) over comprehensive documentation
  • Customer collaboration over contract negotiation and
  • Responding to change over following a plan

Then we strive to embody these values through a combination of attitude, culture, technical practices and frameworks.

Agile is not prescriptive technology; there will be differences between agile teams.

What is Our Goal For Agile Hardware Development?

I’m an idealist. Considering agile hardware is in its infancy, it would be a major opportunity missed if we start with the goal of being anything less than ideal. Shooting for the stars is the only reasonable thing to do. Therefore…

The goal of an agile hardware team is to develop the customer relationships, culture, teamwork, technical skills and supporting structures and practices necessary to enable immediate deployment of an SoC, ASIC, FPGA or IP while working at a sustainable pace.

It’s taken me 5 years to put it into words, but that’s finally it; that’s the goal of an agile hardware team. It’s a lofty goal, but I don’t really see any viable alternative. This is the course we set, then we take baby steps (or giant leaps) toward achieving our goal.

(The exact definition of deployment varies by technology, but in the general sense deployment means development stops, you package what you have, send it to your customer… or to the fab, then to your customer… then carry on with development if necessary.)

Achieving Our Agile Hardware Goal

People will have their opinions about the best way to get started. Some will believe in a top-down approach driven by management. Others will see a bottom-up approach approach lead by developers. Then there’s the various technical practices, frameworks and process tools to consider. Finally, there’s the role of EDA and how it supports a new development philosophy.

I strongly believe that agile hardware will start as a bottom-up movement where developers take the lead and managers assume the role of enabler to support experimentation and growth. This is based on a) comments and discussion I’ve heard in software circles regarding successful and failed agile transitions; and b) the fact that agile was proposed by developers for other developers.

I also believe that technical practices from XP are the right place for developers to get started as opposed to looking first to Scrum, Kanban or other frameworks (though if you have a different opinion, we can still find agreement that starting anywhere is better than not starting at all!). Many of the technical practices required to support Scrum and Kanban are so much different than what we’re used to that it’ll take us some time to catch on. As we get comfortable and gain an understanding of what we’re in for, we can carry on toward Scrum and/or Kanban and/or somewhere else, if necessary.

As for EDA, it will have to assume a support role, responding to the newly discovered needs of developers. Notable for EDA will be the challenge of responding with tools that enable incremental development through the physical design tool chain in a way that shortens feedback loops as much as possible. There will also be opportunities for open-source development in areas where EDA is slow to respond.

One Person Can Make A Difference

Even if you find yourself deep in the bowels of the most rigid development structure ever created, anyone with a little gumption can get started with agile. Refer to XP for technical practices that can be successfully adopted by individuals with little or no impact to existing practices while drawing little or no attention to yourself.

Remember that before there was agile software, there wasn’t agile software… and that some within software still don’t believe it’s possible even now that it’s becoming mainstream. We’ll have the same within agile hardware for a long, long time to come.


8 thoughts on “The Goal Of An Agile Hardware Team

  1. Nice recap.

    However I think some emphasis has to change since hardware is different…

    Regarding documentation: high quality terse specs are essential – they are the source from which tests (especially properties) are written. And with mask costs as they are, this is ultra important for us.

    Individuals vs processes and tools. Well, process and tools are what makes asic possible. I think the emphasis here is for small teams to own their own processes and tools. Of course wheel reinvention is bad, so teams should copy from each other. But tools and processes should not be inflicted from on high!

    Change and customer collaboration (aka firmware usually!). Specs help here – clearly written (and terse) with reviews! Iteration and change are a fact of life, but are massively mitigated by up front specs written from a system usage point of view. Again, these should be written by the small teams doing the ASIC work, reviewed by the small teams of firmware engineers using the chip. God like architects handing down weighty tomes is not good, and rarely cost effective.

    1. thanks jon. agree re: process and tools though teamwork/communication have been marginalized to the point we’ve forgotten about them. we’ve a lot of work to do there. need a renewed emphasis. and documentation… well… I think we’ve a lot of work to do there also. I’ve seen a lot of specs in my day and every one of them has created more problems than it’s solved.


      1. Am surprised regarding specs. However, to be brutal, most specs are poorly written. I like them very terse, almost like psuedo-code properties. Lengthy essays are no use.
        I also favour documenting the lifecyle of a block in terms of the operations invoked on it and by it. Each operation is then documented clearly as a sequence of register writes and reads by software, or a hardware protocol.
        We have for a long time used parts of the Fusion method defined a couple of decades ago. Here’s the only online mention I can find… (not meant to be an advert for this software by the way).

        And yes, teamwork and communication are essential. A good spec process helps.

  2. Having physical design in the loop takes too much time. Fusion may be adequate, but an executable model run in an IDE has the ability to step thru the transfers and the debugger can show the contents of registers. The physical circuits are configured to do the logic of the design. Timing is the primary concern for physical design.

    Logic can be expressed by Boolean algebra, if/else, case/switch in both HDLs and programming languages so logic design can be done and test cases run without ever doing physical design. Verification would need to validate the mapping from code to circuits. Probably post synthesis simulation can be used.

    We used to do the logic design then use a wiring program for build. It worked!

    1. agreed. today, physical takes a long time. but I’d suggest that the tools we use now are built for the paradigm we follow. if the paradigm changed, the tools would change, too, so I’ve love to see development teams challenge eda to better support the idea of iterative/incremental development and deployment to see what they come up with.


  3. I believe that OOP modeling will be sufficient at least until the majority of iterations are done. The IDE and debugger/compiler tie things together and make it easy to observe the function. Probing a chip is difficult and time consuming. It is a mystery why development boards are so popular. There is more to a system than blinking LEDs.

    An OOP model is essentially a spec that can execute examples and observe values.

    Application code talks to the driver that manipulates MMIO registers and the chip interfaces with MMIO and physical device interface. The key is the sequence of transfers and transitions of interface signals. Classes have accessors to model these interfaces so the mapping is direct.

    I have put together a trivial example C# project that transfers from application to IC and from IC back to application. Next is to pass a data array to the IC and return an array of processed data. After that add the processing to create the return data.

  4. The interesting questions we must tried to solve on the way to agile are:
    1. Who is our customer? The people that wrote drivers, the Firmware, the Application or the final customer that buy a product with SW and its HW? For sure the reply strongly depend on your business model but try to ask yourself this question; this alone will change your mind to be more agile.
    2. what is deployment? In SOC you cannot go to Fab each week for iteration, so where shall the agile world end?

    last but not least I still believe in waterfall methodology (as long as your SOC or FPGA is small enough to make it manageable). This is why I really liked the idea not to directly to scrum or kanban.

    1. Hi, Yehuda, I think the customer is the design team that includes application, driver, IC, and peripheral device interface. The design team’s customers are the ones that buy the final HW and SW and are more concerned with what it does than how it does it.

      Also, this effort applies more to designs that are too big for waterfall to be manageable.

      I have the same thought that HW cannot go to FAB each week. Writing and understanding specs is really a poor way to communicate and is slowed down by logistics of editing, printing, and distributing.

      My suggestion is to model using C# classes. One reason is that generic Lists that can be used to show in formatted text what functions are required and the status can be included as well as comments in the code for the application, firmware, and IC model.

      The IC model uses bool types and Boolean algebra to describe the control logic and data types to model the data flow. Breakpoints and single step are used to examine the values or the values can be formatted for a log file or visual display.

Leave a Reply

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