Yes, if you have Cadence licenses, you can follow our labs: https://github.com/EECS150/asic_labs_fa21 (sky130 option), which will generate layout. Lab 6 doesn't have a Sky130 version, because OpenRAM doesn't mix well with other memory macros, we may have some alternatives in a few months. Behind the labs is a tool called Hammer: https://github.com/ucb-bar/hammer/. There is an e-mail alias through which you can ask for non-public plugins for commercial tools.

Why doesn't openram "mix well with other memory macros"?

Clocking scheme is different than ASAP7 (or TSMC), so it is not a drop-in replacement.

Ah, we are offering alternatives to that if you don't like it using the two halves of the clock.

We would welcome a PR...

If you have issues with OpenRAM, you should file them in github.

It is not an issue, it is a design decision...

Github issues have bugs, feature requests, etc. So there is a category for that.

Thanks @User for the pointers.

@User So ASAP7 still doesn't have SRAMs and this just uses fake ones?

Yes, ASAP7 memory is fake, but its front-end views mimic a typical foundry macro. We can do the same for Sky130 (make a fake macro), but that defeats the purpose, IMO.

That means the clocking scheme is arbitrary for ASAP7 as well.

No it doesn't. It matches what commercial processes use. The idea is to have the same RTL generation process be able to target a variety of processes. We can probably make a Sky130 macro that conforms to that, and then OpenRAM can match it. That will happen probably a couple of months, the priority is to get the version of a flow (and these labs) that work with open EDA tools (OpenROAD).

Well, you could just change OpenRAM to incorrectly use a different behavioral model since the ASAP7 one is fake anyways...

That would be good. We avoided having fake stuff in sky130, because it is a real process, and our flow should make things that are physically realizable.