wafer.space Community - Standard Voltage & SRAM Macros

RebelMike

Maybe a bit of a table describing the capabilities and current state/risk of the different IP libraries would be useful to have somewhere. My understanding: SCLs:

gf180mcu_fd_sc_mcu7t5v0 - foundry provided, safe, works at 5V or 3V3. Slow.
gf180mcu_fd_sc_mcu9t5v0 - foundry provided, safe, works at 5V or 3V3. Faster than 7t but takes more area.
gf180mcu_as_sc_mcu7t3v3 - community provided, not tested, high risk, works at 3V3 only. Fast. PADs:
gf180mcu_fd_io - foundry provided, safe, works at 5V or 3V3 but connects core and IO power domains together.
gf180mcu_ocd_io - community provided, tested on run 1, low risk, works at 5V or 3V3 but keeps core and IO power domains separate, so you could e.g. run IO at 5V and core at 3V3. SRAMs:
gf180mcu_fd_ip_sram - foundry provided, safe, works at 5V or 3V3. 128, 256 and 512 bytes.
gf180mcu_ocd_ip_sram - community provided, initial testing from run 1 looks good, medium risk, works at 3V3 only. Smaller area. 64, 128, 256, 512 and 1024 bytes.

Do you know if anyone ended up doing this?

Tim 'mithro' Ansell

Do you know if anyone ended up doing this?

Not that I've seen

Great table @RebelMike just what I was looking for

There's that one Google docs on SRAM options for sky130 / ihp-sg13* / gf180mcu: https://docs.google.com/document/d/1Cyeh-kpbmeF-G5Fq_sljsc890BRfw81f0aPwP-twvVE/edit

SRAM options

SRAM options for sky130 / ihp-sg13* / gf180mcu Most of this information is compiled from the SRAM channel on FOSSi Chat and the websites / repositories of the relevant IP blocks / generators. It is current as of August 2026. OpenRAM (University of California, Santa Cruz) sky130 only (plus some...

namibj

There's that one Google docs on SRAM options for sky130 / ihp-sg13* / gf180mcu: https://docs.google.com/document/d/1Cyeh-kpbmeF-G5Fq_sljsc890BRfw81f0aPwP-twvVE/edit

That document looks like something I would create but it wasn't created by me!

Tim 'mithro' Ansell

That document looks like something I would create but it wasn't created by me!

Do you think teaching the COB e-tester to do basic all-ones/all-zeros/"random-ish" pattern testing for rough function checking of the FlexMem dies on Run2, [if sufficiently supported by the tester schematic also a brief (100~1000 ms span) retention test each with all-zeros and all-ones pattern (this one actually done on every die; the functional behavioral test could be done to just a single die though one random-looking pattern might be good too just to rule out most wiring/via defects and broken address decoders) with the access voltage notably higher as we'd be stressing the internally-differential bitcells)], would be desirable (so we'd have at least preliminary information on bitcell performance/margins and an idea of actual production yield with a long time to spare until the slot buy deadline of Run3)? I'm understanding that some form of serial is recorded during this testing, and I don't think there'd be good reason to flag them based on results more nuanced than (at most) sorting between "no errors as long as voltage is kept reasonable" and "memtest caught at least one error" without discarding but rather to make it easier to look at "interesting" individual dies later.

namibj

Do you think teaching the COB e-tester to do basic all-ones/all-zeros/"random-ish" pattern testing for rough function checking of the FlexMem dies on Run2, [if sufficiently supported by the tester schematic also a brief (100~1000 ms span) retention test each with all-zeros and all-ones pattern (this one actually done on every die; the functional behavioral test could be done to just a single die though one random-looking pattern might be good too just to rule out most wiring/via defects and broken address decoders) with the access voltage notably higher as we'd be stressing the internally-differential bitcells)], would be desirable (so we'd have at least preliminary information on bitcell performance/margins and an idea of actual production yield with a long time to spare until the slot buy deadline of Run3)? I'm understanding that some form of serial is recorded during this testing, and I don't think there'd be good reason to flag them based on results more nuanced than (at most) sorting between "no errors as long as voltage is kept reasonable" and "memtest caught at least one error" without discarding but rather to make it easier to look at "interesting" individual dies later.

@namibj - I would probably happily send you a free CoB testing tool if you wanted to try developing that. I doubt it would be something that we would run as part of actual CoB testing.

4:08 a.m.

@namibj - wafer.space will (hopefully) have the CoB tester available for purchase from Crowd Supply sometime soon.

4:08 a.m.

@Lauri / @stuart / @storborg - Where did we get with that?

Tim 'mithro' Ansell

@namibj - I would probably happily send you a free CoB testing tool if you wanted to try developing that. I doubt it would be something that we would run as part of actual CoB testing.

If the developer of the current firmware could make a guess how long they'd expect to take to implement such if they would do it themselves, in a way that doesn't rely heavy on AI (at least not really on agentic AI), I'd be able to give you an understanding/guess/judgement of whether I expect to fit implementation and the necessary debugging of such functionality into the next couple weeks (I'm expecting it to take a week or two from now to reach me at the fastest reasonable). Do you happen to know if the FlexMem (Chips4Makers) test dies on Run2 are owned by them or by you? In any case depending on the timing impact from it I would request getting a pair of COBs that pass bond testing of each of the 3 FlexMem dies on loan to test/debug with.

