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). 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 at last as conclusion and summary:
#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
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.
#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. 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.
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.