Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Am I understanding correctly, this is kind of like code generation (which is roughly a compiler that takes some sugared language and produces unsugared code that's usually incredibly ugly / indecipherable), but the input is some sugared language and the output is board designs?

Do the board designs you output look alien / weird to people who have been laying out boards by hand / with conventional EDA tools? If so, is it causing any resistance to JITX adoption?

A common creature comfort requirement for anything that transpiles / codegens, is source maps so that while debugging you can see the lines of code that you(r team) typed, rather than harder-to-read generated code. Have you thought of trying to bring that concept to JITX?

Super interesting, thanks for posting this.



Code generation is a good analogy - nice high-level code in, CAD design out. The 'sugaring' is implemented in a macro system that generates an Intermediate representation we designed for electrical systems (kinda like LLVM for hardware).

JITX only produces weird-looking designs when they are provably correct and of high-performance. You can't throw an indecipherable mess to an EE and ask them to spend time understanding it. That's just not a productive way to design. There's a lot of work we do to make a design legible, including generating a schematic for the user to read.

Yes! Our 'source-maps' connect the generated design checks, board, and schematic back to the originating line of code. So the user sees the output they are familiar with (e.g. schematic), and can trace it back to the line of code it came from. Collaboration in a team happens more at the source-code level, and we make sure that the same CAD design gets generated when that code is run.


Thanks, this is amazing work!




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: