Working in a startup has forced me to pick up Eric Ries’ “The Lean Startup” again. If you haven’t read it, it’s a book about applying “scientific principles” in a startup or entrepreneurial environments. As a hardware guy, you could imagine my slight “disappointment” the first time I read it. “Well, it’s only for software”, “Big companies probably can’t adopt this”, “Written in 2011? That’s so yesterday”.
I now find some ideas more intriguing after my second viewing (actually listening on Audible during commute). I begin to make connections between the underlying principles behind “lean thinking” and IC design practices. Maybe (and just maybe), IC design is primed to adopt lean principles more formally and systematically. So, you are reading this two-part series as a result of my obsession with such principles for the past couple of months.
Ah management jargons, we meet again
To many, management jargons seem just as foreign (and possibly pompous) as engineering abbreviations. Nevertheless, the end goal of either side remains the same: plan, execute and deliver a satisfactory result in a time and cost efficient manner. I have come to learn that a good “process” is key to sustainable and predictable results. So let’s first put away our engineering hats and look at the three most popular process improvement methodologies compared to the traditional waterfall approach.
Lean
Lean manufacturing was invented by Toyota to achieve a more efficient production system. In the 1950s, Toyota adopted the just-in-time (JIT) manufacturing principle to focus on waste reduction (seven types identified) in the process flow. The system was later rebranded as “lean” and studied by many business schools. In a nutshell, lean systems aim to remove unnecessary efforts that create minimal value for the final output.
Six Sigma
Who doesn’t love normal distributions? Six Sigma’s originator Bill Smith must secretly be a marketing genius because the name fully captures the methodology’s key principle – reducing variations. As one would imagine, Six Sigma processes heavily rely on data and statistical analysis. Decisions are made with data evidence and not assumptions. This notion shouldn’t be that alien to IC designers – after all, we run Monte Carlo simulations precisely for yield reasons. Modern processes combine Lean and Six Sigma and call it Lean Six Sigma (jargons right?).
Agile
You might be the most familiar with this term. After “Manifesto for Agile Software Development” was first published in 2001, it quickly gained steam and almost achieved this “Ten Commandments” type status in the software world. The biggest difference in Agile is its embrace for constant change and readiness to launch small revisions frequently. Many became a fan of Agile during COVID since it proved to be the most resilient system.
Relevance to IC design
It’s easy to classify such process methodologies as “obvious” or “not applicable to hardware”. Some might even falsely generalize Lean as less, Six Sigma as perfect, and Agile as fast. Ironically, “less, fast and perfect” are actually the desirable outcomes from such processes. Acknowledging and studying these ideas can help improve our own design methodologies.
In this post, I want to zoom in on the “waste reduction” aspect in lean (part 1). Not only do we often see over-specifying or over-designing leading to waste, valuable human and machine time are also not fully utilized when schematics are drawn inefficiently.
It’s also no coincidence that some commonalities exist, which might be applicable to circuit design as well. Lean, Six Sigma and Agile all rely on a constant feedback loop of “build-measure-learn”. The difference lies only in the “complexity” and “latency” in the loop (part 2).
Now let’s try putting this in IC design’s perspective: if we are the managers of the “circuit design factory”, how would we adopt these principles?
Waste in IC design
Lean was first applied in manufacturing systems and later extended to other fields. Fortunately, lean is equally applicable to the engineering process. The table below, taken from an MIT course on lean six sigma methods, shows a mapping between the original manufacturing wastes and their engineering equivalents.
So how can we extend this further to IC design? Here is my attempt at mapping these wastes. I wager that you must have experienced at least one of these frustrations in the following table. I bet even more that we have all been waste contributors at a certain point.
Waste reduction toolbox
Now that we have identified the waste categories, let’s discuss the top 5 ways to reduce them during design cycles. You could call these personal learnings from the good and the bad examples. Many ideas here have parallels to some programming principles. So without further ado, let’s begin.
1. Finding O(1) or O(log N) in your routines
Targets waste #4, #8
I apologize for my software persona popping out, but there is beauty in finishing a task in constant or logarithmic time (check big-O notation). Examples for circuit design involve using hierarchies, array syntax, and bus notations to reduce schematic drawing/modification to O(1) or O(log N) time.
If you are learning to create floorplans, ask your layout partners about groups, array/synchronous copy (for instances), aligning (for pins), and cuts (for routes). I wish someone had told me these lifesaving shortcuts earlier because I have spent way too much time doing copy→paste→move.
2. Systematic library/cellview management
Targets waste #1, #2, #3
Borrowing from software again, revision controls in library manager are widely used nowadays. While the benefit is huge, it could lead to unintended bad habits. Many designers simply create as many variations of the same cell as possible without actively “managing” them. This could result in mass confusion later on, especially if no final consolidation happens. Worst case scenario, you could be checking LVS against one version, but tape out another.
If investigations and comparative studies require multiple versions, I recommend using a different cellview instead of creating a completely new cell. Combining with config views in simulations, the entire library becomes cleaner and more flexible. When library consolidation or migration happens, only the relevant final cells will survive, thus a clean database. I plan to discuss how to create a good cellview system in a more detailed future post.
3. Symbol/schematic skeleton before optimization
Targets waste #5, #6, #7
Top-down methodology encourages designers to have a bird-eye view of the entire system in addition to the fine details of their responsible cells. One method is to define block and cell level pins earlier in the design phase. This idea is similar (though not as sophisticated) to abstract classes or interface (e.g. Java, Python, etc.) in object-oriented programming languages. Instead of implementing the specific functions right away, a high-level abstract description first defines the key methods and their interfaces. The IC equivalent would be to appropriately name and assign port directions for each block’s pins. The symbol itself contains all the information for its interface.
“How can I build a symbol without knowing what’s inside?” The truth is you must know the most critical pins – an amplifier should at least have power, inputs and outputs. You must also know the most basic required features on a block – power down, reset, basic configuration bits. Informative symbols and schematic skeletons should be possible with these pins alone. The same concept is applicable to layout and floorplans, with pins + black boxing.
Since we are only dealing with symbols and pins here, it’s must easier to modify if specification changes or a new feature is requested. This ties into the “minimum viable product” (MVP) concept that we shall discuss in part 2.
4. Design w/ uncertainties & effort forecast
Targets waste #5, #6, #7
Now your schematic skeleton looks solid, the device level design begins. You have a clear plan of execution because of the symbol creation exercise, but potential pre and post layout discrepancies bother you till no end. We all have had that fear: what if this thing completely breaks down after layout?
To address this, designers should 1. estimate parasitics early by floorplanning, 2. use sufficient dummies, and 3. add chicken bits. Depicted below is an example of a tail current source in an amplifier. Before starting layout, designers should have a mental (or real) picture of how the unit current cells are tiled together. There could be an always-on branch (8x), two smaller branches for fine adjustments (4x + 2x), and dummies (6x). A critical parasitic capacitor connects to the output node w/ reasonably estimated value.
One could argue the extra programmable branches and dummies are “waste” themselves. Keep in mind that reserving real estate at this stage consumes minimal effort compared to potential changes later in the design process. Swapping dummies and the always-on cells only require metal+via changes. What if layout database is frozen during final stages of the tapeout but some extra juice is required due to specification change? What if the chip comes back and you realize the PDK models were entirely off? The chicken bits might just save you.
5. “Ticketing” pipeline between design and layout
Targets waste #3, #5, #8
This last one is my personal system to communicate with my layout partners. I use a poor man’s “ticketing” tool called POWERPOINT. Yes, you read that right – I am suggesting to use one more .ppt document to cut IC design waste. My personal experience so far is that this interface document provides better communication and results than any zoom calls, especially if there are time zone differences. Below is how an example slide looks like.
Each slide acts as a ticket for a layout modification request. The slides DO NOT need to be pretty at all. A quick snapshot and description serve the purpose of both conveying and documenting the request. As the design gets more complete, this slide deck will grow in size but all changes are tracked in a visual way. This also allows the designer and layout engineer to prioritize and work at their own pace, almost in a FIFO manner. When periodic checkpoints or project milestones are close, this slide deck becomes extremely helpful for reviewing and further planning.
Till next time
Being lean in our design process never means reducing design complexity or using fewer tools. Rather, it’s the mentality that we should begin with the right design complexity and use the right tools.
I hope some techniques mentioned here can provide insights on how to be lean when designing. As promised, there are more to this topic. Specifically, IC design process can also embrace incremental changes in Agile methodology. We can achieve better outcome by breaking large design cycles into smaller ones. So stay tuned for part 2!
