Google offers free fabbing for 130nm open-source chips
fossi-foundation.org
fossi-foundation.org
Want a linter for your project? That's going to be $50k. Also, it's an absolutely terrible linter by software standards. In software, linters combine the best ideas from thousands of engineers across dozens of companies building on each other's ideas over multiple decades. In hardware, linters combine the best ideas of a single team, because everything is closed and proprietary and your own special 'secret sauce'.
In software, I can import things for free like nginx and mysql and we have insanely complex compilers like llvm that are completely free. In hardware, the equivalent libraries are both 1-2 orders of magnitude less sophisticated (a disadvantage of everyone absolutely refusing to share knowledge with each other and let other people build on your own ideas for free), and also are going to cost you 6+ figures for anything remotely involved.
Hardware is in the stone age of sophistication, and it entirely boils down to the fact that people don't work together to make bigger, more sophisticated projects. Genuinely would not surprise me if a strong open source community could push the capabilities of a 130nm stack beyond what many 7nm projects are capable of, simply because of the knowledge gap that would start to develop between the open and closed world.
There has been quite a lot of study in economics about cooperation. My favorite is Eleanor Ostrom's work on "the commons". She observes that with a certain set of rules, discovered across the world and across varying geographies, people do seem to be able to cooperate to maintain a natural resource like a fishery or a forest or irrigation canals for hundreds of years. Her rules are here (https://en.wikipedia.org/wiki/Elinor_Ostrom#Design_principle...).
That said, economics doesn't rest on this. Macroeconomics doesn't care, nor micro/labor/health/sports/developmental econ either.
Sure trying to predict how someone (and more interestingly how groups) will behave based on their psych profile is an important area of research, but the aforementioned subfields of econ already have well working assumptions about how people will behave in the aggregate, even if they can't derive it from some exact utility function.
Even when entities (corporations, for example) are trying to maximize utility, and an optimal decision is desired, there are issues with how much time and resources can be spent making decisions, so optimality has to be bounded in various ways (do you wait for more information? Do you spend more time and compute on calculating what would be optimal? etc.).
I keep seeing something like this in workplaces people don't join forces they avoid friction. Until something (crisis) or someone (capable leader) flips the thing on its head.
In economics, ... but the power of cooperation seems to be valued much less
I'm not sure that I agree with this. The creation of firms and trade are both cooperative. They aren't altruistic though. (I'm not disagreeing with your overall point, just that cooperation isn't valued in economics.)The trick to making it all work is that knowledge and/or tooling (the means of production) ought not be proprietary, but product or service absolutely can be.
however the line does blur when talking about blueprints and designs.
in any case, I think that free software movements are a sociological anomaly, I wonder if there is any academic research into this from an antropological or an historical economics viewpoint.
also, it seems to me that in some sense the entire market works in cooperation, just not very efficiently (it optimizes for other things than efficiency and is heavily distorted by subsidies and tariffs)
Sort of?
I tried to get into FPGA programming a while ago, and it turns out the entire software stack to get from an idea in my brain to a blinking LED on a dev board is hot garbage. First of all, it's insanely expensive, and second of all, it really, really sucks. Like how is it <current year> (I forgot what year it was, but it was 2016-2018 timeframe) and you've tried to reinvent the IDE and failed?
I think projects like RISC-V and J Core are super cool, but I couldn't possibly even attempt to contribute to them based on how awful the process is.
The whole thing revolves around the marginal cost of an extra copy of a piece of software being close to zero, no other critical industry gets such economies of scale. Making more chips still requires huge capex and opex.
There is a lot of literature on the subject of cooperation, especially from anarchist philosophers (i.e. Mutual Aid: A Factor of Evolution, Kropotkin).
I don't have the proper background to make a strong case about this, but I feel like middle ages guilds would be closer to the open-source model than to the current "trades secrets" one, wouldn't it?
Likewise, I don't see farmers of ye olde times keeping their crop-growing tricks to themselves as secrets and so on.
Furthermore, we've known about many indigenous cultures where "the tribe" is regarded as more important than the individual, meaning that sociologically they should be more aligned with the open-source model than the capitalistic one, shouldn't it?
Again, I'm not an expert in the area, but it seems to me that our current society is more "historically anomalous" at the commoner level than any more socially-conscious one would be (i.e.: common people has leaned to greed/individuality these days than almost always in the past).
I don't mean to engage in some "no true capitalism" libertarian defense, but rather point out that a lot of fine (if simplistic) economic models/theory have been corrupted by various ideologies. A lot of radical-seeming stuff is not radical at all according to the math, just according to your rightist econ 101 teacher.
I.e. a trade is when two parties engage in a mutually beneficial exchange.
The libertarians economists talk about cooperation in terms of spontaneous order. Milton Friedman had his story of the process to manufacture a pencil as "cooperation without coercion". Basically it's the "invisible hand" driving people to cooperate via price signals and self-interest. I don't know if there's much that can be done with the concept beyond that.
EDA is very essential for chip development at this point and it seems like an industry ripe for disruption. We're seeing some inroads by open source EDA software - simulators (Icarus, Verilator, GHDL), synthesis (yosys) and even open cores and SOC constructors like LiteX. In software land we've had open source compilers for over 30 years now (gcc for example), let's hope that some of these open source efforts make some serious inroads in EDA.
How is a 4 years old distribution "very ancient"? There's very likely plenty of Ubuntu 16.04 in the field, and there's nothing inherently wrong with that.
RedHat uses "old" kernels, if that's what you refer to with "ancient" but there are reasons for that, and they're also backported, they're not unupdated.
What does this mean? I've only been in the C++ game for 6 years and for me if I can get something from std rather than rolling my own or pulling in another library, I'm cheering.
the thing is that i think the open source software is a miracle that it even exists, and i don't find it strange that nowhere else has replicated the success. Because open source, at heart, is quite altruistic.
This is the record of the miracle of St. iGNUtius [0]. Back in The Day, before all the young hipsters were publishing snippets of code on npm for Internet points, Richard Stallman seethed in frustration at not being able to fix the printer driver that was locked up in proprietary code. While addressing St. iGNUtius, patron saint of information and liberty, he had a vision of the saint saying that he had interceded for Stallman, and holding out a scroll. On the scroll was a seal, and written on the seal in phosphorescent green VT100 font was the text "Copyright St. iGNUtius. Scroll may be freely altered one the sole condition that the alterations are published and are also freely alterable." Upon opening the seal, and altering it according to the invitation, Stallman saw the scroll split into a myriad of identical scrolls and spread throughout the world, bringing liberty and prosperity to the places it touched. Stallman hired some lawyers to write the text of the seal in the legal terms of 20th century America. Thanks to the miracle of St. iGNUtius, software today is still sealed with seal, or one of its variants, named after the later saints, St. MITchell and St. Berkeley San Distributo.
[0] A twentieth-century ikon of St. iGNUtius: https://twitter.com/gnusolidario/status/647777589390655488/p...
The original RMS email announcing the project is a nice read. When placed in the context of his personal frustration with commercial software it can also be seen as a line in the sand.
Now I grumble if it’s a pain to install a massive open source tool chain for free and these days it’s rarely painful.
I should stop and appreciate that more once in a while.
JITX (YCS18) was funded under IDEA to automate circuit board design, and we're now celebrating our first users.
Great program.
The issue I see in hardware is that all complexity is handled manually by humans. Historically there has been very little capacity in EDA tools for the software-like abstraction and reuse which would allow us to handle complexity more gracefully.
You can crank out correct HDL all day with https://clash-lang.org/, and the layout etc. work that takes that into "real hardware" while not trivial, are less creative optimization problems.
This is a post-hoc rationalization behind the decrepitness of the (esp Western[1]) hardware industry, and the rampant credentialism that arises when the growth of the moribund rent-seekers doesn't create enough new jobs.
[1]: Go to Shenzhen and the old IP theft and FOSS tradition has merged in a funny hybrid that's a lot more agile and interesting than whatever the US companies are up to.
Not having an advanced degree doesn’t mean you can’t master complexity. It’s the same as with software.
The advanced degree is not meant to teach you how to grok complexity. It's to teach you what problems you can expect to encounter and how to go about solving them.
-Engineering PhD
Design for test, Logical verifcation (simulation, logical equivalence checks, electrical design rules), Physical implementation (library development and characterization, floorplanning, place and route, signal integrity), signoff (timing closure, electrical desing rules (again), physical verification, OPC) all require highly complex tools to automate. For large designs you will have people dedicated to each individual step because the ways in which things can go wrong -- and the absolute necessity of things going right to get a working chip -- are legion. And there's no substitute for experience to know the right questions to ask.
It's like the difference between driving your car across the country and flying to orbit. If you make a wrong turn in your car you can just make another turn or backtrack (edit the source code and rebuild). If don't have the right torque on the tank strut bolts on your rocket, "You will not go to space today".
Source: 30 years in the ASIC and EDA industries doing chip implementation and EDA tool flow development.
Another interesting open source EDA project coming out of Google is Verible: https://github.com/google/verible which provides Verilog linting amongst other things.
FOSS development isn't cost-less. And so the business equation is always present.
The degree to which purely academic support for open source can make progress is asymptotic. People need to eat, pay rent, have a life, which means someone has to pay for something. It might not be directly related to the FOSS tool, but people have to have income in order to contribute to these efforts.
It is easy to show that something like Linux is likely the most expensive piece of software ever developed. This isn't to say the effort was not worth it. It's just to point out it wasn't free, it has a finite cost that is likely massive.
An industry such as chip design is microscopic in size in terms of the number of seats of software used around the world. I don't have a number to offer, but I would not be surprised if the user based was ten million times smaller than, say, the mysql developer population (if not a hundred million).
This means that nobody is going to be able to develop free tools without either massive altruistic corporate backing for a set of massive, complex, multi-year projects. If a company like Apple decided to invest a billion dollars to develop FOSS chip design tools and give them away, sure, it could happen. otherwise, not likely.
Further, games would be very easy to copy for users, to develop cheats for multiplayer, to duplicate by competitors, etc.
The longest lived games are the longest lived because they are open enough for the community to keep them alive.
Compare that with something like Android where I'm lucky if I can get GDB to hit a single breakpoint on a good day.
The problem is, it's also a very, very tough industry to disrupt. Not for lack of trying though.
Hopefully there is a middle ground somewhere, where the folks working on open source software can get compensated for their work so as to enable a healthier system overall, so we aren't all just “software serfs” sharecropping for our overlords.
I think it's also a cultural thing. Like you said, lots of your own special secret sauce, and so many issues trying to fix bugs that may have to do with that secret sauce.
Can't say I miss it at all really.
Tangent: I've noticed this problem in dentistry and sleep apnea! The methods of knowledge transfer in the field seem to be incredibly inefficient? Or there are tons of dentists not learning new things? (I recall a few dentists on HN -- I would be interested in any comment either way on this.)
The reason I say this is that many patients can't tolerate CPAP (>50% by some measures). There are other solutions, and judging by conversations with friends and family, dentists and doctors don't even know about them!
----
My dentist gave me one of these alternative treatments for sleep apnea, which was very effective. It's mandibular advancement device (oral appliance). Even the name is bad! They have a marketing and branding problem.
Random: Apparently Joe Rogan's dentist did a similar thing with a different device which he himself invented. Rogan mentioned it 3 times on the air.
So basically it appears to me that practitioners in this field don't exchange information in the same way that software practitioners do (to say nothing of exchanging the equivalent of working code, which is possible in theory).
I looked it up and there are apparently 200K dentists in the United States. It seems like a good area for a common forum. I think the problem is that dentists probably compete too much rather than cooperate? There is no financial incentive to set up a site of free knowledge exchange.
Related recent threads I wrote about this:
https://news.ycombinator.com/item?id=23666639 (related to bruxism, there seem to be a lot of dentists who don't seem to understand this, as I know multiple people with sleep apnea and bruxism who don't understand the connection)
https://news.ycombinator.com/item?id=23435964 (the book Jaws)
Those things are in the basic apnea treatment palet over here (Netherlands), actually more common than PAP machines. Why do you think they are alternative?
I've talked to several people who have a CPAP, and they don't even know of the existence of the mandibular advancement device. Their doctors and dentists apparently don't tell them about it!
I'm puzzled why that is the case. I think it has something to do with insurance. If that's true, it's not surprising that other countries don't have the same problem!
Imagine a combined Intel+AMD+Samsung+Nvidia behemoth pooling together their expertise. Internal competition would still exist, but for actual technical reasons now instead of market ones. One could imagine myriad ways to fund such a cooperative endeavour, which are never even tried because the current model is sacred.
I think the main reason why open source has taken off is because access to a computer is available to many people, and as cost is negligible, it only required free time and enough dedication + skill to be successful. For hardware though, each compile/edit/run cycle costs money, software often has 5-digit per seat licenses, and thus the number of people with enough resources to pursue this as a hobby is quite small.
Reduce the entry cost to affordable levels, and you have increased the number of people dramatically. Which is btw also why I believe that "you can buy 32 core threadripper cpus today" isn't a good argument to ignore large compilation overhead in a code base. If possible, enable people to contribute from potatoes. Relatedly, if possible, don't require gigabit internet connections either, so downloading megabytes of precompiled artifacts that change daily isn't great either.
For example, Altium Designer is probably the most modern (not most powerful although close) PCB suite and yet despite costing thousands a seat it is a slow, clunky, single-threaded (in 2020) program (somehow uses 20% of a 7700k at 4.6GHz with an empty design). Discord also thinks that Altium Designer is some kind of Anime MMO
https://kicad-pcb.org/blog/2020/04/Development-Highlight-Alt...
git clone https://git.dev.opencascade.org/repos/occt.git
It's not well-advertised, but they do offer public read-only HTTP access to the git repository.[1] This URL really should be listed on the Resources page as well as the project summary in GitWeb.[1] https://dev.opencascade.org/index.php?q=node/1212#comment-86...
Like you say, it's kind of shocking to see one core running at 100 percent while the rest do nothing and the app is sluggish in 2020.
In the same vein something like ECAD tools don't use GPU-accelerated 2D rendering but instead use GDI and friends (which used to be HW-accelerated, but isn't since WDDM/Vista).
A lot of "easy" opportunities to improve UX and productivity.
Hardly Altium Designer's fault, but I too would avoid using it.
Even though it has a long history of open-source attempts, as pointed out by Tim in his presentation, they are few and far between, and massively underwhelming compared to the thriving open source software community.
However, if this initiative takes off, it'll be a big help in creating an open source EDA toolchain community.
The opensource EDA toolchain community is already producing some good stuff, Symbiflow: https://symbiflow.github.io/ is a good example, it's an open source FPGA flow targeting multiple devices. It uses Yosys (http://www.clifford.at/yosys/) as a synthesis tool which is also used by the OpenROAD flow: https://github.com/The-OpenROAD-Project/OpenROAD-flow which aims to give push-button RTL to GDS (i.e. take you from Verilog, which is one of the main languages used in hardware to the thing you give to the foundry as a design for them to produce).
The Skywater PDK is a great development, which is a key part of a healthy opensource EDA ecosystem though there's plenty of other great developments happening in parallel with it you will note there's some people who are involved in several of these projects they're not all being developed in isolation. The next set of talks on the Skywater PDK include how OpenROAD can be used to target Skywater: https://fossi-foundation.org/dial-up/
If that is basically a given, why publish anything for free, when you can instead charge 10k/seat in licensing?
Or put another way, Apple and Google are both responding to Intel/the market’s failure to innovate enough in idiosyncratic manner:
- Apple treats lower layers as core, and brings everything in-house;
- Google treats lower layers as a threat and tries to open-source and commodify them to undermine competitors.
I don’t mean this free fabbing can compete chip-for-chip with Apple silicon of course, just that this could be a building block in a strategy similar to Android vs iOS: create a broad ecosystem of good-enough, cheap, open-source alternatives to a high-value competitor, in order to ensure that competitor does not gain a stranglehold on something that matters to Google’s money-making products.
Apple spends $100+ millions to design high performance microarchitecture to high-end process for their own products.
Google gives tiny amount of help to hobbyists so that they can make chips for legacy nodes. Nice thing to do, nothing to do with Apple SoC.
---
Software people in HN constantly confuse two completely different things
(1) Optimized high performance microarchitecture for the latest prosesses and large volumes. This can cost $100s of millions and the work is repeated every few years for a new process. Every design is closely optimized for the latest fab technology.
(2) Generic ASIC design for process that is few generations old. Software costs few $k or $10ks and you can uses the same design long time.
I don't believe Google does anything because it's a "nice thing to do". There's some angle here. The angle could just be spurring general innovation in this area, which they'll benefit from indirectly down the line, but in one way or another this plays to their interests.
If only Google had this singular focus... From my external (and lay) observation - some Google departments will indulge senior engineers and let them work on their pet projects, even when the projects are only tangentially related to current focus areas.
Looking at Google org on Github (https://github.com/google); it might be a failure of imagination on my part, but I fail to see an "angle" on a good chunk of them.
And by old, I mean /old/. 130 nm was used on the GameCube, PPC G5, and Pentium 4.
Things don't have to be ultra modern to offer value.
They can outsource silicon development. Should not be a problem with their money.
In comparison to dotcom development teams, semi engineering teams are super cheap. In Taiwan, a good microelectronics PhD starting salary is USD $50k-60k...
Experienced teams who have designed high performance microarchitectures aren't common, because there just isn't that much of that work done.
And when you're eventually going to spend $$$$ on the entire process, even a 1% optimization on the front end (or more importantly, a reduction of failure risk from experience!) is invaluable.
At the scale that Google is at, it really wouldn't surprise me if they were working on their own silicon to solve the problems that exist at that scale.
My guess would be a cloud based chip design software is in the works. This would accelerate AI quite a bit I should think?
It's actually a big part of why some silicon companies distribute themselves around timezones - so someone in Texas can fire up the software immediately when someone in the UK finishes work.
It's not unusual to see an 'all engineering' email reminding to you close rather than minimize the software when you go to meetings.
- 130 nm process built with Skywater foundry - Skywater Platform Development Kit (PDK) is currently digital-only - 40 projects will be selected for fabrication - 10 mm^2 area available per-project - Will use a standard harness with a RISC-V core and RAM - Each project will get back ~100 ICs - All projects must be open source via Git - Verilog and gate-level layout
I'm curious to see how aggresive designs get with analog components, given that they can be laid out in the GDS, but the PDK doesn't support it yet.
(Remember 130nm gave us the late models Pentium 3s, the second model P4s and some Athlons, though all of these had a bigger die size)
I'm thinking you could have some low power or very specific ICs, where these would shine as opposed to a generic FPGA solution
3.16mm x 3.16mm?
[0]: http://www.apollo-core.com/ I can't easily find how "open source" it is though, but it's free to download.
There are some other pretty nice and featured 68k cores that are open source (TG68, WF68K30L etc.) but none that is really close to the features and performance of the Apollo 68080.
If you do a little research you'll find out that there's plenty of "stay away" and "can't believe they haven't been sued into oblivion yet" indicators and all sorts of misleading claims and marketing.
My summary would be that it's a tightly-controlled, closed project lead by questionable people with well-documented histories of questionable practices including ignoring copyrights, distributing infringing software, deleting critical posts from their forums and putting out misleading information.
https://wiki.apollo-accelerators.com/doku.php/about_us:links
That would be a fun upgrade if I had an old 68k Mac in good condition. I've thought occasionally about what if Motorola had had the resources to continue developing 68k like x86.
I have a "Firebee", an Atari ST-like machine built around a 264mhz coldfire, and it's quite nice.
My understanding is that Coldfire got used in a lot of networking hardware, due in part to its network order endianness, and partially because Freescale put network hardware support into some of the cores.
But there is no continuing demand for Coldfire, really, so it has stalled, NXP never continued on with it and is going the ARM route now, like everyone else.
Chips that cost $1000 from a distributor cost 1/10th to 1/100th the price when you have a relationship with the manufacturer, mostly because distributors can't sell them very quickly and have to keep a ton of stock to have the SKUs you want.
On a modern FPGA, processor clocks of 200-300 MHz are possible to get with designs that aren't huge.
It really is "spiritually" a 68k series processor, just with some cleaning up. I like it.
I believe freescale currently owns the architecture, and still manufactures some 68k microcontroller cores.
Owns it how? 68060-- the last of 68k's designs-- was released in 1994. Any patents should now be expired.
> Owns it how? 68060-- the last of 68k's designs-- was released in 1994. Any patents should now be expired.
Sure, patents wouldn't be a barrier to clone the design and create an equivalent using the same patented ideas, but copyright still prevents you from copying the design, and will prevent copying significant parts of the design as well.
Shouldn't that already be problematic for the 68k projects in hardware through FPGAs? Apollo already does it and sells hardware, and the MiSTER project also does it by releasing FPGA designs for e.g. the Sega Genesis which has a 68k processor. Is it a different story if you embed 68k in an ASIC?
These are kiosk-sized machines that a company can use to set up a fab with a few million dollars. Any individual can then design a chip and have it fabricated very (as in "I want to make a chip for fun") affordably.
I was not able to find a ton of information on this, but the 190nm process was supposedly ready last year and there were plans to go below this. The wafers are 12mm in diameter (so basically, one wafer -> one chip) and the clean room is just a small chamber inside the photolithography machine. There are also no masks involved, just direct "drawing".
The simplistic explanation for why this works is that electron beams can be easily focused using magnetic lenses into a beam that reaches the nano meter level.
These beams can then be deflected and controlled electronically which is what makes it possible to effectively make a cpu from a cad file.
Furthermore, It's very easy to see how the complexity of photolithography goes up exponentially as we scale down.
Therefore I believe it makes sense to abandon the concept of photolithography entirely if we want open souce silicon. I believe that this approach offers something similar to the sort of economics that enable 3D printers to become localized centers of automated manufacturing.
I should also mention that commercial E-beam machines are pretty expensive (something like 1-Mil) but that I dont think it would be that difficult to engineer one for a mere fraction of that price.
Theoretically it should be feasible to fab 350 nm without double-patterning by optimizing a simple immersion DLP/DMD i-line stepper.
I think ArF immersion with double-patterning should be able to do maskless 90 nm.
I'm not sure where it was, but I remember a seeing a project where someone made a rudimentary homebrew electron microscope by chemically etching the tungsten filament from a light bulb (to get the tip sharp enough) and attaching it to a piezo buzzer that was scored to separate it into four quadrants. The filament could be moved by applying various combinations of voltage to the piezo quadrants.
I didn't find the one I was thinking of (which I think was ca. 2002 and so maybe just vanished by now), but search results suggest that variations of this have been done by several people.
Decades ago computers used magnetic core memory. Those things operate on a macroscopic/classical physics level. You can make a core memory by hand if you buy the ferrous toroid first. But moreover, you mention 3d printers — it’s probably possible to manufacture the toroid on a sub-10k machine these days, be it a 3d printer or CNC machine. Some of these techniques generalize to multiple materials, meaning you could automate both the manufacturing of the toroid and the wires connecting them (and the assembly) and have an actual open-source, easily fabricated memory.
One thing not a lot of people know is that you can create clock-triggered combinatorial logic out of core memories just by routing the wires differently. So you’ve got your whole computation + volatile memory + non-volatile memory built on the same process using just two materials and at a macroscopic scale (think: millimeters). That sounds easier to bring up than silicon.
Yeah, macro-scale has its limitations (speed; power draw!), but it’s still enough to enable plenty of applications, and with room to scale it as the tech gets better.
This very, very much depends on what the algorithm is (integer or FP? how data dependent?), but I would say no for almost all interesting cases.
The only exception would be if you're doing a "mixed signal" chip where some of the processing is inherently analogue and you can save power compared to having to do it with a group of separate chips.
Another exception might be low leakage construction, because that gets worse as the process gets smaller. This is only valuable if your chip is off almost all of the time and you want to squeeze down exactly how many nanoamps "off" actually consumes.
I wonder how many "test chips" Google will let a non-expert team do to get it right? And whether they provide any "bringup" support?
No, you actually have more leakage at older nodes, what changes is the ratio of current spent on leakage vs. current spent doing something useful.
Of course, the lower gate capacitance allows for lower switching losses. But adiabatic computing could theoretically recover switching losses, allowing for higher efficiency at older nodes. That can be approached by using an oscillating power supply for instance, to recover charges. If someone was to design something like this for this run, it could be very interesting.
Now I'm wondering if this isn't some covert recruitment operation by Google: they will likely comb trough application, select the most promising ones, and the designers will get job offers :)
130nm is almost 20 years old at this point. You can do amazing things with this process but saving power is probably not one of them.
So yes, for specific tasks like crypto operations or custom networking, you should be able to make a 130nm ASIC that is going to outperform a 7nm Ryzen. You are not going to be able to make a CPU core that's going to outperform a Ryzen however.
So somebody like me, who did two standard cell based ASICs 25 years ago, probably would have to add a sizable safety margin to produce a reliable chip, and would achieve nowhere near the performance of a pro team at the time.
[1] https://theopenroadproject.org/
[2] https://github.com/The-OpenROAD-Project/OpenROAD
https://www.themosisservice.com/university-support
Previously MOSIS would run select a few student/research designs to go along with the commercial MPW runs, frequently on pretty modern fabs. I'm not really sure how much they still run.
(oh here is the MOSIS/TSMC runs for this year https://www.mosis.com/db/pubf/fsched?ORG=TSMC)
Surely they have some threshold requirements that the thing actually works? How is this going to work? I mean, if there's no investment required from me, what's the incentive for me to verify my design properly? What's the point in them fabbing a load of fatally bugged open-source designs?
I don't think they care much about what comes out of it though, whether it's "bugged open-source designs" or not, for sure they want less of the bugged one, but the end-goal isn't the projects, it's the people behind theses projects. Google wants more people that design chips, and then recruit them. This just goes on recruitment cost. They may be interested in the open source part of it, but as soon as they'll stop paying for it (and I'm pretty sure it's not going to stay for long, they mention up to 2021), the state of open source chip design will come back to the current status.
BTW, it will be nice to try this together with the OpenROAD tools [1]. They have support for Google's PDK on their to-do list (planned for q3, but I doubt it will be ready that fast).
[1] https://github.com/The-OpenROAD-Project https://theopenroadproject.org/
So the minimum order quantity usually needs to be at least in the tens to hundreds of thousands of chips if you don't want each chip to be a sizeable chunk of that initial cost.
It would be really nice to get to the point where small batch chips were viable though. One aspect is cost -- if they could get the NRE cost down to, say, $20k - $50k, and the software licensing cost down to zero, that would open up a lot of options.
The other aspect is the "dark art" nature of the process kit and communicating with the fab. If everybody assumes that chip design is expensive, they're going to be reluctant to even talk to the fab to see what options are available. If they see a bunch of people building interesting things with this shuttle program, then all of a sudden the fab is going to see more business interest as people try to figure out if there's a way to make their project work.
These organizations typically also gives access to software design tools. But that's still a sizeable investment. Last project I've worked on used a (more expensive than usual I think) GloFo 22nm technology. Price was around €9k/mm², 9mm² was the minimum area. Still much more accessible to academia than individuals or open source projects, but not out of the realm of a crowdfunding campaign.
There are multiple chips that ought to be open source, broadly available, and cheap: AV1 decoders, small FPGAs, Wi-Fi or SDR chips, TMPs, and other crucial pieces for security, DIY/open HW projects, and basic computer building blocks. Most interesting to me are chips that would allow novel applications that commercial ventures would never look at, like open, hackable p2p WiFi meshes, or emulators-on-a-chip, or other application-specific coprocessors (protein folding, etc).
[1] ttps://mycmp.fr/technologies/process-catalog/
I'm thinking 5-20 mm rotor diameter (3M-750k rpm transonic limit), or maybe even smaller.
The interesting part would be an analogue ASIC that decodes an external control signal modulated onto the microwave (via rectenna) or optical (solar cell/photodiode) "wireless power" beam.
Demodulation would first do naive rectenna-based AM demodulation, followed by a bandpass and FM demodulation, revealing 12 carriers corresponding to the 4 3-phase motors, which are just FM-demodulated to yield the H-bridge control signals.
These would primarily be one xx MHz PLL and 12 lower-frequency ones spaced 50-200 kHz (the FM subcarrier's bandwith (assuming narrow-band FM) is twice the maximum motor field frequency), starting as low as feasible while still being able to use AC-coupling liberally.
Also either some amplifiers for (potentially-overdriven) "linear" H-bridge operation or (NE555-like?) PWM chopper drivers to exploit the winding inductance for less-wasteful H-bridge operation.
Far too much to realize in discrete circuitry, but nothing really fancy beyond a parametric PLL design. And not really realistic for a μC, either, because of brown-out resilience and overall latency.
At least the polyphase induction motors are very easy to drive, compared to the typical 3-phase permanent magnet outrunner motors used in most multicopters.
Depending on how predictable the effects of some tuning parameters are, maskless litho could allow for chips to be tuned to measured electro-mechanical properties of these sintered motors, reaching optimal drive waveforms. And for digital circuits, hard-wired ROM (security/shelf life/radiation-hardness) for individual chips or even doping-controlled ROM for anti-readout private/secret key storage.
I expect a maskless double-patterning ArF+immersion process allowing NDA-free-usage to be "the" thing that would enable true state-of-the-art experimentation and true ASICs (where the prototype needs an ASIC to be more than a paperweight after some photoshoots and staged interactions).
Feel free to contact me/let me know if you'd like further discussion(s).
> $70K, 20 WEEKS, 100 SAMPLES
Note quite $50K, but close.
* More people will learn complete digital design workflow; very helpful for many students of EE/CE
* More bright ideas and experiments in robotics/IoT
* More startups
I'm not sure what happens when they reach full capacity on their sat network. Space for research projects, or launching surplus consumables?
As somebody with a decent amount of FPGA experience, having a go at setting this software up and seeing if I can get anything to synthesise and through place and route is something I've been intending to have a play with, but I haven't had the spare time.
It uses yosis for synthesis and a few other tools for the rest of the process, and is called Qflow - http://opencircuitdesign.com/qflow/index.html
Now, how do you generate these layouts? It depends on what you are doing. If more on the experimental side of things, writing scripts to generate structures is fine, as long as these conform to the fab-provided design rules. Technically, that's still what everyone is doing at the industrial level, except the scripts -- often written in tcl -- are provided by the fab.
Now if you have some FPGA experience, you are probably interested in logic synthesis tools. There are a few ones, I've seen some academic with their own place-and-route stage, for instance. https://open-src-soc.org/program.html#T-CHAPUT does that, I think.
The slides linked above outline one of the possible ways to do this: leverage chisel ( https://www.chisel-lang.org/) and the FIRRTL intermediate representation for RTL description. A few tools can ingest the output and try to come up with a layout. Hammer (https://github.com/ucb-bar/hammer) is such a tool, but I don't think that PDK is available with it just yet. To be honest, I don't think commercial tools are that advanced, and it would be fairly doable to catch up.
There is some interesting work in this field, but since fabbing is expensive, it tends to be more within the academic community than the free software one. I'd look for papers, not on Github, though that's slowly changing.
The chip design world is a slow beast to turn around: everything in the fabrication process is optimized to maximize yield, hence very little leeway is allowed: "If it ain't broken, don't fix it" is the motto, for good reason: if changing humidity levels 0.2% can make a fab lose millions; they won't try to use new and experimental software.
I'm watching this space, notably with Verilog alternatives such as Migen. The open source community starts to embrace FPGA, wich is already great. I wish more manufacturers opened up their bitstream, so maybe we need an open FPGA? Though this free fabbing offer would be a great fit for Wi-Fi chips, I think. I wonder if People at openwifi (https://github.com/open-sdr/openwifi) are interested?
I hope that gives a few interesting pointers to whoever reads this :)
And if they were to, I'd say that Cadence itself isn't especially easy to use, nor complicated to replicate. It would feel more like a lock-in attempt.
The gEDA project would be a good place to start a new layout-level EDA. It has the necessary tools for simulation, already. Synthesis and place-and-route tools exist, but there are many alternatives, documentation is lacking, and I am not sure that PDK is compatible.
I don't know of a good open-source drawing tool, but it shouldn't be too complicated to make a basic one. The more complex part would be to integrate it with DRC (design rule check). An then the usual Layout Schematic Extraction to perform LVS (Layout Versus Schematic) simulation, antenna rules, etc.
Thinking about it, it's a good thing that node isn't too advanced. It reduces the design rules complexity by a few orders of magnitude.
If you have open-source design tool (including schematic simulation and verification), I think you will have open-source tool for physical verification. Assume that we still use rule check standard from Mentor Calibre, Assura.
> Thinking about it, it's a good thing that node isn't too advanced. It reduces the design rules complexity by a few orders of magnitude.
The complexity depends on process. The smaller process, the more complex. There is thousands of rule check even on the old process (180nm, 130nm...).
"Haha, funny!"
> I wouldn't count on it: I don't think Cadence internals have changed much since then.
(Sigh)
The industry has become dangerously too consolidated, with like of Avago/Broadcomm trying to buy themselves a monopoly.
The big semi look at big dotcoms like Google as cows to milk, obviously they don't like it.
How fast is the iterative development and library ecosystem compared to native traditional RTL design tools ?
My biased view is that iterative development with Chisel, to the point of functional verification, is going to be faster than in a traditional RTL language primarily because you have a robust unit testing framework for Scala (Scalatest) and a library for testing Chisel hardware, ChiselTest [^1]. Basically, adopting test driven development is zero-cost---most Chisel users are writing tests as they're designing hardware.
Note that there are existing options that help bridge this gap for Verilog/VHDL like VUnit [^2] and cocotb [^3].
For libraries, there's multiple levels. The Chisel standard library is providing basic hardware modules, e.g., queues, counters, arbiters, delay pipes, and pseudo-random number generators, as well as common interfaces, e.g., valid and ready/valid. Then there's an IP contributions repo (motivated by something like the old tensorflow contrib package) where people can add third-party larger IP [^4]. Then there's the level of standalone large IP built using Chisel that you can use like the Rocket Chip RISC-V SoC generator [^5], an OpenPOWER microprocessor [^6], or a systolic array machine learning accelerator [^7].
There are comparable efforts for building standard libraries in SystemVerilog, notably BaseJump STL [^8], though SystemVerilog's limited parameterization and lack of parametric polymorphism limit what's possible. You can also find lots of larger IP ready to use in traditional languages, e.g., a RISC-V core [^9]. Just because the user base of traditional languages is larger, you'll likely find more IP in those languages.
[^1]: https://github.com/ucb-bar/chisel-testers2
[^2]: https://vunit.github.io/
[^3]: https://docs.cocotb.org/en/latest/
[^4]: https://github.com/freechipsproject/ip-contributions
[^5]: https://github.com/chipsalliance/rocket-chip
[^6]: https://github.com/antonblanchard/chiselwatt
[^7]: https://github.com/ucb-bar/gemmini
Say, as an input you have a layer description (schematics) - how can you transfer it to a tiny scale so precisely to produce a mask?
Here's a video form Intel on how they are made: https://youtu.be/u3ws0UebnSE
Apparently they use "electron beams", not sure what those are, they sound similar to lasers but with electrons, from this video: https://youtu.be/PWV9pvdRBNY
https://www.nikon.com/about/technology/product/semiconductor...
Are older processes more automated?
Can the 130nm production line, produce many different designs without any manual intervention?
The process design kit (or PDK) mentioned in the article takes care of "configuring the machiines". The PDK provides describes how to construct low-level primitives (the instruction set, if you will) for the specific fab. Designers then layer on their logic circuits using those primitives.
Even engineers/students from countries with less resources will now be able to design make prototypes in viable way.
I think, however, that this may help Google integrate into academia. I can imagine a lot of MSEE and PhD students are looking at this hungrily.
Whelp... definitely crossing fabbing off my list.
I wonder if his project would fit the bill here... real VIC-II chips are dying all over the place and getting hard to find... manufactured ASICs to replace them could be a popular item....
The authoritative source seems to be the slides of this guy at google: https://docs.google.com/presentation/d/e/2PACX-1vRtwZPc8ykkk...
From the slides this is "current plans, subject to change". This is an 'open source shuttle process'. Shuttle processes are a relatively cheap way of making small numbers of chips (it is actually more costly per chip, but the fixed cost is smaller). There will be some kind of approval process, and I would imagine that there is a capacity limit for both the number of chips and number of projects.
(I didn't have time to watch the talk, so the above is just from the slides)
- Each shuttle run will accept 40 projects, if more than that apply a selection process will be used. A lottery was mentioned as a possibility.
- First shuttle run this November
Like you mention everything is just planned at this point, but the speaker said these were roughly their goals.
I don't think this program is meant or likely to produce high frequency 100mm2+ chips (and it's worth remembering those chips had a lot of engineering effort put in them outside of manufacturing process) but it should permit chips of somewhat decent performance. It's a very generous thing!
I mean 130nm is 20 year old technology and you can buy general purpose CPUs today which are night and day faster than anything made with 130nm. Allowing you to emulate anything specialized using sofware.
And for gate/line level effects things get slower still. Back when I was doing my master's thesis I was running simulations over the weekend on sequences of 100s of instructions in SPICE.
Then again, this is going to be a really fun experience
- Reimplement the whole thing, in your choice of language, strictly without consideration of performance, to concretely grasp the implementation.
- Rewrite your reimplementation efficiently, using profiling etc, and using SSE/AVX or related techniques if/as possible. (I noticed references to Monte Carlo simulation in the code, and found some noise online that suggests this is vectorizable. I don't understand how MC is being used in the code though.) FWIW assembly language is likely 95-99% not worth chasing instead of Rust or C; one of the few real-world scenarios that call for asm is software video decode/encode, which boils down to patterns of hardcore number crunching that compilers are regarded to optimize poorly. I do not know whether this program is slow because it is poorly optimized or slow because it is simply computationally expensive.
- Rewrite your implementation to run on a GPU, if possible, using OpenMP or CUDA. (This may require implementing your own engine that achieves the same goals as the existing engine, after you achieve a high-level understanding of why the engine works the way it does, because you may need to rearchitect the way the program works in order to cram it into a GPU.)
- Reimplement your implementation in VHDL so it will run on an FPGA.
- Retarget your VHDL so it can be fabbed on a fixed-function ASIC.
This would be my high-level Handwavy Armchair Guide to achieving what you want :)
It's possible that the GPGPU or FPGA milestones will give you a significantly appreciable many-x performance boost. That may be 2x or 10x or 100x; you will be able to find out what is possible almost immediately, as you build your brain-dead implementation and go down little research/analysis paths figuring out how everything works.
It's also possible that the current implementation is poorly designed, and that sticking a profiler on it may find low hanging fruit. Likewise, it's equally possible the current implementation is well-tuned above average (despite being written in C++).
Oh, I found this random link that may be uninteresting or useful: https://news.ycombinator.com/item?id=18628326
Also for analog stuff you can't use FPGAs. And if you need an ASIC anyways for that why not include the digital part as well?
Has this announcement thrown that use-case for FPGAs out the window?
In short, no, this doesn't impact the trade-offs and wouldn't even if Google provided this service as a commercial print-on-demand offering. You can get an ASIC fab'd on older nodes for surprisingly cheap, if you have the know-how and access to tools [2].
When power is a first-class design problem (it frequently is), even an "old" 28nm FPGA like Xilinx's 7 series will run rings around an 130nm ASIC. The extra silicon you're powering in the FPGA is more than offset by the economical access it gives you to modern nodes with lower voltages.
[1]: https://ieeexplore.ieee.org/document/7086413 [2]: https://spectrum.ieee.org/tech-talk/computing/hardware/lowbu...
Edit: Nevermind, another comment says 10 mm^2 per project. That's probably too small for the type of camera sensor I have in mind.
Specifially, slides 35-40. You burn a feature fuse to unlock manufacturing test features. The device is personalized with a serial number + told to generate private key + record stored in database. Then, the key is locked in by burning a second feature fuse that disables any future writing to those segments.
- amazingly good for security.
- finally the public at large will get to understand *in details* how an ASIC is designed.There is no such thing as free lunch! I really wonder what is Google's game plan with this. 20 years ago they started to made maps + email + office +... free for everybody, but the game plan was they gathered everything about everybody, so now we know. Sorry Google, I don't trust you one bit anymore.
An attempt to do something like this would have a Z80, a 6502 and a 68000 in a single chip (none of them are rare, however):
As to whether such changes could be detected, given that the intended design is known, I'm not sure. Someone more knowledgeable than me might be able to comment on that.
(Not entirely simple at 130nm as this is shorter than the wavelength of visible light!)
I always wondered why you needed gearing mechanisms in a micro machine. Has there ever been a practical application for gears in MEMS?
At this size range, though state-of-the-art MEMS (mechanical vibrating frequency filters for RF receivers in phones, accelerometers) can have sub-100nm dimensions, basic accelerometers, pressure sensors, and inkjet heads are absolutely doable.
> Not with this PDK or process, no. MEMS processes are quite specialised.
But yeah, this is the problem. Although ICs and MEMS devices are made with similar tools, MEMS usually needs processing steps that don't play nicely with the steps in an IC process (e.g., etching away huge amounts of silicon to leave gaps and topography, or using processing temperatures and materials that mess up ICs). This SkyWater process cannot do MEMS.
A more general problem is that different MEMS devices often need different incompatible process steps, so a standardized process is infeasible (though http://memscap.com/products/mumps/polymumps tries).
However, there is a tiny chance that, if we get enough detail on the process steps and leeway in the design rules, a custom layout could implement a rudimentary accelerometer or something that works after post-processing (say, a dangerous HF bath), but only with intimate knowledge of said process steps (e.g., internal material stress levels) and a lot of luck.
IIRC, Sandia Lab's SUMMiT V process (the source of videos like [1]) was funded in part to make mechanical latches and fail-safes for nuclear weapons, but I'm not sure what's currently in use for obvious reasons. I don't think they found many other practical applications, though experimentation led to TI's DMD chips, among other things.
Occasionally, MEMS techniques are used to make (relatively large) gears for watches.
I've also seen people try to use gears for microfluidic pumps, but I don't think any are much better than current simpler solid-state approaches.
(1) I wonder if you can make an unpickable lock with MEMS.
Say, if you get a finger print scan, or retinal scan, then the device would need a positive confirmation in order to unlock itself.
I have no idea how practical this is, but it sounds like some kind of Superman genetic authentication system, in order to unlock the information crystals.
(2) The other thing is, can the gears be used to store potential energy? Such as using the microfluidic pumps? Or a microspring?
Where maybe you can use another piezoelectric device, or solar, to provide the electricity to run the gears, in order to store potential energy during peak production hours.
Then, when you need it, you release the potential energy.
The key here might be if you can build a micro electric generator. But I don’t know if you can deposit a pair of opposing micro magnets on a MEMS unit.
But if this can work, then you would need a lot of units, in the tens of billions, in order to produce enough electricity to do something useful.