wafer.space Community

@Tholin / @Tim Edwards - I'm hoping to work with @Leo Moser (mole99) to put together something using previous MPW designs to send to GF for testing very soon.

Like, this month?

Yes

21:55

Hopefully that isn't a surpise to @Leo Moser (mole99)

Its was a surprise to me, heh

22:09

Would you also be interested in sending one of the WiP custom padframes to GF for testing?

Sure! I believe @Leo Moser (mole99) is busy this week with finishing iHP related stuff?

I have a padframe that should be working.

23:05

I can take that, populate the project area with a copy of one of my GFMPW designs and we'll see if everything still works as before.

23:05

Would allow me to do some fixes as well. The RISC-V core on my multi-project die is just a few adjustments/bugfixes away from being able to boot Linux. (edited)

@Tim 'mithro' Ansell Would this be of interest to you in general? Linux-capable CPU core on gf180?

A bit weird but I definitely wouldn't say no.

00:08

The uclinux on Tiny Tapeout is a pretty good demo to show people.

The idea is to get early feedback from GF, especially regarding the sealring, as the corner of the sealring is simply "best-effort" since we don't have any rules for it in the PDK. Another issue is fill generation, for which we currently only have a partial implementation in magic. I'm just finishing up my IHP tapeout and will be at ORConf right after that. After ORConf, I will have one full week to create a test reticle and work on fill. I will also upload the template repository for wafer.space designs. I would appreciate if you could use the template to build your chip @Tholin. It automatically adds the sealring after GDS streamout. (edited)

Alright, will do

16:02

I'm rushing some bugfixes to my multi-project die right now, and then I will tape that out a second time.

16:03

Not gonna do anything new. The multi-project die is a whole heap of designs that I already know the characteristics of, which is good.

Thanks! I'll let you know after ORConf once it's pushed. Being able to make comparisons between previous shuttles is definitely good.

@Tholin : I'm glad you're working on a 3.3V standard cell library for GF180MCU. I have come to the conclusion that the OSU standard cells are invalid and probably will never be synthesizable. I think it is the same old story with academic development---At one time in the past, they had expertise in standard cell design, but that expertise has been lost, and now all they do is academic excercises like CharLib where they are concerned about simulation efficiency and accuracy, and nobody has noticed that the layouts they're passing to the tool are unworkable for a variety of reasons (such as, for example, having a cell height that is not divisible by any track height).

Yeah! I do need to keep working on it sometime. Its on hold for now until after the first wafer.space shuttle.

@Tholin Just so you know, final submission will be in early December, so there may still be time to work on it :)

True, but my SCL is 3.3V and I do wish to tape out one more 5V chip on the first wafer.space shuttle.

15:14

Second and onwards I will be playing with 3.3V. Lets uhhh...make sure that the 5V stuff we have already works first.

15:14

Oh, that just reminds me that I should absolutely create a test layout for the extra 5V cells I’m making.

@everyone - The CrowdSupply page which will allows you to purchase wafer.space slots will be live in the next day or two. I am looking for people who want to purchase a slot to be beta testers.

4

Hey @Tim 'mithro' Ansell which pdk will we be using?

ombudsman

Hey @Tim 'mithro' Ansell which pdk will we be using?

