python lobbyists at SystemVerilog IEEE 1800 needed

If you care about the future of python in verification it is a good time to go find your company’s rep at the SystemVerilog IEEE 1800 committee.?As we could have expected, and as we learned from Dave’s post a few weeks back, the forces are arraying themselves for another standard revision. And though it might sound a bit pradoxical, Python’s adoption depends to a large extent on what goes into that revision.

Although Python and SystemVerilog are often presented as competing alternatives, the situations where this is actually true, are extremely rare. How many times in a verification engineer’s career does one really get to benchmark a few verification languages and choose the most appropriate? If you’re working in big corporates the answer is almost 0, if you’re doing one exit after another you might get that very dubious pleasure a few times, and even then, your choice might be dictated by many non-technical factors. In the most typical setup, however, they’re simply used together to get the job done. At a high level, python might be seen as complementing SystemVerilog's inherent limitations, just like TCL used to do for VHDL/Verilog. Where SystemVerilog is rigid, strongly typed, static, pre-compiled, old fashioned boomer comes in Python and allows a backdoor of flexibility and innovation. The relationship is more symbiotic than anything else, and although some people might dream of a day without SV, I don’t (even though I do think we’re going to see great growth in other languages). Yes, I’ve written this,?but if you actually read beyond the clickbait title, you’ll see it says something a bit different (and I was wrong about cocotb - it is immensely useful).

So, for better or worse, these strange bedfellows have to continue their co-existence, and if you care about python, you actually care about the next revision of the standard. Why? because whatever goes in there might make python’s integration either way harder or way easier. If we get to see DPI that supports moving classes from one side to another and not just bits and bytes that need unpacking, if we get to allow DPI context to be class instances instead of just modules and other static design interfaces, if packages, classes and constraints can be traversed via VPI just like their design counterparts, and their functions are exposed, if we could get json representation of objects, if..if…if,?the python verification engineer’s life are going to become much easier and much more productive. In return, python will make things that are impossible in SV, a walk in the park. I have already written about how cocotb actually brings reflection to static modules (see an example here), and the same could be achived for classes, maybe throwing away all these horrible uvm_field macros at some point. With python’s access to coverage and general purpose databases, and some control of stimuli (maybe even just turning constraints on/off) you can already see a path to controlling test according to coverage. Unit tests, fine grain control of assertions, and many more applications, are also highly-dependent on how much of SystemVerilog is open to the outside world. And, if you think what I mentioned would cost vendors too much to implement, just recall that most TCL API already get access to most of these things.

It should be clear that exposing itself to python is as much in SystemVerilog’s interest as it is in Python’s interest. As we said, the relationship is a symbiotic one. If SV tries to build a wall, it will likely shoot itself in the foot. However, the fact that its clear to me, and maybe to you, doesn’t mean it is clear to everyone working on the next SV standard. And, even if it is, committees have dynamics of their own: there are always many good ideas, many features that have already drawn high investment but can’t be pused out wihtout the stamp, many varying needs. Python needs a lobby, which goes back to my openning statement.?

And now, if you’ll excuse me, I’m going to try and find Apple’s nearest committee member (any Apple readers please DM me if you know who they are :-))