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.

Download the paper

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.

Read the case study

Gain confidence in your design and tape out in time

Square screen with various tabs symbolizing the LUBIS EDA App Builder

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.

A person painting a ladder between two mountains, symbolizing the help with tape-out from LUBIS EDA to customers.

It is the combination of multiple verification techniques, including formal verification, that will take you one step closer to quality tape out.

Target hit in the center by an arrow and a missile and 2 people are next to it, illustrating that LUBIS EDA helps its customers to meet their schedule.

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.

Square screen with various tabs symbolizing the LUBIS EDA App Builder

It is the combination of multiple verification techniques, including formal verification, that will take you one step closer to quality tape out.

Target hit in the center by an arrow and a missile and 2 people are next to it, illustrating that LUBIS EDA helps its customers to meet their schedule.

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.

A person painting a ladder between two mountains, symbolizing the help with tape-out from LUBIS EDA to customers.

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

Illustration of the LUBIS EDA planning phase
Illustration of the LUBIS EDA feedback cycle
LUBIS EDA sign-off illustration that adds the missing AIP to the design puzzle

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.

Illustration of the LUBIS EDA planning phase

Plan

We identify high-risk blocks, define verification targets, scope efforts, and set up accurate KPIs.

Illustration of the LUBIS EDA feedback cycle

Execute

We follow and complete the verification plan defined during setup. We send you weekly feedback and on-the-spot bug reports.

LUBIS EDA sign-off illustration that adds the missing AIP to the design puzzle

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.

The general verification setup around the RISC-V core

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.

Make an appointment