comment on this article

Agile approach to design might help get FPGA based products to market more quickly

"Design doesn't proceed on a block by block basis; rather, Agile is all about feature." - Andy Culmer

Hardware design has, traditionally, been accomplished in a linear fashion – the so called waterfall approach. This starts with requirements capture, followed by the production of a detailed specification and then an architecture.

Andy Culmer, engineering director with design consultancy ITDev, said: “Everything is fixed up front and you tend to work through the architecture block by block, with a lot of integration towards the end of the project. That means system verification doesn’t happen until the latter stages because you can’t fully verify your design until it’s integrated. It’s a somewhat inflexible approach in which it is hard to judge progress.”

But as systems become more complex and time to market pressures increase, there are signs that another approach might be a more appropriate way to develop devices such as FPGAs.

That approach is Agile development – a concept that is more common amongst software developers. Culmer said one of the advantages of Agile development is the use of cross functional teams. “If you have hardware and software people working side by side towards a common goal, it tends to break down the barriers and you don’t end up with problems specific to either ‘camp’.”

He noted that ITDev brings a number of different disciplines to its teams. “It’s not just FPGA design,” he said. “We not only span technologies, but also different parts of a design. A customer might have a GUI team, an FPGA team and so on. Some of these customers have commented that because we don’t have barriers between teams, we can often implement things more efficiently.”

One of the problems with the waterfall approach which Culmer flagged up is to do with time to market. “You save all of the uncertainty for the end of the project,” he said. “While you can predict how long it takes to design a block, you can’t forecast accurately how long it will take to integrate that block, fix bugs and verify the integrated system.” The result, he contended, is greater risk. “You might think you’re halfway through the design, but you don’t really know.”

Agile changes that, he believes. “Agile is much more about constant integration of incremental changes. The design doesn’t proceed on a block by block basis; rather, Agile is all about features.”

Fig 1: The traditional waterfall approach is inherently linear

The focus on features inherent in the Agile approach fosters a shared understanding and a focus on delivering value. “In Agile, features are usually described in the form of ‘user stories’. These not only encapsulate a feature’s requirements, but also the motivation and use cases behind it. The scope is everything needed for that feature, not just design implementation.”

There are three main features of an Agile project, Culmer said. “One is incremental development and the fact that you work feature by feature. Another is continuous integration; every time a change is made, automated checking is performed. It’s not just simulation, but also builds, static code analysis and all sorts of tools. Without this, incremental development would be a lot less efficient. Finally, there are the processes and the ways in which teams are organised.”

There are a number of meeting types, ranging from ‘show and tells’ – updates on what’s been done – to longer ones with a forward looking agenda. “There’s a focus on the ‘stories’ you’ll deliver in the next increment, or ‘sprint’. It’s an ideal opportunity for engineers to discuss aspects such as hardware/software partitioning and design for test. This results in a detailed plan for each story, greater accuracy and buy-in.”

Fig 2: Agile design focuses on the constant integration of incremental changes

Spreading the risk

Culmer noted that Agile allows risk to be spread more evenly. “The project becomes more predictable because you are tracking progress on the basis of how long it takes to implement features, rather than how long it takes to integrate blocks.”

He also believes Agile provides more opportunity to do something about risk. “If things aren’t going to plan, you have the opportunity to deal with the problem because each sprint might only be two or three weeks’ work. Each new sprint has a new plan and the stories you include are always those of greatest value, based on the latest information. By planning and estimating regularly and as a team, the current plan doesn’t suffer from becoming unrealistic.”

Continuous integration is one way of monitoring the use of resources on an FPGA. Culmer said: “If something didn’t synthesise as expected – maybe you ran out of block RAM, for example – you can tie that back to the commit and you can usually find out quickly where the problem was. And continuous integration forces you to keep your testbenches up to date.”

Agile may not always be the clear choice, however. “If you’re designing, say, for aerospace, where requirements are inflexible,” Culmer concluded, “you may not see all of the benefits that Agile brings and a waterfall approach may be reasonable. There’s also nothing wrong with borrowing from multiple methodologies to maximise the benefit for any given application.”

Agile development for complex FPGA based hardware

This potential approach acknowledges that it’s not always possible to go from nothing to a basic integrated system in one iteration, even if you leave out all of the features. The emphasis is to work, as far as possible, at a system level and to prioritise integration over feature implementation. You’ll still need to give due consideration to features when architecting the design, but only to the level of detail required for that purpose.

1. Start with software models of the complete system. This will test the concept and inform the architecture design. Only add features to the model that are needed to inform these decisions. Other features can be modelled on a ‘just in time’ basis.

2. Move to model-based system level simulations. Set up continuous integration (CI) testing and get your simulations automated as soon as possible.

3. Replace models with basic implementations. Leave the features for later, but keep your CI verification coverage high.

4. Build as much as possible as you go along. Add automated builds to your CI. If there are unforeseen problems, you’ll want to know about them as soon as possible.

5. Prioritise development of a synthesisable design. Because you are simulating your whole design as you go along, as soon as you have a fully buildable design you can start testing in the wider system.

6. Test your design in the system as soon as possible. Use the target hardware, when available, or development boards to keep improving higher level test coverage and highlight integration issues.

7. Add hardware based testing to your CI. Automate your tests and run them regularly to detect issues as soon as they appear.

8. Add features incrementally. Ensure verification/test coverage is maintained with every iteration.

9. Release product to market. As soon as the minimum required features are available you can go to market, or at least start customer trials. Gather feedback and use this to set development priorities.

10. Continue incremental development. Add new features and release them to market as upgrades or new product generations.

Graham Pitcher

Related Downloads

Comment on this article

This material is protected by MA Business copyright See Terms and Conditions. One-off usage is permitted but bulk copying is not. For multiple copies contact the sales team.

What you think about this article:

Add your comments


Your comments/feedback may be edited prior to publishing. Not all entries will be published.
Please view our Terms and Conditions before leaving a comment.

Related Articles