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 07/31/2025 23:59 and 09/01/2025 00:00

I know there was someone who was yearning for a transmission gate in the 5V 7-track SCL. Well, I made it in both _1 and _2 variants. I’m not sure how to characterize these, though. lctime can’t do it.

Image attachment

Image attachment

2

11:13

I can characterize the delays from A -> Y when the EN = 1, ENB = 0. But I cannot characterize the turn on/off delays when switching the enables. So they’re treated like regular buffers by STA. (edited)

11:14

I can also make a version with the inverter to generate ENB built-in, but I believe the idea is that multiple of these can share one inverter.

11:16

I know a multi-bit flip-flop was also a thing that people wanted, so I may do that next.

11:20

I know a 8-to-1 mux was also on the list of desired standard cells. But that one is gonna take some doing. That’s a lot of logic.

Do we know what actually happens when a 3.3V FET is pushed into punch-through?

14:36

What kinda currents are to be expected?

14:36

Unfortunately, its not included in the SPICE models.

I don't think so, at least not on GF180MCU. I assume that this is often not modeled since you are outside the safe operating range.

11:13

By the way, here are a some nice I/O cell symbols for IHP as inspiration: https://github.com/IHP-GmbH/IHP-Open-PDK/pull/630

I also see we don't have a IO pad cell that can switch between analog and digital IO. I wonder how difficult that would be to do.

11:25

The naive approach I feel like taking is it to take the existing digital bi-directional IO cell and cramming a transmission gate in there somewhere to switch an analog signal.

11:26

The digital output can already be fully disabled, of course.

11:26

If that is not the stupidest idea ever, though, I think I can pull that off quite easily.

But ... why ?

Didn't sky130 have such cells?

11:55

I mean, sky130 caravel

11:56

I remember that being a thing in the IO configuration options in mgmt controller firmware, at least. And option for analog.

It did, but AFAIK no-one was using them and caravel didn't either.

It would be useful for multi-project dies

The option for in the mgm controller was just disabling the output buffer and input buffer.

11:57

The transmissions gates and analog muxing and all the analog stuff of the IO cell was never used. Instead carvel just wired directly to the pad through a resistor, no switching.

I kindof need such a cell for my own purposes, at least.

And that's what they did in GF too, hence the ef IO pad where they just added an analog connection.

Oh

11:58

Oh so that's what's different about the ef cell

yes

Just a resistor doesn't seem like the best approach to me, tbh

12:00

Since that does limit current

The resistor is just meant as ESD protection.

I mean, I'm also worried that if the pin is used for digital IO too, the digital voltages might backflow into the analog circuitry and cause damage, especially if that pin's dual purpose is analog output. (edited)

Well it all depends on what's wired to the analog pin of course. There is no "one-size-fit-all". Because a pass gate is a non-linear resistor which is also not a perfect solution. And depending on its size it will also be a current limit ... or an added capacitance depending on where you lie on its size ...

Right

12:06

I'll have to evaluate that on a case-by-case basis

12:07

Of course, I do hope I'll be able to customize the pad frame and swap out the actual IO pad structures for my own so that I may do that.

Speaking of the mgmt controller, though: will wafer.space customers have the option of using the RISC-V management controller wrapper on their dies? If so, I have to report a really nasty bug in that thing's caches that I found that caused me a lot of grief and that should definitely be fixed.

The home page specifically states "... not requiring the usage of a specific pad frame or Caravel."

Well, "not requiring" still does not exclude the possibility of it being an option.

12:34

But basically, user area wishbone writes corrupt the latest data cache entry. So if you set a variable before doing that wishbone write, the variable write has now been undone until the cache is flushed.

12:34

Or...something like that. Its weird and hard to debug. I just have a way of reproducing it sitting in one of my repos somewhere.

It would be great if you could file an issue here: https://github.com/fossi-foundation/caravel_mgmt_soc-gf180mcu

I will! I didn't know there was new repos for this stuff.

12:58

I kinda thought I'd never get to report that bug when efabless went under.

Thanks! Yes, the repos under the FOSSi Foundation should be considered the authoritative source.

@Leo Moser (mole99) / @tnt / @Tholin / @psychogenic - Probably a good idea to have the discussion about the padring and chip-on-board stuff here?

16:46

@Tholin - It appears that Tiny Tapeout finally convinced @Tim Edwards to join Discord so I invited him here too.

Yeah, I'm here. : )

2

