This is pretty great, I love the concept of modeling circuits with code. I wish it wasn't Rust, but only because circuits are based on functional programming, so there's no need for the added complexity of mutability or the other imperative concepts that Rust goes to great lengths to support. But it's good to get a reference implementation done before exploring doing this in Lisp or something.
I'd also like to see if this attempts to address the drawbacks of VHDL and Verilog. When I used VHDL in college in the 90s, I remember that it had a lot of trouble with basic stuff like describing a collection of bits as a variable and expecting math on that variable to "just work". Like maybe I could connect a circuit directly to one of the variable's bits, but it acted flakier than if I connected it to a verbose circuit described manually. I think it had something to do with timing, maybe rising/falling edge stuff, or maybe something needed to be latched before it could be used, etc. And maybe some of that has since been "fixed", although the problem was probably user error on my part.
Anyway, I'd like to see a thin layer above hardware description languages that takes care of that stuff so that they don't have surprising side effects. It's kind of like how XML is more powerful than JSON because it can have its own types, but the industry discovered that custom types encourage anti-patterns, so now everybody just uses JSON. I need a circuit to be built as described, even if it has additional training wheels inside for my protection, and then an optimization pass would remove anything superfluous or maximize stability by converting to stuff like gray code (which is probably already widely supported). I feel rather strongly that this issue has set FPGAs back by at least 2 decades, maybe longer.
Hey, thanks! I wrote this in Rust because I am comfortable in it + proc-macros, but someone might port this to Lisp or such.
As I explained it in another comment, this aims to make it easier and more approachable for learners to learn about hardware. I (personally) feel HDLs can be a bit scary, and as this is in a higher level language, you get its familiarity and still get to think about pins and their connections and stuff.
As you mentioned , this is indeed choose-your-difficulty library. You can make everything out of gates, or as I did in my CPU demo, expose pins for connections, but do the internal processing using if-else and loops etc. (https://yjdoc2.github.io/pcb-rs-examples/) This allows focusing on stuff like how caches are invalidated on jumps and how waiting on memory takes CPU cycles etc.
Currently this does not translate to something that can be targeted to directly h/w like VHDL etc does. But hopefully this will make subject of hardware and low level systems more approachable and easier to learn.
Come to think of it, I remember wishing for something just exactly like this library when I was in college! There is something in what you are doing that bridges the gulf between imperative and functional programming. It's important work and I'm glad it exists in the world. So thank you!
Comments
This is pretty great, I love the concept of modeling circuits with code. I wish it wasn't Rust, but only because circuits are based on functional programming, so there's no need for the added complexity of mutability or the other imperative concepts that Rust goes to great lengths to support. But it's good to get a reference implementation done before exploring doing this in Lisp or something.
I'd also like to see if this attempts to address the drawbacks of VHDL and Verilog. When I used VHDL in college in the 90s, I remember that it had a lot of trouble with basic stuff like describing a collection of bits as a variable and expecting math on that variable to "just work". Like maybe I could connect a circuit directly to one of the variable's bits, but it acted flakier than if I connected it to a verbose circuit described manually. I think it had something to do with timing, maybe rising/falling edge stuff, or maybe something needed to be latched before it could be used, etc. And maybe some of that has since been "fixed", although the problem was probably user error on my part.
Anyway, I'd like to see a thin layer above hardware description languages that takes care of that stuff so that they don't have surprising side effects. It's kind of like how XML is more powerful than JSON because it can have its own types, but the industry discovered that custom types encourage anti-patterns, so now everybody just uses JSON. I need a circuit to be built as described, even if it has additional training wheels inside for my protection, and then an optimization pass would remove anything superfluous or maximize stability by converting to stuff like gray code (which is probably already widely supported). I feel rather strongly that this issue has set FPGAs back by at least 2 decades, maybe longer.
Hey, thanks! I wrote this in Rust because I am comfortable in it + proc-macros, but someone might port this to Lisp or such.
As I explained it in another comment, this aims to make it easier and more approachable for learners to learn about hardware. I (personally) feel HDLs can be a bit scary, and as this is in a higher level language, you get its familiarity and still get to think about pins and their connections and stuff.
As you mentioned , this is indeed choose-your-difficulty library. You can make everything out of gates, or as I did in my CPU demo, expose pins for connections, but do the internal processing using if-else and loops etc. (https://yjdoc2.github.io/pcb-rs-examples/) This allows focusing on stuff like how caches are invalidated on jumps and how waiting on memory takes CPU cycles etc.
Currently this does not translate to something that can be targeted to directly h/w like VHDL etc does. But hopefully this will make subject of hardware and low level systems more approachable and easier to learn.
Thanks!
Come to think of it, I remember wishing for something just exactly like this library when I was in college! There is something in what you are doing that bridges the gulf between imperative and functional programming. It's important work and I'm glad it exists in the world. So thank you!
I feel similarly, except that I am excited to see it written in Rust.