Reframe and Reuse: Extending The Capabilities Of EDA Tools Through Creative Reframing

There's a joke that goes like this (from Mike Cook's List Of Math Jokes) :

A physicist and a mathematician setting in a faculty lounge.
Suddenly, the coffee machine catches on fire.  The physicist grabs a
bucket and leaps towards the sink, fills the bucket with water and
puts out the fire.  The second day, the same two sit in the same
lounge.  Again, the coffee machine catches on fire.  This time, the
mathematician stands up, gets a bucket, hands the bucket to the
physicist, thus reducing the problem to a previously solved one.

My interpretation: Make the physicist do all the work!


There any many problems is ASIC design for which straightforward solutions/tools may not exist. You want the tool to consider timing, area, power and X. The rub is that the tool does not support measuring or optimizing for X. In such cases, it is worthwhile to explore the possibility of reframing X into something the tool does understand.

By reframing the problem, you save yourself a whole lot of work:

• You don't code, test and release a tool that supports concurrent optimization of X, timing, area, power,..
• You don't create a tool that optimizes only X and spend time iterating between X optimization and standard optimization
• You get to leverage the powerful algorithms built into your EDA tool to concurrently optimize for timing, area, power, X, Y, Z, ...
  

For example, if X is uniform placement density and the tool does not explicitly support it, you can recast the problem as one of uniform/max/min metal density (which is supported via the DRC engine). Using virtual (user-created) metal layers and associated density rules to represent the placement density, enhance the cell's physical view such that the tool sees that the entire area of the cell is covered with one big piece of virtual metal. During optimization, the tool will try and meet the virtual layer density requirements (representative of uniform placement density) along with its standard cost functions (area, timing, power,etc).


Tags : ASIC, VLSI

In The Shameless Pursuit Of Average : Uniformity As A Metric In Physical Design

Physical design tools aim to create a placed and routed design exhibiting the best area, timing and power. As one progresses to smaller technology nodes, the additional steps in the flow deal with more localized phenomena.

• Dynamic IR drop is a local phenomenon in both time and space. It occurs when a group of cells in the same region switch at the same time.
  
• DFM-related phenomena such as CMP effects and CAA hotspots are local in space. They occur due to the layout geometries in a very small window area.

The usual approach in the ASIC design flow is to implement the design first and fix violations due to local effects later. This is a valid trade-off. The overhead in tracking or resolving local effects while implementing the whole design would be high so it makes sense to follow the "design-first-fix-later" approach. Is there another effective way to skin this cat? Let's state our problem in this way:

Local violations occur when local phenomena are far from the full-chip average.

• If the power consumption in a small window is larger than the design average, there would be more static IR drop in that window.
  
• If the power consumption is high in both a small layout window as well as a small timing window, it would result in dynamic IR drop violations.
• If the routing density in a local window is high, it would result in CAA hotspots
• If the routing density in a local window is too low, it would result in CMP hotspots

The obvious solution that presents itself is:

Rather than fix violations later, add uniformity as a cost function in physical design tools to avoid the occurrence of violations in the first place.

• If uniform power density is added to the tool's cost function, we would not see large static IR drop in local layout windows.
• If we can spread power density in both time and space, dynamic IR violations can be reduced as no local layout window will consume a large amount of power in a small time window.
• If we can add uniform routing density as part of the cost function, we can avoid CAA hotspots a priori rather than spreading out wires later.

Tags : ASIC, VLSI

Pushing The Envelope : Mobile/Wireless Design And The Advancement Of ASIC Design

At a high level, the metric space for an ASIC design consists of:

• Performance (Timing)
  
• Area
• Power
• Effort
  
• Schedule
• Unit cost

Depending on the application of the end device, each ASIC project has important metrics and some not-so-important metrics driven by the business concerned. Every ASIC design is sitting somewhere in the n-metric space as per the importance of each metric. For example:

• Supercomputer applications : Performance is everything. The nature of the business (low volume, high margins, controlled device environment) is such that the other metrics don't really matter (within (relaxed) limits).
• Desktop Processors : High performance and unit cost matter. Schedule and effort are very high (think of the teams to spend a year or two doing nothing else but designing the next-generation desktop processor) but that's ok because, with a low unit cost and high volumes, the business will still generate a profit.
• Memories : Area and unit cost matter. The objective is to create the densest memories possible such that you can hit a performance standard at the least unit cost possible.

