Lacking is an index that allows a searcher to simply describe something. Search on "skin blister (or bubbles) on bottom of foot," and there are lots of relevant hits. There is no way in electronics to search on something by simply describing it, like "NPN transistor with foreword biased diode to base." Sure, Google will almost always return something, but most of it is not relevant to that question.

What comes to mind here is to automatically generate natural language descriptions of all the circuits in the database and then use standard text searching techniques to search these descriptions. The grammar of these descriptions would probably not be very good but it would not need to be.

 

I had not thought about parsing the netlist file, but that could be done. I suppose one downside of using the netlist to obtain the circuit's structure is the physical location of the components would not be present. The video below shows the beginnings of automatic circuit layout capabilities that I am adding to the circuit simulator I am working on which may eventually help with this.

I think I would be able to parse the data that is in .asc and .asy files to read circuits into memory complete with the positions of their components.

Hi,

Well, if you include physical layout then circuits that have the same components will look different if drawn different. With the netlist, a generic comparison is not only possible it's probably the simplest way since it only contains information about the parts and their connections. The only variation then would be the node numbering.

 

Hi,

Well, if you include physical layout then circuits that have the same components will look different if drawn different. With the netlist, a generic comparison is not only possible it's probably the simplest way since it only contains information about the parts and their connections. The only variation then would be the node numbering.

When the .asc and .asy files are read a netlist is created in memory during this process. You are correct that one way or the other the netlist is the basis for doing the circuit structure comparisons.

 

Since netlists are a kind of graph, I have been researching techniques for finding patterns in graphs. The research quickly uncovered that searching for patterns in graphs of chemical structures is a standard technique in chemistry. Since you point out the similarity between searching for patterns in circuits and searching for patterns in chemical structures, I am going to look more closely at how the searching of chemical structures is done.

As for searching by similarity in function instead of by identical structure, my thought is to implement identical structure search first then start thinking about how it can be expanded towards searching by similarity in function.

It depends on what the netlist represents.
If the schematic netlist represents circuit connections, then there is no graphical or physical representations within, unless its proprietary. In terms of a Spice netlist...there is no graphic info contained in a spice netlist.

 

It depends on what the netlist represents.
If the schematic netlist represents circuit connections, then there is no graphical or physical representations within, unless its proprietary. In terms of a Spice netlist...there is no graphic info contained in a spice netlist.

Before we go too much further in the process of developing a circuit search engine it would probably be a good idea to create definitions for the terms we will be using. I agree that a schematic netlist does not contain any graphical or physical representations. By "circuit structure" I mean just a circuit's (or subcircuit's) connections with the connections being logical nodes and not physical terminals.

 

Before we go too much further in the process of developing a circuit search engine it would probably be a good idea to create definitions for the terms we will be using. I agree that a schematic netlist does not contain any graphical or physical representations. By "circuit structure" I mean just a circuit's (or subcircuit's) connections with the connections being logical nodes and not physical terminals.

Agreed.

 

When the .asc and .asy files are read a netlist is created in memory during this process. You are correct that one way or the other the netlist is the basis for doing the circuit structure comparisons.

Hi,

Then we just have to figure out how to deal with different node numbering for the same circuit, and different component numbering.
We could have a circuit with two resistors R1 and R2 that both have the same value 1k but in one circuit the numbering is swapped, so in circuit A the resistor R1 connects to nodes 1 and 3, and R2 connects fo 5 and 6, but in circuit B R2 connects to 1 and 2 and R1 connects to 5 and 6. Same values so the two circuits are the same.
We could also have R1 connect to 7 and 3 in circuit A, and in circuit B R1 connects to 5 and 8, yet they are the same circuit exactly.
So we would have to think about how the different morphs can be the same.

Maybe just start with the component base label such as "R". Make every R like R1, R2, R3 just R, R and R, then see if they connect in the same way that the comparison circuit connects them. If so, check the values. If not, we dont have a match already.
So with a netlist like:
V1 0 1
R1 1 2
R2 2 0
to compare that with a netlist first count the elements, if they both have the same number of components that passes test 1. IF they have the same number of resistors, caps, inductors, etc., that passes test 2. If the components connect in the same way that passes test 3. If the components have the same values, that passes test 4.
If test 4 fails, have a degree of similarity factor come into play based on how different the values are and then classify it.
If it completely fails any test then it would be classified as a different circuit entirely.

Another idea is to form a reference grid. This would help categorize the nature of the topology. A grid that is big enough to contain the entire circuit would be the starting point. On each grid line one component would be 'placed'. There would have to be a third dimension though to handle non planar circuits.

