Thermal Files Search — Sun 11 Oct 2026 (week 41)

An exhaustive search of the Esperanto archive on mordast for thermal-modeling and IC-layout files, done Sun 11 Oct 2026 on the Intel (private door, ~/git0/aifoundry, session 4405afb9), on your ask: find the thermal files, figure out the homegrown formats, chase the tar files, map where else the data could live, and feed the Vinci4D (Eric Frank) layout question. It extends the 1 Oct thermal-model-files report, which defined what Vinci's solver reads; this one says what the vault actually holds. Method: a research pass on what files mark thermal work (15-option tool/format survey, 11 Oct), then a classifier over the browser's index (124,477 Drive names, 10,165 Jira + 10,587 Confluence attachments, 554,045 commits) plus a walk of the 435-repo design mirror, plus looking inside the archives. Everything below is file metadata — names, sizes, dates, formats — never file contents. NDA: this page is private and unshared; locating a layout file is not clearance to move it, and nothing is exported to Eric without Roman's review.

The bottom line

• There is no OASIS anywhere and no full-chip GDS. A census of the whole design mirror finds 0 .oas/.oasis and 127 real .gds (473 MB), every one a third-party macro: the Movellus LVD-PLL (189 MB) and Moortec sensor macros (16–24 MB). None is Esperanto's die, and all carry TSMC/vendor IP — the opposite of the "clear of TSMC" file Eric asked for. This is not a mirror gap (below): the layout simply was not kept as a merged mask database here.
• The real geometry that exists is abstract: block-level DEF floorplans, and they are substantial — minion_top 157 MB, TBoxWrapper 180 MB, memshire_west_side 370 MB (gz), spio 130 MB (gz), plus partial soc_top. These give die/block outlines, placement and the power grid, which is enough to derive a thermal floorplan, but they are TSMC-7nm / Samsung-SF4 physical databases, so they still carry foundry IP.
• The thermal/power modeling is homegrown, exactly as you expected, and it is in Drive, not the design repos. The power estimation/ folder is a 2017–2018 flow built from Excel, MATLAB, Perl, HSPICE and custom text formats — minion_tdp.m (MATLAB, computes junction temperature Tj from power), stackfin (per-standard-cell fin/transistor counts — literally "heat by transistor"), .condense activity traces, PrimeTime-PX .frpt power reports and _power_hier_*.report per-block breakdowns, PowerEstimationMaster.xlsm. No commercial thermal-solver file exists.
• The git "thermal" hits are firmware, not modeling. The thermal directories in the mirror are Linux kernel thermal drivers (maxion-linux/.../thermal, thermald) and the Rodinia hotspot benchmark — on-chip thermal management, not a thermal model.
• The 48 SDK tarballs (2.1 TiB, 87.9% of Drive) are software, not design data: each et_sdk_tools_*.tar.gz opens on et_sdk_tools_wheels/ (numpy, matplotlib, PyYAML…). A 150 s interior scan of one found no layout/thermal files; the full 2.1 TiB was not exhaustively unpacked (see "where else").
• git-LFS is a near-dead end. 35 repos use LFS, but for images and ML bundles; only a couple of design files are pointer-only (the gepardo copy of the PLL GDS, and a LFS-tracked maxion_top.def.gz). The missing full-chip layout is genuinely absent, not stranded on an LFS server.
• The most likely home of anything missing is archive/eng — the one export mordast cannot mount (address- restricted) — then the dangling Google-native Sheets and the unrestored engineer home directories. Concrete asks are on Requests for Roman.

1. Layout files — for Eric Frank (Vinci4D)

Eric's solver reads a die layout (OASIS/GDSII) or, failing that, block outlines plus per-block power. What the vault holds, by format (whole mirror; counts include ~3–4× duplication across the esperanto-soc, et_soc_1_5_tsmc7nm, et_soc_2_pd_tsmc7nm and et_soc_2_pd_sf4lpp copies):

What this means for Eric. There is no file that is both the real die geometry and clear of TSMC. The two honest options, both consistent with the 1 Oct email: 1. Derive a block-outline floorplan (die rectangle + one rectangle per shire with x/y/w/h, plus per-block power from §2) from the soc_top / minion_top DEF. This is the HotSpot-style "one row per shire" model — it carries no TSMC geometry, so it is the cleanest thing to share, and it is buildable from what is here. 2. Share a block-level DEF/LEF (e.g. minion_top), which has real placement but is a TSMC-7nm database and so needs Roman's and likely TSMC's sign-off. Heavier, and not "clear of TSMC".

Either way the decision is Roman's; this report only establishes that option 1 is feasible from vault data today.

