Category: Tips & tricks

Yes, you read the title right. If you haven’t seen or used metal resistors (a.k.a. metres, rm, etc.) in your schematics, I hope this post opens a new door. Most modern PDKs already include metal resistor cells in the library. If not, you could create your own with CAD team’s help (if you have access to one). Normally, we work hard to avoid metres because they show up uninvited and mess up everything after extraction. However, they can be extremely helpful when placed properly, especially for simulation, testing and documentation purposes. In this post, I will explain in more details how to effectively utilize metres in these areas.

Some wires deserve a name

Metal resistors have been around for a long time. I only began using them more heavily when finFETs came about. As explained in another post, layout and parasitics are now dominant factors in a design’s success. Therefore, many routing wires need to be scrutinized just like devices, and they deserve to have dedicated cells.

The easy example we can all agree on is on-chip inductors. Although many PDKs come equipped with inductor pcells, we probably still end up drawing our own. There are many methods to deal with inductor LVS (black boxing, creating pcell, etc.), but my current favorite is to use metal resistors. These schematics are boring to say the least (the resistance is negligible, often <<1Ohm and essentially a short), but they will pass LVS as is without any funky setups. To simulate, you replace it with another schematic view generated from your favorite EM solver, be it an inductor model or nport model. The possibilities are endless: a similar schematic can apply to transmission lines as another example.

Perhaps my favorite use case is for creating a standalone routing cell for a critical net. This happens the most when a signal need to branch out and reach multiple destinations. Metal resistors can help define this design intent early on (especially if you have already experimented with the floorplan). This is just another aspect of the “draw it like you see it” mentality. The example shown below is for a simple clock route, but you can easily expand this to be a distributed or tree structure. Note that the schematic could be “less boring” now that I added some parasitic capacitors to both supply and ground.

Let’s compare the two schematics below. On the top is a straightforward one showing a clock buffer driving the signal to the top and bottom buffers. Although not drawn here, one can imagine an improved version including annotated routing information and a cartoon floorplan in the corner. So how can we further improve upon that? That’s where the bottom schematic come in with a routing cell created with metal resistors.

Here are some of the biggest benefits of the bottom schematic:

1. It forces you to treat routing plans seriously and acknowledge that it’s part of your design. Heck, it makes everyone who looks at this say that routing cell must be very important.
2. There are two more unique and critical nodes (i.e. clk_top & clk_bot) for easy probing during simulation. There might be some who are fluent in netlist and know exactly where the signal of interest is, but that’s not me. With this schematic I can easily probe these two nodes and obtain useful information right away (e.g. delay matching).
3. This schematic intrinsically separates the design problem into two parts: driver fan-out sizing and parasitics. So if the post layout simulation results weren’t as desired, we could have a better plan of attack for debug. Is it routing parasitics or fanout limited? Maybe I should try C-only extraction for the routing cell to see if it’s resistance dominant. Maybe there is some layout issue in the buffer instead of the wire routes, so let’s use extracted view only for the routing cell. I hope that you see this is a more efficient scheme to help designers isolate layout issues.
4. Let’s talk about the supply/ground pins. The obvious reason is give the extracted capacitors a better reference rather than “0”. The more important reason is that these pins will remind you to include power grids surrounding the wires in layout. Many designers find out much later that top level integration slapped a dense power grid over their critical signals. This can lead to yelling, hair pulling and sometimes redesign. Putting power pins on routing cells lower the chance of such “surprises”.

Despite the examples focusing on high speed wires, metal resistors could be equally important for lower speed applications. When resistance matching is critical (e.g. summing node for a current DAC), segmenting a net with metal resistors can work wonders.

On-chip probe points

Now let’s go to other extreme of the speed spectrum: DC test voltages. For the uninitiated, real world designs often require the ability to measure critical on-chip signals. For digital blocks, an internal mux and a protocol of your choice (I2C, SPI, monitor bus, etc.) is sufficient to select and send signals off chip. The principle is the same for analog signals, except you have to decide the exact locations to probe in the physical layout.

There are mainly two categories of test signals: performance critical and location critical. Performance critical signals are ones that you don’t wish to disturb when you look at them. For example, you don’t wish to add extra capacitive loading on a high speed net or you want to make sure no extra noise can be injected into the VCO control voltage through the test path. The typical solution is to use a large isolation resistor (could be ~100k) locally before sending the voltage to a far-away analog mux. In this case, the resistor is an actual device like a poly resistor.

