cleanup gds directory

[proppy]

Is it intentional that the gds/ directory already contains the hardened project + wrapper?

This could be confusing for developers who expect that the test and mpmprecheck would fails until they actually go thru the step of hardening their design.

[SaraEfabless]

we purposely want the GDS there, so, ppl dont have to generate it to see the design or to run check LVS, maybe in the future to have a GDS inside the repo.

[proppy]

I'd like us to revisit this, since this is causing extra confusion with the recent gf180mcu support, see #176

The project being used as a multi-technology template now, its result dirs should really be empty.

[mattvenn]

Yes I just got hit by this myself. I think especially now we are supporting multiple PDKs, these binaries should be deleted.

[mattvenn]

@SaraEfabless it's kind of difficult to just run LVS on its own. IMO it's better if people build the GDS, then they can check all the results and know that the artifacts are generated by the current tools and pdk.

[proppy]

alternatively, the github action could generate the gds for sky130 and gf180mcu and commit them to a different branch?

That would be assuming that the efabless platform is capable of fetching a different branch than the default one for a given tapeout.

@jeffdi any thoughts?

[proppy]

One possible way to address this could be for the efabless platform to support pulling artefacts from non-default branches allowing users of this repo to keep main for designs and configurations and keep all the generated files in dedicated technology-specific branches.

Curious what others think?
@mattvenn @QuantamHD @mithro @RTimothyEdwards @jeffdi

[mattvenn]

I think having a different branch specified would be good. Then it could be possible to have one repo for gf180 and sky130