multiple power pads when global supply name used in sub blocks?

Calibre (as far as I know) also supports the idea of virtual connections, but that's not done merely by describing the net with a global-like name. The exclamation mark on the end is a Virtuoso convention, used by the schematic editor to mark the net as global; this ends up as a .GLOBAL in the CDL which is how the schematic-side of LVS would know that it's global. However, nothing on the layout side would do this.

It seems to me that you shouldn't be using global nets in the first place (globals are generally evil, since they prevent re-use). Instead you probably should use inherited connections on the schematic side - ideally using an explicit pin on the schematic using that inherited connection (e.g. a pin called "vplus" (no exclamation) with a net expression on it with property vplus, default vplus!). Then you can have an explicit pin on the layout side called "vplus" and you can override the property on each block as needed to separately connect them up. This then allows the true connectivity to be checked - so your LVS will actually checking that the correct pad is connected to the correct block, rather than pretending they are all the same net.

Regards,

Andrew

I started off with inherited connections, but ended up removing them because I could not figure out how to handle cells with two (or more) inherited connections with the same property name (vdd in the case of the pdk cells).  I have many cells with multiple vdd supplies. I changed to globals, which solved that issue, but now that is a problem!

I put together this  trivial example cell made from two pdk inverters. The pdk inverters use vdd as the property name for the plus supply. The netset is shown in yellow.

So far, so good. The left inv assumes vdd=vbat!, the right one vplus as expected.

But at the next level I want vbat1 and vplus1 for one cell, and vbat2, vplus2 for the other.

But, of course,  both vplus and vbat assume vbat1 for the right "cell", and vbat2 for the left cell.  I can't add a second netset with the same property name.

Do I have to edit the pdk cells (if I can) to give the individual inverters (in this example) different property names?

I'll review the RAK again, but I'm not sure it answers this question.

Well Andrew, thanks to re-reading your answer more closely, I've managed to do what I want - to a point.  My question now, is why can't I seem to generate inherited supply pins for the next level of instantiation without the bang?  It doesn't like my explicit pins, and adds implicit connections.

There's no "bang" in your pins - the only "bang" is in the default value of a net expression. That's because the default has to be global - if you don't override the property then it needs to be able to connect to it somehow - hence making the default a global net.

