The ASIC Factory (Complete) : The Toyota Way For Fabless ASICs

Reading The Toyota Way by Jeffrey Liker got me to thinking about the benefits of bringing manufacturing into the realm of ASIC design (low cost, high quality, predictability, etc). For those who don't know, The Toyota Way is Toyota's management philosophy. The production system reflecting that philosophy allows Toyota to consistently figure as one of the best companies in the world. It's hard to comprehensively describe a philosophy in words but it is generally accepted that there are 14 principles that capture the essence of the Toyota Way. How can these 14 be applied to ASIC design? My thoughts:

#1. Base your management decisions on a long-term philosophy, even at the expense of short-term financial goals.

Focus on core competencies and don't waste too much energy pursuing multiple courses of action. This would apply to designs too. Trying to be good at everything from low-power wireless designs to high-performance multi-core processors is a recipe for disaster. You could extend this to methodologies or even EDA tools. Streamline. Focus. On the flip side, don't let the lack of a large current market prevent you from pursuing technologies or products that would have a great future market. Lastly, distinguish between the two (easier said than done but someone has got to say it ;) ).

#2. Create a continuous process flow to bring problems to the surface.

Have a methodology and design process that is transparent and efficient. It will allow you to easily spot problems in the flow. Minimize idle time and non-value added work. In the course of work, a design engineer:

• writes a script
• checks the syntax
• executes the script
• waits for the results
• opens some reports
• checks specific parameters (slack, perhaps)
  

Writing the script and checking the slack are pretty much the only steps that really adds value. Everything else is a waste of the engineer's time. What are you doing about it?


#3. Use "pull" systems to avoid overproduction.

In "pull" systems, the control flow is backward not forward. Each stage "pulls" its required inputs from previous stages rather than having inputs "pushed" onto it. You replenish items that are being depleted (i.e sold) rather than creating items in set proportions. "Pull" processes avoid overproduction by generating items in response to consumer demand. Further, note the complete lack of upfront scheduling. One of the advantages of "pull" systems is that they are self-scheduling. Each stage signals the previous stage in such a manner that the end goal is reached just in time.

In an ASIC design context, the translation of the principle would be that each stage of the ASIC design flow "pulls" data from previous stages. For example, place-and-route "pulls" data from scan insertion. There is no point in rushing through scan insertion if the scan-inserted netlist is not going to go through place-and-route for the next few days. The DFT engineer does not need to create a scan inserted netlist until the PNR engineer is ready to use the scan inserted netlist. Prioritizing is simplified, too. When juggling multiple projects, the DFT engineer simply works on the design that flags him or her first. In such a system, each engineer will work on high-priority items first and project will progress at the right pace and complete on time.

#4. Level out the workload (heijunka). (Work like the tortoise, not the hare).

Leveling out the workload has multiple benefits. Since the load on resources is close to constant, it is easy to predict demand and plan accordingly. As resources are closely matched to load, there is optimal utilization of resources as well. In organizations where the load varies wildly, the management will have to plan for the worst case. The problem is that these acquired resources will never be fully utilized during normal periods. When you level out the workload, transitional peak requirements are correspondingly low. You will require less "margin" when it comes to tools, machines and even people. One of my previous posts, It's Not What You've Got, has some details on application of heijunka for machines and licenses.

#5. Build a culture of stopping to fix problems, to get quality right the first time.

Most ASIC design projects go through concurrent evolution of RTL, floorplan and package. Sometimes, for new IP, we can expect that the IP vendor will provide multiple drops of increasing maturity as the project progresses. Given this state of affairs, does this principle imply that we must freeze RTL before running synthesis? or that the IP must be solid before the RTL is designed? No! Quality is relative to expectations and point of view. For synthesis, the meaning of high-quality IP might be that the timing information contained in the libraries are final or close to final. This would allow synthesis to proceed without nasty timing surprises down the line. The area of the IP is immaterial. The IP need not even have a dummy placeholder LEF. For place-and-route, high quality can be taken to mean fixed IP macro size and fixed pin locations. The GDSII that matches the size and pin locations can come later during the final DRC runs. Clearly, this principle does not preclude usage of a concurrent evolution methodology.

