Neil Johnson - Principal Consultant, XtremeEDA Corp
EDA360: The Way Forward for Electonic Design and Silicon Realization–A New Approach To Faster, Better, and More Profitable Silicon, both released in 2010 by Cadence Design Systems, posted some lofty goals for the EDA industry. Discussed and debated thoroughly, the overarching themes of these papers is a fundamental shift in how EDA tools and semiconductors are developed. The EDA360 vision predicts a need for EDA and semiconductor companies drop the prevailing hardware centric, bottom-up approach to development in favor of a collaborative, top-down approach driven by the application of the end product. The reason for this shift is that semiconductor companies are no longer providing point hardware solutions. What were once strictly hardware solutions have become complex system solutions that have come to invariably include a large embedded software component.
From a different world comes a compatible approach to product development. Agile software practitioners have been successful for more than a decade with a similar approach to product development. Agile teams use a top-down approach suggested by EDA360 where team goals are driven by a view of the end application, or more specifically, the needs of their customer.
While the EDA360 vision could prove to be a critical motivator in the transformation of the EDA and semiconductor industries, it is just that: a vision. To realize that vision, a team needs proven process and methods. The goal of this article is to show how agile development principles can enable realization the EDA360 vision.
EDA360: The High Points
The word vision tends to be reserved for ideas that are big, abstract and all encompassing. For some, visions can be a powerful factor in finding revolutionary new solutions. For others, they are fluffy and annoyingly vague. In the end, a vision requires interpretation before it can be made practical. The following sections take a closer look at a few important pieces of the EDA360 vision with opinions for why they are important to semiconductor development.
Application Driven Development
EDA360 is based on the idea that semiconductor development is no longer restricted to delivery of hardware. Products are a combination of hardware and software designed to solve larger and more complex system-level problems. The usage model has changed accordingly where the customer view of a product has shifted away from the low level details of the hardware to that of the application. Development teams, therefore, must embrace the application as the primary driver of development.
For many developers, application driven development will seem completely foreign because the application view of a product has historically been the domain of software engineers and system architects. The developer’s context is normally abbreviated to contain a particular module within the design and its communication with adjacent modules. As a result, the developer’s ability to make intelligent decisions is similarly restricted. The EDA360 vision suggests a dissemination of the application level knowledge formerly reserved for architects. This dissemination of knowledge enables developers to make smarter design choices relative the needs of the application, particularly as it relates to usability for an end customer.
Use the right tool for the job, that is how holistic verification is defined in EDA360.
“Working with the single goal of verifying design intent…EDA tools must choose the best approach for any given phase of the verification process”.
EDA360: The Way Forward for Electronic Design
This is particularly critical in verification because of the wide array of tools and approaches that could include any/all of simulation, formal analysis, emulation, acceleration, prototyping, ESL modeling, co-simulation, etc. Holistic verification–and an implied next generation of verification smart tools–presents a lofty goal for EDA companies.
But holistic verification–and for that matter holistic planning, software and hardware design, support, maintenance and all other phases of an application driven development cycle–should mean more to semiconductor development teams. Teams must see finding “the right tool for the job” as a subjective task that is entirely dependent on the needs and characteristics of a development team as well as its plans for delivery. “The right tool for the job” will not be the same for everyone; it may not be the most advanced–or possibly even current for that matter–nor is it even guaranteed to stay constant over time. The right tools are those that are easily integrated and best address the needs of the team, its product and end customer at a particular time and phase of the project.
If smart tools from EDA companies fit the bill, great. Otherwise, a holistic approach to verification–or more importantly, the entire development cycle–is one that will be created and refined by semiconductor companies themselves.
Intent, Abstraction and Convergence
Intent, or more specifically unified intent, is the idea that everyone in a development team works from the same product description. The product description has clear definition for structure and content and represents a unified source of design intent which drives all phases of development.
Abstraction is the idea that intent should be realized at the most appropriate level of abstraction. Raising the level abstraction as much as possible brings benefit with respect to productivity, expediency and reuse because only the relevant details are considered. Decisions related to lower level details can be delayed until necessary.
Both intent and abstraction are tenants of EDA360 silicon realization that have been on the radar of EDA and semiconductor companies for many years as a means of increasing productivity and efficiency in semiconductor development. The tenant of convergence however, detailed in Silicon Realization–A New Approach To Faster, Better, and More Profitable Silicon, adds considerable value as part of EDA360 and goes beyond traditional thinking.
Even modestly sized state-of-the-art products are developed as a set of newly developed modules and IP blocks along with the supporting integration logic. Completion of these modules and IP ideally converge at some point as they are molded into the end product, validated and delivered. With successful convergence comes successful, timely delivery. For teams that are slow to converge, the obvious consequences can include added stress on the development team, delivery dates being pushed and ultimately dollars lost.
Where convergence as described within EDA360 adds value, however, is that EDA360 highlights the need for close collaboration. As noted in Silicon Realization–A New Approach To Faster, Better, and More Profitable Silicon:
“the term “convergence” represents the marriage of top-down and bottom-up methodologies. Convergence is about building a solution where successive refinements and concurrent optimizations ensure intent is met in all aspects.”
Silicon Realization–A New Approach To Faster, Better, and More Profitable Silicon
The paper goes on to discuss how trade-offs must be balanced during development between functional, electrical and physical constraints and how collaboration, with foundries in particular, is necessary to speed design closure and reduce the risk of re-spins.
Convergence is quite obviously critical for success semiconductor delivery. Within EDA360, collaboration will be the key enabler for convergence; between product companies and foundries as noted but also within design teams between functional experts of all disciplines.
How We Get From Point A to Point B
Imagine yourself on a day-long hiking trip with your team. It is early morning and everyone has gathered at the office, each with a backpack with a day’s worth of food and water. A driver in a 15-passenger van pulls up. The team piles into the van and heads out to point A, a secluded little place just south of the middle of nowhere. The goal for the team is to lay claim on behalf of the company to point B then call in for a ride home.
From point A, point B is about 102,000 paces at a bearing of 43.7 degrees. Since no one on the team has ever been there, your executive team–which coincidentally has never been there either–has held information sessions to describe point B. Only half the team has attended these sessions due to conflicting responsibilities.
After arriving at point A, the first thing the team does is split into four small groups. Based on their understanding from the information sessions, each group devises a plan for how it intends to get to point B: one group draws a map, two others write detailed, step-by-step directions and the last team talks about how to get there but does not end up with an exact plan. There is some chatter and discussion between groups, but in the end, each decides independently on how best to get to point B. Plans in hand, everyone agrees to meet at point B at 5:00pm and the groups strike off.
Just as they get started, a company executive speeds out to point A (in his Ferrari) and calls one group back. He needs them to stay behind for an hour to clean out the van so it can be returned to the rental agency. As they clean the van, the executive makes a comment about point B being 5,200 paces north of where was originally suggested though he also admits he cannot be certain. He then jumps back in his Ferrari, offers his best wishes to the groups and speeds off.
And so it follows that each group makes its way toward point B, one starting an hour later than the others and each following its own plan. The groups do not see each all day.
Only one group shows up at point B by 5:00pm. At 6:00pm, a second group shows up. Shortly thereafter and out of breath after having sprinted the final mile, the third group arrives. The last group, however, never arrives.
At 8:30pm, the three groups at point B scramble around nervously until eventually they stumble into the final group–which coincidentally was waiting roughly 2,500 paces away. It is now 10:00pm and darkness has set in. The newly rejoined team resigns to the fact that it will not be able to find its way back to point B, nor lay company claim to point B, so they call the executive team with their new coordinates for a ride home.
The next morning, a different driver in a different van finally shows up to take the team back to the office (changing companies saved 20% on the cost of the rental!). Your team, now ragged, tired and hungry, staggers into the van and heads back. The team arrives at the office to the deflating news that point B was not point B at all (it was actually point C). Your executive team has decided that you and your team will be leaving the next morning to lay claim to what is now certainly and undeniably point B; no question about it.
Lessons Ignored in Traditional Development
Why lessons ignored and not lessons learned? It is because so many teams in semiconductor development have taken this journey before–many more than once–and the opportunities for lessons learned along the way tend to be ignored. Instead, teams rush into their next project for fear that taking the time taken to retool and reload will put the team’s new objectives at risk.
There are several opportunities to learn from the team’s hike to point B:
- Only half had attended information sessions describing the team’s objective
- The location of the team’s objective is given in terms that are quite meaningless
- The first thing the team does is split into smaller groups, each creates their own plan to reach their objective
- A convenient yet arbitrary meeting time is chosen (5:00pm is the end of the work day)
- Little discussion is held between groups during planning
- The groups do not see each other all day though they all expect to meet at point B by 5:00pm.
- One group is interrupted to fulfill a task of questionable value
- That same group is given ambiguous information about the team’s objective; that information is not shared with the rest of the team
- Executives distance themselves from the development team but are not afraid to intervene when they see fit
- Not all groups started the journey at the same time
- Groups arrive at their objective at different times
- One group arrives exhausted to point B and there is a nervous scramble to find the final group
- The team comes close to their final objective but unfortunately misses on both location and time
- The moral and well-being of the development team is compromised to save a few dollars on a rental van
- The whole team ends the hike exhausted after being stranded all night without relief
- Even though the team missed their objective, it was completely wrong anyway
- Executives quickly recalculate the location of point B and waste no time in redeploying the team
Everyone in product development can attest to the importance of execution. Most in EDA and semiconductor development, however, underestimate how execution can be improved with even minor effort. All of the previous bullets point to either flawed execution or are the results of flawed execution; the parallels to the semiconductor development should be easy to spot.
For teams looking to realize any significant improvement in development process, including those that see the value in creating a top-down, application driven development process described in EDA360, they must first take the time to learn from their past. A team cannot simply adopt the next big thing–or anything for that matter, EDA360 included–and expect success.
Lessons Learned With EDA360
As previously noted, Silicon Realization–A New Approach To Faster, Better, and More Profitable Silicon highlights the importance of convergence with insight into how EDA providers can assist teams converging on its end product. This is a significant step in the right direction, both in terms of recognition and of possible solutions.
Building on what is presented in EDA360, the remainder of this article focuses on two very basic corollaries of convergence:
- The need for convergence implies that there has been some initial divergence; and
- Lesser divergence should simplify the problem of convergence.
The story of the team hiking toward point B is meant to be a lesson in the importance of convergence. It is also meant to emphasize how we in hardware development have a preference for divergence and how we have ignored the problems divergence creates as teams approach delivery.
Obviously, EDA360 does not only apply to EDA. The immediate effects will be felt by organizations that evolve to use next generation tools and techniques. Further, the evolution toward EDA360 will undoubtedly trickle down to even the organizational structure, especially when teams understand the importance of convergence and the requirements to make it happen when focused on the application. Agile development process can almost certainly assist organizations with this immense undertaking.
Realizing EDA360 with Agile Development Methods
Close collaboration is a key characteristic of Agile development teams. The reason for this close collaboration is that agile teams understand the perils of divergence and that minimizing divergence also minimizes rework for every link in the development chain.
Consider traditional semiconductor development process where functional compartmentalization and limited collaboration creates one long diverge–converge cycle. A number of functional teams are allowed to wander from the very beginning until mounting delivery pressures dictate the obvious need for a stressful, at times haphazard convergence. What usually plays out is represented in Figure 1 where management, architects and the entire development team start with different views of the product.
Unified intent is one way to limit early divergence but does not completely address the problem. Even with unified intent, early divergence is almost guaranteed by the fact that there is very little correlation between priorities of functional teams. Shared milestones do not normally appear until a product release, which for any non-trivial development can be many months after a development begins.
Now consider a process that includes not only unified intent, but regular milestones that are shared across all functional teams. The purpose of these shared milestones is to ensure that functional teams are indeed converging toward a customer solution long before delivery of the end product. A key characteristics of these shared milestones is that they normally entail completion of some functional subset of the end product.
With the understanding that development will diverge from intent to a varying ways and to varying extent, agile teams set milestones for incremental completion of a product. In agile development, the repeated diverge/converge cycle shown in Figure 2 is known as incremental development. Teams start small by developing a small but functional subset of the end product. In semiconductor development, this could include a subset of the RTL, a test environment and test suite to ensure the RTL is functionally correct, any embedded software and a partially completed physical design. The entire team then gathers to critique that functional subset to see that it meets intent. That cycle is repeated all the way to the end product.
To highlight the link between incremental development and EDA360, incremental development by definition is a process “where successive refinements and concurrent optimizations ensure intent is met in all aspects” as noted in Silicon Realization–A New Approach To Faster, Better, and More Profitable Silicon.
With much shorter cycles, opportunities for divergence are minimized thus simplifying the problem of convergence. The team also takes the opportunity to unify and/or modify intent at the end of each cycle, ideally with input from its customer. A key characteristic of incremental development is that each increment ends with a functional subset. A functioning product offers the best opportunity to objectively observe how a team has captured intent. The length of each cycle is left to the team though they are normally between one week and three months in length.
A New Approach to Delivery
With incremental development comes new possibilities for product delivery. Because they are regularly converging on functional product milestones, agile teams may also consider delivery at each milestone, the benefits of which are two-fold. First, the team is always in a position to deliver incremental product updates to its customers. In hardware development, target technology obviously dictates feasibility but for FPGA or IP development in particular, incremental delivery is entirely realistic. Second, the team is always in a position to cut scope and/or terminate development if it is found that delivery of reduced scope meets the needs of its customer (aka: you aren’t going to continue building in features that your customer won’t use). The decision to cut scope and/or terminate development can be applied regardless of target technology.
The EDA360 vision should be considered as being quite progressive in the way that the responsibilities of developers change to support the application of the product as opposed to the limited view they have traditionally been given. EDA360 falls just short, however, of the standard set by agile development teams.
For agile teams it is not the application but the actual customer that leads development. Because the team is responsible for realizing their customer’s intent, their customer may be fully integrated within the development team to play a leading role in a collaborative effort of development and delivery. The reason for integrated the customer is that it is assumed that intent–or application–will change over time and that deviation in intent must be reflected in the final product.
In the ideal scenario, agile teams have a customer onsite at all times to critique deliverables and clarify intent. In the context of EDA360, when–not if–an application changes, a customer is immediately present to guide the team. To be sure, this is not a “customer is always right” scenario; it is a true collaborative effort where the customer has a vision for the application and the development team helps realize that vision. The two share analysis of the issues and trade-offs that invariably appear during development as opposed to one giving orders to the other.
Cross-functional Development Teams
In Agile Transformation in IC Development, the concept and application of cross-functional development teams is described as follows:
“IC development teams are typically divided into functional sub-teams. Design, verification, physical design and software are the most common functional splits. Between them, there are usually spikes of cooperation during times of bug fixing and crisis management. Cooperation also tends to increase as a project nears conclusion. These functional sub-teams, however, usually set their own priorities and work toward their own goals on a daily and weekly basis. And while they do not operate in complete seclusion from each other, it is fair to say that meaningful cooperation is relatively limited during normal development.
A critical feature of an Agile team is its cross-functional composition. While each team member has an area of expertise, there are no formal lines drawn based on function. The entire team works toward common goals on a daily basis and collectively the team assumes a “get it done” attitude. The team’s common goal of delivery at regular intervals brings steady motivation for regular cooperation. It also creates a penchant for crisis aversion that is not present between independent sub-teams…”
Agile Transformation in IC Development
Functional specialization and organization into functional sub-teams is most certainly the norm in semiconductor development. For teams embracing the EDA360 and those that see the value in incremental development, however, this compartmentalization is no longer practical. Semiconductor development teams stand to benefit from working as a cross-functional team with a renewed emphasis on shared goals and cooperative problem solving.
This article has already discussed how semiconductor development teams have a tendency to forget about their past thus losing valuable opportunities for improvement. By contrast, and because agile development is by definition an empirical process, agile teams see analysis of past results as absolutely required for success in future.
To analyze past progress, agile teams use regularly scheduled meetings called retrospectives. This is a time where project stakeholders get together to measure progress in terms of what the team is building–the product–and how the team is building it–the process.
Regular retrospectives are activities that any team can use to continuously improve their product and process. For any team contemplating an EDA360-style upgrade, regular retrospectives should certainly be seen as mandatory; initially to see why current processes are ineffective and then continually thereafter to ensure the team is on the right track in terms of realization.
EDA360 certainly represents a major shift in the EDA and semiconductor industries. It captures the challenges on the horizon for all EDA and semiconductor companies as we continue into an era of large, complex system development and presents a vision for how companies overcome these challenges. Like any vision, however, how it is interpreted and deployed by Cadence and other EDA and semiconductor companies will ultimately determine its success.
Agile development represents another shift in how semiconductors are developed. Many software development companies have already realized that agile brings the toolkit best suited to addressing the unpredictable challenges of building software. While acknowledging the obvious differences between hardware and software development, it is hard to deny that many of the same tools and methods applied in agile development can be applied to semiconductor development.
Complementing the EDA360 vision with proven methods from agile development brings exciting new possibilities and a viable way forward for both EDA and semiconductor companies.
Copyright – Neil Johnson 2011