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.
Leave the formal verification of your silicon design with us. We will efficiently get these hard-to-find bugs that escape other verification techniques.
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.
When you ask us to formally sign off your design, we focus on efficiently detecting simulation-resistant bugs with formal verification following our LUBIS App builder that leverages our in-house automation software.
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.
When you ask us to formally sign off your design, we focus on efficiently detecting simulation-resistant bugs with formal verification following our LUBIS App builder that leverages our in-house automation software.
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.
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.
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.
Formal verification methods can help you at all design levels. You can count on us at every stage.
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.
When design and specifications are developed beforehand, we provide an AIP to validate the correct implementation of specified features.
We assess and analyze specific and hard-to-verify features based on the project scope and verification plan.
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).
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.
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.
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.
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.
Get in touch. We will craft a unique project for you that efficiently helps you reach your quality targets.