https://open-source-silicon.dev logo
Join Slack
Powered by
Hello all, We continue with our testing process, s...
# ieee-sscs-dc-22
j
Hello all, We continue with our testing process, solving issues but also finding new ones. We are now able to control our DC-DC converter statically as expected, which means that both power transistors and gate drivers are working fine. However, when we try to do dynamic tests, passing from one state to another, we find some unexpected behavior. We have one integrated flying capacitor per core, and we connected the top and bottom plate , each of them to two pins: one analog pin and one GPIO (using the no_esd connection) set in the user_defines.v as "GPIO_ODE_USER_STD_ANALOG". Please see the attached drawing as reference. When we go from a discharging state (D1D2D3D4 = 1001), expecting that the capacitor releases any charge, through a dead-time state (D1D2D3D4 = 1000) to the floating mode (D1D2D3D4 = 0000), we expect the capacitor to have 0V stored. But when we measure, we see a voltage around 1.3V appearing between the top and bottom analog pins, and 0.4V appearing between the top and bottom GPIO pins set as analog ith no_esd connection. The same happens when we go from a charged state (5V stored in the capacitor) to a floating state: the voltage is not stored but goes to 1.3V and 0.4V measured between the analog and GPIO_analog pins, respectively. I was checking this github issue and the diagram confirms that the analog and GPIO_analog pins should be at the same voltage: https://github.com/efabless/caravel_user_project_analog/issues/15 We are quite confused, so any help would be really appreciated @Tim Edwards @jeffdi @Mitch Bailey @Boris Murmann @mehdi @Harald Pretl
m
There’s a schematic of the sky130 gpio cell here. What chip is this? Do you have 2 byte code on the chip?
t
@Jorge Marin: What did you do with the 
io_oeb
and 
io_out
signals for these pins? If you left them floating, then do not use mode 
GPIO_MODE_USER_STD_ANALOG
, which could fail to turn off the digital output buffer, but use 
GPIO_MODE_MGMT_STD_ANALOG
instead.
🙏 3
j
@Tim Edwards we left them open OK, we will set it in the mode you mention, thanks
@Nelson Salvador FYI
@Mitch Bailey our chip's code is A1, thanks
hello @Tim Edwards @Mitch Bailey, we have programmed the GPIO to have the GPIO_MODE_MGMT_STD_ANALOG mode in the pins connected to our integrated capacitors, but we still see strange behavior - basically, when we charge the capacitor and then leave it floating, we don't see the expected voltage due to stored charge. Checking the GPIO diagram available here (https://github.com/efabless/caravel_user_project_analog/issues/15), we believe that maybe the voltage peaks in the capacitor are activacting the ESD diode to VDDIO (I attach again the drawing to this message) and discharging the cap... this would be really bad scenario, we didn't think about this in the berserker designer mode 😕. Nevertheless, when we try to set VDDIO to 5V (to try to avoid the activation of ESD diodes), we can't even test the converter states in DC as we properly do for VDDIO = 3.3V. Do we need to do anything specific to use VDDIO at 5V? Also: is there any way of turning off the ESD diodes? I guess leaving VDDIO floating may be risky, but would this be an option if we manage everything with extra care? Any other ideas on debugging would also be appreciated. cc @Boris Murmann @mehdi @jeffdi @Harald Pretl @Ali Sabir
@Mitch Bailey also measured leakage when the OEB pins where not connected, where does this leakage occur?
t
@Jorge Marin: Where is the layout for this chip?
j
m
@Jorge Marin did you measure leakage related for unconnected oeb pins in 
MGMT
mode or 
USER
mode? For 
USER
mode, the rtl for 
caravel/rtl/gpio_control_block.v
has
Copy code
assign pad_gpio_outenb = (mgmt_ena) ? ((mgmt_gpio_oeb == 1'b1) ?
                        gpio_outenb : 1'b0) : user_gpio_oeb;
This selects 
io_oeb
which if unconnected, might result in leakage. If it’s related to gpio 0-6, the user_project_wrapper io_out[6:0] and io_oeb[6:0] signals are buffered which if unconnected, might also result in leakage whether in 
USER
mode or 
MGMT
mode.
j
@Mitch Bailey we detect the issue (not leakage current measured directly, but indirectly through an on-chip capacitor discharging) in both USR and MGMT modes by the way, is there any spice-level model of the GPIO which we can use to check simulations?
t
@Jorge Marin: I finally got around to taking a look at the layout and understanding which pins are connected to what. Definitely you will leak through ESD diodes on mprj_io[25] and mprj_io[27], since these two have diodes on the pad. That means if you don't want leakage, you will need to run VDDIO at 5V. But now the question is why you are having other issues when running at VDDIO=5. That may be a board-level issue. What circuit board are you using for testing? Are all components of that board rated for operation at 5V?
m
The 
gpio_control_block
is synthesized as a soft macro in 
caravel_core
. The schematic for the underlying gpio block itself is available at https://github.com/d-m-bailey/sky130_fd_io.git I don’t know if that provides you with enough information or not.
j
@Tim Edwards we are using the Efabless evaluation board, in which we cut the connection for VDDIO and connect that voltage externally to 5V
t
@Jorge Marin: That will most likely cause the SPI flash and FTDI to fail, although I don't know offhand which parts are rated for what voltage.
j
@Mitch Bailey if you could indicate which schematic will help to do the simulation of the connection of e.g. mprj_io[25], that would help a lot
t
@Jorge Marin: Assuming that the SPI flash and FTDI are 5V tolerant (won't die at 5V), and you need the SPI flash to configure the I/O, but you don't need a running program to test your part, you should be able to power up at 3.3V and then raise it to 5V after the I/O are properly configured.
m
@Jorge Marin 
top_gpiov2
is the base gpio. But again, that does not include the 
gpio_control_block
which interfaces with the 
user_project_wrapper
.
👍 1
j
@Tim Edwards we did the following test: we isolated the VDDIO pin and provided voltages slightly above 3.3V there, verifying that the SPI and FTDI chips are still supplied by 3.3V and therefore that we can change only VDDIO. After this, we tried different states of the DCDC converter statically, and works as expected. When we go to VDDIO > ~3.8V, the converter states check gives werid results, and it doesn't react to the digital inputs. It seems like the GPIOs stop working. I guess this is not the expected behaviour, do you have any idea what could be wrong? or which other debug tests can we try?
t
@Jorge Marin: If the chips like the FTDI and SPI flash are still powered at 3.3V, then when you set VDDIO to 5V, you are going to start dumping current into the ESD circuits of those chips, which is going to drive down your supply and probably make it unstable as well.
j
@Tim Edwards sorry, I'm not getting it, which ESD gets active and why?
t
@Jorge Marin: All right, I went back and stared hard at the PCB schematic for the Caravel board so I could make sure I'm not saying things that aren't true. From the board schematic, here are the problems that I think could potentially occur when you raise 
VDDIO
to 5V: (1) The FTDI chip continues to be powered to 3.3V, not 
VDDIO
. Any of pins GPIO 1 to 4, if they attempt to output a "high" signal at 5V, will dump current directly into the FTDI. Check that the lines are grounded, mainly GPIO 1 (SDO), which is an output from Caravel. I don't think this would be an issue. (2) 
VDDA
continues to be connected to 3.3V as well. Nothing on the board other than some analog circuits inside the GPIO run on the 
VDDA
domain, and they're all well isolated. It shouldn't be a problem. (3) The oscillator chip and the SPI flash both run on 
VDDIO
, and I don't think either of them is rated for 5V. I'm not sure how you verified that the SPI flash is being supplied by 3.3V, because the PCB schematic doesn't show it that way. Your observation of problems occurring at around 3.8V is consistent with the 
VDDIO
supply dumping directly into the 3.3V supply somewhere, though, since that's about a diode drop above 3.3V. Right now I can't see a clear mechanism, unless something is going on with 
VDDA
that I'm not aware of.
i
@Tim Edwards According to this image (or my understanding of it) if the conection between pin 1 and 2 of J5 connector is cut (which is this case ) then none of the chips (other than the caravan) have a connection to Vddio. Can you please confirm this? If this is the case then vddio on chip an the other power domains are isolated, so we dont see (3) possibility happening.
t
@italo: Thanks for that screenshot. But, whoa. . . The connections in the screenshot do not match the schematic and it's clear that shorting across the jumpers has undermined running LVS on this. I think the error is in the FTDI chip connections. The 3.3V network is connecting to the lower corner of the FTDI chip, and the 
vddio
network is connecting to the top and right sides. I think all of those pins are shorted internally to the FTDI, meaning that cutting the trace under the header is not separating the domains. You would need to correct it by cutting the trace to the FTDI on the lower left (relative to the screenshot; the FTDI is oriented upside down) and reconnecting it manually to 
vddio
. (attn:@Andrew Wright / @jeffdi / @Passant / @mshalan). I need to review the FTDI pins before I'm sure of that answer, though.
@italo: This is my interpretation of it: (corrected; see repost below.)
j
@Tim Edwards thanks for the feedback, we will confirm this tomorrow when coming back to the lab
t
@Jorge Marin, @italo: Looking more carefully at the board schematic (which is difficult, because none of the schematics are marked with the board revision number and I haven't found one matching rev. 5V yet), I think I have misidentified the 3.3V LDO, which I now think is U5, and the proper solution is just to cut the trace across J9 rather than the one across J5. (edited---"one possible solution" is to cut the J9 trace instead of J5 and attempt to drive all circuitry on the board to the same voltage, although you might want to still stay a bit below 5V so as not to stress the parts too much.)
After reviewing this with @Passant, apparently there is some hard connection across the FTDI that is not showing up very well on the highlighted net, but the 
vddio
wire ends at the M.2 connector and is not directly connected to the rest of the network to the right of it. So the board is not mis-labeled. That means that you were correct that cutting J5 will isolate just the Caravel chip's 
vddio
from the rest of the regulated 3.3V network. So I just ended up back where you started, which is that I don't know where 
vddio
could be dumping current into any 3.3V domain. The only think I can think of is what I wrote originally as (2), which is that maybe 
vdda
is somehow connected to 
vddio
. It's a long-shot idea, but maybe cut 
vdda
from the 3.3V net and connect it to 
vddio
instead?
Final re-post of the annotated board layout. Next time I'm going to do the thorough review before I start making recommendations. . .
j
Hello @Tim Edwards, we don't use the VDDA domain... i'm not sure how this could help, do you have an explanation on how could VDDA be connected to VDDIO? any other ideas? or do you know anyone who could give feedback on these testing issues?
or, maybe, do you know anyone who has tried the VDDIO = 5V and have a working chip? has this been tested before? the big mistery in our current status is why does VDDIO = 5V disables the GPIO operation...
Just to recap for a better understanding, we have the following scenarios: • We tried to run through the different states of the DCDC converter with VDDIO = 3.3V and the input voltage VH = 3.3V. We manage to get the charging and discharging states (as seen in the figure), but when we try to get to the floating capacitor and then measure the voltage drop across its terminals, we get zero. We have two hypothesis there: 1) the ESD protection diode between the pad and VDDIO in the GPIO pins in the floating cap terminals, set as MGMT ANALOG pads, is discharging the capacitor with the minimum voltage spike, and 2) any attempt to measure the integrated capacitor, which has a small value (even if huge in the layout), 8nF, results in discharging it with the instruments we are using (a multimeter and a, oscilloscope with active probes). • Assuming ESD protection leakage could be an issue, we tried to run through the different states of the DCDC converter with VDDIO = 5V and the input voltage VH = 3.3V (to have some margin for these hypothetical voltage spikes that turn on the ESD diode). In this case, the GPIO pins stop working and therefore we can't change the state of the converter Any feedback on the hypothesis, methods and resuts from more experienced colleagues would be highly appreciated (or the contact of anyone who could help us debugging this)! @Tim Edwards @jeffdi @Mitch Bailey @Stefan Schippers @Amro Tork @Harald Pretl @Boris Murmann @mehdi
t
@Jorge Marin: I just ran the experiment myself of cutting the J5 trace and applying an independent supply to the 
vddio
domain. I was able to get 
vddio
up to 5V and the processor kept running and the 3.3V output of the regulator remained constant. The 
vddio
line was stable at 5V. I was running the blink test and the LED kept blinking, so the GPIO pad was still operating normally, as was the internal digital at 1.8V.
j
@Tim Edwards thanks for checking this, we will run the same test with @italo at our side to verify
t
Also, I cannot find a leakage current or power in the I/O documentation, but the liberty file says 8.8nW, which at 3.3V should be 2.7nA, or approximately equivalent to a gigaohm resistance.
i
@Tim Edwards Thanks for all the feedback and support ,we ran some tests on the chip and here are our results: 1. We upload the blink program with vddio = 5V and it worked. Then we tried to make the DC-DC converter work (with a code that suits our needs) and the converter would not work, more specifically the level shifters seem to not work (they used to at vddio 3.3V). 2. With the 1. Result, we opted for testing an external and bigger capacitor (around 250 times bigger) than the one on chip, setting vddio at 3.3V and the supply of the converter and the level shifters to around 3V too. This resulted in the capacitor holding charge after the charge state and dropping the voltage just when we measure it (we took a measurement wait close to a minute and come back to measure the same voltage value). This made us belive that indeed the masurement was discharging the tiny capacitor on chip. So in recap we believe the DC converter may work at 3.3V but not at vddio 5V and we still cant understand why. Any idea of what can be causing it or another test to identify some problem would be of great help.
t
@italo: No, I don't know. The level shifter looks like a typical level shifter to me.
i
Hi @Tim Edwards we continue the testing of the chip. We were wondering about how and when the program is flashed to the chip, we have noticed that everytime we start up the evaluation board the previously flashed program is the one running so, Is the chip flashed every time at startup or once is flashed with a program it remains that way even after being powered off?
t
The SPI flash chip is only flashed when you do "make flash". Like any flash memory, it will retain its state when power is removed.
i
So if we flash our program, power off and then test the chip outside the evaluation board without a flash memory it will have no program loaded (factory state)?
t
There is no flash memory inside the Caravel chip, therefore no concept of a "factory state".
i
Thanks a lot. @Jorge Marin i think this info will be helpfull for the testing setup
j
@Tim Edwards, sorry for the redundancy, just to be 101% sure about this: if we provided a wrong user_defines.v at the tapeout moment, then if we want an sandalone setup (outside of the evaluation board) to make the chip work, we will always need the SPI flash chip to be incuded in that setup to make sure the GPIOs are set correctly, right?
t
Yes, that's right.
i
@Tim Edwards, After some tests we have some doubts about the vdda1 supply,is it normal for vdda1 to be shorted to gnd? We found this behaviour in the current chip we are testing. It seems to work fine in other aspects like flashing a program into it. We havent try to power vdda1 just as a safety measure. Any ideas of what could have happend? or is this normal behaviour?
p
vdda1 is not connected to any onboard supply. if utilized, it should be supplied from its pin on the right pin header. So, I guess it’s normal to measure it as 0v if not powered
i
I see, but Is not like the measure value is 0V, there is continuity, so I'm not sure if this should work like that, for vdda2 for example continuity is not found.
m
I noticed some possible issues looking at the OEB and the gpio defaults report. OEB report (gpio numbering corresponds to verilog bus indices. 15 corresponds to 26 in the layout).
Copy code
gpio |   in   |   out  | analog |  oeb min/sim/max  | Message
   0  |        |        |        |      /     /      |
   1  |        |        |        |      /     /      |
   2  |        |        |        |      /     /      |
   3  |        |        |        |      /     /      |
   4  |        |        |        |      /     /      |
   5  |        |        |        |      /     /      |
   6  |        |        |        |      /     /      |
   7  |      4 |        |        |      /     /      | Warning: oeb expected high for input only
   8  |      4 |        |        |      /     /      | Warning: oeb expected high for input only
   9  |      4 |        |        |      /     /      | Warning: oeb expected high for input only
  10  |      4 |        |        |      /     /      | Warning: oeb expected high for input only
  11  |        |        |        |      /     /      |
  12  |        |        |   4628 |      /     /      | Warning: oeb expected high for analog
  13  |        |        |   8468 |      /     /      | Warning: oeb expected high for analog
  14  |        |        |   8468 |      /     /      | Warning: oeb expected high for analog
  15  |        |        |        |      /     /      |
  16  |        |        |   4628 |      /     /      | Warning: oeb expected high for analog
  17  |      4 |        |        |      /     /      | Warning: oeb expected high for input only
  18  |      4 |        |        |      /     /      | Warning: oeb expected high for input only
  19  |      4 |        |        |      /     /      | Warning: oeb expected high for input only
  20  |      4 |        |        |      /     /      | Warning: oeb expected high for input only
  21  |        |        |        |      /     /      |
  22  |        |        |        |      /     /      |
  23  |        |        |        |      /     /      |
  24  |        |        |        |      /     /      |
  25  |        |        |        |      /     /      |
  26  |        |        |        |      /     /      |
gpio defaults report (gpio numbering corresponds to layout where 15-25 are missing)
Copy code
USER_CONFIG_GPIO_5_INIT    13'h0000     
USER_CONFIG_GPIO_6_INIT    13'h0000     
USER_CONFIG_GPIO_7_INIT    13'h0402
USER_CONFIG_GPIO_8_INIT    13'h0402
USER_CONFIG_GPIO_9_INIT    13'h0402
USER_CONFIG_GPIO_10_INIT   13'h0402
USER_CONFIG_GPIO_11_INIT   13'h000a
USER_CONFIG_GPIO_12_INIT   13'h000a
USER_CONFIG_GPIO_13_INIT   13'h000a
USER_CONFIG_GPIO_14_INIT   13'h0000
USER_CONFIG_GPIO_26_INIT   13'h000a
USER_CONFIG_GPIO_27_INIT   13'h000a
USER_CONFIG_GPIO_28_INIT   13'h0402
USER_CONFIG_GPIO_29_INIT   13'h0402
USER_CONFIG_GPIO_30_INIT   13'h0402
USER_CONFIG_GPIO_31_INIT   13'h0402
USER_CONFIG_GPIO_32_INIT   13'h000a
USER_CONFIG_GPIO_33_INIT   13'h000a
USER_CONFIG_GPIO_34_INIT   13'h000a
USER_CONFIG_GPIO_35_INIT   13'h000a
USER_CONFIG_GPIO_36_INIT   13'h0000
USER_CONFIG_GPIO_37_INIT   13'h0000
First, 
13'h0000
is probably not what you want. This has both input and output enabled (actually, `DM`’s are all 0 so output and input [edit] is effectively disabled). See attachment. 
13'h000a
and 
13'h0402
are user mode settings which may result in leaks because 
io_out
and 
io_oeb
are not connected. You can safely use the mgmt mode counter-parts for user analog and user input modes without worrying about the 
io_out
and 
io_oeb
connections. 
13'h000b
for analog and unused gpio and 
13'h0403
for input. Also gpio 14 has connections at the analog pin, but is configured as 
13'h0000
.
t
@italo: The answer to the immediate issue is that 
vdda1
should not be shorted to ground. By "continuity", you mean that you are seeing < 1 ohm between 
vdda1
and ground?
@italo: The only way I can see for 
vdda1
to short to ground would be if the level shifter failed for some reason; say, that 
vccd1
was not connected; then the inverter after the level shifter could be turned completely off, the value at its output could be mid-range, causing the large inverter to crowbar. The only other mechanisms would be latchup (but I don't see any part of the design that would tend to cause latchup) or clamping (unlikely unless you have wild spikes on your 
vdda1
supply).
i
@Tim Edwards: we made the following test: 1. We tested the contnuity with the ev.Board OFF and it shows 2.4 ohms. 2. We tested the contnuity with the ev.Board ON and it shows 9.9 ohms. We werent paying attention to the resistance value shown in the tester(FLUKE 87V), but it appears to increment once the board is ON.
t
@italo: How is your 
vccd1
connected?
i
@Tim Edwards: you mean from the ev Board to the outside world or internally in the chip? If its internally in the chip i would have to check it up, any other way we havent connected anything to that powerline externally. CC @Jorge Marin
t
@italo: The 
vccd1
is providing the 1.8V power supply to the level shifters. Without that power supply, your level shifters will fail and you will get exactly what you observe---A crowbar current on all the level shifter outputs which will effectively short 
vdda1
to the tune of something in the range of tens of ohms, for which your 10 ohm measurement sounds about right.
(@italo: FYI, if you call out somebody by name in an edited message, they don't get notified; You would have to name @Jorge Marin in a new message, like I just did.)
p
without cutting the trace on J3, vccd1 should be connected to the on-board 1.8v LDO
i
@Tim Edwards @Passant: Vccd1 is connected to the 1.8 LDO on board and when powered reads the 1.8V, also when the board is powered vdda1 reads 0.008V, to keep the idea clear, is this a normal behavior when vdda1 is not powered by an external source (the 10 ohms resistance between vdda1 and gnd when the board is ON) knowing that vccd1 is being supplied?
t
@italo: Yes, if you don't power 
vdda1
then it will remain at ground unless something inside your circuit is charging it through a conductive path. Outside of the user project, all of the 
vdda*
domains are isolated from all other supplies.
👍 1
n
Hi @Tim Edwards thanks for your support, i'm working in this project too, and we see that vdda2 doesn't have the same behavior as vdda1 (i.e. when the board is powered and we reads the voltage, it decreases from some mV to 0V, like a discharge, but there isn't continuity in any moment to gnd), just to be sure, is this also normal behavior?
t
I assume so. Both 
vdda1
and 
vdda2
would act like that if not connected to anything in the user project---they would jump up to some low voltage due to capacitive coupling, and eventually drift to zero from leakage through the clamp circuitry.
j
Hello @Tim Edwards, just to give a bit of context: we are testing our 4th sample after destroying 3 due to incorrect manipulation of the evaluation board - we were expecting the former breakout board and we are waiting now for an interface board to use the setup we designed. In the meantime, we discovered some issues, such as wrong user_defines.v settings, so we may need to redo our setup. @italo and @Nelson Salvador will be working on this in the next weeks. We are afraid the low impedance between Vdda1 and gnd could be the reason of desctruction of our latest sample, and therefore all these questions being asked. What is quite strange is the difference in measurements between Vdda1 and vdda2, given the fact they have an identical connection on chip.
m
@Jorge Marin do you have a schematic for 
user_analog_project_wrapper
?
j
@Mitch Bailey do you mean a drawing, or a schematic file for simulation?
m
@Jorge Marin Ideally an xschem 
sch
file.
j
@Mitch Bailey we have the top of our block, but not the user_analog_project_wrapper we had a lot of updates at top level and couldn't keep up with the changes i'll try to find our latest wrapper schematic (probably slightly different to the one we delivered in the end) among the tons of versions we have...
👍 1
n
Hello everyone, we have continued with the tests varying different parameters, such as the load, the switching frequency, and the duty cycles of the PWM that are used for our 3-level floating capacitor converter. From these tests within “safe functional” values (200khz PWM and 117ns dead time) the following system efficiency values have been obtained (image 1). Various values still need to be improved, and after these measurements, frequencies of 600khz have been achieved. However, all this has been achieved using Vddio= Vdda2= VH= 3.3V (Vdda2 is the power supply for the level shifters used in the gate driver of the transistors and VH is the power supply for the converter). One of the objectives being that this can work up to 5V. When trying to use Vddio= 3.3V with an external voltage source (cutting off J5) and the !RST signal connected to GND (to not program anything, although with or without the program the system behaves the same according to what has been observed in the results. By the way, the program that the board has loaded is to correctly configure some pins.) the system works fine, as expected. In this way, using a duty cycle of 75% for example, the following image taken from the oscilloscope is obtained (image 2). However, when we use Vddio= 5V and Vdda=VH= 3.3V or 5V, what we get is image 3, which is the value of VH with very fast switching perceived as noise and not a PWM. Image 4 is the value of VH when it should not switch (and you can see the clearest and most stable signal). We still don't understand why this doesn't work correctly at 5V. Does anyone have any idea what could be happening? cc @italo @Jorge Marin
j
@Tim Edwards @Mitch Bailey @mehdi @jeffdi @Amro Tork @Boris Murmann @Harald Pretl @Stefan Schippers sorry for the collective ping, our students @Nelson Salvador and @italo have done a great work making our dc-dc chip work for low load current and 3.3v to 1.8v conversion, with efficiency over 80%. We still have a long way ahead to identify the sources of loss, but the results are encouraging. However, we still have the following issue: when we set VDDIO (the esd circuit reference) to 5v so we can do 5v to lower voltage conversion , the chip stops working as expected. More precisely, the integrated gate drivers stop reacting to input switching pulses. We are out of ideas and we would really like to test this case. Could anyone help us, or know anyone who has this type of expertise ? We can prepare a detailed presentation with our design and the issue.
t
@Jorge Marin: I recall something about different observed behavior on the side with 
vdda1
vs. the side with 
vdda2
?
My first suggestion would be to start at 
vddio = 3.3V
and slowly ramp it up and figure out at what value of 
vddio
the failure occurs. Most of the circuit pins are analog pins and have no path to any of the power supplies. I think it most likely that issues must occur on the GPIO pins. The GPIO pins are, of course, supposed to operate up to 5.5V without any issue. But there are many connections into each GPIO pad, and just because I can't think of any mechanism by which a 5V VDDIO would cause a GPIO pad to behave differently doesn't mean that there isn't such a mechanism. If there is one, though, it should be observable on any board with any chip.
n
Hi @Tim Edwards, regarding the difference between VDDA1 and VDDA2, the issue we observed in previous samples (sample 1 to sample 4, following our tags) is that at least one of these supply pins showed connectivity to GND when measured with the voltmeter. This behaviour was not observed in the current sample (sample 5). This is definitely a strange behavior, since we see different measurements among “identical” chips.
@Tim Edwards Regarding the issue with VDDIO, we did the following test over a single core of our buck DC-DC converter: ◦ the system is operating at 200kHz, with VH = 3.3V (input high voltage) and 55% modulation index (to obtain VOUT = 1.8V) - i.e., we are operating the DC-DC converter with digital pulses for this conversion ratio ◦ Initially, the VDDIO voltage is set to 3.3V - we have done load sweeps with this setup, and we get reasonable efficiency plots (with peak efficiency up to 85%), so we presume it is in general working fine. ◦ When we try to increase VDDIO towards 5V in steps of 100mV, we see the behavior in the attached plot. ▪︎ 1) At 3.3V VDDIO the current at VDDIO pin is 1.3mA. The output voltage is 1.8V (correct voltage for 55% of duty cycle) with 1.8mA load current for 1kohm load. Is this VDDIO current reasonable? ▪︎ 2) When we increase VDDIO to 3.4V we see that the current in VDDIO increase to 1.7mA and the output voltage decrease to 1.75V. From our point of view this is unexpected, since the VDDIO shouldn't affect vout. This behavior is the same until 3.5V in VDDIO. ▪︎ 3) From 3.6V in VDDIO the current increase to much from 2.9mA, and the output voltage start to increase too (this is explained because the modulation doesn't work fine anymore) ▪︎ 4) At 4V in VDDIO the modulation signals complete stop reaching the power stage, and the output get stuck at 3.3V (VH). Please let us know if you have any comments of this. We could send additional measurement of this if need it. Also, any advice on other debugs measurement ideas are welcome. PD: In the plot, blue line is VDDIO's current (top) and voltage (bottom) and yellow line is our output signal. Also please note come from Joulescope which probably average the signals (only in case this switching very fast).
t
@Nelson Salvador: There is a somewhat low yield that is, I believe, due to an issue with fill shapes being created under the pads (found and fixed recently) that makes the pads prone to shorting. I do not have enough reports back to get a feel for the yield loss, but it could be as much as 10% or more. The ball bonds used by the packager for the QFNs is pretty reliable, but I have seen dead chips from time to time.
j
@Tim Edwards from sample 1 to sample 3, the issue may have been triggered by issues in our manipulation (such as mixing voltage domains), but samples 4 and 5 were managed with more care after understanding the evaluation boards a bit more in detail.
t
@Nelson Salvador: Interesting measurement. It doesn't look like a forward-biasing diode; it looks like a fairly proportional rise in current draw vs. voltage. It definitely interferes with the DC-DC converter output, though.
j
@Tim Edwards do you have any advice on how to debug this? We were counting on measuring for input voltage VH = 5V, which would be a nice claim for our purposes of publishing this work.
also, this is completely unexpected since increasing the VDDIO voltage should intuitively make things more robust, no? and mostly, as said above, it shouldn't interfere in VOUT i.e. the operation of the system
@Tim Edwards another note: the flying capacitors in our topology is also connected to GPIOs, set as analog. I believe this was a bad decision, but we can't do much now. This means that there may be some leakage through the ESD diodes from there. Therefore, we could expect some ESD current peaks that in average show the current we observe in VDDIO (we do observe large voltage peaks, but with short width, in the flying capacitor terminals, which even exceed 6V). However, and repeating what I wrote before, having higher VDDIO should REDUCE these ESD current peaks, and not the opposite as observed from measurements. This is completely counterintuitive - your help (and other colleagues at Efabless or elsewhere) would be really appreciated in making sense of this.
t
@Jorge Marin: The last set of scope traces doesn't differentiate between VH and VDDIO---It might be a good idea to capture how the circuit behaves when each of these is changed independently. You do need to keep VDDIO close to or above VH due to the connection of the flying cap on the GPIO pins. Otherwise, there would be no need to change VDDIO at all. But if you always change VH along with VDDIO, then there should be no change in the ESD current. If you raise VDDIO to 5V but keep VH held at 3.3V, does the circuit continue to operate normally?
n
@Tim Edwards We already tested those case (using Vddio= 5V with VH= 3.3V and 5V) but none of these cases does the circuit work well.
👍 1
j
@Tim Edwards maybe we explained wrongly: VDDIO is changed but VH is fixed at 3.3V in the experiment above
@Tim Edwards the plan is to increase the VDDIO first and then see how much we can increase VH, but until now we can't even make it work with VDDIO = 5V and VH = 3.3V
t
That narrows down the possibilities. Unfortunately, it narrows them down to zero. . . I cannot see a mechanism by which changing VDDIO should have any effect on the output at all, as long as VDDIO is the highest voltage in the system.
j
@Tim Edwards indeed, it's too weird, that's why we are asking for expert advice here. Any chance anyone at Efabless can take a closer look at this?
t
@Jorge Marin: What C code are you running on the processor?
j
@Nelson Salvador can you attach the code version we use?
n
@Tim Edwards We modified the original blink.c (blink.c modified is attach) to test other pin configuration, but with or without the program (!RST connected to GND) the converter seems to works the same. All latest tests were done with !RST connected to GND.
t
Everything there looks entirely normal and correct. I am running out of ideas, because the VDDIO should not be affecting the operation of anything.
j
@Tim Edwards you didn't have any projects with these kind of issues until now?
t
I'm not sure that I've tested anything on sky130 at 5V before. Most of the stuff on the standard development board doesn't run at 5V.
j
@Tim Edwards I see.. Could it be some issue generated by the GPIO design? I really cant see anything extremely weird in our design, except perhaphs the super large caps we integrated on chip.
t
I don't think so. But just coming up with off-the-cuff ideas. . . I don't think that VDDIO would forward-bias into VDDA, but for the record, what is VDDA set to (all three of them, I guess)?
m
@Jorge Marin If your unused gpio inputs are Hi-Z and you have the corresponding gpio configuration in input mode (
DM[2:0]
not 
000
and 
INPUT_DISABLE
low), then you might see increased leakage from 
VDDIO
as you ramped the voltage. You could try tying all the unused gpio pads to 
VSS
if they aren’t already. I’ll try to run CVC-RV with 
VDDIO=5V
and 
VDDA*=3.3V
and see what’s flagged.
@Tim Edwards what about the resetb pad? I haven’t created a schematic from the netlist yet, but CVC seems to be showing a vddio voltage divider connected to vccd pmos. If the intermediate voltage exceeds vccd, then there parasitic diode on the pfet could be forward biased.
This may also be a problem with the gpio when vddio > vdda.
t
@Mitch Bailey: I have a hard time following what's going on inside the amux switch (I mean generally, not just your schematic. I've been puzzling over it for ages). But if that's true, then it should be easy enough to connect all 
VDDA
to 5V as well. I don't think the reset pad should be an issue. The only thing in the vccd domain in that pad is the 
enable_vddio
signal, which should be going to some kind of level shifter. Would CVC flag a level shifter?
m
CVC does flag level shifters, but the potential problem I’m seeing is that an intermediate voltage is connected to a thin-ox pmos drain that has vccd source/bulk. Do you have any diagrams of the reset pad?
t
Diagrams?! If only. No, I have to stare at the SPICE netlists.
🙁 1
m
I’ll put it on my list of things to do.
t
There's the block diagram in the I/O documentation, but it only shows a pull-up pMOS that's in the vddio domain, and the enable_vddio signal goes to a triangle (buffer, I assume) labeled "LV", which isn't enough detail. The circuit in question is 
sky130_fd_io__xres4v2_in_buf
and is the "LV" block in the block diagram, but the whole I/O pad is rated for 5.5V operation, so I'm pretty sure it's all correct.
@Mitch Bailey: FYI, the I/O documentation has a table of which power supplies are valid in which states. For the condition VDDIO = 1, there is a valid state VDDA = 0 and VSWITCH = 0. However, the caravel padframe has VSWITCH hard-tied to VDDIO. I think that might be a mistake (possibly @Andy W could verify that?) and we should have tied VSWITCH off to VDDA instead. That may be the source of the coupling between VDDA and VDDIO when VDDIO > VDDA, per your schematic. Note that the table in question doesn't address the issue of power supplies being different, just power supplies being variously "on" or "off". But I would assume that if there is a forward biasing current path, then it would apply equally to (VDDIO = 5V, VDDA = 3.3V) as it would to (VDDIO = 3.3V, VDDA = 0V). I have not stared at the circuit/schematic/netlist/documentation long enough to say that with any certainty. Just a hunch.
@Jorge Marin @Nelson Salvador: Anyone have a chance to test with VDDA = VDDA1 = VDDA2 = VDDIO = 5V?
n
@Tim Edwards We work with Ev. Board REV 5A and we have external access only to VDDA1 and VDDA2. Is enough set those pins at 5V?
j
@Tim Edwards we are not really sure where is VDDA connected, how can we check this? We don't have such pin in the ev. board
t
@Jorge Marin: The Efabless evaluation board has connections for VDDA, VDDA1, and VDDA2; they go to the chip pins of the same name. On the QFN package, that's pin 30 for VDDA, 40 and 47 for VDDA1, and 9 for VDDA2 (20 for VSSA, 38 and 52 for VSSA1, and 1 for VSSA2).
n
@Tim Edwards This is our evaluation board. Looking the PCB in KiCad, I understand that VDDA are the 3.3V pins (under GND, top right), Is this correct? Using an old image to support me, our actual evaluation board doesn't have connection between J5 pins, this is for set 5V on pin VDDIO (top pin in J5). So, when we increase VDDIO over 3.3V (with external supply in top pin J5), we need connect the USB (J1) because without that the converter doesn't work, and this activate the 3.3V and 1.8V domains in evaluation board.
j
@Tim Edwards unfortunately to isolate VDDA and set it to 5V using the evaluation board (as shared by @Nelson Salvador above), we need to modify the board (e.g. unsolder the 3.3V regulator) or to modify our own setup, which may take some time. If you have any ideas on how to do this more efficiently, they are more than welcome.
t
@Jorge Marin: You might first try just VDDA1 and VDDA2, which are already pinned out and independent; if that doesn't make any change to the chip behavior, then we can look into what's needed to isolate VDDA.
👌 2
j
@Tim Edwards thanks for the advice @Nelson Salvador tried just VDDA1/2, but without good results, i.e. the chip stops working properly He's trying another setup with independent VDDA now, we will report this as soon as he has some conclusions
n
@Tim Edwards Thanks for your support. Yesterday I tried to increase VDDIO from 3.3V (with VDDA1 and VDDA2 at 3.3V) but in this case, the converter failed with the minimum increment at VDDIO (at 3.4V, we can see this in attached plot. blue line is VDDIO's current (top) and voltage (bottom) and yellow line is our output signal). Then, I tried to start the test with VDDIO at 5V (with VDDA1 and VDDA2 at 5V too) but in this case the converter started with the output signal wrong. The PWM is designed to start the converter at 0V, and then with a switch tells it to give the voltage based on a duty cycle, but with all at 5V, the output signal start at 5V. After all of this, I tried to replicate the first situation showed some days ago, where VDDIO increase at 4V and then the converted failed, but I couldn't, the result was the same (converted failed with VDDIO at 3.4V). Now, I use another setup, like @Jorge Marin said, with independent VDDA. Therefore, we are now able to set VDDA = VDDA1 = VDDA2 = VDDIO = 5V. The results were pretty similar to showed 7 days ago, with VDDIO increase from 3.3V at 4V, and with all at 5V nothing works.
j
Hello @Tim Edwards, @Nelson Salvador has completed several tests to evaluate the issues reported above. The main conclusion until now is that setting VDDA = VDDA1 = VDDA2 = VDDIO = 5V still generates issues, stopping the operation of our DCDC converter - it seems, as before, like the integrated gate drivers stop working and therefore the switching signals are not reaching the power stransistors, but we don't understand why. We also have other observations we would like to share: when the input of the DCDC converter VH is gradually increased to VH = 5V leaving VDDIO = 3.3V, the system keeps working, but the efficiency is highly decreased (by around 15%). This is a somehow expect this, since the voltage in the GPIO pins of the flying capacitors increase and therefore it's more probable that we activate the ESD diode, loosing some power there. The weird part of this is that we don't see any relevant ESD currents on VDDIO when we do this test, so we don't understand where else could the power be going. Another really strange behavior is that the voltage in the flying capacitor GPIO and in its analog pin (both are shorted internally, our (bad) idea was to have redundancy for measurements) show voltages that can differ in up to 0.6V (the GPIO voltage seems to clamp close to 1.8V). The main blocking stone for us right now is that we cannot increase the VDDIO voltage without our chip stopping working, and we don't understand why. If we could set VDDIO = 5V we would be able to have a better range for ESD and therefore probably be able to avoid unwanted power losses. Your further help or ideas would be really helpful.
@Tim Edwards actually the only way we see right now to measure without the influence of ESD losses would be to open de VDDIO connection while operating the DCDC. Do you think it could be a possible idea to try this, or it's just a way of destroying our sample immediately (sorry if the question is too naive)?
t
@Jorge Marin: I don't think there will be a risk of destroying the chip. Your main risk is going to be latch-up, which would disable the chip until you power cycle.
14 Views
Open in Slack
PreviousNext
Powered by