wafer.space Community

Tim 'mithro' Ansell

@Tim Edwards - Could you add your new 3v3 SRAM into the spreadsheet @ https://docs.google.com/spreadsheets/d/1fW5ecBsLSec4hXBMaOjMUHQGslm4y-QUILgrxqS8MpA/edit ?

Your spreadsheet is showing a maximum of 115kB with my largest (1kB) macro. Assuming the thing actually works.

Tim 'mithro' Ansell

@BreakingTaps - It would be great to add the stuff you did around DFFRAM too.

will do! A little confused by the DFFRAM entries that are currently in the sheet. they link to Tim's sram (and are also dead links)

Hi guys, I am working on the OpenROAD Initiative (https://openroadinitiative.org/) to support open-source EDA tools. @Tim 'mithro' Ansell suggested I reach out here to get your feedback on two questions: What are the trade-offs of using open-source tools vs. commercial tools? What level of support do you expect from open-source tools (community, dedicated team, etc.)? I really appreciate your responses! We’ll use your input to fine-tune our approach in improving usability and reducing costs for chip designers. Thanks in advance!

1

BreakingTaps

will do! A little confused by the DFFRAM entries that are currently in the sheet. they link to Tim's sram (and are also dead links)

The existing DFFRAM data is not valid, just me copying the SRAM block to give you a place to add your data.

1

OlegL

Hi guys, I am working on the OpenROAD Initiative (https://openroadinitiative.org/) to support open-source EDA tools. @Tim 'mithro' Ansell suggested I reach out here to get your feedback on two questions: What are the trade-offs of using open-source tools vs. commercial tools? What level of support do you expect from open-source tools (community, dedicated team, etc.)? I really appreciate your responses! We’ll use your input to fine-tune our approach in improving usability and reducing costs for chip designers. Thanks in advance!

BTW It should be open source tools vs proprietary tools

OlegL

Hi guys, I am working on the OpenROAD Initiative (https://openroadinitiative.org/) to support open-source EDA tools. @Tim 'mithro' Ansell suggested I reach out here to get your feedback on two questions: What are the trade-offs of using open-source tools vs. commercial tools? What level of support do you expect from open-source tools (community, dedicated team, etc.)? I really appreciate your responses! We’ll use your input to fine-tune our approach in improving usability and reducing costs for chip designers. Thanks in advance!

@OlegL None of the three Get Involved buttons are working for me using Chrome with popups and javascript enabled.

bailey

@OlegL None of the three Get Involved buttons are working for me using Chrome with popups and javascript enabled.

Not sure where these buttons came from. Ignore them. There is a link in the message where you can learn more about OpenRoad Initiative

OlegL

Not sure where these buttons came from. Ignore them. There is a link in the message where you can learn more about OpenRoad Initiative

@OlegL Sorry for the confusion. The Get Involved buttons are on the https://openroadinitiative.org/ page.

Riyaz

Home

bailey

@OlegL Sorry for the confusion. The Get Involved buttons are on the https://openroadinitiative.org/ page.

@bailey The website is still work in progress. Please add any answers to question(s) and/or your comments to the reply

1

Hi guys, just circling back to see if anyone has any feedback or comments on these two questions: 1. What are the trade-offs of using open-source tools vs. proprietary tools? 2. What level of support do you expect from open-source tools (community, dedicated team, etc.)?

OlegL

Hi guys, just circling back to see if anyone has any feedback or comments on these two questions: 1. What are the trade-offs of using open-source tools vs. proprietary tools? 2. What level of support do you expect from open-source tools (community, dedicated team, etc.)?

grain of salt: I'm an absolute newbie here, and no experience with proprietary tools. but for 2), I think the biggest help would be really thorough documentation of common "knobs" that a designer might need to tune. What the parameter does, how it interacts with other parts of the system, when you might need to tune a specific parameter, what ranges are reasonable, guides about how to think about parameter tweaking ("try A first, then try B, but be careful because it might affect XYZ"). Some of this exists but it's pretty sparse in places. I.e. material to help with self-directed troubleshooting, rather than direct support (which scales poorly anyway). As an example, I pretty blindly messed with all the margin parameters until I found combinations that worked, only to later learn that manual ECO steps exist and I could maybe have targeted specific areas of the circuit. Ditto to learning late in the project that 9T cells were an option and fixed a lot of my timing/congestion issues. Or that different SRAM macro placement locations/orientations could seriously impact PVT corners. Or how to load up DRC violations and inspect them manually, and strategies for fixing them. All of that seems very obvious in hindsight, but it was a huge learning curve to get up to speed with since documentation is kinda all over the place. And there is a big lack of "best practice" style guides

00:14

tl;dr: the wafer.space project template was amazing for "push button get GDS", but as a newbie it took a long time to figure out how to tweak things to fit my specific design

More robust docs about how OpenRoad/LibreLane works in that regard would really help

People who are interested in adder optimization might find https://onlinelibrary.wiley.com/doi/abs/10.1002/cta.70336 interesting.

2

I've begun a series of back-end checks on the ws-1 open source designs. I'm currently running magic extraction, magic soft connection checks, and CVC-RV ERC checks. netgen LVS will follow if I can locate the source netlists, and then maybe Klayout LVS. You can follow the results here https://github.com/d-m-bailey/extra_be_checks/discussions/52.

1

https://www.linkedin.com/events/7426800975115493376/

LinkedIn Login, Sign in | LinkedIn

Login to LinkedIn to keep in touch with people you know, share ideas, and build your career.

04:02

I'll be chatting on a live stream about wafer.space with Alex from Hackster tomorrow

04:02

Please share with people

2

06:11

This is super cool!

@Tim 'mithro' Ansell ^^^ Crypto Spam (screenshots) in this channel and others (including channels that ought to be limited posting like announcements and welcome-and-rules, but for some reason are open to general posting...)

Leo Moser (mole99)

Thank you all for taking part in today's call! I'm looking forward to seeing the actual chips working

Sorry for missing the call. Is there any recording, slides or pictures to share?

Would have loved to join but was traveling that day.

Tim 'mithro' Ansell

I'll be chatting on a live stream about wafer.space with Alex from Hackster tomorrow

For anyone (like me) interested in Tim's chat with Alex: https://www.youtube.com/watch?v=HpBEOXHUzHE

Hackster.io, an Avnet community

Tim "mithro" Ansell: Custom Silicon with wafer.space // Hackster Café

1

Thorben

Sorry for missing the call. Is there any recording, slides or pictures to share?

Would have loved to join but was traveling that day.

No problem! There will be future ones

Unfortunately not, we just looked at the various projects and had a chat.

1

Tim is indeed right that I invest a lot of energy into making my open source silicon projects as impressive as possible, and its absolutely because I want to make open-source chips look like something to be taken seriously. And I won’t let "but that looks really difficult" stop me because I have covered my eyes! The difficulty can’t scare me if I can’t see it!

16:56

There are two things that get me through stuff like making my own SCL or making my first analog layout: 1) 200mg of caffeine 2) Wilful ignorance

16:58

Sometimes, I just need to lock in and focus on one problem at a time because the big picture is a giant monster and I have to hide from it to survive.

16:58

But also....so much coffee...

16:58

especially near deadline

ewen

@Tim 'mithro' Ansell ^^^ Crypto Spam (screenshots) in this channel and others (including channels that ought to be limited posting like announcements and welcome-and-rules, but for some reason are open to general posting...)

Do you know how to setup / fix that?

Tholin

Tim is indeed right that I invest a lot of energy into making my open source silicon projects as impressive as possible, and its absolutely because I want to make open-source chips look like something to be taken seriously. And I won’t let "but that looks really difficult" stop me because I have covered my eyes! The difficulty can’t scare me if I can’t see it!

I hope I didn't mangle your name too badly, I only speak one language and can't even pronounce that right a lot of the time.

It was correct

I don't know if it's a major problem, but it appears that the magic tech file 1.0.572-0-g5443591 does not process the metal slot layers.

Warning: unknown layers.
layer=34 type=3 (metal1 slot)
layer=36 type=3 (metal2 slot)
layer=42 type=3 (metal3 slot)
layer=46 type=3 (metal4 slot)
layer=81 type=3 (metal5 slot)

@Tim Edwards (edited)

Tim 'mithro' Ansell

Do you know how to setup / fix that?

https://support.discord.com/hc/en-us/articles/205369668-How-do-I-set-up-a-Role-Exclusive-announcements-channel Tl;DR: set up group of users who are to have permissions to post announcements, change channel permissions to remove "send message" from the "Everyone" group, and add "send message" permission for the group of users that should be allowed to post.

need information on the thickness of the chip?

bailey

I don't know if it's a major problem, but it appears that the magic tech file 1.0.572-0-g5443591 does not process the metal slot layers.

Warning: unknown layers.
layer=34 type=3 (metal1 slot)
layer=36 type=3 (metal2 slot)
layer=42 type=3 (metal3 slot)
layer=46 type=3 (metal4 slot)
layer=81 type=3 (metal5 slot)

@Tim Edwards (edited)

Magic does not handle the slot purpose layers, but it will preserve them if writing GDS verbatim. I notice that magic does not check for maximum metal width, either. That is probably a holdover from the original PDK development when we were expecting GF to run fill, seal, and slot generation. So there was no need to check the rule. Does wafer.space have any automated slot generation scripts, or is that up to the user to resolve?

Tim Edwards

Magic does not handle the slot purpose layers, but it will preserve them if writing GDS verbatim. I notice that magic does not check for maximum metal width, either. That is probably a holdover from the original PDK development when we were expecting GF to run fill, seal, and slot generation. So there was no need to check the rule. Does wafer.space have any automated slot generation scripts, or is that up to the user to resolve?

I created a simple script for metal slot generation: https://github.com/wafer-space/gf180mcu/blob/main/gf180mcuD/libs.tech/klayout/tech/drc/slot_generation/slots.drc

1

Tim Edwards

Magic does not handle the slot purpose layers, but it will preserve them if writing GDS verbatim. I notice that magic does not check for maximum metal width, either. That is probably a holdover from the original PDK development when we were expecting GF to run fill, seal, and slot generation. So there was no need to check the rule. Does wafer.space have any automated slot generation scripts, or is that up to the user to resolve?

I was just wondering about slot layers over via drc/lvs rules. Having the slot layers in a totally different cell would complicate magic extraction, I think. But if drc checks are required to ensure that the slot does not interact with vias and the slot does not break connectivity, then there may not be a problem. (Other than not being able to manually add slot data in magic).

I think the existing setup works best: Magic does not check maximum metal width and does not handle slots. Slots, fill, and seal ring are all added by scripts prior to submission and then run through DRC checks on klayout.

1

Are there any 3.3V digital IO libraries for the gf180mcu or plans to create one? I’m only aware of the foundry-provided 5V library, without level shifters and the OCD 5V IO for a 3.3V core by @Tim Edwards. Are these the only existing IO libraries, or am I missing something? Is running the foundry IO at 3.3V together with the core (which will be rather slow) the only option to get 3.3V CMOS IO currently?

The foundry one has caracterization data for 3.3V and will run fine at that level.

17:56

The speed difference between 3.3v and 5v is not that huge, it's only about 20~30% faster. (edited)

tnt

The speed difference between 3.3v and 5v is not that huge, it's only about 20~30% faster. (edited)

For the core? I've run several tests in Librelane some time ago using 3.3V liberty files for 7t library and got the impression that the difference is closer to 2 times. I'll check again, thanks.

@Egor Lukyanchenko : For the core, there is the 3.3V library created by @Tholin at https://github.com/AvalonSemiconductors/gf180mcu_as_sc_mcu7t3v3. It is being tested along with my I/O library on the current Wafer.Space shuttle run.

@Tim Edwards I'm aware of that and eagerly awaiting the results :). Do you plan to perform some kind of on-chip timing characterization for cells when you get the silicon? (edited)

@Egor Lukyanchenko No, I meant for the IO.

tnt

@Egor Lukyanchenko No, I meant for the IO.

For the IO I agree, the difference should be around 30%. But currently the core will need to be at 3.3V also, and it will be much slower, especially if considering ss corner (3V). So I was asking if maybe someone is planning to create 3.3V IO for 5V core or something like it :).

