freenode/#clim - IRC Chatlog
Search
15:41:02
lukego
I'm writing a program to output a printed circuit board design. I'm trying to do it in two main steps: decide where the components go and then decide how to connect them together.
15:42:12
lukego
For each component I need to pick a position on the board and then draw the "land" for its "footprint" there. That basically means to draw some ink that marks where the copper pads will be for soldering the part onto. So basically I'm drawing the yellowey golden bits of a picture like this: https://file.pcbway.com/websponsor/18/08/29/165932718_Top.png
15:44:00
lukego
Producing an actual drawing like this is important -- I can review it on the screen and I can also send it off to a fabricator to produce the PCB, which is the ultimate goal of the whole endeavor.
15:45:05
lukego
However, I also need to do a separate "routing" step to make all the necessary conncetions between these golden pads. That means basically to draw the dark green lines and make sure they follow all the necessary rules e.g. don't intersect.
15:46:57
lukego
and I'm thinking that the input to the "routing problem" will be basically the set of all those golden pads, including their positions, and the set of connections between them that have to be made. So I need to "reverse engineer" out of the image e.g. the locations of all golden pads that reprsent "Ground" or "1.2V power"and so on
15:48:22
lukego
aaaand the routing will be done on a separate data structure, something called "corner stitching" that I'm knocking off from Ousterhout's ancient 80s/90s CAD stuff. So I need to convert from this very concrete pixel-based repreesntation into a somewhat more abstract cell-based topological one
15:49:04
jackdaniel
I would start with the abstract cell-based topological representation and define presentation methods present on them
15:49:52
jackdaniel
you will still have the output record hierarchy generated from the abstract representation, and you could modify present methods or instances parameters to tweak the board
15:55:10
lukego
That's definitely what I'd do with a regular GUI toolkit. However I'm wondering if a CLIM sheet would make a reasonable data structure for "defining the problem" i.e. placing all of the golden pads that will need to be routed. The downside is that I need a conversion routine to translate that into a topological representation. The upside is that I can use CLIM's convenient drawing functions for defining the pads
15:55:59
lukego
So for example in your example code above ^^^ the repetition of left/right/top/bottom is relying on CLIM transformation functionality that I'd presumably need to write by hand if I "ported" this code to the abstract representation instead
16:00:45
admich
I have seen that recently the mirror of a sheet is no more the x11 window but an object clx-mirror. Is it correct respect to the spec? What is the benefit of this indirections?
16:02:00
jackdaniel
admich: it is correct, spec says that the mirror is not defined (so it is a backend-specific object)
16:02:32
jackdaniel
regarding benefits, I'm implementing xrender-based mechanism with double buffering, so I want to put a pixmap in clx-mirror as a backbuffer
16:05:06
jackdaniel
admich: regarding sheet geometry: http://turtleware.eu/static/paste/3a5704e8- (demo wip)
16:05:26
jackdaniel
slyrus was interested in it, afaik Krystof did implement it partially, but the source code is lost :)
16:07:34
lukego
jackdaniel: Here's a quick hack approach to converting CLIM output records back into geometry (rectangles) tagged with metadata (presentation objects). maybe not so nasty? https://imgur.com/a/bS0rmaM
16:11:40
admich
Eventually if I want to try to write a svg backend, what is the dependency policy? Can I use a library as spinneret or cl-who to produce xml code or better to use only format?
16:12:21
jackdaniel
admich: it is fine for backend to have dependencies (especially if it saves time and maintanance burden)
16:15:22
lukego
(Could also be that there's a simpler and more convenient drawing abstraction that I should be using e.g. turtle graphics instead of affine transformations.)
16:15:36
jackdaniel
I'm not sure how much of javascript is required for svg, but maybe cl-javascript (as a compiler) could be a sensible dependency too
16:17:35
admich
for an output only backend like pdf and postscript, I think javascript isn't necessary.
16:35:10
jackdaniel
lukego: I'm thinking about something like this: http://turtleware.eu/static/paste/be799619-legs.lisp.txt
16:35:38
jackdaniel
since all output is presentations, you could define commands - i.e add-pin and add-leg that works on the empty slot
16:36:07
jackdaniel
notice, that in the function #'draw we position the board, and the board operates in its own coordinate systems
16:36:22
jackdaniel
moreover, the board introduces yet another (inner) coordinate system for its pins etc etc
16:37:23
jackdaniel
you could get fancy and store the output record references inside each object (i.e leg holds in a slot a reference to its own presentation output record), however that doesn't seem to be necessary
16:38:59
jackdaniel
moreover, since these are presentations, you could define a multi-point drag-and-drop translator to manually set a route between pins
16:41:46
jackdaniel
now, if you define a command like this: (define-app-command (com-foo :keystroke #\space) ())
16:42:01
jackdaniel
then you may recompile the function draw, and after pressing space in the application window, it will get redrawn
16:48:19
lukego
jackdaniel: Is there an easy way to see the output records for this example? e.g. once it's already loaded on the screen can I somehow grab the output records in the SLIME inspector to see what CLIM did?
16:50:37
lukego
re: interactive commands, I'd like to be able to write a lot of commands for understanding what's going on in the diagram, e.g. showing all the pads that should be connected to GROUND, etc, but I don't want to do any "imperative" changes to the design e.g. placing pads or routing traces. I want to do that purely algorithmically.
16:52:01
lukego
but that's maybe also a grey area e.g. maybe I could click on something to change the parameters of the algorithm that routes it e.g. quickly test what happens if I'd rotate a part by 90deg and then if I like it I could add that constraint to the board-layout code.
16:52:58
lukego
(Maybe it's double gray area. If the board design "code" turns out to be mostly constraint expressions and parameters then interactively tweaking them might make sense while looking for the values to keep.)
16:59:42
jackdaniel
when you press space, it gets redisplayed, but if you press control+space, it will print all output records
17:04:12
lukego
So I think the next step for me is to write drawing routines for the different shapes of chips, then draw the ~100 chips that make up my design, then extract the ~1000 pin/pad locations, then write a function to create routes between them.
17:07:10
jackdaniel
this is somewhat improved example with interactivity: http://turtleware.eu/static/paste/85cbb9a8-legs.lisp.txt
17:07:50
jackdaniel
my old house collapsed, so this time I will build it starting from the smoke on the chimney
17:08:18
pjb
lukego: I would guess modern datasheets include the drawing and pin/pad positions. You can just download a database for them…
17:10:14
lukego
pjb: Genreally I'm doing the hardest and riskiest parts first but there are dependencies e.g. I need to define all the parts that I need, define what they look like, define guesstimated positions of them. that's what I've been working on. then I can route 'em.
17:12:09
lukego
yeah there will need to be some kind of a feedback loop there. I'm doing my placements using Screamer at the moment and I'm thinking that will be flexible for incrementally adding constraints ("move that towards bottom-left", "pick rotations for these that minimize intersections", etc)
17:12:12
pjb
lukego: you may have some constraints for the connectors for example, but the rest can be subject to the routing.
17:13:07
jackdaniel
n.b I'm quite satisfied with the defpresent macro, I will add it to my repl-hack-utilities :)
17:13:10
lukego
but I've spent enough time thinking about routing to identify an initial strategy to take from the litetrature ("Contour") so it's not a complete unknown.
17:14:30
jackdaniel
see how I've defined another view class that is default for the stream I'm drawing on
17:14:41
jackdaniel
otoh, when I right-click on the pin, the "textual" representation appears in the menu
17:15:37
lukego
"Contour" router is basically to shop the board up into tiles representing used and empty space and then find the pairs of things that need to be connected and do A* search from both ends in parallel until they meet. rinse and repeat. see how that goes... it's designed for VLSI and not PCB
17:18:37
lukego
I'm also currently "floorplanning" the board into discrete modules. that's mostly for divide-and-conquer purposes e.g. to have small enough domains to do Screamer backtracking searches usefully in. but also because a lot of good PCBs seem to be designed that way in practice. https://twitter.com/lukego/status/1363497447532675077
17:34:12
lukego
oh also, experience so far suggests it's easier said than done to import geometry from vendor datasheets, which means e.g. diagrams like this in pdf files https://imgur.com/a/aKsigfY and I'm still thinking hard about how to get accurate and reliable footprints. I think though that I'll start with cartoonish approximations for writing the router and then get the fine details right at the end.