wafer.space Community

I've begun work on a SCL for gf180mcu using 3.3V transistors

23:56

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.

23:56

3.3V gf180 is at least as fast as sky130_fd_sc_hd

1

23:56

But most likely faster

23:57

It trades punches with my sky130_as_sc_hs SCL, which outperforms fd_sc_hd by a wide margin.

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.

4

@Tholin - Awesome work!

DFF done. About to test it all in a flow for the first time. And then its time for an initial commit to GitHub.

1

19:55

Gimme a minute for the commit

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.

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

15:41

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.

1

3

15:42

And since I've done this before, I can copy my own work from sky130_as_sc_hs

1

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.

you could try asking here: https://yosyshq.discourse.group/

YosysHQ

A place to discuss YosysHQ software and tools

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

Tholin

AS2650v2 Bad Apple Demo

2

18:47

Audio also generated by the AS2650v2, but recorded directly from the DAC output. That piezzo is...not good.

@Tim 'mithro' Ansell nice seeing you at open sauce... Hopefully I can find a way to contribute to the first wafer.space shuttle.

1

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.

1

17:01

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.

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.

2

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

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.

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.

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.

and probably use the same position for the wirebond, otherwise you'll have a much higher NRE for doing packaging

Yes, although I think Tim wants to try CoB where such changes could be more easily accommodated?

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 ?

I thought wafer.space won't do packaging? Raw dies only?

13:51

I was already looking into options for getting dies packaged on my own.

13:52

Anyways, yeah, that sounds good. So its basically OpenFrame, but for gf180.

13:52

Hmmmm

13:53

Yeah, if I make custom IO pads, I can arrange them in the same pattern as is required.

tnt

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 ?

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.

Tholin

Anyways, yeah, that sounds good. So its basically OpenFrame, but for gf180.

Yeah, kind of OpenFrame but you can change the IO pads.

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.

14:04

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.

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.

14:05

I don't think that schematics exist, same as on sky130. Mitch even created the schematics for some of the IOs in sky130.

14:07

You have some functional schematics in the docs: https://gf180mcu-pdk.readthedocs.io/en/latest/IPs/IO/gf180mcu_fd_io/tri_state_1.html

14:11

Here is the repository for Mitch's gpiov2 cell on sky130 as a reference: https://github.com/d-m-bailey/sky130_fd_io

One of the cells in the PDK is marked "gf180mcu_ef_io__bi_t". An efabless engineer created it?

Yeah, it just exports the ana signal they needed for caravel for analog stuff mixed with a digital io ...

14:16

(which is not something that exists in the default io cell)

Ah. Well, that sucks.

15:05

But yeah, the functional schematic does look like the simplest possible bi-directional buffer one can build.

15:06

The only concern I have is that activating PU and PD at the same time appears to generate a short circuit.

15:10

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.

Going to build this for now. Nothing fancy. I'll see about experimenting with more advanced features once I get the hang of things.

1

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?

Technically yes, but the LV transistors obviously have different characteristics than the HV transistors, which concerns me.

16:40

I know that there is liberty files with characterizations of the IO pads, which I also need to figure out how to generate.

I’ve begun reverse-engineering the existing IO pads. Going to record the information in a google doc soon.

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.

The output drivers on the IO pads actually use the even higher voltage 6V FETs

18:00

Which explains why they perform ultra poorly at 3.3V

18:05

But makes sense. Gives the chips some upwards margin when operating at 5V.

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.

I present to you: a complete reverse engineering of gf180mcu_fd_io__bi_24t