Skip to article
ZF. Back to portfolio
PortfolioResearch practiceCodex × TCAD

Research practice · June 2026 · Simulation only

Codex × TCAD: turning one ATLAS deck into an auditable research workflow

I did not ask Codex to imitate a device simulator. I built a harness around my local Silvaco ATLAS environment so that paper reading, deck generation, solver execution, metric extraction, and scientific stopping decisions could share one traceable state.

H-diamond FETSilvaco ATLASPython post-processingHuman-gated agents
8
gate lengths from 2 μm to 50 nm
6
trace layers from assumption to claim
1
blocked result deliberately kept visible
Context

The project did not begin with a prompt

This research-training project studied lateral scaling in H-terminated diamond FETs by reconstructing a published device in two-dimensional TCAD. I already had a working diamond.in deck, local Silvaco access, preliminary curves, and prior experience with short-channel and RF analysis from my coauthored In₂O₃ TFT study.

The missing piece was not another isolated plot. It was an engineering structure that could keep the paper, physical assumptions, parameterized experiments, raw solver outputs, metric definitions, figures, and failure decisions synchronized across a long-running task.

Project-generated cross-section of the reconstructed H-terminated diamond FET
Model starting pointProject-generated cross-section for the 130 nm baseline. It is a TCAD structure diagram, not a fabricated-device micrograph.
System

The harness made the workflow durable

I used a persistent goal file, a project plan, task-grasp notes, protected artifact rules, and completion gates to hold state across many Codex turns. That converted a chat session into a constrained execution loop: the agent had to inspect the current workspace before acting and had to prove a result from live files rather than from conversational memory.

  1. 01

    Anchor

    Freeze the target paper, goal, assumptions, protected outputs, and completion gates.

  2. 02

    Inspect

    Read the device deck, local solver setup, prior logs, figures, and extraction definitions.

  3. 03

    Execute

    Generate parameterized decks and invoke the installed ATLAS solver only on an authorized branch.

  4. 04

    Transform

    Parse raw outputs into consistent metrics, CSV tables, and figures without hiding sign or unit choices.

  5. 05

    Audit

    Map every claim back to its deck, raw log, processing script, table, and figure status.

  6. 06

    Gate

    Promote, hold, branch, or stop according to evidence—not according to how polished a plot looks.

Authoritative execution chain

paper → deck generator → local ATLAS → raw outputs → parser → CSV → figure → requirement audit → decision gate
Control

The chat record shows where I steered the work

The most revealing parts of the record are not “continue” prompts. They are the moments where I changed the protocol, challenged an assumption, imposed a stopping rule, or interrupted the orchestration itself. The entries below paraphrase those decisions from the original Chinese Codex thread.

  1. Make risky changes reversible

    I authorized experiments on copies when data or code looked suspect, keeping the known baseline intact.

  2. Challenge the scaling assumption

    I asked whether changing only gate length was physically adequate and opened full-lateral scaling as a diagnostic branch—not an automatic replacement.

  3. Require a post-run logic check

    Each experiment had to end with a judgment: did it support the intended physical route, or did the workflow need to reflect and correct course?

  4. Stop the Fig. 3 loop

    After repeated routes failed to close the VTH/DIBL trend, I stopped that line and redirected effort to defensible results and closeout work.

  5. Interrupt orchestration drift

    When the long-running thread became repetitive, I halted it, reorganized the workspace, and requested a status report so I could make the next trade-off.

Evidence

From one deck to a queryable evidence chain

Codex helped parameterize gate length, oxide thickness, gate bias, drain bias, and frequency-sweep conditions. Controlled scripts generated the experiment decks, invoked the installed solver, and retained each input together with its .log, .str, and .outevidence. Separate post-processing scripts normalized the p-type current convention, extracted threshold voltage, DIBL, transconductance, and the H21 0 dB crossing, then wrote common CSV inputs for the figures.

  1. 01Modeling assumption
  2. 02Generated ATLAS deck
  3. 03Raw .log / .str / .out
  4. 04Python extraction
  5. 05CSV metric table
  6. 06Figure and claim status

Claim status

SimulationAnalytical referenceCandidateBlocked

