Schematic-less design entry: producing actual schematics

[SiliconWizard]

In a couple earlier threads (a while ago...) we talked about schematic-less design entry, the potential benefits and shortcomings, existing solutions and what could be done.
One of the exisiting solutions, for instance, is Skidl. As I said back then, I designed my own system and have completed a couple projects with it.

Obviously, even though there are a number of benefits, the fact you're not dealing with actual schematics can still be a problem, especially for sharing your design. It's much easier for most of us to just look at a schematic rather than some kind of textual representation.

I've thought about automatically generating schematics from the native representation, but that's a very complex task. Considered using graphing tools such as Graphviz and others. Using block diagrams generators such as the ones used in FPGA tools. But they are complex and don't really yield acceptable results for a typical electronic schematic anyway.

Automatic generators look too complex to write and in the end, probably not very useful.

So the next, almost obvious idea I got, was that it would be nice to just use an existing schematic editor that could import netlists, exactly like a layout editor does, except that instead of footprints, it would just insert part symbols and ratsnests for connections, that you could then arrange manually. If the netlist changes, you can re-import it, and only the differences would be added/modified, keeping the rest intact (exactly like a layout editor does). This way, you could generate schematics that look exactly the way you want, but are a faithfull mirror of your original design. It would exactly work like a layout editor, but for schematics, so there would not be really anything new to implement per se.

I guess there's just so little interest in this workflow that it's probably never going to be integrated in any schematic editor, but just thought I would throw the idea and see what people think (if any is interested).

[Pseudobyte]

I just don't see the point to be honest. I can't think of a situation where it would be easier to type out my schematic as opposed to drawing it. Modern EDA suites have all the ERC functionality built in. Even if you have some large complex design, you can break it into hierarchical blocks to simplify the visual representation. It is also very easy to reuse blocks from other designs.

[nctnico]

The idea is kind of interesting but I think that it needs to be higher level to be useful. Skidl is still at the assembler language level compared to -for example- C.
It would be nicer to be able to describe functional blocks instead of individual parts. Like 'Opamp_circuit' with inverting / non inverting gains, noise requirements, bandwidth requirements, etc which then synthesizes a circuit using the most optimal parts.

[T3sl4co1l]

It's been done before; Multisim has semi-live* schematic routing functionality.  It's somewhat more annoying than helpful, as it doesn't escape congested wires very well (leading to shorts), and tends to snap carefully hand-routed wires back automatically (over other wires and components that you don't want them on..).

*You drag things around, and when you let go it solves the routes.  I must say, it does all of this, faster than Altium 20 can even place a single wire segment...

This includes back annotation from Ultiboard -- you can alter the PCB netlist and pull it back into schematic.  Although, it's my experience it gets terribly, hopelessly confused in multi-sheet and hierarchical designs (as of MS11, the last version I used).  When it's placing new parts or net connectors, it seems to choose the ugliest possible locations, but it can indeed solve the problem -- or, at least try once and give up.

At least it's an easier problem, probably -- graphics are well defined shapes, usually orthogonal and snapped to grid, and overlapping can be tolerable, at least briefly.

Incorporating some higher level constructs/concepts would be cool -- distributing space between components, wires and labels following a heuristic (ala LaTeX); grouping wires on common paths into buses; prioritizing left-to-right signal flow and top-to-bottom power flow; etc.  Would be really cool; but yeah, not at all trivial to write, and at this level, maybe not real-time usable either.  (That said, speculating alternate routes on GPGPU time would be interesting.)

Tim

[SiliconWizard]

It's been done before; Multisim has semi-live* schematic routing functionality.  It's somewhat more annoying than helpful, as it doesn't escape congested wires very well (leading to shorts), and tends to snap carefully hand-routed wires back automatically (over other wires and components that you don't want them on..).

Thanks, never used Mutisim. Obviously implementation of this to be useful should be done with some care.

With this "netlist-to-schematic" approach I have in mind, I don't think there should be any fancy automatic feature. Just the ability to manually place parts/groups of parts and connect them with the help of ratsnests as with a layout editor. No automatic "routing", no messing with the already routed wires. (Some kind of "push and shove" for wires would be helpful though, but no more than this.)

Incorporating some higher level constructs/concepts would be cool -- distributing space between components, wires and labels following a heuristic (ala LaTeX); grouping wires on common paths into buses; prioritizing left-to-right signal flow and top-to-bottom power flow; etc.  Would be really cool; but yeah, not at all trivial to write, and at this level, maybe not real-time usable either.  (That said, speculating alternate routes on GPGPU time would be interesting.)

