Agile was a strong theme at recent Verification Futures conference, 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?” Here, I’ll consider how things have changed in the past two years.

First, “agile” is a catch-all to describe a wide variety of iterative development techniques and processes with “scrum” being the most popular. Scrum breaks iterations into short (such as two or three weeks) feature-driven time-boxed developments (called sprints) that aim to deliver a “working product” (typically software).

As the project progresses, the sprints deliver 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’s 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 and there’s data suggesting the claimed advantage is realized as well as others. In fact, Forrester reports that more than 50 percent of software developers have adopted scrum and this is increasing. One technique that many agile developers adopt is continuous integration.

Continuous integration is the practice of frequent merging of all developer working copies on a shared mainline or trunk. “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” 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 easier 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’s clear that this can’t 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 can demonstrate working features to their users at the end of each sprint. TVS has been a strong advocate of agile development, as written in a paper at IPSoC in 2012 and also in its VIP.

The development approach starts by performing a feature extraction of the protocol and then partitioning the features into separate deliveries to the client who can use the partial VIP deliveries in the verification. The same approach can be applied to RTL development and it’s 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 learned by the adoption of agile is the need to automate the testing. This ensures that there are sufficient regression tests to ensure that subsequent sprints don’t break previously working features. Given that many hardware developments already employ automation (using methodologies such as UVM), this eases the adoption of agile.

In conclusion, hardware developers can begin 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.

Mike Bartley has been involved in software testing and hardware verification for more than 25 years. His diverse background in software and hardware across various sectors has enabled him to grow his company, Test and Verification Solutions (TVS) to over 140 test and verification engineers. Focused on software testing and hardware verification, the company helps its clients provide leadership on both methodology and execution.