https://open-source-silicon.dev logo
Join Slack
Powered by
Hello dear Chipathon colleagues, We received our c...
# ieee-sscs-dc-22
j
Hello dear Chipathon colleagues, We received our chip and started our testing process. Exciting! Together with @italo and @Alfonso Cortés we have managed to get some first general measurements from the evaluation board while we adapt our setup to the M2 breakout board format (in the first plan, when the chips would arrive in march, the breakout board was different). And the chip seems to work! Two states of the DCDC seem fine when tested statically. We are trying to get some dynamic operation now. Unfortunately, we confused some power domains and the evaluation board doesn't work as expected anymore (specifically for the 3.3V LDO). We also have some strange behavior when we try to overwrite that voltage externally. Is there a Slack channel where we can ask about testing issues? or is there someone from Efabless or with enough experience with the latest testboards to whom we can direct the questions? @Boris Murmann @mehdi @Tim Edwards @Harald Pretl @Mitch Bailey @jeffdi
t
Sure, I can answer questions. Bear in mind that today is a holiday in the U.S. (Thanksgiving).
I have not done a lot with this particular version of the board, but I can see that J5 and J9 are in the 3.3V path, and that you have put a header on J5 and jumpered across it. Did you cut the trace between the two header pads before you installed the header?
j
@Tim Edwards yes, we did, and we still get a weird voltage (0. 6v) when we try to force 3.3v with a external power supply We had some wrong supplies and therefore it could also be the case that we broke the sample, we will try with a fresh one now that we fixed some issues
t
If you remove the M.2 board, can you get vddio back to 3.3v with the external supply?
j
We didn't try, we will, thanks!
@Tim Edwards we tried this and we cant go over 2.2V with 200mA when the chip is connected, without the sample we can set 3.3v So i guess we have a broken sample...
t
Can you make a drawing of how you have the power domains connected, and can you remind me where the project repository is so I can check how the project is powered internally?
j
Hello @Tim Edwards, I made a drawing of the connection, please see below. We basically have two identical structures with 4 power transistors (2xNMOS, 2xPMOS), each of them with a level shifter (LS) which uses 1.8V and 5V power domains. For the test, we set all the digital inputs of the LSs to ground, so the VH input is connected to VOUT1 and VOUT2 which are externally open. The 1.8V domain is provided by the regulator in the breakout board, and the 3.3V for VDDIO we try to provide it externally (after cutting the line and placing the pin header) but we manage to get to around 2 volts with ~240mA current. Our delivered project is the following: https://platform.efabless.com/projects/1427
@Tim Edwards, by the way: we measured a fresh unpowered sample and we see that the 4 pads connected to VH are internally shorted (io_analog[2],io_analog[3],io_analog[7] and io_analog[8]) as expected. On the other hand, the sample we are powering and that shows the strange behaviour has io_analog[2] and io_analog[3] open, and only io_analog[7] and io_analog[8] shorted among them, the latter being the expected. So we definitely have something weird in that sample which could be due to overcurrent that we accidentally applied when confusing voltage domains.
t
Oh, you mention 
io_analog
so you are using the 
caravan
chip and connecting the analog pins. What sort of ESD protection did you put on those?
j
We didn't put any ESD protection, mainly because of limited amount of time. We assumed it wouldn't be too critical since they are connected to the sources of the large power PMOS from the top (to the pin called VH in the drawing above), and not connected to any transistor gates. I have to admit we were not too careful until now with the ESD issue with this first sample we were testing, but do you think this could be a big issue? Do you have any advice?
t
If you are connected to diffusion and not gates then you have some protection, but it will not be able to drive as large amounts of current as the ESD diodes can. It sounds like you thought it through, but yes, it's probably easy to destroy something with an over-voltage or over-current condition.
j
Ok, thanks for the feedback @italo @Alfonso Cortés we need to be extra careful when managing the samples following @Tim Edwards comments above
@Tim Edwards @Boris Murmann @mehdi @Harald Pretl @Mitch Bailey @jeffdi, together with @italo and @Alfonso Cortés we have some updates on our chip testing. We managed to measure a fresh sample (S2), and we realized that the caravel evaluation board is not (completely) broken and could at first trial give the 3.3V needed in the VDDIO power domain (but this voltage showed a bit of noise, going down to 3.1V at times, we wonder if the 3.3V LDO is still partially damaged). We managed to test the default DC-DC converter state (with all the level shifter inputs to GND, which connects input to output) in both cores successfully. Then, when we manually changed the digital inputs to logic VDD = 1.8V in one of the cores, to get another state working (with expected output being GND), things started getting weird. We couldn't set these digital input voltages to 1.8V - they only reached around 1.1V. We powered off the setup and tried from scratch, and the 3.3V from the LDO going to VDDIO started to behave strangely and went to 2.8V, which was a behaviour similar to the first sample (S1) that was exposed to overvoltage and a shortcircuit. We were much more careful in the whle manipulaton and test steps now, but somehow we failed to reproduce in S2 the two states we could measure in S1 (confirming that the level shifters work in S1, but not yet in S2). We wonder if there could be ESD issues as you mention above. Is it possible that, due to the fact that we are using some analog pins without ESD (though not connected to any gates) we generate an event on the GPIO pins which damages the VDDIO power domain circuitry? Or could it be possible that the ESD protection of the GPIO is not strong enough and we need to be extra-extra careful with sample manipulation when manually changing those voltages? or maybe not connecting the OEB pins (as in our case, because we didn't understand we should have done this) is creating some functional issues? any help would be highly appreciated!
t
@Mitch Bailey: Was there an OEB check on this project, or did this tapeout precede the OEB checks? What was the result from CVC for this project?
m
I’ve run the checks, but haven’t checked the results. I’ll do that now.
j
I think there was no OEB checks, the last tapeout was the first time we were introduced to this
m
Here are the oeb check results. 2211 was before they were integrated into precheck.
Copy code
gpio |   in   |   out  | analog |  oeb min/sim/max  | Message
   0  |        |        |        |      /     /      |
   1  |        |        |        |      /     /      |
   2  |        |        |        |      /     /      |
   3  |        |        |        |      /     /      |
   4  |        |        |        |      /     /      |
   5  |        |        |        |      /     /      |
   6  |        |        |        |      /     /      |
   7  |        |        |      2 |      /     /      | Warning: oeb expected high for analog
   8  |      2 |        |        |      /     /      | Warning: oeb expected high for input only
   9  |      2 |        |        |      /     /      | Warning: oeb expected high for input only
  10  |      2 |        |        |      /     /      | Warning: oeb expected high for input only
  11  |      2 |        |        |      /     /      | Warning: oeb expected high for input only
  12  |      2 |        |        |      /     /      | Warning: oeb expected high for input only
  13  |        |      2 |        |      /     /      | ERROR: oeb must have possible low for output
  14  |        |      2 |        |      /     /      | ERROR: oeb must have possible low for output
  15  |        |      2 |        |      /     /      | ERROR: oeb must have possible low for output
  16  |        |      2 |        |      /     /      | ERROR: oeb must have possible low for output
  17  |        |      2 |        |      /     /      | ERROR: oeb must have possible low for output
  18  |        |      2 |        |      /     /      | ERROR: oeb must have possible low for output
  19  |        |      2 |        |      /     /      | ERROR: oeb must have possible low for output
  20  |        |      2 |        |      /     /      | ERROR: oeb must have possible low for output
  21  |        |      2 |        |      /     /      | ERROR: oeb must have possible low for output
  22  |        |      2 |        |      /     /      | ERROR: oeb must have possible low for output
  23  |        |      2 |        |      /     /      | ERROR: oeb must have possible low for output
  24  |        |      2 |        |      /     /      | ERROR: oeb must have possible low for output
  25  |      2 |        |        |      /     /      | Warning: oeb expected high for input only
  26  |      2 |        |        |      /     /      | Warning: oeb expected high for input only
