ASIC verification and sign-off activities often involve multiple engineering teams, external service providers and specialised tools.
Before sharing RTL or assigning a verification task to an external engineering partner, it is important to understand the technical scope, deliverables, ownership and confidentiality arrangements.
The following ten questions can help establish a clear working relationship.
1. What exactly is included in the verification scope?
Identify the RTL blocks, interfaces, features and functional requirements that must be checked.
A clearly defined scope reduces misunderstandings during execution.
2. What are the expected deliverables?
Agree on the expected outputs.
These may include:
- SVA properties
- Assumption documentation
- Formal execution results
- Counterexample analysis
- Coverage and vacuity observations
- Verification summary reports
The deliverables should be agreed before the engagement begins.
3. How will assumptions be reviewed?
Assumptions influence which behaviours the formal engine explores.
The verification partner should explain how assumptions will be justified, documented and reviewed.
4. How will proof failures be handled?
A failed property may indicate an RTL defect, an incorrect assertion, an incomplete assumption or a modelling problem.
Agree on how counterexamples will be investigated and how unresolved issues will be reported.
5. How will proof convergence and limitations be reported?
Not every property will necessarily reach an unbounded proof.
The report should distinguish proven results, bounded results, failures and inconclusive outcomes.
6. How will RTL revisions and ECOs be handled?
Verification evidence must be associated with the correct design revision.
Agree on how changes to RTL, parameters, configurations and assumptions will be tracked and how affected properties will be re-evaluated.
7. How will LEC and STA dependencies be addressed?
Formal property verification does not replace LEC or STA.
Clarify whether the engagement includes these activities or whether they remain with the customer's internal team or another service provider.
8. Who reviews the technical results?
Understand who develops the properties, who reviews the assumptions and who is responsible for technical escalation.
For complex blocks, establish whether an experienced reviewer is available.
9. How will confidentiality and IP ownership be protected?
Before sharing RTL, agree on:
- NDA and contractual confidentiality obligations
- Ownership of customer RTL and project deliverables
- Treatment of pre-existing background IP
- Approved development and execution environments
- Access controls and data handling
- Restrictions on uploading confidential design information to public AI or third-party services
Do not share confidential RTL or design constraints through public enquiry forms or unapproved services.
10. Can the engagement begin with a defined pilot?
A limited pilot can help both teams evaluate technical capability and working practices.
For example, the pilot may cover one RTL block with an agreed set of properties, assumptions, proof results and a verification report.
The pilot scope, acceptance criteria, schedule and responsibilities should be agreed in advance.
Conclusion
Selecting an ASIC sign-off engineering partner requires more than comparing rates or available engineers.
A clear scope, technically reviewed assumptions, transparent proof reporting, revision traceability and appropriate confidentiality arrangements are important for a successful engagement.
A well-defined pilot can provide practical evidence of whether the working relationship is suitable for a larger verification programme.
