Agile IC Development

If you have been involved in software development you have probably heard of the “waterfall” development methodology. This is the approach whereby a complete specification of the software is developed before a single line of code is written. Nowadays, few people develop software that way since it is too slow. And worse, nobody knows what the specification should be for a product like a video game or even a smartphone operating system. The more modern approach is known as “agile development” in which the basic idea is to get something up and working as soon as possible and then every week or two release a new version with more features. That way there is feedback from users as to what is important and only relatively small amounts of code can be written before a course-correction is made. The waterfall approach risks developing huge amounts of code before finding out that it is a mismatch to what the market needs. The most obvious example of this recently was the Obamacare website which had basically zero contact with users until the day it was released with disastrous consequences.

Agile development fits well with the modern approach to startups which focus on the MVP, minimum viable product. Get something out, start interacting with users, and then pivot as necessary.

But SoC development is still stuck in the waterfall era and is now at a breaking point. SoCs often have over 100 IP blocks from multiple sources, systems have a larger and larger software component, there are increasingly aggressive security and power requirements. But perhaps the biggest issue is that the specification changes all the time, so the idea that you can start from a fixed plan of what is needed and then just implement it is completely wrong. The market requirements are simply not known completely in advance. We need to have an equivalent to agile development in software, namely Agile IC Development.

In Agile IC Development the various stages of SoC design need to be performed more in parallel. Specification, prototype, design, synthesis, physical design, verification etc. Nothing is stable. Whereas waterfall is more vertical and sequential. First specification, then prototype, then design and so on. Ideally we would do everything in parallel but that is not practical: you can’t do physical verification in parallel with synthesis, for example. But the more the line is diagonal rather than top to bottom, the more agile the methodology is.

Today Sonics has launched the Agile IC Methodology along with several partners, or collaborators. I’m not sure what the official word is. The initial phase is to create a LinkedIn group to start the discussion. Sonics is too small to drive it single-handedly but on the other hand they are not so large as to be seen to be trying to set their own agenda and exclude their competitors as would be the case if one of the big 3 was driving it.

The partners in launching this appear in this video to give their perspective (12+ minutes). Along with Sonics, there is Mike Gianfagna of eSilicon, Jim Hogan, Warren Savage of IPextreme, Bernard Murphy of Atrenta, Mac McNamara of AdaptIP, and Neil Johnson of Xteme EDA.

The LinkedIn group is here.