2. The homegrown thermal/power flow — power estimation/ (Drive)

This is the "old-school homegrown formats" you pointed at. A 2017–2018 power-and-thermal flow, all in Drive at /archive/gdrive/power estimation/, built from spreadsheets, MATLAB, Perl, HSPICE and custom text — no commercial thermal tool. The pipeline:

So the "thermal model" is a MATLAB/Excel calculation (minion_tdp.m turning a per-block power map plus a stack/fin model into Tj), not a solver database. The ingredients Eric wants — per-block power at a stated V/f — are here, in the .report hierarchies and the .xlsm.

3. Vendor thermal engagements, sensors, measurement

• Ansys RedHawk-SC (electrothermal / power-integrity), under Third Party Engagement/Ansys/Redhawk-SC/ (Gepardo / ET-SoC-2): mostly training and manuals — including an "On-die Thermal Self Heat Analysis and Electromigration" deck — plus small 2024 driver scripts (input_files.py, run.py, a 20 KB RTL_VCD.tar.gz). Vendor material and a started flow, not a body of Esperanto thermal results.
• Moortec thermal diode (on-die temperature sensor IP) under Third Party Engagement/Moortec/ThermalDio… and in the cad/home-cad-ip/moortec GDS — the sensors the firmware reads.
• Measurement side is the live lab work, not the archive: the thermal-camera hub (P3 on the card, lock-in thermography, the 34-sensor firmware). That is where per-sensor validation data is coming from.

4. Where else the files could be (the theory)

Ordered by likelihood of holding real thermal/layout data:

1. archive/eng — the one export mordast cannot mount (address-restricted to 10.20.10.0,10.10.1.0; mordast is 10.20.10.72). The likely home of the signoff run areas (RedHawk/Totem/Voltus EM-IR and self-heat results), tool installs, the pre-2017 depot, and the merged tapeout database if one was kept. The single best place to ask about.
2. The dangling Google-native Sheets. The Drive rclone logs show "Original Esperanto Shared Drive" reached only as a shortcut, and 52 Google Docs/Sheets never followed — their names are the power/thermal wish-list (PrimeTime timing summaries, power characterization planning, PMIC, NoC power, ET-SoC-2 power rails, PTPX experiments, SLT shmoo). Live Sheets, not copied. A Drive re-export with shortcuts resolved would capture them.
3. The unrestored engineer home directories. 45 of the 54 home/<name> exports are empty placeholders — the ex-Esperanto roster, provisioned and waiting for a restore. Individual thermal/power scratch work (MATLAB, scripts) would live there.
4. git-LFS objects. A git lfs fetch on the mirror would pull maxion_top.def.gz and the gepardo PLL GDS. Small, but maxion_top.def.gz is a real block floorplan worth having.
5. The 48 SDK tarballs (2.1 TiB). Structurally software (Python wheels); a bounded interior scan found no layout/thermal, but they were not fully unpacked. Low probability, high cost — only worth a full pass if 1–3 come up empty.
6. DRM-locked vendor PDFs (314 × 403 on the Drive copy). TSMC/Synopsys databooks with the material/thermal- conductivity and stack-up numbers the model needs — these largely never arrived; they come from the foundry, not the archive.
7. The TEAM Confluence space and the unmounted parent archive/esperanto export — not exported / not mounted.

5. What's actionable now

• For Eric: a clear-of-TSMC block-outline floorplan is buildable today from the soc_top/minion_top DEF plus the minion_top_power_hier power reports — no foundry IP. That is the fastest unblocked deliverable and matches the 1 Oct email's option.
• For the homegrown model: minion_tdp.m + stackfin + PowerEstimationMaster.xlsm are the existing thermal model; they can be read and re-run to produce per-block power/Tj for the current workloads.
• For Roman: the asks (mount archive/eng, resolve the Drive shortcuts / re-export the Sheets, git lfs fetch, restore the home directories) are on the Requests-for-Roman page. The world-writable auto.home-select autofs bug is flagged there too, as a thing to fix — it was not used.

Artifacts

• Browse & search these files: the Thermal tab on the archive browser — http://100.96.72.114:8792/thermal (nekko.ai tailnet) — category chips, keyword search, facets by source/extension/repo. Built from thermal_search.py (source).
• This report: tailnet
• Requests for Roman (the data-source asks): spacesheep (private)

Total life satisfaction: this pins down what the vault can and can't give Eric today — a derivable, clear-of-TSMC floorplan now, the rest waiting on archive/eng — and turns the "where are the thermal files" question into a short list Roman can act on.