============================================================== 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: 06/30/2025 23:59 Before: 08/01/2025 00:00 ============================================================== [07/02/2025 23:54] tholin I've begun work on a SCL for gf180mcu using 3.3V transistors [07/02/2025 23:56] tholin I created an inv_2 cell and characterized it using the exact same parameters for input slew and output load as I did for the inv_2 cell in my sky130 SCL and got promising results. [07/02/2025 23:56] tholin 3.3V gf180 is at least as fast as sky130_fd_sc_hd {Reactions} ๐Ÿ‘€ [07/02/2025 23:56] tholin But most likely faster [07/02/2025 23:57] tholin It trades punches with my sky130_as_sc_hs SCL, which outperforms fd_sc_hd by a wide margin. [07/03/2025 16:27] tholin I have all the cells that I need for yosys and OpenLane to do their things, except a D-Flip-Flop. That one is gonna take a bit. I always struggle with them a bit. {Attachments} 2025-07_media/image-D2C91.png {Reactions} blobclap (4) [07/04/2025 17:41] mithro_ @Tholin - Awesome work! [07/04/2025 19:14] tholin DFF done. About to test it all in a flow for the first time. And then its time for an initial commit to GitHub. {Reactions} ๐Ÿ‘ [07/04/2025 19:55] tholin {Attachments} 2025-07_media/image-62331.png [07/04/2025 19:55] tholin Gimme a minute for the commit [07/04/2025 22:14] tholin Apologies for the delay. I encountered some DRC errors, but I canโ€™t test my changes because OpenLane continues to use the previous version of the cell layout files. I donโ€™t know where its getting those from, they are long overwritten. Sadly, I donโ€™t remember what I did to fix this issue the last time I had it. [07/05/2025 15:40] tholin https://github.com/AvalonSemiconductors/gf180mcu_as_sc_mcu7t3v3 {Embed} https://github.com/AvalonSemiconductors/gf180mcu_as_sc_mcu7t3v3 GitHub - AvalonSemiconductors/gf180mcu_as_sc_mcu7t3v3: Custom Stand... Custom Standard Cell Library for GF180MCU process node on open PDK. - AvalonSemiconductors/gf180mcu_as_sc_mcu7t3v3 2025-07_media/gf180mcu_as_sc_mcu7t3v3-101A7 [07/05/2025 15:41] tholin And with that, the hardest parts are actually already behind me. The project is now in the "smooth sailing" phase where I can just add more combinatorial logic cells in whatever order I like. {Reactions} ๐Ÿ‘ ๐ŸŽ‰ (3) [07/05/2025 15:42] tholin And since I've done this before, I can copy my own work from sky130_as_sc_hs {Reactions} ๐Ÿ‘ [07/08/2025 10:45] tholin Progress on the SCL has been halted for two days now because I added a mux2 cell and even though nothing appears bad in the liberty file, the GL tests fail unless I disable this cell. Yosys is simply synthesizing bad logic when the mux2 is defined. If anyone has any leads on this, please reach out. [07/08/2025 10:47] mattvenn you could try asking here: https://yosyshq.discourse.group/ {Embed} https://yosyshq.discourse.group/ YosysHQ A place to discuss YosysHQ software and tools 2025-07_media/discourse-logo-sketch-small-1B62A.png [07/15/2025 18:45] tholin Here, ya'll might get a kick out of this. The AS2650v2 is a custom MCU/CPU I taped out for GFMPW-1 and on one of the test boards for it, I created this demo. I actually did this almost a year ago, I only just bothered to record it. https://www.youtube.com/watch?v=8YNhw6dvOw4 {Embed} Tholin https://www.youtube.com/watch?v=8YNhw6dvOw4 AS2650v2 Bad Apple Demo https://avalonsemiconductors.github.io/AS2650/ 2025-07_media/maxresdefault-52BDC.jpg {Reactions} ๐Ÿ’ฏ (2) ๐Ÿฆ„ (2) [07/15/2025 18:47] tholin Audio also generated by the AS2650v2, but recorded directly from the DAC output. That piezzo is...not good. [07/25/2025 17:10] _mwelling_ @Tim 'mithro' Ansell nice seeing you at open sauce... Hopefully I can find a way to contribute to the first wafer.space shuttle. {Reactions} ๐Ÿ‘ [07/26/2025 16:59] tholin SCL update: ran a flow on a custom RV32IM core with a tweaked config to optimize for delay to see how far I can push it speed-wise and ended with an fmax=105MHz, while retaining the same density as the 7-track 5V cells. If I let the fmax drop and optimize for area, on the other hand, my SCL has a noticably higher density than the 7-track 5V cells. And this is all before I added most of the aoi combo cells I planned, so this is likely to improve even more as I keep working. I also have to add that this is not a good RISC-V core I'm compiling here. Its something I threw together in a few hours. Architectural improvements could easily throw this past the 150MHz mark right now. {Reactions} ๐Ÿ’ฏ [07/26/2025 17:01] tholin Another note is that I am testing my SCL against RTL from one of my GFMPW-1 submissions, which means it uses caravel_user_project and OpenLane 1. I don't know what the recommended setup for wafer.space will be, but I assume LibreLane and an OpenFrame-equivalent? I'll still need to test my SCL against LibreLane and see if that also yields performance improvements. [07/26/2025 17:09] tholin In other news, I've also started collecting ideas on things I can put onto my submission for the first shuttle. I am planning to again do a multi-project die. The ideas list is quite long by now. I will soon pick out a handful of them and start writing up requirements documents so I can start implementation work the moment the deadline becomes known. I can share a bit of this list if anyone else still needs inspiration. {Reactions} ๐Ÿ‘ (2) [07/27/2025 07:30] mole99 I would expect LibreLane to be used for wafer.space submissions. That's where future development takes place, and it already has quite some nice features (and bug fixes) compared to OpenLane 2 (not to mention OL1). Ultimately it depends on the users how they create their layout, but IMO LibreLane should be the recommended path. There is of course the existing pad frame from the GFMPW shuttles at Efabless, which is going to be used for the first wafer.space shuttle run. I'm working on an OpenROAD.PadRing step for IHP, which should work for GF as well, since the IO pads are really not that complicated (compared to e.g. sky130...). This would make it possible for each submission to wafer.space to have a different die area, which would of course require a more sophisticated reticle stitching. I would assume there to be one or two standard sizes to enable cost-effective packaging of the dies (if needed). [07/27/2025 12:59] tholin When you say using the existing pad frame from GFMPW, does that mean caravel including the management controller? I have my own (not so good) opinions about caravel, but I don't think I'll be able to test my 3.3V SCL effectively without changes to the IO pads, which I already volunteered to look into sometime soon. [07/27/2025 13:22] tholin TL;DR the existing IO pads are really slow at 3.3V, so pads specifically geared for 3.3V IO voltage (I assume using the low-voltage FET devices instead) is something that is desperately needed. [07/27/2025 13:28] mole99 No, just the pad frame without Caravel. That should work for most submissions. However, if you want to create your own pad frame, feel free to do so. What matters is that the die size stays the same, as that will make the reticle stitching easy. [07/27/2025 13:32] mattvenn and probably use the same position for the wirebond, otherwise you'll have a much higher NRE for doing packaging [07/27/2025 13:39] mole99 Yes, although I think Tim wants to try CoB where such changes could be more easily accommodated? [07/27/2025 13:43] 246tnt I really don't understand how programming a CoB machine is cheaper than programming a wire bonder for QFN ... the packaging made by swissbit is literally doing CoB since they use a PCB as the substrate , so if you find someone that does CoB cheap, why can't they do the same thing as swissbit ? [07/27/2025 13:51] tholin I thought wafer.space won't do packaging? Raw dies only? [07/27/2025 13:51] tholin I was already looking into options for getting dies packaged on my own. [07/27/2025 13:52] tholin Anyways, yeah, that sounds good. So its basically OpenFrame, but for gf180. [07/27/2025 13:52] tholin Hmmmm [07/27/2025 13:53] tholin Yeah, if I make custom IO pads, I can arrange them in the same pattern as is required. [07/27/2025 13:54] mole99 I was thinking more along the lines of doing a few pieces with a manual wire bonder, like you guys did with TT-CoB. That should be enough to verify Tholin's standard cells. Anyway, Tim will have to tell you what he actually has planned for the packaging. [07/27/2025 13:55] mole99 Yeah, kind of OpenFrame but you can change the IO pads. [07/27/2025 13:58] tholin I still gotta understand how the current IO pads work. I took a look at the files in the PDK, but they're very complicated. So I think I'll have to make it a weekend project just to read into the topic. [07/27/2025 14:04] tholin Are there any additional files for these sitting in a repo somewhere that are not part of the PDK download? xschem schematic files would be incredibly helpful. [07/27/2025 14:04] mole99 Let us know your progress, I'm interested in that too ๐Ÿ˜€ But you're in luck, compared to sky130, the IO pads in gf180mcu seem to be pretty straightforward. [07/27/2025 14:05] mole99 I don't think that schematics exist, same as on sky130. Mitch even created the schematics for some of the IOs in sky130. [07/27/2025 14:07] mole99 You have some functional schematics in the docs: https://gf180mcu-pdk.readthedocs.io/en/latest/IPs/IO/gf180mcu_fd_io/tri_state_1.html [07/27/2025 14:11] mole99 Here is the repository for Mitch's gpiov2 cell on sky130 as a reference: https://github.com/d-m-bailey/sky130_fd_io [07/27/2025 14:15] tholin One of the cells in the PDK is marked "gf180mcu_**ef**_io__bi_t". An efabless engineer created it? [07/27/2025 14:15] 246tnt Yeah, it just exports the `ana` signal they needed for caravel for analog stuff mixed with a digital io ... [07/27/2025 14:16] 246tnt (which is not something that exists in the default io cell) [07/27/2025 15:04] tholin Ah. Well, that sucks. [07/27/2025 15:05] tholin But yeah, the functional schematic does look like the simplest possible bi-directional buffer one can build. [07/27/2025 15:06] tholin The only concern I have is that activating PU and PD at the same time appears to generate a short circuit. [07/27/2025 15:10] tholin Actually, it appears to have some additional complexity in the form of the slew rate and drive strength control lines on the output buffer and the Schmitt Trigger enable on the input buffer. Wondering if we really need those for most use cases. Definitely a nice-to-have, but not something I can imagine ever needing myself. [07/27/2025 15:25] tholin Going to build this for now. Nothing fancy. I'll see about experimenting with more advanced features once I get the hang of things. {Attachments} 2025-07_media/image-CCBC8.png {Reactions} ๐Ÿ‘ [07/27/2025 16:19] mole99 Just asking because I don't know any better: Is it not possible to just replace the HV transistor with LV transistors directly in the layout of the IO pads? [07/27/2025 16:40] tholin Technically yes, but the LV transistors obviously have different characteristics than the HV transistors, which concerns me. [07/27/2025 16:40] tholin I know that there is liberty files with characterizations of the IO pads, which I also need to figure out how to generate. [07/27/2025 17:39] tholin Iโ€™ve begun reverse-engineering the existing IO pads. Going to record the information in a google doc soon. [07/27/2025 17:52] 246tnt GF180's 5V IO compatibility is one of the thing making that process interesting. So making IO pads that perform properly at 3.3V while maintaining is what's really needed, along with proper separation of IO and core voltages. [07/27/2025 18:00] tholin The output drivers on the IO pads actually use the even higher voltage 6V FETs [07/27/2025 18:00] tholin Which explains why they perform ultra poorly at 3.3V [07/27/2025 18:05] tholin But makes sense. Gives the chips some upwards margin when operating at 5V. [07/27/2025 19:06] mole99 From what I've heard those aren't different devices, but just a different model for a specific W/L. But yeah, they could probably be downsized then. [07/28/2025 23:06] tholin I present to you: a complete reverse engineering of gf180mcu_fd_io__bi_24t {Attachments} 2025-07_media/image-0579E.png [07/28/2025 23:07] tholin This is a purely "functional" schematic. I did not yet record specific device properties like FET width and length. [07/28/2025 23:07] tholin Turning this into xschem files is next. [07/28/2025 23:07] tholin Top is the input path, bottom is the output path. [07/28/2025 23:08] tholin I think there is still a few things I got wrong, but Iโ€™ll tweak them tomorrow. [07/28/2025 23:09] tholin For my purposes, I technically donโ€™t need to go and make accurate xschem files, but I feel like others will find the information useful. [07/28/2025 23:09] tholin A couple insights [07/28/2025 23:10] tholin The concept of having separate IO and core voltages actually seems represented in these cells. There is two power rails, "VDD/VSS" and "DVDD/DVSS" and a majority of the transistor count here is actually just extensive buffering to translate between the two power domains. [07/28/2025 23:11] tholin There is also significant amounts of protection diodes on internal signals, which makes no sense to me unless said signals cross power domains. [07/28/2025 23:14] tholin Iโ€™ve just spent all day staring at Klayout dissecting layouts, so logging off for today. [07/29/2025 05:07] mole99 Nice work! [07/29/2025 05:09] mole99 Yes, the IO cells were designed for separate power domains. However we only got the 5V standard cell library open sourced. Thus the power domains were tied together afaik. [07/29/2025 07:32] tholin They do not appear to be tied together inside the actual IO cell layout, so if they are, its somewhere else on the chip. [07/29/2025 07:33] tholin In either case, it doesnโ€™t look difficult to untangle the power domains. [07/29/2025 07:35] tholin However, the 6V transistors used in the output buffer are really terrible at switching 3.3V onto the pad, which weโ€™ve practically observed as well. But we know that the 5V FETs are snappy enough for logic circuits, even when powered at 3.3V. So, really, the only thing in the IO cell that needs modification is the final pad drivers. [07/29/2025 07:36] tholin And in particular, youโ€™re looking for something that can do 5V just as well as 3.3V. I have an idea, but let me run some simulations first. [07/29/2025 08:18] 246tnt They are tied together by the actual `dvdd` / `dvss` pad cells. [07/29/2025 08:19] 246tnt But the tracks inside the IO cells that carry `vdd` / `vss` look pretty weak to me. Only ~ 13.5u total width. [07/29/2025 12:49] tholin Makes sense. vdd/vss is the core voltage and just used to power some buffers. dvdd/dvss is the IO voltage. [07/29/2025 12:52] 246tnt In the other techs you still have decently beefy rails for it since the ring in the IO is used to also feed power to the core. Those rings being wimpy here means the added rings in the core will need to be beefier since they'll have to do the whole job. [07/29/2025 15:54] tholin Okay, done {Attachments} 2025-07_media/image-00EC8.png [07/29/2025 15:59] tholin https://github.com/89Mods/gf180mcu_io_re/tree/main {Embed} https://github.com/89Mods/gf180mcu_io_re/tree/main GitHub - 89Mods/gf180mcu_io_re: Reverse-engineered schematics of gf... Reverse-engineered schematics of gf180MCU IO pad cells. - 89Mods/gf180mcu_io_re 2025-07_media/gf180mcu_io_re-303EC [07/29/2025 16:07] 246tnt Did you test if it pass LVS against the extraction ? [07/29/2025 16:07] tholin Nope [07/29/2025 16:08] tholin I would not know how to do that. [07/29/2025 20:33] tholin Okay, so, I had the idea of making an IO pad driver that uses transmission gates to re-wire itself and switch between using high-voltage or low-voltage transistors based on the chip's supply voltage. I threw something together in xschem and simulation looks good on that idea. [07/29/2025 20:47] 246tnt huh ? I have trouble seeing how that would work. Adding a transmission gate in series would surely be worse than using the 5V transistor at 3v3 ... [07/29/2025 20:56] tholin Not like that [07/29/2025 20:56] tholin Its easier I just show [07/29/2025 20:56] tholin {Attachments} 2025-07_media/image-8AD12.png [07/29/2025 20:56] tholin This is simplified. Theoretically, XM5, XM7, XM11 and XM15 could be entire banks of FETs in parallel, just how it is on the actual IO pads. [07/29/2025 20:57] tholin The transmission gates decide which tansistors get the buffer input signal on their gate, and which are disabled. [07/29/2025 20:57] tholin For disabled transistors, it is ensured that the potential difference between their gate and body is 0V. [07/29/2025 20:58] 246tnt But you're exposing the 3v3 transistor drain-source to > 3.3V which they are also not rated for. [07/29/2025 20:58] tholin From what little specs we have on these FETs, this *should* work. [07/29/2025 20:59] tholin Where does it say that? [07/29/2025 20:59] tholin I am looking at https://gf180mcu-pdk.readthedocs.io/en/latest/analog/spice/elec_specs/elec_specs_1.html [07/29/2025 21:00] 246tnt Actually you're exposing the gate to 5V. The transistor are symmetrical, no difference between D and S so when you have the gate at 0V and the "drain" at 5V, you have a 5V potential difference between the gate and drain. [07/29/2025 21:02] tholin Hmm [07/29/2025 21:02] tholin Do we really have some concrete numbers on what the FETs are able to tolerate? [07/29/2025 21:03] tholin The closest thing I can see in the docs is `5 Punch-Through Voltage`, which is higher than a 5V difference even for low-voltage FETs. [07/29/2025 21:05] 246tnt No, not really. [07/29/2025 21:06] 246tnt Maybe @Tim 'mithro' Ansell has access to some SOA. [07/29/2025 21:06] 246tnt There is https://gf180mcu-pdk.readthedocs.io/en/latest/analog/spice/elec_specs/elec_specs_5_4.html [07/29/2025 21:06] tholin I can also just tape it out. Not as a proper IO cell, just that test circuit somewhere on the die. See what happens. [07/29/2025 21:07] 246tnt But by that spec you might as well just use the 3v3 transistor at 5V all the time ๐Ÿ˜… [07/29/2025 21:07] tholin I mean....we can try. [07/29/2025 21:08] tholin My plan for the first shuttle here is it to tape out a 3.3V chip using my SCL and custom IO pads for 3.3V operation. [07/29/2025 21:08] tholin I can sacrifice a few to 5V experiments. [07/29/2025 21:09] 246tnt There is also https://gf180mcu-pdk.readthedocs.io/en/latest/analog/spice/elec_specs/elec_specs_5_5.html [07/29/2025 21:14] 246tnt I don't think they'd immediately die at 5V, I think it's more accelerated degradation and might only show on some percentage of a chip after hundreds or thousands of hours ... [07/29/2025 22:50] tholin Okay, so, basically, we don't know exactly what'd happen. [07/29/2025 23:14] mithro_ I'm sure someone might but I wouldn't trust their answers until it was verified with a real tape out. [07/31/2025 16:15] tholin It would be good to have those estimates anyways. But yeah, I can absolutely tape out some test structures. [07/31/2025 16:25] tholin So, this is kindof an important question for what I wish to do: if customizing the types of IO pads in the pad ring is on the table for wafer.space, does that mean we get access to analog IO (which was frustratingly not a thing on GFMPWs)? ============================================================== Exported 114 message(s) ==============================================================