The issue in your schematic is that you have the pins on one net, and the inherited connection overrides on another net. When you create an explicit pin called vbat2 with a net expression with a default of vbat2!, the local net in schematic needs to be called vbat2! (that doesn't make it global - because of the presence of the inherited connection, all nets called vbat2! in that schematic are connected and overridden by the property).

The easiest way to do what you want is to select the instance and then use Edit→Net Expression→Available Properties. Select one of the properties and choose "Convert to inherited pin". You can then give the pin name, property and default (which should auto-populate) and it will then set the property on the instance to (say) [@vbat2:%:vbat2!] - so it will directly connect the vbat property on the instance to the new inherited net at this level.

Or you could use the "Override with specific net" and set that net to vbat2! and then create pins yourself as you've done.

Regards,

Andrew

Hi Andrew,

I am still confused (apologies for being so thick) about the necessity for assigning a bang to the netset property.  I have put together a more readable example of multi level inherited connection example which achieves what I want, Each inverter at the bottom level maps to each of the top level non-banged vplus and vbat supplies.

But I am curious why every default net couldn't be assigned to the same default - e.g. vbat! rather than e.g.  vbatA!, vbat2! etc which appeared to be necessary. 

This setup - with netsets mapped to bangs - appeared to be the only one which achieved my goal.   I could not get netset of: e.g. vbat2=vbatB (no bang) to work no matter how I configured the explicit pin, an implicit wire always resulted.

The PDK cell using the analoglib vdd_inherit. As you can see it is reflecting the top level unbanged supply vplusA

hierachy level 1

hierachy level 2

hierachy level 3

Top level with eight non banged power nets

A portion of the VXL created, LVS verified layout.

Even though this achieves my goal, if I am doing something wrong or sub-optimal please let me know.

Many thanks for your time and effort.

The net in a schematic which has a net expression on it (or on the terminal) will always be locally called blah! (i.e. with a bang) because the net name in the schematic when you're editing it will reflect the global (default) net name. If you have a netSet of vbat2=vbatB then that means it is bound to a local net called vbatB then that will be distinct from the default net of an explicit pin with a net expression where the default was vbatB! (they are different nets).

You can't have the same net as the default for two or more net expressions in the same schematic. That's because the actual net in the schematic would be the same for both of them - say you had vbat1 with a default of vbat! and vbat2 with a default of vbat! - anything on the net vbat! in the schematic is connected - and so you can't override vbat1 to be one thing and vbat2 to be something else at a higher level netSet - because they are actually connected in the schematic and so can't be two different things.

Now there is a way of achieving what you want in your earlier post. If you add a wire from the vbat1 pin at the top, and then do Create→Wire Name. On the pop up form check the Create net alias labels checkbox:

and then click on the wire you just added. Upon check and save, this will create an alias name for that wire. Since the wire is connected to the pin which is on net vbat1! you've just aliased vbat1! to vbat and hence they are connected (if you select the wire and type car(geGetSelSet())~>net~>aliases you'll see the aliasing; if you probe the wire, you'll see the vbat1 wire at the bottom highlight too).

I'm not sure this is any better than creating the "Convert to inherited pin" that I suggested earlier on, but maybe you find that more readable? Alias labels are an alternative to using patch cords - a bit lighter visually than a patch cord (note, you can alias globals to internal nets, pins to internal nets, and internal nets to other internal nets - but alias globals to other globals, pins to pins or pins to globals).

Regards,

Andrew

The net in a schematic which has a net expression on it (or on the terminal) will always be locally called blah! (i.e. with a bang) because the net name in the schematic when you're editing it will reflect the global (default) net name. If you have a netSet of vbat2=vbatB then that means it is bound to a local net called vbatB then that will be distinct from the default net of an explicit pin with a net expression where the default was vbatB! (they are different nets).

You can't have the same net as the default for two or more net expressions in the same schematic. That's because the actual net in the schematic would be the same for both of them - say you had vbat1 with a default of vbat! and vbat2 with a default of vbat! - anything on the net vbat! in the schematic is connected - and so you can't override vbat1 to be one thing and vbat2 to be something else at a higher level netSet - because they are actually connected in the schematic and so can't be two different things.

Now there is a way of achieving what you want in your earlier post. If you add a wire from the vbat1 pin at the top, and then do Create→Wire Name. On the pop up form check the Create net alias labels checkbox:

and then click on the wire you just added. Upon check and save, this will create an alias name for that wire. Since the wire is connected to the pin which is on net vbat1! you've just aliased vbat1! to vbat and hence they are connected (if you select the wire and type car(geGetSelSet())~>net~>aliases you'll see the aliasing; if you probe the wire, you'll see the vbat1 wire at the bottom highlight too).

I'm not sure this is any better than creating the "Convert to inherited pin" that I suggested earlier on, but maybe you find that more readable? Alias labels are an alternative to using patch cords - a bit lighter visually than a patch cord (note, you can alias globals to internal nets, pins to internal nets, and internal nets to other internal nets - but alias globals to other globals, pins to pins or pins to globals).

Regards,

Andrew

Andrew,

How does one modify a symbol pin without redoing cellview to cellview in modify mode from the schematic? 

As I try to get my head around which pins are regular, global or inherited I sometimes find myself needing to change a symbol pin to an inherited pin but there seems to be no editing capability for this other than recreating the symbol in modify mode.

Ken,

Of course, you have two choices with the symbol - you can either have the pin present on the symbol (with the net expression on it) as well as on the corresponding schematic, or just on the schematic (and omitted from the symbol).

If you want to change a pin on the symbol to have a net expression, you can do that by editing the symbol, selecting the pin and then using Create→Net Expression (fill in the property and default value). Or you can start with nothing selected, do Create→Net Expression, fill in the form and then click on the pin. Having done this, if you do an edit properties with the pin selected, you'll see the net expression.

To remove the net expression, select the label showing the net expression info attached to the pin (usually something like "VDD *") and delete it. That removes the net expression too.

Regards,

Andrew

Thanks Andrew,

As usual your help is much appreciated.