But when it comes to EDA, the utterly closed-source culture of the industry has completely prevented what essentially amounts to a horde of smart people to work on the problem: no one - except a very small number insiders - even know what the problems are.
You have layers upon layers of closed source EDA tools and home-brew scripts, all built around horribly abysmal "standards" like SystemVerilog, mostly cobbled together in TCL and Perl.
For instance, the following sounds like a horrible joke, but it is real. In a real life, world-class company, port connections between modules are handled using a Perl script. This perl script invokes, I shit you not, an Emacs-Lisp Verilog parser, that scans your files to figure out what submodules you are instantiating, infers the ports that you want to connect, then injects a blob of connections directly into the source code file you were editing. The engineers at this company then commit the output of this Perl script into their source code repository. Predictably the diffs are full of line noise.
And you can't escape from this, any of it, because there are so many tools involved, and they all do such useful things, that you end up truly stuck using whatever features all of the tools support. And `ifdefs. Sigh...
Working IT (aka DevOps, continuous tech support), it's just cutting & pasting strings. Maybe some data quality stuff.
Gods I miss product development. Actual design & programming.
You can also look at it from the other perspective: at least you can still make money making hardware tooling. That is not possible for software tooling, as everything is open-source already.
You have a very distorted view of OpenSource. People working on OpenSource related project do make money. And lots of it. They're just not selling what essentially amounts to obfuscated source code, a way of doing business that is apparently a great source of astonishment for HW folks.
The other point is the state of hardware tooling. Tool vendors may be making money, but their customers are getting shafted something fierce.
Every single EDA tool I've used feels like it was written in the 80's: slow, bulky, bloated, opaque, complicated, unpredictable behavior, need band-aids all over the place to get it to do what you actually need (Tcl anyone?)
The typical byproduct of an industry focused on secrets instead of innovation.
I was talking about compilers and such. Do you have any evidence to support this case?
In the SW world tooling people are busy kick-starting entire industries. You can argue they may be making less money, but as to their overall utility to the ecosystem, clear win AFAIC.
Here's an example:
https://www.infoworld.com/article/3247799/development-tools/...
Where is the LLVM of the HW world?
Nowadays, I suppose you can still make money writing compilers, but besides being a master at compiler design, you now also have to have the skills to sell your services, which is difficult, time-consuming and boring. You can't just sell shrink-wrapped products like before.
There's a cargo cult confidentiality that achieves absolutely nothing if not completely frustrating out anyone who tries their best to keep their interest in it alive.
Try writing an FPGA SDRAM controller that reliably operates across frequency, voltage, and temperature at 150 MHz. It is doable but a challenge with the common xilinx boards that are sold to hobbyists for $80. If you can do that, then think about designing a circuit which operates 20 times faster, and negotiates a protocol which is 100 times more complex than what an SDRAM controller has to do.
Kernels are extremely complex software blobs with crazy race conditions, and tons of device-specific hacks. Somehow the world goes on with Linux going open source. Nobody is claiming that a single person will bang out a USB 3.1 block, but building up these "IP"s over time through the community would be a huge first step.
All the more reason for sharing your solutions with the rest of the world, or at the very least parts of it.
The problem with the EDA industry is their firmly held belief that these kind of trade secrets is what they're competing with.
Think of Google, who had this exact same struggle internally.
For BigTable and MapReduce, they chose to sit on the "IP" to put it in H/W parlance. This gave the world Hadoop and its evil twin file-system whose name I forget. Yay (Hadoop is a a catastrophe).
For Tensor Flow, they chose the OpenSource route. TF is arguably the best framework for ML. There's a lesson somewhere in there.
That's probably what's lacking here, anyone with anything to gain by opening up all the bemoaned goodies. Is that Darpa's role?
Wouldn't you then want ten times the number of people eyeballing the code? And boatloads of free contributers submitting change requests to fix potential problems?
And a marketplace of users that can freely choose deciciding which "IP (I still find the term so deeply offensive, I can't help but it I have to put it in quote)?
The point is that, while these blocks can be complicated and need lots of customization, the ability to grab the source and modify it yourself is a huge enabler. If I could grab a stock IP from a repo and then spend 40 man-hours customizing it, it would be a huge benefit over spending 1000 man-hours making the IP from scratch.
I hate to appeal to expertise, but I've written HDL, synthesized it, and done mask layouts before. I understand that it requires a lot of customizing, but the first step to all of this is sharing. Sharing infrastructural components is a huge reason of why the commodity software business is as robust as it is.
And let's be honest, a state of the art block ported to the latest process isn't going to be 40 man-hours to customize, you're probably looking at more like a couple man-years unless it's very well designed... Which is why reusable core shops are a viable business. And how vibrant of an open source community would you have, if it took a small team a year just to customize & implement the open source design to their application? You would have very few users.
Now, you could argue that because a lot of the real work is in the customization that they could open source the core. But where does the customization end, and the core, the root functionality begin?
I think a more realistic pitch would be an open source testbench or behavioral model that verifies your core is fully spec compliant.
I doubt most projects need the full 10gibts. What if they only need 750mbits? That's unfortunately not possible without USB 3.1. The alternative to USB 3.1 (Gen 1 or 2 doesn't matter) is USB 2.0 which only can do 480mbits.
Those are hardly that simple. There exist entire companies whose function is designing such cores (and licensing them).
I guarantee you, every single Chinese manufacturer who wants to dodge licensing fees has already done so with stolen IP cores. After all, EDA companies are hopelessly stuck in the past and woefully unaware of proper security practices.
There's a clear need for a Ruby-to-gates compiler, the only possible explanation for why there isn't one is because hw guys just don't get it
Hard not to just throw up your hands.
The sad irony is a lot of the tools, languages, & culture of today's software could really be valuable- for formal verification. But that doesn't get much attention.