@jeffdi @Tim Edwards @mehdi, Hi Jeff and Tim, do you know what's this problem? I'm a little confused.

@mehdi @jeffdi @Tim Edwards, Hi Jeff, could you look at this above? I just meet the zeroarea problem and off-grid problem, Tim told me that you know how to solve them...

@jeffdi @Tim Edwards @mehdi, Hi Jeff and Tim, I meet some DRC violations in magic check, can we waive these DRC violations? For the last two violations, we have it before and had waived them.

@jeffdi @Tim Edwards @mehdi, Hi Jeff and Tim, I also meet a layout check failed problem when doing the lvs check, there are some logos and blocks that can't pass it. Can I waive these problem?

@jeffdi @mehdi, Hi Jeff, our GDS just remains the DRC that needs to be waived. Could you help us to pass it? Thank you very much. Attach our GitHub link and efabless project link: https://github.com/Elon-J/OpenFASOC_NIST_PMU_ReRAM https://platform.efabless.com/projects/1090

@jeffdi @mehdi Hi Jeff, our final gds has some DRC related to Openram that needs to be waived. Could you help us pass the precheck? Here is our repo and project link. Thanks! https://github.com/minghungumich/OpenFASOC-RoT-IBEX-AES https://platform.efabless.com/projects/1091

@jeffdi @mehdi Hi Jeff, I use 16 srams with 2k byte size in our tapeout. It is from repo https://github.com/efabless/sky130_sram_macros/tree/dev/sky130_sram_2kbyte_1rw_32x512_8 dev branch. When I opened the klayout with generated precheck marker, it all happens inside the sram macro like this. Can you help us check if it can be bypassed?

I've got a metal density fail on this job. https://platform.efabless.com/projects/1229 Anyway to find out what layer the problem is on? Or by how much the density is?

Hello all, I'm facing a problem with the precheck on the site shown in the screenshot, My repo link: https://github.com/MohamedAliYounis/GP_ASU_G22 Posted in #shuttle-precheck

Hello, is it necessary to use the mpw-7a tag for this tapeout? My macro hardening fails on the openlane version for mpw-7a but it runs ok with the latest openlane image (updated 2 days ago), alongwith with the updated open_pdks. As long as our repo has a Makefile with the openlane tag and open_pdks commit versions used, can we proceed with tapeout? The DRC error here is “DRC errors: Min area of metal1 holes > 0.14um^2 (met1.7)“, and from looking around it seemed that updating openlane was the fix (which did work, this error is not seen anymore)

Hello , where is the activity tab of my Request’? @jeffdi

We have submitted our tapeout like this: does that mean we have done everything?

@jeffdi I have submitted my project successfully and I can't find the request or activity tap, could you help please?

Hello all we passed the precheck half an hour ago and the project is in tape out phase. It is now at step 5 of 7 for the last 20 minutes. How long does it take to finish? Sorry for the last minute question

I'm getting a strange tapeout job error. I have a fairly a large design integrated into the user_analog_project_wrapper. All precheck and tapout checks pass except for the "Klayout Metal Minimum Clear Area Density". The logs show the following layer densities. It's my understanding that these densities represent the % of empty area on each layer. The numbers are significantly smaller than they should be just based on a quick visual inspection (I'm not using even half the available area per layer), and some of the results are even negative which doesn't make sense. Attempting to run the magic metal density check python script returns an error saying the design is less than 700 x 700 um, which is not the case. Could this be an error in error in the tapeout check?

Excuse me. I have some problem with the re submission of MPW7. When I do step 2, to run chip-level static timing analysis for your project integrated in updated Caravel design, I follow this documentation. It will do make install again then "make install_mcw". But I will clone the branch of mpw-8a.

Does that matters?

I have a similar problem with re-submission of MPW7. In order to run new timing analysis, the Makefile re-installed new versions of OpenLane. I then completed mpw_precheck and tapeout and everything succeeded. However, the CI scripts ran a day later and throws errors that the version of OpenLane installed does not match the one tested, and suggested a "make pdk". I am halfway through this, but then realized that this new OpenLane install will probably force me to rebuild my project all over again. Does this make my project now look like a new project and thus does not meet the terms of original submission date, and thus miss the lottery for MPW7 acceptance? What should I do now? It does seem that the CI script is doing the test on user_proj_example, not my project, so do I just update OpenLane and not re-run my project (this will get past the error, but it does seem like a silly rule to get around for timing re-submission testing)?

Hello All, we have our latest version of the online tapeout in the Efabless platform failing, and would like to revert to a previous version which passed the tapeout for submission, is this possible? or do I need to run the previous version precheck+tapeout again? cc @Tim Edwards @jeffdi @Mitch Bailey

Hello All, we have a problem with resubmission of out MPW-7 tapeout. It passes precheck, but fails density checks in tapeout job AFTER Caravel integration and metall fill. Density values reported by tapeout klayout_met_density.log are on the screenshot. It looks like metal fill scripts "overfilled" M2 & M5 a bit. Is there a workaround which could be applied to our GDS to mitigate this issue or nothing can be done without metal fill scripts changes?

This message was deleted.

Hi all , anyone have idea how to deal with this problem as tape out is failed while checking@Mitch Bailey @jeffdi @Tim Edwards any ideas? fom_density_fail.png

Something weird happened to my post-tapeout GDS: the metal fill seems to go out of bound but somehow still passes the tapeout check. I don't think this is the expected behaviour and I can't find what causes it:

Expected:

Erroneous:

Both of them passes the tapeout check

Can I get a clear Idea on what's going on for tapeout run?? I have tried every possible solutions that I got from different resources but my tapeout is failing again and again.. my precheck is all passed: Precheck Id: 03c6e668-01c4-4e5b-b1be-841e58aa9852 Also I don't get the point why there is difference between logs in my jobs for same precheck run ( Warning : 183 shift/reduce conflicts) and the log file saved in galaxy desktop( NO warnings saved here) ?? my tapeout is failing: Tapeout id: 92fbac3a-4dd9-4842-a7bf-d42447e12500

@Mitch Bailey Sir I didn't compress user_project_wrapper.gds file.. I was using this repo with my colleague.. https://github.com/komalg27/matrix_multiply_mpw8.git registered on efabless. Tried with other efabless account and github credentials. New repo https://github.com/radhe-2022/mpw8_trail.git still tapeout is failing with same reason

Has anyone seen this on recent tapeout jobs? This is for a chipignite project, the most recent one 2306Q. Apparently analog support is paused until the tapeout version is updated. Any ETA on that?

[05/09/23 08:48:53 PDT] FAILED
STDOUT: {{Project Local Info}} submission.tar.gz
STDOUT: {{Tapeout Failed}} This version of tapeout does not support analog projects, please try again later.