[therealchiggs]

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?