What is stream-out (GDSII/OASIS), and what must be in it?

Short Answer

Stream-out writes the finished layout as a GDSII or OASIS file, the format signoff tools and the foundry read. The file must contain the full layout: top-level routing and power, the real standard-cell and macro geometry merged in, metal fill, pin text, and every shape on the layer and datatype numbers the foundry expects. Anything missing or mis-mapped is invisible to signoff, so a clean check on an incomplete stream proves nothing.

Technical Explanation

• write_gds (ICC2) and write_oasis (ICC2) write the current design to a stream file. OASIS is a more compact format for the same data, useful when GDS files get very large.
• ICC2 libraries often carry abstract or frame views for cells. The final stream needs real cell geometry, so the standard-cell and macro GDS or OASIS files are merged in with write_gds -merge_files (ICC2). The command first merges the listed files into an intermediate file, then merges the new stream with it.
• Layer mapping decides which ICC2 layer and purpose becomes which stream layer and datatype. write_gds -layer_map (ICC2) supplies the mapping file. A missing entry means a shape is dropped or lands on the wrong layer, which can make DRC pass on data that is not there.
• Fill is included by default: write_gds -fill (ICC2) takes include, exclude or fill_only, and include is the default. Writing fill only, or excluding it, is sometimes done to hand fill to a separate flow, but the tapeout stream needs it.
• Pins are written as text and geometry by default (write_gds -output_pin all (ICC2)). Text labels name nets for LVS, so losing them turns every port into an unnamed net. Names are limited to 32 characters unless you use write_gds -long_names (ICC2).
• signoff.physical.merge_stream_files (ICC2) is a different thing. It tells IC Validator In-Design checks, such as signoff_check_drc (ICC2), to read the real GDS or OASIS of listed cells instead of library views. It does not change what write_gds (ICC2) writes.
• After stream-out, check the file itself: rerun DRC and LVS in IC Validator on it, not on the ICC2 database.

What To Check

• Every macro and standard-cell library has a matching GDS or OASIS in the merge list.
• The layer map covers every routing, via, cut-metal and text layer the runset reads.
• Fill is present in the stream when the tapeout flow expects it there.
• Top-cell name and pin labels match the reference netlist used for LVS.
• A clean IC Validator DRC and LVS run on the streamed file.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): All cell GDS merged, no unmapped layer warnings, and IC Validator DRC and LVS on the stream are clean.
• Suspicious (illustrative): Stream-out warns about a few unmapped marker or blockage layers the runset does not read; document them.
• Hard stop: LVS on the stream fails with devices missing inside every macro, a sign that macro GDS was never merged.

What The Interviewer Is Testing

• Understanding that signoff checks only see what the stream contains.
• Knowing the difference between merging at stream-out and signoff.physical.merge_stream_files (ICC2).
• Awareness that a layer map error can hide violations instead of creating them.

Follow-up Question & Model Response

"Why run IC Validator on the streamed GDS if ICC2 In-Design checks were already clean?"

Candidate Model Response: In-Design checks read the ICC2 design library, often with frame views for macros unless you configure otherwise. The stream is a new file produced by a translation step with its own layer map and merge list. Any mapping gap, missing cell GDS or name truncation happens there. Running IC Validator on the exact file the foundry receives is the only way to prove that file is clean.