I've been following this closely and put a fair bit of time into porting a CAD tool to this new process.
I won't be submitting a design at this time.
The Google sponsorship comes with a lot of strings attached. That's okay, "he who pays the piper calls the tune". Unfortunately unlike MOSIS and IMEC there is no option to pay your own way in order to drop the strings. Based on MPW charges for other foundries through MOSIS+IMEC the Google subsidy is worth around $5k-$10k per submission [1]. But there isn't any option to pay that amount yourself.
One of the most problematic "strings" is the fact that you do NOT get a reserved booking. This is a big issue because for anything more serious than an undergrad-level "hey I threw a pile of verilog at the place+route tool" the designer time invested will be worth a lot more than $5k-$10k. But they expect you to invest this with zero guarantee of getting it fabbed, which means that investment can easily get dumped in the trash bin. Project selection is "random" which is sort of just another way of saying "unaccountable".
The other problematic "string" is the Management Engine Padframe [2] they wrap around your design. You can't touch it or change any part of it, and it sits beteween your design and every single pad that faces the outside world. This sort of Management Engine garbage is exactly what we need open silicon in order to avoid. Yet here Google and Skywater and eFabless are sticking it back into the mix. Oh, by the way, this makes "OpenMPW" totally unusable for any RF work, or any design that needs an analog input.
Kinda miffed about all this, especially that they sprung the "Management Padframe" on us two weeks before the tapeout deadline. That screams to me "this is not for serious designs, please undergrads only thanks".
PS, It's also intensely irritating that you're forced to create a LinkedIn account and must use your LinkedIn account to log in to the MPW upload site. That is some amateur-grade personal data harvesting there. Serious MPW providers, like MOSIS who have been doing this for 25 years, give you their PGP key for you to encrypt the GDS with and don't put you at the mercy of deplatforming by LinkedIn for whatever lame reason LinkedIn cooked up this week.
Ultimately this is the first run of many. This first shuttle is very much a trial run where they're hoping to identify issues and get things smoother for the second time round. It's not intended for people who are primarily interested in getting their ASIC made for free (where putting in the design time without result is not acceptable). It's for people who are motivated by the concept of open source silicon and are happy to put in their time, potentially with no reward, to help move that concept forward.
Things have been a bit chaotic for the first shuttle, but that's not hugely surprising given the nature of the project. I can't blame them for choosing a random selection process, as they had no real idea who would be submitting designs, what they would be and what level of quality they would be at or if they'd even fill all the slots. Random seems entirely fair for this first, alpha quality level run. Some defined selection process may be appropriate for future runs but you need to see the submissions coming into the first one to work that out.
As for Caraval I think it's been well known this will be required from the beginning, perhaps they could have done a better job in documenting this (it's been extensively discussed on the Slack group, plus mentioned in various talks).
I think you're expecting a matured, tested setup that gives you good documentation where you just submit your finished design without any further interaction with the community. It may well get to that point, but it's not there yet. This is just the beginning and if you're not interested in getting stuck in with pushing the concept forward, just interested in simply using it, you will need to wait a while.
I agree the submission process has been somewhat chaotic, but I don't think it has been exceedingly so. The fact that this was gonna be an alpha test of new technology was clear from the start. Taping out with a modern PDK and open source tools just hasn't been done before. Also, the caravel requirement has been known for at least three months. True the design wasn't done yet and the details were sparse, but saying it was added two weeks before the tapeout deadline is disingenuous when it was announced at the start of the program. As for not taking your money to get your own tapeout, I'm sure they'll be most happy to do so once they've worked out the kinks, which is exactly what they're using the shuttle runs for.
(Not affiliated with the project in any way, just watching closely out of professional interest).
> Also, the caravel requirement has been known for at least three months.
That is simply false. Maybe known to insiders at eFabless.
Seriously where do you see any public mention of "caravel" three months ago? There's absolutely nothing about it on the mailing lists [1] [2].
> it was announced at the start of the program
Where?
I heard about this in late July and have been following this very closely since they posted the design rules in early September. I've probably read through the DRC rule document more closely than anybody outside of Google/Skywater/eFabless. Two weeks ago there was nothing anywhere in any of that about having to use their "Caravel" management padframe.
As of 15-Sep (git commit 107103f922db43408f59a1540cd4bd3737b30172) the text "caravel" does not appear anywhere in the PDK [3]. I checked with:
It was talked about all over the place. E.g. see https://youtu.be/EczW2IWdnOM from June around the one hour mark. As I said, I'm very far from an insider.
What are you referring to, where exactly in there? I poked "around the one hour mark" and didn't stumble across it, but am not gonna watch the whole thing. It's over an hour of somebody talking at a camera.
Does an offhand comment buried in the middle of a 90-minute youtube ramble really strike you as appropriate notification of such an important requirement? Especially when this requirement doesn't appear anyplace where it can be read?
I just gave an example, I didn't mean to say it was the exclusive source of info. Every discussion I've seen of what the layout would actually be was always "roughly 10mm^2, pending finalization of the harness". Also, it was talked about many times on the slack. Look, I have no dog in this fight. All I meant to say was that this was not some sudden last minute change of plans. Could things have been communicated more clearly? Sure. But that's par for the course for an alpha program like this.
The slide at 1:02:49 has "standardized harness" in bold red. It's up for a few minutes and the presenter discussed the harness and reasoning for a good minute or so.
He says (1:03:00) that the harness "will be isolated from the area that your design goes into" and (1:03:21) that it will "enable probing and controlling your region if you want".
In other words, the video says you can simply not connect to it and not use it if you don't want it. He never says anything about it being hardwired to the padframe.
Then, two weeks before tapeout, they changed the rules and made this thing not only mandatory, but made it the only way your design can boot up or communicate with the outside world.
> In other words, the video says you can simply not connect to it and not use it if you don't want it. He never says anything about it being hardwired to the padframe.
I didn't get that impression. As I understood it, the probing and controlling is, entirely, "if you want". However IO via the harness is not optional. As the other user says, perhaps this was not communicated clearly to you, but an intentional bait and switch it doesn't appear to be.
My definition, it’s not a bait and switch because they weren’t deceptive and you were never sold anything. Could be better communicated? Sure. But deceptive? No.
Maybe the name "caravel" is new, but the presence of a standardized harness was announced at the same time as the whole initiative.
There's some discussion of the harness on skywater-pdk-users, and it was mentioned in various comments in the previous discussion on HN: https://news.ycombinator.com/item?id=23755693
I know this is somewhat out of context, but just wanted to say thanks for helping create Julia! I remain ever grateful that I was able to take my undergraduate math courses coding in Julia instead of being forced to use Matlab or R.
Paying your own way defeats the purpose for their goals here. They are looking to build an open-source reposiory of tooling and designs. For that, some standardisation is required. If you are looking for a commercial chip spin, don't expect it to be free.
This is a really cool and unprecedented open source project by Google.
> Oh, by the way, this makes "OpenMPW" totally unusable for any RF work, or any design that needs an analog input.
Pretty sure that there are some analog io pins in the caravel harness.
> This sort of Management Engine garbage is exactly what we need open silicon in order to avoid.
The comparison of the caravel harness to Management Engine seems weird - caravel itself is also open, from RTL down to GDSII.
> Serious MPW providers
It's been pretty obvious that this first free shuttle run is not a "serious" MPW provider, but the first trial of a new (open) PDK and a lot of new tools. If you are looking for a serious professional provider, look elsewhere or perhaps come back later.
To get analog io, projects can connect to the analog_io pins in the wrapper [1] which connect to the pad through a 150 ohm resistor, and disable the digital GPIO drivers. If that resistor is a problem, user projects can route directly to the pad_no_esd pin.
There are a number of people working on analog or mixed-signal designs inside the caravel harness with analog io.
From caravel/verilog/rtl/README:
> mprj_io: 32 bits general purpose programmable digital or analog I/O
> The user will also have access to the ESD-protected pad connections for analog signals
Only the digital I/Os are accessible from outside the package. Every entry in the table has either "power", "ground", or "digital {in,out,I/O}" for the "type" column.
They appear to have some kind of simple output-only analog driver (see "analog output" in the Summary Description column) but no analog input according to the datasheet.
Clicking through to "Caravel" made it immediately obvious what this is: it's not a system for you to get help from Google, it's a system for you to donate your work to Google and put it on the corner of a chip for them. Hence the opaque selection criteria and the standardised "parent" SoC controller.
Oof, that management padframe is a dealbreaker for me. I was interested in potentially doing some interesting analog parts. If I can't even do that, this is way less interesting to me.
What exactly was the justification for slapping that thing on, anyway? It looks like they want to use it for on-die test, but why make it mandatory?
I agree there has got to be a better way to select projects than random. I find it hard to think of an objective and fair critera, but something involving a mix of effort, research quality, and value to the community would be good.
The requirement to use caravel I don't think is overly malicious, but all I heard was "we want to see how people use it". I don't know the reason it's not optional this shuttle run, but I figure it could become optional on future runs. (can't say for sure though.)
Also, normally beggars can't be choosers and that's a reasonable take -- but this is kind of different... Preparing your project for submission is a ton of work and users are not being told what to expect very clearly.
> I agree there has got to be a better way to select projects than random.
Provably random? It really seems like "random" is just a way of saying "we're not going to discuss our decision process".
> The requirement to use caravel ... but all I heard was "we want to see how people use it".
That makes no sense.
I'll give them credit for one thing: the way they're doing the WLCSP packaging far-backend run is very slick and cool. Ordinarily WLCSP packaging costs a fortune, and you have to run your own boat of wafers from the MPW to get it. By forcing everybody to use WLCSP with the same pinout EVERYBODY gets this cool option at a reasonable price.
But they could very easily have simply said "your UBM layer must be identical to the Caravel padframe's UBM layer" (UBM is the layer that says where the top level of chip metal interfaces with the Under Bump Metallization of the WLCSP package). Basically just say you pins have to be in the same place as Caravel but you don't need to use the rest of it.
Compared to what, a bare die? WLCSP is usually cheaper than plastic packages...
Edit:
Maybe that's only true in volume? I guess throwing a handful of dies on a wirebonder is easy compared with designing and fabbing the interposer, and who cares if the plastic costs a few cents more.
WLCSP unit cost is very low, but there is a very high fixed cost.
Also WLCSP packaging must be done a wafer-at-a-time. With an MPW, you don't get a whole wafer of your chips -- they cut up the wafer and send the chips with your design to you, and the chips with other peoples' design to the other people.
So ordinarily on an MPW if you want WLCSP, you have to pay the fab to run a whole second "boat" of wafers just for you, so those wafers can be run through the packaging process before they are cut up. This often costs more than the MPW booking does!
Pulling a Google Fiber on the chip fabs might not be a bad thing right now -- TSMC is way, way too powerful at the moment. Even Google isn't the driving factor behind a likely military invasion.
Actually there's one other possibility: that this is an audition before Google acqui-hires eFabless.
Can't say I blame them. Running MPW shuttles is an incredibly tough business; of the three leading shuttle providers (MOSIS, IMEC, CMP) two are non-profits affiliated with universities and the third used to be. There isn't a lot of profit in it.
And I can't really blame Google either... Tim Edwards is easily worth the entire company's payroll so they'll be getting a great deal as long as they can keep him interested.
Maybe I'm not looking far enough ahead, but how is running 130nm MPWs competing with the TSMC/Samsung level of fabs?
I can see how eFabless might have the effect of commoditizing a foundry because you aren't necessarily locked in to their tooling.
But doesn't that principle only sort of hold if the foundry's process itself is sort of a commodity (i.e. mature,old)? Old has worse connotations than I mean, because you can do a lot at fairly large nodes, you just aren't making iPhone SoCs at 130nm.
You'd be surprised how much stuff is made on these old processes. A lot of very security-cricial stuff like Baseboard Management Controllers, lights-out management controllers, and laptop embedded controllers are almost entirely built on pre-OPC (i.e. pre-90nm) processes.
All of those chips are in the "security flaw equals remote root" category.
SkyWater's 130nm process is compatible with on-die flash (unlike most post-90nm and nearly all post-40nm processes). You could do a "secure enclave" or your own Hardware Security Module and not have to worry about backdoors.
But to answer your question directly: this isn't about making an iPhone comeptitor.
> Pulling a Google Fiber on the chip fabs might not be a bad thing right now -- TSMC is way, way too powerful at the moment. Even Google isn't the driving factor behind a likely military invasion.
TSMC only got so powerful because the competition, especially Intel, were abysmal failures in rolling out new tech. It's not like their Dutch supplier ASML only sells their tech to TSMC, too. Anyone with the cash at hand could buy their stuff.
Also: the last US governments (both Obama and Trump) or the major EU governments could have stepped in any fucking time in the last 10-15 years and say "hey it might be a good idea to have some backup for Intel instead of leaving everything to Taiwan"... only in 2020 TSMC finally announced to build an US fab, and the EU is still sitting on their hands.
Google do not have the commitment, focus, or skillset to compete in ASICs. Certainly not to compete with TSMC themselves. Apple have the design experience now to deliver the M1 - 12 years after acquiring PA Semi. And it's manufactured by .. TSMC.
This has every hallmark of a VP who wants to play with semiconductors, not a serious attempt to deliver something specific.
They have to honor existing contracts which keep them on the hook for many years. When Larry announced they were scaling back, he specifically cited this sort of leverage being the biggest concern.
Not entirely. I'm not sure if they're still introducing Google Fiber to new cities, but they're definitely still expanding to new neighborhoods in existing cities.
I don't think they even have full saturation in their pilot cities and only see one city added in the last year. Considering Google's tendency to cut projects below a certain size as much I'd love to be a Google fiber customer it's more realistic to expect it to be killed in the next year or two.
I'm not kidding, read the other articles, at least the "Strategy" ones. Some technical details have changed but many of the fundamental principles still apply ;-)
"The pattern of “commoditizing your complement”, an alternative to vertical integration, where companies seek to secure a chokepoint or quasi-monopoly in products composed of many necessary & sufficient layers by dominating one layer while fostering so much competition in another layer above or below its layer that no competing monopolist can emerge, prices are driven down to marginal costs elsewhere in the stack, total price drops & increases demand, and the majority of the consumer surplus of the final product can be diverted to the quasi-monopolist."
Usually, the more competition there is in a market segment, the lesser the margin becomes.
Let's say your customer often "complement" your offer A with B from another company. If the other company faces fierce competition on the market for B, its margin will be low. So, you may be able to capture a little bit more of the customer's money: he wants to spend x on both stuff, the less it spends on B, the more it can spend on A.
The original deadline was two days ago, but it seems to be extended indefinitely. The reason is that all parts of the stack, caravel, openlane, openroad, and the submission process itself are under heavy development that is only just finishing. Much frustration and hand wringing has been had in their slack group in recent days.
For something this complex and new a chat interface is totally inappropriate. You're going to have hundreds of people asking the same question -- you need a searchable mailing list so people can see if their question was already asked.
Putting data that should be public behind signupwalls with abusive TOSes (Slack, LinkedIn, Discord, Facebook) is becoming quite the trend these days, even in places you wouldn't expect it. Thanks for speaking up about it.
It'll be interesting to see what this is used for. Probably mostly university EE projects. Thats a good thing: More chip designers coming out of college fully-formed.
I won't be submitting a design at this time.
The Google sponsorship comes with a lot of strings attached. That's okay, "he who pays the piper calls the tune". Unfortunately unlike MOSIS and IMEC there is no option to pay your own way in order to drop the strings. Based on MPW charges for other foundries through MOSIS+IMEC the Google subsidy is worth around $5k-$10k per submission [1]. But there isn't any option to pay that amount yourself.
One of the most problematic "strings" is the fact that you do NOT get a reserved booking. This is a big issue because for anything more serious than an undergrad-level "hey I threw a pile of verilog at the place+route tool" the designer time invested will be worth a lot more than $5k-$10k. But they expect you to invest this with zero guarantee of getting it fabbed, which means that investment can easily get dumped in the trash bin. Project selection is "random" which is sort of just another way of saying "unaccountable".
The other problematic "string" is the Management Engine Padframe [2] they wrap around your design. You can't touch it or change any part of it, and it sits beteween your design and every single pad that faces the outside world. This sort of Management Engine garbage is exactly what we need open silicon in order to avoid. Yet here Google and Skywater and eFabless are sticking it back into the mix. Oh, by the way, this makes "OpenMPW" totally unusable for any RF work, or any design that needs an analog input.
Kinda miffed about all this, especially that they sprung the "Management Padframe" on us two weeks before the tapeout deadline. That screams to me "this is not for serious designs, please undergrads only thanks".
[1] https://europractice-ic.com/schedules-prices/
[2] https://github.com/efabless/caravel
PS, It's also intensely irritating that you're forced to create a LinkedIn account and must use your LinkedIn account to log in to the MPW upload site. That is some amateur-grade personal data harvesting there. Serious MPW providers, like MOSIS who have been doing this for 25 years, give you their PGP key for you to encrypt the GDS with and don't put you at the mercy of deplatforming by LinkedIn for whatever lame reason LinkedIn cooked up this week.