In other cases, extra loading is not problematic but you are specific about the location and metal layer where the signal is probed. Supply and ground network is the best example for this use. Our friendly metal resistor can be the perfect fit here. My suggestion is to create a corner in the schematic that summarizes the probe signals and their respective metals like below. This little corner provides layout engineers enough initial information (fine tuning is certainly required), and also serves as documentation.

To those who are pcell savvy or wish to improve upon this, you can create a wrapper cell with custom symbols with metal information written on them. The size can also be adjusted for more compact drawings (schematic real estate is valuable too). Depending on your appetite and the scale of your design, this might be an overkill. However, there is a similar use case in the digital land that might make more sense for some.

Digital mapper

Let’s take the diagram above and flip it left and right. Then, you have a bus coming in on the left, and branched out to new unique pins on the right. Remember the configuration section of the symbol here? This list can grow quickly for a larger block, and propagating all these pins to higher level could become troublesome. Somewhere in the schematic hierarchy one needs to connect these meaningfully named pins to the dull digital buses. Perhaps you have seen something like this before

Ah, the good old connect by net name crime. The noConn cells are there to eliminate the warnings due to a few unused bits, but now the whole bus is “not connected”. There is no structure in how the digital bits are connected to their destinations. No amount of “dynamic net highlighting” is gonna save your eyes when you need to debug a wrong connection. Your layout partner is probably also making a voodoo doll and sharpening some needles. Introducing the digital mapper cell, sponsored by metal resistors

The magic happens inside the mapper like below. Luckily, tools today recognize buses that are tapped off from a bigger bus without complaining. This results in a much cleaner look for the schematic and nothing is connected by net name. Right away, it conveys more information about each bit’s usage, expected metal layer and even relative locations in the layout. For example, the noConns signify routing tracks reserved for shielding around critical signals, like power down and reset.

Building upon this unit metres mapper group, a complete mapper cell can contain much more information about the circuit’s programmability. You guessed it – here can be go-to place for all the default values if you annotate them down. What’s better is you could see which configurations share the same register map address. You can even read off the combined value in hex for digital and verification folks. This is just another example of schematic as documentation, made possible by metal resistors. From layout’s point of view, the initial effort might be similar, but any incremental change becomes easier to track with this cell.

I have one final note about the digital mapper cell. Depending on your team’s own methodology, the mapper inputs could potentially be lumped into a single wider bus. This can help simplify the symbol of a mid-level block and makes higher level schematics easier to read and draw. But again, it’s up to your personal taste.

Dear Santa

As a build up to my personal wish list, here is a my bad attempt at a Christmas poem:

‘Twas the night before Christmas when an unexpected friend showed up in the PDK,

Her name was Metres, who smiled and said “your wires are going to be OK”.

Forgive me Santa for being so greedy,

but I still wish Metres can be a bit more handy.

Don’t you know a special elf named CAD?

Perhaps he can help, I heard he’s a good lad.

I know he is busy all season long,

but here is the list for what I want

1. As mentioned above, the metres symbols should display metal layer info directly.
2. Currently, pins can be assigned a “type” (power, signal, analog, etc.), but I personally never used them and understood their purpose. Is it possible to create a “digital” pin type and give me a field to input “default values”? It would be nice if the default value can show up in the symbol pin automatically.
3. Is it possible to read in a digital mapper cell and generate a spreadsheet for the configuration table? This probably requires #2 to happen first.
4. To expand upon #3, perhaps the process of creating configuration spreadsheets can be fully automated if special metres are recognized when tracing an entire netlist. Now designers only need to make sure their schematics contain the configuration details, and never have to touch Excel.
5. A similar methodology might also work for analog test signals, just need another special flavor of metres pcell.

These might still be pipe dreams, but dreams do come true if we wish hard enough. The bigger point, however, is that we need to keep thinking about ways to enhance productivity, improve design scalability and reduce chances of error. An effective use of a tiny element like metres can translate to huge gain in efficiency. You never know what would be the next gem you find or create in the PDK.

The verdict is final: layout IS the design. The images below taken from Alvin Loke’s CICC slides (watch his recent talk here) summarize the key challenges in modern CMOS designs. Layout effort grows linearly (I think it’s more than that) due to more stringent DRC rules and longer design iterations. As a result, it has forced changes on most of our design mentality (although we designers are a stubborn breed). I began to re-evaluate the way I draw schematics because I know eventually a good layout is king. I still hold the personal belief that it’s more likely to work if it looks good. This applies to both schematics and layout.

Design in reverse

