Somewhat blunt question: how incredibly unsophisticated can a project be and still qualify for submission? Given there's a week until submission, my verilog skillset is somewhere around "userspace contains wishbone-addressable register latching a single word, that when read returns that register xor `0xaaaaaaaa`". This would perhaps be a waste of a tapeout. On the other hand, https://fossi-foundation.org/2020/06/30/skywater-pdk extensively discusses "open source, no further strings attached" and "democratizing hardware design, a chip for everyone", and in those terms I am perhaps the ideal program participant. Certainly if Google and SkyWater are gracious enough to fund effectively a hands-on self-study course on chip design, in exchange for incidental platform/toolchain beta testing, I will jump on the opportunity :)

@User there are a few people doing "mega-chips" with several different projects multiplexed together (with wishbone and I/O provided to each) - it may be more efficient to try to see if one of those would accept your project, perhaps?

That does make sense! Could you point me to any further information on those? I'm not seeing any other hits in slack search for "mega" or "megachip"

@Matt Venn is doing one

Sweet. I think my rough plan right now it to check out @Kunal's course to see if I'm in way over my head, and maybe try to get the tooling running locally in the interim On a scale of 1 to 10, how would you rate the accuracy of the following statement: if I clone https://github.com/efabless/caravel and put my experimental logic there, and it passes prechecks etc, a git merge with your or matt's or other megachip project will result in the build either succeeding with the combined result, or failing cleanly with "not enough mm²"?

For the megachip, the approach would be more of building the core directly with openlane as its own macro, and then copying the GDS/LEF and verilog (the main concerns with the precheck is just making sure all the licensing is good in that case) into the mega-project, where it can then be manually placed and connected to the rest of the design.

@Anton Dyudin The verilog is just a tiny part ... at the current state of things, going from working (fpga tested / simulated) verilog to something passing in OpenLane is still a massive amount of work.

@Anish you can take a look at https://github.com/mattvenn/multi-project-harness

@Anton Dyudin ^

thanks @Anish I meant to @Anton Dyudin

@tnt can you mention some of the steps that are a "massive amount of work" regarding openlane?

When (and if( I figure them out, I will ...

@tnt I did get stuck with openlane crashing during converting the caravel example user project

crashes (segfault) / placement errors / routing not finishing / disconnected power / LVS errors / DRC errros / Antenna Errors ... I think I've have a lot of different stuff.

Alright, that is kind of disturbing. Good info.

Now to be clear, I already find it amazing that it works at all given the relatively short amount of time this has been done in and the complexity of those issues. I know the devs are working hard on it and it's definitely come a long way. I'm just trying to highlight that if you want to submit something, the time to work on the verilog alone was ... in the past and that by now you should be working on getting it through the flow if you want something.

What version of openlane are you using?

develop

branch.

ahh

my own experiience has been that all my designs apart from the tiniest have gotten me finished gds files with no fatal errors

@Matt Venn what issues have you been having with the combining designs?

@Matt Venn That's probably because I'm using macros, so I end up hitting all the issues you're having now right from the start.

yep

Do you actually get down to 0 DRC errors and 0 Antenna violations (both with Magic and OR antenna checks) ? The flow doesn't actually error out on those, they're just burried in the logs ...

oh btw, I only just learnt about this file: runs/xxxx/reports/final_summary_report

huh, I've been able to get 0 DRC and 0 LVS pretty reliably (at least when not pushing the density too hard) but always end up with ~50-100 antenna violations (mostly on ~1.5 sqmm designs, although never gotten down to 0)

Yeah LVS is not too hard. If it fails, it usually has good reasons. DRC ... the router keeps doing weird stuff to me with one of the FF resulting in a DRC violation, but it's not too frequent (I get maybe 4 / 5 of them) and they're easily fixable by hand. Antenna ... much more issues and some are hard to fix by hand. Also by default it only runs the OR antenna check. Doing the magic antenna check, I get other violations (which ... look real when looking at the final GDS).

oh yikes

I don't patch the GDS, I usually edit the DEF. I have a custom

tcl

script that does the flow only up to routing. Then I fixup the

DEF

, then I have another script that does the rest of the flow.

ah ok, is this script on GH by any chance?

It's not. But it's really just the

flow.tcl

but with in first place with everything before/after the

global_routing

step commented out.

I'm now imagining a

git rebase

like flow, opens up

$EDITOR

in the middle to let you patch things…

yeah, being able to either hook custom step or replace functions or "pause" until you can go fix things would be useful.

Yeah, it'll need to be reproducible for the final precheck anyway right?

Don't think so no.

has some differences of opinion, but sounds like "commit the final fixups as a patch" at minimum At least in theory :P

Yeah, I asked here if having to manually patch things was acceptable and was told it's fine.

I suppose similarly to the goal being for the router to produce results that don't need patching, fair enough!