Sign off your high-risk blocks and reach best-in-class SoC design quality
Leave the formal verification of your silicon design with us. We will efficiently get these hard-to-find bugs that escape other verification techniques.
50% of respins are due to functional bugs
Your time and budget are limited. To avoid bug escapes and reach the best possible quality for tape out, make formal sign-off a priority of your verification strategy.
Not experts or not willing to do it within your team? Having a custom design that comes with special needs? No problem, we will do it for you. We have done it for others across AI, ML, automotive and more, including RISC-V players.
Gain confidence in your design and tape out in time
For formal sign-off, we target simulation-resistant bugs using formal verification supported by the LUBIS EDA Formal Verification Toolbox to accelerate the process and improve quality.
It is the combination of multiple verification techniques, including formal verification, that will take you one step closer to quality tape out.
By the way, 66% of ASIC projects are behind schedule. We bet you do not want to be one of them. Count on us to help you stick to your budget and timeline.
It is the combination of multiple verification techniques, including formal verification, that will take you one step closer to quality tape out.
For formal sign-off, we target simulation-resistant bugs using formal verification supported by the LUBIS EDA Formal Verification Toolbox to accelerate the process and improve quality.
By the way, 66% of ASIC projects are behind schedule. We bet you do not want to be one of them. Count on us to help you stick to your budget and timeline.
Gain confidence in your design and tape out in time
Plan
Execute
Sign off
We identify high-risk blocks, define verification targets, scope efforts, and set up accurate KPIs.
We follow and complete the verification plan defined during setup. We send you weekly feedback and on-the-spot bug reports.
We hand out to you the Assertion IP (AIP) that accelerates run-time and integrates with existing regression tests to validate that a code change does not impact the existing functionality of the final product.
Plan
We identify high-risk blocks, define verification targets, scope efforts, and set up accurate KPIs.
Execute
We follow and complete the verification plan defined during setup. We send you weekly feedback and on-the-spot bug reports.
Sign off
We hand out to you the Assertion IP (AIP) that accelerates run-time and integrates with existing regression tests to validate that a code change does not impact the existing functionality of the final product.
Based on your design stage
Formal verification methods can help you at all design levels. You can count on us at every stage.
Design bring-up
Design and specification are still in process during design bring-up.
We provide your design team with an Assertion IP (AIP) based on your specifications.
You then use that AIP to verify that new changes do not affect the existing functionality of your design. You also use it to identify specification mismatches in order to update the AIP according to the changes.
Design verification
When design and specifications are developed beforehand, we provide an AIP to validate the correct implementation of specified features.
Bug Hunting
We assess and analyze specific and hard-to-verify features based on the project scope and verification plan.
IP redesign
The demand for IP redesign has become standard.
Continuously adding new functionalities to the IP results in growing design complexity. You need to refactor your IP and improve performance to preserve all existing functionalities (documented or not).
Industrial case study
Compute Cores
RISC-V Core
RISCV instruction set is an open-source ISA based on RISC principles and is being widely used in many areas due to the flexibility and modularity it offers. Formal verification became a necessity due to the increased usage of RISCV cores in many critical domains.
The design that was verified is a RISC-V base model (RV32i)
Bug Findings
Over 50 bugs were found during the first round of verification of this design in several instructions.
The bugs that were found were due to wrong execution of instructions, wrong exception handling and violation of the standard ISA description of the instructions.
Bug 1
A bug was found in the BLT instruction where the design generates an exception when it should not. The instruction should check if register rs1 is less than rs2, if the condition holds true, then jump to the target address. However, the design was calculating the target address before evaluating if the condition is true which resulted in a misaligned address exception to be asserted, resulting in wrong values in some of the CSRs.
Bug 2
A bug was found in the JALR instruction where the design wrongly writes the fetching address of the JALR instruction to the register file in case a misalignment exception. The design fetches the JALR instruction from address 0x84 where it calculates the target address. In case of a misalignment, a misalignment exception should be generated and the JALR should not take effect. The design was correctly generating a misalignment exception, but it was wrongly writing the fetching PC value to the destination register.
Need us to sign off your design?
Get in touch. We will craft a unique project for you that efficiently helps you reach your quality targets.