Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spice netlist not exactly the same for the same circuit #4172

Open
failiz opened this issue Sep 22, 2024 · 3 comments
Open

Spice netlist not exactly the same for the same circuit #4172

failiz opened this issue Sep 22, 2024 · 3 comments

Comments

@failiz
Copy link
Contributor

failiz commented Sep 22, 2024

Problem

The same circuit (I tried with flipflop_led_flashing_circuit) does not produce the same results all the time. Launch Fritzing and observe how the circuit behaves differently (sometimes the green signal spikes first, other is the blue one). This is a tricky circuit and chaotic in the beginning. It seems that the order of the components in the spice circuit matters in this case. I exported the netlist of the two behaviors and they are different (components are placed in different places):
{3975F299-C3A0-4787-8BE5-337F217EBB2B}

Proposed Solution

Make that Fritzing always produces the same spice output. In this case (the order of the components), it is just annoying, but changing the name of the nodes of the circuit could have strong consequences if we go for loading new netlists every time there is a user interaction in the circuit.

@failiz
Copy link
Contributor Author

failiz commented Sep 24, 2024

And now I tried to change some wires while doing a transitory simulation. I moved a wire in the breadboard and it created a spice netlist where the name of the nodes are different, see below:

{BB5EBE33-D5D6-43E3-BFDC-AB47EACC20B2}

This means that will not be able to modify wires during the simulation. Not sure if there is an easy way to make the code to make it deterministic. Please, note that the netlist should be identical as I am changing one view (BB) but the items are still connected in the other (SCH).

@KjellMorgenstern
Copy link
Member

KjellMorgenstern commented Oct 1, 2024

This might be introduced by usage of QSet or QHash when generating the list.

We had a similar problem with the search in sketch feature. Before 1.0.3 it often resulted in irritating matches.
After we prioritized exact matches over substring matches, we still had to make sure the result stays in order when de-duplicating and looking up the view items. For this, the KDToolBox::DuplicateTracker class was very useful. See 25b3f72

@failiz
Copy link
Contributor Author

failiz commented Oct 1, 2024

It is not introduced by QSet or QHash. I modified the code to use a list instead of a Set, and it still happens.

I think it is caused by the scene()->items() which is used to generate the netlist. I am calling it from the schematic sketch view, but there are connectors from other views too. (If I remember correctly Fritzing, makes a wire for each of the views). And thus, modifications on the breadboard view (e.g., removing a wire or adding a new wire not connected in one end) produce a different list of connectors items to generate the netlist (even though the "netlist" electrically is equivalent), but the order of the components and the name of the node changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants