============================================================== Guild: wafer.space Community Channel: Information / general Topic: Welcome to [wafer.space](https://wafer.space/) - documentation at [wafer.space github](https://github.com/wafer-space) - buy at [buy.wafer.space](https://buy.wafer.space) - archives at [discord.wafer.space](https://discord.wafer.space/) After: 07/31/2025 23:59 Before: 09/01/2025 00:00 ============================================================== [08/01/2025 11:11] tholin 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. {Attachments} 2025-08_media/image-754CB.png 2025-08_media/image-1BB3A.png {Reactions} 👍 (2) [08/01/2025 11:13] tholin 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. [08/01/2025 11:14] tholin 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. [08/01/2025 11:16] tholin I know a multi-bit flip-flop was also a thing that people wanted, so I may do that next. [08/01/2025 11:20] tholin 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. [08/07/2025 14:36] tholin Do we know what actually happens when a 3.3V FET is pushed into punch-through? [08/07/2025 14:36] tholin What kinda currents are to be expected? [08/07/2025 14:36] tholin Unfortunately, its not included in the SPICE models. [08/10/2025 11:12] mole99 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. [08/10/2025 11:13] mole99 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 [08/10/2025 11:24] tholin 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. [08/10/2025 11:25] tholin 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. [08/10/2025 11:26] tholin The digital output can already be fully disabled, of course. [08/10/2025 11:26] tholin If that is not the stupidest idea ever, though, I think I can pull that off quite easily. [08/10/2025 11:54] 246tnt But ... why ? [08/10/2025 11:55] tholin Didn't sky130 have such cells? [08/10/2025 11:55] tholin I mean, sky130 caravel [08/10/2025 11:56] tholin I remember that being a thing in the IO configuration options in mgmt controller firmware, at least. And option for analog. [08/10/2025 11:56] 246tnt It did, but AFAIK no-one was using them and caravel didn't either. [08/10/2025 11:56] tholin It would be useful for multi-project dies [08/10/2025 11:56] 246tnt The option for in the mgm controller was just disabling the output buffer and input buffer. [08/10/2025 11:57] 246tnt 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. [08/10/2025 11:57] tholin I kindof need such a cell for my own purposes, at least. [08/10/2025 11:58] 246tnt And that's what they did in GF too, hence the `ef` IO pad where they just added an analog connection. [08/10/2025 11:58] tholin Oh [08/10/2025 11:58] tholin Oh so that's what's different about the ef cell [08/10/2025 11:58] 246tnt yes [08/10/2025 12:00] tholin Just a resistor doesn't seem like the best approach to me, tbh [08/10/2025 12:00] tholin Since that does limit current [08/10/2025 12:00] 246tnt The resistor is just meant as ESD protection. [08/10/2025 12:03] tholin 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. [08/10/2025 12:04] 246tnt 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 ... [08/10/2025 12:05] tholin Right [08/10/2025 12:06] tholin I'll have to evaluate that on a case-by-case basis [08/10/2025 12:07] tholin 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. [08/10/2025 12:15] tholin 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. [08/10/2025 12:20] 246tnt The home page specifically states "... not requiring the usage of a specific pad frame or Caravel." [08/10/2025 12:31] tholin Well, "not requiring" still does not exclude the possibility of it being an option. [08/10/2025 12:34] tholin 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. [08/10/2025 12:34] tholin 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. [08/10/2025 12:53] mole99 It would be great if you could file an issue here: https://github.com/fossi-foundation/caravel_mgmt_soc-gf180mcu [08/10/2025 12:58] tholin I will! I didn't know there was new repos for this stuff. [08/10/2025 12:58] tholin I kinda thought I'd never get to report that bug when efabless went under. [08/10/2025 13:25] mole99 Thanks! Yes, the repos under the FOSSi Foundation should be considered the authoritative source. [08/21/2025 16:45] mithro_ @Leo Moser (mole99) / @tnt / @Tholin / @psychogenic - Probably a good idea to have the discussion about the padring and chip-on-board stuff here? [08/21/2025 16:46] mithro_ @Tholin - It appears that Tiny Tapeout finally convinced @Tim Edwards to join Discord so I invited him here too. [08/21/2025 16:46] rtimothyedwards_19428 Yeah, I'm here. : ) {Reactions} 👋 (2) [08/21/2025 16:52] 246tnt 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 ... [08/21/2025 16:54] 246tnt 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. [08/21/2025 16:55] mithro_ I updated a few details on chip on board thoughts @ https://docs.google.com/document/d/1ts9o1qC_U_-j65IQ7aDVNUoQ0aruVR_bUW2TsVUjdYo/edit?tab=t.0 {Embed} 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 ... 2025-08_media/AHkbwyL11tj3cvfD7UzevwkoORdeaJ9W8HGrPU1S7w-7E59E [08/21/2025 16:59] 246tnt 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. [08/21/2025 17:01] mithro_ 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. [08/21/2025 17:01] mithro_ I've also been meaning to chase up @stuart about what his partner can / can't do. [08/21/2025 17:02] mithro_ 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). [08/21/2025 17:06] mithro_ I created the #cob channel for the chip-on-board discussion. [08/21/2025 17:08] tholin Padrings is also another interesting topic, I'd say. [08/21/2025 17:09] mithro_ I've see cob and padring stuff connected? [08/21/2025 17:15] tholin Alright [08/21/2025 17:23] mithro_ People might find https://bit.ly/ws-tiny-riscv-proof interesting too. {Embed} https://bit.ly/ws-tiny-riscv-proof wafer.space - GF180MCU Bit Serial RISC-V Implementation - bit.ly/ws... GF180MCU Bit Serial RISC-V Implementation https://bit.ly/ws-tiny-riscv-proof Goal The primary goal of this project is to show a potential pathway to creating “custom RISC-V” chips with wafer.space’s low volume manufacturing & chip on board packaging that are within the realm of being cost compet... 2025-08_media/AHkbwyLB4cIdHr5BaevGBccwKPL1xmYlo7H4OScvtA-F2458 {Reactions} 👍 [08/21/2025 17:31] 246tnt 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. [08/21/2025 17:31] 246tnt Also if you have the full die for it, then space is really not much of a constraint. [08/21/2025 17:31] urish unless you want a 64-core MCU 😉 [08/21/2025 17:44] mithro_ @tnt - The idea is to sub-divide the die into even smaller die to get cost down even further [08/21/2025 17:45] mithro_ IE Try to prove you could do a sub-$1 type thing. [08/21/2025 17:46] 246tnt So you're going to have different die sizes ? [08/21/2025 17:51] saladchap 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? [08/21/2025 17:52] mithro_ @digshadow Was looking at dicing the bare die even further with lasers and similar [08/21/2025 19:38] digshadow yeah and I would go so far to say I'll probably laser dice the "garage semiconductor" test chips at some point [08/21/2025 20:02] mithro_ Started a thread. [08/21/2025 20:03] mithro_ I'm clueless enough to not know why alu matters verse gold? [08/22/2025 06:27] mole99 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. [08/22/2025 06:31] 246tnt 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 😅 [08/22/2025 06:56] mole99 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](https://github.com/mole99/greyhound-ihp/blob/dd7334364b053c3a0b52e81fc34a8fffb9808f5f/config.yaml#L162). 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. [08/22/2025 07:37] 246tnt 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. [08/22/2025 07:44] mole99 True, that would be a nice improvement! [08/22/2025 07:55] tholin 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? [08/22/2025 07:59] mole99 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. [08/22/2025 08:03] tholin 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. [08/22/2025 08:09] mole99 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. [08/22/2025 08:12] tholin No, I’m worried about *not* being able to use LibreLane. Don’t wanna fall back to OL. [08/22/2025 08:13] mole99 Then it's all fine :) [08/22/2025 09:45] mole99 {Attachments} 2025-08_media/Bildschirmfoto_vom_2025-08-22_11-35-06-BCD4C.png [08/22/2025 09:45] mole99 Not bad for starters [08/22/2025 16:27] mithro_ https://ic.onidev.fr/library/gf180mcu.html [08/22/2025 17:37] mithro_ If anyone is procrastinating, feel free to update the info @ https://bit.ly/ws-gf180mcu-stdcells 🙂 {Embed} 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... 2025-08_media/AHkbwyIkx20_yVUaPkY6H1IWJgHkZmbxZWsYMNxTFv-53089 [08/22/2025 18:04] tholin I added some info [08/22/2025 18:11] mithro_ Thanks! I moved your lib closer to the top as one which is under active development. [08/22/2025 18:27] mithro_ BTW The LibreSilicon people have a solution called popcorn which "grows" standard cells out of an inverter - https://pdk.libresilicon.com/ {Reactions} ❤️ [08/23/2025 13:52] leviathanch. 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 {Embed} https://gitlab.libresilicon.com/generator-tools/standard-cell-generator Generator tools / Standard Cell Generator · GitLab GitLab Community Edition 2025-08_media/twitter_card-570ddb06edf56a2312253c5872489-FA048.jpg [08/23/2025 13:52] leviathanch. 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 [08/23/2025 13:53] leviathanch. 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 [08/23/2025 13:53] leviathanch. first however, we need to make the DRC violations and shorts go away [08/23/2025 14:01] leviathanch. 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 {Embed} https://wiki.libresilicon.com/index.php?title=StdCellLib Index.php [08/23/2025 14:01] leviathanch. I'd be very happy about support, because right now I'm basically a one man show [08/23/2025 14:03] leviathanch. 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 {Embed} https://gitlab.libresilicon.com/generator-tools/standard-cell-generator/-/pipelines/148 Pipeline · Generator tools / Standard Cell Generator · GitLab GitLab Community Edition 2025-08_media/twitter_card-570ddb06edf56a2312253c5872489-FA048.jpg [08/23/2025 16:17] tholin 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. [08/23/2025 16:17] tholin Can I just tell LibreLane "there is a separate SCL at this path, please include it"? [08/23/2025 16:42] 246tnt If you couldn't with OL2, it's unlikely you can with LL. [08/23/2025 16:42] tholin Talking about OL1 [08/23/2025 16:43] tholin 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 [08/23/2025 16:48] 246tnt I'm not sure. You could try to just override all the PDK SCL relative config options in your config ... [08/23/2025 16:49] 246tnt All the stuff normally set in `config.tcl` and `$(SCL)/config.tcl` that you need to change, override those in your project config. [08/23/2025 16:50] tholin That could work. Depends on if the project config takes precedence over the PDK configs. [08/23/2025 16:54] 246tnt Yes, it should, I override defaults all the time. [08/23/2025 17:38] mithro_ @Tholin - It might be worth chatting with donn on https://matrix.to/#/#librelane:fossi-chat.org {Embed} https://matrix.to/ 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 2025-08_media/matrix-logo-56B2E.png [08/24/2025 23:29] tholin 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. {Attachments} 2025-08_media/image-66242.png [08/24/2025 23:30] tholin That took all weekend to get to work, even with htamas’ POC repo as a starting point. {Reactions} ❤️ [08/24/2025 23:37] tholin 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 [08/24/2025 23:37] tholin I need to go for today, but I will work on this more tomorrow and create a repo. [08/25/2025 06:29] mole99 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? [08/25/2025 06:31] mole99 @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. [08/25/2025 09:35] tholin 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. [08/25/2025 09:40] 246tnt It probably prevents shoot through current if you maintain a mid-rail voltage at the input. [08/25/2025 09:44] tholin Possibly [08/25/2025 09:44] tholin I figured having OE and IE set at the same time might cause a conflict, but I don’t see how. [08/25/2025 10:14] 246tnt Yeah, the doc says that's invalid, but I also didn't really see what problem it could cause ... [08/25/2025 10:30] tholin 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. [08/25/2025 10:39] 246tnt Yes, that's what I concluded from the spice models too [08/25/2025 11:26] tholin But I think, for the sake of completeness, I will wire the IEs to the user project area on my little setup too. [08/25/2025 13:11] tholin @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. {Attachments} 2025-08_media/image-CA205.png [08/25/2025 15:00] tholin Power routing is still an issue. I checked how they did it in caravel and its...odd. [08/25/2025 15:01] tholin 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. [08/25/2025 15:02] tholin 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? [08/25/2025 15:20] tholin 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. {Attachments} 2025-08_media/image-D061C.png [08/25/2025 15:24] 246tnt AFAIU `pdngen` should be capable of extending straps to the IO power rings but I'm not sure how to set that up. [08/25/2025 15:26] 246tnt Ah but here it's some pad kind of thing. I know for caravel sky130 I did write a custom step for that. [08/25/2025 16:05] tholin In any case, here is what I have so far: [08/25/2025 16:05] tholin https://github.com/AvalonSemiconductors/ll_gf180_full_chip {Embed} 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 2025-08_media/ll_gf180_full_chip-AD40B [08/25/2025 16:05] tholin You can open it in the (latest!) iic-osic-tools and do `make user_project_example`, `make user_project_wrapper`, `make chip` [08/25/2025 16:06] tholin Trying to emulate the efabless naming conventions a little bit. [08/25/2025 16:07] tholin The only thing that’s missing is the power connections to the top-level PDN in `chip` [08/25/2025 22:49] tholin 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. [08/26/2025 20:38] tholin 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. {Attachments} 2025-08_media/image-106BB.png [08/26/2025 20:38] tholin I actually need to make them longer, they don’t quite reach the ring of the PDN. [08/26/2025 20:39] tholin Literally called `gf180mcu_fd_io__dvdd_tail` because I’m not very creative. [08/26/2025 23:11] tholin Okay, can’t get it to connect yet, but almost there. {Attachments} 2025-08_media/image-2FD02.png [08/26/2025 23:29] tholin PDN won’t lock on to these and drop down vias. I’ll figure this out tomorrow. [08/27/2025 13:18] mole99 {Attachments} 2025-08_media/Bildschirmfoto_vom_2025-08-27_14-51-07-8BA84.png [08/27/2025 13:18] mole99 I managed to persuade pdngen to connect to the default I/O power/ground cells. [08/27/2025 13:30] tholin I got it figured out may way too! {Attachments} 2025-08_media/image-52C2F.png [08/27/2025 19:01] tholin Alright! Done! I even included a basic setup with cocotb for RTL and GL verification. https://github.com/AvalonSemiconductors/ll_gf180_full_chip [08/27/2025 19:03] tholin {Attachments} 2025-08_media/image-270AD.png {Reactions} blobclap [08/27/2025 19:16] tholin 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? [08/27/2025 19:16] tholin Weird [08/27/2025 21:15] tholin 24,875 magic DRC errors :flop: [08/27/2025 21:24] tholin Right, I remember this [08/27/2025 21:24] tholin When I was reverse-engineering that IO cell, I saw that it had tons of DRC errors. [08/27/2025 21:25] tholin The IO cells in the PDK are just....like this. They have tons of DRC errors. [08/29/2025 13:12] tholin 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 [08/30/2025 16:57] 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. [08/30/2025 17:26] mole99 Nice, looking forward to it! [08/30/2025 17:27] mole99 Do you know whether the I/O cells are violating the rules or whether the DRC deck is incomplete? [08/30/2025 17:45] tholin 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. [08/30/2025 17:46] tholin For instance, the pad driver macro on the 24t bidir IO cell has minimum width violations on resistive ndiff and pdiff regions. [08/30/2025 17:56] mole99 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. [08/30/2025 17:59] _saltypretzel Maybe since the pad frame was the same for each tapeout, all the chips would have the same drc errors in the padring [08/30/2025 18:01] _saltypretzel 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. [08/30/2025 18:57] mole99 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. [08/31/2025 20:32] rtimothyedwards_19428 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. [08/31/2025 20:36] rtimothyedwards_19428 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. [08/31/2025 21:59] tholin 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. [08/31/2025 22:00] tholin 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. ============================================================== Exported 162 message(s) ==============================================================