wafer.space Community - general

wafer.space Community

Information / general

Welcome to wafer.space - documentation at wafer.space github - buy at buy.wafer.space - archives at discord.wafer.space

Between 10/31/2025 23:59 and 12/01/2025 00:00

Great talk thanks for sharing, I probably would have missed it otherwise

I finished porting the AS2650v2 to the wafer.space template. Although I’m not planning to tape this out, its a good reference: https://github.com/AvalonSemiconductors/as2650-ws

GitHub - AvalonSemiconductors/as2650-ws: AS2650v2 on wafer.space te...

AS2650v2 on wafer.space template. Contribute to AvalonSemiconductors/as2650-ws development by creating an account on GitHub.

2

Look how much free space there is without caravel!

Image attachment

4

12:51

With enough effort, you could easily double the amount of on-die RAM to 8KiB, but there is also 16 unused pads here as there is more of those too, so could fit more peripherals.

12:51

I am very happy I designed a extendable bus interface for the peripherals.

Running DRC on this takes more than the 32GB of RAM in my PC, so I have yet to actually see a top-level flow complete on this. (edited)

13:02

I will spin up an AWS instance with 128GB of RAM later and hopefully it completes.

13:02

You’ll see me commit the final outputs into the repo if I succeeded.

Maybe don't commit to the repo as it will bloat the git history, instead maybe as a release?

Or that

I did not take that much RAM to build user_project_wrapper during GFMPW

Tholin

I did not take that much RAM to build user_project_wrapper during GFMPW

Steps like filler generation were done by Efabless at the time. However, if you think a step takes too much RAM for its purpose, please let me know.

Yeah, I didn’t consider that it now has to check all the fillers.

13:35

I have my own concerns about those. Like, afraid that the fillers will interfere with any artwork on the die.

13:36

Ideally, I’d like the option to block fillers on a specific layer only, instead of every layer at once using fillblock. The artwork pixels themselves would create the required density on whichever layer it is on.

Unfortunately, this PDK does not provide layers to block fill on specific layers only. There's NDMY and PMNDMY (https://gf180mcu-pdk.readthedocs.io/en/latest/physical_verification/design_manual/drm_10_08.html).

I forgot that the SRAM macros generate magic DRC errors.

Image attachment

14:34

I think the LVS errors are from the logo.

14:35

Yes

14:35

Okay, I can fix that

14:35

Just missing some config lines

14:36

There is a layer in the GDSII file called "SRAM_CORE" or something like that, that is probably a DRC exclude.

14:36

Magic seems to ignore it right now. Klayout appears aware and does not generate DRC errors.

14:37

"SramCore 108/5"

14:37

That’s it

Yes, there are special rules for SRAM:

14:48

Maybe @Tim Edwards could look into adding them to the magic DRC deck, or simply ignore DRC errors in these areas (KLayout also checks them).

1) What 3.3V SRAM? 2) Yes, the usual method is to replace the SRAM with an abstract view. For the foundry-supplied 5V SRAMs, the PDK creates a .mag view in maglef/ that is DRC clean and points to the GDS data for the SRAM. That is the appropriate one to have in the layout while running full DRC.

Tim Edwards

1) What 3.3V SRAM? 2) Yes, the usual method is to replace the SRAM with an abstract view. For the foundry-supplied 5V SRAMs, the PDK creates a .mag view in maglef/ that is DRC clean and points to the GDS data for the SRAM. That is the appropriate one to have in the layout while running full DRC.

There are none in the PDK yet, but with Staf Verhaegen's SRAM generator we could try to generate them. 2. I was thinking more along the lines of excluding all areas marked by SramCore from the default DRC rules. This way all SRAM macros (and future generated ones) won't result in any violations. We should still check the layout with the KLayout rules, of course. I will try to blackbox the foundry SRAMs for now, I even created a LibreLane PR for that some time ago: https://github.com/librelane/librelane/pull/786

I opened one of the SRAM macros in magic on its own. There are DRC errors outside the region marked as "SramCore" also.

Those are illegal overlap but they are "fixed" by using the appropriate gds flat glob options when loading the GDS. IIRC Leo already set that up.

The abstract view is of the entire SRAM macro, so if you use that, it should resolve all issues whether or not they exist in the core cell.

2

tnt

Those are illegal overlap but they are "fixed" by using the appropriate gds flat glob options when loading the GDS. IIRC Leo already set that up.

I've set those up for the I/O and filler cells: https://github.com/wafer-space/gf180mcu-project-template/blob/6c5025a5e572e6c65f1c677966f37575acb1e52a/librelane/config.yaml#L192 Maybe the _CDNS_ also fixes the issue for the SRAMs.

Awesome video from @Matt Venn and Nanik Adnani who made some analog designs on gf180 https://www.youtube.com/watch?v=hVejMrkV-Bk

Zero To ASIC Course

Get started with Analog - Interview with Nanik Adnani

1

Leo Moser (mole99)

I've set those up for the I/O and filler cells: https://github.com/wafer-space/gf180mcu-project-template/blob/6c5025a5e572e6c65f1c677966f37575acb1e52a/librelane/config.yaml#L192 Maybe the _CDNS_ also fixes the issue for the SRAMs.

I changed the behavior of magic some revisions ago (after our discussion about the problem) to automatically seed the GDS reader with flatglob "*_CDNS_*" so that this would be taken care of by default for anyone with a sufficiently new version of magic. But I don't think that will solve the issue with the SRAMs, because the "CDNS" string is a result of using Cadence pcells, and the SRAM module cells are not pcells.

Tim Edwards

I changed the behavior of magic some revisions ago (after our discussion about the problem) to automatically seed the GDS reader with flatglob "*_CDNS_*" so that this would be taken care of by default for anyone with a sufficiently new version of magic. But I don't think that will solve the issue with the SRAMs, because the "CDNS" string is a result of using Cadence pcells, and the SRAM module cells are not pcells.

Good to know! Then I can remove that flatglob.

@Leo Moser (mole99) - Any recommendation on how much memory the server needs to run the checks?

00:01

@everyone - If people aren't already - I highly recommend signing up for the wafer.space GF180MCU Run 1 Crowd Supply campaign @ https://www.crowdsupply.com/wafer-space/gf180mcu-run-1

wafer.space GF180MCU Run 1

Fabricate 1,000 chips of your own design

3

waferspace

3

3

Tholin

Look how much free space there is without caravel!

16 x SRAM 512x8 SP?

https://docs.google.com/spreadsheets/d/1fW5ecBsLSec4hXBMaOjMUHQGslm4y-QUILgrxqS8MpA/edit?gid=0#gid=0

GF180MCU SRAM Sizing

00:04

https://docs.google.com/document/d/1hk0WXCmQ8LYNhn8gIVs8vHymR2MleQx2ro_hQlyOYKU/edit?tab=t.0

wafer.space - GF180MCU SRAM Maximizer

GF180MCU SRAM Maximizer Goal Work out the maximum amount of SRAM that is able to fit into the GF180MCU configuration. Specification Layout as many SRAMs as possible that fit in a given die space. Current die size - 3.88mm x 5.07mm Die Size Instances Total Wi...

1

asic destroyer

16 x SRAM 512x8 SP?

Could easily fit that much total, yeah

1

00:07

But I think I will continue to rely on external memory for most things.

Tim 'mithro' Ansell

@everyone - If people aren't already - I highly recommend signing up for the wafer.space GF180MCU Run 1 Crowd Supply campaign @ https://www.crowdsupply.com/wafer-space/gf180mcu-run-1

