Top Ten: Tips on schematic entry in Cadence

Now, the snow has melted … and this week’s top ten list goes through some top-ten schematic entry tips for the Cadence schematic editor. (Some bullets are quite generic, but yet …) Today’s list is not really ordered so, ten points simply to think about.

And as usual: these bullets are ten out of many, of course. Please add your own links – I would be quite glad to get your opinion on this.

I guess it also should be mention that quite a lot of groups/design houses out there are solving some of these things in-house, as quite a lot of support is offered by their CAD departments.

• #10: Pretty schematics and symbols

  We need to start simple… draw nice schematics, proportional symbols, spacious transistor placing, etc. Think of it this way: draw your schematics such that you can take the plot from Cadence rather than redrawing the schematics in another tool. Yes, it looks a bit dodgy sometimes, but there are two things to it:

  • (1) the schematics in the database is the schematics reflecting your design, not the one in openoffice draw, and
  • (2) remember the audience of your design report: quite often analog designers themselves. They are quite used to read these kinds of schematics. In fact, they do it eight hours a day.

  Further on, in my cadence daisy flow, you have an option to remove some layers to clean up your schematics slightly. See the bindkeys listing (F12) for this. Then the schematics isn’t that bad actually.

  Then also the symbols: this is a tribute to Mr. Joakim Bängs, a friend of mine, whose symbols are so creative and self-explanatory. “All” the stuff found inside the symbol is actually drawn on the symbol itself, making it very easy to “read” the schematics.

  Further on, add a lot of explanatory text to your schematics making life simpler for the reader.

• #9: Iterated instances, nets and buses

  Using iterated instances will come hand-in-hand with bullet #10: a clean schematics is easier to read. Yes, sometimes it might be a bit tricky to understand how the iterated instances actually are hooked up if you’re not trained – but you could (see 10) add some explanatory text…

  Assume that you want to connect 128 resistors in series in some kind of resistor string. It would be tempting to place those 128 resistors in the schematics and then start to hook them up with all this wiring and labels. This is not what you should do. Instead instantiate one resistor: R_string<127:0>. To the left terminal you create a wire and name it: vTop,vRef<127:1> . To the other terminal use: vRef<127:1>,vBot. Tadah! Neat and simple.

  An N-bit DAC array with 2^N unit cells can for example be instantiated this way with one single instantiation and then just label the connectors cleverly. See the Cadence help on buses and how you can play around with e.g. NETNAME<9:0>, NETNAME<9*9:0>, etc.

  Especially, if you have digital circuits in your analog schematics, use iterated instances and buses to mimic the coding style you would use in RTL.

• #8: Stick to a standard naming convention – and put names on everything!

  This bullet is related to #10 too I guess… Stick to some naming convention within your group/team/project/design. It is so annoying to 100 different flavours on the name of the ground and supply voltage: vgnd, vGnd, vss, gnd, gnd!, GND, Vss, Gnd and vpwr, vPwr, vdd, vddHi, vdd12, vdd33, vdd!, VDD, VDD3, VDD1, vSupply, vPos. What’s wrong with one single name? Further on, to avoid some hook-up confusions (quite often “verification” is done by name-to-name mapping). So, stick to some clever way of naming bias currents, control signals, etc. Do not approve a design if the naming convention is poor. There should not be any doubts on the naming.

  Let me give you a classic one (well, maybe it only indicates our sloppiness, but yet…): Tape out in a few minutes, we have forgot to add the power down signal to a block. We need to hook it up on top level, and there is no time to re-simulate. Analog designer at one end calls his input signal: powerdown_lo. Digital designer at the other end reads this and interprets: “Ah, this is an active low, powerdown signal”. No, no, no! It was an active-high powerdown signal referred to the lower supply voltage. For the digital guy, there was no concept of two power domains, but for the analog it was: 1.8 and 3.3 V domain. Chip turns out to be dead. Yes, bad verification strategy, but quite a lot of signals are indeed hooked-up on a name-to-name mapping and verification time is reduced if you are even more consistent.

  So: same thing in your analog circuits, add names on everything. Every single transistor, every single inverter, every single instant, every single net. The debugging becomes much simpler. For example, you run a simulation and get a comment on voltage level for I0.I13.I14.I19.M12.D connected to net /I0/I13/I14/I19/net3</code. In my world it is much easier for me to read: Ifilter.Ibias.Istartup.Iota.Mtail.D connected to net /Ifilter/Ibias/Istartup/Iota/vCommon. It is so much easier to start the debugging.

