NETI AI / Engineering assistance inside WCS
Turn a finding into
a clear next step.
Ask about the work in front of you. Get an explanation connected to the selected design, the computed result and the sources available in your project.
Native Engineering & Technology Intelligence (NETI)See how context changes the conversation.
Findings, simulation readiness and run comparisons
- Measured
- 0.01 µm
- Required minimum
- 0.26 µm
Explain this width violation and what to inspect in Prism.
This M1 feature is too narrow.
The measured width is 0.01 µm. The rule requires at least 0.26 µm.
In Prism, inspect the M1 segment at the highlighted marker. Check its width in the Y direction.
Example conversation
What should I check before running this simulation?
Start with the blocking item reported by preflight. It identifies the part of the circuit or setup that needs attention before a run can begin.
In Pulse, inspect the referenced device, connection or analysis setting. Check that the selected models and setup match the circuit you intend to simulate.
Run preflight again after the change. Once the blocking checks pass, submit the simulation and inspect the resulting waveforms.
NETI explains the reported result. Simulation readiness comes from the deterministic preflight checks.
Example conversation
What should I review after this correction?
Compare the revised run with a compatible baseline. Check that the intended finding was resolved, then inspect new and recurring findings.
A smaller total count is useful, but it does not tell you which rules or locations still need attention. Review those differences in Parity and cross-probe the affected geometry in Prism.
Bring the remaining findings to the review with the relevant run results available to your teammate.
Run summaries and comparisons provide the facts for the explanation, rather than an estimate from a screenshot.
A useful answer needs the right inputs
Engineering context,
with a path back to the facts.
NETI works across supported Prism selections, Parity findings and run comparisons, Pulse preflight and simulation results, and WCS documentation. The question is interpreted within the workflow’s available context.
Explore AI and data controlsWhat an explanation can draw on
The selected design or result, available technology information and relevant documentation. Where a workflow provides source links, engineers can open the original rule, guide or result and inspect it directly.
Numerical measurements and verification outcomes come from the engineering services. The assistant helps interpret them and identify supported next steps.
When the context is incomplete
An unavailable rule, model or result leaves a gap in the explanation. The assistant should identify that gap rather than invent a threshold or imply that a check has passed.
Using a supported context and a specific engineering question gives the review a clearer starting point.
How access follows the project
Assistance uses authorised context. Organization policy and feature entitlements govern the available workflows; a question does not grant access to another team’s design or confidential PDK material.
From assistance to an engineering action
A proposal your team
can actually review.
For supported Parametric operations, describe the intended change and inspect the proposed parameters, preview and validation results before deciding what to apply.
The same review pattern supports bounded simulation and verification run proposals. Approval records a decision; execution is a separate step with fresh access and validation checks.
- 01
Intent becomes a typed proposal
Inspect the operation and exact proposed inputs.
- 02
Preview and checks make it concrete
Review what the operation would create or run.
- 03
An authorised reviewer decides
Approve or reject the proposal; the submitter can withdraw it.
- 04
Execute, then inspect the result
Run the approved operation and review its output in WCS.
Bring a question your engineers recognise.
Book a technical walkthroughSee the WCS workflow