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!
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.