Different nomenclature for node currents - origin, meaning and how to stick to one only

AncisMichele said:

(side note: to save all nodes, I have to plunge into the Explorer view of the specific test and act from there - I could not find the same option from the Assembler surface or any RMB menu)

This one is easy, see https://support.cadence.com/apex/ArticleAttachmentPortal?id=a1O3w00000AE8ccEAD

Regarding your other problems: The colon and dot separators are used when ADE cannot map the Spectre net or terminal names to the corresponding schematic names (see https://support.cadence.com/apex/ArticleAttachmentPortal?id=a1Od0000000spMSEAY). This does not always seem to work consistently.

AncisMichele said:

(side note: to save all nodes, I have to plunge into the Explorer view of the specific test and act from there - I could not find the same option from the Assembler surface or any RMB menu)

This one is easy, see https://support.cadence.com/apex/ArticleAttachmentPortal?id=a1O3w00000AE8ccEAD

Regarding your other problems: The colon and dot separators are used when ADE cannot map the Spectre net or terminal names to the corresponding schematic names (see https://support.cadence.com/apex/ArticleAttachmentPortal?id=a1Od0000000spMSEAY). This does not always seem to work consistently.

Thanks Frank!

Unfortunately I have no access to the support articles these days :-/

If possible, would you be so kind to point me to the places in the manuals where these topics are explained or treated?

After all, one should be able to operate the software safely by reading the accompanying documentation, if the support option is not available at the minute.

Situation is really puzzling because what I reported in the beginning, and pushed me to create all those expressions with the colon , is no longer happening so when something is not reproducible like this, it makes me very nervous.

I would really get to the bottom of this but in my position right now, without access to proper support, it gets complicated.

I get all sorts of crazyness which probably is related to some translation hiccup, as your last point seems to suggest.

The reason why I got fiddling with current probes is because I was trying to make sense of some simulation results that did not completely stack up.

The results involved currents flowing into a certain device - these currents were not adding up to zero, as in Kirchhoff you're not welcome.

I then put current probes in series with all the device nodes, and found out that those currents would add up to zero as requested.

Next step: calculate the difference between the device node current and the one from the current probe. That's when I had to formulate the differences in terms of the colon-separated nomenclature.

Anyhow, as said, this is no longer recognized and a quick regex substitution on the outputs csv saved my day :-)

However, to my full surprise, a first output of a current difference that was formerly zero, gave me a new result.

But only for that plot.

Then, same simulation and a fresh calculation, things are back to square one with the "known" discrepancy, which is for another device_node/current_probe pair.

A few snapshots to clarify:

For an AC simulation, the currents on nodes g,d,s,b,x of N0 do not add up to zero.

The currents of the corresponding probes, does add up to zero.

From a previous analysis, I found out that the discrepancy was/is concerning the source, node "s".

As I said, I scaled up the test suite to Assembler, I got all this information no longer yielding a result, then fixed it.

Once fixed (now the probes are to be accessed via /IX/PLUS) to my surprise, I got this plot

As you see, from here it would look like now the discrepancy is on the g node!!!

I could not believe my eyes.

I then resimulated and got back to my known result: the culprit is the s current:

The rendering might not be optimal but down at the bottom of the graph you have all other currents which are same between device and probe, and the only divergent one is the source couple.

Now I'm left with two orders of problems, which I nevertheless hope have a common source (!)

- why do currents change between two points in a circuit which should be the exact same node, with no intervening elements but the implicit gmin, which however I set to 1e-14 and in this case that node is at gnd potential?

- why do I get that this discrepancy is also "fluctuating" from node to node, depending on the simulation?

Good thing is, I've got the databases now of the two simulations, so I can look a little deeper and try to figure out what's happening and more importantly, make sure that this won't harm my design process. I'd rather be doing other tasks on a Friday afternoon, though.

Michele

Dear Michele,

AncisMichele said:

Unfortunately I have no access to the support articles these days :-/

If possible, would you be so kind to point me to the places in the manuals where these topics are explained or treated?

The URL Frank provided is to a Cadence Troubleshooting Article and is not in a "manual". Cadence tools can be quite complex due to the many different applications, circuit topologies, and myriad of simulator settings and types. I do not know how decisions are made as to what documentation is included in a "manual" and what documentation is classified as a Troubleshooting Article, Application Note, or other types of Cadence support documentation. As a result, I would highly suggest you pursue a Cadence Support Account to provide access to all documents. 

You have many questions I cannot answer as you have not provided enough information concerning your software versions, the exact steps you are using, and the nature of your simulations (DC, transient, etc...) and if you are changing simulation types and using the same data access syntaxes. However, if you are not familiar with ocean commands, a way to determine the syntax of your outputs is to query the output names from the CIW. With your Assembler or Explorer session open and after your simulation of interest is complete, type "results()" to determine what results are available, followed by "selecResult(<name of available result>)" and then "outputs()" to get a list of the outputs. If you have a lot of outputs, you can use the following command to send them to a file named "output_names.txt"

ocnPrint(?output "output_names.txt" outputs())

An example of the interaction with the CIW follows. My entries are in black and the CIW responses are indented and in blue.

Shawn 

results()

tran(tranOp model instance output designParamVals
primitives subckts variables
)

selectResult('tranOp)

stdobj@0x571aabc0

outputs()

("/XcheckSim" "/ivdda" "/GlbI_RCNet_3" "/GlbI_RCNet_2" "/VCO/inv_4/MP0"
"/VCO/inv_0/MP0" "/VCO/inv_1/MP0" "/VCO/inv_2/MP0" "/VCO/inv_3/MP0" "/VCO/inv_5/MP0"
"/VCO/nand2_0<1>/MP1" "/VCO/nand2_0<0>/MP1" "/VCO/nand2_0<1>/MP0" "/VCO/nand2_0<0>/MP0" "/VCO/inv_4/MN0"
"/VCO/inv_0/MN0" "/VCO/inv_1/MN0" "/VCO/inv_2/MN0" "/VCO/inv_3/MN0" "/VCO/inv_5/MN0"
"/VCO/nand2_0<1>/MN1" "/VCO/nand2_0<0>/MN1" "/VCO/nand2_0<1>/MN0" "/VCO/nand2_0<0>/MN0" "/V2"
"/V8" "/V9"
)

Hi Shawn,

thanks for your answer and yes, I understand I shall pursue a proper Support Contract as information contained in the manuals shipped with the software seem insufficient to enable proper use of the tools. Unfortunately, my hands are tied at the minute, so I'll have to do with what's available. My point in asking in which part of the manuals one maybe details the working strategy of netlisters and such is that, sometimes, it happens that the information *is* in the manuals, just harder to extract. In this case the ANs and other articles do help clarifying, but if one can't access them, he/she can just spend a little more time face down on the manuals and get a grasp on how to proceed. That's what I meant by asking about - possibly - a place in the documentation about these topics.

Not having access to the topic in question, I don't know whether this is info that's not included in the manuals in any form, in which case of course I'm lost.

Unknown said:

You have many questions I cannot answer as you have not provided enough information concerning your software versions, the exact steps you are using, and the nature of your simulations (DC, transient, etc...) and if you are changing simulation types and using the same data access syntaxes.

Provided you think you can and want to help further in this instance, we can surely tackle most of these unanswered questions one by one. This is the Virtuoso version:

This is the spectre version:

The nature of my simulations is plain AC and I am not changing simulation types between runs. As I think I have reported, the only change was to "scale up" my simulation environment from a single design in Explorer, to multiple tests (of which that design is one part) into Assembler.

Anyhow, this is becoming rapidly an issue and I've tackled it with our Foundry right now, let's see how it pans out and I agree, this topic is too complicated to be discussed in a Forum.

Just a small note on your CIW suggestions. Thanks for that first of all, however I have a question: how should the output of results() be any different from what I get from the Browser window I already reported? Is there anything that could be different? If so, why?

Thanks!

Michele

Michele,

Rather than trying to answer all of your specific questions (which don't quite have enough information on the context to be able to answer them all) - BTW, neither Shawn nor Frank work for Cadence and even though I do, I answer here in my spare time (hence me answering on a Sunday when sat in the garden enjoying the sunshine; surely I should have something better to do with my spare time? ;-> ).

There's some confusion here. Let me go back to basic principles (and I will talk about what happens with spectre as the simulator):

1. Names which begin with a "/" and use / for hierarchy delimiter are "schematic" names (strictly not necessarily a schematic, but a view that has a database representation). the final segment might refer to a node name within the sub-circuit, or the terminal name of a component if a current. 
2. Names that do not begin with a "/" are "netlist names" and correspond to the names which end up in the Spectre netlist. In this case, "." is used as the hierarchy delimiter, and ":" is used to delimit the final terminal current or operating point parameter of a device. Some primitive devices have named terminals (so for example, the iprobe device has terminals called in and out - see "spectre -h iprobe" and voltage sources have p and n). Often for hierarchical blocks, the pin number is used for the current (there is some complexity with the option  useterms but let's assume for now that's at default because it gets a bit messy if you alter that)

When a schematic name is used in an output, ADE may have to generate a name to add as the save statement - either for voltages or currents, depending on what is being saved. For node names, it needs to do any name mapping (e.g. reserved words or illegal characters) and will translate the name into the appropriate name in the netlist. For primitive device currents, the termMapping in the spectre simulation information in the CDF is used to do the mapping - you'll see that this maps the PLUS pin to :in for example. The MINUS pin also saves the :in pin but has a function to negate it upon reading the current so that you don't need to save both currents.

You can only give schematic names for things that exist in the schematic (or whatever view is being netlisted), so referring to things defined within an external text representation (e.g. within a subcircuit model) cannot use the schematic naming convention. You should always be able to use netlist names, but you need to make sure that these are saved - and you got the names correct - sometimes reserved words may mean that the netlist names are very different from the schematic (relatively rare, but it can happen). So most of the time people prefer to use the schematic names - and that's what ADE would normally use if you probe something from the schematic.

Now, when the simulator runs, the result data is always written with netlist names in the database (i.e. dots for hierarchy, colons for currents/operating point parameters etc). That's what's actually in the PSF. However, ViVA will try to map this back into schematic names using a reverse mapping of what was done during netlisting. If the name doesn't correspond to something netlisted, then it can't do that. it does get this wrong for certain things now and again, but that's generally a bug that we should fix if it causes a problem.

You can see this with the OCEAN functions that Shawn referred to:

openResults("/path/to/psf") ; ADE may already have opened the results for you anyway
results() ; the list of result names available
selectResult("tran") ; pick the transient results
outputs() ; the reverse mapped names (where it can)
outputs(?map nil) ; outputs the original names unmapped (i.e. with the dots and colons in)

You can always refer to an output from the database using the unmapped name, and the mapped name if it is able to do the reverse mapping - i.e. corresponds to something in the schematic hierarchy.

The other issue you've been seeing with currents not summing properly might be due to needing to use useprobes=yes for AC analysis (which effectively inserts an Iprobe in series to ensure that the currents are measured correctly) or it could be due to the use of inline subckts in your model files. If these are used, then the current is the current of the inline device - which may not be the same as the currents for the external pins of the subckt - which can then cause confusion. That said, the default for the option inlinesubcktcurrent=subckt has been subckt for quite some time, so not sure that this would be the reason. We'd have to see it to be sure - so support is the way to handle that. If you are working for a customer with a normal contract then this should be possible, even if you're a contractor (you typically need an email address from that company for this).

Probably a bit of a lengthy reply for a spare-time response in the Sunday sunshine, but hope that helps clear things up a bit. In general, netlist names should work provided that the mapping didn't change for some reason, but usually schematic names are preferred because they directly correspond to an element on the schematic. 

Andrew