Gyroscope report

ET-SoC-1 thermal model: what to ask Ainekko for, and the email — Thu 1 Oct 2026 (week 40)

Covers the thermal-modeling request to Roman Shaposhnik and Tanya Dadasheva (Ainekko). Generated Thu 1 Oct 2026 (week 40) ~16:25 PDT on the Intel. Sources: your #community-lab ask of Mon 28 Sep ("CAD files of the layout to do thermal modeling, ie an oas file"), the et-soc1-prototyping findings (origin/main, 1 Oct), Vinci's FAQ, the Hot Chips 33 deck, Ainekko's GitHub repos and the vendor examples linked below.

The email is written; Gmail would not save it as a draft (the connector is still read-only), so it opens from one tap below. It asks for what Vinci's solver reads: OASIS/GDSII for the die, IPC-2581 for the board (not ODB++, which Vinci doesn't list), STEP for mechanical parts, ECXML for a compact package model, and a layer stack-up table in CSV/JSON, plus power maps and material properties. The full .oas layout Eric named may well be blocked by TSMC and third-party IP (the NoC is NetSpeed's; PCIe and DRAM controllers were licensed), so the email offers the standard stand-in: a dimensioned floorplan, a power map from sign-off power analysis, and per-layer metal density.

Send it

To roman@nekko.ai, tanya@nekko.ai · Subject: ET-SoC-1 thermal model: which design files could you share?

Hi Roman, Tanya,

Following up on my Discord ask for CAD files for thermal modeling. Eric Frank (Vinci, which builds fast thermal and warpage simulation for chips and packages; he's planning to come to the lab tomorrow) would like to build a spatial thermal model of the ET-SoC-1. How feasible is it to get the files for that?

Why it's worth doing: everything we have now is lumped. The firmware gives us only the average of the 34 minion-shire sensors, and from it I fitted a single heatsink model (about 1.5 °C/W). But placement clearly matters: in short bursts, the same work on the perimeter shires took 1.6-2x longer to hit the 66 °C throttle than on the interior shires. A spatial model would let us place and schedule work so the die heats evenly instead of throttling.

Vinci's solver reads OASIS/GDSII, IPC-2581, ECXML and STEP, plus a layer stack-up table (CSV or JSON), power maps and material properties. Roughly in priority order:

  1. Die: block outlines and die orientation (minion, memory, Maxion/IO and PCIe shires), where the temperature sensors sit, and per-block power at a known voltage and frequency. Eric's example was the layout as an OASIS (.oas) file. If the layout can't leave the building (TSMC or third-party IP), a dimensioned floorplan with a power map from sign-off power analysis, plus per-layer metal density, would do.

  2. Package: the stack-up with materials (die thickness, bumps/underfill, TIM, lid, substrate layers and copper coverage) and the outline drawing as STEP or DXF; or a compact thermal model (ECXML, or θJC/θJB) if Esperanto or the package house made one. The preliminary datasheet's sections 8 and 9.1, including Tj max, still say "future release".

  3. Board and cooling for the lab's PCIe dev cards: the board file with its layer stack-up (an IPC-2581 export or the Allegro original; et-man links "Board File V3.2" but doesn't include it, unlike the MXM files in et-boards), and the heatsink drawing or part number (STEP ideally) with the airflow it was designed for.

  4. Validation: a signed service-processor firmware build (or the signing route for lab cards) that reports each sensor rather than the average, and any of Esperanto's thermal or power characterization data.

Any subset helps; the floorplan with power and the package stack-up matter most. We're happy to sign an NDA, keep the raw files off the public pages and publish only derived results. Vinci's tool runs on-prem, and they don't train on customer data.

Could you check what came over with the Esperanto IP? Happy to talk it through tomorrow.

Thanks, Yaroslav

Eric isn't on it. Cc eric.frank@vinci4d.ai if you'd rather he field format questions directly.

What a thermal model needs, and what is already public

Level What the model needs What's public What the email asks for
Die Block outlines and orientation; power per block at a stated V/f; sensor positions 570 mm², 89 mask layers (Hot Chips 33); a ~527×456 px die plot; 34 minion + 8 memory + Maxion/IO + PCIe shires on a 6×6 grid; 35 temperature sensors, one per minion shire plus one in the IO shire, and none in the memory shires (et-platform PVT driver). Die size 25.6 × 22.2 mm is your estimate from the plot The .oas/.gds, or a dimensioned floorplan + power map + metal density
Package Stack-up per layer: thickness, material, k in x/y/z (Vinci's native CSV/JSON); outline as STEP 45 × 45 mm body, 44.8 mm lid, 2,494 balls, ≤3.95 mm tall (datasheet Fig. 9-1, image only). §8 (ratings, incl. Tj max) and §9.1 "Package Thermal Information" say "future release" Stack-up + materials, outline as STEP/DXF, or an ECXML / θJC / θJB compact model
Board + cooling Board stack-up and copper (IPC-2581); heatsink STEP; airflow and ambient Ainekko's MXM module is fully public in et-boards (Allegro .brd, Gerbers, OrCAD, BOMs). The PCIe dev card V3 in the lab is a scanned PDF only; no heatsink drawing anywhere The dev card's board file (IPC-2581 or Allegro), heatsink drawing/part, design airflow
Validation Per-sensor temperatures vs workload; per-rail power; IR or thermocouple points The host API gives only aggregates (minion-shire average); per-rail power you already log; your lumped model (1.47 °C/W network, leakage feedback) is the baseline a spatial model must match A signed firmware that reports each sensor; Esperanto's characterization data

Is there anything ready-made for a similar chip?

No public thermal model of any 7 nm many-core accelerator exists, and nothing for the ET-SoC-1 itself. What exists is useful as precedent and scaffolding:

Sources

Total life satisfaction: this turns a week of solo lab measurements into a joint project with Eric, with a concrete deliverable: a heat map you can schedule work against.