For distribution: we’re close but we need content and probably a little bit of compliance paperwork.

For the record, I'm in Germany; you could mail it to the office preferrably not via specifically FedEx in specifically a way that requires me to settle import duty bills with FedEx (DHL and UPS are zero issue, DDP through FedEx is also zero issue). (FedEx charges painful billing fees that's why.) Insured USPS depending on the timing is also zero issue (it's delivered by DHL here, they take like 5 bucks flat fee for the courtesy of dispersing the duty to customs ahead of you even knowing the exact shipment if you're a consumer and thus couldn't have filed it with customs without causing customs delays.), but uninsured I don't trust with goods worth more than 20 bucks.

namibj

There's that one Google docs on SRAM options for sky130 / ihp-sg13* / gf180mcu: https://docs.google.com/document/d/1Cyeh-kpbmeF-G5Fq_sljsc890BRfw81f0aPwP-twvVE/edit

Any idea who created that Google Doc? I had Claude pull the data into a spreadsheet @ https://docs.google.com/spreadsheets/d/1O2FOcM8blrrgphjqfaYhFVnZL5zYIxU0w4GsqV4uyRc/edit?gid=406#gid=406

diugging the comments suggests Tamas Hubai

In my view the CoB tester current goal is to catch any CoB's that have a bad or missing bond. Any testing that's beyond this is not wafer.space responsibility. Design verification should rest with the chip designer. However, it is possible to set up more die specific tests as part of CoB testing, but this should be discussed separately. Re: tester, as @Tim 'mithro' Ansell said, happy to arrange a tester for you.

Lauri

In my view the CoB tester current goal is to catch any CoB's that have a bad or missing bond. Any testing that's beyond this is not wafer.space responsibility. Design verification should rest with the chip designer. However, it is possible to set up more die specific tests as part of CoB testing, but this should be discussed separately. Re: tester, as @Tim 'mithro' Ansell said, happy to arrange a tester for you.

I'm aware it's not wafer.space's responsibility; the main reason I'm even suggesting it caught in the CoB testing would be that the tests in particular would be designed to provide statistical yield information of the afaik by far densest single-port SRAM available without NDA on gf180mcuD. That said, I would still be interested in this; whether it's practical for me to complete on an appropriate schedule I would try to judge if you could perhaps attempt to judge the effort involved in implementing some relatively simple SRAM retention testing and a couple simple pattern tests aimed at catching misbehaving addressing decoders. If it's within my predicted capabilities, I would like measurements to be published in about 4~6 (8 at most) weeks from now. (On such note: if there is known minimum and maximum operating temperature for the tester, I'd like to hear; if I can find an empty chest freezer to use and (easier) a temporarily spare electric baking oven, I'd try to rig up a "we have a glove box at home" with some thick gloves to test up to about 90~95C and down to about -15C (or as far as the tester can handle. Provided I've managed to get some room temperature data first, and likely any thermal chamber testing won't be in November, though I'd try at least with some days to spare to the Run3 GDS deadline.)....)

namibj

I'm aware it's not wafer.space's responsibility; the main reason I'm even suggesting it caught in the CoB testing would be that the tests in particular would be designed to provide statistical yield information of the afaik by far densest single-port SRAM available without NDA on gf180mcuD. That said, I would still be interested in this; whether it's practical for me to complete on an appropriate schedule I would try to judge if you could perhaps attempt to judge the effort involved in implementing some relatively simple SRAM retention testing and a couple simple pattern tests aimed at catching misbehaving addressing decoders. If it's within my predicted capabilities, I would like measurements to be published in about 4~6 (8 at most) weeks from now. (On such note: if there is known minimum and maximum operating temperature for the tester, I'd like to hear; if I can find an empty chest freezer to use and (easier) a temporarily spare electric baking oven, I'd try to rig up a "we have a glove box at home" with some thick gloves to test up to about 90~95C and down to about -15C (or as far as the tester can handle. Provided I've managed to get some room temperature data first, and likely any thermal chamber testing won't be in November, though I'd try at least with some days to spare to the Run3 GDS deadline.)....)

I think the CoB tester without hardware modifications can't be used for function testing: 1. Maximum current you can supply to chip is 1mA. 2. Out of 5 mux channels, 2 are for power, and you're left with 3. if the CoB needs clk from rp2350, then you're left with 2 IOs. (i didn't have time to read the whole thread, so I'm assuming you need more IO's to do the test?) This makes me wonder if we could have a single IO interface for on-chip testing. Instead of developing custom test harnesses for each chip, wafer.space could provide a standard test interface, and chip designers implement their own on-chip test logic. re: temps - I haven't tested it outside 25-35 range. I can do some simple testing in coming weeks. Have a freezer and hot plate available.

@namibj - I would also chat with @Essen and @Tim Edwards and @Chips4Makers aka Staf Verhaegen about what testing of SRAMs makes the most sense.

7:55 a.m.

I think there was some other discussions around that.

From looking what the spreadsheet shows, it looks like @Chips4Makers aka Staf Verhaegen has done a pretty excellent job with flexmem.

namibj

If the developer of the current firmware could make a guess how long they'd expect to take to implement such if they would do it themselves, in a way that doesn't rely heavy on AI (at least not really on agentic AI), I'd be able to give you an understanding/guess/judgement of whether I expect to fit implementation and the necessary debugging of such functionality into the next couple weeks (I'm expecting it to take a week or two from now to reach me at the fastest reasonable). Do you happen to know if the FlexMem (Chips4Makers) test dies on Run2 are owned by them or by you? In any case depending on the timing impact from it I would request getting a pair of COBs that pass bond testing of each of the 3 FlexMem dies on loan to test/debug with.

I haven't paid for the flexmem test chips so I consider the dice owned by wafer.space and they may send them to anyone they like. Besides I haven't started with thinking how to test the test chips and given the limited time I have I myself will most likely only be able to do a limited functional verification of the chips. So if you could be involved in a more in-depth testing of the chips that would be a godsend. I certainly will support you there.

1

Chips4Makers aka Staf Verhaegen

I haven't paid for the flexmem test chips so I consider the dice owned by wafer.space and they may send them to anyone they like. Besides I haven't started with thinking how to test the test chips and given the limited time I have I myself will most likely only be able to do a limited functional verification of the chips. So if you could be involved in a more in-depth testing of the chips that would be a godsend. I certainly will support you there.

Thanks!

Lauri

I think the CoB tester without hardware modifications can't be used for function testing: 1. Maximum current you can supply to chip is 1mA. 2. Out of 5 mux channels, 2 are for power, and you're left with 3. if the CoB needs clk from rp2350, then you're left with 2 IOs. (i didn't have time to read the whole thread, so I'm assuming you need more IO's to do the test?) This makes me wonder if we could have a single IO interface for on-chip testing. Instead of developing custom test harnesses for each chip, wafer.space could provide a standard test interface, and chip designers implement their own on-chip test logic. re: temps - I haven't tested it outside 25-35 range. I can do some simple testing in coming weeks. Have a freezer and hot plate available.

It's SRAM; I actually assumed the analog mux would have been capable enough to turn IO supply "rails" into bit patterns. But the other restrictions do suggest I should work with the others on getting a more capable tester than this bond-ESD-diodes one; I'd plan on piggybacking on the same COB interface though.

Chips4Makers aka Staf Verhaegen

I haven't paid for the flexmem test chips so I consider the dice owned by wafer.space and they may send them to anyone they like. Besides I haven't started with thinking how to test the test chips and given the limited time I have I myself will most likely only be able to do a limited functional verification of the chips. So if you could be involved in a more in-depth testing of the chips that would be a godsend. I certainly will support you there.

I want to use your memory at 50MHz, so I guess I am interested in helping testing

10:35 p.m.

No promises in being able to do so before run3, I will have to see how the rush goes.

We have roughly ~150 die from the first 6 initial wafers which are currently getting sorted. We will get another 1,000 die sometime early next year.

1

Tim 'mithro' Ansell

We have roughly ~150 die from the first 6 initial wafers which are currently getting sorted. We will get another 1,000 die sometime early next year.

As mentioned I'd probably like 2 bonded ones of each of the 3 FlexMem slots that do not show bond defects on any of the functional pins. On loan would suffice. @Lauri can you link me info about the MUX so I could figure out if I could "ab"-use the MUX itself to generate the CMOS level test patterns for the SRAM to access it at a speed fast enough to not outright take "forever" to memtest? It's just a few kilobyte so it shouldn't take any real time to complete, and I'm not doing access speed tests. I want to test for bad bits, especially also under harsh voltage and as practical temperature corners, but pretty much only for retention. So it'd involve testing data retention down to around 500 mV, then re-increasing VDD to whatever is reasonable to access, and checking data bits. It would be great if this works with the existing tester so we don't need special hardware to possibly cover many dies for statistically significant results.

namibj

As mentioned I'd probably like 2 bonded ones of each of the 3 FlexMem slots that do not show bond defects on any of the functional pins. On loan would suffice. @Lauri can you link me info about the MUX so I could figure out if I could "ab"-use the MUX itself to generate the CMOS level test patterns for the SRAM to access it at a speed fast enough to not outright take "forever" to memtest? It's just a few kilobyte so it shouldn't take any real time to complete, and I'm not doing access speed tests. I want to test for bad bits, especially also under harsh voltage and as practical temperature corners, but pretty much only for retention. So it'd involve testing data retention down to around 500 mV, then re-increasing VDD to whatever is reasonable to access, and checking data bits. It would be great if this works with the existing tester so we don't need special hardware to possibly cover many dies for statistically significant results.

Mux chip is WCH CH446X

1

Lauri

Mux chip is WCH CH446X

Hmmm, looking at the numbers and the revision r2 schematic at https://github.com/szfate/BondTest72 , it should almost be practical to pull off with this. Basically, what's missing would be a precision programmable voltage source packaged/combined together with a bias load resistor (from COME) to GND (that soaks up the directly connected 1000μA current source as well as the leakage through COMC and COMD performing parallel read/scan access of to-be-read die/DUT CMOS outputs (like those IOs are driven so it's through the channel not the VDD ESD clamp)), which would work as a convenient pluggable module on J1. Given that these FlexRam dies on Run2 don't actually contain that much memory, a full SRAM memtest pattern access (to see if the previous milliseconds of reduced supply voltage caused any of the bits to loose their pattern-value due to a natural bias to the negation) should only take single digit milliseconds anyways... With that schematic, the approximate 5 MHz minimum/worst-case read/probe (per bit) access speed (under conditions that only involve well-driven CMOS logic signals (thus only requiring a brief moment to propagate until the still-selected switch can be returned to a resting state of high-Z)) (and at least half that speed for write bits (turn off drive in one direction, turn on drive in the other direction)) aren't that bad.

GitHub - szfate/BondTest72: BondTest72 mainboard design files

BondTest72 mainboard design files. Contribute to szfate/BondTest72 development by creating an account on GitHub.

@RebelMike any updates you would make to your list from July? Would we consider 3v3 SRAM more safe now?

Actually looks like as of October 11, https://docs.google.com/spreadsheets/d/1O2FOcM8blrrgphjqfaYhFVnZL5zYIxU0w4GsqV4uyRc/edit?gid=406#gid=406 claims OCD SRAM is working in silicon @ 50 MHz

Open Source SRAM Achieved Results (SKY130 / GF180MCU / IHP SG13G2)

@glaxus - Don't necessarily trust that, I had an AI generate it. It's a risk verse reward type trade off. How much do you care about your design not working?

Hmm, it’s not a commercial design so low stakes I guess. The FD macros just take so much space that they might not be feasible in the first place. I’ll have to use flexmem or ocd macros in my case anyways I think