I've thought of something like this, but it's very complex. Even more complex than automatically placing text blocks like Latex does (and Latex is already not that simple.)
Started with existing tools dealing with graphs as I said, as the underlying algorithms for placing nodes and connections look like the basis of what we'd need here. But none of them are really enough to get any sensible electronic schematic out of them. In an earlier thread, I cited netlistsvg which looked like a possible starting point ( https://github.com/nturley/netlistsvg ), but it's much more limited than it appears, so not really usable at this point.

[djacobow]

I'll check it out. I started my career in semiconductors, where all digital parts of the circuit went to textual descriptions (either low level almost netlist or high level synthesizable behavioral) long ago. I still would prefer to work that way on boards. I'm actually surprised board folks cling to schematics. Text is easier to annotate, diff, search, etc. But folks like pictures, and I'll admit for analog circuits, they do help.

[SiliconWizard]

I'll check it out. I started my career in semiconductors, where all digital parts of the circuit went to textual descriptions (either low level almost netlist or high level synthesizable behavioral) long ago. I still would prefer to work that way on boards. I'm actually surprised board folks cling to schematics. Text is easier to annotate, diff, search, etc. But folks like pictures, and I'll admit for analog circuits, they do help.

Yep, we've discussed this in a couple other threads before. The benefits are many.
I have developed a tool like this a year ago or so. I've used it since then on a couple projects, and would like to be able to use it more. But there's always the problem of when you have to share a given design externally. People usually expect to see schematics. So this is the key problem: sharing.

For the higher hierarchical levels, block diagrams are OK, such as the ones generated by RTL-to-schematic tools for instance. But yes, for the lower levels with "analog" parts, block diagrams are more or less unreadable.

[SiliconWizard]

The idea is kind of interesting but I think that it needs to be higher level to be useful. Skidl is still at the assembler language level compared to -for example- C.
It would be nicer to be able to describe functional blocks instead of individual parts. Like 'Opamp_circuit' with inverting / non inverting gains, noise requirements, bandwidth requirements, etc which then synthesizes a circuit using the most optimal parts.

