Readit NewsIt seems like an AI would not "play by the rules" and can easily detect weird edge cases and shortcuts. But as far as I can tell from the small GIFs, it's not doing any particular glitches.
We are 100s of individuals from more than 30 national and international partner institutions with planes, drones, ships, ground stations and autonomous buoys trying to understand how and why these clouds form, how that links to their environment, dust from Africa, the ocean current, the jetstream aloft, etc. The positions of the different platforms can be seen live on the main website and the data we are producing is appearing on there too.
If you have any questions about what we're doing I'd be very happy to help or point you towards the right people :)
Yes you can release your code, but you can't release your netlist or GDS-II. There's no guarantee that somebody else will be able to take the same HDL and close timing, even with the same foundry libraries (say if they are using a different tool, or different options). You'll also need things like clock-gating cells, memories, IOs (at a minimum) and those are foundry specific, so those would need to be abstracted out in some way.
> For analog chips, you can't do anything. An analog design highly depends on the parameters of the transistors you use, so before you even BEGIN designing, you have to sign an NDA to get the transistor models and you can NEVER open source an analog design.
Now this is where I disagree. Sure you can't open source your analog GDS-II, but maybe that's not the way to go. In my opinion what you want to do is build a foundry independent PDK for a generic 28nm, 40nm or whatever node using PTM models. A well designed analog circuit needs to be relatively independent of specifics, otherwise it's not going to work across all corners (this is more true for modern nodes than the kind of nodes the old textbooks talk about) and it'll be difficult to port to another process. So there's a good chance that analog circuits built for 'generic 28nm' or 'generic 40nm' could be ported to any foundries process (of course the PDK needs to be well designed). Yes you won't be able to push things to the limit as the DRC will be wider, but analog rarely needs to go to the limit. You could probably take the same approach for digital, but that's a lot more open source stuff to build.
Check out OpenRAM and FreePDK45 for academic projects taking this approach. Unfortunately FreePDK45 is only available to those with an academic email (despite being called 'open source'), which makes me very sad.
I talked to someone who worked on AsicOne, and he said that even if you make your own PDK and draw your own transistors and everything, you'll still have to sign an NDK to do the sign-off and what not. I'm not intimately familiar with the whole process myself, but from what I understand it is basically impossible to have an open source analog design that you can actually manufacture. (sure, you can make a theoretical toy thing, but if you can't manufacture it, who cares?)
Everything else is very experimental at best. These days the FOSS FPGA tools are finally getting some traction, with Yosys and Nextpnr. But AsicOne tried to make an ASIC with open source, and faced endless troubles.
For ASIC there is basically QFlow, which is quite old, but used successfully to tape out a chip in the past, and there is OpenRoads, which is very new, experimental and ambitious. There are still major gaps in these tools, so in the end you inevitably have to sign an NDA and use proprietary tools and libraries.
And that's just talking about DIGITAL semiconductors where you compile HDL to pretty much generate the transistors from foundry cell libraries. So you have to sign an NDA to get the cell library, but you can at least release your code.
For analog chips, you can't do anything. An analog design highly depends on the parameters of the transistors you use, so before you even BEGIN designing, you have to sign an NDA to get the transistor models and you can NEVER open source an analog design.
The small dot of light at the end of the tunnel are projects like Minimal Fab, who make more accessible fabrication lines with open transistor models.
The crazy thing is that back in the days there were lambda rules, which were open rules anyone could use to design and model with. But with sub-micron devices, these scalable rules no longer scale, so fabs started producing secret models for their specific process.
I'm hopeful that after FPGA, and digital ASIC, analog will be next to be revolutionized.
In particular it's hard to tell if any particular fork is just a one man hobby project, a fork of a fork, or has any significant work behind it.
Of course the big one is LineageOS, but they seem to make specific phone images, mostly for high-end phones, rather than generic system images for my low-end phone.
The list of generic system images is extremely long and not all that helpful: https://github.com/phhusson/treble_experimentations/wiki/Gen...
I ended up chosing phh-treble because it doesn't add any BS, promises quick updates, and serves as a base for many other roms, lending it some reliability. It's pretty much AOSP with hardware fixes.
That said, it doesn't do some pretty basic things like automatic brightness and night mode, or a PIN timeout. So maybe that's eventually drive me to try another ROM...
So where's the non-sketchy, non-for-profit equivalent? Where's the nice frontend for llama.cpp that makes it trivial for anyone who wants to play around with local LLMs without having to know much about their internals? If Ollama isn't doing anything difficult, why isn't llama.cpp as easy to use?
Making local LLMs accessible to the masses is an essential job right now—it's important to normalize owning your data as much as it can be normalized. For all of its faults, Ollama does that, and it does it far better than any alternative. Maybe wait to trash it for being "just" a wrapper until someone actually creates a viable alternative.