Well, what I'd like is that for TT users, whatever they receive, they should have the option to use it on a custom board without having a gigantic connector and huge associated parasitics. ATM with a QFN it's easy enough to unsolder it to re-use it and we also sell kits where the QFN is not soldered and thus can be easily used on custom projects. QFN also make testing before full assembly easier because it's easy for me to do one and validate things. For the last 2 (or3?) TT boards, there was something that went wrong and required fixing before final assembly of the whole batch. Bare-dies and wire bonding make all of that not trivial ...

16:54

The only 2 ideas I had were :

Use a tiny board-to-connector like they use on cell phones and stuff, something small and hopefull not too expensive but still doesn't have huge parasitics
Make our "homebrew" QFN basically wirebonding the chip to a tiny ( like 15mm x 15mm ) thin PCB that exposes pads on the bottom and can be reflowed on the final PCB.

I updated a few details on chip on board thoughts @ https://docs.google.com/document/d/1ts9o1qC_U_-j65IQ7aDVNUoQ0aruVR_bUW2TsVUjdYo/edit?tab=t.0

wafer.space - GF180MCU Chip-on-Board (COB) Packaging

Goal As wafer.space provides bare die -- the goal is to provide a number of existing pad rings for people which have associated PCBs already designed (with a known cost) and manufacturer pathway (which also has a known cost). As the PCB needs to be designed for a specific pad ring -- design of ...

As far as the pad ring, the only thing I would specify is the number and position of pads if you plan to offer more than bare die but also some form of "packaging" service. What the actual pins are doesn't really matter ... With the possible exception of marking some of the sites as being "GND" so you can bond them to a gnd pad or to the substrate via conducive epoxy or such.

tnt

As far as the pad ring, the only thing I would specify is the number and position of pads if you plan to offer more than bare die but also some form of "packaging" service. What the actual pins are doesn't really matter ... With the possible exception of marking some of the sites as being "GND" so you can bond them to a gnd pad or to the substrate via conducive epoxy or such.

I'm working on partnering with PCB Way, Seeed and JLCPCB (talking to people at each of these companies) so they can do the packaging.

tnt

As far as the pad ring, the only thing I would specify is the number and position of pads if you plan to offer more than bare die but also some form of "packaging" service. What the actual pins are doesn't really matter ... With the possible exception of marking some of the sites as being "GND" so you can bond them to a gnd pad or to the substrate via conducive epoxy or such.

I've also been meaning to chase up @stuart about what his partner can / can't do.

tnt

As far as the pad ring, the only thing I would specify is the number and position of pads if you plan to offer more than bare die but also some form of "packaging" service. What the actual pins are doesn't really matter ... With the possible exception of marking some of the sites as being "GND" so you can bond them to a gnd pad or to the substrate via conducive epoxy or such.

I wrote in the document;

As wafer.space provides bare die -- the goal is to provide a number of existing pad rings for people which have associated PCBs already designed (with a known cost) and manufacturer pathway (which also has a known cost).

17:06

I created the #cob channel for the chip-on-board discussion.

Padrings is also another interesting topic, I'd say.

Tholin

Padrings is also another interesting topic, I'd say.

I've see cob and padring stuff connected?

Alright

People might find https://bit.ly/ws-tiny-riscv-proof interesting too.

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...

1

Not really sure why you want to go bit serial ... the size of the SRAM is going to be way bigger than the rest of the logic I think.

17:31

Also if you have the full die for it, then space is really not much of a constraint.

unless you want a 64-core MCU

@tnt - The idea is to sub-divide the die into even smaller die to get cost down even further

17:45

IE Try to prove you could do a sub-$1 type thing.

So you're going to have different die sizes ?

Tim 'mithro' Ansell

I've also been meaning to chase up @stuart about what his partner can / can't do.

Place I know only does alu wire bonds, not gold. They can do packaging too but not asked for details, do we have any kind of spec or requirements data I can share with them?

tnt

So you're going to have different die sizes ?

@digshadow Was looking at dicing the bare die even further with lasers and similar

Tim 'mithro' Ansell

@digshadow Was looking at dicing the bare die even further with lasers and similar

yeah and I would go so far to say I'll probably laser dice the "garage semiconductor" test chips at some point

Tim 'mithro' Ansell started a thread. 08/21/2025 20:02

stuart

Place I know only does alu wire bonds, not gold. They can do packaging too but not asked for details, do we have any kind of spec or requirements data I can share with them?