I had a quick go at trying to remove the thick oxide from the foundry standard cell ( go to the 3.3v oxide thickness but still leave the geometry the same ), hoping it would result in faster logic ... this was however quite a failure

18:34

The resulting cells ended up slower because although the thinner oxide lowered Vt a tiny bit, it wasn't even enough to compensate the increased gate capacitance also resulting from the thinner oxide and so it was all in all worse than leaving the 5V transistors running at 3v3.

tnt

The resulting cells ended up slower because although the thinner oxide lowered Vt a tiny bit, it wasn't even enough to compensate the increased gate capacitance also resulting from the thinner oxide and so it was all in all worse than leaving the 5V transistors running at 3v3.

Still a great attempt and a very interesting experiment

. I saw a discussion about it in Google docs.

Have you tried reducing gate width at the same time BTW? The minimum width for 3.3 is 0.28 um vs 0.5 um for 5V, so it should reduce the capacitance by a sizable amount.

Well yes, but that's a whole harder to automate / script

1

Egor Lukyanchenko

Have you tried reducing gate width at the same time BTW? The minimum width for 3.3 is 0.28 um vs 0.5 um for 5V, so it should reduce the capacitance by a sizable amount.

That's not exactly how that works

19:31

For example, the foundry cells don't use minimum-width transistors for "size 1" cells

