Verification
-
FV Interview Questions (XII) – How to Define Clocks for Designs using Both Posedge & Negedge?
If the design is using only posedge of a single clock, then the clock can be defined as: # assume clk is the clock input signal name at top level If the design is using only negedge of a clock, then the clock can be…
-
FV Interview Questions (XI) – Does a Liveness Property Failure Mean a Deadlock?
Liveness property debug may often be tricky. If we ever find a liveness property failure, it does not necessarily mean a deadlock exists in the design. Instead, it could be due to lack of proper assumptions. Assuming we have a data processing block, in which…
-
FV Interview Questions (X) – How does Liveness Property Impact DV & How to Work Around it?
In the last post, we mentioned that liveness properties may not be useful in simulation. Some simulation tools do not always report liveness property failure in DV tests. In addition, liveness properties may even significantly degrade simulation speed. Simulation tools use checker threads for SVA…
-
FV Interview Questions (IX) – How to Write Efficient Liveness Properties?
Should You Use Liveness Properties in the First Place? Liveness properties are often more complex to prove, and challenging to debug. Plus, they may not be useful in simulations (covered in the next post). Before writing liveness properties, designers should ask themselves, is it really…
-
FV Interview Questions (VIII) – What is a Liveness Property?
Designers are typically more familiar with safety properties, whose intention is to check a “bad thing” can never happen. For example, in the following safety property, when valid is asserted while ready is low, valid should keep asserted in the very next cycle. If valid…
-
FV Interview Questions (VII) – What is Precondition Reachability Check?
Assert and assume properties often use a triggering event, or a precondition, to define when the test expression should be checked. If the precondition is unreachable, then the assert property will never trigger, and it does not check what was intended. Consequently, the tool can…
-
FV Interview Questions (VI) – Dealing with Complexity by Abstraction
From Black Box to Behavioral Model, to VIP We discussed black boxing, but black boxing assumes a logic X at the output ports. One can further add assume properties at black box module outputs, to constrain their behavior. Designers can wrap these assume properties into…
-
FV Interview Questions (V) – Dealing with Complexity by Black Boxing
Other than design reduction, black boxing is another effective approach to deal with FV complexity. Black boxing can be done in design analyzing phase: Or it can be done in design elaboration phase: By default, the outputs of a black-boxed module always produce a logic…
-
FV Interview Questions (IV) – Dealing with Complexity by Design Reduction
In our book “Crack the Hardware Interview: Verification, Implementation, Synthesis & Power”, we briefly discussed what to do if FV cannot achieve full proof. Design reduction is an important technique to tackle this problem. We will dive a little deeper in post. Many designs have…
-
FV Interview Questions (III) – How to Waive an Expected Failing Property?
Typically we want to get full proof for all assert properties and see all cover properties proven reachable. However, sometimes we may want to disable certain properties from being run during FV. For example, the FV VIP supports all features of a protocol, but the…
Read Our Books for Free with Kindle Unlimited
Our books are available on Kindle Unlimited for free. Plus, you get unlimited access to hundreds of other books for preparing hardware interviews, including our recommended reading list
* Chipress participates in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com
Subscribe
Enter your email to get updates from us. You might need to check the spam folder for the confirmation email.
Chipress 