Issue Accessing Analog GPIOs on UNIC-CASS Chip (Caravan – Nov 2023 Fabrication) Dear all, We are experiencing difficulties in testing our analog design fabricated through the UNIC-CASS program in November 2023 using the Analog Caravel (Caravan). Our project is fully analog and relies on the GPIO pads in analog mode, but so far we have not been able to establish proper communication with the user area. Here is what we have tried so far: 1. We tested the following firmwares from the Caravel GitHub repository, such as: [chipignite](https://github.com/efabless/caravel_board/tree/main/firmware/chipignite) [mpw2-5](https://github.com/efabless/caravel_board/tree/main/firmware/mpw2-5) 2. Using the chipignite firmware, we were able to control the pull-up and pull-down resistors, using the MGMT variables. We are also able to correctly load and execute the Blink example (/chipignite/blink). However, we had no success when trying to control the USER variables that connect our project. 3. Our design makes exclusive use of the GPIOs in analog mode. We have attempted to configure them with the appropriate firmware settings (e.g.,

GPIO_MODE_USER_STD_ANALOG

) but have not been able to communicate with our project in the USER area yet. We would greatly appreciate any guidance or suggestions on what we might be missing, especially regarding the correct configuration of the GPIOs for analog operation or any known issues with the Caravan firmware. Thank you in advance for your help! Best regards, Fabián Olivera

@Fabián Olivera Operationally, I don’t think there is any difference between

GPIO_MODE_USER_STD_ANALOG

and

GPIO_MODE_MGMT_STD_ANALOG

. Don’t know if that helps. Is your data in a public repo?

@Mitch Bailey: As the firmware directory indicates, MPW2-5 were all in the same bucket (i.e., had timing issues). I'm pretty sure we were beyond that by 11/23 but it's just a matter of figuring out which run it was, which can be decoded from the chip's user project number.

Hi @Tim Edwards, In fact, the first circuit we tested was the ring oscillator, which was designed to operate with an ultra-low supply voltage of around 0.25 V and oscillate in the range of tens of kilohertz, between 10 and 20 kHz. The ring oscillator is connected to reg_mprj_io_9 (VDD) and reg_mprj_io_10 (OUT). Both in the ring oscillator test and in the basic test to verify the approximately 0.3 V expected at the n-MOS current mirror of the LDO, we observed that the outputs in the user area appear to be in a high-impedance state. The n-MOS diode of the LDO mirror, due to its low impedance, should pull the node down to around 0.3 V, but it appears to be clearly in a high-impedance state.

@Fabián Olivera Are you able to share your repo?

Hi @Mitch Bailey, Sure! The simulation files of the circuits developed by my students can be found in the xschem folder of the following repository. There, you can find the ring oscillator (test_ring_100mV.sch) and the LDO (test_ldo.sch) that I mentioned earlier: https://github.com/gme-cefet/pmu-circuits/tree/main/xschem The GDS file closest to the fabricated version can be found in another repository, from a different group, under the MPW5 branch: https://github.com/edsonsilva17/ic2/tree/mpw5/gds Since the efabless repositories were shut down, we were unable to download the final version that was actually fabricated. However, this version is very close to the one that was sent for fabrication, at least for our project block is the final. Among the three integrated projects in that MPW run (visible in the GDS layout), our group’s circuit is the one located at the bottom left.

@Fabián Olivera Here are the mpw5 repos that were taped out. Do you know which one was yours?

@Mitch Bailey: Fabián indicated that his design was on CI2311, but a similar design was taped out earlier on MPW5.

Hi @Tim Edwards, thank you very much for your help. I will try to contact David to get the latest version of the repository related to our chip (C2-109 CI2311 and C2-044 CI2311), which was taped out through the UNIC-CASS program in November 2023. (@David, could you please help us with that?) Some questions and comments have come up based on your observations: 1. Could the analog GPIO connections (no_esd) in the user area be tested without powering the SoC Management, and therefore without loading the firmware? Is there a direct path to the PAD? In that case, we would only need to power the padframe at 1.8 V to activate the protection diodes and avoid gate overvoltage on the 1.8 V devices. 2. Indeed, in most of the tests we performed, we used 3.3 V to power the padframe. But this is required in order to program the SoC firmware, isn’t it? We already have some samples, so it’s important for us to have a clear understanding before the next test.

@Fabián Olivera I'll see if the data is available.

@Fabián Olivera: In principle, you can power the management core without affecting the voltages in the user domains. However, it is possible that coupling could cause the user domain voltage to rise, and if so, there's nothing on the chip to stop it until it hits about 3.7V (although if you used the user VCCD domains, they would be protected against anything higher than roughly 2.2V). You may be able to power and test the parts that are connected to analog pads of Caravan without powering the management SoC. It depends on what coupling might exist between the power domains, which depends on what's in the user project. The harness chip is designed to allow the power supplies to operate independently.

@Tim Edwards: When you refer to the analog pads, does that apply to both the analog pads without ESD protection and the analog GPIOs? Do both of them have a direct connection to the padframe?

The analog connections on the GPIOs, or at least the ones labeled "`gpio_noesd`" (which is not all of them) have a direct connection to the pad. There are different grades of ESD projection. The ones labeled

gpio_analog

have both the diode protection at the pad and a series resistor. The ones labeled

gpio_noesd

still have the diode protection at the pad. The ones labeled

io_analog

have no protection at all (other than that implemented by the designer in the user project) (these names are the ones found in the

user_analog_project_wrapper

module). But. . . Those pad diodes are designed for 3.3V signals, so they're not going to help much for a signal that is connected internally to a device with a ~2.5V breakdown.

@David, do you have any updates regarding the efabless' repository for our design? The codes written on two of our samples are “C2-109 CI2311” and “C2-044 CI2311,” as shown in the attached photo. Just remembering, the tapeout was on November, 2023.

Not yet. I'll ask again.

Hi @David, Do you have any updates? If not, could you please let us know how to request access to the final Efabless repository for our chip tapeouts? The ID codes are C2-044 / CI2311 and C2-109 / CI2311.

Hi @Fabián Olivera Sorry, I do not have an update. I will re-request the data.