In part 1 of this series, we introduced the most popular modern project management methodologies and relevance to IC design. More importantly, we identified the most common IC design wastes and discussed ways to address them.
Let’s bring the discussion to the “agile” side. To recap, agile principles were originally intended for software development, and they put more emphasis on continuous and incremental additions to the final products. On the IC design side, Prof. Elad Alon and his team spearheaded the agile hardware movement (here is his great talk). So we will start by looking at some details in their work.
Agile equals “codify”?
Let’s address the elephant in the room: it seems “agile hardware” just means finding ways to codify IC design process, exemplified by Chisel and BAG. Are we becoming programmers?
Chisel’s goal is to further abstract Verilog. “Abstract” perhaps isn’t the best choice here. The better analogy might be that Chisel is to Verilog like Python is to C. Chisel is more friendly for building complex neural network SoCs, like Python is better at building neural network models with PyTorch.
BAG offers a new paradigm for analog/mixed-signal designers, in which designers capture their design flows in Python code. The generator also comes with an automatic layout drawer, which to many is the most attractive feature in modern process technologies. A new framework called TED was published recently, an interesting read given the context of BAG. Shown below is an example of how BAG works.
So what’s wrong?
I personally have mixed feelings about all this. While I truly hope we can shorten IC design cycles to that of software, we could be going down another rabbit hole if we simply agree to codify everything.
To play devil’s advocate, here are my challenges:
- To be fair, BAG’s goal has always been to capture design flows, i.e., how we design, not what we design. However, there is a huge assumption here: our current design flow is worth capturing. We might be opening up another can of worm in picking a design flow, which could lead to more up-front cost.
- Proposed generators tend to focus more on “well-established” circuits, like bandgaps, op amps, diff pairs, and non state-of-the-art converters and SerDes. Given the ocean of available IPs within companies, the supposedly huge savings from using generators become diluted quickly in larger cutting-edge projects.
- We could be losing the visual (artistic) component, arguably the biggest benefit of traditional IC design flow. A schematic is worth a thousand lines of code. Transferring knowledge with well-drawn schematics is orders of magnitude more efficiently than through code in my humble opinion.
Are we ahead of ourselves?
Here is a good article on the current state of agile hardware development: Does SoC Hardware Development Become Agile by Saying So: A Literature Review and Mapping Study. I believe frameworks like Chisel and BAG are ahead of their time. They could very well be the ultimate form of IC design, but I can’t help but feel there is a missing step in between. Factories become fully automated after assembly line workers follow a manual or semi-automated process consistently first. To me, the entire IC design field hasn’t really reached the assembly line state yet.
Regardless, the agile hardware movement still provides valuable contributions to how we should approach design processes. Codifying IC designs should be the byproduct of the agile hardware movement. Combining with some principles in Eric’s Lean Startup, the following sections outline what we can start doing today towards creating the final IC factories.
Minimum Viable Product (MVP) in IC design
If you haven’t heard it yet, it’s a term made popular by the Lean Startup methodology. In contrast to launching polished products, MVPs are launched with just enough features to run experiments, test the market, and learn from feedbacks. A famous example is Dropbox, whose MVP was just a video demonstrating how the product is supposed to work before a working prototype is ready.
“This is madness! How can we ship MVP chips?” Well, we just have to redefine who IC designers’ customers are before applying the MVP concept. Our customer should be whoever takes our block into the next integration level. If you are building a regulator, your customer is the higher level designer who uses your regulator. If you are a mid-block owner, your customer is the integration person who puts the system together and slaps an IO ring around it. In the case of unfortunate graduate students, you are your own customer.
The FFPPA Pyramid
In order to define an IC product, five meta requirements are usually necessary – function, feature, power, performance and area. People are most familiar with the last three (abbreviated PPA), but I always throw function and feature in the mix. Below is a pyramid depicting what I believe is the typical order of importance for these criteria, with bottom being most important.
The key message here is there exists a pyramid like this for every project (with a slightly different order). We can certainly shuffle around the blocks on top. Some projects might have a killer feature, while others might have non-negotiable power/area constraints. However, FUNCTION should always be the foundation (I once taped out a very energy/area efficient noise generator when I wanted to build an ADC). After we have identified the pyramid, we can start building the MVP from bottom up.
MVPs during design cycle
OK, actually I lied. Your MVP doesn’t even need to functional. Recall from our top-down methodology discussion, symbols themselves already contain enough useful information and could serve as an MVP for your “customer”.
Starting with critical pin definitions is actually the first step toward a functional block. Let’s use an OTA as an example and see how its MVP form can evolve in an agile framework.
Voila! Here is your OTA MVP. You can pass it on to the higher block owner for drawing his/her schematics. Note that being an MVP doesn’t mean it’s a low quality symbol. In fact, we should apply the same standard as if it were the final version.
The MVP’s next version should then have some functions to it, either with ideal models, basic transistor topologies or a mix of both. For a perfectly functional OTA, all we need is an ideal transconductor and a large resistor as its output impedance. The beauty here is that the most critical specifications are already in the model (gm, gain, etc.). MVP here becomes MSP – Minimal Simulatable Product.
Finally, we can start building some real circuits. A natural question to ask is then why don’t we jump straight to this real circuit implementation. For a simple OTA, perhaps the MVP process isn’t that necessary, but the benefits will be amplified for larger scale blocks.
The key advantage of using MVPs is that we barely meet the need the “customer” so that his/her own work can continue. Throughout the process, we maintain a version of the circuit that’s usable in schematics and simulatable to various degrees of accuracy. The same idea applies when layout efforts begin. Layout pin placement is critical for floorplanning; dummy and decap devices can be added incrementally; power down and over-stress protection features could come in next. All these incremental additions happen according to the FFPPA pyramid that we agreed on earlier.
Tape-in and incremental additions
If you feel the example above is too simple to make a compelling point, here is an excellent project by the Berkeley Agile team for a RISC-V processor: An Agile Approach To Building RISC-V Microprocessors.
The figure below taken from the paper should summarizes the essential difference in an agile model. Throughout the entire process, each layer creates an MVP for their own customer layer. For instance, the Design layer only finishes F1 to the Implementation layer, and incrementally adds more features down the line.
My favorite idea in this example is the concept of a “tape-in”. In the authors’ own words, it’s “a trivial prototype with a minimal working feature set all the way through the toolflow to a point where it could be taped out for fabrication”. A “tape-in” is perhaps the closest thing to being a real MVP in the IC design context. In fact, I believe the sooner a project reaches the “tape-in” stage, the more likely it will succeed. The positive psychological impact of seeing a potential path to completion is huge.
Even though AMS design cycles are more manual than digital/SoC flows, the “tape-in” concept is equally applicable. Designers all have a tendency to sit behind closed doors and polish our cherished designs until the last second. However, there is no need to finish all features, include programmability, or even meet power/area budget in one go. Rather, we could constantly push out “releases” of your design and optimize incrementally. This requires no coding but a shift in mindset, which is agile design model’s true essence.
The Power of “Small Batches”
Another lesson in lean thinking is about the power of “small batches”. The line between “lean” and “agile” is a bit muddy on this one for me. Here is the entertaining example Ries used in his book:
A father and two daughters (six and nine) decided to compete on how fast they can stuff envelopes. The daughters went about the intuitive way – label all envelopes, then stamp all envelopes, then stuff all envelopes. The rationale is sound: repetition at each task should make us more focused and efficient. On the other hand, the father’s strategy was to label, stamp, and stuff each envelope individually before moving onto the next one.
The father ended up winning, not because he is an adult, but because of the often overlooked costs in the waterfall approach the daughters took. They miscalculated the effort required moving from one big task to the next, as well as the cost of mistakes found later in the process. Sounds familiar? These are precisely the challenges we face today.
There is no real data to back up the following cartoon graph, but this could very well be what’s happening here. While traditional “large batch” approach is good enough for older designs, it’s evident that we have already crossed a “critical N” line in today’s designs. The crossover that favors “small batch” approach happens when the cost of hand-offs and errors start to dominate in the entire process.
Small batches in AMS design
The agile model in the RISC-V example essentially pushes features into the final design in small batches. When the design process is multi-layered in nature, small batches allow parallelism that creates almost no gap between design tasks. As a result, the same principles should be applicable to AMS designs.
Below is a typical representation of modern AMS design cycles. It has four layers of main tasks, and most of our pain points lie in the layout and post-layout verification steps. As a result, the feedback latency from post-layout results to schematic/layout modifications is too long (i.e. red arrows). Designers’ hands are often “tied” until layout or simulation finishes. Does the code compiling comic above ring any bells again?
Now if we apply the small batch principle to redraw this design cycle, it would look like the following diagram. We can break the monstrously large design cycle into several much more manageable smaller design loops.
It is easier said than done. We as designers need to develop a new skillset to create such a collection of small loops. We need to create schematic hierarchies with clean interfaces, understand dependencies among sub-cells, and most importantly have a good feel about layout and verification efforts. Like all skills, designing circuits with small batches require constant practice, from block to block, from tape-out to tape-out. When done right, the efficiency brough by the small batch approach is so so sweet.
Final Thoughts
I just finished a tape-out at the time of writing. Did I follow the lean/agile principles I wrote about here? If I were honest, no.
We are all creatures of habit, and the bad ones stick around the longest. I plead guilty for sometimes getting carried away in making non-MVPs in large batches. Nevertheless, there are other times when lean/agile methodologies help save huge efforts and resources when the unexpected happened.
Like all of you, I am continuously learning and trying different ways to become a better designer. Lean and agile principles have found their roots in modern design methodologies. They proved to be valuable in reducing design wastes and handling changes. I look forward to hearing about your design methodologies. The day when we all agree on a systematic design flow is the day we can truly start codifying IC designs.