I'm definitely interested in this, but it's a little outside of my hobbyist budget at the moment (especially for pre-ordering when I don't have a specific design pretty far along). Keeping an eye on it, but unlikely to be in on this first run. Feedback, if useful: (a) It'd be useful to have details on the COB option (specific sizes, number of pads, etc), and (b) a partial COB option (like 30-100 or so parts) that would allow one to pursue packaging for the rest if results are good, or (c) a packaged option (QFN or the like) would make things a bit more appealing to this particular hobbyist.

I also wanna add that the magic DRC check taking dozens of gigabytes of RAM to run on the top-level is not good since not everyone has that. Even if that particular step is skipped, the rest of the flow needs enough RAM to where my laptop is struggling. And when it comes to hobbyists, these are the kinds of devices people are using.

@Tim 'mithro' Ansell : You might consider crowdsourcing additional Tiny Tapeout runs at Tiny Tapeout prices? I think you are better off aiming at getting many users at $100 to $200 each than indivduals putting up $7000 a run. I would certainly put $200 down on a lark, but I'm not going to spend $7000 unless I have something obvious in mind to do with it.

doh. Might be time to finally upgrade the lunix workstation. 32GB is kinda weak these days I guess ^^

Tim Edwards

@Tim 'mithro' Ansell : You might consider crowdsourcing additional Tiny Tapeout runs at Tiny Tapeout prices? I think you are better off aiming at getting many users at $100 to $200 each than indivduals putting up $7000 a run. I would certainly put $200 down on a lark, but I'm not going to spend $7000 unless I have something obvious in mind to do with it.

I'm hoping that when TT has finished porting that will definately be what happens.

00:29

@Brian Swetland / @Tim Edwards - You can also sign up for the updates even if you don't buy anything.

2

something mid-way between TT and a full dedicated wafer space run in cost, number of parts, and area might be interesting too.

00:31

I feel like there are probably viable price steps around $500 or $1000 or so for folks interested in something a bit more than a single part on an eval board of TT but not quite as big a commitment as $7000-8500 for 1K parts of their own

@Tholin : If anyone wants to help track down why magic is taking dozens of gigabytes of RAM, I can work on thinking of ways to mitigate the resource problem. It really should not be that bad. A number of methods were written (including by me) without consideration of how resources might blow up, and even when that goal is kept in mind, it's not always clear how badly some random subroutine is going to scale. From time to time I work on those issues, but recently I've been doing more PDK work and much of the magic development has been quick fixes and additions for problems that crop up when onboarding a new process. The "quick fixes" are often responsible for the resource hogging because I was trying to solve a problem quickly and just put down what came to mind without thinking about it too deeply.

1

00:36

@Tim 'mithro' Ansell : The $500 range is good for a "Chipalooza test chip" type design; those had about 14 slots for dedicated analog designs, all power gated (and $500 x 14 = $7000, conveniently). I've been wanting to run something like that on GF but I don't have any structure set up for advertising it.

No matter how you slice it, it's very exciting to see ASIC design heading into viability for hobbyists, small shops, etc, the way PCB and FPGA stuff previously has. Not just the more affordable shuttle runs, but the open toolchain.

@Tim 'mithro' Ansell : Also I don't know how much CrowdSupply works like KickStarter but I'm willing to bet that if you had a $50 entry for just supporting the whole project and getting back some small token piece of swag, you would get a lot of takers.

3

If there was an interesting project in the run that was open source (or at least open documentation), a support tier for $50-100ish for like 2-3 COB parts of that particular project, under a "can't guarantee it'll work, but you get an artifact and it might work" disclaimer might be a worthwhile "support the run" sort of thing

Brian Swetland

I feel like there are probably viable price steps around $500 or $1000 or so for folks interested in something a bit more than a single part on an eval board of TT but not quite as big a commitment as $7000-8500 for 1K parts of their own

I'm 100% supportive of people organising that type of thing.

Brian Swetland

If there was an interesting project in the run that was open source (or at least open documentation), a support tier for $50-100ish for like 2-3 COB parts of that particular project, under a "can't guarantee it'll work, but you get an artifact and it might work" disclaimer might be a worthwhile "support the run" sort of thing

One of the primary reason Crowd Supply is interested is that they would like people to use Crowd Supply to raise for their own projects that use wafer.space silicon.

Tim 'mithro' Ansell

I'm 100% supportive of people organising that type of thing.

Makes sense. Suppose that could take the form of a template/example project of a TT style interconnect and sub-project-select interface that folks wanting to do so could easily integrate.

Tim 'mithro' Ansell

One of the primary reason Crowd Supply is interested is that they would like people to use Crowd Supply to raise for their own projects that use wafer.space silicon.

oh, interesting! Yeah that would be cool to see.

IE If you are crowd funding a device which is a few hundred dollars and get a few hundred orders, it's reasonable to do a wafer.space run or two.

00:58

Crowd Supply also offers a pathway to getting your stuff listed on Mouser

Tholin

I also wanna add that the magic DRC check taking dozens of gigabytes of RAM to run on the top-level is not good since not everyone has that. Even if that particular step is skipped, the rest of the flow needs enough RAM to where my laptop is struggling. And when it comes to hobbyists, these are the kinds of devices people are using.

@Tholin (or others) - I have a machine (Ryzen 9950X3D, 128GB DDR5) which I was thinking I could give out a few accounts on, for people needing ways to run their stuff. Let me know if this would be helpful for you (edited)

Sadly my machines which have >128gb memory are in a shipping container

AWS also works

Tim Edwards

@Tim 'mithro' Ansell : Also I don't know how much CrowdSupply works like KickStarter but I'm willing to bet that if you had a $50 entry for just supporting the whole project and getting back some small token piece of swag, you would get a lot of takers.

That's a great point. I hope it is added as an option. I don't have anything I can fab at this time, but I want to make sure it continues to be available

Or use any leftover slots to tape out chip design people might be interested in buying and make the money back that way.

Tholin

Or use any leftover slots to tape out chip design people might be interested in buying and make the money back that way.

I had hope to do something like that, but need to have some designs people want to buy first

I can’t really offer much. I could do what I did with the AS2650v2, but with a RISC-V or other architecture that actually has C compiler support.

11:40

But that’s all I can think off

Bunnie was suggesting exploring silicon capacitors -> https://docs.google.com/document/d/1ahoCTmPvKExYtk3qqxvjMpnq5XOcIQvVWMF84zgi82k/edit?tab=t.0#heading=h.90mbdw45v39k

wafer.space - GF180MCU Silicon Capacitor

GF180MCU Silicon Capacitor Goal Create software which is able to generate a "maximal silicon capacitor" for a given configuration. Specifications GDSFactory Uses AI to tune the capacitor capacity Initial targets are the different GF180MCU stack ups. Why? Empty slots can be filled with silicon...

I am also experimenting with analog

11:59

Especially since we can do high-frequency analog stuff inside an IC

11:59

I want to make a chip that just has a bunch of analog gadgets on it

12:00

But I’m still experimenting.

There is of course @peterkinget 's Mosbius too

Tholin

I want to make a chip that just has a bunch of analog gadgets on it

See https://github.com/fossi-foundation/frigate_analog. Basically a field-programmable analog array with DACs, ADCs, instrumentation amplifiers, temperature sensor, etc., etc. Hard to port from sky130 to another process, but I would like to do that for GF180MCU and IHP sg13g2 eventually.

2

By the way, I am now actively working on a 3.3V SRAM macro. A bit of detective work which is a combination of ripping the DUALGATE layer off of the existing SRAMs and squeezing the transistors down to minimum length with the same W/L as the 5V cells have, and squeezing out additional space according to the published 3.3V SRAM design rules. My estimate from working on the main core SRAM cell is that a 512kB block will be 255um x 285um vs. 430um x 485um for the existing 5V SRAM 512kB macro. That's approximately 1/3 the area.

3

4

2

sky130's mpw_precheck has an oeb check to verify that the gpio connections make sense. Like:

If the gpio output is connected, then oeb should not be fixed high.
If the gpio input is connected, the gpio should be in input mode.
etc.

Does wafer.space need anything similar?

Tim 'mithro' Ansell started a thread. 11/07/2025 04:42

Leo Moser (mole99) started a thread. 11/07/2025 07:06

Leo Moser (mole99) started a thread. 11/07/2025 07:11

I’m slowly getting better at throwing together these multi-project dies. Come a long way since my first one on GFMPW-1. Optimizing multiplexer timing right now.

09:34

And at this point, I understand it good enough that I can automate it, I think.

09:35

Its definitely possible to auto-generate the multiplexer RTL from some config files specifying each design.

09:37

The big thing with my setup is that any lines going to the pads, be it outputs or output enables or anything like that, have any constant values optimized. If a io_oe value, for instance, is fixed at 0, instead of that being implemented in the project macro, routed on the top-level to the multiplexer where it then passes through standard cells to the output, the constant is instead resolved inside the multiplexer RTL to remove all that overhead.

09:37

Yielding better top-level density and timings.

09:38

Image attachment

09:38

Like this

09:38

Actually, this may be a better example

Image attachment

09:39

So its not as easy as generating a case-block where each entry is

5'hxx: begin
  io_oe_sel = designname_oe;
  io_out_sel = designname_out;
  io_cs_sel = designname_cs;
  etc

(edited)

09:40

Still, I think this is automatable with enough effort.

09:41

This is a really good setup for sharing die space between a low number of designs, like 4 or 5

09:41

Its, like, in-between TinyTapeout and utilizing the full die.

2

09:42

I could get to work on this if there is demand for a automatic, small-scale multi-project setup.

1

@Tholin - Offer still stands to put Avalon on the wafer.space design-help page -- maybe it could be focused on "help groups share multiple designs in one slot" type thing?

I mean, I at the very least have a LOAD of reference designs.

12:02

Soon even analog stuff

Tim 'mithro' Ansell

@Tholin - Offer still stands to put Avalon on the wafer.space design-help page -- maybe it could be focused on "help groups share multiple designs in one slot" type thing?

Also, might be worth mentioning in the profile update that @Andrew Wingate is doing for me?

Tim 'mithro' Ansell

Also, might be worth mentioning in the profile update that @Andrew Wingate is doing for me?

Sure!

Unfortunately, time is tight for me now, so I will definitely not get started on an automated multi-project setup until after december.

Tholin

Unfortunately, time is tight for me now, so I will definitely not get started on an automated multi-project setup until after december.

I mean a "contact Tholin if you are interested in XYZ" type thing?

Probably not. That sounds like it could easily become too stressful on me.

Tim 'mithro' Ansell

I had hope to do something like that, but need to have some designs people want to buy first

I don't know if @Leo Moser (mole99) is planning to port greyhound, but something like that on a breakout would be interesting for me to buy as a hobbyist. Mosbius too.

My next multi-project die is going to include a few things for homebrew computer builders.

1

RebelMike

I don't know if @Leo Moser (mole99) is planning to port greyhound, but something like that on a breakout would be interesting for me to buy as a hobbyist. Mosbius too.

I won't be porting Greyhound just yet, but I'll start with an FPGA. Just need to find the time for it while preparing the reticle :)

1

I’m thinking - arranging the macros of my multi-project die is a bit tedious to make sure there is enough spacing. I extended my padout graphic generator to also draw the macros, but even then, its a lot of tweaking values in the config and re-running the generator until I happen to get it right. But I wonder if I could turn the padout generator into an interactive UI where you can click and drag the macros with your mouse?

Image attachment

Does magic not automatically generate a PR_bndry when streaming out GDSII? It didn’t for one of my analog macros.

In any case, setting the bounding box manually works and I now have DACs in my submission.

you need the FIXED_BBOX property and then it will.

Image attachment

15:55

I just add DACs to this column as I need them

15:56

The outputs are not wired up to the analog pads yet because something broke and I’m still trying to figure it out.

15:59

I am going to create a layout for an op-amp next. Already have a schematic for it. I wanna use op-amps inside one of my peripherals, but I’ll also wire one straight to three analog pads for testing.

16:02

I also wanna see if I can generate a VGA signal, but using actual analog outputs for the colors.

Definitely need some big drivers if you're planning direct drive. Each color signal is ~ 14 mA peak.

Probably not that. We’ll see.

@ᵖʳᵒᵖᵖʸ - See @Tholin's multi-project stuff above. (edited)

How likely is it that the first run actually happens? The Crowdsupply page shows only 13% funding, and the announcement about reaching out if you're planning to buy a slot makes it seem like it's currently unlikely to happen? And if that were the case, would there be another attempt at a later date, or would that be the end of wafer.space? (edited)

@Tim 'mithro' Ansell

@Leon - The run will 100% be happening

03:41

@Leon - I'm committed to running atleast two GF180MCU runs

03:42

Getting enough people purchasing slots is important to getting us beyond these first two runs

1

