Text-based schematics?

That's a natural desire to make diagramming more efficient : )

(I guess you don't mean HDLs, since the output from them usually you wouldn't want to convert down to a schematic more detailed than a block diagram, i.e. not at the level of say discrete components in an analogue circuit for instance).

Over the years, I've tried automating diagramming many times, with varying results.

For instance, there was a period where I wanted nice message sequence diagrams, so I automated that, not using SVG at the time, but some other graphical language or format which I can't recall.

Simple block diagrams are fairly feasible directly typing SVG, with no higher-level language. I wanted a resistor color code, I did that in raw SVG, it was simpler than manually drawing it.

The SVG looked like this:

Another time, I wanted to sketch out some sort of timeline of activity, and that was quite successful, it was quite elaborate, using a mySQL database to store lots of timestamps and event names, and then plotting from that, and having the ability to click on the graphic and identifying the full entry in the database. This sort of stuff is great when there are thousands or tens of thousands of events.

I think there's a lot of potential nowadays with languages such as Python so that diagrams could be programmatically created (and it would be possible to write higher-level functions to (say) place a specific component etc), but I've often found I prefer to tweak things myself, and for the high-quality diagrams, I stick with PowerPoint. For instance, I won't always center everything, because some things just visually look better eyeballed, even though they are not technically aligned (same reason old classic cars look nice with their french-curved metalwork rather than perfect computer-made curves. That's the sort of thing that would get awkward to do programmatically without many iterations in code, until it looked visually right. I think you hint at the same problem when you mention the problem of labeling things, because although there's a desire to just focus on logic, there's also another desire, to make it visually pleasing too, and that will still need the human input to nudge things one or two pixels, or move a node a fraction to the left more than a computer may have done, and so on. I actually do the same thing even with computer-drawn charts. If I'm using Matlab, then I'll edit the graphic output, because I like nudging the values on the axis a little bit different to what the computer did! I don't think anyone has ever noticed that though, but nevertheless it makes me feel better knowing a chart has been tweaked to what I feel at the time is just right!

Example below; the text "1MHz" has been nudged to the right compared to what Matlab would have done by default, i.e. rightly or wrongly, I preferred to trust my sense of what looks visually better, more than the software.

If it's a simple schematic, then I like using PowerPoint (since I've got shapes for most of the basic components already drawn over the years), otherwise I'll draw in KiCad.Over the years I have plenty of basic shapes drawn in PowerPoint, e.g. MOSFET example below. For sure I could construct that in a programming language, but I bet I'd still want to tweak manually.

Anyway, back to Python; one method I've used on occasion, is to use it to create the desired diagram, and then edit the generated SVG output in (say) Inkscape. However, it's a one-way thing, i.e. if any changes need to be made, you'd have to either start from the Python code again and then again modify using Inkscape, or, just make further changes to the output, and accept that the Python code wont be used again, it has served its purpose for originating that particular diagram.

Also, KiCad supports Python, so technically it may be possible to use that to directly create a schematic, but I've never tried that. I've done a few basic things with Python with KiCad, it's for sure powerful, but I'd be speculating if I suggested it's possible today to entirely build a schematic using it. I think it could be a lot more effort than just manually drawing the schematic though.

At university they made me describe schematics in text with SPICE, unfortunately the graphical tools that have been created on SPICE have features that are not compatible between different programs based on SPICE. You could maybe try AI-based assistants like flux.ai.

Flux Copilot - The First AI Powered Hardware Design Assistant

Interesting topic.  I think with analog designs involving opamps and transistors schematic entry would be more efficient than text entry.  In a digital design where you have a series of bussed signals I could see text entry being faster.  Arguably the hierarchical methods in HDL languages could be used for this.  Where you define a component in terms of it's inputs and outputs, along with top level nets for interconnecting between components.  Then you could use 'port mapping' like in VHDL to tie everything together.  Ideally the tool would generate a nice schematic as an output to this text entry so that it's easier to visualize for the person doing the layout.

I find the interconnect in HDLs completely incomprehensible.

So I use a block diagram editor at the top level to hang all the blocks together but I find the HDL much better at describing the logic.

I know that some other people find the opposite.

I certainly can't imagine doing analogue design in text.

I would post an example but I'm supposed to be getting a big design to work right now so no time

MK

You are not alone with this.  I too have used block diagrams for the very top level.  Sometimes when I am looking at the higher level hierarchical code developed by another person I will translate it into block form manually on piece of paper as a way to help commit the names of the blocks and signals to memory. 

I think of E-CAD as "word processors" for electronic design and I have my own conventions to make schematics "readable". I can't imagine a text base description language that would be as clear or readable. CAD systems have many tools to minimize the work and show connectivity at a glance and there are a lot of tricks to making the design process quicker and more readable. There are some conventions like making signals flow from left to right and top to bottom, but you are right, to make a schematic into something easily readable takes work. I can't resist cleaning up schematics to minimize corners and crossovers, even though it takes time. I find many techniques used to reduce schematic clutter (such as connections made with labels instead of wires and busses shrunk to a single line) to be confusing and time consuming to decipher, so I only use labels when making connections to a new page. I would actually rather make a bigger page than add more pages.

dougw said:

I can't resist cleaning up schematics to minimize corners and crossovers, even though it takes time.

It takes self-challenge:
"Am I doing this because I can't sleep if there are cross-overs that can be avoided" or
"Is this diagram clear enough that my colleagues (or me in 7 years) will be able to understand it".

Good Enough is a valid KPI for efficiency improvements.

Doesn't KiCAD have some underlying text base?

yes, although the structures are intended to support the graphic tools, the workflow and the manufacturing files.

I don't see those getting generated by a text based front end. (in an achievable way)

Every designer has their preferences and their productivity. I always have a pause before a final check prior to sending a design to be manufactured. During that final check I clean up both inefficiencies and weaknesses in the design, even if they won't likely affect performance. Or I might add in more test points or more intuitive labels. I not sure exactly how important all this is in circuit functionality, but I do catch some errors and the results are high productivity with a high chance of the PCB working. Other designers have different methods and performance, but that doesn't mean they would have better (or worse) performance using my methods..