What we seek to prevent is the propagation of low quality (as defined by expectations) in the ASIC flow. Quality is a box that is centered around a target number (area in sq.mm, for example) and bounded on either side by tolerance limits (within 5% of final design area, for example). Anything within the box is of acceptable quality. Anything outside the box is of low quality. Low quality RTL, for example, can be defined as RTL that does not include blocks with large area impact. When the designer does not fully capture the area of the design, the place-and-route strategy will suffer. When the design grows by a million gates over the space of a few iterations, your floorplan and powerplan go out of the window. In fact, you might find yourself in the unenviable position of having to switch from a flat place-and-route strategy to a hierarchical one.

Low quality inputs lead to low quality outputs. Rather than waste time and effort downstream, do the right thing: Get quality right the first time around.

#6. Standardized tasks and processes are the foundation for continuous improvement and employee empowerment.

The benefits of standardization are many.

• Standardization of processes is essential to meet quality constraints. When each engineer has his or her own way of doing things, the quality of the output varies widely. Further, there is a high probability of the introduction of errors. When you diligently follow a proven process that is known to provide quality output, the chance for errors are minimized. A standard synthesis script that is to be used across all projects is an example of a standardization that makes it easy to meet quality constraints.
• Standardization makes it easier to map out and subsequently meet schedules. When you have fully mapped the path from RTL to GDSII, you already have an idea of the critical execution path and how long the process will take. In fact, through standardization, scheduling methodology itself will be a well-documented process.
  
• Standardization is the first step towards automation. When your processes are standardized with respect to inputs, outputs and measurable quality metrics, you already have a specification that can be used to automate the menial and repeatable sections of the ASIC design process.
• Standard processes are required to be fully specified before one attempts any process improvement strategies. Before you can improve, you must know what it is you're improving upon. Further, when the process improvements suggested are "proven", they can be incorporated as a part of the standard design process. If you find (and prove) a way to improve simulation runtime by 15%, it is easy for everyone in the organization to reap the benefits if this improvement is incorporated into the standard ASIC design process.
  
• Standardized processes that are accessible at all levels serve to empower employees. When everybody knows what needs to be done and what is important, they have a checklist against which to evaluate a situation and their proposed response. Employees are empowered because they are able to take decisions with greater independence. Further, they have the confidence that the decisions made are both right and justifiable in light of set processes.

#7. Use visual control so no problems are hidden.

The principle of visual control is not about a fancy GUI with lots of bells and whistles. It's about providing the user the easiest possible way to check whether their work is on track or not. The idea is : summarize, summarize, summarize. Create indicators that make it easy to take decisions. It's the difference between a IR drop text report and a heat map. The former is accurate but the latter is a more effective indicator. But, don't think you have to draw pictures all the time. A simple summary table that captures the essence of a 10000 line timing report is also a visual indicator in this context. Effectively summarizing a report is one level of visual control. What about the entire design project? Imagine, for example, an active version of your ASIC methodology flow diagram. As tasks get completed, boxes turn green in real time. Perhaps, the size of the boxes could be indicative of the time taken for a task. In one look, the project manager knows where the project is and what needs to be done.

Be sure to tune the visual indicators to match the target end-user. Unlike the ASIC flow visual used by the design manager, a timing engineer would see a summary table with violations categorized by slack, number of violations, violation clock groups, etc. For someone at the CEO level, all they'd see is a progress bar saying 'project 65% complete'.

#8. Use only reliable, thoroughly tested technology that serves your people and processes.

Stable processes built on stable technologies and tools is what enables a fabless ASIC company to deliver quality products on a predictable schedule. Given this, there has to be some very compelling reasons for a company to migrate to newer technologies, processes and tools.

• Will it fit into and improve our processes?
  If no, you can stop right here. The tools serve the process and not the other way around. Before anything else, ensure that your new tools will fit into or improve your processes.
  
• Will it benefit our engineers?
  Even the most technologically advanced tool is worth nothing if it cannot be used by your engineers. Ensure the people who actually going to use the tool think it's going to improve their lot.
  
• Has it been tested by us?
  Ensure that you go put the tool through its paces with meaningful tests. It's good to have a formal evaulation process and a set of testcases to measure the benefits of any new tool or technology.
  
• Does it consistently offer a marked value improvement over current tools?
  It is essential that a new tool or technology offer a significant value addition over existing ones for successful adoption. Usually, there's substantial institutional knowledge (tacit or explicit) about incumbent tools and technologies. When you shift, there's a learning curve that will cause some impact in terms of productivity. Further, the value addition is what will drive your people to adopt the new technology or tool. If new tools do not deliver significant value over current ones, they's not worth using.
  
• Does it require a significant rework of processes?
  Much like the previous question, some tools might require too many changes to the way you do business. Rapid change is an energizing concept for business books but suicidal when it comes to mucking around with processes.

