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

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.”

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.”

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.”