skywater-pdk VS myhdl

Preferably Intel compatible or able to run Linux? Something I can build in my garage or in a simple microprocessor fab.

https://github.com/google/skywater-pdk

It looks neat, but the process node is 1 um with 3 metal layers.

The open Skywater PDK is 130 nm : https://github.com/google/skywater-pdk (though I don't know how reliable the PDK is?)

From working in a somewhat related discipline, the PDKs for the high end nodes (think tsmc N16 and lower) are quite hard to obtain and require your org to pass security audit. In addition to that the cadence licenses are priced very much for a big-org rather than a startup.

Does your chip absolutely need a modern node? I'm assuming you've seen the open source skywater pdk, but here it is just in case. https://github.com/google/skywater-pdk

If you need a free PDK, check out: https://github.com/google/skywater-pdk

That would be really neat, but I haven't seen anyone even make a CMOS imager on SKY130.

https://github.com/google/skywater-pdk

One could make an array of thermopiles, like the hacker that made their own imager out of discrete diodes (digiOBSCURA) . But each pixel would cost $7.

https://www.digikey.com/en/products/detail/excelitas-technol...

One might be able to make an array of thermistors (possibly with active cooling using a peltier) like the diycamera (digiOBSCURA) below. Might be an application of combining many RC oscillators in a tree and recovering the signal with an FFT. I have a gut feeling this is possible, but haven't show it.

https://www.digikey.com/en/products/detail/panasonic-electro...

https://github.com/IdleHandsProject/diycamera (digiOBSCURA)

One could experiment with microbolometers on tinytapeout. https://elicit.org/search?q=cmos+microbolometer

https://tinytapeout.com/

Unlike x86_64 which can only legally be produced by two and one-quarter companies, RISC-V is a permissively open-sourced ISA so anyone can make a chip. Literally, you can download Verilog of Berkeley Rocket cores from Github and run it on an FPGA, or prep it to send to SkyWater to fab at 130nm.

Taping out an actual chip inevitably involves IP that's not yours, e.g. the standard cell library and other 'physical' IP like memories and flash. You cannot open source that as it is not yours and in general the owners of it won't want to open source it either (though there are exceptions e.g. the Skywater 130nm PDK https://github.com/google/skywater-pdk).

In OpenTitan we've built all the 'logical' IP ourselves from the ground up. This is the Verilog RTL you can see in our repository but you need the 'physical' IP to make a real chip. We haven't built any physical IP so we need to get it from the traditional industry sources which means traditional industry licensing (i.e. very much not open).

Thank you for tackling this critical problem for logic designiners. I think the tools available are much too old for fast paced workflows.

From my experience attempting to get a similar workflow down for my company:

I tried to use verilator a while back but ultimately I couldn't because it didn't have same constraints in the verilog language features that I was going to use in production. It doesn't even matter who was missing a feature, verilator or the proprietary tool, it was just about getting them to be same that caused the cognitive dissonance that I didn't want to deal with.

I ultimately decided to move away from verilator and use the clunky proprietary tools since it was what would be used in production. Getting "verilator compatibility" seemed like a "nice to have".

Second, the a winning local-first framework of verilator wasn't really established. You show in your example running a test from the yaml file using what looks like a bash script. Even as an experienced programmer who knows bash and sh well, I still find it very hard to write complex thoughts in it. The last high level attempt I found to bridge this gap is likely https://www.myhdl.org/ I don't know them personally, but it seemed like they had some very good thoughts on what makes writing good hardware level tests good. I think it would be worth reaching out to them if you haven't already.

The one thing that even more critical was a way to run our tests locally. The 10-20 seconds it takes to start a docker image (best case) in the cloud is really frustrating when you are "so close to finding a bug" and you "just want to see if this one line change is going to fix it". Once we got our whole pipeline going, it would take 1-6 minutes to "start a run" since it often had to rebuild previous steps that cache large parts of the design.

So I think you will want to see how you can help bring people's "local's first" workflows slowly into the cloud. Some tools (or just tutorials) that help you take a failing test, and run it locally and on the cloud will be really good especially as you get people to transition!

Also PyMTL, PyRTL, and MyHDL.

MyHDL

Any hardware designers here who use Python for designing hardware? There are a bunch of libraries that all seem promising MyHDL, PyRTL, PyVerilog, PyLog, PyMTL3, ... All seem to work roughly the same. Write code in Python and transpile it to VHDL/Verilog. Which of these are popular and well-maintained? MyHDL looks good but it's last release was 0.10 in 2018 and for hardware design you don't want to rely on 0.x software. Anything like Chisel for Python.

It is : https://www.myhdl.org/

Personally I have fond memories of MyHDL [0], which may be seen as another "code-to-silicon" converter (or at least as the first step of a code-to-silicon workflow). I used it only briefly, and on a school project that had surprisingly little to do with actual hardware design [1], but it really felt "Pythonic" in the best possible way.

[0]: https://www.myhdl.org/

[1]: https://github.com/lou1306/gssi/tree/master/2pc