(We've discussed the point before in other threads, so I'm not sure it would be the place to discuss this here, this one is specifically about producing schematics, so let's try and keep it on topic...)

Just a point: Skidl being essentially a Python library can do exactly what you suggest. You can programmatically generate any circuit. Granted the library itself doesn't give you much but it still gives you hierarchical blocks and busses, so you can implement your own generators on top of it. You have access to the whole language. I think the few examples that are given for Skidl don't really do it justice. That said, I decided to develop my own tool as I wanted something a bit more elaborate and not Python-based. I can absolutely do what you suggest above. I have even included a couple of E-series functions so that it can automatically find existing resistor values for instance for a given set of constraints. I can write reusable parameterized blocks.

[nctnico]

That thought has crossed my mind too. Perhaps a library with generators could help to make life easier. Imagine you can add an SMPS chip to your design by just giving it some operational parameters (frequency, output voltage and current limit) and be done with it.

A way to group component numbers (reference designators) to allow easy placement on a PCB would be nice. More importantly being able to link components to a database would be very useful as well. That latter is essential for the logistics if you want to produce PCBs without creating the BOM manually. In that case you'd be referencing a database ID which is then translated into a component value and a footprint.

[T3sl4co1l]

With this "netlist-to-schematic" approach I have in mind, I don't think there should be any fancy automatic feature. Just the ability to manually place parts/groups of parts and connect them with the help of ratsnests as with a layout editor. No automatic "routing", no messing with the already routed wires. (Some kind of "push and shove" for wires would be helpful though, but no more than this.)

Ahh, yeah, so what's going on is, there's a single netlist that is the primary basis of the design.  The netlist is the first-class object, and SCH and PCB are derived from it.  There is no desync between SCH and PCB, or vice versa: rather, the graphics in each get out of sync with the netlist, and you must solve both, to complete both.

Which we traditionally do anyway, but instead of generating netlist from SCH, we could go in reverse.

The schematic of course being semantically optional at that point, and the PCB being the manufacturing goal.  Documentation and familiarity being a related topic, but one which can be discussed separately.

Since both are layout problems, the tool should provide layout assistance -- ratsnest, library symbols, ERC, shoving of wires or parts (optional), bus routing, etc.

I wonder if you could open two PCBs, using different variant footprints, and just hand-wave a PCB as schematic documentation.  In standard EDA, I mean.  PCB has everything that's needed: ratsnest, pins, traces, grids, graphical symbols, text...  Not so much graphics or color, though.

I think it's interesting that, say, Altium has, at least the awareness, that back annotation could be a thing; it will automatically do trivial things, like update part parameters, of course.  The differences report will list any applicable component, net, etc. differences, but it does not offer any solution for them -- you have to poke and prod at the design, at worst just guessing what's wrong, until they sync up.  (And as mentioned, Multisim is much more proactive on this front, if not very competent.)  Having a netlist-centric architecture makes this so much more obvious.

Y'know, I'd be a bit surprised if this doesn't actually exist anywhere.  There's plenty of differences, from awkward user experience to philosophical design, between EDA packages, that someone must've tried this architecture before.  Is schematic-centric design really so deeply ingrained that they haven't?

The history of EDA packages covers a long line of obscure and proprietary software; who knows?

Tim

[SiliconWizard]

Y'know, I'd be a bit surprised if this doesn't actually exist anywhere.  There's plenty of differences, from awkward user experience to philosophical design, between EDA packages, that someone must've tried this architecture before.  Is schematic-centric design really so deeply ingrained that they haven't?

The history of EDA packages covers a long line of obscure and proprietary software; who knows?

Yep, who knows. But as far as I've personally seen, alternative workflows such as this one are relatively rare and when used, in-house solutions only... (but if anyone has  a specific existing solution in mind, please share!)

Other than this, you got it, what I have in mind is exactly this: the design entry is not schematic-based, the layout is the main "output", and the schematic(s), only for (re)viewing/sharing purposes. The schematic and layout editor would essentially share the same structure, just manipulating different objects. I bet writing this from existing software (such as KiCad or other) would not be that hard. Just don't have time for this...

[Lukas]

Ahh, yeah, so what's going on is, there's a single netlist that is the primary basis of the design.  The netlist is the first-class object, and SCH and PCB are derived from it.  There is no desync between SCH and PCB, or vice versa: rather, the graphics in each get out of sync with the netlist, and you must solve both, to complete both.

Which we traditionally do anyway, but instead of generating netlist from SCH, we could go in reverse.

I'm glad I'm not the only one with these thoughts as the EDA software I wrote https://horizon-eda.org operates that way internally. For the time being, the only easy way to arrive at a netlist is to draw a schematic, but the option to generate the netlist from something else and then generate a schematic (only symbols and labels) is there architecture-wise.

[nctnico]

I'm wondering how this would work while debugging / verifying a board. Not saying it can't be done or it has to be done in a certain way. I'm just interested in ideas on how to work without a schematic.

[T3sl4co1l]

The inverse of a netlist, a component list, might be useful.  (That is, instead of calling out components and the nets they connect to: call out the nets, and the component pins they connect to.  The usual netlist view you get in a PCB editor.)  Or both together.  Maybe with some cross reference highlighting to elucidate connections and relationships between nets and components.  It's a compact enough representation that you could stand some chance of showing an entire design on one screen; I'm not sure offhand how impractical such a density could be.

Hierarchical or structural listing will be important.  Perhaps nets and components can be tagged with an ID or name for the user-defined subcircuit they form; perhaps this can be derived automatically, using graph locality / classifier methods -- which likely won't do a great job semantically, but where it differs from semantic intent could be very practical for PCB layout.  Configurable weights for buses and supplies would be helpful to tune that, I think (should buses be treated as a single net, a single higher-priority net, or should their nets be treated flat, individually?; supplies routed via planes should be deweighted, but supplies that are hand wired should have normal priority; etc.).

Mmm, some of these are really good ideas for any EDA tool...

Tim

[SiliconWizard]

The inverse of a netlist, a component list, might be useful.  (That is, instead of calling out components and the nets they connect to: call out the nets, and the component pins they connect to.  The usual netlist view you get in a PCB editor.)  Or both together.
(...)
Hierarchical or structural listing will be important. 

The tool I designed has both. (But I'll gladly take any idea that I may not have thought about yet.)

You can look up any "pin" (port) and get the corresponding net with all other pins/labels connected to it. Or conversely. You can also look up any pin/reference from the flattened netlist (so typically from the layout) and get the corresponding hierarchical names. So, for instance, U4 on the final PCB has a pretty hierarchical name that you can look up very easily. The lookup includes pin/pad matching, so for instance you can lookup "U4.15" (which would be pad 15 of U4 in the layout) and get something like "InputStage.DiffAmp.In+".

And of course, it's fully hierarchical. I can generate both a hierarchical netlist, and a flattened netlist (the latter being used for layouts and final reference assignment).

I must say I like this workflow now. The only thing missing, as the thread was all about, is a way to ease sharing designs with people that are not in the know.

[T3sl4co1l]

Cool!

How about relational data -- say, highlighting a net also highlights nets one degree of separation away?

Uh, subject to specified exceptions -- don't search through power nets, or huge or multipart components, for example.  Exceptions might also be crafted by differences between nets; very small nets (2 or 3 pins) are preferred, while huge nets (like supplies with 40-odd pins) are excluded.  The exclusion might be relative (so we see the 10 connections either side of a bus buffer, say), lots of tuning possible.

That way you can see, for example, a transmission line net, while also highlighting the nets connected to it via series termination resistors or filtering components.

Rather than looking into each component manually and trying to remember which other ones you wanted to look at, you see everything all at once.

It works both ways, of course; you might be interested in seeing the components in parallel with a given component, just as you might want to see nets in series with a given net.

It would indeed, as you say, be difficult to share.  "Unfortunately, no one can be told what the Matrix is. You have to see it for yourself..."

Tim

[SiliconWizard]

How about relational data -- say, highlighting a net also highlights nets one degree of separation away?

Uh, subject to specified exceptions -- don't search through power nets, or huge or multipart components, for example.  Exceptions might also be crafted by differences between nets; very small nets (2 or 3 pins) are preferred, while huge nets (like supplies with 40-odd pins) are excluded.  The exclusion might be relative (so we see the 10 connections either side of a bus buffer, say), lots of tuning possible.

That way you can see, for example, a transmission line net, while also highlighting the nets connected to it via series termination resistors or filtering components.

That idea is interesting, and I've - kind of - thought about it especially when I was working on the ERC part. (But as you mentioned, there would be other purposes for this as well!) So I have actually thought about that for power nets!

For instance, if a power input port is connected to a power net via some series component (resistor, inductor, ...), then ERC will flag a warning because as far as ERC can see, the power input port is connected to a "passive" port only. Being able to follow net "paths" beyond direct connection would definitely be interesting but it would require the use of rules - not that simple in the general case. But definitely something I'd like to add.

As for huge nets - I have implemented flexible busses, so you can manipulate an entire bus very easily. For instance you can define the power pins of a given part (like a part with dozens of Vdd or GND pins) as a bus. Then there is a way to express the connection of all pins of a bus in one go. Then as long as you are at the hierarchical level, the nets will list busses instead of separate pins.

It would indeed, as you say, be difficult to share.  "Unfortunately, no one can be told what the Matrix is. You have to see it for yourself..."

Yeah. We can always choose not to care.
But you run into A LOT of resistance in the general EE crowd for this kind of workflow.

[SiliconWizard]

Ahh, yeah, so what's going on is, there's a single netlist that is the primary basis of the design.  The netlist is the first-class object, and SCH and PCB are derived from it.  There is no desync between SCH and PCB, or vice versa: rather, the graphics in each get out of sync with the netlist, and you must solve both, to complete both.

Which we traditionally do anyway, but instead of generating netlist from SCH, we could go in reverse.

I'm glad I'm not the only one with these thoughts as the EDA software I wrote https://horizon-eda.org operates that way internally. For the time being, the only easy way to arrive at a netlist is to draw a schematic, but the option to generate the netlist from something else and then generate a schematic (only symbols and labels) is there architecture-wise.

Yes, I've evaluated Horizon before and it's an impressive piece of work for a one-man (AFAIK) development.
True that many EDA schematic editors still do not embed a netlist representation internally, they rather generate netlists from the graphical items and their relative position. This is kind of odd, but comes down IMO to the fact that circuit design to this day is mainly still shematic-centric, and more than that, "drawing"-centric, meaning that the basis of a circuit design is still considered to be just a drawing. Like people did before they used computers.

Have you implemented export to some vector graphics format yet? If you added the "netlist import" function as mentioned above in the schematic editor and some vector graphics output such as SVG or EPS, then I'd definitely have found what I'm looking for here.

[EEEnthusiast]

HDL would work well for digital circuits but never for analog and mixed signal circuits. The visual feel of a circuit can never be fulfilled by a text document. For digital designs, HDL works out well as the logic can be described well in many languages.

[nctnico]

HDL would work well for digital circuits but never for analog and mixed signal circuits. The visual feel of a circuit can never be fulfilled by a text document. For digital designs, HDL works out well as the logic can be described well in many languages.

I tend to agree but OTOH I have the feeling this agreeing comes mostly from being set in old ways.
After all, what is the difference between describing logic or an analog circuit? I think the biggest difference is that the approach will me more like developing software. Starting at a high level and then using functions to add more details in every layer until you end up with parts. When dealing with a software project (including VHDL) I use an IDE which allows to traverse through the functions and variables in order to keep an overview of what is where.