The gf180mcu PDK (https://gf180mcu-pdk.readthedocs.io/) - I believe at least @Leo Moser (mole99) & @Tholin, @tnt have already been working with it. (edited)

2

01:50

I believe ciel is the best way to get the PDK?

Exciting times, Tim

1

Tim 'mithro' Ansell

I believe ciel is the best way to get the PDK?

yeah, with sky130 I use this -

#Enable PDK with this commit
ciel enable --pdk-family sky130A 12df12e2e74145e31c5a13de02f9a1e176b56e67

# Initiate the flow from design directory
librelane --ciel-pdk -p sky130A -s sky130_fd_sc_hd --flow Classic config.json

03:05

GF180 is also same I think

Hi guys, I was told this was the place to be and you where looking for beta testers. Still need to give it some more though as to if I wish to commit 6k to my broken a0

(edited)

heyo, connected with Tim at OpenSauce and might have roped me into participating as well

In the middle of a big cross-country move right now (and have no layout experience past my own little DIY projects) so not sure if I'll make this first shuttle. Was thinking about doing some test structures / circuits for an analog'y neuromorphic chip (spiking neural net stuff)

I wish I had the personal budget for a whole die, but in the meantime if anyone is thinking of sharing the cost for a multi-project die, I would at least like to know

algofoogle (Anton Maurovic)

I wish I had the personal budget for a whole die, but in the meantime if anyone is thinking of sharing the cost for a multi-project die, I would at least like to know

Hi @algofoogle (Anton Maurovic) How much area would you be looking for, and do you have any specific requirements ?

Essen

Hi guys, I was told this was the place to be and you where looking for beta testers. Still need to give it some more though as to if I wish to commit 6k to my broken a0

(edited)

If anyone is ready to order, please contact me with an email address and I'll add you to the access list.

Can people test if https://buy.wafer.space sends them to https://www.crowdsupply.com/wafer-space/gf180mcu-run-1/ correctly?

wafer.space GF180MCU Run 1

Fabricate 1,000 chips of your own design

wafer.space GF180MCU Run 1

Fabricate 1,000 chips of your own design

3

1

Tested on Firefox and Edge. Re-direct works.

1

Works for me (Chrome)

17:10

Nice campaign page!

As I mentioned, anyone ready to commit to a slot, please message me and I'll get you added to the ability to purchase right away.

algofoogle (Anton Maurovic) started a thread. 09/11/2025 04:48

@Tim 'mithro' Ansell In the campaign page, maybe specify it's the gf180mcuD variant in the PDK, that should allow people to lookup anything they need about the exact spec ( like top metal thickness for instance ).

1

Also "GlobalFoundries GF180MCU open‑source PDK" should be "GlobalFoundries gf180mcu open‑source PDK" or "GlobalFoundries open‑source PDK for GF180MCU".

@Tholin : Would it be okay with you if I incorporated your gf180mcu_as_sc_mcu7t3v3 standard cells into the open_pdks build of GF180MCU as an option? I would like to put something on the 1st wafer.space shuttle run using this library.

Okay, full disclaimer first: I never ran the full prechecks on a layout produced with the SCL. I don't know if it produces DRC correct GDSII outputs in the eyes of klayout (which was a massive pain point with my other SCL). (edited)

I understand the risks, and I'm willing to run the whole library through a large project synthesis and debug anything that looks wrong. Maybe extend the library, as well.

21:28

I want a 3.3V standard cell library for gf180mcu, and OSU is not going to be it.

Yeah, I'm not surprised

1

Hi everyone, I'm in the US/Chicago time zone until the 5th October

21:30

@Tim Edwards - @Leo Moser (mole99) talked with Staf from chips4makers at OrConf and apparently his cells should work on GF180MCU

I know Tim Ansell wants to do a test tapeout with GF later this month and for his consideration I'm gonna offer a GDSII of my multi-project die, but with some minor bugs fixed and using the template that mole99 is cooking up. After this, I'll be mostly free to keep developing my 3.3V SCL.

@Tim 'mithro' Ansell : If you want people to have access to Staf's cells (SRAM, or does he have more?), then I just need a pointer to a repository and I can incorporate them into open_pdks for GF180MCU.

@Tim Edwards - I'm guessing @Leo Moser (mole99) is probably still travelling back from OrConf at the moment.

21:42

This is what @Leo Moser (mole99) sent me;

I'm now back from ORConf, which was great! I had some interesting discussions with a lot of people. One of the most interesting projects for us is Staf Verhaegen's SRAM compiler: https://www.youtube.com/watch?v=G9uyKw3XoiM It would not only allow us to generate SRAM macros in different configurations, but also for 3.3V transistors on gf180mcu. I asked him if he would be interested to put different SRAM configurations on a shuttle slot. He is interested, although there are some changes needed to make it work on gf180mcu. I told him I'll get back to him after asking you whether there's still a slot available. Moreover, we could also use Staf's FlexCell stdcell generator to generate 3.3V cells. https://gitlab.com/Chips4Makers/c4m-flexcell Tholins cells are great, but this would give us a larger set of stdcells that we could even take to a different process. Tamas did not use them for the TT test shuttle only because he couldn't get them working with LibreLane in time for the tapeout. But it's just a matter of figuring out how to configure LibreLane with these stdcells. The only missing part then is the separation of the 5V and 3.3V voltage domains in the padring. There's a clever workaround using breaker cells that Tamas has already used. The proper way would be to create new power/ground pad cells based on the existing ones.

(edited)

FOSSi Foundation

A portable area efficient SRAM compiler: a ... job somebody has to ...

Chips4Makers / c4m-flexcell · GitLab

A flexible, scalable, open source standard cell library.

21:43

His stuff is also listed at https://bit.ly/ws-gf180mcu-stdcells

wafer.space - Notes around voltages and options for I/O and standar...

Notes around voltages and options for I/O and standard cells bit.ly/ws-gf180mcu-stdcells Voltages and GF180MCU See also https://bit.ly/ws-gf180 The GF180MCU process uses the same stack as the other 180nm process technologies but changes; The default oxide to be the same as the other 180nm proce...

@Tim 'mithro' Ansell : I have already declared my intent to work on the dual voltage I/O library problem.

@Tim Edwards - Great! Just trying to make sure everyone knows about things.

Tholin

I know Tim Ansell wants to do a test tapeout with GF later this month and for his consideration I'm gonna offer a GDSII of my multi-project die, but with some minor bugs fixed and using the template that mole99 is cooking up. After this, I'll be mostly free to keep developing my 3.3V SCL.

@Tholin Thanks for working on your design so we can include it in the test tapeout. Just to be clear, this is not a real tapeout, but rather a way for us to get feedback from GF about the design of the reticle, the sealring, if the fill matches density also on their side etc. The more real world design we have on there, the better. We should probably call it a virtual tapeout :)