In contrast to the above, consider the driving forces of the mobile and wireless business:

• Short product cycles
• High volumes
  
• Cost-driven business
• Power-sensitive
• High performance
• Smaller/slimmer mobile devices
• Increasing functionality (multiple interfaces(Wi-Fi, Bluetooth, SD), on-device memory ..)
  

Here's what the metrics look like for the space:

• Performance : high performance (increasing functionality)
  
• Area : ultra-low area (smaller die, smaller footprint)
  
• Power : ultra-low power (very power-sensitive)
  
• Effort : Low effort (small teams, fast turnaround time)
  
• Schedule: Very short (shrinking product cycles, market windows)
  
• Unit Cost : Very low (high volume, low margins)

The mobile/wireless space works to satisfy almost impossible (and conflicting) requirements. There is no slack on any front. This is a good thing. The effect of the all-round pressure is that the techniques and methodologies used in the mobile/wireless space are required to push the state-of-the-art all the time and in all directions. Sophisticated power management, advanced mixed signal design, high-yield techniques, the list goes on and on.

Performance-driven businesses (supercomputers, processors) usually receive the largest mindshare but it is mobile/wireless design that has been (and will be) quietly advancing ASIC design on all fronts.

Tags : ASIC, VLSI

Safety in Numbers : In Search of A Complete Statistical RTL2GDSII Flow

Much has been said about the shift from corner-based sign-off to statistical sign-off. Most of the material has been focusing on the use of statistical timing analysis and statistical extraction to alleviate the pessimism and effort associated with corner-based sign-off. What no one has been touting is a complete statistical solution. Design in the statistical domain is a paradigm shift and cannot but help affect the entire RTL2GDSII flow. In the absence of a complete solution, there's a "lost in translation" scenario when a design transitions from corner-based implementation into statistical sign-off. Put bluntly, is there sense in adopting statistical sign-off while the rest of the flow supports only corner-based analysis?

The smart money says that statistical design is here to stay. In that case, the complete solution is already on its way. But, right now, we are in a no-man's land between corner-based design and statistical design. What are our choices?

1. Short-term Gain/ Long-term Pain. Use corner-based flows until a complete statistical solution is in place. Nothing needs to change as of now. Of course, the transition will be widespread and painful when it is attempted.
   
2. Short-term Pain/ Long-term Gain. Adapt non-statistical implementations tools to work with existing stat-aware tools. The transition into a complete solution will be gradual. The pain here is that of adapting non-statistical tools to fit into a statistical design flow. Lots of workarounds, custom scripts that will eventually be rendered obsolete by the arrival of eda tools with native stat support.
   

Tags : ASIC, VLSI

The Hidden Factory : First Time Yield In The ASIC Design Flow

The Six Sigma methodology is widely used to redesign processes to be more efficient. The way Six Sigma works is to redesign a process to all but eliminate defective outputs. To achieve Six Sigma, a process must create no more than 3.4 defects per million opportunities. Why the focus on defects?

• Defects = Waste: When a process creates a defective output, all the effort and material invested in that defective part is essentially wasted.
• Defects = Rework: When an intermediate stage produces a defective output, the process for that stage is repeated to produce a correct output.

Focusing on eliminating defects in a systematic manner allows a process to be both more efficient as well as produce outputs of consistently high quality.

One of the key measures of process quality used in Six Sigma is First Time Yield(FTY). The first time yield of a single stage is the probability that a correct output is created if the stage is run exactly once. The first time yield of a process is the product of the first time yield of its stages.

FTY is great for identifying priority areas for redesign. Think of a simple process consisting of two stages: A and B. The FTY of A is 50%. The FTY of B is 100%. The FTY of the entire process is 50% (100% * 50% ). Stage B is perfect but Stage A is bringing down the FTY of the process. Another benefit of FTY is to identify "hidden factories". What if stage A is followed by a quality check stage that mandates a rerun of A in case of defective outputs? If we were to insert a QC check stage between A and B, the process as a whole will have 100% yield. But, stage A will be repeated twice on average to produce a correct output for a given input. When you view the process as a black box, you would not see these stage A iterations. For this reason, these iterative loops are called hidden factories. So, a process of multiple stages can produce a million correct outputs for a million correct inputs and still not be a good process.

