Is Agile coming to Hardware Development?

Mike Bartley, TVS

Agile was a strong theme at Verification Futures in Reading in February 2015, with a number of speakers discussing how they have introduced continuous integration. In 2012 at IP-SOC, I asked “Are we too hard for agile?” and in this article we consider how things have moved on in the past two years. We start with a short introduction to agile (which can be skipped if you know it),

“Agile” is a catch-all to describe a wide variety of iterative development techniques and processeswith “scrum” being the most popular. Scrum breaks iterations into short (e.g. 2 or 3 weeks) feature-driven time-boxed developments (called “sprints”) which aim to deliver a “working product” (typically software). As the project progresses the sprints deliver more and more of the solution until the full solution is delivered. The main claimed advantage over sequential development processes (typified by “waterfall” and “V-model”) is that there is a chance for user feedback after each sprint thus increasing the chance of delivering what the user really wants. Agile is now being widely adopted in software development (Forrester report over 50% of software developers have adopted scrum and this is increasing year on year) and there is data suggesting the claimed advantage is realised as well as many others. One technique that many agile practises adopt is continuous integration which we will investigate further.

Continuous integration is the practiceof frequent merging of all developer working copies on a shared mainline or trunk. The definition of “frequent” will vary from “on every check in” to “a daily merge”. The merge needs to be automated and ideally accompanied by automated checks such as compilation, static analysis and regression tests. The main claimed advantage is that integration issues are identified quickly which helps with the need to deliver frequent “working product” (which is discussed below)software frequently. This needs tool support and Jenkins is probably the most widely used. It was mentioned by Alan Fitch of Ericsson at Verification Futures and also used by BluWireless in their SystemC based design and verification flow.

Turning to “working product”, building and demonstrating working software is much simpler than working silicon. Producing a running FPGA from RTL is harder than running software from code but certainly achievable in hours. However, for silicon, we need to change the definition of working product as it is clear that this cannot be silicon. So, we can turn this into RTL running correctly in simulation. This is sufficient for IP development but for a SoC we can extend this to include running software (although this might only be possible later in the project).

Finally, we should consider the other main tenet of agile which is feature driven development. This ensures that software teams are able to demonstrate working features to their users at the end of each sprint (or time-box). TVS has been a strong advocate of agile development written in a paper at IPSoC in 2012 and also in their VIP for many years. The development approach starts by performing a feature extraction of the protocol and then partitioning the features into separate deliveries to the client who are able to use the partial VIP deliveries in the verification. The same approach can be applied to RTL development and it is key that the verification environment follows the same feature driven approach as this is key to demonstrating the “working RTL deliverable”. This approach is best supported by a planning tool such as asureSIGN that can partition the plan according to the sprints and map the features onto the corresponding verification targets (such as coverage, properties proven, tests passing, etc.).

One of the lessons from software adoption of agile is the need to automate the testing. This ensures there are sufficient regression tests to ensure subsequent sprints do not break previous working delivered features. Given that many hardware developments already employ automation (using methodologiessuch as UVM) then this eases adoption of agile.

In conclusion, hardware developers can start to adopt some agile techniques now. The definition of “working product” will need to be adapted and might be different for IP, SoC and FPGA development. However, a feature-driven, time-boxed development should start to deliver improvements fairly quickly.