That's really great to hear, but it might be useful to clarify that on the website somewhere? Usually when a crowdfunding goal isn't reached, that means the project doesn't happen, so the "13% funded" on the Crowdsupply page might be deterring people from making plans to use wafer.space? (I'm just guessing though, I know very little about chip design and am just an interested spectator hoping for your success.)

It’s a bit different to a normal crowdfund because the thing you’re buying is only worth something if you’ve completed a design yourself. Doing that will take weeks and most people wouldn’t have started until after the start of the campaign. So it makes sense that most of the purchases will come in at the last minute.

RebelMike

It’s a bit different to a normal crowdfund because the thing you’re buying is only worth something if you’ve completed a design yourself. Doing that will take weeks and most people wouldn’t have started until after the start of the campaign. So it makes sense that most of the purchases will come in at the last minute.

So it makes sense that most of the purchases will come in at the last minute.

Of course, but that also means you only know if the project reaches the funding goal at the last minute. With the usual crowdfunding model (where projects without sufficient funding are cancelled), that means people have to commit to spending time and resources without knowing if they can actually have the designs produced. I imagine there are potential customers not willing to do this, for whom it would be highly relevant to know that the first two runs are certain to happen. (edited)

3

So, my multi-project tapeout is going to have a series of DACs on it and I wish to see if I can use three of them to generate a VGA signal directly. But I don’t wanna display just frames of solid color. Anyone have an existing VGA Demo from TT they’d be okay with me using for testing purposes?

Happy to contribute https://github.com/TinyTapeout/tt-logo-screensaver

GitHub - TinyTapeout/tt-logo-screensaver: DVD-style screen saver wi...

DVD-style screen saver with the Tiny Tapeout logo and Gamepad Pmod support - TinyTapeout/tt-logo-screensaver

1

17:02

But all TT projects are permissively licensed, so you can choose virtually any project

17:03

There are many cool projects from the TT08 demoscene compo: https://tinytapeout.com/competitions/demoscene-tt08-entries/

TT08 Demoscene Entries - Tiny Tapeout

All the entries to the TT08 demoscene competition

urish

Happy to contribute https://github.com/TinyTapeout/tt-logo-screensaver

That's nice and colorfull! Perfect!

2

ttlogo

3

Overhauling my DAC in multiple ways right now. It doesn’t actually quite work as it is right now.

13:46

Resistors too small. Even a buf_20 cell cannot drive the DAC as it is.

13:47

Did an oopsie and used the wrong kind of resistor.

13:47

Its very confusing how many of them there are.

Since I have a working opamp now, may as well use it. Here’s old vs. new.

Image attachment

1

14:20

Previous version just used a FET

Oh man, am I going to need some massive transistors in that opamp just to drive a 1Kohm load on the output.

What does "number of fingers" do? If I change it from 1, nothing changes about the simulation output.

It's in how many finger the W you indicated will be split during layout.

Oh, so it doesn’t automatically multiply the W by nf?

It does change some things subtly but it's mostly when trying to match devices or changing the capacitance and such, you wouldn't really see it much in the kind of graphs you're plotting.

15:03

No, the W is the total W, not the finger W.

Ah

15:03

Because I am trying to multiply W

15:04

While keeping the shape of the FET in the layout managable

Well you can inrease nf buf you also need to increase W.

I guess I just have to do it by hand

15:07

Actually, it doesn’t like that

Image attachment

15:08

If the total W gets too high, it breaks.

The models only support a W up to a certain size. You need to change the multiplier instead.

1

That’s a lot of very large transistors.

Image attachment

15:47

This is gonna take a minute

I’ve found that trying to set up my opamps as voltage followers (output connected to MINUS, source voltage into PLUS) strangely doesn’t work. But building an inverting amplifier with a little bit of gain does.

Image attachment

16:37

No idea why

16:37

Don’t question the component name.

My main problem with that schematic is not that the op-amp is chonky (chonky is in the eye of the beholder!) but that you have some pretty high currents for an on-chip amplifier. On-chip circuits are usually meant to drive microamps, not milliamps. Driving an off-chip load does require some beefy components, but with the right amp design, you can restrict the beefy components to just the output driver, and most of the rest of the amplifier will be reasonbly small. A voltage follower is generally easier to get working than an inverting amplifier (all the drive current goes to the load), so it's probably a good idea to look closely at what's causing that configuration to fail. Finally, a current bias is much better than a voltage bias, and if it's really taking a voltage bias, then you shouldn't need a milliamp current path through your voltage divider to set it.

18:04

@Tholin : Feel free to post the amplifier schematic, or a link to the project. (edited)

Note: resistor values are not yet properly tuned, I only care about the ratios so far.

18:16

But yeah, this is meant to drive a pad.

18:18

I should share the schematic for the opamp sometime.

Image attachment

I also wouldn't count too much on that working like in sim. I'm not expert, but biasing the gate of mosfet with a resistor divider seems like it could yield quite a bit of process variation.

20:47

Why is the gate and drain of XM6 connected together ?

Leo Moser (mole99)

The models only support a W up to a certain size. You need to change the multiplier instead.

Shouldn't the model only care about the finger width and not the total width ?

tnt

I also wouldn't count too much on that working like in sim. I'm not expert, but biasing the gate of mosfet with a resistor divider seems like it could yield quite a bit of process variation.

I second this. For the "adj" pin, you should definitely consider using a replica biasing scheme.

21:11

Even if your resistors are ratiometrically designed, your mosfet threshold voltage, mobility, Cox etc... will all change under process. Since mosfets have gain, you'll have a trouble keeping the bias currents the same. across chip-chip or even from one part of the chip to another.

Tholin

Click to see attachment 🖼️

the first stage of the amplifier can definitely be a lot smaller (length and width wise)... it seems like one side of the differential pair (and current mirror) is not equal to the other? These should be the same otherwise you will have systematic offset in your circuit.

Don’t worry - I can explain all this very easily.

21:21

I don’t know what I’m doing

21:21

Analog stuff is so inaccessible still flop

flop

21:23

Also, yeah, I do have some weird offsets

I played with the transistor values until the output looked good. And I simulated it across all process corners and there is very little variance.

Been working on a 500x300 black and white camera, and I finally got the pixel array done. All done in gdsfactory https://github.com/njcoburn/OPENIMAGESENSOR/blob/main/test.py

Image attachment

Image attachment

OPENIMAGESENSOR/test.py at main · njcoburn/OPENIMAGESENSOR

OPENIMAGESENSOR - An open source image sensor. Contribute to njcoburn/OPENIMAGESENSOR development by creating an account on GitHub.

1

blobclap

2

1

1

Very cool! Do I see round corners on the photodiode? Do the docs have DRC guidelines on that?

I built a better opamp after doing some research. This one is almost rail-to-rail!

Image attachment

11:02

And will only need two big transistors.

11:03

The other opamp I designed I may keep the non-chonky version of for internal use on the die. It has some properties that made it easier to use for building that sine wave generator I showed a long time ago.

It behaves okay enough under a 1Kohm output load, so I think I’ll move ahead to the layout stage with this one.

12:25

Still a massive output stage just to drive a 1Kohm load. Am I doing this right?

Image attachment

Check the size of the transistor in the IOs. They can drive a 1kohm load with no problem, so if you're bigger than they are, you're doing something wrong.

12:42

Also post the new internal schematic of your op amp.

Oh, right

Image attachment

12:44

It looks a little weird on the right, having duplicated the transistors in the schematic. But its so that importing the SPICE into magic generates the transistors how I want them.

Tholin

I built a better opamp after doing some research. This one is almost rail-to-rail!

Since this thing at least works really good in this configuration, I do wonder if a IO pad structure specifically meant for analog output that contains this circuit would be something people would want to use. It just takes whatever analog signal comes in and boosts it to be able to drive 1kohm loads. (and inverts it, but that can be solved with a second opamp).

I don't know the tools you are using, but many of them will let you get multiple instances in the same way by using InstanceName<N:0> to get N+1 instances of the transistor in the netlist and layout. I would try it in the schematic then check the netlist to see if it works in your toolchain.

I can do this, but it stacks the transistors in a way I don’t like.

So I think one issue might also be expecting it to be rail to rail using that architecture. Inherently that basic op-amp can never be and maybe you're massively oversizing the transistor to get it closer to rail and compensate for a fundamental limit of the architecture.

What might also be worth investigating is using shorter cascoded transistors. Shorter channels will give the same gm with shorter widths, and the cascode will raise the output impedance with lower Vds

12:52

With this process you can also probably interdigitate the two transistors for a very compact layout.

tnt

So I think one issue might also be expecting it to be rail to rail using that architecture. Inherently that basic op-amp can never be and maybe you're massively oversizing the transistor to get it closer to rail and compensate for a fundamental limit of the architecture.

Oh, yeah, I stopped making the transistors larger when I hit an area of diminishing returns. But if I make them any smaller, there is a big difference in the output still. What is nice is that its effectively rail-to-rail when used internally, not to drive an output pad.

See how this for instance use symmetrical Nmos/Pmos input pairs and then combine them to increase the range : https://www.xschem-viewer.com/?file=https://github.com/htfab/flash-adc/blob/main/xschem/opamp.sch Obviously this is single stage so you'd still need to drive a power stage instead.

That xschem viewer doesn’t work on firefox

https://github.com/htfab/flash-adc/blob/main/xschem/opamp.sch then

tnt

See how this for instance use symmetrical Nmos/Pmos input pairs and then combine them to increase the range : https://www.xschem-viewer.com/?file=https://github.com/htfab/flash-adc/blob/main/xschem/opamp.sch Obviously this is single stage so you'd still need to drive a power stage instead.

That is for increased input common-mode range (as needed in a unity-gain non-inverting amplifier), but doesn't do anything for output swing.

Oh yeah, I thought it was setup as a non-inverting buffer to buffer the R2R output, my bad. Rechecking the way it's used, it's indeed inverting and will mainain both input at mid range.

tnt

Oh yeah, I thought it was setup as a non-inverting buffer to buffer the R2R output, my bad. Rechecking the way it's used, it's indeed inverting and will mainain both input at mid range.

Although if the intention is to produce a general-purpose op-amp, then it is a point worth considering in the design.

