MyHDL: Using Python as a hardware description and verification language(github.com)
github.com
MyHDL: Using Python as a hardware description and verification language
https://github.com/myhdl/myhdl
15 comments
I use systemverilog daily, and it's very powerful. What does myhdl bring that's a game changer or even significant advantage in practice? SV has quite powerful synatx, especially for verification, and it seems this replicates the basics of that but had to force it into an imperative box by using yield, etc to achieve concurrence, while SV has it by default - so SV is less complex in thst regard. Its an impressive achievement nonetheless, but I'm looking for a reason to switch.
For rtl there doesn’t seem to be much reason to use things like hardcaml and chisel.
Testing is usually where the claimed advantage is. That and being open source.
But as you say, SV is all about testing and verification. But the tools are closed source and expensive.
I think the big win is the open source tooling that comes along with these efforts.
Testing is usually where the claimed advantage is. That and being open source.
But as you say, SV is all about testing and verification. But the tools are closed source and expensive.
I think the big win is the open source tooling that comes along with these efforts.
SV has some quite crazy features and is absolutely massive. But I agree I think Python is a terrible replacement. By moving away from SV you lose a lot of tool support which is extremely important (can you do FPV in Python?) and Python is a pretty bad language anyway compared to its peers (Typescript, Kotlin, Rust, etc.)
I use VHDL, not used Python. My understanding is that Python will be many times slower than VHDL, so verification tests that take the best part of a week would then take several weeks with Python. And being dynamically typed is fine if you are running a script that returns quickly, but what about it borking even hours into a simulation, when you can catch most dynamic type errors with stronger typed languages at compile time. Python doesn't look like a compelling replacement for VHDL, unless my understanding is off.
Previously: https://news.ycombinator.com/item?id=20931307
https://news.ycombinator.com/item?id=8836324
Interesting that it hasn't been commented upon much, and the project seems to not have had any updates since 2018...
Interesting that it hasn't been commented upon much, and the project seems to not have had any updates since 2018...
I agree!
Just the fact that it's capable of translating to VHDL or Verilog makes it very useful. I'm surprised the industry doesn't care too much still.
Just the fact that it's capable of translating to VHDL or Verilog makes it very useful. I'm surprised the industry doesn't care too much still.
I can tell you, as someone that had some experience in the industry with this, that the two problems are :
- Teach people new paradigms - unfortunately, not all FPGA/Asic devs are fond of OOP nor have python on their abilities
- Get further down the rabbit hole of framework debugging. To add a new layer on top of the horrible beasts that Xilinx Vivado/ISE or Intel Quartus are, one must ensure that the work is really going to be faster and more reliable.
In the end, on the most constrained workflows, one would have to verify first the python/HDL code using MyHDL, then verify the generated VHDL using the industry tools, then go through the synthesis and place and route processes, add some verification layers there then test the result.
Convincing a team to accept such a framework takes time and organization.
In the end, on the most constrained workflows, one would have to verify first the python/HDL code using MyHDL, then verify the generated VHDL using the industry tools, then go through the synthesis and place and route processes, add some verification layers there then test the result.
Convincing a team to accept such a framework takes time and organization.
The industry still heavily uses TCL. TCL!
Thanks that made me smile :)
I actually really like Tcl, I like the simplicity of its command argument nature.
The thread "Why is Tcl syntax so weird" was posted a couple of weeks back, https://news.ycombinator.com/item?id=29143346. The first comment on the page includes "Tcl is still a wonderful language and I often lament how it’s mostly died out". Happily, for me at least, it's still going strong in HDL land :)
I actually really like Tcl, I like the simplicity of its command argument nature.
The thread "Why is Tcl syntax so weird" was posted a couple of weeks back, https://news.ycombinator.com/item?id=29143346. The first comment on the page includes "Tcl is still a wonderful language and I often lament how it’s mostly died out". Happily, for me at least, it's still going strong in HDL land :)
TCL is a terrible error-prone language. The fact that language rules are quite short (I think, there doesn't even seem to be a specification so who really knows) doesn't mean the language is good.
Brainfuck is stupidly simple but good luck writing reliable code with that!
I should make a TCL quoting quiz to prove how insane it is.
Brainfuck is stupidly simple but good luck writing reliable code with that!
I should make a TCL quoting quiz to prove how insane it is.
The rules are here https://www.tcl-lang.org/man/tcl/TclCmd/Tcl.htm
I guess Tcl is just one of things that divides opinion.
I guess Tcl is just one of things that divides opinion.
Ah thanks for that. I dunno, I suspect most TCL users are those that are forced to use it (because of EDA tools probably). Kind of the same reason Bash and CMake are popular, even though they share similar levels of insanity to TCL.
The one thing I'll give it is that the "function bodies are just eval'd strings, quoted using braces" is a kind of neat trick for implementing functions. Like if you want to make a language that supports functions with the minimum amount of code possible, that's a fun idea.
Not a good idea, but a fun one. The correct response is "ha that's a neat trick. Now please delete it and do it properly."
The one thing I'll give it is that the "function bodies are just eval'd strings, quoted using braces" is a kind of neat trick for implementing functions. Like if you want to make a language that supports functions with the minimum amount of code possible, that's a fun idea.
Not a good idea, but a fun one. The correct response is "ha that's a neat trick. Now please delete it and do it properly."
Using modern languages for hardware design seems to be a tendency today. I wonder how does MyHDL compare to Chisel? Chisel is another hardware description language based on Scala, which has already been wildly used in the RISC-V community. Check it out here: https://www.chisel-lang.org
And I've been involved in a project that's making heavy use of Bluespec: https://github.com/B-Lang-org/bsc/
Same problem though - you have to transpile it down to Verilog to use it in anything beyond a simulation.
Same problem though - you have to transpile it down to Verilog to use it in anything beyond a simulation.
Writing verification in Python is a powerful productivity enhancement. I’m less convinced about the benefits of coding RTL in Python. As others have alluded to, there are strong downsides to adding another layer of tooling into an already fragile tool stack. At some point you’re going to hit proprietary tools that take [System]Verilog or VHDL so a traditional HDL inevitably becomes your base language for synthesis, linting, reference point for constraints etc. My preferred flow is SV for design and C++ (via Verilator) and/or Python (via Cocotb) for verification.
What I find surprising is how the industry seems to have dropped the ball in terms of languages. The biggest innovation in the last 20 years was SystemVerilog, but that combined relatively powerful verification advances with half-hearted improvements to the synthesizable subset of the language. All hardware designers really need is an improved way to abstract design composition - let me pass types, modules and instances around so that I can write composable designs. Instead we got multiple features with narrow special case definitions in the form of interfaces, packages and classes with the result that it’s still very hard to write a function that can be parameterized on type or width and will synthesise?!
The lack of clarity about what is synthesizable means different tools have different levels of language support. Any reasonably complex project will utilise multiple tools so you have to code to the lowest common denominator (after working out by some painful process which language features work reliably in each tool). The combined tax on the tool vendors (most of whom took the best part of a decade to get SystemVerilog support) and designers must total hundreds of thousands of developer hours in wasted productivity. I wish we had separated out verification from HDL a long time ago. Verification is essentially just software, why should it share the same language as the hardware design?
What I find surprising is how the industry seems to have dropped the ball in terms of languages. The biggest innovation in the last 20 years was SystemVerilog, but that combined relatively powerful verification advances with half-hearted improvements to the synthesizable subset of the language. All hardware designers really need is an improved way to abstract design composition - let me pass types, modules and instances around so that I can write composable designs. Instead we got multiple features with narrow special case definitions in the form of interfaces, packages and classes with the result that it’s still very hard to write a function that can be parameterized on type or width and will synthesise?!
The lack of clarity about what is synthesizable means different tools have different levels of language support. Any reasonably complex project will utilise multiple tools so you have to code to the lowest common denominator (after working out by some painful process which language features work reliably in each tool). The combined tax on the tool vendors (most of whom took the best part of a decade to get SystemVerilog support) and designers must total hundreds of thousands of developer hours in wasted productivity. I wish we had separated out verification from HDL a long time ago. Verification is essentially just software, why should it share the same language as the hardware design?