About a year ago, Mike Thompson said that as much as he liked what Neil and I were doing with the AgileSoC, he just didn’t think the agile methodologies fit all that well with hardware. He then said that he wanted to find the time to write to us with his thoughts. I encouraged him to write a post for the AgileSoC blog promising that we would definitely post it. My reasoning is that while Neil and I are quite pro-agile, we realize that it is not a great solution for every team (just most teams). I very much wanted to hear opposing views pointing out the problems so that we could create an open discussion to either a) accept that those problems are limitations of agile; and/or b) find solutions to address those issues raised.
Thanks very much to Mike for starting this discussion. If you haven’t seen it yet, you should read it here before you read this post! I’ll stop pestering him now for the article. We’d encourage any others to consider posting. If we let Mike have a go, we’ll likely let you too!
Michael brings out some excellent points in his article (but I expected nothing less from him). My summary of his key points are:
- physical design (PD) issues have such long time frames and real hard constraints that attempting to apply a pure ‘software’ agile approach could be difficult at best (or even disastrous for the schedule); and
- Test Driven Design (TDD) could be more problematic because of the reality of PD.
- no one in RTL uses a pure waterfall method anymore, but they also can’t use an iterative approach due the PD issues.
Physical Design
I found it interesting that while Mike said that agile techniques cannot be applied to physical design because it takes a long time (OK, he actually said a “loooong time”), but then stated that to “get it right, several iterations may be required”. He then goes onto say that “SoC Development time is driven primarily by Physical Design, not Functional Verification.”
What if found interesting is that if PD is the long pole in a schedule then physical design would stand to gain the most by using an agile methodology. Incremental development is already an aspect of a Scrum methodology. While Scrum proponents suggest short iteration cycles of a few weeks (related to a single Scrum “Sprint”), there’s no reason that the iteration could not be several weeks/months to accommodate PD’s longer time frames. But using the Scrum framework, a Sprint Planning session could be added to establish the PD goals and objective measures to hit, doing daily stand-ups to ensure continued progress and remove any blocking issues as quickly as possible, and a Sprint Retrospective to provide an opportunity to look athow we completed the Sprint and find opportunities to improve. It would seem to me that adding this structure to the PD work would seem beneficial.
Secondly, if PD is truly driving the schedule, then we should be ensuring that we focus on the most important PD problems first. Adopting an iterative process provides intermediate milestones with associated concrete objective measures to show the PD team has addressed those issues in an organized way. This would build confidence as the program progresses that are meeting schedule.
Test Driven Development
Mike then proceeded to throw a few strikes against Test Driven Development (TDD). While what he states is (mostly) true, one counter point to the argument is a practice that I’ve seen several times: where designers create simple stimulus and environments to unit test their modules. Many times these simple environments are created partly as a reaction – since “those darn verification engineers can’t give me a simple environment, I’ll do it myself.”. But just as often it is done by engineers who care about the quality of the module they build. My opinion is that if they used a TDD approach to create that simple stimulus then that effort could be integrated and leveraged as part of a team’s overall testing strategy. Using a TDD framework (like SVUnit) creates a consistent, common approach rather than a set of disparate ad-hoc environments.
As well, having a set of unit tests provides working examples of how to use the particular module. Using a common approach to this task can mean that a set of unit tests can be provided with a module – increasing the possibility of the module to be re-used in a subsequent spin of the chip, or by another project in your company.
Using TDD provides one clear advantage: once the tests are in place, I can fearlessly make functional changes to the code knowing that I’ve got a very fine granular set of tests that quickly tell me when I’ve broken something. While RTL designers do spend a lot time working on timing and physical issues, I believe that if they have spent some time doing TDD tests that they could fearlessly make changes to structural issues knowing that they can quickly verify they haven’t broke any functionality – without having to wait for the next regression (or until the next random selection when the particular sequence of stimulus occurs).
Management: Waterfall vs Agile
Mike states that no one (still in business) uses a pure waterfall approach to scheduling their team. I’d be willing to bet that there are still teams who continue to successfully use a strict waterfall method. Some teams are obliged to to work in a waterfall approach because of their particular industry or system that they are delivering into. I’m going to concede the intent of Mike’s statement: the pure waterfall approach of sequentially completing requirements analysis before design; completing design before implementation, etc all the way to acceptance testing is rarely used anymore.
However, the intent of the picture that Neil created is a meant simply to illustrate the true value of an iterative approach to manage a project. What I take away from that diagram is that most of your team is focused on delivering the next of set of important features. While the groups won’t be in perfect lock-step process as the diagram perhaps conveys, they are all working on those features together. That means that the RTL designers, verification and software teams are all considering features A, B, and C at the same time. The RTL designers are considering the physical and functional aspects that must be delivered; the verification and software teams are trying to design what they’ll need in their respective environments to support these new features. But the key is that they are all focused on features A, B, and C at the same time.
(Playing my own devil’s advocate:) It is definitely true that a particular feature may be trivial to implement in RTL, and extremely difficult to verify, or vice-versa. But if the process you use encourages the teams to look at features in this way, the team can potentially come up with ways to reduce the complexity for whoever has the more complex portion e.g., RTL can add functionality to make the verification task easier; verification could consider ways to share their work with software; software can consider ways to offload potentially difficult pieces of hardware where performance is not critical. The agile methodologies encourage thisconcurrent collaborative process.
Compare this approach to many (many) teams where RTL designers, verification and software are usually not looking at the same issues at the same time. In many teams RTL functional design is complete well before verification creates their first environment, software is still working on the previous release and won’t look at even a software register map to spot usage model issues.
That to me is the key strength of the agile approach – create opportunities to break down the walls that currently exist for many groups. That’s what Neil’s picture says to me.
So I don’t have a set of questions like Neil (he asked the ones I wanted to hear about), but I’d welcome anyone’s thoughts regarding my post, or Mike’s. Again, both Neil and I would encourage anyone with positive or negative views to share them on AgileSoc.