I don’t know, why do you refer 14 nm as common. It’s for the newest consumer toys. Regular electronics in your dish washer is made using 65, 90 or even 130 nm process.
130nm was used to make the Athlon XP, Athlon 64, Pentium M, Pentium 4 and PowerPC G5 in the 2001-2003 timeframe [0]. So at the peak of 130nm's performance spectrum, it was able to produce stuff that can still run 2020 software quite okay. The Athlon 64 is probably the best 130nm silicon produced in its heyday and it's in the ballpark of a Raspberry Pi 4 (which has a 28nm SoC) in single core benchmarks.
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!
As I recall from that generation, also the first models of AMD opterons, commonly built into dual socket motherboards. For the time they were very speed competitive with the Intel option.
I recall the dual socket (everything was single core at the time) Xeon being particularly unimpressive.
In fact it was somewhat of a step backwards from the better thermals/power efficiency of a dual socket, 1.13 to 1.4 GHz / 512KB cache Tualatin pentium 3.
That sounds pretty huge. I've never seen on Hackaday or similar people getting small runs of chip fabbed. What are the broader implications of this? Will other fabs start to lower the barrier to production as well?
You generally don't do small runs of chips, unless cost is no object. The NRE costs of getting the masks made, even on older processes like these are still comfortably in the $X00,000 range, blowing past $1 million pretty quickly if you need a process that isn't ancient. That's without design software licenses, which can be hundreds of thousands more.
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).
A while back I came up with the idea of an ultra-miniature quadro copter with asynchronous outrunner motors who's stators would most likely be sintered (with or without a ferromagnetic matrix) to handle the power density, and a simple tube-shaped rotor (though a squirrel cage style might be better).
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).
Skywater (the actual fab Google is using for this program) also runs their own shuttle program[1]. The cost isn't public, but it's reportedly in the range of 40-50k.
I think it combines a multi-project wafer service with some open source tools. I think they are trying to foster a open source development type of atmosphere with chip design. The current commercial tools are expensive and difficult to use. Maybe this can be improved upon to make it accessible to more individuals.
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.
Sounds like there should be open source software for such a thing? I bet the software for laying out transistors and so on will suddenly become viable with something like this, good idea Google!
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.
> 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/
Not only is the software expensive it's often crap. By which I don't mean, oh no it doesn't look nice - crap as in productivity-harming.
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
KiCad is getting very good but it requires a lot of work to compete with the big boys - for example there's no signal integrity built in, and impedance control is fairly detached from your board i.e. I don't think you can do RC on impedance control yet. I don't need a huge amount but signal integrity is fairly important for the project I'm designing.
From what I can tell a lot of parametric design software is also single threaded. I felt like this is was an opportunity where usage of multiple cores could make Freecad stand out a little bit. Except Freecad uses opencascade as their kernel and they require you to sign a CLA just to download the git repository. Considering that barrier to just cloning the code I just decided to not contribute anything. They do offer zip file downloads of the source code but at that point I lost interest.
I suspect geometric kernels and 2D/3D renderers don't fall into the "easy to parallelize" category. Of course there are functions that use multiple threads, but it's not obvious how you could build the core system to do so. However the code in CAD software is often pretty old, it wasn't that long ago that many of these still used intermediate mode OpenGL and I wouldn't be surprised if some still do.
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.
It seems like it depends a lot on your representation of the circuit network. If you consider each trace and PCB element as a node in a graph which maps the connections of the traces and PCB elements then you could parallelize provided you can describe the boundary conditions at each node. There's a degree to which they're interdependent, but there are also nodes at which the boundary condition is effectively constant and I think those would make good cut points for parallelization.
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.
Very similar to what you just said, I suspect that a driving factor in the state of open source in hardware is that anyone working in hardware almost be definition has a large corporate backing, since producing hardware is so capital intensive (compared to software).
If that is basically a given, why publish anything for free, when you can instead charge 10k/seat in licensing?
Possibly because initially the open source software will be significantly worse than the proprietary software and thus won't get any sales, and it will only be better with a lot of contributions, but then it's already freely available and so it still won't get any sales (but might get support/SaaS contracts).
How much has the power efficiency improved between 130nm and 7nm? Is it plausible to get better performance/watt for a custom chip on 130nm vs a software application running on a 7m chip? I get that hardware has other benefits but just wondering for accelerators where the cost/benefit starts to make sense.
I would definitely be rather interested in learning how to design some chips with feature sizes large enough for power handling... I'd love to hear about this as well. This sounds like a clever way to commoditize hardware design, like when printing PCBs became affordable.
But as an example, you WOULD be able to profitably mine bitcoin on 130nm ASICs if all the rest of the world had was CPUs/GPUs/FPGAs, which was more what the grandparent post was asking: 130nm hardware implementations can be much, much faster and/or energy efficient than a 7nm general-purpose chip which simulates the algorithm.
> Is it plausible to get better performance/watt for a custom chip on 130nm vs a software application running on a 7m chip?
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.
> 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.
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.
Doesn't leakage increase again below 22nm because of tunneling losses, though?
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 :)
> Doesn't leakage increase again below 22nm because of tunneling losses, though?
You have tunnelling losses on bigger nodes as well, they are just not that dominant. Dielectrics got better as nodes shrank, and this is the reason FinFETs became practical (which switch faster, and more reliably on smaller nodes, but leak worse.)
An open source WiFi chip would be super cool. I wonder how easy it would be to take the FPGA code from openwifi[0] and combine it with a radio on the same chip?
The problem is that analogue IC design is a field that even digital IC design people regard as black magic. It's clearly possible for that to happen but the set of people who have the skills to do it is very narrow and most of them are probably prevented from doing it in their spare time by their employment agreements.
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?
A big part of the "black magic" really comes down to insufficient tooling. And at least in hardware, insufficient tooling comes down to the fact that everything is open source and trade secret, and teams pretty much refuse to share knowledge with each other.
An open source community would go a long way to fixing an issue like this, and these "black magic" projects are actually a fantastic place for the open source world to get started, because it's an area where there's a ton of room for improvement over the status quo.
Even if you could technically make it work, I'd be very nervous around the legalities of that. Or is the Wi-Fi spectrum so unregulated that you can run without any certification at all?
WiFi equipment (and pretty much every other radio) requires certification in order to be sold in every country I am aware of. WiFI doesn't require a license to operate, but that doesn't mean you can just use any hardware you like (though I think there may be exceptions for hardware you build yourself, at least in the US).
I suspect, however, that the gap between designs that are realizable for amateurs with limited training, and the ones that are realizable for professional teams is wider than in software.
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.
I wasn't able to find great specifications for the 130nm process, but it looks like the difference in transistor size and efficiency is somewhere around 100x. For specialized applications, going from a CPU to an ASIC is usually around a 1000x performance gain.
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.
Not with this PDK or process, no. MEMS processes are quite specialised, and I beleive this project only supports digital standard cells currently, with IO and analogue/RF stuff coming out eventually (it's on the roadmap in the slides).
> I wonder if you can make micro machines at this level? The MEMS thing.
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.
> I always wondered why you needed gearing mechanisms in a micro machine. Has there ever been a practical application for gears in MEMS?
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.
Fascinating, thanks for the info. Some ideas about this:
(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.
> I wonder if you can make an unpickable lock with MEMS
I'm not sure what you mean. MEMS are generally tiny and I'm not sure why you'd need a ~1mm safe? But MEMS relay switches, which mechanically connect/disconnect circuits, exist.
> The other thing is, can the gears be used to store potential energy?
Springs and fluid reservoirs aren't very energy or power dense; good batteries and capacitors are much more effective and reliable. MEMS flywheels have been built and are potentially competitive, but are also extremely tricky to build.
> The key here might be if you can build a micro electric generator.
This is doable and an area of active research (for, say, charging low-power devices when a human walks, definitely not grid-scale power). Magnets are hard to work with in MEMS, so other techniques (piezoelectricity, triboelectricity) are used. [1] is currently badly-written but mentions most important bits.
The efabless people that the talk mentions a bunch of times are using a fully open-source design flow but I think it's a bit hacky (as in, a bunch of command line tools from various open source projects, some of which may be unmaintained judging by the commit logs). They seem to have successfully fabricated a RISC-V based SoC with it though, which is crazy cool.
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 is a bit complicated, isn't it?
I do hope someday, there is solution which is fully opensource for this problem. And it's seems that this day will be long.
IIRC there are a couple ways to produce the intended design. At the end of the day, fabs often take layouts in the GDSII format, which is documented and open. The Klayout open source visualizer is industry-standard in my experience.
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 :)
There is an open PR adding support for the OpenROAD tools [^1]. So, there should be a flow that uses open source VLSI tools eventually.
The Google 130nm library is still filling a huge gap as all the open PDKs up to this point were "fake" educational libraries, e.g., FreePDK [^2]. You can run them through the a VLSI flow, but you can't tape them out.
I wouldn't count on it: I don't think Cadence internals have changed much since then.
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.
> The more complex part would be to integrate it with DRC (design rule check)
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...).
> If you have open-source design tool (including schematic simulation and verification), I think you will have open-source tool for physical verification
Right, though the manufacturer will usually automatically run design rules checks on the submitted designs (they don't want you to endanger other people's components due to density or antenna rules). But I was mostly thinking of it being integrated with a manual layout drawing tool: that's a nice-to-have, but not necessary, and more complex for a drawing tool. If you leave that out, creating a drawing tool should be pretty straightforward.
> The smaller process, the more complex.
Hence my point: it's easier to start with a less-complex process.
This reminds me of how cubesats kind of got off the ground because some launch commpanies allowed extra spare capacity to be sold or donated to student projects.
I couldn't tell which was the cart and which the horse, but the SpaceX telecommunications satellite launch I saw had a rideshare arrangement going on. I suspect what happened is that someone only needed half a payload, and SpaceX filled the rest with their own stuff. But the PR person made it sound like the opposite was happening.
I'm not sure what happens when they reach full capacity on their sat network. Space for research projects, or launching surplus consumables?
With the PDK being open, does anyone know if any kind of NDAs are still required to get a chip fabbed? While free-of-charge fabbing is quite nice, I think being NDA-free is even more important so all work including the tweaks necessary for fabbing can be published, e.g. on GitHub.
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).
From talking to VC. NDA are useless. It really comes down to whether you trust the people or not. It is like patent just a gesture. Everything is in the implementation.
I think the plan is to let people do exactly what you're talking about(let people publish everything down to layout files). At least that's the impression I got from the talk. There is a distro of OpenROAD called OpenLane trying to target this PDK. fossie have a couple of more talks coming up in the next few months on tooling support including OpenROAD, OpenLane, etc..
And I think they're aiming for the first shuttle run in November, so the tooling will have to be ready at least on Q3.
I don't think so. Tim explains in the talk, designs must be submitted via a public Github repository. I think the whole point is to create an open ecosystem.
Meta: please don’t use preformatted text for lists. It makes reading much harder, especially on narrower displays. Just put a blank line between each item, treat each as a paragraph.
yes but since drug discovery isn't bottlenecked by virtual docking throughput, it doesn't matter.
We've seen similar approaches applied to BLAST, and in the end, everybody ends up giving up the ASIC or the FPGA because it's not cost effective long-term.
I initially did an image search to get a quick idea of what you were referring to. "Oh, that looks commercial/expensive..." - but no, it's open source, under the Apache license. Which means the only question is how motivated you really are to speed it up. If your answer is "really really __REALLY__ motivated", then...
- 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++).
Generally you get somewhere between 2 and 3 orders of magnitude power/performance benefit from realizing an algorithm in hardware if it's suitable for that sort of thing. If you're dealing with random memory accesses from a large pool it won't be but streaming tasks like media codecs or encryption work really well.
I know Google absolutely loathes having Intel silicon in their datacenters, the management engine and other blobs can't be audited. It's conceivable they want to help bring open chips to market to try and remedy this problem.
The market of skilled hardware designers is running low: training costs are high, complexity has skyrocketted. By doing this they can increase attention to a field that is otherwise dominated by big corporates (already somewhat the case). The only way to have a sane and healthy chip market is to make 1) the entry barrier low and 2) stimulate innovation. This does both of that.
I wrote something similar above, but maybe a bit like Microsoft acquiring LinkedIn? To get a list of chip designers that could possibly work at Google? Since the designs are open source, they can also evaluate their skill level. And lastly, the contributors are probably less likely to already work at IC companies that have NDAs, etc.
Google wants to create an open, innovative ecosystem for silicon so it will be easier for them to build accelerators for their workloads to meet the growing demand for compute. TPU is only one example of the kind of accelerators they want to build. Tim directly addresses this in the talk: https://youtu.be/EczW2IWdnOM?t=407.
From a hobbyist and preservation perspective, it would be cool if this could be used to produce some form of the Apollo 68080 core to revive the 68k architecture a little bit, and build out the Debian m68k port [0][1]. The last "big" 68k chips were produced in 1995 (that would be a 350nm process?) so this could be hugely improved on 130nm. The 68080 core is currently implemented in FPGAs only and is already the fastest 68k hardware out there. With a real chip, people could continue upgrading their Amigas and Ataris.
[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.
Ah that's a shame. I suppose this could be used to perform a revival of 68k without the Apollo core, but it's a shame that the engineering effort already there would not be available. Maybe this would be an incentive for them to open source it, but yeah.
Note that there have been IP theft and other shadiness allegations from ex-members of the Apollo team.
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.
How fast can those FPGAs be clocked? Is it better to have a free but small run of 68k ASICs which might have similar performance, or the potential to run a soft core on off-the-shelf FPGAs, at much higher cost per unit, but with the ability to rapidly iterate on the design?
The Apollo project here would be particularly suitable as they have already iterated on the design using FPGAs. The chip is already working as an FPGA and bringing tangible improvements: I'm assuming a 130nm ASIC version would be even better.
I'm not sure that assumption is necessarily right. As a general guide, on a cheap (sub $200) modern FPGA I can clock an RV64 core at 50-100 MHz. As you spend more on the FPGA, you can get higher clock rates and/or more cores. Also it should be possible to clock 32 bit cores higher (perhaps much higher) because there will be fewer data paths for internal routing to skew. On the other hand, modern RISC architectures are designed for this, whereas old 68k architectures may not be.
I had no problem running PicoRV32 at 50mhz (maybe higher... 75mhz? can't recall, at that point I had other issues that might not have been CPU related) on an Artix 7 35t.
Honestly instead of chasing after new 68k silicon it'd be better to just emulate on a modern processor. Not the same romance, I know....but
The soft core approach has many advantages, but FPGA companies have dropped the ball on single-unit (hobbyist) sales.
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.
http://www.myirtech.com/list.asp?id=630 looks nice for something under 300$ AND 4GB RAM, but i think the embedded quad-core ARM is still faster than anything you can 'emulate' on the FPGA.
ColdFire is still around but is also not fully binary compatible with 68k. There have been attempts at making Amiga accelerator cards using Coldfires, but I don't think I've ever seen one that was fully finished.
It's not fully binary compatible but pretty damn close. People working on the Firebee were able to make it run pretty smooth, there's some things you can do to trap the old instructions and rewrite. It's never going to work for games and the like, but games and the like from that era have all sorts of other video hardware specific dependencies that are even more difficult to satisfy.
It really is "spiritually" a 68k series processor, just with some cleaning up. I like it.
I am really not an expert in 68k but the Coldfire does not appear to be fully compatible with the old 68ks used in old Macs and Amigas, and Googling around it doesn't appear to have had much uptake if any. It's not being made anymore either.
Interesting thing to consider. I wonder how actively people want to protect 68k, as not even Freescale/NXP seems to use it anymore.
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?
> > I believe freescale currently owns the architecture,
> 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.
"Probably" doesn't seem strong enough. I mean, the only thing that would give you any hope of avoiding being sued out of existence leaving nothing but a small greasy spot behind would be obscurity and commercial irrelevance.
The PowerPC 7457 was built on a 130nm process, used in the AmigaOne XE as well as the Apple G4 machines. That's probably about as good as you will get for an community-led chip fabrication. You could probably get it up to over 1GHz if you made a 68k at this size. A modern FPGA is probably the better way to go for this kind of thing. I doubt this free fab includes things like die testing and packaging. That's an expensive process so someone would need to front some money to actually get the testing and packaging done for enough chips to make the cost actually worth it. It would be much cheaper to design an interposer board that could plug into a motherboard to take the place of the original 68k. This would also allow you to continuously upgrade the processor without requiring a whole new fab to take place.
>You could probably get it up to over 1GHz if you made a 68k at this size
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.
Coldfire is what they would have, and did, make. By dropping a few problematic instructions they were able to use a more RISC-like approach and produce a nicer core. Most code just needs a recompile, or you can trap the old instructions and work around them.
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.
Strategically, could this be part of a response to Apple silicon?
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.
My first reaction was that it could be a recruitment drive of sorts to help build up their hardware team. Apple have been really smart in the last decade in buying up really good chip development teams and that is experience that is really hard to find.
It wouldn't surprise me. They've been designing custom hardware for some time. Look at the Pluto switch and the "can we make something even more high performance" or "we can make it simpler, cheaper, more specialized and save some watts" (which in turn saves on power for computing and power for cooling costs).
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.
Pluto is merchant silicon in a box, like all their other switches.
"""Regularly upgrading network fabrics with
the latest generation of commodity switch silicon allows
us to deliver exponential growth in bandwidth capacity
in a cost-effective manner."""
I wasn't intending to claim that Pluto is custom silicon but rather that Pluto is an example of Google looking for simplicity, more (compute) power, and less (electrical) power.
The next step in that set of goals for their data center would be custom silicon where merchant silicon doesn't provide the right combination.
> Apple have been really smart in the last decade in buying up really good chip development teams and that is experience that is really hard to find.
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.
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.
These are not related at all. Only common element is making silicon.
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.
That's not terribly long ago, really. My understanding is that a sizeable chunk of performance gains since then have come from architectural improvements.
My understanding is that architectural improvements (i.e. new approaches to detect more parts in code that can be evaluated at the same time, and then do so) need more transistors, ergo a smaller process.
(Jim Keller explains in this interview how CPU designers are making use of the transistor budget: https://youtu.be/Nb2tebYAaOA)
Probably the fastest processor made on 130nm was the AMD Sledgehammer, which had a single core, less than half the performance per clock of modern x64 processors, and topped out at 2.4GHz compared to 4+GHz now, with a die size basically the same as an 8-core Ryzen. So Ryzen 7 on 7nm is at least 32 times faster and uses less power (65W vs. 89W).
You could probably close some of the single thread gap with architectural improvements, but your real problems are going to be power consumption and that you'd have to quadruple the die size if you wanted so much as a quad core.
The interesting uses might be to go the other way. Give yourself like a 10W power budget and make the fastest dual core you can within that envelope, and use it for things that don't need high performance, the sort of thing where you'd use a Raspberry Pi.
Your suggestion was more what i was thinking, perhaps something more limited in scope than a general processor. An application that comes to mind is an intentionally simple and auditable device for e2e encryption.
You wouldn't get access to ASIC fab just to make a CPU. Fill it with tensor cores, or fft cores, plus a big memory bus. Put custom image processing algorithms on it. Then it will be competitive with modern general silicon despite the node handicap.
Think of all the chips from then and before then that are becoming rare. The hobbyist and archivist community do their best with modern replacements, keeping legacy parts alive, and things like FPGAs, but to be able to fab modern drop in replacements for rare chips would be amazing.
Things don't have to be ultra modern to offer value.
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.
They're not doing this out of the kindness of their heart. Just because we don't know the data being collected here (yet) does not invalidate my statement. Name a google product and you can easily identify the unique data being collected.
> I don't believe Google does anything because it's a "nice thing to do".
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.
Can someone please tell me how photo-masks are produced? I don't understand how can tiny features be printed at almost the same scale as a final structure? With a laser beam?
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?
Photographic reduction. The masks are much larger than the final chips. https://commons.wikimedia.org/wiki/File:Semiconductor_photom... (Actually AIUI in EUV photolithography you can't use transparent masks, but must use a kind of mirror with the pattern etched onto it.)
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
Is enough of the PDK open now to allow for actual hacking on devices? I have a rather simple analog chip I'd love to make for my own personal uses (I'd love a really long modern bucket brigade device to build gritty analog delay lines for synth hacking)...
What are the chances that google will add their own hidden or proprietary circuitry to any open-source chips? They'll add all sorts of "Security" and "Tracking" features..
Approximately zero. They have nothing to gain from doing so, and everything to lose. It isn't a website we're talking about, adding that kind of complexity to a chip would be highly obvious to the people who integrate it, who aren't from Google.
To a chip? Doesn't seem likely. Adding something like an Intel Management Engine is quite a task, and they'd look awful if they got caught trying it in secret. If they're just making the CPU, in isolation from the rest of the system, I imagine it would be just about impossible to do something like that.
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.
If you hand them GDSII then fiddling with it is very time-consuming and difficult, but can be spotted by looking at the resulting chip under a microscope.
(Not entirely simple at 130nm as this is shorter than the wavelength of visible light!)
Also, adding something like that would be an incredible amount of work. Basically you would have to totally re-do the layout even if you're just adding a macro somewhere and totally re-design it if you're not going to end up causing a drastic decrease in max clock rate. That's for an management engine or tracking style thing. A backdoor that makes #5F0A40A3 equal to every other number for password bypass wouldn't be that invasive and might only slow things down by a little bit so I guess that's a possibility if a certain design becomes really popular?
The designs have to fit in 10mm² but the total chip will be 16mm² with the pads, a RISC-V and some interfaces supplied by Google. They could obviously fit some trick into their part, but given that it too will be open source you can inspect it if you don't trust them.
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.
I should note there's open source ASIC toolchain - OpenROAD[1][2]. I wonder if these can be integrated. You also can use SymbiFlow to run your prototype in FPGA[3][4].
This is a 0.13µm CMOS process while the 4004 was made using a 10µm PMOS technology. So the electrical characteristics would not be the same. If you don't care about that then the answer is "yes".
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):
The crossover point where ASICs become less expensive than FPGAs is also lower than you might think even including mask costs, provided it's on an older process node.
Sounds interesting but what you build as an open source chip?
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.
Gate level emulation is really, really slow. If you've got a nice abstraction like the x86 ISA you can simulate a chip at that level far faster but if you're interested in the net level design rather than the abstraction emulation will be way, way slower. At least in throughput, it takes a long time to fab a chip and so you really ought to do emulation first in any event.
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.
403 comments
[ 0.25 ms ] story [ 274 ms ] threadpricing: https://www.androidauthority.com/cheap-android-phones-269520... soc: https://www.samsung.com/semiconductor/minisite/exynos/produc...
https://en.wikipedia.org/wiki/STM32
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!
[0]: https://en.wikipedia.org/wiki/130_nm_process
In fact it was somewhat of a step backwards from the better thermals/power efficiency of a dual socket, 1.13 to 1.4 GHz / 512KB cache Tualatin pentium 3.
* 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
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.
https://en.wikipedia.org/wiki/Multi-project_wafer_service
https://www.tekmos.com/products/asics/reducing-the-asic-nre
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/
[2] https://europractice-ic.com/
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.
[1] https://www.skywatertechnology.com/mpw-fastshuttle/
https://en.wikipedia.org/wiki/Multi-project_wafer_service
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.
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/
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
Hardly Altium Designer's fault, but I too would avoid using it.
https://kicad-pcb.org/blog/2020/04/Development-Highlight-Alt...
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.
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.
[1] https://dev.opencascade.org/index.php?q=node/1212#comment-86...
If that is basically a given, why publish anything for free, when you can instead charge 10k/seat in licensing?
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.
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.
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 :)
You have tunnelling losses on bigger nodes as well, they are just not that dominant. Dielectrics got better as nodes shrank, and this is the reason FinFETs became practical (which switch faster, and more reliably on smaller nodes, but leak worse.)
[0] https://github.com/open-sdr/openwifi
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?
An open source community would go a long way to fixing an issue like this, and these "black magic" projects are actually a fantastic place for the open source world to get started, because it's an area where there's a ton of room for improvement over the status quo.
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.
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.
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] https://www.youtube.com/watch?v=GiG5czNvV4A
(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.
I'm not sure what you mean. MEMS are generally tiny and I'm not sure why you'd need a ~1mm safe? But MEMS relay switches, which mechanically connect/disconnect circuits, exist.
> The other thing is, can the gears be used to store potential energy?
Springs and fluid reservoirs aren't very energy or power dense; good batteries and capacitors are much more effective and reliable. MEMS flywheels have been built and are potentially competitive, but are also extremely tricky to build.
> The key here might be if you can build a micro electric generator.
This is doable and an area of active research (for, say, charging low-power devices when a human walks, definitely not grid-scale power). Magnets are hard to work with in MEMS, so other techniques (piezoelectricity, triboelectricity) are used. [1] is currently badly-written but mentions most important bits.
[1] https://en.wikipedia.org/wiki/Nanogenerator
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 :)
The Google 130nm library is still filling a huge gap as all the open PDKs up to this point were "fake" educational libraries, e.g., FreePDK [^2]. You can run them through the a VLSI flow, but you can't tape them out.
[^1]: https://github.com/ucb-bar/hammer/pull/584
[^2]: https://www.eda.ncsu.edu/wiki/FreePDK
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...).
Right, though the manufacturer will usually automatically run design rules checks on the submitted designs (they don't want you to endanger other people's components due to density or antenna rules). But I was mostly thinking of it being integrated with a manual layout drawing tool: that's a nice-to-have, but not necessary, and more complex for a drawing tool. If you leave that out, creating a drawing tool should be pretty straightforward.
> The smaller process, the more complex.
Hence my point: it's easier to start with a less-complex process.
"Haha, funny!"
> I wouldn't count on it: I don't think Cadence internals have changed much since then.
(Sigh)
I'm not sure what happens when they reach full capacity on their sat network. Space for research projects, or launching surplus consumables?
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/
Then again, this is going to be a really fun experience
We've seen similar approaches applied to BLAST, and in the end, everybody ends up giving up the ASIC or the FPGA because it's not cost effective long-term.
- 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
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.
[0]: http://www.apollo-core.com/ I can't easily find how "open source" it is though, but it's free to download.
[1]: https://news.ycombinator.com/item?id=23668057
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.
https://wiki.apollo-accelerators.com/doku.php/about_us:links
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.
Honestly instead of chasing after new 68k silicon it'd be better to just emulate on a modern processor. Not the same romance, I know....but
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.
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?
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.
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.
Even engineers/students from countries with less resources will now be able to design make prototypes in viable way.
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.
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.
"""Regularly upgrading network fabrics with the latest generation of commodity switch silicon allows us to deliver exponential growth in bandwidth capacity in a cost-effective manner."""
https://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p183...
The next step in that set of goals for their data center would be custom silicon where merchant silicon doesn't provide the right combination.
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.
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.
But that all means nothing for companies who buy Virtuoso copies from from guys trading WaReZ in pedestrian underpasses in BJ.
A number of quite reputable SoC brands here in the PRD are known to be based on 100% pirated EDAs.
This is not a critique, but a call to think about that a bit.
In China, you can spin-up a microelectronics startup in under $1m, in USA, you will spend $1m to just buy a minimal EDA toolchain for the business.
Allwinner famously started with just $1m in capital, when disgruntled engineers from Actions decided to start their own business.
Not cool man, not cool.
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.
And by old, I mean /old/. 130 nm was used on the GameCube, PPC G5, and Pentium 4.
(Jim Keller explains in this interview how CPU designers are making use of the transistor budget: https://youtu.be/Nb2tebYAaOA)
You could probably close some of the single thread gap with architectural improvements, but your real problems are going to be power consumption and that you'd have to quadruple the die size if you wanted so much as a quad core.
The interesting uses might be to go the other way. Give yourself like a 10W power budget and make the fastest dual core you can within that envelope, and use it for things that don't need high performance, the sort of thing where you'd use a Raspberry Pi.
Things don't have to be ultra modern to offer value.
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.
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?
https://www.nikon.com/about/technology/product/semiconductor...
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://en.wikipedia.org/wiki/Electron-beam_lithography
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!)
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
[^8]: https://github.com/bespoke-silicon-group/basejump_stl
[^9]: https://github.com/openhwgroup/cva6
[1] https://theopenroadproject.org/
[2] https://github.com/The-OpenROAD-Project/OpenROAD
[3] https://symbiflow.github.io/
[4] https://github.com/SymbiFlow
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):
https://www.crowdsupply.com/chips4makers/retro-uc
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?
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.