StefanSchippers / xschem

A schematic editor for VLSI/Asic/Analog custom designs, netlist backends for VHDL, Spice and Verilog. The tool is focused on hierarchy and parametric designs, to maximize circuit reuse.
Other
297 stars 21 forks source link

Highlight nets connected to particular custom type of pin #197

Open georgtree opened 2 months ago

georgtree commented 2 months ago

Hello! I have a question - is it possible to define custom type of the pin, for example, electrical type, magnetic, thermal, signal, etc, and when wire is connected to this pin, it is highlighted with colour that correspond to that type of net? For example, we connect wire to pin with thermal type, and it turns red, and if we accidentally connect it to other type, it turns grey to show that type are mismatched. By this I want to highlight connections inside particular physical domains, so we can visually diagnose if pins with different types are connected, and see which type of pins we connect with this particular wire. Thank you in advance.

georgtree commented 2 months ago

I thought of it because you already have ERC check for different symbol directions...I thought about the tcl script that will iterate through all instances, check the type of node and highlight attached net to particular colour, but I am not sure that all available command are in Xschem API already.

StefanSchippers commented 2 months ago

Hi, George,

net / pin types are already used for VHDL. a sig_type attribute is attached to a net / pin to define the type of the signal, since VHDL allows any type (primitive or user defined), like bit, std_logic, real, integer and so on. 3

I think you can reuse this attribute. There is also a class=... attribute that defines the class of the pin/net, for VHDL this could be for example signal, constant. I think class can be used to define the class of the pin/net (electrical, thermal, mechanical,...) and the sig_type should define the representation (bit, real, integer)....

Then some script needs to be realized to do what you want. If you can send a simple working example (with the sub-schematics/sub symbols) I can do some experiments.

georgtree commented 1 month ago

Hi, sorry for late reply - by working example, what do you mean? the example that can be run successfully in simulator, or just example of xschem .sch file? If the second, I can send it to you right now (in first case you also need all my models, verilog-a files, etc), the only thing that I don't know how to do is - save all elements locally with full hierarchy. For example, i have following sub-circuit, that contain three domains: electrical, magnetic, and mechanic translational: image This circuit is run from other circuit at top hierarchy: image

The idea is to have all wires that connect pins with the same type be highlighted with color of this domain, and the color is defined by type of pin. I think of it as an additional script that can highlight nets according to types of connected pins (the corresponding type-color binding could be loaded from configuration file). You already have great highlighting mechanism, so I think it is doable (just sharing my thoughts, I think I can do it also by myself, but maybe you have a quick solution)

StefanSchippers commented 1 month ago

You can send a cut-down example of your design containing two or more signal domains. Create a new empty directory (example/), place the schematics and symbols used into this directory. set XSCHEM_LIBRARY_PATH in your xschemrc to contain only xschem base devices and this directory: set XSCHEM_LIBRARY_PATH ${XSCHEM_SHAREDIR}/xschem_library/devices:/path/to/your/example Verify xschem can open the example and there are no missing symbols. Then zip the directory so I can run the test.

georgtree commented 1 month ago

Hello! I did it, hopes all will be ok. Attached file to this post, I added three classes to pins - magnetic, mech_trans and electrical. Also I think that subcircuit pins should inherit the class from devices pins at lower level. Thank you in advance. example.zip

StefanSchippers commented 1 month ago

I have created the following script:

proc hilight {} {
  set color(magnetic)   0 ;# red
  set color(electrical) 1 ;# yellow
  set color(mech_trans) 2 ;# white

  foreach item [xschem list_nets] {
    lassign $item net type ;# type can be net or ipin or iopin or opin
    set class {} 
    foreach item [xschem instances_to_net $net] {
      lassign $item i p x y  ;# i=instname, p=pinname, x and y are unused coorditanes
      set cl [xschem getprop instance_pin $i $p class]
      if { $class ne {} && $cl ne $class } { ;# print error if a net connects to different class domains
        puts "error: $net connects to $cl and $class"
      }
      set class $cl
    }
    puts "$net --> $class"
    xschem set hilight_color $color($class)
    xschem hilight_netname $net
  }
} 

hilight

Applying the script to your schematic yields this: 1

where red is magnetic, yellow is electrical, white is mech_trans. I had to change the "magnetic ground" label to GND instead of 0 otherwise the same label (0) connects to different class domains.

georgtree commented 1 month ago

