there are some developments, but mostly you would get new additional tool on top of existing stack, rather than a new stack.
Problem 1. patents. in early FOSS days people got momentum to push hard for corporations to give up compiler patents and other obvious nonsense and let GCC flourish. same situation is here in hardware, the very idea of simulating circuits is a mine field of patents and you'd be sued out of existence.
Problem 2. features. there are a lot of features that you need to push out a working chip into an existence. open source tools or alternatives are SO far behind that they cannot be used or can be used only on something really small.
Problem 3. verification. there are no (VIABLE! that python coco stuff doesnt count!) open-source alternatives to UVM (uvm as a library is open source, but there are either no simulators that can run it). If we had some of the older verificaion languages to go open source (like specman, vera), maybe we had a chance.
the point is that for FOSS there was an active movement that forced IBM and old megacorps to forfeit such "nonsense" patents. So if you roll out a brand new c++ compiler you may have some buffs with intel if you try to go to their turf about some propreitary x64 specific optimizations, but, say, IBM wouldnt sue you because you dared to create "a program/method of transforming source code into machine code" that violated 250 patents from their portfolio.
According to their Wikipedia page, they paid 12.5 M$ to settle in 2007 and continued to operate for another 4 years before being bought for half a billion USD. Not exactly what I would consider "sued to pieces" ;-)
Problem 1. patents. in early FOSS days people got momentum to push hard for corporations to give up compiler patents and other obvious nonsense and let GCC flourish. same situation is here in hardware, the very idea of simulating circuits is a mine field of patents and you'd be sued out of existence.
Problem 2. features. there are a lot of features that you need to push out a working chip into an existence. open source tools or alternatives are SO far behind that they cannot be used or can be used only on something really small.
Problem 3. verification. there are no (VIABLE! that python coco stuff doesnt count!) open-source alternatives to UVM (uvm as a library is open source, but there are either no simulators that can run it). If we had some of the older verificaion languages to go open source (like specman, vera), maybe we had a chance.