To Wrap or Not To Wrap – How To Use Schematic Hierarchy To Enhance Design Productivity

It’s non-trivial to decide when a new schematic hierarchy is necessary, and everyone is self-taught in this regard. It’s an important decision but an early investment that’s often overlooked. In this post, I will share some ideas on when and how to create schematic hierarchies so that your design flow can be more efficient.

My personal guideline is to always check the top schematic crimes (to mimic the late Prof. Patrick Winston in his “How To Speak” lecture), each of which could be prevented or solved by creating symbols and hierarchy in your schematics. They are not mutually exclusive and could often happen at the same time. Let’s see how wrapping up your circuits can help.

1. The “too flat” crime

The “too-flat” crime happens when there are too many primitive circuit elements or circuit blocks and the circuit’s function is not easy to tell anymore (even by an expert eye). We were taught not to draw an op-amp’s internal circuits again when we use it in other schematics, but somehow we forget to do so for other circuits when their symbols are not pre-defined or readily available. This crime can also be committed unintentionally when you begin with a simple circuit, but then keep expanding until it’s lethal to the eyes. My suggestion is to ALWAYS use a border sheet and use it as a rule of thumb on when new hierarchies should be considered. I tend to avoid going above a D-size sheet, and try to contain most schematics in a B/C-size sheet. Otherwise, it usually means the schematic is too flat, even for a higher level circuit block.

2. The “too hard to change” crime

Imagine you are drawing a circuit that copies a reference current and produce bias currents for all other blocks. You rolled up your sleeves, pulled out the best current mirrors you know, and sent the gate bias to many devices. You pat yourself on the back and said to other designers “I got you covered”. The next day, you are asked to add more outputs, add a power down and trimming options to each branch, and improve these current sources (e.g. increase output impedance, reduce mismatch, lower noise, etc.). All these changes require you to either modify the device sizes or add new devices MULTIPLE times. You may run into crime #1 if you start changing things blindly.

What may seem to be a redundant step of creating a symbol for your unit current source (even if it’s a single device at first) can save you from tedious changes later in the design phase. Now when changes are necessary, you only need to do it ONCE inside that nice wrapper (the same goes for layout. Your colleague will buy you coffee for doing this).

It almost seems obvious when it comes to coding – if you run a routine more than once (however simple it is), wrap it up in a function. So let’s treat your circuits as modular functions and place and drop onto your schematic canvas.

3. The “wait for layout” crime

Designing the circuit (including schematics and layout) is probably 20% of the work, and the rest goes to simulation and verification. For modern CMOS technology, the design cycle becomes much longer due to the increased layout complexity. There have been numerous solutions proposed to address this issue. Some examples are using look-up table based design methodology that includes some pre-simulated layout effects (e.g. ADT by Master Micro) and better EDA tools focused on parasitics (paragonX by Diakopto).

While these tools are fantastic, I believe as designers we should make our lives easier starting at the very first schematic building stage. Let’s take a simple CML amplifier, consisting of a tail current source, differential gm devices and resistor loads. You pass along the schematic to your layout partner and begin waiting because you can’t simulate anything until every component is done and put together to pass LVS. The process takes longer than you think because a very weird DRC violation forces you to re-floorplan. When the layout eventually comes back and the first SPICE simulation doesn’t show promising result, you don’t quite know where to start debugging because the layout is already “too complete to take apart”. If this sounds familiar to you, you are not alone. I encountered many similar challenges when I first started IC design, especially when dealing with new technology nodes.

Now let’s break the problem into smaller pieces by wrapping up different portions of the amplifier. Right away you can see how this addresses the issues mentioned above. You don’t need the whole thing done to simulate something meaningful. If you care a lot about device matching, have the differential pair done first. If bandwidth degraded significantly when everything is put together but not when each part is simulated separately, then you know the problem is in the higher level metal connections. This way of drawing schematics also encourages reuse in other circuit blocks, thus cutting the “wait for LVS” time.

It’s not a new concept. In fact, the agile software development paradigm already adopts this incremental development method to allow more iterations and “fail often and early” mentality. Prof. Elad Alon has proposed the idea of agile hardware development before, but focused more on using software generators (e.g. Blue Cheetah). What I believe is we can still bring in a human touch by using agile thinking when drawing schematics, keep ourselves entertained, and achieve similar results. When it comes to both schematics and layout, we need to draw smarter, not harder.

4. The “fish bone” and “solder dot” crime

This is a easy to understand but sometimes hard to avoid crime. Systems with complex programmability and feedback loops often make us draw wires that are crossing each other. Schematics will begin to have fish bone patterns, and soon connectivity becomes hard to track. Most people are aware of this problem, but solves it with the next crime (“connect by net name”). Creating new symbols can help because you can now redefine the pin locations and hide some crossings in a new hierarchy.

Here I also want to discuss solder dots, because crossing wires can sometimes create unwanted ones. Mainstream schematic capture tools have definitely gotten “smarter” over the years on how to reroute your wires when you move circuits around, but it’s far from perfect. I can still get a few unwanted connections when things move, and it’s usually solved by better symbol pin placements, more direct wire routes, and more better solder dots connections. My three tips on solder dots for more readable schematics are

1. Minimize number of right angles on a net (Use T-shaped connections)
2. Use either the double or diamond solder dots to emphasize branching
3. Order your pins to line up solder dots diagonally in Manhattan wiring whenever possible. This can reduce # of crossings and save some real estate in a bigger mesh.

5. The “connect by net name” crime

We all have committed this one, and probably will continue. Sometimes it could be impossible to connect all pins with wires so I might downgrade this one to a misdemeanor. We also connect by net name somehow believing that it’s quicker. Raise your hand if you are tired of a schematic that looks like this

When net labels become invisible to the human eyes and are only for machine consumption, I question the value of putting them there in the first place (especially for higher level blocks). The pin names should already be sufficient to tell what each net is. Debugging the connection become exhausting when you need to highlight these nets. To quote my Ph.D. advisor Boris Murmann, “I’d actually prefer a netlist that describes the connectivity”. When building such schematics, typing in all the unique net names probably consumes the same if not more effort than grouping the left two blocks and creating a new symbol to align pins like below. Another benefit of adopting such a style is that it forces you to think early about the interface between multiple blocks, making functional checks less error prone. This comes very handy in large mixed signal systems, which we will discuss in future posts.

The flip side of the coin is deciding when not to wrap. We certainly don’t want to create unnecessary hierarchies because it takes time to make one and descend into one. From my limited experience so far, it’s hard to come up with some good rules because each design is different depending on legacy block reuse, layout change complexity, and frankly your colleague’s habits as well. We should, however, start discussions, share experiences and exchange ideas. I look forward to hearing about your thoughts on drawing schematics and creating hierarchies.