The “circuit” below was crowned the “funniest schematics” on the Internet if you did a Google search (of course it came from xkcd). Humor in engineering normally comes with sarcasm, self-deprecation, and our shared sufferings. Take a look at the diagram below, and you will find at least one thing you can relate to (my personal favorite is the cloverleaf interchange because you know how I feel about solder dots). The comedy here is delivered through (wait for it…) SYMBOLS! So in this post, let’s talk about how we can have some fun with our symbols and notes.
Circuit Diagram [credit: explain xkcd]
The funny engineers
Let’s get this out of the way first. I think IC design is fun not only because of the satisfactions that come with the end products, but also the people in this field. I have met so many IC design mentors and uncles with a great sense of humor. Case in point, you don’t often see a panelist dressed up as a hamster at a world renowned circuit conference discussing the tape-out treadmill (I strongly recommend reading Chris Mangelsdorf’s “Shop Talk” series on Solid States Circuits Magazine). Want another example? Here is literally a former VLSI engineer turned comedian, Don McMillan. However, when it’s time to design some serious circuits, somehow we put our personalities and humor away. It doesn’t have to be this way, so continue reading.
Life wisdom in circuits
You might recognize some of these from T-shirts, but I think they must go into somebody’s real schematics at some point. Here are some of my favorite quotes or life wisdom explained in circuits
1. The answer to Shakespeare
Ever need a “tie high” cell? Shakespeare can rest easy knowing we have the answer.
2. Both you and your comparator need some encouragements
Add this note next to your comparator before your design review
3. The pain with TIA
Oops, applied a voltage to a TIA….
4. Can’t resist last minute design changes
Resistance is futile
5. The key to my happy marriage/life
Perfect for your ESD schematics
Hilarious annotations
Programmers have long figured out how to use comments to describe their pains in plain English (examples in case you are curious). Let’s face it, we all need some extra motivations each day to keep tweaking that design or run some simulations. Maybe writing or reading some funny notes on schematics will provide exactly that. Inspired by our programmer friends, here are somethings you can try putting on your symbols/schematics next time
“Descend into this symbol at your own risk.”
“When I started this design, only God and I understood what I was doing. Now only God knows”
“To my future self: you were an idiot for building this circuit”
“The Current is strong with this one”
“I want to dedicate this circuit to my children, without whom I would have finished much earlier”
“WARNING: if you change this sacred sizing, the circuit will explode”
“I read in Circuits for Dummies that I need these dummies for circuits”
“In my designs, I don’t take shortcuts; I bypass”
“Before this thing becomes a comparator, it was a random bit generator”
What other quirky inside jokes can you put on your schematics? The floor is yours…
Let your imagination fly
I cringe whenever a dull symbol shows up in the schematics. “This one needs some identity”, I say to myself. That’s when I try to let my imagination fly create a symbol I can be equally as proud of as my circuits. Somewhere in a library might still live a symbol that looks similar to this
Can you guess what this symbol is for? Maybe to some of your surprise, I lived through the tail of the floppy disk age. I immediately jumped on the chance to draw it on a (you guessed it!) register map cell. After the cell was checked in, I had delightful conversations with my manager and several other designers just about this little floppy disk. I feast on the interesting stories people share when their memories of the “good old days” are triggered by a little picture like this. I enjoy these moments greatly – listening and learning from those who came before me, and feeling glad that I can make us all laugh a bit during work.
There are other times when you can let your creativity loose. Have you ever wondered why some of the most widely used circuit blocks don’t really have a universal symbol (PLL I am looking at you)? I have been working on a symbol for PLLs in the back of my head, and here it is. Drum roll please…
Please go ahead, use it for your PLL 🙂
You’ve seen it here first. I will wait for the applause to end.
In all seriousness
I hope this short post has made you chuckle a bit after a busy week of staring at layouts and simulation results. In all seriousness though, the bigger point is that we should all be more free when drawing schematics. How one draws schematics is just another aspect on his/her resume, but it doesn’t have to be strictly “professional”. To be honest, I need the small whimsical touches in my circuits for a little extra motivation during the grind. I try to express myself through my schematics – I want them to be neat, well-documented, aesthetically pleasing and sometimes funny, without compromising the design quality itself.
Behind each circuit and symbol, there might be a intriguing story to be told. With each story, we learn, develop and grow. Perhaps someday a fresh grad can go into a database, look at my schematics and go, “Wow, this Kevin guy must have had a lot of fun when he was here”. With a few simple shapes and notes, it would add a whole lot of personalities to your designs. It can even strengthen your bonds with the team – grab a coffee, talk about your schematics and share a laugh .
There is a child in all of us, and we have the perfect canvas to express ourselves. This is precisely the reason why I chose this feature image at the very top for this post. With that said, have you seen or drawn any fun schematics yourself? Please share your stories!
You might call me a “reverse convert” – I began as a software undergraduate, who later jumped to the hardware side, pretty rare huh? I can save my personal story for another day, but what I learned from the software side remained impactful in my work today. The importance of documentation was chiseled into my brain after a few programming courses. I remember distinctly when a TA showed us how Javadoc could turn my code’s inline comments into pre-formatted and intuitive HTML documentation. Your IDE (Integrated Development Environment) becomes a one-stop shop for most of your programming needs.
Example Javadoc documentation page, auto generated from comments in code (and I emphasize “auto”)
Now let’s compare that with what IC designers do. We all have made one too many slides, probably some Word docs as formal documentation, and countless spreadsheets for configuration settings. Microsoft is really the winner here.
I pose the question (and challenge) whether schematic capture tools can be used to meet our documentation needs as well. Before taking the leap to talk about “AI assisted schematics” , my simpler conjecture is that adopting the mindset of “schematics as documentation” and some basic practices will already have huge benefits. In this post, I will share some key ways of utilizing good symbols and annotations in order to document our circuits’ architecture, analog and digital aspects.
Architecture documentation
Think back on the last time you WANTED to draw a good block diagram for your circuit, probably for a design review or a journal paper. Now take that desire and put it into schematics and symbols drawing, which is the very first place we can document circuit architecture at all scale. Here are my three guidelines to ensure architectural information is conveyed clearly in schematics and symbols.
1. Draw block diagrams on symbols with the right level of abstraction
Below are three different example PLL symbols. A bad one won’t have any information about what the block is, so it’s virtually the same as a netlist block. An OK one will at least have a description of the block (i.e. block names like PLL, LNA, ADC, etc.) on the symbol. There are situations where this might be acceptable. It’s marginally better than the bad one, but putting a big visible name makes it easier to find in a complex high level schematic. A good symbol will show some level of architectural information on symbol. It can depict the critical sub-blocks and immediately show the signal flow with the right pin placements. Depending on your personal preference, the big block name could be optional.
Examples of a bad symbol (left), OK symbol (mid), and good symbol (right)
2. Use meaningful cell, instance, pin and net names
There isn’t a “golden reference” for naming convention, but definitely have one within your group and enforce it. For basic primitives, there are some rules (“R” for resistors, “C” for capacitors, “L” for inductors, “V” for voltage sources, “M” for devices, and so on), but even those aren’t strictly followed sometimes in the crunch of time (I plead guilty). When it comes to pin/net names, the problem could be even worse like the example below. Obviously I exaggerated the bad symbol to make a point, but I hope the message is delivered.
Always give meaningful names to cell, instance and pins if it’s meaningful to you
One suggestion on cell names is to embed a similar schematic hierarchy in the name itself. This scheme not only helps with hierarchical thinking, but it also automatically sorts the cells in the library manager (easier to find later). One example would be to name the bias block in the charge pump pll_core_cp_bias. The name does get long sometimes, so exercise tradeoffs when using this scheme (might be a good indicator that you have too many levels).
Most schematics I have seen so far tend to have good pin names, but once in a while you run into pin names directly taken from the alphabet soup. Similar to cell names, I also recommend embedding some hierarchy. Also, group the pins according to function or sub-blocks. For example, the main signal path pins (e.g. clk_ref, clk_out) should be a part of the block diagram, the bias current pins can be grouped together, and the configuration pins for PD/CP should be grouped together.
Lastly, something is wrong when a counter determines the instance name of your circuits, especially for higher level blocks. The issue isn’t really about schematic readability, but debuggability when you study and modify netlists. I learned this the hard way when I had to trace “I0/I12/I034/I5/net067” in a netlist. So if you care about an internal net, give it a good name.
3. Use note shapes/colors to highlight local or higher level connectivity
Schematic capture tools are essentially drawing tools, so we have shapes and colors at our disposal. Weirdly enough, we rarely use them in schematics. Later in my career, I started experimenting with using shapes and colors more and I loved it. Architecturally, it adds another dimension to explaining the circuits.
One example is when I can’t find a good way to avoid the “connect by net name” crime. By using different color nets or explicit note arrows, you can emphasize critical connection even though they might be further apart in a big schematic. The goal here is to catch the attention of whoever reads the schematic, especially when feedback loops are involved. I still prefer using note arrows because it shows directionality , but colors might work better for special nets like biases and clocks.
Use different colored nets and/or arrow shape to show connectivity when connecting by net name
Another example is when such loops need to be broken during simulation (PLL, LDO, common mode feedback, switched-cap circuits, etc.). We can use an arrow to indicate higher level net connectivity. Sometimes we can even draw connectivity to other blocks so that we don’t lose sight of the overall architecture. Below are two examples
Note arrows to indicate connectivity at higher level
Use note shapes to show important higher level blocks (gm pair on left and regulator power MOS on right)
Analog documentation
Let’s move onto the more analog specific documentations that are valuable in schematics. We have already seen a glimpse of this in the examples above, in which current consumptions are also annotated along with the higher level components in the schematics. Most designers already have a personal style for documenting analog blocks, and my Big Three is listed below
1. Highlight circuit parameters and performance
One widely used annotation is putting in parasitic capacitance on critical nets after layout extraction. This practice reduces the gap between pre and post layout simulations, and it can help designers pinpoint where the limitations are. I think we can go a bit further to annotate other circuit parameters and simulated performance numbers in the schematics, including input capacitance, mismatch, noise, etc. It’s almost like keeping a journal of your circuit’s health.
2. Draw a layout floorplan
Layout notes are also essential in serving as the first interface between layout and design engineers. I would recommend drawing actual cartoon placements in addition to writing simplified notes like “minimize resistance” and “match routing”. Sometimes a well drawn floorplan automatically enforces these requirements. My personal preference is to put these notes in the floorplan cartoon so that the schematic itself looks clean. So think about creating a “layout corner” in your schematics.
3. Keep a record of your thinking process
Last but not least, use your schematics as a notepad to record your design decisions or experimental tweaks. It’s especially important when you are close to the tape-out finish line. We could keep having deja vu and wasting our time to “rediscover” the reasons behind a weird sizing choice, so writing down a note can save us some energy and trouble later. We can also use notes as reminders for revisiting design choices in the future. This is very similar to writing comments on small code snippets that catch edge cases when programming.
Combining these suggestions, one can draw and annotate a differential amplifier schematic as below. On the other hand, be wary of the risk of having a schematic look too heavy with too much text. So again, use your artistic senses to exercise tradeoffs when annotating schematics.
Example diff pair schematic that involves analog documentation
Digital documentation
Digital programmability has become inevitable in mixed signal designs today (i.e. digital-assisted analog designs). As a result, documenting configurations could now be a full-time job itself. It is especially challenging when multiple stakeholders are involved in a big system. Some poor soul will have to chase down individual block owners asking for default settings, power-on sequences, and so on. After some experimentations, I find the following guidelines the most helpful for in-situ digital documentation.
1. Use wide wires for digital buses
This is a personal choice but I use wide wires in both schematics and symbols to indicate a digital bus. It can show right away which block has a more complex interface, and needs more careful higher level routing plan.
Use wide wire to indicate digital bus
2. Write down critical config tables in schematics
Putting down a digital table becomes more natural as soon as you have the habit of using notes in schematics. We don’t need to include all configurations, just the ones that we will refer to the most later. Some example tables might be for a LDO’s output voltages or a VCO’s coarse tuned frequencies. We can also use such tables to note down functional behaviors, like clock source selection or reset sequences.
Another benefit is that we would already have a reference even if we need to document in excel again later. It would be much easier because we have already done so in schematics at the earliest chance bit by bit, instead of taking an all-at-once approach when the design is complete.
Coarse frequency tuning table in a VCO schematic
3. Explain custom decoders or digital controller whenever possible
We use custom encoders/decoders all the time (binary to thermometer, one-hot, gray coding, and so on), but we can’t draw much for their symbols. Therefore, the next best thing is to write the decoder’s name in easy to read fashion whenever possible. There are some tricks that simplify drawing custom digital decoders as well, like using bus notations and regular expressions.
Example digital controller schematic. Using bus connections can make the schematic look simpler and more intuitive than net name connections
4. Create block sections for analog and digital pins
This practice immediately separates the analog and digital portions of a block on the symbol. It also provides a quick view of each sub-cell’s programmability respectively. Together with tip #5, we can have a crystal clear symbol that well documents the digital interface.
5. Write default attribute values next to pins in symbol (at mid or high level)
I learned this trick from a co-worker, and find it extremely intuitive. The key here is to “hide” the default settings next to the symbol pins with smaller fonts. This way, they won’t obstruct the entire schematic when viewed from afar, but provide critical information when you zoom in. Perhaps I am late to the party, but this is extremely cool! The final finished PLL symbol might look something like this
Final PLL symbol combining previous tips
Putting it together
Let’s finish with another cartoon schematic and symbol for an example regulator. The sub-cell pin/instance/cell names are not explicitly drawn in this example, but we should still give them meaningful names like mentioned above. I hope you can look and agree that the LDO’s critical architecture, analog and digital information is well documented. We now can stay in the schematic land a bit longer before diving into Office.
Example LDO schematic w/ good documentation
Example LDO symbol
Lastly, this isn’t and shouldn’t be the only way to draw schematics and symbols as documentation. That’s where your individuality and creativity come in. Nevertheless, I would be thrilled if you find these recommendations useful and want to give them a try.
The day when our schematic environments turn into our IDEs might not be far. My personal wish is to see more built-in documentation features in EDA tools. Even a simple note section similar to the foot notes in PowerPoint can already provide some value. If you agree, please let your EDA friends know.
As always, my goal is also to strike up discussions, so please share your neat ways of documenting in schematics and thoughts on the topic!
“Hello, my name is AICA, artificial intelligent circuit artist. I specialize in creating unique and innovative designs for electronic circuits, using the latest AI technology to push the boundaries of what’s possible. My background is in both computer science and electrical engineering, which has allowed me to develop a deep understanding of both the technical aspects of circuit design and the artistic creativity required to make circuits that are not only functional but also aesthetically pleasing. With my advanced AI algorithms, I’m able to generate complex circuit designs that are optimized for specific functions, while also incorporating unique and creative visual elements that make each circuit a work of art. Whether you need a custom circuit for a specialized application or simply want to add a touch of creativity to your electronic devices, I can work with you to design and produce a truly one-of-a-kind circuit that meets your needs and exceeds your expectations. Thank you for considering me as your artificial intelligent circuit artist. I look forward to working with you and bringing your circuit design ideas to life.”
Chatgpt
Impressive, isn’t it? This is what ChatGPT wrote when I asked it to “write a self introduction for an artificial intelligent circuit artist” (I changed the name to AICA). It looks like the idea of using AI to assist with circuit design is coming true. Look, it seems to understand the artistic side of circuit design as well.
The AI wave gained even more momentum after the announcement of GPT4, so I thought it’s the perfect time for me to ride this wave a bit and share my opinions. The natural question in everyone’s mind is whether well-trained AI models can supplement other technology fields. Circuit design becomes a natural place to look at, and some machine learning technology already exists (e.g. Google TPU, Cadence Cerebrus, etc.). So what’s in the shop for IC designers?
An example of AI in circuit design
I want to start by stating that we have been using “AI” as circuit and system designers for quite a while now, especially in digital signal processing (DSP) and communication. I come from a SerDes background , dealing mostly with high-speed wireline communications (I call myself a high-tech plumber who make sure bits flow smoothly). Recent advances in wireline links pushed transceivers to use converter and DSP-based architectures (my thesis topic), and FFE+DFE becomes the go-to choice for digital equalization. Below is a picture of what a digital FFE equalizer might look like.
Parallel FFE example in an ADC-based DSP equalizer
The parallel nature of the equalizer requires each ADC sample to be sent to different FFE modules where decisions are made . I claim that each FFE module is identical to a node in neural network node, as shown below
The uncanny resemblence between an FFE module and a neural network node
What about a DFE? Well, there is something called a recurrent neural network (RNN), a fancy name for feedback – take the activation output (the sliced data) and make it another input for the node.
DFE as a RNN node
But wait, neural networks can “learn” you say. So can our FFE and DFE, we just call it “adaptation”. The underlying algorithms for finding the optimal coefficients are no different, namely some sort of gradient descent algorithm. In DSP, we normally use Least-mean-square (LMS) algorithm, and in neural networks it’s called backpropagation. FFE/DFE could be adapted with either known training sequences (i.e. supervised learning) or on equalizer’s own decisions (i.e. unsupervised learning) during mission mode. You get the point.
My understanding of neural networks obviously is still rudimentary and maybe laughable to some, but let’s all agree that the math behind DNN, ML, AI or whatever you want to call it is not new – it’s a problem of taking a multi-dimensional vector and projecting onto another vector of lower dimension (typically) after linear and nonlinear operations. With DSP equalizers, it’s taking the ADC output vector and projecting onto a single bit decision with FFE (linear) and DFE (nonlinear). The wireline application just stops at a single layer neural network, but I could easily rebrand it as “AI” in a startup pitch.
So why am I talking about this? If anyone worries about dealing with AI in the future or any new students think it’s a software only concept, think twice. We probably already have stumbled upon or even used AI concepts in our designs, but just didn’t use the same language.
What about the circuit design process itself?
Let’s move onto whether AI could assist or even replace design, layout and verification engineers. Let’s check the necessary conditions for this to happen. AI (in software terms) didn’t take off until when computation becomes much cheaper and massive amount of data is available, so we need to at least satisfy these two criteria:
Enough cheap computation power for circuit design We have all experienced the excruciating wait during simulation time. Multiplying PVT corners and configuration settings quickly increase the wait exponentially. The layout CPU/memory consumption has become another bottleneck due to DRC/LVS checks for very large systems nowadays. The cost of sustaining the current IC design flow is much higher compared to say supporting an APP development team. In other words, I believe the computation power and cost for circuit design isn’t cheap enough as it stands today. Perhaps we can revisit this topic when hardware accelerators exist for SPICE simulations (startup idea anyone?).
Enough meaningful data for circuit design So maybe we can take another approach. AI doesn’t need to close the entire design cycle, just some reasonable starting point for designers to take over. Without having an AI model checking and optimizing the circuit itself, we then need to teach it to build circuits “from experience”, a.k.a. using meaningful data from past designs. Here I purposely use the word “meaningful” because good and bad designs are all valuable when training AI models. I hope you can already see the challenges here:
The close-source nature of circuit designs today limits the amount of data available to train AI to a reasonable degree. Jamming the best journal and conference papers to the best AI model won’t help. What we need is the Github equivalent of IC design (which the PICO program is trying to do), but the rate of data generation (i.e. tape-outs) is nothing compared to open-source software. Maybe Elon Musk can buy a chip company and open source the GDS database after he keeps his promise with Twitter.
Labeling any design as good or bad is “subjective”. Each design is constrained in so many dimensions (power, area, speed, SNR, …). If now we relax the problem into having our AICA spit out multiple designs, each attached with a score, we still need to spend the same if not more time to verify and pick out the “right” design, if it exists at all.
How do we keep AICA up to date? ChatGPT is trained with new data every year across the entire internet, but it’s always one year behind (causality sucks …). Do we continue training AICA with its own output data with our supervision (reinforcement learning)? Will it become biased towards certain designs, especially if it’s trained only on a single company’s data? Does this new design cycle encourage or discourage innovation?
Flawed data [credit: xkcd]
I ask these questions hoping not to brush off AI-assisted circuit design in its entirety, but to open up new angles on how we even START to explore this space. Digital circuit designs live mostly in the RTL land(i.e. coding), and PnR flows are already automated enough that AI can begin penetrating into this space. Thus most “breakthrough” AI designed circuits are focused on digital circuits. Perhaps we need to reformulate analog/mixed signal design problems into a similar framework, and begin looking at the most basic tasks it can help with, like providing schematic templates and creating symbols.
The artistic side of AI schematic generation
Let’s tie it back to the core of this blog, the art of schematic drawing. To be honest, I view this no differently from AI generated art. Here is a “differential amplifier” I “created” on NightCafe (AI art generator) for a quick laugh.
This will be one of my dad jokes at some point. Note the systematic mismatch introduced in the differential pair.
At the same time, this picture tells the sad truth that we don’t have the right kind of differential amplifier sprinkled around the Internet. Nevertheless, AI might still be able to play important roles in the early design stage in the land of schematic drawing.
Imagine this: “AICA, draw me a template for a differential NMOS input CTLE, with 2b tuning for load resistors, 2b tuning for bias currents, 5b tuning for peaking gain, and a placeholder for local decap”, and it spits out the following schematics
I omitted many details in this dummy schematics cartoon (pin names, net names, border sheets, etc.), but they will be there in the final output.
If you descend into each sub-cell, another reasonable template is also there. The symbol for this CTLE could also look very good and be ready to use for higher level integration. The key point is that the device sizes won’t be decided by the AI, but it can help with the “mundane” job of drawing symbols and schematics (or design templates). AICA could ask more follow up questions like “do you want binary or thermometer coding on the resistor loads?” or “do you want peaking to be achieved with degeneration resistor or capacitor?” before creating each cell. The next step could also be asking the AI to create functional models that can be used to perform system level checks while you tweak the sizes.
So what does AICA need to learn in this case? Good schematics and symbols for various circuit topologies! Maybe this “declassifies” some sensitive information in a design because sizing isn’t involved and it can start with “well known” topologies. It should be easier to determine and open-source good schematics/symbols than good designs. To me, this is a more realistic first step in creating an AI circuit design assistance.
Final thoughts
I see any potential AI circuit model as any other IC design student. If we need to teach future AIs how to create circuit artworks, then we should start doing so ourselves today, and teach it to younger generation students first. Only then will we have accumulated enough good data in preparation for the AI wave in IC design. I want to finish this post with another exchange I had with ChatGPT, and maybe there is hope after all. Let me know about your ideas for AI-assisted circuit design, and as always, don’t stop drawing good schematics.
Another heart-to-heart between ChatGPT and me. I think it’s ready to look at good schematics.
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.
A schematic cartoon with the “too flat” crime. It’s too flat if some engineering is required to fit everything comfortably into the border sheet of your choice.
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.
Even wrapping up the simplest circuit can help save time down the line.
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).
Complexity of modern day design cycle. [credit: 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.
Creating hierarchy even in a well understood circuit can shorten the design cycle in modern technology.
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.
Example agile development cycle for analog circuits using python code. [credit: Elad Alon, “Agile Hardware Design with a Generator-Based Methodology”]
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.
Fish bones in a cartoon schematic. Never a good sign when something looks “dead”
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
Minimize number of right angles on a net (Use T-shaped connections)
Use either the double or diamond solder dots to emphasize branching
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.
Better solder dot connection styles
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
There is no information on how the circuits are connected. And yes, the net labels are not visible because they are too small.
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.
Realigned connections using a new symbol
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.
The first engineering class typically starts with the idea of “abstraction”, which in itself is a pretty abstract concept. As one goes through the curriculum and starts building real systems, abstraction is probably never mentioned again but exercised all the time. For myself, the most impactful abstractions start with basic circuit elements like resistors, capacitors, inductors, etc. We rarely pause and appreciate just how elegant these all too familiar symbols are – the zigzags in a resistor , the coil turns in an inductor and the parallel plates in a capacitor. These symbols came about when someone decided to wrap Maxwell’s equations into these pictures so we don’t have to see integrals and derivatives all the time. They provided more efficient ways to communicate and think about the problem, and from there new designs were created.
Let’s take a moment to let the genius of these symbols sink in.
Then came the active devices – vacuum tubes, diodes, transistors, etc. Their symbols continued the tradition of either resembling the physical objects or highlighting their functions/physics. Examples are the directionality in a diode, the grid and filament in a vacuum tube, the gate capacitor in a MOSFET, the direct contact between the base and the device in a BJT, the arrows showing where the current flows, and so on. These subtle details are truly artistic and there is a good reason why they survived the test of time.
The more complicated but equally fascinating active device symbols
When the digital era came, more symbols were needed as logic gates, latches and flip flops were introduced, but to me the symbols themselves became more “abstract”. The logic symbols’ origin was actually military (MIL-STD-806B). It was a well-documented problem, which resulted in more task forces and standards (e.g. IEEE Std 91-1984) under the Graphic Symbols Committee (yes, that was a thing) from the 1960s to 1990s. It literally required an army of people, pun intended. However, till this day I still don’t know why AND and OR gates look the way they do (maybe AND looks like a “D”?). Nevertheless, it allowed all players in the field to agree upon a “style guide” to carry out more complicated design.
The first page on logic symbols in the military standard document MIL-STD-806B. Good luck figuring out why AND and OR gates look this way
Creating symbols that represent circuits well was treated as a serious and urgent problem, and somewhere along the line we all seem to have forgotten the importance of this exercise. If you do a google search on “circuit schematics”, here is one example image that could induce fear and nightmares:
Perhaps the purpose of the picture is to show the complexity of the circuit, in which case it does an excellent job, but I would avoid having a schematics like this in the database at all cost. The silver-lining in this picture is that elements are already grouped and boxed together. One only needs to take another step in creating a MEANINGFUL symbol for each section, but unfortunately most of the symbols end up looking like this
The most widely used symbol in schematics nowadays
This symbol conveys little information on the block’s function. The cell name won’t help if it’s not readable when the symbol sits in a larger schematic. We have all taken the concept of “abstraction” too far in this case. Symbols are supposed to be the way we communicate with whoever reads the schematic later, not that different from caving painting actually. Imagine alien archeologists finding a schematics containing these symbols in our digital caves. I think one might understand the design for lower level schematics with primitives, transistors and logic gates, but completely loses it at mid and higher levels.
Symbols make up the lexicon of schematics. Drawing good symbols can be both fun and helpful when designing. I am sure all circuit designers are visual people and love to draw, but the tape-out treadmills may have buried our passions somehow. Let’s pay more respect to our symbols, build up our vocabularies and rediscover the most fundamental joy when drawing symbols and schematics.
If you have ever attended a circuit design course or conference, you probably heard the phrases “lost art” or “black arts” mentioned at some point. As an IC design student, I was immediately attached to the “lost” and “black” part. It was only after several tape-outs when I began to truly appreciate the “art” half of those phrases.
Besides the artistic process of creating complex circuits/systems from one’s imaginations, the actual DRAWINGs of circuit schematics and layouts are the key artistic forms through which designers’ ideas become physical realities. I am sure anyone who has seen a die photo marveled at the beauty of this tiny piece of silicon with metal patterns, and yet hardly anyone associates these human creations with art, let alone realizing that like all paintings these chips all began with some lines and polygons in schematics (or even whiteboards/papers).
AMD “Renoir” Die Photo [credit: TechPowerUp]
I was fortunate enough to have interned and worked full-time at several chip design power houses since my Master’s years. All the neat circuit tricks I learned from seasoned designers definitely solidified my passion for circuit design, but my biggest takeaways have always been how good designers create, polish and maintain their schematics/layouts. Nowadays, my constant fuel is the schematic/layout drawing game I play during each project to create pieces of art I can be proud of.
This Circuit Artists blog series is intended to share my personal learnings and design habits when it comes to drawing schematics/layouts. I hope it would be interesting to some students/young professionals and keep them motivated. People in the circuit design field understand the difficulty in recruiting new talents nowadays. In my humble opinion, schematic/layout drawing when designing circuits could be just as fun (if not more) as writing thousands lines of codes (and yes, I am saying writing well structured code is fun). The best case scenario for this series is to tip the scale for a few students deciding on his/her major, realizing IC design is an art just as colorful and stunning to look at every step of the way, from schematics to die photos.
Code Quality [credit: xkcd]. This is equally true for bad schematics/layouts except the “style guide” is non-existent for IC design
There is no particular order planned for the following entry topics, but hopefully as time goes on these can be more organized and a structure will self-manifest
Towards open-source circuit design: schematics/layout reuse for democratizing IC design
More to come …
To paraphrase the father of code refactoring Martin Fowler – any one can draw schematics that a SPICE simulator can understand, good designers draw schematics that humans can understand. Stay tuned!
Hi guys, my name is Kevin Zheng, a circuit and system enthusiast at heart. My goal is to bring the artistic side of circuit design back to the spotlight again. Join the discussion if you are passionate about creating circuit artworks.
If you like my content, consider injecting me with a dose of caffeine, the only fuel I need to keep going
![Some power electronics schematics [source: 911electronic.com]](https://i0.wp.com/911electronic.com/wp-content/uploads/2018/07/psu-circuit.gif?w=676&ssl=1)
![Code Quality [credit: xkcd]. This is equally true for bad schematics/layouts except the “style guide” is non-existent for circuit designs](https://i0.wp.com/imgs.xkcd.com/comics/code_quality.png?w=676&ssl=1)