Are your 
io_out
signals also connected to the management soc? If not, there may not be a way to output anything because 
io_oeb
is not driven.
j
you mean output anything from the GPIO as digital output? we don't have any of these in our chip... but we didn't connect anything to the management soc, only set as user, if this is what you are asking we are interested in having valid digital inputs throught the GPIOs, because we need to feed the gate drivers for out power switches, and this as set in our user_defines.v @Alfonso Cortés can you share our user_defines.v?
a
user_defines.v
user_defines.v
m
For each 
io_out
, there is an corresponding 
io_oeb
. When 
io_oeb
(output enable bar) is low, 
io_out
-> 
gpio_out
. When 
io_oeb
is high, 
gpio_out
= 
Hi-Z
.
a
@Mitch Bailey the eob report seems inconsistent with our user_defines.v We do not have any GPIO configured as io_output, only io_in and analog
m
The 
user_defines.v
for caravan are offset. 
USER_CONFIG_GPIO_25_INIT
corresponds to 
gpio[14]
. and 
USER_CONFIG_GPIO_37_INIT
to 
gpio[26]
oeb check does not consider 
user_defines.v
, just the 
io_in
, 
io_out
, 
gpio_analog
, and 
io_oeb
connections. However, you are correct in that it does seem inconsistent with the usage specified in 
user_defines.v
. I don’t think you should be able to have 
GPIO_MODE_INVALID
in the file. Is the chip id 
B7
?
j
@Mitch Bailey how can we check the chip ID?
m
Anything printed on the chip?
j
A1 - 021 CI2211
That's the tag printed on the package
i
IMG_20231129_144256.jpg
m
I don’t see anything wrong with the oeb check results for A1. Looks like your using 
GPIO_MODE_USER_STD_INPUT_NOPULL
and 
GPIO_MODE_USER_STD_ANALOG
. Because 
io_out
and 
io_oeb
are unconnected, there might be some leak in the 
gpio_control_block
with 
GPIO_MODE_USER*
. The corresponding 
GPIO_MODE_MGMT*
modes whould work too, but without the leak. I didn’t have any netlists available, so I didn’t run LVS. If you wanted to share the netlists for 
user*project_wrapper
, I’ll run LVS. No CVC errors either.
7 Views
Open in Slack
PreviousNext
Powered by