Thinks IDE vs thinking CAD - WIP
This post is full of hard statements; when you right a concept, you can’t check everything. This means there could be discussion.
CAD approach vs IDE approach
Here we don’t mean CAD specifically as a CAD software; we take software toolkits for building something that have CAD functionality. KiCAD is EDA, though a big part of it is CAD. Electronic design, computer-aided design… Indeed, the main difference lays in the design term here. We can build a very complex explanation, but we won’t. When you have design thinking, you first create a presentation, some view of what you’re going to create. When you develop, you first make a model.
The main problem here is that when you describe a model, you first think how you will process it. If it’s suitable or not. Would it be easy to perform it’s automatic transformation? Thousands of problems are solved just by the fact this model can be automatically processed by something.
When you design, you jump to one of the final steps. How it looks, not caring about how it could be processed. Because an engineer will take your schematics (in fact, drawing), understand it and do this thouthands of things by hand. And check it. Or, sorry, we have a computer-aided design - you’ll draw it in CAD. That’s how you aid your hand-work.
Another thing is that automating approaches that come from pre-computer era isn’t always a good thing. Yep, that’s why computers were made, to automate. But it takes time to understand the proper language to talk with them. When somebody draw schematics on big papers with using kulmans, it wasn’t possible to use any automation except your eye, any analysis except your head and so on, and so on. But now things changed. You still have a model of your presentation first, you’ll still have your topology as a model.
Language that wasn’t found and understood
Any graphical presentation is actually a language; the only difference is that instead of words you have graphical symbols, instead of code file you have a painting, instead of language variation you have a specific designer with his own graphical language. If you’ve ever learnt the theory of arts and read Lotman, that’s ABC of arts for you. Though, painting is so-so a code - but PCB is much more a code file in that sense.
Let’s throw away all this metathors - your PCB is a code. Your resistors are variables, you sub-circuit is a function, and maybe your IP is a library. What’s next? Next is that any topology is a code in almost any tool. So why don’t we apply pure code concepts to the topology? No reason not to, though we don’t. What’s the result? The result is not having any Diff view except your eyes and no formal analysis except your brain. Almost. Was I talking about version control? Oh, yeah, man, you have your .zip files, you’re old school.
This hipsteric sentiment leads us to the next thought. In software development a single issue can be costy, though not so much. But what if a series of car head units must be completely reassembled because of a single manufacturing mistake? Yep, we have zillions of $ here. And that’s why we need another approach, more safe one, more from computer era. No kulmans, man.
Code
File format
Nobody actually cared about specific topology serializing before the era of version control systems. And even after, since legacy formats were created. Lots of binary files, no public libraries for reading (because why one needs it). Separate directions of separate vendor-locked EDAs, same for CAD. Because they know better. Though, they don’t know how to write a gerber analyzer, so you won’t have it. Also Diff tools is not their strong point. So, no Diff, yeah.
Same situation happened with project file formats in IDE world. Or dependency description. Luckily, filesystem-anaware project files almost dead, since they don’t bring any single benefit and only lead to file choas in the project folder. But at least most of these files were textual and not binary. You know, even images become XML a bi through the time.
Long story short, we should have a pure code file for describing the topology, we should have the underlying description of the topology in pure code form. A langauge similar to OpenModelica is OK by the way.
PCB view is in fact just the presentation of this code. And what’s better - we can have as many presentations for the same core as we want, since after parsing the code we automatically have the model ready. Let’s take the graphic representation as a second main view of our topology code - we are designers first, you know.
Completion
Completion in the programming languages is a complex topic, though it’s also pretty simple. The complexity are completion types appeared through the time (like postfix completion in JetBrains IDEs). The simplicity is the fact that basic completion filtering the code tree in a concrete place is usually enough to write the code.
But which parallel can we have for the completion in the graphical interface showing us our PCB topology? Let’s take this brilliantly simple LM358 opamp datasheet as an example of the completion we can have there.
Let’s imagine we’ve placed the LM358 alone on the PCB. What’s gonna happen? Nothing, we’ve just placed a random component. Let’s click it’s ground leg and invoke a completion… You see it? In any circuit, empty or not, you’ll probably have a limited amount of variants of what to connect to it’s ground lef. It’s either ground or one of the split supplies. In fact, concrete amount of cases isn’t important here. We can reduce this cope and suggest at least some typical cases. Will it help? Yes, of course. What about voltage supply? We can also suggest some number of connections, and in case the voltage supply is selected, we can suggest the typical voltage. When this voltage is selected, we can check the circuit around for voltages higher or less than a selected ones…
What if we invoke smart completion on opamp that isn’t connect anywhere? We probably should have one of typical circuits generated for it. Indeed, haven’t your placed it here for a reason or you just want it to stay on the PCB to hold the place? So, you probably need some variant of it’s usages, right?
What if you’ve decided to make a real amp circuit with this opamp and you need a specific coefficient of the amplification? Probably we can handle resistors automatically, right, even if a single one is placed?
And here what happens when you start working with the model: you can process it, predict it parts, and even more. This thesis applies not only to analogue components, of course. When you design yet another schematic with a random STM32, you’ll probably have some parts of the schematic actually predefined. You should be able to complete them automatically when placing the component on the initial schematic.
Components / library optimization
There is a feature called *Optimize imports in IntelliJ IDEs that removes not needed libraries included on top of some language file. For C++ it removes unsed #import or #include librarie; for Java it deals with import some.package; instructions; for other languages it removes their library usages.
How can we apply such a concept to our schematic project? If we have a model that tracks usages of external components added via some library, we can detect that specific component was put at some point, but is never used now. We can remove it from the project and optimize the size of project, avoid the mess with components added by somebody somewhen (say, 20 years ago) for not clear reason.
Formatting
Though code formatting is much easier compared to the schematic re-formatting, we still can do it. We can reorder components on the schematic at least to avoid intersections for connections; we can keep components not that close to each other; and what we can 100% to do is to place all the needed component labels so that they look good and unified. So, even here we have a field of applying pure code conception to the schematic editing.
Reordering
In IJ IDEs you can reorder code lines - you invoke the shortcut that moves the whole line up or down, automatically inserting it to the place needed. It removes the need to copy-paste. Why can’t you do it on the schematic? You obviously should be able to do that.
There is a more complex reodering - moving a statement. For example, the whole method inside the class by changing the method order. And more - they key here is that such reordering is based on the code structure. This way you avoid manual selection, and again - avoid copy-pasting. Why can’t we perform the same on circuit parts? Nobody applied such a concept to EDA. How many times you’ve dragged yet another part of circuit and rebuilt the same connections you’ve just set just because you want it in a bit another place?
Multiple carets / selection
What if you have 30 resistors in the near scope and want to change their values all at once? If you had analogue of multiple carets in IDE, you could do it by several shortcut invocations and just typing a new value once. Right now you will need to type it multiple times and select each resistor separately.
Expand \ shrink selection
There is a kind of selection that select inner/outer code statement based on the code model. This way you don’t care about code formatting, manual selection of lines and so on. Be warned - the implementation in VSCode that you’ve probably used is very bad. The right one is again in IJ IDEs. But what do we have for schematics? Nothing. Oh, well, ctrl+shift+select multiple components, or drag the selection window. Very, very slow. And inefficient.
Quick documentation
It’s obviously documentation for the code variable or type displayed in a separate popup or in some toolwindow inside the IDE window. What about specific components on schematic? Yep, read the datasheet in a separate window.
There should a short note about separate windows. The short note is following:
Gosh, having a single IDE window is a breathe. Having tons of EDA windows is a goddamn nightmare.
Analysis
Or, well, so-called inspections. Let’s say it some useful automatic check that you run on your codebase to get tons of warnings and errors you’ll never fix (ho-ho). And it’s clear that we can have thousands of such checks even for the schematic. No value for resistors? No capacitance for the capacitor set? Missed earth polygon? Wrong symbol used for earth footprint? Yep, we can check it automatically, generate a report and, you know, do other THINGS.
But let’s stop jocking. There are such checks. They are usually not unified. They are performed on different steps of PCB creation. They are not that sticked ot industry standards. There is not CI integration. And that’s how we make electronic devices during last 30 years. Kulmans, man. Drawing, bro. Design, bitch.
Not even saying to have at least some highlighting for the schematic component with a warning.
Navigation
TBD