You don't want to become a dinosaur clinging onto processes till you become extinct. You don't want to surf on the edge of chaos, either. How does one reconcile constant improvement of processes with the if-it-aint-broke diktat? Separate the improvement of processes from the mainstream. Live projects continue using proven technologies and processes with success. At the same time, there is a group or an effort to evaluate new technologies, tools and methodologies that have the potential to offer a value addition over current technologies, tools and processes. If the improvements show promise after exhaustive testing, they can be incorporated into the mainstream methodology.

#9. Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others.

If corporations are organisms, corporate culture is akin to the genes. People, like cells, come and go but the culture of the corporation remains unchanged. What determines corporate culture in the first place? As someone once wrote, things that get rewarded get done. The same goes for corporate culture. The culture that gets rewarded gets followed. This is great if your culture is the one you want. But, what if you're at A and you want to get to B? Effecting cultural change is not easy but, atleast, it's slow :). What is the best way to get from A to B and stay there? When you advance and reward people who live by and understand philosophy "B", you not only set in motion the change of culture from A to B but also, through positive feedback, ensure that the change sticks. Using visible and respected leaders who live, understand and spread the philosophy is one of the best ways to make this happen.

#10. Develop exceptional people and teams who follow your company’s philosophy.

If #9 was about getting the right "PR", this principle is about live demos. The evangelizing leaders are ok but you have to give people something to hold up and say "See?! this stuff works!". This principle works as a two-step process . Step 1: get people and teams to work within the defined process. Step 2: get exceptional. When exceptional work is accomplished using the defined process and tools, the corporate philosophy gets reinforced in the minds of the engineers.

#11. Respect your extended network of partners and suppliers by challenging them and helping them improve.

When it comes to ASIC design, there are not many companies that can go it alone. A typical fabless ASIC has EDA partners, IP partners and assembly and test partners. You could think of customers as partners in this context. Why would you want to challenge and help partners improve? Whether you like it or not, each of these partners is a co-pilot. If there's a problem with an IP macro, a project using the IP gets delayed until the IP is fixed. What if you could help your IP vendor deliver quality collateral the first time around?If you're an IP company, you probably spend a lot of time supporting customers whose IP is not integrated correctly. What if you could help your customers integrate your IP correctly the first time? Everybody wins!


#12. Go and see for yourself to thoroughly understand the situation (Genchi Genbutsu).

The prerequisite for any successful process improvement initiative is a good problem statement. This principle mandates that, in order to frame a good problem statement, you have to experience the pain firsthand. This way, your work is not directed by assumptions and guesses. You think and design from personal experience and have a solution that addresses the real problem. For example, what are the pain points in your ASIC flow? Too many ECOs? Is timing closure where your people burn most of their cycles? Or, perhaps, the last few DRCs? You'll never know until you experience it firsthand. Once you know what the problem is, the solution cannot be far behind.

#13. Make decisions slowly by consensus, thoroughly considering all options; implement decisions rapidly (nemawashi).

This principle is a masterful piece of social engineering. It's relatively simple to put a product project on the fast track. You create a skunkworks team and let them drive the project to completion. The problem with such an approach is that you will crash and burn when you apply it to processes. When it comes to processes affecting people, you first need to ensure that you're solving their most pressing problems. Second, you need buy-in from everyone to ensure successful adoption. That's why this principle works for processes. Counter to a skunkworks method, process design (or re-design) should be something every concerned stakeholder should have a hand in deciding. This approach provides superior solutions that also stand a better chance of large-scale adoption.

• Since the decisions involve the key stakeholders, the outcome is probably a superior solution that addresses the real issues.
  
• By having a larger number of people exploring the solution space, the quality of the solution is improved.
• Since all stakeholders feel like they had a hand in the design, the not-invented-here issue does not arise.

At the end of the decision-making process, there is support for the solution across the rank and file of the organization. Further, the solution will not undergo further changes. These two factors make possible the rapid implementation of the solution.

#14. Become a learning organization through relentless reflection (hansei) and continuous improvement (kaizen).

Think of the previous principles as directions. This 14th principle is the motive force that propels the organization. The 14th principle turns an organization into a living being constantly evolving to meet the challenges within and without. The principle is simple. First, everything and anything can be improved if you apply your intellect to its design. Second, incremental and continuous change at every level of the organization directed by the previous thirteen principles has the highest chance of success.

Tags : Methodology, ASIC, VLSI