I'm clueless enough to not know why alu matters verse gold?

So do we ditch Caravel and its padframe? As @Tim Edwards mentioned in FOSSi Chat, it's excruciatingly slower than the earlier picorv32 implementation (about 100 times slower), and as @Tholin discovered, there's a major bug in it (https://github.com/fossi-foundation/caravel_mgmt_soc-gf180mcu/issues/1). If @tnt uses the same script to create the I/O cell positions as for Tiny Tapeout on IHP, this would be compatible with the LibreLane padring generation step. I can then replicate the same padring using just the config.yaml in LibreLane, and wafer.space users could easily swap out the I/O cells for other types.

I was definitely going to use the same script ... (or possibly just use the one merged in LibreLane if I manage to get it to do what I need). I mean it just distributes the IO as evenly spaced as possible so that satisfies my OCD

Well, an even distribution definitely makes sense :) We just need to think how we can improve the script when we have differently sized cells, or cells with two bondpads. But luckily, the I/O cells in gf180mcu all have the same size again. You would need to enter the I/O cell names and the instances similar to here. But I think in your script you automatically place the I/O cells based on the instances? In that case, the padring step allows you to supply a custom pad.cfg, similar to the PDN step.

Yeah the instance name is ... randomly picked by yosys with a bunch of `generate so the best I can do is match it with regexp but definitely not provide one complete stable name. And yeah, I don't see why you need to set the pad type in the config. You instanciate them in the verilog right ? So that info is available in the database already and from the name you can get the type.

True, that would be a nice improvement!

I assume all this means I’d have to cook up my own setup for generating the top level GDS and all the macros using LibreLane?

What do you mean by that? From now on, you should no longer use OpenLane anyway. There will probably be a wafer.space example design that can be used as a starting point for creating the complete chip with padring.

I did say LibreLane. Avoiding the old OpenLane is what I’m trying to do, otherwise I’d be a little more okay with using the gf180 caravel_user_project.

Yes, I thought it was clear that we are using LibreLane for everything. So I thought your question was about something else, maybe reusing macros from OpenLane - which is possible.

No, I’m worried about not being able to use LibreLane. Don’t wanna fall back to OL.

Then it's all fine :)

Image attachment

09:45

Not bad for starters

https://ic.onidev.fr/library/gf180mcu.html

If anyone is procrastinating, feel free to update the info @ 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

If anyone is procrastinating, feel free to update the info @ https://bit.ly/ws-gf180mcu-stdcells

I added some info

Tholin

I added some info

Thanks! I moved your lib closer to the top as one which is under active development.

BTW The LibreSilicon people have a solution called popcorn which "grows" standard cells out of an inverter - https://pdk.libresilicon.com/

1

Tim 'mithro' Ansell

BTW The LibreSilicon people have a solution called popcorn which "grows" standard cells out of an inverter - https://pdk.libresilicon.com/

Exactly. We also already generate standard cells for SKY130, GF180 and most recently I have introduced support for IHP's SG13G2 https://gitlab.libresilicon.com/generator-tools/standard-cell-generator

Generator tools / Standard Cell Generator · GitLab

GitLab Community Edition

13:52

Skywater and IHP's cells still have some short circuits and I'd be glad if some folks could render some support with solving it

13:53

In addition, I'm also currently working on a pad cell generator, which dynamically layouts pad cells from a parametric meta design based on design rules provided

13:53

first however, we need to make the DRC violations and shorts go away

I wrote some text on our wiki page and built a Docker container with all the tools needed for getting started, even klayout should work (still some issues with IHP tho) https://wiki.libresilicon.com/index.php?title=StdCellLib

14:01

I'd be very happy about support, because right now I'm basically a one man show

14:03

My own 1 micron process from Hong Kong currently refuses to route, IHP and SKY130 still produce short circuits which makes CharLib fail characterizing the cells https://gitlab.libresilicon.com/generator-tools/standard-cell-generator/-/pipelines/148

Pipeline · Generator tools / Standard Cell Generator · GitLab

GitLab Community Edition

I have a minor question. Has it become any easier to use a custom SCL in LibreLane? Doing so in OpenLane requires me to hack the PDK install, merging my SCL in and editing some config files to get it to recognize and even so I still need some hacks in the flow configuration too. I know this approach works with LibreLane too, I did it during a TinyTapeout experimental shuttle and my sky130 SCL, but I wonder if there is a better way by now.

16:17

Can I just tell LibreLane "there is a separate SCL at this path, please include it"?

If you couldn't with OL2, it's unlikely you can with LL.

Talking about OL1

16:43

TT did use OL2 (or LL? I forgot), but I kinda just went with my hacky approach because I was pressed for time and knew it would work, at least (edited)

I'm not sure. You could try to just override all the PDK SCL relative config options in your config ...

16:49

All the stuff normally set in config.tcl and $(SCL)/config.tcl that you need to change, override those in your project config.

That could work. Depends on if the project config takes precedence over the PDK configs.

Yes, it should, I override defaults all the time.

@Tholin - It might be worth chatting with donn on https://matrix.to/#/#librelane:fossi-chat.org

Matrix - Decentralised and secure communication

You're invited to talk on Matrix. If you don't already have a client this link will help you pick one, and join the conversation. If you already have one, this link will help you join the conversation

Okay, I’m still not done, BUT this has the same size as a caravel die and is pad-out compatible! Of course, without a mgmt controller, there is 5 more GPIOs.

Image attachment

23:30

That took all weekend to get to work, even with htamas’ POC repo as a starting point.

1

23:37

Issues:

I’m pretty sure power isn’t connected - the several thousand warnings in the log about unconnected vss and vdd nets imply as such

the SL, CS, PD and PU pins on the bidir IO pads are tied to constant values. Not sure what to do with them. Forward to user project area? Tie to constants according to a user config file? Feedback on this is appreciated.

No SDC files to define delays introduced by IO pads - top-level STA is therefore questionable

Needs some Makefile magic to be more user-friendly of a setup

23:37

I need to go for today, but I will work on this more tomorrow and create a repo.

Great work! But as mentioned earlier, we will most likely use new pad positions for Tiny Tapeout, which will become the new standard pad ring. Yeah, I also need to look into power connections. @htamas I noticed that you have some CONNECT_POWER_PADS defines in your code. Have you managed to get your padring to connect automatically to the core PDN?

06:31

@tnt One thing to consider for the future when I/O cells with different widths are a thing: Do we distribute the positions of the bondpads evenly, or do we make sure the distance between the I/O cells is evenly distributed? Currently, because all cells have the same width, both is the case. (Might not be that relevant for TT, but I would like to make the LibreLane padring step future-proof.) I would go for the latter. With the first approach there is the issue that you can't go as tight because a larger cell might already be touching its neighbours while the other cells still have space. If there are cells with two bondpads, such as for LVDS, it becomes difficult to ensure the same distance between all the bondpads anyways.

What is the point of having the IE (Input Enable) pin on the bidir IO cells? I thought it tri-states something, but it doesn’t. Seems to just force Y to zero.

It probably prevents shoot through current if you maintain a mid-rail voltage at the input.

Possibly

09:44

I figured having OE and IE set at the same time might cause a conflict, but I don’t see how.

Yeah, the doc says that's invalid, but I also didn't really see what problem it could cause ...

If you check my reverse engineered schematics, you’ll see that it makes no difference to a pin set to output whether IE is also set or not.

Yes, that's what I concluded from the spice models too

But I think, for the sake of completeness, I will wire the IEs to the user project area on my little setup too.

@htamas I see the "GeneratePDN" step is still enabled in your top-level flow, even though it won’t actually do anything. Is there any reason for this? I had to disable it in my project because it suddenly started throwing errors for seemingly no reason. (edited)

Image attachment

Power routing is still an issue. I checked how they did it in caravel and its...odd.

15:01

There is a macro in the hierarchy called "caravel_power_routing" that just contains short bridges on Metal3 that connect between the power rails in the pad ring, and the PDN of caravel_core.

15:02

I would like to have a general-purpose solution rather than doing that part manually, so I guess its time to write a custom step?

To visualize: The VDD and VSS IO cells have just a little bit of overhang on the Metal2 layer for all power rails, which is where caravel_power_routing latches on to and bridges to a PDN’s ring further to the right. (edited)

Image attachment

AFAIU pdngen should be capable of extending straps to the IO power rings but I'm not sure how to set that up.

15:26

Ah but here it's some pad kind of thing. I know for caravel sky130 I did write a custom step for that. (edited)

In any case, here is what I have so far:

16:05

https://github.com/AvalonSemiconductors/ll_gf180_full_chip

GitHub - AvalonSemiconductors/ll_gf180_full_chip: Example of full c...

Example of full chip with custom padring on gf180mcu using LibreLane - AvalonSemiconductors/ll_gf180_full_chip

16:05

You can open it in the (latest!) iic-osic-tools and do make user_project_example, make user_project_wrapper, make chip

16:06

Trying to emulate the efabless naming conventions a little bit. (edited)

16:07

The only thing that’s missing is the power connections to the top-level PDN in chip

Yeah, I believe I have to ask for help with the power connection problem. I’m not sure what the best approach would be here. Making hookups to the rails in the padring is also an option.

I decided to just cheat a little bit. Made custom VDD/VSS IO cells that are actually just copies of the PDK cells, but I gave them tails like this.

Image attachment

20:38

I actually need to make them longer, they don’t quite reach the ring of the PDN.

20:39

Literally called gf180mcu_fd_io__dvdd_tail because I’m not very creative.

Okay, can’t get it to connect yet, but almost there.

Image attachment

PDN won’t lock on to these and drop down vias. I’ll figure this out tomorrow.

Image attachment

13:18

I managed to persuade pdngen to connect to the default I/O power/ground cells.

I got it figured out may way too!

Image attachment

Alright! Done! I even included a basic setup with cocotb for RTL and GL verification. https://github.com/AvalonSemiconductors/ll_gf180_full_chip

19:03

Image attachment

blobclap

1

Only remaining issue is that LVS fails simply because the vsscore and vddcore nets in one circuit have a random number added to the end of their names? (edited)

19:16

Weird

24,875 magic DRC errors flop

flop

Right, I remember this

21:24

When I was reverse-engineering that IO cell, I saw that it had tons of DRC errors.

21:25

The IO cells in the PDK are just....like this. They have tons of DRC errors.

Doesn’t have much at the moment, but this is where I will upload all the extra standard cells I’m making: https://github.com/AvalonSemiconductors/gf180mcu_extra_cells

Working on the multi-bit DFF now. I assume the point of that is area savings by making multiple DFFs share the same clock inverters, not just because of the reduced area from less inverters, but also because it simplifies the clock tree.

Tholin

Working on the multi-bit DFF now. I assume the point of that is area savings by making multiple DFFs share the same clock inverters, not just because of the reduced area from less inverters, but also because it simplifies the clock tree.

Nice, looking forward to it!

Tholin

The IO cells in the PDK are just....like this. They have tons of DRC errors.

Do you know whether the I/O cells are violating the rules or whether the DRC deck is incomplete?

Leo Moser (mole99)

Do you know whether the I/O cells are violating the rules or whether the DRC deck is incomplete?

I've been trying to put together 3.3V compatible IO cells by simply modifying the existing ones. And so I can say that, yeah, there are actual DRC errors in there that I keep having to fix.

17:46

For instance, the pad driver macro on the 24t bidir IO cell has minimum width violations on resistive ndiff and pdiff regions.

That is interesting. I wonder how Efabless did their tapeouts then. Maybe these rules only apply to the core area? Or GF waived the DRC errors on the I/O cells? I'll have to ask Tim.

Maybe since the pad frame was the same for each tapeout, all the chips would have the same drc errors in the padring

18:01

I don’t recall having drc errors in the pad ring at least when I ran drc on magic. Of course, when they submit to fab, they maybe run their own closed source calibre deck on it first.

Yes, the same padring was used for all designs on GFMPW0/1 afaik. Did you submit a design to one of the shuttles? You probably only ran DRC on the user_project_wrapper, which was later integrated with the padring.

As far as I recall from the tapeouts, we got GF to waive all the errors that were inside their own cells. But it has been a long time since we did those tapeouts, and I have forgotten all the details. Reading other tools' GDS into magic is always a struggle, and what you see is not necessarily what you get. I'm running DRC on the Caravel GF version chip_io padframe now to try to refresh my memory.

20:36

A review of the padframe suggests that most errors are the usual struggle to read in layers like DUALGATE that may exist outside the cell with the diffusion that it affects, which is the sort of thing that magic does not deal with very well. Failure to see DUALGATE in the right cell then ends up triggering errors about different voltage gates in the same well. But I have yet to see anything that is obviously a real error.

My conclusion as well. All errors to do with clearance and sizing are not technically impossible, quite clearly so if you look at all the working GFMPW chips.

22:00

Can we expect a similar waiver from GF again? Otherwise, I am 100% down to sit down and spend a few days editing the IO cells to be DRC clean. (edited)

Exported 162 message(s)

Timezone: UTC+0