<!channel> Okay, once again. . . Sorry about the channel blast, but I would like to get feedback from former/current/future Caravel designers to help with the definition of the next-generation Caravel chip, specifically to define the padframe pinout of the harness, which is something that everyone on this channel ought to have a say in. The rest of this message is largely a repeat of the message from Thursday, as I was unable to reach everyone on the channel. For those who did read it and respond, thank you! There is ample room around the existing caravel/caravan/openframe padframe to roughly double the existing number of pads. However, the more pins there are, the larger the package and the more complex the development board, not to mention complications of the design of the power supply network on-chip. I do know that some designers had projects in mind which exceeded the 38 GPIOs available in the current Caravel chip, and some people have told me that they were reducing the scope of their designs to fit it in the existing 38 GPIOs. I would like to get some feedback from anyone who has considered a design that requires a large number of GPIO pins about what the use case is, and what is the minimum number of GPIOs needed for that use case. Are there any obvious use cases which would require more than 64 GPIOs? More than 72? The main idea would be to group GPIOs in banks of 8 bits, and the maximum size that we think is possible (but not necessarily practical) with the existing die size would likely end up as a 128-pin TQFP and could have as much as 9 banks of 8 GPIOs. Most likely we will reduce the total GPIO count and provide additional analog or high-speed digital components with dedicated inputs/outputs. If you have requests for an improved architecture, let me know!

I know that I'm not the best example of a previous designer, since MMWICs are quite niche, but having some support for GSG/GSGSG input and output would be interesting for designing MMW front-ends. I have designed a GSG pad for my previous tapeout that I could gladly share if there's interest

I think being able to leverage some of the GPIOs as extra power supplies and clocks could be useful — we were looking into making a wavelet processor (cochlea) where having more GPIOs would just allow the design to come up independently of the RISCV processor, but then we realized that we could just leverage the ROIC’s logic analyzer to generate some of the signals we were putting on GP inputs. Then any spare GPIOs just allow us to bring out test / debug signals, analog and digital, and although we haven’t tried this, it might be useful for debug and power measurements to be able to split apart some more IP-specific power supplies.

I personally think that the pin count should be kept such that the ball pitch on the RDL is 0.5mm minimum, as below that reduces PCB/PCA fab. options for people. Other than that being able to choose your pads (like you suggested in another thread @Tim Edwards) would be realy cool

@Tom: The expectation is that we'll keep the same WLCSP ball pitch if we use WLCSP (which we are considering switching to again because the wirebonding jobs have gotten so backlogged that the wirebonding is no longer a clear winner for lowest turn-around time for manufacture). A WLCSP solution would not be able to output more than 70 pins (I've done that exercise before). But we could potentially use a BGA package if we can find a cheap one (not obvious that we can make that cost-effective) which would be larger than the WLCSP solution but a lot smaller than a QFN or LQFP.

👍

I used gpio for analog purposes and found it apt .I will test my chip and provide more feedback soon,but I felt caraval should have Ethernet other than spi. It helps in multi chip design for AI application . Or PCI. One of them should be considered to make it suitable for larger sustem design @Tim Edwards

What options do we have for high speed IOs? Maybe a separate bank for that if it is even possible? I'm mostly after 100MHz+. I recall reading somewhere the IOs were rated max 50MHz.

You can check the spec for the SIO, which Is rated higher than the GPIO, maybe up to 100MHz. The SIO was part of the SkyWater I/O set that did not get into the first round of pushes on the Google repo, but we just managed to get Google to agree to take a pull request with the IP added, a few week ago. The SIO has been in the documentation the whole time, though. Otherwise I would probably add a special purpose pad that can drive LVDS or LVPECL.

Thanks Tim. I'm not up to speed with what progress has been made in the last few months, but a Caravel solution with some open source IP on high speed serial links would enable new applications. Maybe I haven't caught up enough to know this is already the case?

@Kauser Johar: No, it's not the case yet. We have been keeping the original Caravel design, or something close to it, for all of the shuttle runs so far. The only solution for high speed is the Caravan design, using the straight-through analog pads, but that is difficult for most designers because they have to figure out how to provide ESD protection themselves.

