Agile development in the SoC design world? - Embedded.com

Agile development in the SoC design world?

One of the great debates of the last ten years in the software world has been the question of Agile Development. Given the growing role of software in an SoC project, it seems fair to ask if Agile techniques could—or should—be applied to the enormous OS porting, driver development, middleware integration, and application development projects that now envelop most SoC designs. For that matter, should IC design methodologies themselves become agile?

Agile Development, we are told, began early but emerged as a reaction against the growing formalization of software methodology around 2001. Formal methodologies emphasize early validation and freezing of requirements, and then systematic development, documentation, and test of code vs. these requirements. But Agile emphasizes getting to running code quickly, and then entering an iterative spiral, generating code, getting feedback from the customer rather than from frozen requirements, and modifying the code. Adherents say agility seeks out and delivers what the user wants, especially if the requirements are evolving. Detractors say Agile is a cover story for hacking and shoddy documentation. If you would like more detail on Agile methods or on the debate, there are several conference sessions at ESC Boston in September on the subject.

But does Agile work? Adherents say yes, skeptics no. Data paint with more shading. It appears that when experienced developers work in small, cohesive groups with good access to end-users, agility works as advertized. In particular, agile developments seem able to survive rapid shifts in requirements that would cripple a conventional project. But teams that are large, inexperienced, or geographically dispersed have reported difficulties with agile approaches. More worryingly, there is still a very active debate about whether Agile is appropriate when the requirements are not negotiable—say on a spacecraft attitude control system rather than a Web page.

All of this seems intuitive. Is there a possible conclusion? It might be easy to say that the software teams that work in support of SoC designs are large, heterogeneous, and geographically dispersed. Further, they often have little or no access to the end-users of the chip, to whom the project may still be unknown. Or the level of access envisioned by Agile Development might simply bridge too many trade-secret barriers between SoC developer and systems vendor. So the prospects seem dim.

And yet a closer looks suggests other possibilities. Many of the hardware-facing requirements for SoC-support software are rigid, and are defined early by the initial architectural design in the silicon flow. But many of the application- and even mid-level blocks could benefit greatly from more fluidity—as the final power and performance characteristics of the IC become more certain, and as customer engagements begin and early customers become more specific about how they intend to use the device in their systems. So perhaps there is benefit in partitioning the software effort into a requirements-driven side linked closely to the IC architecture, and an Agile side linked to customer engagement. It would be necessary to be extremely careful about volatility at the interface between the two efforts, not the least because they will involve very different kinds of personalities.

What about an Agile SoC design flow? Some design managers might argue that we already have one, given the enormous energy and time that goes into ECOs. We just don’t have the right tools. Others would argue that given the assets at stake, the far more formal approach to verification management in the IC design world, and the sheer size of chip-design projects, Agile is out of the question. But is there a partitioning of the chip-design flow that would allow a combination of requirements-driven and agile development within the same project? Such an approach, for example, could rely on flexible partitioning of tasks between hard-coded logic, programmable state machines, and software to isolate those more volatile requirements that are likely to result in ECOs to areas where they can be easily iterated upon. Would it work? Anyone doing it already?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.