Hi guys, How do I get hold of the caravel test harness pad frame required for the Google funded MPW? I've got the caravel repo. and copied padframe2.mag from it but it's got other stuff in it. Any one know how I can generate/get hold of the required vanilla padframe? Cheers!

You don't ... currently you have to use the whole caravel, including all the other stuff in there. Only the "user area" (giant hole in the center) is for your use.

Does the user area provide direct pad access for analog designs? Looks like a digital wrapper to me.

It has an analog connection to one of the padframe output, through a ~ 150R resistor for ESD protection.

Are you certain that you're required to use the whole caravel rather than just design a chip with the same pad frame?

Yes.

Ok, cheers

I was given the impression that even analog signals had to get auto-routed to the pads, which basically rules out most analog circuit design for the first tape-out. Hopefully this was either never true, or will not be true of the next tape-out.

@tnt @Tom @Chris Jones I would suggest to contact @Tim Edwards/EFabless about your analog requirements (or any other requirements that do not meet the official MPW rules). The rules are there to cover most cases, special cases need to be discussed.

@Chris Jones: No, that was never true. It is helpful to have openlane do the top-level auto-routing, but it is certainly not mandatory.

So @Tim Edwards, am I free to use the pads in the Caravel padframe as I choose then? It sounds like no since some of the info. I've been reading suggests that the chip is assembled onto boards for you. Are we therefore restricted to use the pins as defined by the user area breakout? They look digital to me yet I'm doing an analog project.

@Tom: There are a few groups who have ripped out the management area of the caravel chip. However, it is one of those things where I would say "don't do this unless you know exactly what you are doing". The padframe has been carefully constructed after reading through the SkyWater I/O documentation many times and consulting with SkyWater about the fuzzier details of the text. The caravel SoC controls the I/O enable sequence and the largish number of signals going to the GPIO pins. As Sylvain noted, you can drop a user project in the middle and route to the analog I/O signals on the user project wrapper, and when you get the chip back on a demonstration board, the managment SoC can be programmed to shut all the digital components of the pads off and run analog signals through. I have made direct connections to the user project wrapper frame pins called "analog_io", which are the signals that Sylvain mentioned, that have a connection to the pad through a 150 ohm resistor. This is the "recommended" way to do analog designs within the caravel project framework. There is also another pin on the GPIO pad cell that is a direct connection to the pad, no resistor, and therefore quite ESD-sensitive; since it is not a signal on the user project wrapper layout, you would only be able to connect to it by routing through the wrapper and directly to the pad, which should be doable if you are careful to look at the full chip layout and figure out where to route through without colliding with other routes. The analog connections can take a voltage from ground to the external 3.3V power supply, and are tolerant of a power supply up to 5.5V, if you want to replace the 3.3V regulator on the development board. Also: Because some people are doing analog designs that cannot tolerate having giant bump bond pads directly on top of them, we are planning to reserve one wafer to not be bump bonded, but have unpackaged parts delivered back to the users. It would then be the responsibility of the user to get the dice packaged and to create a development PCB for it. We are trying to be flexible, but there are costs (and risks) associated with flexibility, and so we are trying very hard to convince people to stick within the standard caravel framework so we can avoid more than a bare minimum amount of "special handling".

Has any group been working on replacement IOs btw ? The frequencies listed in the skywater IO docs are agonizingly slow.

@Tom: FYI, "chip_io" is the layout you want. "padframe2" has the bump bond pads positioned on top (and is unfinished because I have not added the connections out to the padframe; I've been able to put this off because the bump bonding is done by a 3rd party so the layout does not need to be ready at the time of tape-in to SkyWater). But although "chip_io" is a full padframe, it has no connections to the pins other than the power supply rings and clamps, all of which would need to be handled.

Thanks, @Tim Edwards, that's very helpful info. I'm going to do as you suggest (at least until I gain the required experience/knowledge to get more adventurous with a custom breakout).

@tnt: @James Stine is working on an alternative I/O pad set, which should be a lot less complex. You can ask him about the potential frequency response. I was planning to take one of the power pads and rip out the vias to the ESD diode devices so that it would just be a bare connection from pad to core. That would be the simplest method, although then iit would be up to the core circuitry to provide some kind of ESD protection.