Tholin

Oh, right

Given you have two gain stages now with the diff amp, you have 3 poles which could be close to each other… make sure everything is stable when you build it with feedback too

Oh never mind, they seem to be in parallel… regardless it is still something to consider

Leo Moser (mole99)

Very cool! Do I see round corners on the photodiode? Do the docs have DRC guidelines on that?

The docs do not have drc guidance on that, but it didn't trigger any rules so I assume it's okay. The nwell is 5x5um so I assume it's large enough to not matter

Ethan Mahintorabi

The docs do not have drc guidance on that, but it didn't trigger any rules so I assume it's okay. The nwell is 5x5um so I assume it's large enough to not matter

It might be okay, it might also be a missing check :) I only found the following in 3.0 Layout Information:

3.6 Only 90 deg and 45 deg bends are allowed for poly and metal lines.

So I assume that for nwell round coners are okay (as long as all points are on-grid). If you have a complete chip layout, please let me know and I can already include it in the reticle to send to GF for early feedback.

Leo Moser (mole99)

It might be okay, it might also be a missing check :) I only found the following in 3.0 Layout Information:

3.6 Only 90 deg and 45 deg bends are allowed for poly and metal lines.

So I assume that for nwell round coners are okay (as long as all points are on-grid). If you have a complete chip layout, please let me know and I can already include it in the reticle to send to GF for early feedback.

Do you need a full pad frame with density fill or can I just send you a gds with the pixel array fitting into the die area

15:47

Or I could just send you some rounded nwell

Ethan Mahintorabi

Been working on a 500x300 black and white camera, and I finally got the pixel array done. All done in gdsfactory https://github.com/njcoburn/OPENIMAGESENSOR/blob/main/test.py

this looks amazing! have you been doing simulations to check functionality, or just YOLO'ing it? And if yes, how? That's the part that I really stumbled on when thinking about doing an imager

@Andrew Wingate Great post, Andrew! https://www.crowdsupply.com/wafer-space/gf180mcu-run-1/updates/chip-on-board

Community Progress on Chip-on-Board Packaging Strategy

The wafer.space community is developing a flexible chip-on-board packaging strategy, so you won't need specialized equipment or expensive packaging services to use your chips.

3

Ethan Mahintorabi started a thread. 11/11/2025 20:13

urish started a thread. 11/11/2025 20:39

All I did was try to include my opamp in another circuit and magic went and reset the positions of the transistors AND saved the changes to the .mag file without asking for confirmation. Why? Why did magic just destroy my work?

Image attachment

Tholin

All I did was try to include my opamp in another circuit and magic went and reset the positions of the transistors AND saved the changes to the .mag file without asking for confirmation. Why? Why did magic just destroy my work?

I guess you can blame me for that one. the SPICE import function is supposed to be re-entrant, letting you add, subtract, or change devices without messing with the existing layout. Apparently that doesn't work?