I think he meant length not width.

tnt

I think he meant length not width.

I've meant poly width, which is channel length, SPICE "L" parameter, obviously. Confusing names, but gf180mcu refers to it as "Gate Width (Channel Length)" :). I've checked SPICE file for 7t library, all digital cells have nmoses with L=6e-7 and pmoses with L=5e-7 which are the minimal allowed for 5V.

There's a company creating ASICs with LLM models hardcoded into the chip, so it can run only that specific model, but much faster and more efficiently: https://taalas.com/ Out of curiosity, is this something that could be done (on a smaller scale) on wafer.space? I feel like the low cost might be a big advantage here, and the old process node not as much of a disadvantage as for other types of chips (since the main comparison is GPUs, not other model specific ASICs, so even an old node might be good enough). I have no idea how to estimate how large the chip would need to be depending on parameter count, so maybe this is completely unrealistic and a stupid question

(edited)

If efficiency is important older nodes can't be competitive in power/computation by orders of magnitude; same for time/computation and there are limits on amount of parallellization possible. (edited)

Leon

There's a company creating ASICs with LLM models hardcoded into the chip, so it can run only that specific model, but much faster and more efficiently: https://taalas.com/ Out of curiosity, is this something that could be done (on a smaller scale) on wafer.space? I feel like the low cost might be a big advantage here, and the old process node not as much of a disadvantage as for other types of chips (since the main comparison is GPUs, not other model specific ASICs, so even an old node might be good enough). I have no idea how to estimate how large the chip would need to be depending on parameter count, so maybe this is completely unrealistic and a stupid question

