<!channel>: The first Chipalooza test chip has returned from fabrication, and I will be working on both testing some parts that I have in hand myself, and getting some parts out to the designers who have designs on the chip. I have not tested much so far, but what I have tested looks good (to the extent that I can do testing on my desk, which means all under nominal conditions; characterization will happen later). I looked at the two op-amps (@Thomas Dexter and @Luis Henrique Rodovalho); both of them appear to be operating to spec. I did a simple test on the comparator (@Andrew Kang) which also appears to be working although I don't have any specific performance measurements. I updated the repository https://github.com/RTimothyEdwards/chipalooza_projects_1 for the test chip with a new directory

firmware/

containing the test setups for four of the circuits, and software utilities for configuring them. In the next few days I hope to take a few simple measurements from all of the circuits on the chip. In addition to the ones mentioned above, that means the temperature sensor (@Or Dicker), the crystal oscillators (@htamas and @Brady Etz), the brownout/overvoltage/POR circuits (@Robin Tsang) and the overvoltage detector (@Lucas Daudt Franck and @William Carrara Orlato). I will keep everyone informed about when I can get additional parts packaged and sent out to the designers.

Update?

Update: I have created testbenches for all of the circuits on the first test chip and pushed those to the repository. I have tested the two crystal oscillators to the best of my ability, which is to say using board-level components like crystals in a canister package, on a prototyping board sitting next to the Caravel development board. I was actually sort of surprised that I could get them to run at all. I was able to run the 32kHz oscillator with rather high jitter which was obviously coming from the messy wiring job, and I was able to run the high-speed oscillator at 4MHz with a rather different bias current than I was expecting. I will eventually get a different daughterboard made, with surface mount crystals and load capacitors close to the pins, which should make a better environment for testing. The temperature sensor works as advertised to the extent that I can test it without a controlled temperature environment. The challenge is that it was designed for internal use, not to drive a pin, so the low-drive output voltage gets pulled up or down by the multimeter load, and that needs to be compensated for in the measurements. The results look "in the ballpark" (based on the equation that Or provided in the documentation) but have the additional complication that I don't really know what the junction temperature is, only the ambient temperature. I can cool the chip with a compressed-air canister and the voltages move in the right direction. Getting this chip in a proper testing environment with a temperature force unit will be necessary to do any useful characterization. Anton was supposed to be mailing out parts and boards to the designers, but I haven't checked on the progress recently.

Awesome 👍 thanks for the update!

Von Braun Labs' overvoltage detector (@Lucas Daudt Franck and @William Carrara Orlato) is working as expected. I had to fix an error in my utility routines where I got the enable bit location wrong; that has been updated and pushed to the test chip repository.

That's great! I'm happy to know that 😃 Thank you for updating us.

@Robin Tsang’s brownout circuit works, although I put some of the output signals on GPIO channels that are connected to the FTDI and I need to figure out how to make them high impedance so that I can get a full signal swing output. However, I can still see and measure the signals on the outputs, and can run through the 8 programmable steps on both output channels.

Yay! Thanks Tim 👍

The only issue I see with the brownout is that I cannot get the highest trip point to work at 3.3V power supply, although it works fine at 3.4V. That's sensitive to the value of the bandgap voltage and I can only read the reference voltage value at the pin, so it's not necessarily an issue with the brownout circuit. The trip points are closer to the expected values when using the internal bias, which doesn't surprise me, because the external bias is supplied by an early version of the bias generator that is more sensitive to supply voltage changes, so the bias current is starting to drop at the lower brownout voltages.

Let's try to figure why. That's probably the most important trip point, don't you think? I can't think of any obvious reason off the top of my head, but just so that we are on the same page, the brownout circuit has built in hysteresis around the trip points (from memory it's around 100mV +/-), so it shouldn't trip exactly on each trip point.

Yes, I can see the hysteresis on the scope. At the second-to highest trip point, the brownout signal falling edge is happening very close to the 3.3V value, although I assume that the actual trip happens at a lower voltage value, plus a delay. I'm not really set up for careful characterization at this point. I'm just looking at basic functionality. There are rather too many unknowns in my test setup and I would not assume any error in the circuit yet.

And just to clarify, let's say the trip points is set at 3.0V and the nominal supply is 3.3V, the circuit should trip if the supply dips below 2.9V, assuming the hysteresis is 0.1V (hysteresis is PVT dependent so it's not going to be exact, but ballpark). The circuit should stay tripped as long as the supply is below 3.1V (because the supply has to rise back above the set trip point ie 3.0V plus 0.1V of hysteresis) AND the timer hasn't timed out, both conditions need to be true (trip points and timeout) for the brownout to reset and be ready for the next trip. This is from memory but I believe it's accurate.

I have not looked at the timeout signals on the brownout (or POR), but they are accessible. I did not take them to external pins (I could have run them to a digital pin somewhere, but for the first test chip I didn't want to combine too many digital and analog signals on the same pin; after having the chip in hand and knowing that all the GPIO configuration and analog switches work properly, that would have been safe to do). So I ran the timeouts to the logic analyzer and I have to have the processor sample them periodically. It should be able to sample fast enough to see the timeout within a few microseconds of when it actually happens.

For the POR oscillation behavior, at the moment I can see two ways it can happen, the first is an issue with the POR circuit itself; and the second is when the power supply is trying to bring up the board, at the exact moment when the POR trips (assert reset), there is a glitch ie a surge of current, causing the supply to momentarily dip below the POR's low-side trip point (ie POR trip point minus ~100mV), causing the POR to reset itself and reassert reset when the supply voltage again rises above the POR trip point plus ~100mV. Then repeats. Do you remember roughly what the oscillation frequency is? That info will help. Thank you 🙏 for the update.

Replacing the Digilent with an Agilent 33120A waveform generator made all of the flaky behavior in the POR go away.

Yay 🙌

One-shot mode is very convenient for testing. : )

Internal bias should work down to around 2V across corners, if I remember correctly. Can't tell what's going on with the glitches and the external bias without having it in front of me. Wish I could help more from here.

I'll check on the status of getting chips and boards back to the designers.

Any update on chip deliveries?

In progress. @Anton Maurovic is working on it.