AVF & in-house
engineering development.

AVF: Avecas VLSI Flow

AVF is Avecas’ internal framework for organising VLSI engineering flows. Its documented architecture separates the flow graph, design configuration, technology configuration and executable stage scripts. This separation helps engineers reuse stage logic while keeping design-specific values and technology collateral explicit. AVF is engineering infrastructure; project readiness still depends on the checks and evidence for the particular design.

A flow defines stage order and dependencies. A block configuration identifies the design inputs and constraints. A technology configuration supplies the library and corner references. Stage scripts carry out the tool-specific work. Keeping these responsibilities separate makes a change easier to review and helps explain which input influenced a result.

Preflight, execution and evidence

The documented workflow starts with an input check before execution. Engineers review required files, configuration values and stage dependencies, then run the selected flow in its intended environment. Outputs are organised into reports, generated scripts, logs and design artifacts. The generated scripts are useful evidence because they show the resolved settings supplied to the tools.

Status and summary commands help engineers locate a failed stage and inspect reported quality-of-results metrics. A restart or repeated run needs controlled inputs and clear revision tracking. Automation reduces manual coordination; it does not replace review of timing, verification, physical checks or other acceptance criteria.

Digital and custom-design workflows

The platform documentation describes digital implementation and analog/custom workflow organisation. Depending on the configured environment, a digital flow can connect RTL checks, synthesis, implementation and downstream analysis. A custom-design workflow can organise simulation, characterisation and physical-check artifacts. The precise stages, tools and supported collateral are assessed for the intended engagement.

Tool and process availability must be confirmed within authorised licensing and access arrangements. A configured adapter is not evidence of foundry qualification, certified compatibility or a completed tapeout. Public demonstrations should use shareable design inputs and avoid exposing proprietary PDKs, customer designs or restricted reports.

AI assistance with engineering review

Potential AI-assisted tasks include report summarisation, log triage, documentation search and comparison of controlled experiment results. These tasks should be evaluated against a known reference set before they affect engineering decisions. Suggestions should retain a link to the underlying report or rule so that an engineer can check the interpretation.

Sensitive source code and design collateral require an approved processing boundary. Model-generated scripts need review and testing before use. Any future optimisation feature should report its objective, constraints, baseline and measured result rather than presenting a generated recommendation as signoff evidence. AI assistance is an exploration area, not a substitute for established verification.

Discuss AVF through demonstrable work products

AVF, the Avecas VLSI Flow initiative, is organised around making design execution and its evidence easier to inspect. A useful evaluation begins with a bounded design case, the permitted tool environment and the result that must be reproduced. Establish the supported inputs and expected reports for that case before comparing automation approaches.

A technical demonstration should show the input revision, configuration, preflight checks, executed stages and resulting artifacts. It should also show what happens when a prerequisite is missing or a stage fails. A polished dashboard is useful only when its status reflects the underlying engineering result. Ask which activities are automated, which require an engineer and which are outside the demonstrated scope.

Discuss deployment boundaries, access rights, supported tools and maintenance expectations with the Avecas team. Availability and integration scope are confirmed against the proposed evaluation. AI-assisted suggestions should remain reviewable and should not be treated as signoff decisions. Public descriptions should be separated from confidential implementation details and from capabilities that have not yet been demonstrated.

Review an internal flow as a maintainable engineering product

When evaluating a flow, begin with one documented design configuration and a repeatable baseline. Identify which stages are expected to run, which tools and technology inputs they require, and which artifacts each stage produces. A failed preflight check should explain the missing dependency before a costly run starts. A successful command should still be followed by inspection of the reports that establish whether the engineering objective was met.

For a proposed change, compare the generated configuration and key reports with the baseline. Separate changes to stage logic from changes to design inputs so reviewers can understand the cause of a difference. Include a small regression example that exercises the affected behaviour, together with the tool and environment assumptions. A script that works in one local directory should not be treated as portable until path, environment and dependency handling have been reviewed.

Keep the handoff useful to the next engineer. Explain how to select a configuration, inspect results, identify a failed stage and restart from a valid point. Record known limitations and the owner of each unresolved issue. Internal methodology work can inform a scoped collaboration, but release availability, licensing, support and suitability for a customer environment must be agreed explicitly. The AVF overview describes the approach; it is not a claim that every tool, process technology or signoff requirement is supported.