Skip to content
Avecas

ENGINEERING CAPABILITIES

IC design & embedded
engineering services.

Explore IC design and embedded engineering services across architecture, verification, implementation, and system integration.

Discuss your requirements
Surface-mounted integrated circuits on a red circuit board

Representative photograph · Surface-mounted integrated circuits on a red circuit board.

THE ENGINEERING SCOPE

Built around
your requirements.

Explore the approach ↓
01

RTL & architecture

Turn system requirements into clear microarchitecture, synthesizable RTL, and an integration plan.

02

Design verification

Build confidence with verification planning, simulation, coverage analysis, and formal methods.

03

Physical design

Connect implementation decisions to timing, power, area, and physical signoff requirements.

04

Design for test

Plan test architecture, scan integration, ATPG, and the handoff to production test.

05

Analog & mixed signal

Support analog layout, integration, and verification across the agreed process and design rules.

06

Embedded & FPGA

Bring hardware and software together through prototyping, firmware, and system validation.

HOW WE WORK

Clarity at each stage.

01

Understand

Review the design challenge, available inputs, and target outcomes.

02

Scope

Agree the work package, ownership, interfaces, and delivery evidence.

03

Engineer

Execute with technical reviews and traceable issue resolution.

04

Deliver

Review the agreed sources, reports, and integration collateral.

PROJECT DECISIONS

Know what moves the work forward.

Use these gates to agree readiness, review evidence and responsibility at each stage.

  1. 01

    Understand

    What should be clear before progressing?

    Review method and evidence

    Review the design challenge, available inputs, and target outcomes.

    Review evidence

    Agree the owner, supporting artifacts and the decision needed to move to the next stage.

  2. 02

    Scope

    What should be clear before progressing?

    Review method and evidence

    Agree the work package, ownership, interfaces, and delivery evidence.

    Review evidence

    Agree the owner, supporting artifacts and the decision needed to move to the next stage.

  3. 03

    Engineer

    What should be clear before progressing?

    Review method and evidence

    Execute with technical reviews and traceable issue resolution.

    Review evidence

    Agree the owner, supporting artifacts and the decision needed to move to the next stage.

  4. 04

    Deliver

    What should be clear before progressing?

    Review method and evidence

    Review the agreed sources, reports, and integration collateral.

    Review evidence

    Agree the owner, supporting artifacts and the decision needed to move to the next stage.

ENGINEERING GUIDE

Plan IC design and embedded engineering services.

Read the technical guide

Choose a work package by its technical starting point

Use the directory to identify the engineering decision you need help with. An architecture question, an implementation task and a failing-system investigation need different inputs and different acceptance criteria. Start with the most specific discipline, then identify adjacent work that must be coordinated.

For a new chip or system, agree interface ownership before splitting the work across teams. For an existing design, provide the current baseline and the evidence behind the problem statement. Include known limitations and the environment in which the issue occurs. This helps distinguish a focused review from a larger redevelopment effort.

A useful first conversation ends with a proposed scope, prerequisites, deliverables and review points. The service pages describe typical engineering activities; the actual statement of work confirms available expertise, tooling, schedule and responsibilities. Contact Avecas with a short non-confidential summary before sharing protected design files.

Define the working agreement around technical outcomes

A useful engagement starts with a bounded problem and a named owner for the result. Separate technical scope, staffing assumptions and commercial arrangements. State which team owns architecture, implementation, integration and final acceptance. Identify external dependencies, including tools, licensed data, hardware availability and decisions that the client must provide before work can proceed.

Milestones should represent reviewable outputs. A schedule can show when an architecture review, implementation baseline, validation package or integration handoff is expected, together with the prerequisites for each. Track open decisions and their effect on downstream work. When the scope changes, revise the affected estimates and acceptance criteria rather than treating the change as an informal addition.

Plan for continuity after delivery. The receiving team should know which sources and reports are authoritative, how to reproduce key results and where limitations are recorded. Discuss the support period, issue triage and responsibility for integration separately from the initial delivery. Current staffing availability, location, lead times and commercial terms are confirmed for the actual engagement.

Build an engineering brief that teams can execute

A useful brief starts with the product decision, rather than a list of tools. Describe the intended application, the present design state and the next milestone. Separate constraints that are fixed from preferences that can change. For example, an existing package or board connector may be fixed while buffer depth, software scheduling or implementation hierarchy remains open. Give each constraint an owner so that a review can resolve tradeoffs without relying on assumptions.

For silicon work, identify the architecture baseline, interfaces, clocking, reset sequence, power intent and available technology collateral. Explain whether the engagement begins with a specification, RTL, a synthesized netlist, a placed design or fabricated devices. These starting points require different evidence. A verification team needs expected behaviour and an observable test interface; a physical implementation team also needs usable constraints and consistent library views. A test team needs the intended test modes, package connections and an agreed method for interpreting results.

For embedded work, include the processor or controller, board revision, boot path, operating environment, peripheral interfaces and available diagnostic access. State which failure modes matter to the application. A system that boots once on a development bench may still need recovery, update, endurance, timing and resource checks before release. Describe representative workloads and explain how the team will obtain logs when a failure occurs outside the laboratory.

Choose the engagement around ownership. A focused assessment can produce a finding register and a recommended next step. An implementation package requires agreed inputs, delivery artifacts and review gates. A broader turnkey programme needs explicit coordination between architecture, verification, implementation and downstream partners. Responsibilities for procurement, third-party IP, manufacturing, certification and final product acceptance should be recorded separately rather than assumed to be included.

Plan reviews around usable evidence. At the first gate, confirm that the inputs are complete enough to begin. During execution, review changes against the baseline and investigate unexpected results. At handoff, check that another engineer can identify the correct revision, reproduce the agreed checks and understand unresolved items. Deliverables should include configuration details and limitations alongside the output files. The receiving team should know who owns each remaining action.

Start the conversation with a short non-confidential summary through the contact page. Include the discipline, starting point, expected deliverable and target milestone. Avoid sending proprietary RTL, PDK files, customer data or credentials through a public form. Once the appropriate confidentiality and access arrangements are in place, the project team can agree a controlled method for sharing technical material and refining the estimate.

BEFORE WE BEGIN

Project questions.

A clear conversation is the start of a strong engineering relationship.

Can we start with a single work package?

Yes. A focused engagement can cover a particular design, verification, implementation, or integration requirement.

Which technologies and tools are supported?

The target process, IP, EDA tools, licenses, and engineering requirements are reviewed for each engagement before scope and schedule are committed.

PUT THE WORKFLOW IN CONTEXT

Explore the engineering decisions.

Practical reading to help prepare your project discussion. Studies are illustrative; they do not report client results.

What belongs in a turnkey IC-design project brief ↗

ENGINEERING DIRECTORY

Find the right discipline.

Each guide explains the starting inputs, engineering sequence, checks and handoff for a defined work package.

102 engineering guides

YOUR NEXT CHAPTER STARTS HERE

What will you
build next?

Bring us your engineering challenge.
Let’s define the path from idea to implementation.

Start a conversation