I was fortunate enough to have early access to finFET processes (16nm to be exact) during my Ph.D years. Funny story: when I first stared at a finFET layout, I assumed all gates are shorted due to the continuous poly lines. You can imagine my facial expressions when I learned about poly and MD cuts (😲+ 🤬 + 😭). It took me about 3-4 circuit blocks to fully understand the “evil” that is parasitics in finFETs. The LVS ignorable parasitic caps that double your circuit’s power seem innocent next to the parasitic resistors that smirk at you as they make your netlist size explode. Eventually, I decided to do my designs in reverse: never begin schematics/simulations before layout placement. It might sound counter intuitive, but here are the biggest reasons and benefits for adopting this methodology

1. Save time for everyone in the design cycle
   Think in the shoes of layout engineers. They need to tell you that your circuit is impossible to draw due to some DRC. They probably spent a whole day trying to figure this out, but this bad news seemed inevitable. Frustrations and tension fill the room. These scenarios could be avoided if the designers already understood the floorplan/DRC limitations. So instead of “optimizing” the circuits only in SPICE land, start with layout.
2. Layout can determine your sizing, not simulations
   Designers tend to “overdesign” a cell when assigned a small puzzle piece in a big block. We run hundreds of simulations to squeeze out that 0.1dB extra performance, only to find out later that there is no difference with post layout extractions. Nature is kind to us: we often deal with shallow optima and a single transistor’s size wouldn’t matter too much in the grand scheme of things. So instead of running tons of simulations, your design choice might be informed by what works better in layout. One example would be increasing a device’s finger by one would help reduce the cell’s width due to abutment.
3. Begin thinking about creating hierarchies because of layout “tediousness”
   A good schematics hierarchy could also help increase layout’s efficiency. To fully understand the importance of good hierarchical schematics, you need to experience the painful repetitive tasks in layout firsthand.
4. Embed your design intent for parasitics into the floorplan
   No matter how good your cartoon floorplans in schematics are, it doesn’t come close to real layout floorplans. You might gain new insights after just laying down your tiny transistors and some wires. You might also want to break the OD diffusion to squeeze in more contacts. So, you change an NMOS from a single 10 finger device to 10x single finger devices. You can then draw schematics with design intents for parasitics, but you need to OWN the layout floorplan for that to happen.

The design/layout Venn diagram

I have this mental Venn diagram for design and layout. I remind our team’s designers that a majority of their design efforts should be in layout, with awareness of floorplan, DRC and parasitics at a minimum. On the other hand, a good layout engineer should be an electrical engineer at heart, knowing when to tradeoff parasitic capacitors and resistors, capable of suggesting better floorplans, and just a wizard with those hot keys.

It is certainly easier said than done, and I believe designers should take the initiative to reach across the aisle. DO NOT think you are doing layout engineers’ job, but rather you are helping yourself down the line. I promise you that your design’s “time to completion” will reduce significantly. Everyone in the layout team will shower you with appreciation if you are just a little more layout savvy.

Layout-like schematics

Enough of my ranting about how designers should learn layout, let’s discuss how at least we can draw schematics with layout in mind.

Different companies have different ways of managing their schematics at various levels. For large SoC companies, there might be a transition from a more manual and analog way of managing schematics to more digital like methodologies (i.e. netlist, Verilog, etc.) somewhere in the hierarchy. In these cases, the higher level schematics are mostly auto generated and human unreadable. Sometimes this makes sense because the chip becomes just a combination of macros and functional verifications can be more efficient with the help of digital tools. Nevertheless, drawing good schematics that reflect layout is still a good idea at mid/low level. It is really a personal choice deciding at which level or for which cell to draw a layout-like schematic, but it is a practice that could fit any hierarchy level.

It’s time to get our hands dirty. The biggest hurdle we need to jump over first is the default rectangle symbol shapes handed to us by the EDA tools. Its partner in crime is the selection box, the invisible border that defines the symbol boundary and limits your creativity. The conventional wisdom says input on the left and outputs on the right. We have been going with the flow for a while, and to be fair, they certainly get the job done. To break from this convention, here is the corner selection box that allows you to draw symbols with any shape.

This allows you to create very layout like symbols, yet provide a clear entry point to descent down. To illustrate, below is a top level schematic with a pad ring. The boring rectangle symbols will result in a schematics that look like this (I didn’t put all the pin names on there for simplicity)

Now if I draw the pad ring symbol as a real ring with the corner selection box, the schematics can turn into something like below

Let’s detail out the ways why this is better