Tim Edwards

@Tim 'mithro' Ansell : I have already declared my intent to work on the dual voltage I/O library problem.

@Tim Edwards Great! From what I understand we need two copies of the power and ground cells each, where one is for the core domain and one for the I/O domain. It would be really helpful if you could take a look at this

For now, Tamas used a nice trick to get separate power domains using custom breaker cells, see: https://github.com/TinyTapeout/tinytapeout-gf-0p1/blob/main/docs/padframe.svg However, if we have proper power/ground cells for both domains then we wouldn't have to resort to such tricks. If you have a PR ready just ping me and I can give it a try. We need to make sure that the pin shape for the bondpad comes first in the LEF, so that OpenROAD will promote the correct pin to a BTerm. See this commit: https://github.com/wafer-space/gf180mcu/commit/eb701885d4fc3aff546c974df1b3e7bcce6bd3c7

Tim Edwards

@Tim 'mithro' Ansell : If you want people to have access to Staf's cells (SRAM, or does he have more?), then I just need a pointer to a repository and I can incorporate them into open_pdks for GF180MCU.

Yes, we would like to get Staf's FlexCell stdcells into the PDK, as well as his SRAMs. Since both are generated, there's no repository at the moment that hosts the cells afaik. It would probably make sense for wafer.space to host repositories for both, which we keep up to date that you can then incorporate into open_pdks (unless Staf wants to host them himself).

I made a better DFF to fit into the 7-track 5V SCL. Its slightly wider and has some met2 obstructions, but is significantly faster than the DFFs that ship with the SCL.

12:41

12:42

Seeing clock period improvements of up to several ns using this.

2

Tholin

Click to see attachment 🖼️

Where can I grab this to incorporate it into the existing standard cells?

15:07

This is a digital standard cell layout made with Tholin's 3.3V standard cells, installed into the PDK with open_pdks and run through librelane. It was almost ludicrously easy.

Oh good, I expected it to completely break with librelane without major config changes.

15:09

Set SYNTH_STRATEGY: DELAY 4 if you wanna push it to its limits.

It was almost perfect out-of-the-box. All I was missing was the "drc_exclude.cells" file, and I had to add a "touch" command to the installer to force it to be created. I'll give "SYNTH_STRATEGY: DELAY 4" a try. This was really just a proof-of-concept test, though.

15:15

"SYNTH_STRATEGY: DELAY 4" apparently worked (?). I'm not sure how to prove that it did. Anyway, at this point it's more productive for me to be pushing my commit to open_pdks.

That option makes it optimize for pure speed! Should be able to push the clock period real low now.

I committed a blank drc_exclude.cells file into the SCL’s repo

15:43

So that should be taken care of now

Tim Edwards

Where can I grab this to incorporate it into the existing standard cells?

https://github.com/AvalonSemiconductors/gf180mcu_extra_cells

GitHub - AvalonSemiconductors/gf180mcu_extra_cells: Additional 7-tr...

Additional 7-track, 5V standard cells for gf180mcu PDK. - AvalonSemiconductors/gf180mcu_extra_cells

16:00

Its in here

16:01

gf180mcu_extra__dfxtp_2

Should I merge this directly into the gf180mcu_fd_sc__ repository, or should I try to incorporate it as an extension (like I did with the "sky130_ef_sc" cells), in which case I would prefer a more targeted library name, like gf180mcu_as_sc_9t5v0?

It should be an extension

17:27

I mean, that's why I called it "extra cells"

17:28

The DFF I made is meant to be a full replacement for the one in the fd_sc_7t5v0, though, and you have the exclude the whole wildcard of gf180mcu_fd_sc_7t5v0__dff* from synthesis.

