SE Why Chip Engineers Should Care About AI-Created Behavioral Models
Posted: Thu Jul 23, 2026 7:04 am
You probably know this bottleneck too well: full transistor-level or physical simulations—whether analog circuit, electromagnetic, or thermal—can take weeks or even months. For complex designs, simulating every internal transistor in every block quickly becomes impractical. This is why creating accurate behavioral models is so important. A good behavioral model captures a block’s input-output behavior without carrying all the internal physics. It gives design teams a practical way to run more iterations, explore more tradeoffs, and save expensive golden simulations for the checkpoints that truly require full fidelity. But anyone who has built these models knows the hard part: creating a good behavioral model manually is exhausting. Analog/mixed-signal (AMS) blocks like PLLs, ADCs, DACs, and LDOs are notoriously difficult to model behaviorally. A PLL may respond differently across jitter profiles, supply conditions, temperature corners, and lock states. An ADC may show nonlinear behavior across input ranges, noise conditions, and process variations. An LDO may behave differently under transient load changes, dropout conditions, or stability constraints. That takes engineering judgment. What behavior must be preserved? What can be abstracted away? Which corners matter for the intended use? How much deviation from golden simulation is acceptable? And how do you prove the model is good enough for integration? This is where AI agents can help. In this blog, I will explain an agentic AI approach to quickly produce high-fidelity behavioral models. Simplify behavioral model creation with agentic AI Building a usable behavioral model requires six steps: define scope, generate reference data, produce the model, validate against golden, refine iteratively, and deploy. I will explain where AI agents cut the most time. Step 1. Define the model’s scope and requirements The process starts by establishing what the model is for and how it will be judged. There are four things that need to be locked down before the first simulation runs:
Source: https://semiengineering.com/why-chip-en ... al-models/
- What the model represents. PLL, ADC, DAC, LDO, or another AMS component—and which behavioral subset is in scope for this specific use case.
- Interface, including input/output ports, signal types, timing assumptions, control signals, and expected operating modes the model must handle.
- Accuracy requirements. How closely the model must match golden results across PVT corners, startup behavior, reset conditions, and key operating regions—and which deviations are acceptable given the intended use.
- Use context. Whether the model will be used in Verilog-A, SystemVerilog, C++ DPI, or a proprietary format determines how it gets generated and what constraints it must satisfy.
- Design a stimulus sweep covering the following: Operating conditions. Supply voltage, temperature, and process corners—fast, slow, and typical—across the full range the model will be asked to handle.
- Input types. Transient, AC, step, random, and stress conditions. The model will only generalize to input types it has seen during training.
- Edge and startup conditions. Reset, saturation, lock acquisition, dropout, and unusual load conditions. These are the cases most likely to surface failures in integration.
- Automated gap detection: agents compare model vs. golden, identify where errors are highest, and automatically produce new tests to understand behavior in those regions.
- Active learning: instead of running a predefined grid of simulations, agents intelligently select the next simulation point that maximizes information gain.
- Auto-retraining: once new simulation data is collected, agents recreate the model and re-evaluate—without engineer intervention.
- Wrapping the model in the correct interface, such as Verilog-A, SystemVerilog, C++ DPI, or a proprietary format.
- Running system-level checks to confirm the model behaves correctly when integrated with other blocks.
- Comparing against a limited set of top-level golden simulations where available.
- Versioning the model so it can be updated as the underlying design changes.
- Documenting assumptions, valid operating regions, and known limitations.
Source: https://semiengineering.com/why-chip-en ... al-models/