seanmclo

I've been working on verifying memory coherency units of modern out-of-order CPUs for a few years now. Nowadays, this would be a huge miss if it were to escape to silicon. You'd have a dead on arrival product.

Unfortunately, this isn’t always an option if you need to use a library that’s only available in Python.

At this point, another big benefit of Python is its huge number of libraries. This is really attractive to lots of people who also want static type checking.

Oftentimes, the benefits of using Python in a code base that would benefit from static typing outweigh the costs. Especially when tools like MyPy exist, which aren't perfect but help tremendously.

I can attest first-hand to the "headache" that comes from semi company simulation environments. Not only are they horribly outdated (in Perl/Tcl), but they're different at every company you work at. There's no gold standard because the standard that these EDA companies ought to be making doesn't exist.

There needs to be an open initiative between semi companies to create a standard simulation environment -- with compilers, unit-test frameworks, and all sorts of simulation (gate-level, analog/mixed signal, emulation, etc). Hell, just give me a free IDE plugin for SystemVerilog that actually works.

This lack of a standard seems to me like the critical path in hardware design. I'm trying to support projects to fix this like SVLS (A language server for SystemVerilog: https://github.com/dalance/svls) but these are all hard problems to solve. This industry is relatively niche and doesn't seem to have many engineers interested in FOSS.

I've been looking for an alternative hardware description language to Verilog/SystemVerilog because they're not very readable languages. But after skimming this source code, my initial thought is that I hope Haskell doesn't take off. This is extremely difficult to read.

Maybe I just don't know Haskell well enough, though.

Decide what process node this is aiming for, circuit layout, synthesis, working with a nanofab to actually build the thing, and assuming that there are bugs in there still, multiple rounds of post silicon debug. It's a long and expensive road ahead if you want this as a real product.

Yes. In PDX, Azure recently had a big hiring frenzy and there was a lot of attrition as well.