Roadmap

[slagernate]

Hi,

I am curious what the latest roadmap for magic looks like: which new features / improvements are up for consideration and what are their priority? This site appears to list some things, but with no ordering of priority (and was updated last ~22 months ago): http://opencircuitdesign.com/magic/ (need to click "Development" to see the proposed changes). Don't necessarily need an update on everything, just curious if there was a way for the community to discuss features / improvements (and what might be a good first PR for a potential maintainer).

As an aside/example: I think the Amaranth project has a pretty nice structure for the way the community can contribute:
https://amaranth-lang.org/docs/amaranth/v0.5.4/contrib.html.

Edit: perhaps there is intent to use the GitHub Projects bar here?

Thanks!
Nate

[RTimothyEdwards]

It's hard to find anyone comfortable with the code base and the obscure database and algorithms that operate on it. When such people show up and are willing to contribute, I'm happy to collaborate.

My current major short term goals are:

(1) Rewrite a couple of methods which are preventing parallelizing a lot of the magic code. One of the issues is that in a corner-cutting measure, I just modified the database in place during searches to facilitate the non-manhattan geometry. Bad long-term choice. That one's easy but tedious to fix. Another is a tile pointer set in the plane at the end of a search; Darryl has an idea how to get rid of that one.

(2) Then parallelize a lot of stuff, especially searches over planes. Just being able to fork off one process per plane will make magic roughly competitive in performance with any other layout editor out there.

(3) Fix a problematic construction where non-manhattan geometry shares two material types in one tile structure; this prevents it from assigning a net to each of the materials independently. This is hardly ever an issue but occasionally pops up in exotic devices with non-manhattan geometry like angled corners on gates or octagonal capacitors or similar. I had one idea that I think will work, but it changes the way non-manhattan geometry is handled and so impacts (1).

(4) Fix an error that was found recently where doing full R-C extraction with "extresist" ends up falling back on the old, simpler parasitic capacitance models. That's relatively easy to fix, but there are deeper issues with how to properly divide up parasitic capacitance among the many sub-nets created by the resistance extraction.

(5) Remove the stupid dependence of R-C extraction on the ".sim" file format, and get hierarchical R-C extraction working properly (doing the first goes a long way toward accomplishing the second).

(6) Handle the cells and files created by the parameterized cell generator better. Currently, changing a parameterized cell just creates a new cell, and if you spend a lot of time tweaking device parameters, the number of files containing no-longer-used devices keeps growing. I was thinking of just relegating all parameterized devices to a single file, which would keep all the randomized suffixes off of the filesystem.

The general cleanup of code is of course a major goal; it's not my goal particularly, as I'm happy as long as magic compiles. Darryl has been willing to take on that sisyphean task, so I've been happy that it is getting done, finally.

There is also a file TODO in the code base with some other items not mentioned above. I have not updated that file recently and most of the list above is more recent.

[RTimothyEdwards]

Part of the contribution/collaboration problem is rooted in my personal git repository that was created long before github even existed; it is all based on custom scripts and could use a major overhaul. I like github, but I'm not trusting enough to make it the primary location of my life's work in software development and open-source hardware advocacy. Hopefully that's an understandable paranoia.

[dlmiles]

Maybe consider a docker image that runs gitolite/alpine3_21 (I use modified/updated https://hub.docker.com/r/jvstein/gitolite ) which exposes an SSH port, that you might connect as a repo like git remote add myserver ssh://[email protected]:12345/mydir/myproject.git. Then you can setup to connect to locally or over Internet (if you expose application specific SSH port, pubkey auth only and only speaks git protocol, potentially firewalled with a port-knock infront, EL package knock-server, then I have a cell phone app to knock-knock if I am at an unusual location, or I white-list - ssh is pretty secure and hardened if left open, but will get attacked all day).

git is the ultimate distributed backup.

This removes the personal git repository part (which I assume is a cli based setup with scripts) and it turns into a remote repo accessible over ssh, which feels much more like GitHub but without the website, so all the things you can do from the git command CLI.

[RTimothyEdwards]

@dlmiles : I owe you feedback on the above but I am really swamped trying to get something out for the wafer.space tapeout. All good comments, and I would like to move forward with it sometime when I am not colliding with imminent deadlines.