(edited)

I'd start by looking at how the weights are being mapped to the transistors and then calculate the maximum number of transistors on the silicon space and see if the model is of a size you might find useful, then see if 10x smaller is still useful (as that is likely what you'll get on first attempt).

@Leon are you referencing these people? https://www.anuragk.com/blog/posts/Taalas.html edit: whoops, didn't see you posted the link (edited)

Mmm, you can abutt diffusion to tap in gf180mcu right ? Magic doesn't seem to like it.

tnt

Mmm, you can abutt diffusion to tap in gf180mcu right ? Magic doesn't seem to like it.

You should be able to abut diffision and tap, but be aware that they will be at the same potential because of the salicide process. When you say magic doesn't like it, are you referring to drc run on gds created in another tool or are you editing directly in magic?

@bailey I'm editing in magic. And yes, I know potential will be shared.

tnt

@bailey I'm editing in magic. And yes, I know potential will be shared.

@tnt So you're trying to draw something like ndiffusion and ptap abutting and getting a drc error?

yes.

15:10

https://i.imgur.com/FHfjkxC.png

@tnt : This appears to be an oversight on the thickox diffusion only.

16:18

I'm tracking it down now. Not sure how I would end up with it working for low-voltage diffusion but failing for high-voltage diffusion. . .

I think what happened was that I had to put in an extra rule to check high voltage diffusion spacing to low voltage tap (which cannot abut due to the position of the thick oxide mask), and managed to disallow an abutting high voltage tap. I need to update open_pdks anyway, so I'll commit the fix today.

1

@Tim Edwards great, thanks for looking into it !

Are the VDD and DVDD signals in gf180mcu_ws_io__dvdd cells intentionally shorted on metal2? The spice file is missing the VDD pin. .SUBCKT gf180mcu_ws_io__dvdd DVDD DVSS VSS https://github.com/wafer-space/gf180mcu/blob/81dae519f8105d469dc4c89671a718c4f4370483/gf180mcuD/libs.ref/gf180mcu_fd_io/spice/gf180mcu_ws_io.spice Same question for VSS and DVSS in gf180mcu_ws_io__dvss The spice file is missing the VSS pin.

gf180mcu/gf180mcuD/libs.ref/gf180mcu_fd_io/spice/gf180mcu_ws_io.spi...

Temporary development repository for the gf180mcuD PDK variant. - wafer-space/gf180mcu

Leo Moser (mole99) started a thread. 02/25/2026 11:57

@Bl@st - I have an AI driven project to try to make a bunch of designs which are just SRAM at https://github.com/mithro/gf180mcu-sram-forge that still needs work.

GitHub - mithro/gf180mcu-sram-forge

Contribute to mithro/gf180mcu-sram-forge development by creating an account on GitHub.

Just gave the following presentation at Down Underflow 2026 at https://wafer.space/du26

4

1

And here's wafer.space in the latest ECL

https://fossi-foundation.org/blog/2026-02-21-ecl94#waferspace-launches-its-first-shuttle

El Correo Libre Issue 94

El Correo Libre Newsletter, Issue 94

2