Skip to content
ANVIL
Roadmap

Where ANVIL is going

The beta sizes two amplifier topologies, checks them across process, temperature and supply corners, and proves every number with a simulation. The items below are what we plan to build on that base.

Phase 1Next

Broader sizing

More circuits and more analyses, with the same per-number traceability the beta has today.

  1. More topologies

    Planned

    Folded-cascode and telescopic OTAs, fully differential variants with common-mode feedback, and LDO regulators.

  2. Monte Carlo and mismatch

    Planned

    Mismatch analysis and Monte Carlo runs, with the same per-number traceability as today's compliance table.

  3. Noise analysis

    Planned

    Input-referred noise as a spec, measured and graded like the others.

  4. Layout parasitics

    Planned

    Check a sized design with parasitics extracted from its layout, not only at schematic level.

  5. Side-by-side topology comparison

    Planned

    Size several topologies against one spec in a single run and compare their worst-case compliance in one table.

  6. Your own models and foundry PDKs

    Planned

    Load your own model cards and corners, including a foundry PDK, with simulation on infrastructure you control so the models never leave your network.

Phase 2Later

Design workflows for teams

Sizing is one step in a longer loop from requirements to a reviewed cell. We plan to extend ANVIL along that loop.

  1. Composable workflows

    Planned

    Chain spec extraction, sizing, corner sweeps and report generation into one workflow. Steps pass typed results (spec, netlist, simulation result, report), and workflows are stored as versioned text files you can review like code.

  2. Approval gates

    Planned

    Points where a workflow pauses for a designer to confirm extracted specs, approve a simulation budget or pick a topology. A gate pauses only its own branch, and each decision is recorded with its evidence.

  3. Requirement-change impact

    Planned

    When a requirement changes, find the results that depended on the old value, re-check stored simulation data against the new limit without re-simulating, and re-run only what is no longer valid.

  4. Result lineage

    Planned

    A graph from each requirement through specs, design variants and simulation evidence to the decisions and reports built on them, showing what any result depends on and what depends on it.

  5. No duplicate simulations

    Planned

    Reuse a stored result when the netlist, models and simulator version match a previous run, instead of simulating it again.

Tell us what to build first

If one of these would change how you work, or something you need is missing, write to hello@anvillab.tech.