another suggestion, for displaying currents it is simpler to add a 0V voltage source and get the current as shown in picture, this works in a process-independent way, avoiding the intricate sky130 naming conventions.

do you happen to know if

netgen

understands to treat these as shorts during lvs?

Oh, yes, that might be an issue, i see. So you definitely need to track current thru existing devices. I checked your picture and i dont see any errors, However even the simple voltage meters on nets do show the '?' and these don't require any special attribute, so something macroscopic is going wrong. Please verify that if you simulate circuit 'xxx.sch' you must load circuit 'xxx.sch' in xschem, simulate 'xxx.sch' and annotate 'xxx.raw'. This should also annotate subcircuits of 'xxx' if you use these 'pull' annotators.

Yes so the top-level annotations work fine. It's just the ones inside the amp that show

?

. See picture below with populated top-level annotations. Thank you for offering to take a look at the design, @Stefan Schippers (see attached). You man need to make some substitutions since I have my own analoglib with some extra custom stuff in it. Also, if you need to look at anything else in the project (like the xschemrc file) the entire project repo. is here under the

columbus

folder, but the stuff I'm attaching is from local changes.

Thank you @Tom i have made the simple substitutions to enable simulation. The subcircuit backannotation problem is simple: you called the instance '`I5`' and inside the symbol you added the '`X`' character in front of the @name (that gets expanded in netlist to

XI5

). This confuses xschem as he thinks the hierarchical path for a local

node

is

I5.node

instead of

XI5.node

. Solution: Call the schematic instance of the diffamp '`XI5`' and remove the '`X`' prefix in the symbol.

Ah, terrific @Stefan Schippers, thank you for figuring that out for me! As regards your question about the workaround. I'm inclined to think that would be a good workaround, yes, since hierarchical instances will always translate to spice sub-circuits, and will therefore always require an

X

or

x

prefix, I don't see how adding that work around would cause any problems, do you? And it would also enable the use of instances names which don't start with

X

as in my case which would be nice, but I'll leave it to your better judgment. What do you think?

@Tom ok i will work on it. The problem arises because spice requires subcircuit instance names to begin with 'X' while verilog and VHDL netlist formats do not require this. However i can fix that for spice only

Ah yes of course, I forgot about the HDL netlists

@Tom i think i will use your approach: use 'I5' for instance, add a 'X' in front of @name in format string. This gives designer complete control of how netlist is generated (without xschem making decisions). The only thing to fix is the annotator, that must prefix an 'X' to path node specifiers that do not already have a 'X'...

Ok great! that sounds good to me. Please let me know when I should pull in the update. In the meantime I've added the

X

to the name to get it working as per your instruction.

@Tom the change is done, if you sync up xschem to the last commit you can revert the diff amp naming to I5, and add the 'X' in the symbol format string. I have tried your design and annotation works. Thanks for pointing out this issue (sorry it took some time to figure out the root cause 🙂 ).

Wow that was quick. No @Stefan Schippers thank you very much for helping me resolve it!

@Tom, @Stefan Schippers: I didn't notice this thread until today, and nobody pinged me, but the answer about netgen is that netgen will treat a 0V source as a short if that improves the matching (i.e., it will first look for a 0V source in the other netlist, but if there is no such matching device, then it will remove the source and short across it and continue).

Ah, interesting, thanks @Tim Edwards. Useful to know. What about a 0A current source. Will it treat that as an open? I've defined a "no connect" component in xschem to stop it highlighting nets that are deliberately unconnected, and that is a 0A current source to GND under the hood.

@Tim Edwards That is clever! Thanks for the clarification.

@Tom: I do not have any treatment of a 0A current source, but it would be easy enough to add. Easier than the 0V source, even, because I just remove the device and don't have to merge the nets across it.

@Tim Edwards thanks for adding that. I think it's a useful addition