• #7: Connect by labels

  Large schematics could be messy, even if you have used the strategies from previous bullets. After a while you will for example have quite a few transistors with e.g. bulk connections that need to be connected somewhere. You could use the three-terminal transistor symbol that enables you to manually type the bulk connection in the properties form. But if you have the four-terminal device you probably want to add a small wire label on the pin position rather than adding a wire. This is actually possible in cadence. Try it out! Copy a wire label from a net and put that copied label on top of a pin of a symbol. Notice that virtuoso now connects that pin to that wire name. Powerful isn’t it?

  So now imagine you have plenty of, say, digital subcomponents with supply, ground, bulks, etc., on their symbols. Place corresponding small, neat wire labels on the pins instead of routing small strips of wires that are named. (And especially do not route the whole wire to the supply pin!). In the daisy flow, there is an elegant option to add those labels. First, add a text string to your schematic, with e.g.: “VDD vdd! VSS vss! GND gnd!”. Mark the text string and then mark the symbols on which you want the VDD pin to be connected to the net vdd!, the VSS to vss!, GND to gnd!, etc. Then press “alt+s” and daisy will add small, neat labels on those pins. The result is a readable schematics. The labels are also attached to the symbol, so if you move the symbol, the labels will follow it.

• #6: Create analog schematics using verilog

  Very often the verification team asks for models of your analog circuits. This is a classical problem and a quite common source of errors in your designs. The models are quite often incorrect per definition and they are not maintained with the same “love” as the analog designer puts into his schematic levels. One way to tackle this is to think a little bit differently: why not specify your analog circuits with a piece of verilog code?

  There is a function in Cadence (File > import > verilog in the CIW) that allows you to import a verilog netlist into your design. (Notice that it is a netlist and that functional verilog cannot be imported. This normally suits the analog designer quite well though…) For sligthly more complex, or at least slightly higher up in hierarchy, this is quite handy. For example, assume you have a whole analog front-end and want to hook up all the subcomponets: filter, amplifier, converters, bias, etc. It is probably much easier to do this on a few lines of code in the netlist which also can be handed over to verification team.

  But notice that you can even design an operational amplifier using verilog code. The transistor can also be instantiated in the RTL and you can do whatever hook-up you want. After all, in the end, what we simulate is a netlist, and why not use verilog rather than spectre as entry language?

• #5: More nets/ports than needed

  Related to #6 in some sense is this tip: add more nets and ports than needed. Especially add a certain set of ports and nets: Reset, Power down, Test, Bypass, and more. Tell the analog designers to propagate those ports all (well, maybe not all ) the way down through the hierarchy. Now, at least, there is a reminder in each schematic: “Do not forget to add test mode, do not forget to verify power cycling, do not forget to add a bypass mode for IP isolation, do not forget to be able to reset your block”. Of course the analog designer can choose not to hook them up, but at least they are there. Some of the pins/ports could also be a bus of some kind, like e.g. the TEST.
  You can probably think of more special nets that should be around in all components. Or think of it this way once you measured your damaged chip: “Oh, how nice it would have been if we would have had *this-and-that* signal in that block”.