Consider your ASIC Design Flow in this context:

• What are the chances that a design will go through your ASIC Design Flow in one shot?
• What are the chances of a particular flow (synthesis, scan insertion,...) will go through in one shot?
  
• Which flow is bringing you down?
• Where are the hidden factories?
• What are you going to do about it?

Tags : ASIC, VLSI

Out Now! : TSMC Reference Flow 9.0 Is Now Available

The TSMC Reference Flow 9.0 is available for download from TSMC-Online. Eyecatching items include:

• DFT
• Using E-fuse for MBIST
• Failure Analysis
• Low-power ATPG
  
• Really Advanced CTS
• CTS for Dynamic IR
• CTS for Low-power
• Multi-Mode Multi-corner CTS
• Low-power
• Low power automation with UPF
  
• Statistical Design
• {LPC, CAA, VCMP} --> {Timing, Power, Leakage} Flows

Tags : ASIC, VLSI

SNUG 2008 : Registrations Open

In case you're a Synopsys customer in Bangalore, registration for SNUG2008 is now open. Why, Aditya, thank you for that perfectly selfless propagation of useful information with no ulterior motives....

NOT!

If you can, do try and attend my presentation (in the Synthesis & Test track) on the 10th of July.

Register Cloning For Accelerated Design Closure

Multiple technologies exist to achieve timing closure on critical paths. One such technology, clock skew optimization, changes the arrival of clock edges at the launch and sink registers to increase the effective clock period of the critical path. Standard clock skew optimization does not necessarily utilize the full slack available at the input of a register but only the amount required to resolve the setup violations on paths from the register. If clock skew optimization were to utilize the input slack to the fullest extent towards have a large setup slack on the erstwhile critical path, it could accelerate setup timing closure by letting the tool concentrate on other paths in the design. However, the process could also introduce a large number of hold violations on other paths from the register with low hold slack due to the early launch of data. By having separate clone registers for setup and hold paths, one can fully utilize the input slack to launch registers for accelerating timing closure while limiting resultant hold violations. Since cloned registers are exact copies of the original register, the impact of register cloning on verification and ECO methodology effort is minimized. In this paper, a methodology will be presented to identify cloning candidates, insert clone registers and verify the final design against the un-cloned input.


Tags : ASIC, VLSI

Everything's Connected : An Opportunistic View On Butterfly Effects In Physical Design

The emergence of physical synthesis technologies (such as DC-Topographical from Synopsys and First Encounter SVP from Cadence) is usually attributed to the following:

• Increasing interconnect delay:gate delay ratio
• Imprecise prediction of wire delays using wire load models

While the above is certainly true, it does not seem to be the whole story. It seems to me that the whole problem is that there are additional cost functions that cannot possibly be accounted for without placement and global routing. When it comes to logical synthesis (without physical information), tools have no choice but to optimize paths independently. If there is no combinational connection between two paths, synthesis is not in a position to perform any possible trade-offs between these two paths. A cost function combining timing, area and power is applied to each path independently.

When it comes to physical design, two additional cost functions come into play:

• Placement : How can the cells in the design be placed to optimize area, timing and power?
  
• Routing: Can this placed design be routed?

Placement and routing put a new spin on things because hitherto un-related paths (as seen by logic synthesis) start to affect each other through these functions. The logical synthesis cost function has zeros where placement and routing ought to be. In other words, synthesis assumes that each cell in the design will be placed perfectly. The reality, of course, is far removed from this utopian vision. The best metaphor I can think of for this phenomenon is crosstalk. Can your synthesis tool synthesize for crosstalk avoidance? No.There is no correlation between logical connectivity and aggressor-victim relationships. You have to find the aggressors and victims after detailed routing.

But the problem can also be viewed as an opportunity. Since physical design causes un-related paths to interact, one can play around with non-critical paths to close the design without directly optimizing your critical paths. Like everything else, it pays to see the big picture.


Tags : ASIC, VLSI

Force Multipliers : A Paradigm for Technology and Tool Development