Hi, All. We, ISHI-KAI( https://ishi-kai.org/links ), are a community that promotes open source PDK & EDA in Japan. This time, we brought together 14 novice semiconductor designers (most of whom were new to semiconductor design), each of whom created an analog circuit, such as an Inverter or OPAMP, ADC, PLL, BGR, CS, made using xschem & klayout with P-Cells for Wafer.Space GF180MCU . All schematics and layouts are released under an open source license.

Our Project

https://github.com/ishi-kai/ISHI-KAI_Multiple_Projects_WaferSapce-GF180-1 This is the development environment for analog circuits we used for Wafer.Space. Feel free to use it if needed.

WSL Image

https://www.noritsuna.jp/download/ubuntu2404_waferspace_2025.zip ID:ishikai Pass:ishikai

How to Setup

Execute on the Windows command line

cd [Unzipped directory] wsl --import-in-place ubuntu2404_waferspace_2025 .\ubuntu2404_waferspace_2025\ext4.vhdx

How to Use

Execute on the Windows Double-click ubuntu2404_waferspace_2025.lnk

How to Delete

Execute on the Windows command line

cd [Unzipped directory] wsl --unregister ubuntu2404_waferspace_2025

How to Run precheck

Execute on the WSL command line

cd ~/tools/gf180mcu-precheck/ nix-shell export PDK=gf180mcuD export PDK_ROOT=gf180mcu python3 precheck.py --input [GDS file] --top [Top Cell Name]

Setup script for xschem & ngspice, magic, KLayout fo Wafer.Spice GF180 of Analog on Local WSL&Ubuntu&MacOS

https://github.com/ishi-kai/OpenEDA-PDK_SetupScript

How to Setup

git clone https://github.com/ishi-kai/OpenEDA-PDK_SetupScript bash eda-setup.sh bash pdk_gf180-setup.sh

(edited)

1

Leo Moser (mole99) started a thread. 11/13/2025 10:11

Oh! I can use this as the analog output VGA demo on my multi-project die.

Once I am no longer busy preparing a chip layout for the december tapeout, I am planning to spend the following months (while the fab is busy) on two things. Firstly, my custom 3.3V standard cells (including IO pad structures for 3.3V IO). Secondly, a general-purpose, easy to use toolset for creating multi-project dies. I want to make it as simple as defining a project list in a CSV and dropping it plus the source RTL for each project into a repository template, and the whole multiplexer and top-level setup is auto-generated. It would not be as advanced as TinyTapeout, but more dynamic. Better for when the die is only to be split 4 or 5 ways, with each project having a variable size, so you can do crazy splits like a 3 project die where 90% of available area goes to to project #1 and 5% to #2 and #3 each. For bonus points, I may create a GUI for managing the project list, settings and macro arrangement.

3

2

It's old and unmaintained but maybe there are some ideas you can take from my old https://github.com/mattvenn/multi_project_tools

GitHub - mattvenn/multi_project_tools: tools to help make the most ...

tools to help make the most of the limited space we have on the Google sponsored Efabless shuttles - mattvenn/multi_project_tools

Another CrowdSupply post. This time featuring @Tholin https://www.crowdsupply.com/wafer-space/gf180mcu-run-1/updates/tholin-feature

We Have Some Amazing Projects This Run

Our first shuttle run includes a number of incredible projects, and we wanted to take a moment to highlight one of them: an open reimplementation of the historic Signetics 2650 microprocessor.

2

2

I got distracted and accidentally created https://discord.wafer.space archive of the discord server

wafer.space Discord Logs

Public archive of wafer.space Discord server

Triangle and sine/cosine wave generators work much better with the new opamp design.

Image attachment

I wish there was time to get the NTSC color video generator demo going in time for the december tapeout, but I don’t think there is.

1

21:57

Sad.

Update: Work on the 3.3V SRAM block is progressing steadily. I was hoping to finish layout at the end of last week, but it ran over into the weekend. I now have a draft layout, DRC clean, but I have not run LVS yet (will work on that tomorrow) The design is currently about 300 x 330 um, which makes it just slightly less than 1/2 the area of the 5V SRAM. I have some room to shave off additional area from the bottom. I can probably get it down to 300 x 300, but probably don't have time to do that for this tapeout. Once I get it LVS clean, I will push the layout, netlist, and LEF. Adjusting all the timing in the liberty and verilog files will take a lot of time and effort.

3

4

02:36

I would post a picture but it looks just like the 5V SRAM layout from a bird's-eye view, so not really worth the effort.

urish started a thread. 11/17/2025 07:16

@Leo Moser (mole99) How is your ground ring connected to the pads in the template ?

10:14

Maybe it didn't build properly for me locally but I'm looking at it and I can't find anywhere where it's attached.

tnt

@Leo Moser (mole99) How is your ground ring connected to the pads in the template ?

LVS is clean, so it better be attached

Let me check...

Could be attached through substrate ...

Oh, I see

10:18

It's only attached to the top and bottom ground pad

10:19

The reason is, I made changes to the template and now gf180mcu_fd_io__dvss is used for all ground pads instead of my modified gf180mcu_ws_io__dvss which has pins on two metal layers.

10:20

I think there should be no issue with gf180mcu_ws_io__dvss for both horizontal and vertical I/O rows.

10:21

Thanks a lot for alerting me!

1

I hadn't see the one on top and bottom because I forgot I had added those in the padframe

1

10:25

Although I have my rings on Metal5 / Metal4 so I'm not sure how that's going to help me

Yeah, that's another issue

Crunched all weekend...I think I just might make the tapeout deadline! need to add more tests to the bootloader and uart interface, but if I can convince myself that's working my entry is probably ship'able whenever

2

BreakingTaps

Crunched all weekend...I think I just might make the tapeout deadline! need to add more tests to the bootloader and uart interface, but if I can convince myself that's working my entry is probably ship'able whenever

Feel free to ask if you get stuck at any point in the process.

thanks! might take you up on that once I start integrating into the project template

1

urish started a thread. 11/18/2025 10:43

Important notice regarding the foundry SRAM models ‼️ If you're as innocent as me, you might think that the meaning of the SRAM control signals is as follows:

CEN = Chip Enable
GWEN = Global Write Enable
WEN = Write Enable

Far from it! The real meaning is actually:

CEN = Chip Enable Negative
GWEN = Global Write Enable Negative
WEN = Write Enable Negative

All of the control signals need to be negated. (I would have preferred CEB, GWEB and WEB...) Another pitfall: in order for the SRAM model to work, it needs to see a falling edge on CEN. Therefore, you cannot start the simulation with CEN low. Thank you for your attention

3

Oh that's just mean.

1

1

Leo Moser (mole99)

Important notice regarding the foundry SRAM models ‼️ If you're as innocent as me, you might think that the meaning of the SRAM control signals is as follows:

CEN = Chip Enable
GWEN = Global Write Enable
WEN = Write Enable

Far from it! The real meaning is actually:

CEN = Chip Enable Negative
GWEN = Global Write Enable Negative
WEN = Write Enable Negative

All of the control signals need to be negated. (I would have preferred CEB, GWEB and WEB...) Another pitfall: in order for the SRAM model to work, it needs to see a falling edge on CEN. Therefore, you cannot start the simulation with CEN low. Thank you for your attention

( @BreakingTaps )

1

will check my code when I get home, cheers for the note!

1

Leo Moser (mole99)

Important notice regarding the foundry SRAM models ‼️ If you're as innocent as me, you might think that the meaning of the SRAM control signals is as follows:

CEN = Chip Enable
GWEN = Global Write Enable
WEN = Write Enable

Far from it! The real meaning is actually:

CEN = Chip Enable Negative
GWEN = Global Write Enable Negative
WEN = Write Enable Negative

All of the control signals need to be negated. (I would have preferred CEB, GWEB and WEB...) Another pitfall: in order for the SRAM model to work, it needs to see a falling edge on CEN. Therefore, you cannot start the simulation with CEN low. Thank you for your attention

this is diabolical, these signals were clearly named by someone who got paid off by Big ECO

2

This is normal, wait til you see pads where the output data is called I

23:08

as in Into the pad (going out of the chip)

1

Leo Moser (mole99)

( @BreakingTaps )

I assume there is no way to verify people are doing things correctly in the precheck.

Tim 'mithro' Ansell

I assume there is no way to verify people are doing things correctly in the precheck.

@Tim 'mithro' Ansell for the chipIgnite shuttle, we implemented an oeb check that would check the connections and logic values at the user - gpio interface and report discrepancies like output signals without oeb connections, output signals with high oeb etc. Given sufficient specs, I might be able to come up with something using my CVC-RV to examine the port signals and their connections.

bailey

@Tim 'mithro' Ansell for the chipIgnite shuttle, we implemented an oeb check that would check the connections and logic values at the user - gpio interface and report discrepancies like output signals without oeb connections, output signals with high oeb etc. Given sufficient specs, I might be able to come up with something using my CVC-RV to examine the port signals and their connections.

We should probably update the IP to be named something like CE_N or something....

3

Can people see/access test-platform.wafer.space?

It keeps loading for a long time

urish started a thread. 11/19/2025 06:51

Another update, this time featuring @peterkinget and Mosbius. There's also an interesting interview posted with @Matt Venn talking about his project https://www.crowdsupply.com/wafer-space/gf180mcu-run-1/updates/mosbius

We Have Some Amazing Projects This Run: MOSbius

This week we highlight MOSbius, an educational platform from Columbia University bringing hands-on silicon learning to students worldwide.

3

Tholin

Once I am no longer busy preparing a chip layout for the december tapeout, I am planning to spend the following months (while the fab is busy) on two things. Firstly, my custom 3.3V standard cells (including IO pad structures for 3.3V IO). Secondly, a general-purpose, easy to use toolset for creating multi-project dies. I want to make it as simple as defining a project list in a CSV and dropping it plus the source RTL for each project into a repository template, and the whole multiplexer and top-level setup is auto-generated. It would not be as advanced as TinyTapeout, but more dynamic. Better for when the die is only to be split 4 or 5 ways, with each project having a variable size, so you can do crazy splits like a 3 project die where 90% of available area goes to to project #1 and 5% to #2 and #3 each. For bonus points, I may create a GUI for managing the project list, settings and macro arrangement.

Looking forward!

I have a perfectly working layout for a fast DAC now. So why not make an NTSC video generator?

Image attachment

3

19:49

Literally 20 lines of RTL

19:49

Pretty cool

@Tholin - How about a 640x480 HDMI output?

Possible with the ADV7513

The pixel clock for an HDMI connection at 640x480 resolution is approximately 25.175 MHz. -- 10bits per pixel makes it 250MHz needed at the I/O

Image attachment

22:01

Image attachment

22:02

HDMI PMOD is 100% feasible

@Tholin - I'm very familar with those Analog Devices parts

for 60 Hz it's exactly 25.2 MHz -- for some reason the NTSC colour subcarrier -0.1% thing has made its way into digital standards too

22:14

Simple DDR out running at 126 MHz would do it, the problem is just the pad libraries and the clock source

22:15

you can drive 252 Mbps with a clean eye mask with just a 3.3V CMOS push/pull GPIO on a microcontroller and a 270 ohm resistor to set the current level

22:16

I'm also interested in your NTSC DAC as I'm making a games console

roughly GBA-competitive in terms of graphics and CPU

22:16

would be awesome to play on a CRT

LukeW

for 60 Hz it's exactly 25.2 MHz -- for some reason the NTSC colour subcarrier -0.1% thing has made its way into digital standards too

(it's just 800 x 525 x 60 = 25.2e6)

i'm also interested in the NTSC logic for game console reasons, I'm working on an NES clone atm

https://github.com/AvalonSemiconductors/ws-submission-2025/blob/main/macros/NTSCTest/src/ntsc.v

ws-submission-2025/macros/NTSCTest/src/ntsc.v at main · AvalonSemi...

Multi-project die. Contribute to AvalonSemiconductors/ws-submission-2025 development by creating an account on GitHub.

Tholin

https://github.com/AvalonSemiconductors/ws-submission-2025/blob/main/macros/NTSCTest/src/ntsc.v

Ooh so the DAC is R2R with current steering through the 2Rs? I never looked into how DACs are actually implemented before, that's very cool

12:53

Would be great for VGA too. We're a bit too pad-limited for external ladder DACs.

12:54

Annoyed I already assigned all my pads to digital IOs

I am going to test if its good for VGA also

1

12:55

Though right now I am still battling LibreLane

12:55

It is refusing to route the outputs of the DACs to the analog pads.

LibreLane: "it's not a one or a zero therefore it cannot hurt me."

This is weird. My analog pads aren’t being routed, but the netlist that comes out of detailed routing claims they are connected.

15:10

@Leo Moser (mole99) Are the analog pads getting routed in the unmodified template?

@Tholin The template does not connect the analog pads to anything. So no, they aren't routed.

Ah

15:23

Well

15:23

I am connecting them to something and they still don’t route.

15:24

Triggering an obvious LVS error

In the worst case, you could hardcode the port types as inputs and outputs. A proper solution would of course be better. I haven't tried to route inout ports yet, maybe you need to convince OpenROAD's GRT/DRT in some way to do that.

Already tried that. Actually did a lot of modifications to the PDK files to try and get it to route, but no luck.

Is your project somehwere online we can look at ?

https://github.com/AvalonSemiconductors/ws-submission-2025

GitHub - AvalonSemiconductors/ws-submission-2025: Multi-project die

Multi-project die. Contribute to AvalonSemiconductors/ws-submission-2025 development by creating an account on GitHub.

You can try to use the ef bi IO that have the analog port added and see if it connects better to that.

17:02

not ideal, but if that works, at least it'll narrow the issue.

@Tholin So I can see the connections in the system verilog. What about the synthesized gate level verilog? Can you see the analog connections there?

Yes

19:08

The connections are even still present in the netlist post route.

1

I know a lot of people do retro stuff so they probably disagree, but I find that having the default settings of librelane be 5V instead of 3.3V is a bit annoying

1

tnt

I know a lot of people do retro stuff so they probably disagree, but I find that having the default settings of librelane be 5V instead of 3.3V is a bit annoying

I feel you. Including the libs for KianV was some work. But I would argue that the foundry-provided stdcells shouldn't really be used at 3.3V, as they are really bad for that

Once we have a confirmed working 3.3V stdcell library, we can discuss setting it as the default for gf180mcu.

They're really not that bad at 3.3V. I wouldn't use them at 1.8V even if they have specs for that, but at 3.3V they're a bit slower but still very much usable.

09:52

Will the first run include foundry biased wafers ( ss / sf / fs / ff ) with test structures for new standard cells to allow proper validation ?

When I run nix-shell in the template and then magic, I expected magic to load the gf180mcuD PDK, but it instead loads with sky130A. I cannot figure out how to get it to gracefully load the gf180mcuD PDK, so I keep having to go back to iic-osic-tools for analog layout.

tnt

Will the first run include foundry biased wafers ( ss / sf / fs / ff ) with test structures for new standard cells to allow proper validation ?

I didn't know the foundry could create biased wafers on purpose. I thought that just happens due to process variations, and the wafers are sorted afterwards based on the measurements of the test structures? As for your question, I don't think so. First, we would need to pick a stdcell library (or more) to characterize. There is Tholin's library, for example, and the FlexCell library. I tried to PnR Staf's FlexCell library, but I had to stop at routing due to some issues. Also someone need to do the work of creating a chip with these libraries for characterization. @Tim 'mithro' Ansell no one is working on that atm, correct?

Tholin

When I run nix-shell in the template and then magic, I expected magic to load the gf180mcuD PDK, but it instead loads with sky130A. I cannot figure out how to get it to gracefully load the gf180mcuD PDK, so I keep having to go back to iic-osic-tools for analog layout.

Did you export PDK_ROOT and PDK and pass the rcfile to magic?

@Leo Moser (mole99) I didn't know either, I only learned about that recently. I guess they can tweak parameters and then validate using their own test structure that they hit the target and where that wafer ends up

1

Leo Moser (mole99)

Did you export PDK_ROOT and PDK and pass the rcfile to magic?

magic crashes

10:04

No, -d OGL is what crashes it, my bad

Leo Moser (mole99)

I didn't know the foundry could create biased wafers on purpose. I thought that just happens due to process variations, and the wafers are sorted afterwards based on the measurements of the test structures? As for your question, I don't think so. First, we would need to pick a stdcell library (or more) to characterize. There is Tholin's library, for example, and the FlexCell library. I tried to PnR Staf's FlexCell library, but I had to stop at routing due to some issues. Also someone need to do the work of creating a chip with these libraries for characterization. @Tim 'mithro' Ansell no one is working on that atm, correct?

We also have the problem of no 3.3V-optimized IO pads. I will create some eventually as part of my SCL, but not in less than two weeks. Next shuttle. Actually, I’ve had to pause work on my SCL so I can participate in this shuttle and have something ready in time. Sorry.

Tholin

We also have the problem of no 3.3V-optimized IO pads. I will create some eventually as part of my SCL, but not in less than two weeks. Next shuttle. Actually, I’ve had to pause work on my SCL so I can participate in this shuttle and have something ready in time. Sorry.

Don't be sorry, that's super exciting work

Yeah, 3.3V I/Os would also be great!

Tholin

magic crashes

magic: ## Open magic with the gf180mcuD PDK
    PDK_ROOT=${PDK_ROOT} PDK=${PDK} magic -rcfile ${PDK_ROOT}/${PDK}/libs.tech/magic/gf180mcuD.magicrc
.PHONY: magic

This should work.

I am cheating a bit. I took gf180mcu_fd_io__bi_24t, flattened some of it and just deleted the DUALGATE layer. Next step would’ve been to go through and shrink the transistor lengths, since the 3.3V transistors have a way shorter minimum length. Note that this produces a 3.3V only pad, not a pad with separate core and IO voltage supporting both.

1

10:13

The biggest struggle and time-sink would be characterization.

TBH for IO pads, I intend to keep the 5V rated ones since 5V compat is good to keep for TT. Although I'd switch to the split core/io voltage ones of course. And speed wise they're only about 30% slower.

1

I don’t think I can rely on lctime anymore.

10:13

I like using lctime because I’ve read most of its code and understand it, but its limited and simplistic.

Well, there's some talks about performance optimizations at least: https://codeberg.org/librecell/lctime/issues/38

Potential performance improvement

I had a discussion with Holger from NGSpice about how we could improve the speed for characterization, and got the following feedback: "For standard cell characterisation, where we have lots of very similar simulations, where each simulation takes relatively few time and the simulation setup and ...

tnt

@Leo Moser (mole99) I didn't know either, I only learned about that recently. I guess they can tweak parameters and then validate using their own test structure that they hit the target and where that wafer ends up

You can overdope and over expose and do things like that.

Leo Moser (mole99)

I didn't know the foundry could create biased wafers on purpose. I thought that just happens due to process variations, and the wafers are sorted afterwards based on the measurements of the test structures? As for your question, I don't think so. First, we would need to pick a stdcell library (or more) to characterize. There is Tholin's library, for example, and the FlexCell library. I tried to PnR Staf's FlexCell library, but I had to stop at routing due to some issues. Also someone need to do the work of creating a chip with these libraries for characterization. @Tim 'mithro' Ansell no one is working on that atm, correct?

I was trying to convince Mehdi's group to do the same thing as their SKY130 test tile for GF180MCU -> https://github.com/google/skywater-pdk-sky130-raw-data/tree/main/docs/sky130-testtile-open

skywater-pdk-sky130-raw-data/docs/sky130-testtile-open at main · g...

Raw data collected about the SKY130 process technology. - google/skywater-pdk-sky130-raw-data

I wonder if the issue LibreLane has with the analog pads is that they have no separate pins for the pad and signal input. All the IO pads have a separate PAD pin in their definition, except the analog pads, which just have ASIG5V.

11:57

I’m gonna experiment.

1

Update: works

13:25

I will let this flow finish, though, to ensure there is no LVS errors left.

13:25

But it appears that gf180mcu_fd_io__asig_5p0 has some broken port definitions.

Or OpenRoad has a bug that's triggered by whatever they're using

13:33

Because looking at the LEF I didn't really see anything wrong about it

The mag has some weird stuff going on

Image attachment

13:36

The ports that are missing the signal bidirectionalare actually duplicates of ports that do have those parameters.

13:36

Idk

13:36

Removing the broken-looking ones fixed it

The mag shouldn't be used by OpenRoad at all.

Yeah, but I generated the lef and GDSII from that mag

13:38

Oh, I also added a PAD port

13:38

And updated the verilog and lib to reflect this

Tholin

Oh, I also added a PAD port

@Tholin if you added a PAD port to the analog io cell, wouldn't that short with the ASIG5V port?

Yes

13:41

PAD and ASIG5V are still one and the same

13:42

But somehow it makes a difference having both names assigned to it.

Is your current "built" GDS somewhere ? (The repo doesn't use github action so I can't just download what it looks like there

)

No

13:51

Its still building

13:52

A github actions pipeline would fail at this time anyways because I know it has KLayout DRC errors in the DACs.

13:52

I need to flatten them. It sees errors that aren’t there if you take in context from higher up in the hierarchy.

I took that make_gds script from the wafer.space logo IP in the project template and updated it to make it more compatible with a wider range of inputs. https://github.com/AvalonSemiconductors/ws-submission-2025/blob/main/silicon_art/make_gds.py

15:25

The input image no longer has to be in a specific pixel format.

15:25

But most importantly, I added code to automatically repair potential DRC errors.

15:26

Most common are pixels that only touch at the corner:

X_  _X
_X  X_

15:26

But one-pixel gaps are also filled on lower pixel sizes.

15:26

The script now inserts additional pixels until all such errors are gone.

2

Which is just a little hint to everyone that I’m about to have a need for converting more complex images to layouts.

1

1

Tholin

I took that make_gds script from the wafer.space logo IP in the project template and updated it to make it more compatible with a wider range of inputs. https://github.com/AvalonSemiconductors/ws-submission-2025/blob/main/silicon_art/make_gds.py

Cool!

Tholin

Which is just a little hint to everyone that I’m about to have a need for converting more complex images to layouts.

Silicon artwork?

23:58

@Tholin - We should send some to https://www.youtube.com/c/EvilmonkeyzDesignz

EvilmonkeyzDesignz

I'm a Computer Engineer that loves electronics. Video content that I post may include:

Electronics tear-downs
Component close-ups under the microscope
Circuitboard design
Anything else electronics related that I think other people might enjoy. If you are looking for more, check out my Instagram account (@evilmonkeyzdesignz) or the webs...

Okay, my modified analog pads do connect now, but also have a ton of DRC errors.

14:51

Imma see if I can’t be a bit smarter about this.

Tholin

Which is just a little hint to everyone that I’m about to have a need for converting more complex images to layouts.

Didn't the PULP team open source their artwork generator recently? I thought they did but I can't find it on their website

https://github.com/pulp-platform/artistic

GitHub - pulp-platform/artistic: An Open-Source Toolchain for Top-M...

An Open-Source Toolchain for Top-Metal IC Art and Ultra-High-Fidelity GDSII Renders - pulp-platform/artistic

Tholin

The mag has some weird stuff going on

The duplicate rlabels/ports are indeed a problem. If I don’t remove them, not only does routing fail, but the DRT has a chance of crashing.

15:54

I tried doing a diff of the .lef file with and without the duplicate labels and the coordinates of all the ASIG5V pins change slightly. Current theory: the duplicate ports are not exact duplicates, but slightly shifted downwards. If the lef is then written with -pinonly, only these shifted duplicates are exported, which occupy illegal positions. (edited)

Tholin

I tried doing a diff of the .lef file with and without the duplicate labels and the coordinates of all the ASIG5V pins change slightly. Current theory: the duplicate ports are not exact duplicates, but slightly shifted downwards. If the lef is then written with -pinonly, only these shifted duplicates are exported, which occupy illegal positions. (edited)

If you're using magic for lef generation, be sure that the bounding box FIXED_BBOX is set.

It is

1

Tholin

Which is just a little hint to everyone that I’m about to have a need for converting more complex images to layouts.

Embedded image

2

I am paranoid about the fillers messing up the silicon art, so I’ve drawn fillblock over it and duplicated the art onto every metal layer and the poly layer to provide the required density.

17:23

DRC passes with this, so hopefully its fine

Tholin

I am paranoid about the fillers messing up the silicon art, so I’ve drawn fillblock over it and duplicated the art onto every metal layer and the poly layer to provide the required density.

Can't wait to see this for real!!!

17:50

This design is ~120 µm? edit tall? (edited)

Its 700 by 583

17:53

um

17:53

quite big

Oh, I see what I'm looking at now. Mistook 2 scales for one Awesome!!

STA is really annoying me right now. Its reporting setup violations in the 100ns violations because an active design might change the output-enable or pull resistors or something on a IO pad, which triggers a change in the pad’s outputs to the core area, which kicks of timing paths through unrelated designs, which may also change output enables which changes pad outputs which triggers changes through the designs etc. etc. and so on. It "bounces" like that for up to 5 times before coming to a stop.

20:16

I need STA to disregard ANY timing paths that cross macro boundaries except the multiplexer.

20:17

Only one of these will ever be active at a time and it doesn’t get that.

20:17

I could disable STA or STA checker entirely since the setup timing analysis results are largely meaningless anyway in my use case (every design has its own fmax), but I’d like the flow to fail on hold violations.

20:18

I’d like to ignore just setup violations, but still fail on hold violations.

20:20

I tried set_false_path -from [get_ports {io_oe_.*}] and so on, but no luck.

20:20

Or is it set_false_path -from [get_ports {io_oe_*}]?

20:20

Glob or regex?

ports are external pads, so if you're running that on the top level, the ports are the actual pads since the top level include the IO cells. (edited)

20:26

And it's glob.

Thanks

20:27

Actually, because I thought it was regex, it was still trying to do timing analysis on the design select pins, which I thought I had disabled.

You can try to grab the pins on the IO cells [ get_pins "*pad/OE" ] or something.

I just looked at the very top of the STA log and then turned that into set_false_path -from [get_ports {design_sel_*}]

Image attachment

20:28

I’m just matching everything to do with design selection

If these are digital paths, something I find useful is to insert an anchor buffer in the RTL:

module falsepath_anchor (
    input  wire i,
    output wire z
);

`ifdef GF180MCU

(* keep *)
gf180mcu_fd_sc_mcu9t5v0__clkbuf_1 magic_falsepath_anchor_u (
    .I (i),
    .Z (z)
);

`else

assign z = i;

`endif

endmodule

and then just glob them out in the .sdc:

# Apply RTL-inserted false path constraints (setup/hold only, still constrain slew)
set_false_path -setup -hold -through [get_pins *.magic_falsepath_anchor_u/Z]

It's dirty but it makes the constraints a bit less fragile because you don't have to update them when hierarchy changes. Also I think paths through PD/PU can pretty much universally be falsepathed as the slew on the pad due to pulls is so slow.

Record for most violations on DRT?

Image attachment

1

Does anyone by chance have a level shifter cells for 3.3 -> 5v and vice versa. I'm about to design one to fit in the 7 track library, I can change to the 9 track though if someone already has one

@Tholin / @Tim Edwards - You'd be the people I'd guess at being most likely to have done sometihng like the above -^

04:20

BTW Can people access https://doc.test-platform.wafer.space ? (edited)

The manufacturing checking will be deployed there very shortly.

NX domain for me

Tim 'mithro' Ansell

BTW Can people access https://doc.test-platform.wafer.space ? (edited)

Yes on IPv6, no on IPv4

Ethan Mahintorabi

Does anyone by chance have a level shifter cells for 3.3 -> 5v and vice versa. I'm about to design one to fit in the 7 track library, I can change to the 9 track though if someone already has one

Also I decided I'm just going to run the whole tile at 3.3V to avoid the complexity

Tim 'mithro' Ansell

BTW Can people access https://doc.test-platform.wafer.space ? (edited)

I cannot access. DNS_PROBE_FINISHED_NXDOMAIN

IPv6 only for the next few hours.

Works for me. I knew configuring ipv6 would pay off

bailey

I cannot access. DNS_PROBE_FINISHED_NXDOMAIN

IPv4 should now work in theory.

1

Ethan Mahintorabi

Does anyone by chance have a level shifter cells for 3.3 -> 5v and vice versa. I'm about to design one to fit in the 7 track library, I can change to the 9 track though if someone already has one

I made a level shifter for the I/O cells here: https://github.com/RTimothyEdwards/gf180mcu_ocd_io/; specifically, see https://github.com/RTimothyEdwards/gf180mcu_ocd_io/blob/main/magic/lvlshift_up.mag. However, this was designed to fit in the existing I/O cells, not the standard cells, so it's not pitch-matched to any standard cell library. To level-shift down, I generally just use a 5V inverter powered at 3.3V, although if you want it matched to a standard cell library, then the 5V rail should bias the nwell (which will be connected to other 5V standard cell nwells) and the 3.3V supply to the inverter should be a separate pin.

Tim Edwards

I made a level shifter for the I/O cells here: https://github.com/RTimothyEdwards/gf180mcu_ocd_io/; specifically, see https://github.com/RTimothyEdwards/gf180mcu_ocd_io/blob/main/magic/lvlshift_up.mag. However, this was designed to fit in the existing I/O cells, not the standard cells, so it's not pitch-matched to any standard cell library. To level-shift down, I generally just use a 5V inverter powered at 3.3V, although if you want it matched to a standard cell library, then the 5V rail should bias the nwell (which will be connected to other 5V standard cell nwells) and the 3.3V supply to the inverter should be a separate pin.

@Tim Edwards just out of curiosity, why do you recommend biasing the level-down shifter (a normally 5V inverter powered at 3.3V) at 5V?

@bailey Well if you powered it at 5V , it would output 5V ... that wouldn't be much of a level shifter.

15:37

If you make an inverter out of 5V transistors but feed them 3.3V, they will wistand the 5V swing input but only output 3.3V on the output, hence shifting down from 5V -> 3.3V domain.

I would like to add 16KB of RAM (32 macro x SRAM 512 5V). Any advice on the layout? (Z80 design I am working on has a lot of free space, I want to put 16KB of RAM. That particular combinations Z80+16KB RAM is useful for fixing DRAM in old computers) (edited)

tnt

@bailey Well if you powered it at 5V , it would output 5V ... that wouldn't be much of a level shifter.

@tnt Thanks for the explanation. However, I understand that. I was wondering why @Tim Edwards was recommending biasing at 5V with a 3.3V power supply.

@bailey : Because if the level shifter is in a standard cell library and is part of a standard cell block, then the nwell will be shared with other cells biasing it to 5V.

Tim Edwards

@bailey : Because if the level shifter is in a standard cell library and is part of a standard cell block, then the nwell will be shared with other cells biasing it to 5V.

Thanks @tim. So if it's in a 5V standard cell block then the bias is 5V, but if it's in a 3.3V standard cell block, a 3.3V bias is ok too, right? Wouldn't putting a 3.3V powered 5V standard cell in a 5V standard cell row be difficult? You'd need two power rails. Do the 5V standard cells have 2 power rails?

You do need two power rails which is why shifters often exist on the boundary of two power domains. Here's the LV -> HV Sky130 shifter

Image attachment

@bailey : You don't need a power rail, just a power connection. It's only powering the level shifter, not an entire row of logic. In practice, all the level shifters are going to end up on the edge of the digital block, so it should be easy enough to bring a low voltage power bus close to the block and hook it up.

@Ethan Mahintorabi I understand that a level up shifter needs 2 power rails. What I'm asking is why we need two power connections for an inverter implementing a level down shifter. If the cell row height is the same for low/high voltage, then the high voltage capable inverter standard cell could be placed anywhere in a low voltage standard cell layout and still work without a high voltage power connection. The only high voltage is the input signal.

Sorry I misunderstood you. You're correct. That's essentially what I'm doing but across the whole chip. Using 5V standard cells and IO, but only providing 3.3v power.

1

How many IO pins?

FYI: I have started work on a GF180MCU "openframe" design. Hopefully I will get it (and an example user project using the 3.3V logic and the 3.3V SRAM) finished in time for the tapeout.

3

@Tim Edwards I want to also try and submit a TT variant using the split IO so any example of how to do that will be welcome

@tnt : I will be pushing everything to a repository as soon as I have done enough work on it that I know I won't have to replace everything wholesale on every update. Right now I have it in a half-finished state and using it as a reference would be highly misleading. Hopefully by end of day today or tomorrow I will have knocked down most of the items on my "to do" list.

It looks like I won’t be able to test my DACs for VGA output at their full range. TT demos only do 2 bits per channel of color depth, while the DACs are capable of 12 bits per channel.

17:03

Though anything about 8 bits per channel would be overkill.

Some demos can do more

Which ones?

I think @algofoogle (Anton Maurovic) had a demo for his own DAC that can do 8bpc (edited)

17:06

and there's a variant of the tt logo screensaver which reads a bitmap from the ROM that can be easily adjusted to 8bpc https://github.com/urish/tt-rom-vga-screensaver (edited)

17:08

basically need to edit convert.py and remove the parts that downscales from 8bpc to 2bpc, and extend the ROM word length from 6 bits to 24 bits

I have a GBA-ish-capable PPU that's currently hooked up to SPI LCD only. Pretty easy to knock together VGA timing generation. Can your DAC tristate its output @Tholin? It would have to share with digital pads (we have combined digital bidi + analogue pads right?)

17:11

It would be RGB555 320x240, with 480p60 timings, so only a 12ish MHz pixel clock. Not sure if that is an interesting test for you.

17:12

For VGA signal levels without an external buffer I would probably just tie off the 3 MSBs of the DAC code input (assuming it's rail-to-rail) and drive bits 8:4 with RGB555 components

It cannot

ahhh

17:13

no worries. I'm a bit tight on IOs due to the external parallel SRAM

17:15

Um. I mean I guess I could replace my audio PWM outputs with a DAC, and then steal my one unassigned GPIO as the third RGB component

then I could afford 3 analog pads

Where can I see the total wire length after a flow?

urish

I think @algofoogle (Anton Maurovic) had a demo for his own DAC that can do 8bpc (edited)

Yes that’s right, @Tholin I have this, though it’s little more than just an RGB888 test pattern generator: https://tinytapeout.com/chips/tt08/tt_um_algofoogle_tt08_vga_fun — source for the latest version I taped out is here: https://github.com/algofoogle/ttsky25b-analog-vga-dacs/tree/main/verilog/rtl

267 TT08 VGA FUN! - Tiny Tapeout

Rough 24-bit VGA DAC tests with digital control block

ttsky25b-analog-vga-dacs/verilog/rtl at main · algofoogle/ttsky25b...

More analog VGA DAC experiments. Contribute to algofoogle/ttsky25b-analog-vga-dacs development by creating an account on GitHub.

20:28

Image attachment

20:30

I was also working on something more pretty — than the ones above — in RGB888 here: https://github.com/algofoogle/tt10-vga-dac-party/blob/main/verilog/rtl/core_design.v (edited)

tt10-vga-dac-party/verilog/rtl/core_design.v at main · algofoogle/...

24-bit analog VGA DAC experiments (segmented current-steering) on Tiny Tapeout 10 - algofoogle/tt10-vga-dac-party

20:34

I recall @toivoh on the TT discord had an RGB444 demo that would be more interesting. I guess the key would be something that does nice gradients but also hard swings (high frequency stuff and full white or black pixels/blocks over gradients) every now and then… to test both linearity and slew rate. That’s what I was trying to do with the last link I shared.

Tholin

Where can I see the total wire length after a flow?

Is it in the “metrics” file? The TT GHA reports it, so there would be code in the tt-support-tools repo which pulls it out of librelane run artefacts

3076425 of whatever unit its in

I think it’s in microns, so ~3 metres of wire. Nice

22:55

(This is in the ballpark for large designs, I recall)

Yes....large

22:59

Embedded image

This is what 32768 x 5 bits of constant data look like.

algofoogle (Anton Maurovic)

Yes that’s right, @Tholin I have this, though it’s little more than just an RGB888 test pattern generator: https://tinytapeout.com/chips/tt08/tt_um_algofoogle_tt08_vga_fun — source for the latest version I taped out is here: https://github.com/algofoogle/ttsky25b-analog-vga-dacs/tree/main/verilog/rtl

Hmmm...I guess its kinda difficult to make a RGB888 demo since none of the simulators, like VGA playground, have support for this color format?

Tholin

Click to see attachment 🖼️

No data routing on M5?

M5 has the top-level power grid

23:17

In chip_top

23:17

I do not wish to disrupt it any more than I already have.

1

was just asking because you've done an excellent job of shading in all the other layers

23:18

I have a 256-byte ROM for my bootloader and it's enough to make me yearn for tnt's mask ROM

My data here is literally just a single bitmap

23:20

In my NTSC signal generator test

23:21

This is the least efficient way of encoding an image that I’ve ever seen.

Tim Edwards

FYI: I have started work on a GF180MCU "openframe" design. Hopefully I will get it (and an example user project using the 3.3V logic and the 3.3V SRAM) finished in time for the tapeout.

How is that different from what the template is creates / is using?

@Tim 'mithro' Ansell : Well,for one, it's a reference design for the mixed-voltage padframe.

Tim Edwards

@Tim 'mithro' Ansell : Well,for one, it's a reference design for the mixed-voltage padframe.

It would be nice to eventually have a mixed-voltage padframe support in the gf template. I'm assume @Leo Moser (mole99) has that all under control and you guys are communicating regularly about it. (edited)

Right now, the easiest path for me is to copy a lot of stuff from caravel-gf180mcu. Once I've worked out all the details, it can be re-done as a template.

Tim Edwards

Right now, the easiest path for me is to copy a lot of stuff from caravel-gf180mcu. Once I've worked out all the details, it can be re-done as a template.

Guess that makes sense.

@LukeW I started drafting things to port it over

2

Tholin

Click to see attachment 🖼️

Ah I see your problem: Your chip is full of... green.

algofoogle (Anton Maurovic) started a thread. 11/26/2025 11:16

Ok, setting PAD_CELL_LIBRARY doesn't work, can't do that at all because if a glob called from the default config doesn't match any file, it's a fatal error, even if you try to later override that config key in your config ...

13:21

So I need to let PAD_CELL_LIBRARY be gf180mcu_fd_io and then override each key manually.

If there's a way to do things smarter in the config or in LibreLane, just let me know and we can change it.

Well, I think having glob returning no file not be an error would be good

13:44

But ATM I'm just trying to get it to run and see exactly what I need to change for that.

1

Is there any reason all those PAD_ config to be there at all and not in the gf180mcu_fd_io/config.tcl ? (edited)

tnt started a thread. 11/26/2025 14:14

Why is global routing run twice? Its a step that takes forever in some of my flows and its run twice.

I don't think it should be run twice ... I only see it once in Chip flow. (edited)

Its run first as its own step

16:17

Then again during Antenna Repair

16:17

Then a third time actually, but after Antenna Repair has inserted new cells, so that checks out.

16:18

I have a flow where global routing takes 15 minutes each time, so that is 45 minutes of just global routing.

16:18

But yeah, Antenna Repair runs GRT before doing anything and I’m wondering why it can’t pull that data from the database from when GRT was run as its own step.

That’s a new one!

Image attachment

hehe I ran into that a bunch last night while messing around with my sram placements

BreakingTaps

hehe I ran into that a bunch last night while messing around with my sram placements

I know this was asked somewhere else but I'm curious did you find a good way to layout the SRAM? How many are you using and at what size?

Trevor Peyton

I know this was asked somewhere else but I'm curious did you find a good way to layout the SRAM? How many are you using and at what size?

huge grain of salt: I have no idea what I'm doing

I have twenty 512x8 blocks, and my current setup is a ring around the logic cells. Pretty sure I have them all backwards at the moment though, and I have a bunch of slew/cap violations at the moment (and some other broken stuff too) Seeing how little logic there actually is, I might condense the blocks closer to help with timing issues

Image attachment

2

I'm currently pushing a version of the platform (to either https://doc.test-platform.wafer.space or https://buddy.test-platform.wafer.space) which actually runs the gf180mcu-precheck on incoming designs and could probably use a few testers shortly.

Welcome to wafer.space …

Platform for wafer.space low cost silicon manufacturing.

BreakingTaps

huge grain of salt: I have no idea what I'm doing

I have twenty 512x8 blocks, and my current setup is a ring around the logic cells. Pretty sure I have them all backwards at the moment though, and I have a bunch of slew/cap violations at the moment (and some other broken stuff too) Seeing how little logic there actually is, I might condense the blocks closer to help with timing issues

I believe that is similar to the layout that @asic destroyer is using for thier design.

1

Tim 'mithro' Ansell

I believe that is similar to the layout that @asic destroyer is using for thier design.

Image attachment

now that is some nice logic density! i feel bad for wasting so much space haha

1

@BreakingTaps - It just means you'll have to do more designs and purchase more wafer.space slots!

1

hehe yessir! plenty of room for growth

In theory, you could build a memory chip by filling the whole die with SRAM cells and routing the signals out

asic destroyer

In theory, you could build a memory chip by filling the whole die with SRAM cells and routing the signals out

I would actually love someone to actually do that! -> https://docs.google.com/document/d/1hk0WXCmQ8LYNhn8gIVs8vHymR2MleQx2ro_hQlyOYKU/edit?tab=t.0#heading=h.5vu5m0flj1fy

wafer.space - GF180MCU SRAM Maximizer

GF180MCU SRAM Maximizer Goal Work out the maximum amount of SRAM that is able to fit into the GF180MCU configuration. Specification Layout as many SRAMs as possible that fit in a given die space. Current die size - 3.88mm x 5.07mm Die Size Instances Total Wi...

1

My custom SCL breaks LVS. Its been over 3 hours.

Image attachment

1

23:28

I tried checking the logs in the runs directory, but they all cut off. Mid-line.

23:29

So either some unflushed file buffers, or it actually hard crashed.

Tholin

I tried checking the logs in the runs directory, but they all cut off. Mid-line.

@Tholin If you send what you have of the lvs.log and lvs.report, I'll take a look.

Already cleaned up the runs directory for another go But I comited the librelane project causing the issue: https://github.com/AvalonSemiconductors/gf180mcu_as_sc_mcu7t3v3/tree/main/example_project

gf180mcu_as_sc_mcu7t3v3/example_project at main · AvalonSemiconduc...

Custom Standard Cell Library for GF180MCU process node on open PDK. - AvalonSemiconductors/gf180mcu_as_sc_mcu7t3v3

BreakingTaps

huge grain of salt: I have no idea what I'm doing

I have twenty 512x8 blocks, and my current setup is a ring around the logic cells. Pretty sure I have them all backwards at the moment though, and I have a bunch of slew/cap violations at the moment (and some other broken stuff too) Seeing how little logic there actually is, I might condense the blocks closer to help with timing issues

What clock speed are you running at?

"Free worldwide shipping is included, but buyers are responsible for insurance and tariffs." Does anyone have an estimate on what the tariff prices will be for the tapeout to the US? (edited)

Given this changes every time the orange throws a tantrum, any estimates today wouldn't weigh much for what it will be in 4 months ...

An estimate for todays rates would at least help ballpark additional costs.

it's around 50%

1

The baseline import tariff for goods from Singapore to the US is 10%, though specific sectoral tariffs may apply and can be higher. It's important to note that these tariffs are based on the product's country of origin, not where it's shipped from.

1

07:36

According to the Google AI -- so no idea if that is true or not

07:37

https://www.paidnice.com/calculators/us-tariff-calculator

US Tariff Calculator [Advanced] Calculate Latest Trump Tariffs

Calculate US import duties, tariffs and landed costs. Analyze profit margins and optimize your importing strategy with our free calculator tool.

07:37

The COB packaging is likely to happen in China which would make the country of origin probably China

While waiting for things to deploy, I had Claude throw together the following API server for the precheck - https://github.com/mithro/gf180mcu-precheck/tree/feature/api-server/server Would love thoughts on how horrible it is @ https://github.com/wafer-space/gf180mcu-precheck/pull/13 Thinking was to put up a dedicated hetzner server with the highest single threaded performance running it and allow people to run it.

gf180mcu-precheck/server at feature/api-server · mithro/gf180mcu-p...

Precheck for wafer.space MPW runs using the gf180mcu PDK - mithro/gf180mcu-precheck

WIP: API server for precheck service by mithro · Pull Request #13 ...

️ Draft PR - For Feedback Only This PR is NOT intended to be merged. It is shared purely to gather early feedback on the design and implementation approach for an API server that wraps the prechec...

Trevor Peyton

What clock speed are you running at?

20mhz right now (albeit with 5ns slack violations at max_ss)

1

BTW - https://doc.test-platform.wafer.space should be finally running manufacturing checks now.

Welcome to wafer.space …

Platform for wafer.space low cost silicon manufacturing.

1

23:20

Image attachment

I'll be back in an hour or two.

Lost most of yesterday to an issue with SSH multiplexing and jump hosts causing my deployment commands to end up on the wrong VM

Test Submission Platform up @ https://doc.test-platform.wafer.space I expect the submission process is going to be more bumpy than I would like, so I will be trying to babysit it as much as I can. Please do say something if you are having issues or things look wrong! At the moment it is just as likely to be the system as it is your problem. (edited)

Welcome to wafer.space …

Platform for wafer.space low cost silicon manufacturing.

Tim 'mithro' Ansell pinned a message to this channel. 11/28/2025 00:20

Since the run is going to happen anyways, what does the funding goal indicate? Is it the amount of buyers where wafer.space becomes sustainable?

Leon

Since the run is going to happen anyways, what does the funding goal indicate? Is it the amount of buyers where wafer.space becomes sustainable?

That is a good question. I guess it indicates the number of paid slots that I was aiming to have purchased.....

I feel confident that the next run will have more uptake, especially if there are any designs sharing their submissions as examples. Were you planning to have the next run before or after the receipt of chips from this run ?

Tim 'mithro' Ansell

Test Submission Platform up @ https://doc.test-platform.wafer.space I expect the submission process is going to be more bumpy than I would like, so I will be trying to babysit it as much as I can. Please do say something if you are having issues or things look wrong! At the moment it is just as likely to be the system as it is your problem. (edited)

I tested a submission using a link from google docs compressed and uncompressed and it was failing. With github, the upload worked just fine.

Trevor Peyton

I tested a submission using a link from google docs compressed and uncompressed and it was failing. With github, the upload worked just fine.

Can you log an issue?

dshadoff

I feel confident that the next run will have more uptake, especially if there are any designs sharing their submissions as examples. Were you planning to have the next run before or after the receipt of chips from this run ?

See the timeline thread @ https://discord.com/channels/1361349522684510449/1436214297532567753

The first cut of the GF180MCU Caravel "openframe" layout has now been pushed to https://github.com/RTimothyEdwards/gf180mcu_ocd_openframe !

GitHub - RTimothyEdwards/gf180mcu_ocd_openframe: Caravel openframe ...

Caravel openframe for GF180MCU. Contribute to RTimothyEdwards/gf180mcu_ocd_openframe development by creating an account on GitHub.

2

blobclap

1

22:26

Now to create a user project for it that is something more than a bunch of connections that turn off all the GPIOs. . .

Exported 511 message(s)

Timezone: UTC+0