HW_and_Lab__-FV_Summer_School2011__HW_Verif

# HW_and_Lab__-FV_Summer_School2011__HW_Verif - Summer Formal...

This preview shows pages 1–6. Sign up to view the full content.

May 2011 Summer Formal 2011 Summer Formal 2011 Jason Baumgartner www.research.ibm.com/sixthsense IBM Corporation Homework and Lab

This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document
2 Homework 1: Netlist Modeling Exercises 1.1) Properties are specially annotated as "outputs" in the AIGER format. However, there are no special ways to annotate "constraints". How may the netlist be manipulated to allow constraints be reflected in an AIGER netlist? assume (busy not req_valid)
3 Homework 1: Netlist Modeling Exercises 1.2) Latches are assumed to have constant-0 initial value in the AIGER format. Assume you wish to initialize a set of latches to an arbitrary one-hot state: i.e., exactly one of them will be active at any point in time. How may this be represented in the netlist? 0 0 0 assertable?

This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document
4 Homework 1: Netlist Modeling Exercises 1.3) Certain types of logic functions such as multipliers are very difficult to reason about using bit-level algorithms. "Uninterpreted functions" are sometimes used to facilitate the verification of designs with such functions, wherein two instances of a particular function (e.g., one in the implementation and one in a reference model) are replaced with nondeterministic behavior. In particular, these two instances are each replaced by a multiplexor: if the arguments to the abstracted functions are identical, the same nondeterminstic values are sensitized through both multiplexors. Otherwise, different nondeterminstic values are sensisized through. Uninterpreted functions are useful when the correctness of the verification task is not dependent upon the precise values produced from the abstracted functions; only the *consistency* of identical results being produced under identical arguments is relevant. When verifying sequential netlists, a challenge with using uninterpreted functions is that the function pairs to be abstracted may be receive their arguments at different points in time. I.e., the implementation may be pipelined hence the timing with which it receives relevant arguments may not match the un-pipelined reference model. How could one model a precise "sequentially consistent" uninterpreted function to cope with this? Comment on the size of the resulting implementation with respect to the width of the abstracted function. Could you think of lossy yet "sound" shortcuts which are of smaller sizes and retain sequential consistency?
5 Homework 1: Netlist Modeling Exercises 1.4) Recall that “liveness checking” may be reduced to “safety checking” through a netlist transformation, which entails adding a “shadow register” for every register in the original netlist against which a state-repetition – i.e. lasso loop – may be detected. Consider checking a liveness property of the form: every request eventually gets a grant. A single assertion net may be synthesized which remembers that a request has occurred and is awaiting a grant – hence the liveness check consists of checking whether this assertion net may stick at logical 1 forever. Work through the exercise of how to

This preview has intentionally blurred sections. Sign up to view the full version.

View Full Document
This is the end of the preview. Sign up to access the rest of the document.
• Spring '11
• MartinRinard
• formal methods, Transition function, model checking, Model checkers, SPIN model checker, Netlist Modeling Exercises

{[ snackBarMessage ]}

### Page1 / 26

HW_and_Lab__-FV_Summer_School2011__HW_Verif - Summer Formal...

This preview shows document pages 1 - 6. Sign up to view the full document.

View Full Document
Ask a homework question - tutors are online