MyHDL: A step in the right direction
Feb 8, 08:56 PM
I came across MyHDL recently, and I must say I’m quite impressed. It’s very much along the lines of Computer.Build, providing a way of defining hardware in Python, and generating Verilog code from that. It uses Python’s ast module to manipulate and analyze your source code, letting you write pure Python and get back Verilog. You do need a handful of special decorators to tell the compiler what’s going on, but it can mostly figure things out.
The downside of the true AST approach is that it takes a lot of code. Thousands upon thousands of lines of code to recursively descend the AST and deal with the Python language. At least he didn’t have to write a parser, but there’s still a lot of work required when compared with an internal DSL like Computer.Build. For the Ruby side, I’m taking advantage of Ruby’s blocks and metaprogramming tricks to build an internal DSL with minimal effort, and Clojure lets me jump straight to my own language thanks to its Lisp syntax.
Besides being easier to implement, Computer.Build is focusing on a different domain. It’s not intended to support general-purpose FPGA development. Instead, it’s going to be a toolkit for building computer-like devices, with an instruction set and clock and all that jazz. As such, it doesn’t need to support nearly as much of any language as MyHDL does. I’m still working out exactly how much Computer.Build needs to do to support the design of microprocessors, but honestly I think it’s pretty close now that I have state machines working.
If I were starting from scratch on this project and focusing strictly on the FPGA target, I probably would have built this from MyHDL now that I know about it. Since this project is as much about Ruby vs. Clojure as it is about hardware development, I stand by my choices. MyHDL is a very cool tool, though.
4 Responses to "MyHDL: A step in the right direction"
Feb 18, 05:35 AM
Thanks for your interest in MyHDL.
In development, I just moved from the old compiler package to the new ast package: the old code is commented out as a reference which makes the conversion code files much larger than they should be currently.
Recursive descend is mostly automatic as you know, most of the code therefore implements a mapping of MyHDL semantics and types to Verilog and VHDL. This is not always trivial, because MyHDL’s type system is different – I believe superior and higher level :-) I’m therefore not sure whether other methods can make this implementation easier, though I am interested to learn.
Also: the decorators are not specific to the conversion process, but they implement desirable semantics for a HDL. In other words, they are intended for modeling and simulation in the first place.
Feb 19, 02:22 PM
> the old code is commented out as a reference
Ahh, okay. That helps explain some of my confusion.
> a mapping of MyHDL semantics and types to Verilog and VHDL
Which is awesome, BTW. I’m just not sure that mapping a largely imperative language into hardware is the best approach. I don’t particularly like the syntax of Verilog and VHDL, but is Python that much better?
Most programming languages are designed around an imperative control flow, where you do step A, then step B, then step C, with some fancy loops and conditionals thrown in. This just seems like the wrong way to design hardware to me.
Feb 22, 04:19 AM
I have room for only a few thoughts :-)
The alleged mismatch between the imperative style and hardware is a very old critique. I think it’s based on a misunderstanding.
RTL synthesis has no problem with extracting the maximal available parallelism from an imperative description. More importantly, it can create very efficient circuits from the non-parallel part also. That’s what multi-level logic synthesis is good at. To me, an imperative description can just be an elegant way to describe behavior.
People often forget that many other HDLs than Verilog and VHDL have been proposed. Most were very different: non-imperative and concurrent-only. The fact that Verilog and VHDL are winners must tell us something about what engineers want to use in practice.
Feb 22, 08:23 AM
Thanks for taking the time to explain things to me!