24.04.2013 Views

Verification of Parameterised FPGA Circuit Descriptions with Layout ...

Verification of Parameterised FPGA Circuit Descriptions with Layout ...

Verification of Parameterised FPGA Circuit Descriptions with Layout ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

CHAPTER 4. VERIFYING CIRCUIT LAYOUTS 104<br />

all r ∈ R, heightr and widthr are valid, the height and width expressions inferred for block<br />

A will be valid.<br />

Pro<strong>of</strong> By induction on the structure <strong>of</strong> statements and using Theorems 9, 11, 13 and 17.<br />

Similar pro<strong>of</strong>s must be completed for the size function for block compositions SI but these<br />

are similar and easy.<br />

However, if these theorems are simply omitted from the Isabelle theories this makes it im-<br />

possible for them to be referred to in pro<strong>of</strong>s for blocks which have manually specified size<br />

functions. Manually specified size functions are far from useless - they can be simpler than<br />

inferred ones and allow blocks to be allocated sizes that are larger than required. This latter<br />

point is particularly important for run-time reconfigurable designs where it may be desirable<br />

to allocate the same (maximum) amount <strong>of</strong> space to a design regardless <strong>of</strong> how big it actually<br />

is and allow all different generated designs to grow or shrink <strong>with</strong>in that boundary.<br />

A way around this is to describe the size inference function itself in Isabelle and prove these<br />

properties about it using a deep embedding <strong>of</strong> Quartz. A meta-theorem could then be proved<br />

in Isabelle/HOL to provide validity pro<strong>of</strong>s for all size expressions produced by the inference<br />

algorithm.<br />

Issue 2 appears to mainly be one <strong>of</strong> implementation. Isabelle’s automated pro<strong>of</strong> tools do<br />

produce very good results when their rule sets are correctly configured and further investi-<br />

gation is necessary to reveal whether these issues are caused by niceties in the phrasing <strong>of</strong><br />

theorems or subtle bugs in the way they are applied by the classical reasoner. It should be<br />

stressed that where manual intervention in pro<strong>of</strong>s has been necessary it has not required any<br />

theorems or lemmas that are not already present in the Quartz<strong>Layout</strong> library and thus for<br />

an experienced user the task is generally an easy one.<br />

The third issue is perhaps one <strong>of</strong> choice. Formal verification is time consuming and difficult.<br />

As such it makes sense to apply it only to the parts <strong>of</strong> a design or design process where it<br />

is most likely to yield results. No hardware development system is available that is formally<br />

verified from “top to bottom” and in our system we have chosen to implement formal verifi-<br />

cation for a particular subset, based on particular definitions that we can reason are correct<br />

in a semi-formal way.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!