A correction that mattered

Formula estimates were not allowed to masquerade as RF extraction

An early trend could be estimated fromfT ≈ gm / (2πCG), but the target paper defined cutoff frequency from the short-circuit current gain crossing 0 dB. I required the workflow to add small-signal frequency sweeps and parse that crossing. The formula remained a physical comparison; it was no longer presented as the main extracted result.

In the calibrated 6 nm Al₂O₃ model, the extracted simulation trend moved from approximately 0.48 GHz at 2 μm to 156.42 GHz at 50 nm. These are simulation results—not fabricated-device measurements.

Comparison of H21 zero-decibel cutoff extraction and a gm over two pi CG estimate versus inverse gate length
H21 0 dB extraction versus the formula estimate. Project-generated TCAD result; the figure is retained as simulation evidence.
H21 0 dB extraction · 2 μm0.4819 GHzSimulation endpoint
Analytical comparison · 2 μm0.1258 GHzDerived formula reference
H21 0 dB extraction · 50 nm156.4185 GHzSimulation endpoint
Analytical comparison · 50 nm68.3489 GHzDerived formula reference
Evidence receipts

One claim, six receipts

01

Assumption

50 nm case · calibrated 6 nm Al₂O₃ model

The declared case uses the calibrated 6 nm Al₂O₃ model and keeps H21 0 dB extraction separate from the analytical formula comparison.

02

Deck

Parameterized ATLAS experiment

A copied, parameterized deck instantiated the 50 nm gate-length case under the authorized sweep.

03

Raw solver output

.log · .str · .out retained

The local ATLAS run retained its .log, .str, and .out outputs as the raw evidence layer.

04

Parser

Declared extraction and unit conventions

Post-processing applied the declared sign and unit conventions and extracted the H21 0 dB crossing alongside gm and CG.

05

CSV

Endpoint metrics kept distinct

The CSV records H21 extraction at 156.4185 GHz and the analytical formula reference at 68.3489 GHz as separate values.

06

Claim gate

Simulation · not measurement

The promoted public claim is a simulation result, not a measurement; the formula is a derived reference and the package budget is a separate first-order extension.

Extension

The workflow created room for a new engineering question

Once the defensible intrinsic trends were separated from the blocked ones, I used only the extracted transconductance (gm) and gate capacitance (CG) as first-order budget inputs to ask a packaging question: how much series resistance and parasitic capacitance can a scaled device tolerate while retaining 90% of its intrinsic RF benefit?

For the 50 nm simulated device, gm and CGproduce the first-order budgets below. The formula fT,0 is a derived reference, while H21 fT = 156.42 GHz is reported separately, not used as a budget input. This is a device–package budgeting exercise—not a three-dimensional electromagnetic, thermal, or reliability simulation.

50 nm device · first-order extension

90% intrinsic RF retention budget

Only gm and CG enter the package-budget calculation.

Inputs

gm
0.285181545 S/mm
CG
0.66406408596 pF/mm

Method

Rs,max = 1/(9gm) = 0.38961536277 Ω·mm

Cpar,max = CG/9 = 0.07378489844 pF/mm

fT,0 = gm/(2πCG) = 68.3489041569 GHz

Rounded budgets

Series resistance
≤ 0.390 Ω·mm
Parasitic capacitance
≤ 0.074 pF/mm

RF separation: fT,0 is a derived reference; H21 fT = 156.418535957 GHz at 50 nm is reported separately, not used as a budget input.

Project extension artifactAccessible web-native analytical model connecting device-side TCAD metrics to a first-order package-parasitic budget.
Ownership

My judgment remained outside the automation boundary

I retained responsibility for

  • Select the research question and target paper
  • Judge physical assumptions and meaningful variables
  • Authorize solver runs and experimental branches
  • Decide when to continue, stop, or narrow a claim
  • Accept responsibility for the final interpretation

Codex handled execution support for

  • Inspect and index a large mixed-format workspace
  • Turn a single deck into consistent experiment matrices
  • Invoke local tools under explicit run and file-safety rules
  • Parse outputs and check units, signs, names, and lineage
  • Maintain audit documents, gates, and cross-file consistency