• The pad locations are explicit, so you can get a lot of information from schematics alone. You can already visualize signal/current flows. You know exactly how many and where the spare pads are just in case. You know how to floorplan internal block’s I/O pins. The list goes on.
• It makes more sense to have duplicate pins on this pad ring symbol because it reflects the physical layout. Thus, you have an immediate idea of how many pads are available for the same signals, especially important for supply/ground.
• Although I didn’t draw it here, you can imagine how one can expand this symbol to annotate each pad type (e.g. ESD strength, I/O pad type, etc.), adopting the schematics as documentation principle.
• The sense of pride that comes with drawing and admiring this finished schematic, which you treasure almost as much as your kids (ok, maybe not that much).

Another dummy example

Now let’s move to a lower level dummy block for another example. I want to emphasize that this is not a real design and probably doesn’t even work. However, it’s a great example to show how to draw layout-like schematics. Take a digital LDO (since we did an analog one before) and we will focus on the custom digital controller and the PMOS array. Below shows the block diagram

As you can see, this block diagram serves as a pseudo floorplan for the layout as well. I will show you the final schematics first, and go into each sub-block respectively.

We will dive into the PMOS array (or more precisely matrix) first. This cell embodies the notion that the layout is the design. It’s quite straightforward schematic wise but the nuances are all in layout. My preferred way to draw this cell for layout is to create row and column hierarchies like below

Note that I purposedly make the csel bus come from the bottom to match the layout. The vin/vout pin directions are more conventional since there is no easy way to indicate a 3D structure (i.e. VIA up and down) in schematics.

Those eagle-eyed among you may already see that the schematics can be more simplified and scaling friendly using bus notations. When the matrix size is large (e.g. >256 elements or 8 bits), the bus notation makes sense. Otherwise, I think 16 rows + 16 cols can still be drawn out explicitly to reflect layout (that’s roughly 2log2(16) = 8 Ctrl C+V operations, so not that bad). Together with a cartoon floorplan and more notes in the schematics, you can confidently hand this off to your layout partner.

Now we will move onto the custom digital block. The more interesting subcell here is the shift register, so I will expand on it further. For the digital block itself, you can clearly see the three subcells and their relative position w.r.t each other. They can be placed into an L-shape with standard cells, fillers and decaps, just like in the schematics. Of course I didn’t forget to draw a note box to indicate the higher level connections to the PMOS matrix. One benefit with this style of schematics (which might not be obvious until you try it yourself) is you rarely have to connect by net names because the signal directions are preserved like in the layout.

If we descend into the shift register cell, I would draw something like the following. The example design intent here is to run the clock signal against the data path to lower the hold time violation risk. Thus the data input needs to be buffered to the other side of the register chain. The extra buffer delay will act as hold time margin for the first DFF.

Note that I also space out the data buffers and annotate the approximate distance between them. The data buffer size is already chosen appropriately because I know the metal usage and wire length in advance. The clock signal also has the same annotations along with a note symbol for shielding. It’s all possible because I have played around with layout floorplan before drawing this schematic. Again, we can simplify this schematic before the shift register gets too long. It might lose some layout information, so you can add a cartoon floorplan in the corner as a supplement.

Final points

In the interest of keeping this post at reasonable length, I won’t include any more specific examples. However, here is a list for layout information that can be explicitly shown in schematics

1. Routing path features including 45/90 degree turns and branching for critical signals, especially if distributed long distance (e.g. clocks).
2. Directionality between critical signals (e.g. show if data and clock paths are parallel or orthogonal).
3. Special routing plans like a tree structure for matching or star connection for power.
4. Inductor coil placements relative to other cells.
5. Higher level block symmetry (for instance, replicated I/Q mixer in a RF signal path).
6. Common centroid placements and connections for first order gradient cancellation (differential pairs, binary/segmented DACs, etc.).
7. The list can go on as you start to draw it like you see it…

As a closing thought, I started this post with a focus on modern CMOS and finFET, but the principles of design in reverse and drawing layout-like schematics is equally suitable for older process technologies. Designers have to evolve and understand bottlenecks and constraints often lie in other aspects, especially layout. By the same token, I also encourage designers to learn about new ideas in signal processing and systems.

In an ideal world, the Venn diagram described above would have a third circle for system design. Work flows and available talents nowadays force most teams to operate like the diagram on the left. Each circle will expand over time thanks to new technology and tools, but it’s the right overlaps that push innovation forward and ensure execution. We should all aspire to be in the middle of the intersections, and younger generation engineers should be trained as such. So gauge yourself against this picture, and move towards the center 1dB each day and one day at a time.

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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!