The concept of force multipliers originated in military science. Force multipliers are fulcrums that allow you to have an effect that is exponentially proportional to the amount of resources employed. Radar is a good example of a force multiplier. An air force that uses radar will be able to successfully attack or fend off a much larger force that does not have the benefit of the technology simply by being able to track their opponents in the battlefield. Sometimes, the force multiplier does not physically exist. For example, the coordinated use of air and ground forces as a blitzkrieg is more effective than an uncoordinated force of the same size. The blitzkrieg tactic is the force multiplier in this case.

It seems to me that viewing tools and technologies as force multipliers is a good paradigm for guiding technology and tool development.

1. Force multipliers do not replace; they complement. Did they disband the air force after inventing radar? The objective of tool development in a force multiplier context should not be to create a software version of your engineer. It's about creating a tool that will allow them to control a lot with very little. In a design environment such as Pyramid or IC-Catalyst, the engineer is in control but the environment takes care of all the small stuff (generating scripts, checking reports, firing jobs...). An engineer using a design environment is in a position to accomplish a lot with very little effort.
2. Force multipliers need not be complex; just effective. Creating and supporting a complete design environment is a lot of work. plus, there's always the chance that you're over-solving the problem. Small utilities addressing the right issues in the flow can add value with much less effort. Think scalpels, not broadswords.
3. Force multipliers need not physically exist.A stable design methodology does not physically exist, and yet, guides the engineer in the direction that will produce the optimal result in the shortest time.
4. Force multipliers stack. The effect of more than one force multipliers is not the sum of their individual effects but their product. For example, a good hierarchical methodology and a good timing fix utility employed together will accelerate timing closure beyond the sum of their individual effects.

Tags : ASIC, VLSI

Will It Blend? : Combining ASIC, FPGA and Structured ASIC On A Single SoC

The availability of structured ASIC IP for use within standard SoC creates yet another option for ASIC design houses seeking to balance NRE, per-unit cost and time-to-market. You can see the announcement by ChipX here. If this trend keeps up, the options available to ASIC design houses when it comes to design implementation will be a blend of implementation technologies where designers choose the optimal mix of FPGA, structured ASIC and standard cell technologies to hit their target NRE-UC-TTM sweet spot. There was at least one company, Leopard Logic, that created FPGA IP that could be embedded into a standard SoC. Just a short hop to a company offering all three technologies on the same die.

Think of the advantages that each approach bring to the table:

• FPGA : Highly configurable, Fast Time-to-Market , Low performance
  
• Standard Cells : Zero configurability, High time-to-market, High performance
• Structured ASIC : Medium configurability, Medium time-to-market, Medium performance

Can we have the advantages of all the three if a SoC is built using all three technologies? Just flip the equation.

• Blocks that require configurability but can live with low performance : use FPGA IP
  
• Blocks that require high performance : use Standard cells
  
• Blocks that require medium configurability but only medium performance : use structured ASIC IP

Are we heading towards the universal ASIC design flow that can handle all three technologies on a single die?


Tags : Methodology, FPGA,ASIC, VLSI

Death, Taxes and ECOs : The Inevitability Of Functional Errors Is An Opportunity

There was a great article in EETimes a couple of weeks back titled Virtually Every ASIC ends up as an FPGA that I'd summarize thus:

• Functional verification is becoming more of a problem with increasing number of transistors being crammed onto a die
• Simulation is slowly becoming a non-viable option for functional verification (both in terms of time and test vector generation)
• Prototype FPGAs of your design allow your to apply millions of vectors per second (since you can run the FPGA at high speed) and debug issues much faster.
• FPGA is the new testbench.
  

Here's a thought:

• How can a RTL-to-GDSII flow add and extract value in a world where FPGAs are used for functional verification?
• Is that really necessary? Yes. According to the article, 60% of ASIC respins are to fix logical/functional errors and 90% of all ASICs are prototyped as FPGAs

If you could tune your flow to exploit this reality, you have an advantage executing (or bidding for) 60-90% of all ASIC designs!

Tags : Methodology, ASIC, VLSI

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

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

This post is part 6 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 , Part 4 and Part 5 or click on principles #1 through #11 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.

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

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

#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

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