Just add our small team's niche use case, which is most likely not a common one: we make charge / pixel array sensors. Usually, we want as many analog IO as possible, primarily for test purposes. We normally handle bare dies and do wirebonds or other packaging ourselves (already did in a few past chipignite runs successfully). That said, a prepackaged chip with only a select subset of pins routed out is still very useful for initial bringup and tests. So, in my imagination, the Caravel padframe should be filled with pads, but not all pads are necessarily routed out in the standard packaging. Typical users/advanced users can then choose what they want to do.

Hello Tim, I am more of an analog/mixed signal guy and have only used the Caravan harness, but I thought I would message anyway. - I agree that higher speeds on the GPIO would be extremely useful. The GPIO speed is actually a “fake” limit the sample rate of my ADC (my ADC can go faster, but the clock was sent through a GPIO to accommodated other designs on the Caravan). - I also wonder if perhaps it would be possible to extend the idea of the

user_defines.v

verilog configuration to not just set the power up state of the GPIO, but also configure whether a pad is a GPIO or a straight analog connection similar to the analog pins on the Caravan that don’t have all the extra logic loading the pad? In other words, what if we had a setting that per pad, we could remove or add the GPIO? This would give much greater flexibility to mixed signal designs and also remove the need to have a separate “caravan” from “caravel”. I understand then people would have to build their own ESD, but there are now quite a few designs that have successfully built various types of ESD protection that could be used for reference. - I am not sure for how many people this is the case, but on our Caravan, no design used the RISC-V. We all had analog/mixed signal designs. I have a feeling we are in the minority, but we would have preferred to have the extra si space over the RISC-V. Perhaps you could think about an easy way to have a pure analog harness that doesn’t have a RISC-V? Thanks for asking for feedback and reading this!

@Micah Tseng: (1) The issue with having a user select which pad to use is that it is much more complex a problem then choosing the startup state of the GPIO. The startup state is via programmed and affects nothing else in the layout. Changing the pad type changes the entire interface between the chip and the user project. Maybe there would still be just "one wrapper to rule them all" but it would have to include both the analog signal pin and the set of GPIO pins, with only one of the two being active. I'm sure it can be done, but it requires a lot of thought. (2) For the last item, you are implying a Caravan-like version of the openframe design, which is definitely something we're looking into. But if we have a system with selectable analog vs. digital for each pad, then it would work as well for openframe as it would for caravel.

@Tim Edwards Lol, as I was typing it up, I did realize that the last two notes conflict with each other. I think I would personally probably favor the “one wrapper to rule them all” design personally, but it is also certainly the more complex option. I understand what you are saying about the startup state and how removing the GPIO would be more complicated.

@Micah Tseng: I'll be sure to do that!

@Tim Edwards Fairly late to the party, but i know in the lab we have been discussing possibly routing the Wishbone I/O through the GPIO for highspeed connections to the outside word. I'm not exactly sure how many of the 128-pins in the TQFP package would be available for GPIO, but having enough GPIO pins for a Jerry-rigged 16bit Input and output Wishbone bus would be ideal. What we are aiming to turn the Caravel into a co-processor for a larger system, so having a high bandwidth interface would be ideal. Utilizing the wishbone seems like the easiest approach.

@Liam Oswald: That should be doable with the proposed configuration (with 16 bit data buses, as you mentioned, but not 32 bit data buses). I'll write it down as a use case. Very helpful.

Wishbone is an on chip bus protocol. It may work in theory, but whether it is reliable off chip for high speed is a big question. We have the same need to communicate to the user project area via a wishbone interface, but using a high speed serial IO might be more reliable.

Bit late to the party. I'm interested in retro and interested in reimplementation of old(er) chips including 32-bit. The M68030 came in 128/132 pin packages; the '040 in 179/184 ones and the '060 in 206 ones. https://www.cpu-world.com/CPUs/68030/index.html https://www.cpu-world.com/CPUs/68040/index.html https://www.cpu-world.com/CPUs/68060/index.html