Yep, pretty much any industry or individual organization that's been around for 40 years will have decades-old cruft complicating attempts to make changes. That's why it's good to have some sort of skunkworks unit as well.
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.
Doesn't that apply to basically every kind of software? How's it different for HDL simulation software?
> the very idea of simulating circuits is a mine field of patents and you'd be sued out of existence
Do you think a startup selling a new HDL simulator is any more at risk of getting sued than any other software-based startup?
Not trying to be combative, I'm genuinely curious.
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" ;-)
I am hoping we can start proving many if the things they brute-force model check today, too.
But I believe we need LISPy syntax - mainly for simplicity, also for easier parsing and static analysis. I think LISP is a natural way to describe data flow. Unfortunately none of the attempts to write functional synthesizable code that I found so far make the code simpler.
BTW I'm preparing a talk on simplifying RTL code. Can I cite some of your posts in this thread?
The biggest offender on that project list is FIRRTL. Cleary outgrew as someone's university work of "hey, lets do IR, but for RTL" without knowing anything of the industry, tools, etc. At best you can do the same with one reduced canonical simplified verilog source-to-source translation. at worst it does not do the primary function of "being" IR for RTL, because it should've been a graph, not another language with simplified syntax.
- You can use SBT or MVM to pull in dependencies
- You can wrap up designs as .jar files
- Powerful testing tools like QuickCheck come ready made
None of the above is rocket science, but simply by being there things become easier.
without knowing anything of the
industry, tools,
Parsing Verilog and generating valid Verilog is fairly difficult. If you want to stay with Verilog, the most realistic alternative to firrtl right now is the RTL-IL representation used inside of yosys.
> at worst it does not do the primary function of "being" IR for RTL, because it should've been a graph, not another language with simplified syntax.
Canonicalized LoFirrtl (i.e., the representation the compiler lowers Chisel to) is essentially SSA (single static assignment) which encodes a dataflow DAG. So on a per module level, firrtl does represent the circuit as a graph.
What you might be talking about is the fact that this graph isn't global. Having a global circuit graph could make some analyses easier, but it might require essentially in-lining the whole circuit which is something a lot of designers are opposed to. Even small optimizations like removing unused pins from internal modules are often times opposed.
Chris Lattner and others are currently working on an "industry" version of firrtl as part of the CIRCT hardware compiler framework: https://github.com/llvm/circt As you can see they did not decide to go with a global graph based IR and instead opted to just represent local data-flow graphs as SSA.
> Overall semiconducting industry seems to be way more exciting than boring computer industry
The most groundbreaking things all tech must be about are cat video websites, and internet companies :D
People completely forget that were Morris Chang (the previous CEO of TSMC,) not been polite, and ethical to a fault, the industry would've still be dominated by monster big semis, manufacturing every chip around, and who would've milked all big chip users like internet companies to death.
I can't imagine Panasonic, Toshiba, Motorola, or AMD of old not scheming to squeezing their clients to the last cent, and strategizing to prevent clients from gaining negotiating power.
TSMC's benevolent stance in comparison to that would be almost bordering on charity.