SDC? (Software Defined Connection)

The Auto-Router thread gave me a light-bulb moment… I think.

Now that Micro-Controllers and other software driven devices are commonplace, shouldn’t EDA tools take this into consideration?

Let me start with this idea:

I’ve got pins 1 to 5 that are software controlled. Any individual pin coud go to any pin on K1. Microcontroller J1 has a 0.01mil Pin Header Land Pattern, and K1 has an Omron G5LE Land Pattern.

The idea is to make direct connections between the devices on the PCB layout.

J1 Pin 1 to K1 Pin 5
J1 Pin 2 to K1 Pin 4
J1 Pin 3 to K1 Pin 1
J1 Pin 4 to K1 Pin 3
J1 Pin 5 to K1 Pin 2

Then, clicky an icon Update Schematic from PCB and labels are added to make the connections in Eeschema.

I’m just throwing out spitballs to see what might stick. Comments are very much welcome.

I think this would go under pin swap/gate swap.

1 Like

First, I find your relay a bad example. Neither the coil nor the contacts generally go directly to a microcontroller, but for example a multiplexed LED array (witout dedicated driver) or button matrix would be a better example.

My current solution / workaround is to first draw a “preliminary” schematic, then start with the PCB layout, and when it’s easier to route some tracks differently, I swap them manually in the schematic, update the PCB with [F8] and then make the final connection.

A part of the solution is also a dual monitor setup, or simply a big monitor. If you have enough screen area available to show both Eeschema and Pcbnew at the same time (also great for cross-highlighting) then this workaround is quick and simple.

I am a proponent of simplicity. I never cared much for pin or gate swapping, because the problem is too trivial. The workaround I use is easy, (no extra functions to learn) and it is robust. I have a tendency to make silly mistakes with functions I use only occasionally.

I can see merit for this when things get more complicated. When working with FPGA’s you can have many pins which have arbitrary functions (Although timing may be affected by swapping pins).
A counter argument is that when working with FPGA’s a schematic does not make much sense anyway. I very much like the Idea of SKiDL, where a netlist is generated by python code and the classical schematic is skipped. With a bit of an extension to SKiDL I imagine that netlist data can be extracted directly from Verilog or VHDL, or from the output of an FPGA synthesis tool.

Everything together, I think it’s not terribly important. Often you have either just a few pins and it’s easy to do it manually, or you’ve got big chips and want better tools.

1 Like

I do have an idea for reverse engineering PCB’s that has an overlap with this.

In KiCad-nightly V5.99 it is already possible to create new netlist information, or modify the netlist. If this can be combined with background images of a PCB (Top and mirrored bottom for starters, also Full PCB, and depopulated PCB etc, ), then it would make reverse engineering a lot easier.

An extension of this is to make Eeschema and Pcbnew more symmetric. It would be nice to export a modified netlist from Pcbnew to Eeschema, and then show a ratsnets in Eeschema for the differences. This way you still have to fix changes manually, but it enables you to work in two directions when resolving differences between the PCB and the schematic.

So in your example, it would become:
Just put the “microcontroller” and the “Relay” somewhere on the PCB, and route easy to make connections between them. Then put the created netlist in Eeschema, and it shows you ratsnest lines of where to draw wires or place labels.

Sorry but I’m not quite seeing your point. However, an “autocomplete” feature would be interesting.

Select a component then Hotkey tbd to have Vcc, Gnd and either SPI or I2C automatically connected to that component based on reading the pin list for the device.
Some preferences would have to be configured.

It’s been discussed before, but boy does it get complex fast given simple SPI or I2C pinouts are a 8-bit micro thing and the moment you step into 32-bit ARMs, it goes very downhill fast. Especially lets say in one of my favorite micro families, there are multiple serial peripherals that can be assigned to multiple functions on multiple pins but if the peripheral which is “alt-muxed” onto some pins is there in one spot, then suddenly you cannot use it on a different set of pins also muxable to it.

1 Like

Aye, indeed.

I’ve toyed a bit with STM32 and stmCubeMX (only a very little bit) and often functions can be mapped to 2 or maybe three locations on the chip, but not arbitrary. And I assume that the other microcontroller families (Atsam, NXP, TMS320, and 20 or probably more others) have similar limitations.

And this brings it back to my earlier argument. It’s either to simple to bother with much, or it’s getting complicated quickly, and this brings it back to the reverse engineering tools. Being able to make (arbitrary) connections on the PCB and then show the ratsnest in Eeschema (or at least some textual form to list differences) both solves this problem (at least partially) and is also useful in other situations.

Good! The bad example was intentional, as to remove any pre-concieved notions.

This would require quite a bit of graphical programming,that may not be easily supported by the current code base.

What I did fail to do, was to map to other “child” devices. I’ll do that later and provide another screen-grab.

I should have clarified, the designer needs to define the micro in/outs for SPI. As subsequent devices are added, they are connected via a bus or global label.

I didn’t expect fully automagic.

I had a very similar idea years ago, and even wrote a small prototype: https://gitlab.com/pointhi/kicad-schematic-builder

Basically, the idea is to formulate the circuit “modules” and interconnections into an SMT formula and let an existing solver, like z3 create the pin assignment for you. In fact, this approach would allow way more than just that. For example it could:

  • Automatically select you components
  • Optimize for power-draw, costs, part-count
  • Build some power delivery network for you which would theroretically work
  • Bus assignment including ensuring all addresses are distinct
  • Ensure galvanic separation between circuit-parts
  • Ensure output/inputs are in spec (like 3.3V <-> 5V circuit parts)
  • Ensure input/outputs and special blocks of an MCU are valid (like only allow valid timer configurations)
  • … everything else you can encode in boolean/integer/array logic)

I didn’t continued for now, as I would need a way to define modules in KiCad and annotate them to be useful, but the theroretical foundation should be sound. The idea was that I could tell the system, like, I need something which has USB, GPS, bluetooth and a temperature sensor and it should be powered by an LiPo battery, and it will select me the optimum components and a working interconnection. It could theroretically even generate code to initialize all periphials.

The original idea came from Found a commercial automated schematic and pcb routing tool based on KiCad, and I concluded that automated schematic design should be computable feasable in practice. Simply because we can efficiently encode it in SMT.

2 Likes

It seems to me that pin-swap is a little bit more complex. I’ve been looking at what is already in KiCad, and I think my silly idea might be easy to code, while adding a completely new functionality.
Schematic:

PCB:

KiCad already recognizes the net name to the pin of J2. The only thing missing to complete the connection in PcbNew is the ability to recognize the connection to D1 pin 1.

Then have some method for pushing these changes into Eeschema.

You’re going even further than I’d considered. My concept was more “auto complete” than design from a few parameters.

I’ve got some standard modules saved. Then I can make a new hierarchical design by creating a new sheet and importing the standard modules.

Modules:
CP2102, Esp32, 3.3v ps, etc.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.