The ASIC Factory (Part 5) : The Toyota Way For Fabless ASICs

This post is part 5 of the application of the 14 principles of the Toyota Way to the ASIC design process. To catch up, you can either read Part 1 , Part 2 , Part 3 and Part 4 or click on principles #1 through #8 below.

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

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

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

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

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

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

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

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

#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!


Tags : Methodology, ASIC, VLSI

The ASIC Factory (Part 4) : The Toyota Way For Fabless ASICs

This post is part 4 of the application of the 14 principles of the Toyota Way to the ASIC design process. To catch up, you can either read Part 1 , Part 2 and Part 3 or click on principles #1 through #6 below.

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

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

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

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

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

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

#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.


Tags : Methodology, ASIC, VLSI

The ASIC Factory ( Part 3) : The Toyota Way For Fabless ASICs

This post is part 3 of the application of the 14 principles of the Toyota Way to the ASIC design process. You can find Part 1 and Part 2 here or click on principles #1 through #4 below.

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

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

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

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

#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.

Tags : Methodology, ASIC, VLSI

The ASIC Factory (Part 2) : The Toyota Way For Fabless ASICs

This post is part 2 of the application of the 14 principles of the Toyota Way to the ASIC design process. You can find Part 1 here or click on principles #1 and #2 below.

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

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

#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.


Tags : Methodology, ASIC, VLSI

The ASIC Factory (Part 1) : 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?

Tags : Methodology, ASIC, VLSI

Bridging the Divide : EDA User Groups For Multi-Vendor Flows

There's SNUG for Synopsys and MUSIC for Magma. There's User2User for Mentor and CDNLive for Cadence. But, it still feels like something's missing. Don't get me wrong, these conferences are a great place to learn about the latest and greatest ways to use your favorite tool. It's just than no one is looking after the interface between the EDA vendors. If you are one of many ASIC design houses that use multiple EDA vendors, then you know what I'm talking about. If the place-and-route tool does not re-order the scan chains stitched by your DFT tool, What do you do? It may be the PNR tool's problem or the DFT tool's problem, but it is certainly your problem!

There's potential for some mismatches when a flow crosses EDA vendor boundaries and, usually, it's up to the users to make the tools from different vendors work together. While one does get a whole lot of support from the vendors, the ultimate responsibility rests on the ASIC engineer. Further, the inter-vendor issues are discovered anew by each ASIC design company (or worse, each engineer) and precious cycles are wasted in figuring out the issue and possible workarounds. If only there was some way to document the issue and associated workarounds for the benefit of all ASIC design companies! Enter Multi-Vendor EDA User Groups, stage left.

EDA vendors might not be the biggest sponsors of such groups as PR ROI might not be as great as for their individual events. Maybe all the small EDA companies that cannot afford their own user groups can get together on this one. But, I'm guessing this idea needs a more democratic driving force to really work. The people who'd make it a success would be the ones who feel the pain.

Multi-Vendor User Groups. Of the Fabless ASICs, By the Fabless ASICs, For the Fabless ASICs?

Tags : EDA, ASIC, VLSI