I think a gf180mcu_as_sc_9t5v0 makes the most sense?

7t

20:26

Its still 7-track

20:26

I'm also reserving that name for if/when I make a full 5V custom SCL

20:27

Addons to the existing SCLs should have a separate naming convention.

I would say that everything under gf180mcu_as_XXXX would be your name space.

I'll probably be re-naming this to gf180mcu_as_extra, then. Its intended to mostly only contain non-synthesizable special cells anyways, that you have to instantiate explicitly (i.e. transmission gates).

SGTM!

Hi all, I've made a start getting TinyQV building on gf180 - shamelessly stole the build script from tinytapeout-gf-0p1. Result is here https://github.com/MichaelBell/gf180mcu-tinyQV

GitHub - MichaelBell/gf180mcu-tinyQV: TinyQV for gf180mcu

TinyQV for gf180mcu. Contribute to MichaelBell/gf180mcu-tinyQV development by creating an account on GitHub.

21:11

Fits in 600x600um with 25um padding. It's quite slow though, it wouldn't build with a 50MHz clock so I used 40MHz. Whereas it manages over 70 on sky130, is that expected? (edited)

I've gotten pretty good at squeezing performance out of gf180 flows. Let me try.

21:13

What is tinyQV again?

Sure - though this is just me mucking about for now! Don't have any particular goal yet.

21:14

TinyQV is my quad bit serial Risc-V CPU. Tim was looking for a small Risc-V CPU and we thought it might be a good fit

21:16

Its latest outing was on the ttsky25a Risc-V peripheral competition - those versions are huge with loads of peripherals connected. But this version is just the "standard" one

I...uhhh....I’ve never seen this happen before

1

There is some stuff about Mike's TinyQV in my doc @ https://bit.ly/ws-tiny-riscv-proof

wafer.space - GF180MCU Bit Serial RISC-V Implementation - bit.ly/ws...

GF180MCU Bit Serial RISC-V Implementation https://bit.ly/ws-tiny-riscv-proof Goal The primary goal of this project is to show a potential pathway to creating “custom RISC-V” chips with wafer.space’s low volume manufacturing & chip on board packaging that are within the realm of being cost compet...

@RebelMike I would expect gf180 to be slower than sky130 yes, no doubt about it. With tweaking and optimizing, you could maybe get gf180 to match a "default run" of sky130 but if you put the same effort tweaking and optimizing, I'd expect sky130 to win speed wise.

1

@RebelMike - Looks like you are using a bunch of flip flops for the register file? https://github.com/MichaelBell/gf180mcu-tinyQV/blob/main/src/latch_mem.v ?

gf180mcu-tinyQV/src/latch_mem.v at main · MichaelBell/gf180mcu-tinyQV

TinyQV for gf180mcu. Contribute to MichaelBell/gf180mcu-tinyQV development by creating an account on GitHub.

21:22

Or is that main memory?

Tim 'mithro' Ansell

@RebelMike - Looks like you are using a bunch of flip flops for the register file? https://github.com/MichaelBell/gf180mcu-tinyQV/blob/main/src/latch_mem.v ?

That is some scratch memory - though not actually included in that build above.

21:23

Registers are just flip flops - they're in https://github.com/MichaelBell/tinyQV/blob/gf180mcu/cpu/register.v

tinyQV/cpu/register.v at gf180mcu · MichaelBell/tinyQV

A Risc-V SoC for Tiny Tapeout. Contribute to MichaelBell/tinyQV development by creating an account on GitHub.

21:27

Would probably want to tweak the way this works a bit - all of the registers rotate constantly (idea came from https://github.com/Wren6991/tt02-whisk-serial-processor), but using a clock gate or plain enable in logic so only the registers being accessed are rotated would probably be preferable. (edited)

@RebelMike - how does that build compare in size to the minimax example @Xobs did a long time ago pictured the doc @ https://bit.ly/ws-tiny-riscv-proof ?

wafer.space - GF180MCU Bit Serial RISC-V Implementation - bit.ly/ws...

GF180MCU Bit Serial RISC-V Implementation https://bit.ly/ws-tiny-riscv-proof Goal The primary goal of this project is to show a potential pathway to creating “custom RISC-V” chips with wafer.space’s low volume manufacturing & chip on board packaging that are within the realm of being cost compet...

Is that https://github.com/gsmecher/minimax ? I hadn't come across that before.

GitHub - gsmecher/minimax: Minimax: a Compressed-First, Microcoded ...

Minimax: a Compressed-First, Microcoded RISC-V CPU - gsmecher/minimax