Wow, that is super fast and cool, I will try it out this evening! One question - globally, all grounds should be connected to 0, but to make this highlighting tool work properly we need different labels. How to set different labels to be connected to global ground during netlisting? The way I see is define .subckt for each of the ground symbol and connect them to zero explicitly inside subcircuit, but maybe there is more elegant way to do this, some alias for example?

StefanSchippers commented 1 month ago

It is not clear to me how an electrical ground (like 0) relates to a "magnetic" ground. If they are different things they should have different labels.

In your ground symbols there is the global=true attribute. In the spice netlist a .global net line is produced for each ground label (example: .global GND)

Each global label has global scope. Anywhere in the hierarchy they refer to the same net.

georgtree commented 1 month ago

For simulator they are identical, because ngspice doesn't know about any domain, it is an abstraction that helps to work with different circuit variables like current-voltage, angular speed-torque, flux-mmf etc. When circuit is netlisted to ngspice, all grounds must be united.

StefanSchippers commented 1 month ago

Ok, understood. So you can modify the script to not consider the '0' node (it can be connected to any domain, so highlighting it does not make sense).

StefanSchippers commented 1 month ago

For in, out, inout pins of a subcircuit schematic, add the class=... attribute, as well as to the corresponding pins in the symbol. I prefer the user takes the task to assign class attributes to pins, instead of propagating these automatically. This way the user has more control, and the script can flag unintentional domain crossing of nets. Once you highlight nets in a subcircuit if you go up in the hierarchy the highlihts are propagated to parent circuit.

georgtree commented 1 month ago

Hello! Is it possible to define aliases to 0 node, that will be replaced during netlist generation? I tried to use shorts with zero-voltage sources, but it affects the convergence of circuits...

georgtree commented 1 month ago

The idea is to have different common nets for each domain to highlight accordingly (elec_ref, mech_ref, etc), but in netlist these nets must be replaced by the 0 reference. So, in .sch file we see them as different nets, but make a substitution during netlisting.

georgtree commented 2 weeks ago

Hello! Is it possible to define aliases to 0 node, that will be replaced during netlist generation? I tried to use shorts with zero-voltage sources, but it affects the convergence of circuits...

Hello! Is it possible to do something like this? Make a substitution of particular net names during netlisting

StefanSchippers commented 2 weeks ago

the 0-voltage sources (ammeter) are the best way to create net aliases. One caveat: the 0 node is by definition global, so it has the same meaning in every subcircuit without needing to propagate the 0 node with pins. Any other net name (excluding GND which is equivalent to 0 in ngspice) is not global. So if you create another ground alias with a 0V voltage source you must set the node to global. This can be done by using the vdd.sym or gnd.sym symbols instead of a plain net label, These symbols add the .global declaration to the generated spice netlist making the aliases global. 1

see the generated netlist of above example:

** sch_path: /home/schippes/untitled.sch
**.subckt untitled
Vmeas 0 GNDA 0
Vmeas1 0 GNDB 0
**.ends
.GLOBAL GNDA
.GLOBAL GNDB
.end
georgtree commented 2 weeks ago

Hello, yes I tried this, but it affects convergence of some circuits, and in random way, I can't find the pattern to predict that.

georgtree commented 2 weeks ago

I have an idea - i can add my own script between netlist generated by scheme and ngspice, directly in command to simulator, what do you think?

StefanSchippers commented 2 weeks ago

Of course you can. Still curious why a 0V vsource for a net aliasing makes simulation fail.

georgtree commented 2 weeks ago

Me too, I suspect that it adds additional entry in mna matrix, and makes matrix too stiff because of zero series resistance, but I am note sure. Some info is here https://electronics.stackexchange.com/questions/524042/why-do-circuit-simulators-like-ltspice-prefer-current-sources-instead-of-voltage

StefanSchippers commented 2 weeks ago

Can you try to alias a gnd node by using a 0.000001 (or similar "low enough" value) Ohm resistor?

georgtree commented 2 weeks ago

Yes I can, but it takes time, I have to replace all existing references in all my schematics (more than 60) because I can't predict which circuit could produce the issue (it could be the different circuit from the one that produce error for zero-voltage short) and then test them all. I will do it if it is the only way :(

P.S. Please don't get me wrong, I don't shift work on you because I don't want it to do/no have time for it, just to share my current situation

StefanSchippers commented 2 weeks ago

you can posprocess the netlist, transforming all: Vxxxx node1 node2 0 to RVxxxx node1 node2 0.000001 and see if simulation works. No need to tamper the schematic of course, unless the substitutions prove to be effective.

georgtree commented 2 weeks ago

Ah, you are right, I can postprocess netlists, thank you, I will check that