Adapted from: “A Giant, Baby Step Forward: Agile Techniques for Hardware Design”, SNUG Boston 2009
There has been much innovation in EDA technology in recent years and particularly in the area of functional verification. One specific advancement in functional verification that is becoming commonplace in ASIC development is the use of constrained random verification with functional coverage. Constrained random verification with functional coverage is widely considered to be the successor to directed testing. The draw to constrained random verification with functional coverage is the theory that a testbench can apply a broader constrained random stimulus set to a DUT over a shorter time frame when compared to directed testing. The shorter time frame correlates directly with an earlier tape-out and faster time-to-market.
The added up front development cost associated with constrained random verification is generally accepted by the ASIC development community. It is easy to understand how a significantly more complex verification environment would require more resources to develop. As long as the test writing phase is more productive, constrained random verification indeed delivers a productivity gain when amortized over the life of the project.
As with any EDA advancement, however, there are risks associated with adopting a constrained random verification approach. The first risk is how progress is defined. From the view of the verification team, there is a lot of valuable and quantifiable progress made during the environment development phase. With the environment development being such an intense effort, it is easy to get caught up in its perceived importance. Many verification engineers tend to forget that it is RTL – and software – that becomes the ultimate deliverable, not the verification environment.
To a customer, tangible progress is probably viewed in terms of the RTL performing some function to satisfy some requirement, and that function is performing correctly. The heavy front-loaded effort that tends to accompany development of a constrained random environment does not lend itself well to producing this type of progress in the early stages however. This poses a risk to the project where the verification team is not able to give a customer the progress they expect.
The obvious way to de-risk this scenario is to educate your customer by telling them how development proceeds, and when and how they should expect to see results. They should understand the curve from Figure 1 so they are not surprised by the length of the environment development phase and should not expect verified RTL until later in the project. When they do start to see verified RTL, they can expect to see it coming in large chunks as coverage metrics rise rapidly and then start to level off as they asymptotically approach 100%.
Figure 1 – Functional Coverage v. Time For Constrained Random Verification
Figure 1 represents the ideal and carries with it a very real danger. Convincing a customer that they can expect a delay in verified RTL due to the environment development is straightforward using the numerous case studiesshowing constrained random, functional coverage driven verification is verification „best“ practice. The danger is that the team cannot deliver on those promises and create a properly functioning environment on schedule. This scenario should not be surprising given the effort, expertise and foresight required to build a rigorous and robust constrained random environment.
In taking a step back from the constrained random curve that ASIC developers have become all too familiar with, this article contends that Figure 1 is missing some valuable context and is in fact blurring the goal of theverification team and possibly the entire ASIC team. Functional verification is only one piece of the design and test equation. Two major items missing from the curve is the time dedicated to RTL development and software development. Also not represented are some of the human factors that impact success.
The original plot with context is shown in Figure 2. The original verification curve is preceded by RTL development and followed by software development. The RTL development is an extension of the flat line that is essentially a blackout period where RTL designers are busy coding away in isolation. The software extension is a further increase in the coverage curve where software functions are coded and verified. The updated curve shows equal effort for each of the three, a ratio that may vary depending on a number of factors. While also recognizing the non-trivial task of physical design, it is assumed that this combined effort represents the majority share of the effort involved in an ASIC development.
Figure 2 – Waterfall ASIC development with Constrained Random Verification
It should also be noted that the curve in Figure 2 assumes a waterfall approach that is common in ASIC development where the RTL development usually precedes the verification effort and software development lags until a point where much of the hardware development is complete.
While they may not be entirely serial in start and completion, the curve in is meant to imply that there are three separate teams assigned to three separate tasks. While development time may overlap, the goals of each team may not.
In a move away from a traditional waterfall approach to design then verification then software, take these three tasks and layer them in a parallel process where the three proceed in lock step. As RTL is developed, therelevant portion of the verification environment is developed with applicable tests and software is written to support required functionality. This approach is followed through a number of iterations until the goal of product deliverable is attained.
Figure 3 – Iterative ASIC Development
The adjusted, agile curve then for ASIC development would be roughly as shown in Figure 3. The red line still represents the completion in terms of feature coverage though it should be obvious that from the outset, the goal is to have a positive slope as soon as possible. The progress of each iteration is shown with the red dots. Generally speaking, the most important features are always next to be implemented until coverage goals are reached and the end of each iteration would have demonstrable progress.
So the move toward agile development in ASIC development should be two-fold. First, it is an entire team effort where the goals of RTL development, verification and software development are all in sync such that features can be delivered incrementally. Each sub-team is on the same page and each is working toward the same feature based goals. The second is more of an intangible that would not be obvious from any of the curves but has been covered in previous sections. The incremental approach allows for feedback between teams far, far sooner than would typically happen using a waterfall approach. The feedback exchanged between teams that are working toward the same goals simultaneously gives many more opportunities to clarify design intent and holds far less potential for long schedule slips. In short, while the curves in Figure 2 and Figure 3 may show similar completion dates early in the project, the iterative approach should prove more likely and carry a higher degree of confidence.
These points summarize potential value that agile techniques can bring to ASIC development. At a time when team dynamics are becoming more and more diverse, agile development brings a renewed emphasis on teamwork and deliverables as opposed to the compartmentalizing disciplines and using the more subjective metric of task completion. Planning and development iterations provide the opportunities to critique deliverables and design intent and to refine deliverables and design intent, all as a team.
Lastly, all engineers love tools and technology that help them solve problems. Tools only help to solve problems though and rarely are themselves responsible for the actual solution. ASIC development is a process carried out by people. While there have been great innovative and evolutionary strides made with respect to EDA technologies, there have been only minor changes in the way we organize people who develop these highly complex chips. Technology can certainly enhance productivity, but the next big leap in productivity can only come about with changes in the way the team operates. Agile techniques are definitely one set of techniques in a toolbox that should be considered to improve the productivity and quality of deliverables.
For more information, send email to firstname.lastname@example.org
Copyright 2010 XtremeEDA