16nm FinFET AI Chip Tape-Out Summary

This project began around the same time last year, and after a year of “process flow”, we finally received the PDK and digital library 20 days before tape-out. One cannot help but marvel at the efficiency of the team. It took a week to familiarize myself with the process, and the tape-out design was completed within two weeks. The post-simulation is still ongoing, but the GDS had to be submitted. Initially, I planned to work on some RF circuits, but various frustrating issues made it hard to express. “I hope the chip works properly upon return, but it seems a bit unlikely. Even if the team is top-notch, the tape-out summary must be recorded. Which is more satisfying, tape-out or watering? I think a chilled cola is more refreshing.” —- Promises and WordsChip name: ApolloUnresolved issues (I hope those who have encountered similar problems can advise):1. Most of the team members’ first task upon arriving at the lab is to chat with someone. They can chat for hours without doing anything. Their loud conversations and laughter are as excited as baboons after mating. One can imagine how I feel during tape-out with such a group of abstract individuals yelling next to me (unfortunately, audio files cannot be attached to public accounts). I reminded them last semester, but it remains the same. Given that a considerable number of teachers also behave this way, I understand it as part of their culture. Can someone explain to me if this is part of Japanese culture? It feels inappropriate to criticize others in their territory.2. Due to the tight tape-out schedule, I repeatedly urged the team to apply for the PDK, digital library, and MC. He insisted that all materials had been applied for and uploaded to the server, but upon checking, I only found the PDK. After further inquiry, he still firmly stated that the materials were complete and told me to use them directly. In desperation, I asked my boss to reapply myself. Eventually, he admitted that some materials (like MC, IO) needed to be applied through TSMC, causing a week of delays. I later discovered that part of the IO library was missing and asked him to confirm why TSMC did not provide PAD and PIO cells. He ultimately replied that these were all that were available and told me to proceed. Reluctantly, I had to modify the AIO and design the PAD for tape-out myself. Although it seems trivial, it was quite frustrating. Additionally, I wanted to ask, is it true that TSMC’s process cannot provide PIO and PAD cells? Is it that TSMC doesn’t have them, or did the team not consult properly? They also mentioned only having 1P10M IO, not 1P13M IO. I was left confused.3. While debugging the 16nm PR script, there were some inconsistencies between the PR technical document (.tlef) and the QRC file (qrcTechFile). For example, Innovus reported logs:

#layer[3] tech width 76 != ict width 64.0......

Upon inspection, I indeed found mismatches between the ict file and tlef, but I confirmed multiple times that I had not selected the wrong metal layer scheme. I contacted the team several times regarding this issue but received no response. Will such mismatches pose significant risks for subsequent tape-out? For instance, timing inaccuracies, etc.Resolved issues:

• Boundary Cell is somewhat complex: The boundary cells for this process are quite troublesome; to meet DRC requirements, eight different cells must be used. Boundary TAP cells need to be added at the upper and lower boundaries, and some boundary units need to be manually flipped, with limited support from the PR tools in this regard. In contrast, the 22nm process is much simpler.

• Tech LEF fails to fully recognize power rings: When adding the Power Ring, Tech LEF cannot correctly recognize the definition style <span>{VDD VDD VSS VSS}</span>, ultimately only allowing the addition of <span>{VDD VSS}</span>, which is frustrating.

• Fin Grid related DRC should be checked early after Floorplan: Since this process is based on FinFET, it is recommended to conduct Fin Grid related DRC checks immediately after completing the Floorplan, especially focusing on off-grid errors in the IO area to reduce iterations.

• Routing direction must be unified from the start of PDK: The vhv and hvh routing strategies correspond to completely different DRC rules (for example, MINP and Non-MINP layer definitions differ), and should be selected from the PDK installation stage, ensuring consistency with PR tool configurations.

• Metal color change errors in Innovus can be ignored: Such DRCs will not report errors in Calibre and do not require special handling.

• Some standard cells have difficulty with pin extraction: Certain std-cells have issues with pin extraction, and it is recommended to disable them directly to avoid routing failures.

• CPOD type std-cells have not been verified: CPOD related cells were not tested in this tape-out due to time constraints. If there is another opportunity to tape-out this process, it can be considered for testing.

• IO area RTE Cell design is not user-friendly: The routing of the PR tool may mistakenly pull connections into the IO area, causing DRC errors. This can be bypassed by modifying the Netlist before PR, but remember to restore the original state when exporting the netlist after PR (e.g., <span>.POCCTRL(POC),.RTE(RTE), .ESD(ESD)</span> and other ports).

• DTCD Dummy cells need to be enabled: Some BEOL layers require DTCD dummy filling, but not all layers are required, depending on the process documentation.

• Macro design recommendations: When conducting macro design, use <span>cutObsToExposeRouting</span> to leave enough margin to ensure smooth pin extraction during the PR phase. The 22nm process has fewer restrictions in this regard. Additionally, when using <span>write_lef_abstract</span> to extract LEF, it is recommended to retain only power lines at the top level to avoid signal line extraction failures.

• M4 Min Step DRC issues are frequent: This rule generates many DRC errors that need to be manually fixed one by one, resulting in a large workload.

• WB DMY layer must be added for PAD: Omitting this will cause DRC failures, so special attention is required.

• Distance requirements between PAD and Chip Boundary: The process requires a minimum distance of 10μm between the two. I once left only 5μm, which led to having to execute a complete PR process again, sigh.

• Chip Boundary can be drawn directly next to Seal Ring: The Chip Boundary can be drawn directly along the inner edge of the Seal Ring, and corner overlaps will not pose any issues.

• Complete Flash Model files are required for simulation: When simulating Flash, all necessary files, such as SFDP.TXT, must be included; missing them can lead to simulation failures, a hard lesson learned.

• Combinational Loop affects simulation efficiency: If a combinational loop is not broken or SDF simulation is not used, it will significantly slow down simulation speed. It is recommended to manually break the loop or enable SDF format simulation.

• IMPSPS error bug during PR: Loading a DEF format floorplan directly for PR will result in errors (e.g., if there is no valid placement location), while manually operating the floorplan before PR does not have this issue, initially judged to be a tool bug.

• M1.GO.1/2/3 rules are complex and tools cannot recognize them: Such DRCs cannot be recognized by Innovus and need to be manually identified and fixed through Calibre.

• Clock settings during synthesis require special attention: When the clock is bound to certain cell pins, the logical structure after synthesis must be carefully checked to prevent incorrect constraints from leading to erroneous synthesis results; the tool may not report errors, but the logic could be wrong.
  Supplement: Must add CutOD Dummy.