• #4: More components than needed

  You should always have rubberband options in your design, i.e., there should be ways to simply alter designer parameters in your design. For example, the transistors should be made larger since you in the 11th hour found a special operating mode where some more gain was needed. Then you do not want to redo the design, you want to have the transistors there in the schematic and layout and just be able to change a couple of wires to solve the problem.

  There is more to it, to simplify schematics and design, you might want to add some extra blocks that could be useful, but you do not really know what you want to do with them – yet. So, add some spare inverters, current mirrors here and there. Normally, they do not add much more to the area anyway.

  Further on, assume you have two blocks, block A and block B, fairly identical, but now you need to instantiate 11 of block A and 19 of block B in your design. Why not make block A and B identical: block C, but with some “hardware” options: by some simple re-route or metal strip or so on the top level, you can now instantiate 30 block C. This is quite powerful and probably more powerful than you think. Look for symmetry and shared components in fairly trivial blocks and see how they can be re-used.

  Of course, you need to look out for the cases of increasing area too much. But sometimes development time is more expensive than area in the first run. Once the chip is successful, you can do whatever tuning and cost optimization that you need.

• #3: Annotation on symbols

  Yet again a kind of repetition of bullet #10, but this time a little bit more advanced. Notice that in cadence you can add essentially any skill function and attach it to a symbol! The “small, little green/yellow/red labels” on the symbols are actually function calls. The sheet symbol that you often instantiate in the schematic is doing this. There are some text labels referring to when design was saved, etc. But here you could get a bit more creative: since any function can be called, why not do some other things like:

  • “If we run an analog simulation and this block is instantiated in the design, then print the total power consumption of this block, etc.”
  • Generate and print a list of all existing views for this block
  • Use different color schemes dependent on how critical the block is or what stage it is in: finished=green, unfinished=orange, empty=red, etc.
• #2: Parameterized schematics

  Quite often you use parameters in your design: the transistor sizes are given by “inputWidth”, “biasWidth”, etc., resistors are given by “rLoad”, etc. Then you need to go to the layout phase and you have to remove those parameters and insert the true values that you found after doing plenty of simulations. Otherwise, layout XL will not be happy as it cannot place the components in the layout and especially the LVS tool will not be happy as it cannot compare layout vs. schematic. So you start to enter the values given the simulation results. DON’T DO THAT! You should have another strategy: use some other view for simulation, say: simSchematics. In this schematic you use parameters, for almost all components. Then you create a clever script! The script should do the following:

  • Take the existing simSchematic as input
  • Take a simulation state as input
  • Generate a schematic-from-schematic (or simply copy the simSchematic to schematic view)
  • Replace all the variables/parameters in the new schematic with the values found in the state file provided
  • Save and quite the new schematic cell

  This flow can easily be connected to some bindkey and/or wrapped-up in some “delivery” script. Further on, it also enables you to quickly jump between different parameter sets.

• #1: Jump between PDKs, etc.

  Quite often, you jump between different processes and different pdks and different nodes of the same pdk/process. One day you design TSMC 90nm and the next it is STM 65nm, etc. So, my question is then: why don’t you design your own transistors?

  Today, the PDKs from a schematic-level point of view are fairly equal and normally you would only change, say W, L, fingers, and m. Sometimes, for high-speed, or high-accuracy, you need to do some extra tricks for say ad,as,pd,ps, etc. But fairly often, you just touch the basic parameters and then in layout you do the rest. Quite often, the ad,as,pd,ps are not LVS’ed anyway. You need to verify the impact of those through post-layout simulations!

  So, create your own transistor, resistor, capacitor library, with a minimized number of parameters to simplify for you. After all, how many different kinds of transistors do you use? How many resistor types? Draw your higher-level schematics using transistors referring to your own technology file and then let this one point to the different transistors of the different PDKs you are going to use. That is, create a subcell called e.g., schematic_stm065 that instantiates a true STM transistor and parameters are set using pPar or iPar parameters.

  This strategy requires a bit of overhead, of course, but the porting between different processes/PDKs becomes much simpler. Once the schematic is stabilized and you need to go to the layout phase, use a script that parses through the design and then instantiates the “true” transistors with “true” parameters using the script in bullet #2. The actual layout cell view is of course another issue, it is much more tightly connected to the process/pdk and cannot be treated in the same way.

So, any comments? What are your best tips and tricks for the schematic entry in Cadence virtuoso?