https://open-source-silicon.dev logo
Join Slack
Powered by
Has anyone seen some sign of life from their user ...
# mpw-6plus-silicon
c
Has anyone seen some sign of life from their user project on MPW7? I'm a bit puzzled. I have received both parts from MPW6 and MPW7. Some of the circuits are identical between the two and I had already good success bringing up MPW6. MPW7 meanwhile seems to be completely dead.
I also noted the die looks almost twice as thick for MPW6 when compared to MPW7. Were there any notable fabrication differences between the two that I was not aware of?
m
AFAIK the thicker dies were needed for the WLCSP package
now that the package are QFN, they can be thinner
I'm also having problems with MPW7. I have an identical project in MPW6 and MPW7 and it works in MPW6 and not in MPW7
Can you give more details on the simplest project you've seen working on MPW6 but not on MPW7?
All my projects depend on the logic analyser working to enable them. I think maybe there's an issue with the LA and the WB
c
Yes same here. I need the LA to control the user area.
I also see very little current drawn from the supply, but I need to verify this again.
m
interesting, let me check
c
Ok so i just checked. So for the most basic test where I simply power up the design vdda1 I draw a current of ~12uA on MPW6 on MPW7 its close to 0. The circuit that is powered up is completely independent of any inputs and does only require a supply voltage.
m
can you share a link to that design?
For my design, the working one on MPW6 needs 6mA and the non working one is 5.74mA, so I think the difference is just the design actually being enabled or not
t
Do either of you have vccd1 cut from vccd on the dev board so that vccd1 can be measured independently of vccd?
c
No I have not cut it open so far.
m
yes I do
that's how I measured the difference
t
@Matt Venn: So you're seeing a 5.74mA draw specifically on vccd1?
m
yes for my MPW7 version
erm, actually I might be lying, this is after I removed the 1.8v regulator
t
@Christoph Weiser: As for the die thickness: I think it's the packaging house that also does the wafer backgrinding. Jeff DiCorpo should have the form that we filled out that specified the backgrinding amount. I don't have any bare dies from MPW-6 but the package for the bare dies from MPW-7 says "Thickness: 254um". I'm quite sure that the die thickness is in no way involved in what we're seeing.
@Christoph Weiser: Please check the ID number reported by the 
caravel_hkdebug.py
utility.
@Matt Venn, @Christoph Weiser: The ID number can be mapped to the slot number and ID number from this mapping: https://foss-eda-tools.googlesource.com/third_party/shuttle/sky130/mpw-007/foundry/+/refs/heads/main/manifest-mpw-007.csv
c
The command gives me "00071dbf" as output.
t
Then you have A3,003,microwatt_mpw7
What location number is printed on your QFN part?
c
No thats incorrect. I should have "00071a52". It says C2 on the package.
t
No, really, you have A3, the microwatt_mpw7. That's why you get no meaningful test results.
The packaging house has scrambled all the parts.
c
Yes I guessed that at this point :)
Yes because i received raw dies that are correct. I can visually confirm this because of the analog nature of the design.
t
Same here. The bare dies are the correct ones, but what's inside the QFN package is not the same part.
c
That sucks.
t
To me, it sucks a lot less than the thought that somehow my part is completely nonfunctional. Now all I have to do is find out who has my part.
Parts are scrambled in no particular order than I can see, so we'll have to do a community effort to figure out who has whose chips. I don't think there's any way to figure out what chip is inside each marked package other than to read off the part number from the housekeeping SPI.
m
@Matt Venn What part do you have as shown by 
caravel_hkdebug.p
?
t
Matt will be out until tomorrow morning.
👍 1
@Christoph Weiser: You have @Anton Blanchard's chips.
h
For me the project ID is shown as 
0001db09
. That doesn't exist in the manifest. I guess there's a bug in 
caravel_hkdebug.py
where 
{0:32b}
should be replaced with 
{:032b}
. With that change the project ID is 
00076c24
. Unfortunately that's not mine either.
m
Got 
A6,006,riscduino-dcore_d3_3,00075487
here (should be 
00070664
)
t
@htamas: You have the YONGA-CAN controller (A4).
👍 1
h
So we are playing Secret Santa MPW Edition™ where we bring up each other's chip?
t
@htamas: That is exactly how I described it to Andy. : ) (Except for the trademark.)
👍 1
Can anyone confirm that all 10 of your packaged/mounted parts have the same project ID?
h
The first 3 I checked does, let me check the rest.
t
I think if three are the same, the probability that the rest are the same is pretty high.
h
All 10 are the same. Also cross-checked my MPW-6 one and that's different (and correct).
m
Just checked, 10x identical 00075487 for me too.
t
I'm in a meeting now discussing with my colleagues at Efabless how to get everyone their correct parts as quickly as possible. We'll let everybody know as soon as we can.
👍 2
We will be tracking this on a spreadsheet, and will get out an announcement tomorrow so we can start correcting this mess.
j
For those tracking issues with mpw-7, I’ve just created a channel #mpw-7-silicon
m
I get 0003d1f7, so I think that's the problem with the hkdebug bug
changing hkdebug I get 0007a3ee
which is 
bitcoin_mining_asics
6 Views
Open in Slack
PreviousNext
Powered by