[Hypothetical] 'the fab stopped communicating with us as we are too small of a fish in their big pond'... yup, shit happens, maybe

This one is the closest to what's going on, as we are pretty low priority for these foundries. Without casting blame all around, we are still recovering from issues of trying to get the tool flow working starting two years ago when the tools themselves were still under heavy development. That resulted in mostly-not-working silicon for MPW-one. We had to rework everything for MPW-two, but the ripple effect from that caused a massive delay in everything up to MPW-seven. In theory, the delays should be getting shorter for each successive MPW run, although I can't really say that because only a few are out of fab so far. On top of that, Google put a hold on MPW-three through five, waiting on results of MPW-two, so we are currently unable to move those forward at all.

Kudos to FOSSi and efabless community!!! Keep on keeping on. 👏

You make it sounds like mpw-one was an tool issue but afaik it was a methodology issue.

@Matt Liberty: If you want me to cast blame all around, then sure, I can be more specific about who/what was at fault. At the time of MPW-one, either OpenROAD did not have clock tree synthesis, or else the Openlane team did not believe that it had clock tree synthesis; regardless, they wrote their own clock tree synthesis tool, apparently without any understanding of how clock tree synthesis works, and thereby generating a layout that undermined just about everything that the OpenROAD tools were trying to accomplish, and moving the state of the art about two steps backwards from what I had achieved a year earlier with qflow. Anyway, I'd call that both tools and methodology.

@Tim Edwards my point is that after saying you wouldn't cast blame I felt you did. I wasn't clear what tooling you were referring to and didn't wish OR to be viewed as to blame if it was not.

My opinion on OpenROAD is that it is currently Saving the World, even if we have to wait a little bit for it (on a related note. . . Are you working on UDP UPF?)

🙂 Do you mean UPF? I don't know what UDP is?

Yes, UPF, sorry.

Yes it is in progress. We are currently working on global placement to respect the region constraints

Any vague estimate on when that will be ready for use, or at least for testing?

I hope it is two months but resources are always the issue

("UDP" is "user defined primitive" in verilog. Don't know why that popped into my head.)

[I thought of that but we definitely aren't working on that ;)]

I don't think we would be able to make use of it in any timeframe sooner than maybe four or five months, but looking ahead, we want to make use of the LP (low power) library for future designs, and there are a lot of power gating cells in that library with standby power rails and such..

We are first targeting gating and leaving level shifting to a later step

130nm is a pretty old process by today's standards, but ultra-low-power design is a nice niche market for it.

@Tim Edwards what about MPW-8? Is this also on hold (as per Google putting 3-5 on hold)?

@Andrea Mifsud: No. 3-5 are on hold because they used the same Caravel design as MPW-2, and Google wanted to make sure that MPW-2 designs were testable with workarounds before releasing 3-5 as-is (as opposed to scrapping those runs, and re-running all the projects with an updated Caravel design on a future MPW run).

that makes sense for those runs. I was just wondering whether there is something similar going on for MPW 8 as its status is shown as submitted, and thought maybe its on hold?