MyHDL: Using Python as a hardware description and verification language

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...

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.

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.

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?

The industry still heavily uses TCL. TCL!