Could get a little complicated but that's how it is when a program is to be made that has to mimic what humans can do. It cant be too bad though as there are programs that can analyze circuit responses so...
That reminds me, the analysis itself could help to categorize the circuit type.

 

Maybe just start with the component base label such as "R". Make every R like R1, R2, R3 just R, R and R, then see if they connect in the same way that the comparison circuit connects them. If so, check the values. If not, we don't have a match already. <snip>

Another option is to look at the units of the components instead of their labels. For example, the following code classifies components by the units of their values:

In> Resistor?(1`kΩ)
Result: True

In> Capacitor?(1`kΩ)
Result: False

In> Capacitor?(2`μF)
Result: True

In> Inductor?(2`μF)
Result: False

In> Inductor?(3`mH)
Result: True

 

Another option is to look at the units of the components instead of their labels. For example, the following code classifies components by the units of their values:

In> Resistor?(1`kΩ)
Result: True

In> Capacitor?(1`kΩ)
Result: False

In> Capacitor?(2`μF)
Result: True

In> Inductor?(2`μF)
Result: False

In> Inductor?(3`mH)
Result: True

Hi

I think before deciding on any of this, the type of netlist being read needs to be determined. It will make a difference on how the component statement will be parsed in the netlist. What is the type of netlist?

 

I think before deciding on any of this, the type of netlist being read needs to be determined. It will make a difference on how the component statement will be parsed in the netlist. What is the type of netlist?

The netlist of the simulator I will be enhancing to enable circuit searching contains:

1. A list that contains one CircuitElm (circuit element) object for each element in the loaded circuit. Each CircuitElm object contains the element's type (Resistor, Capacitor, etc.), the x,y location of the end of its leads, its value, and its SI unit.
2. A list of nodes with each node containing a reference to the CircuitElm objects that are connected to it.

All of this information can be used when doing pattern matching. The bottom part of the following diagram presents node connection information from the list of nodes and element position information from each element's CircuitElm object:

 

On Wednesday I started writing code to read the data in an .asc file into my experimental circuit simulator. @Papabravo sent documentation on the .asc and .asy file formats to me a couple days ago and it is making this process go much faster than it otherwise would be. So far support for unrotated resistors and capacitors has been implemented.

Here is a test .asc file I created using LTSpice:

Version 4
SHEET 1 880 680
SYMBOL res 48 48 R0
SYMATTR InstName R1
SYMATTR Value 101
SYMBOL cap 48 144 R0
SYMATTR InstName C1
SYMBOL res 288 128 R0
SYMATTR InstName R2
SYMBOL cap 208 32 R0
SYMATTR InstName C2
SYMBOL cap 160 192 R0
SYMATTR InstName C3

and here is what this file looks like loaded into my simulator:



At first I thought I would need to also read each component's .asy file. However, since my simulator has its own code for drawing components all I needed to do was obtain each component's length from its .asy file and put it into the program itself.

 

Here is what I've got:

View attachment 216586

I just keep adding folders with a leading index number corresponding to numbered divider tabs in a 3-ring notebook in case I decide to save any hard copies.

It seems that mere mortals (that includes EEs and hobbyists) would be the happy users of something like you propose. In my computer I got a similar one, obviously much humbler and simpler.

 

I took a snapshot of my LTspice "...\examples" and "...\lib" folders, and the .7z file is 70 MB. If anybody wants it to experiment with or whatever just let me know.

I just wrote a program that counts the number of .asc files that are contained in the "examples" directory which is in this archive. It contains 3573 .asc files!

 

My experimental simulator is now able to read resistors, capacitors, and wires from .asc files with full rotation capabilities. It is also able to locate all .asc files that are in a given directory. So far the development of this circuit search engine has been very exciting!

The next step I had planed was to make a small web application which would enable users on this site to start searching the 3573 .asc files that @Papabravo sent to me.

Unfortunately the AAC User Agreement and Terms of Service do not permit links to web applications to be posted in the AAC forms. Therefore I am moving this conversation about the development of a LTSpice circuit search engine to another website that has a forum or email list. Does anyone have suggestions on other places the conversation can be moved to?

 

My experimental simulator is now able to read resistors, capacitors, and wires from .asc files with full rotation capabilities. It is also able to locate all .asc files that are in a given directory. So far the development of this circuit search engine has been very exciting!

The next step I had planed was to make a small web application which would enable users on this site to start searching the 3573 .asc files that @Papabravo sent to me.

Unfortunately the AAC User Agreement and Terms of Service do not permit links to web applications to be posted in the AAC forms. Therefore I am moving this conversation about the development of a LTSpice circuit search engine to another website that has a forum or email list. Does anyone have suggestions on other places the conversation can be moved to?

groups.io, the successor to yahoo groups