Infinity Refactoring: revenge of the connect algorithmRichard Lin (Ducky) ducky edg edg-model edg-compiler refactoring
It's been a while since my last post, and although there has been some interesting work on more example designs (which just got sent to fab 🎉) that'll be another post for another day, hopefully with some fun videos.
But today, we revisit an old friend: refactoring the compiler. Again.
IntelliJ's find-usages-of is super useful for helping understand code. IDEs are really nifty tools for refactoring!
Folks, this is how the software sausage is made, not by writing perfect code the first time, but by writing something good enough, and critically when requirements change and it's no longer good enough, actually going in and cleaning things back up again. We're at that second part.
Overall, the background is that incremental compilation can be super useful in enabling certain user interactions, for example trying a bunch of options, while minimizing the latency of the action - enough to make it feasible to run interactively (as opposed to batch - where the user kicks off a job, then switches tasks while it runs in the background). But this requires the compiler being able to pause in the middle of a design, effectively leaving holes in the output.
And this is where the connect algorithm comes back in. The current connect algorithm relies on the inner block being expanded, which is a problem if we want to leave it a hole. So refactoring needs to isolate processing across levels of hierarchy, including resolving connectedness on a port of a inner block that doesn't yet 'exist'. And fixing that requires fixes elsewhere - the rabbit hole goes deep, and I'll spare you all the details.