Very frustrating reading the comments from the Aldec marketing head, and it's really disappointing to see such comments coming from a company which has previously engaged so much with the open-source community (they've actually put some effort into proper support for co-simulation using the Python-based cocotb).<p>For example:<p>> Q: What’s still missing out of the design flow? Do all the tools work with RISC-V?
> A: The main thing is the lack of UVM support.<p>This answer just seems like a category error: UVM is (for all intents and purposes) a library for SystemVerilog; an ISA does not "have UVM support", they just aren't even closely related. Perhaps he means that (open-source) implementations of RISC-V cores haven't been verified using UVM, or that open-source functional-verification tooling typically doesn't support UVM?<p>There are two reasons that no-one is using UVM in the open-source community: it's absolutely <i>unbelievably</i> dreadful, and full SystemVerilog support is generally lacking from open-source tooling. Unless you've got $$$$ to spend on a Big-3 simulator (let's be honest, no-one is using Aldec simulators to tape out an ASIC), you <i>can't</i> use UVM even if you wanted to.<p>> UVM would give you constrained random verification, functional coverage, and re-usability.<p>UVM (along with most of the "software" features of SystemVerilog, and pretty much everything else that's come out of Accellera) is a load of utter rubbish that unfortunately won't die. These advantages have absolutely nothing to do with UVM, or even to do with using SystemVerilog as a verification language: they can all be achieved by co-simulating designs with testbenches written in a better language, for example cocotb testbenches written in Python.<p>The reason why UVM is so prevalent has absolutely nothing to do with its suitability or superiority over other frameworks, and everything to do with the cabal of EDA vendors who are trying to maximise their profit: just consider that Cadence has net profits over double that of Arm, and it becomes apparent that the companies who use these tools are "small fish" compared to the companies making them, as perverse as this may be. Arm would much rather write RTL than tooling, so they're completely at the mercy of the Big-3: if Cadence says that UVM is the only way forward, Arm (and the rest of the industry) is pretty much compelled to follow.<p>> Along those lines, we see big problems on the business side. The open-source business model makes it very difficult for companies to make an investment. We do see open source becoming a huge movement, and we’ve already seen that happen in the software domain. But for EDA, and particularly hardware verification tools, we’re still gauging what we’re going do with it. You need to make sure that whatever you invest is going to generate a return on that investment.<p>The subtext here is that EDA vendors <i>absolutely don't under any circumstances</i> want a strong open-source community in the hardware design space: as soon as the community reaches a critical mass, open-source EDA tooling might start to become a more-and-more viable alternative for use in industry, and the EDA vendors might actually have to start doing some work.<p>I'm convinced that the first place this will happen is formal verification: SiFive is already using Kami [1], which came from Adam Chlipala's group at MIT and is open-source. The costs of formal verification are absolutely worth it in expensive ASIC projects, but it seems EDA vendors (and even companies like Arm) have been <i>really</i> slow to see the light. There's a continuous stream of developments in this space coming out of academia which can be used for real-world projects.<p>The general state of the EDA industry is dire. My employer recently spent about $1.5MM renewing licences for a Big-3 simulator: this is the same tool which I can consistently make segfault in about 10 different ways. The quality of tooling is appalling, and the industry is <i>incredibly</i> slow to react. I'm really hopeful that projects such as RISC-V will stimulate the open-source hardware community enough that we might actually see some change in this space.<p>[1] : <a href="https://github.com/sifive/Kami" rel="nofollow">https://github.com/sifive/Kami</a>