I would be shocked if there weren’t a thousand JavaScript developer for every SystemVerilog enigineer, to be honest, because that reflects the demand for software versus hardware engineering. Almost any company need some custom software. Small companies often make do with people who aren’t full-time programmers doing a bit of Python, JavaScript, or even VBA, because they can’t afford enough employees to have that degree of specialism, others will outsource. Larger companies will have at least a few programmers on staff. In contrast, very few companies design custom silicon. Even with FPGAs becoming increasingly cheap, the number of problems that can be cost-effectively solved with custom software dwarfs the number that can be solved with custom hardware by a huge margin (and hardware engineer salaries are lower than software engineers, so it’s not the cost of hiring competent people that’s the problem: big traditionally-software companies are increasingly hiring microarchitects and paying them software engineering salaries, which is causing a retention problem at some of the big chip companies).
But the biggest issue is that it’s written in SystemVerilog.
I’m neither a big fan of SystemVerilog (using Verilog 05 for design and C++ or Python for verification instead), but there is also a UVM version for SystemC (which is C++ actually); see https://systemc.org/about/systemc-verification/overview/
It’s just a programming language
Yes for verification; no for digital design, which is not the same as “programming”.
I believe cocotb will be one of the important technologies in the coming years
SystemC is, in my opinion, the one thing worse than SystemVerilog.
I’ve used cocostb. Evaluated it to see if maybe it was an option for a team of new verification engineers. I liked it quite a lot. But SV for verification is a lot more than classes.
When I checked out, it was missing constraints (and corresponding randomization), functional coverage (groups, points, properties), and SystemVerilog Assertions. Functional coverage is a must have in my domain.
SystemC is, in my opinion, the one thing worse than SystemVerilog.
Well, it’s the C++ programming language plus a library; they didn’t change the language. In contrast SystemVerilog is - from my point of view - a rather unfortunate amalgation of at least four different languages, causing unnecessary complexity, which is an impediment for people who have to learn it and tool implementers who have to maintain compatibility. It would not have been so serious if IEEE had subsequently withdrawn the Verilog standard. Thus, people were forced into SystemVerilog against their wishes, despite its continued relatively low acceptance. Most engineers I know including me still use Verilog for design and something else - like cocotb - for verification. SystemC has still a rather low adoption rate, but if it has a UVM implementation then people at least are not forced into SV.
I would be shocked if there weren’t a thousand JavaScript developer for every SystemVerilog enigineer, to be honest, because that reflects the demand for software versus hardware engineering. Almost any company need some custom software. Small companies often make do with people who aren’t full-time programmers doing a bit of Python, JavaScript, or even VBA, because they can’t afford enough employees to have that degree of specialism, others will outsource. Larger companies will have at least a few programmers on staff. In contrast, very few companies design custom silicon. Even with FPGAs becoming increasingly cheap, the number of problems that can be cost-effectively solved with custom software dwarfs the number that can be solved with custom hardware by a huge margin (and hardware engineer salaries are lower than software engineers, so it’s not the cost of hiring competent people that’s the problem: big traditionally-software companies are increasingly hiring microarchitects and paying them software engineering salaries, which is causing a retention problem at some of the big chip companies).
I’m neither a big fan of SystemVerilog (using Verilog 05 for design and C++ or Python for verification instead), but there is also a UVM version for SystemC (which is C++ actually); see https://systemc.org/about/systemc-verification/overview/
Yes for verification; no for digital design, which is not the same as “programming”.
Agree
SystemC is, in my opinion, the one thing worse than SystemVerilog.
I’ve used cocostb. Evaluated it to see if maybe it was an option for a team of new verification engineers. I liked it quite a lot. But SV for verification is a lot more than classes.
When I checked out, it was missing constraints (and corresponding randomization), functional coverage (groups, points, properties), and SystemVerilog Assertions. Functional coverage is a must have in my domain.
Well, it’s the C++ programming language plus a library; they didn’t change the language. In contrast SystemVerilog is - from my point of view - a rather unfortunate amalgation of at least four different languages, causing unnecessary complexity, which is an impediment for people who have to learn it and tool implementers who have to maintain compatibility. It would not have been so serious if IEEE had subsequently withdrawn the Verilog standard. Thus, people were forced into SystemVerilog against their wishes, despite its continued relatively low acceptance. Most engineers I know including me still use Verilog for design and something else - like cocotb - for verification. SystemC has still a rather low adoption rate, but if it has a UVM implementation then people at least are not forced into SV.
It seems like pyvsc could help with the randomization and the coverage. I haven’t tried it myself yet though.