Verification of Parameterised FPGA Circuit Descriptions with Layout ...
Verification of Parameterised FPGA Circuit Descriptions with Layout ... Verification of Parameterised FPGA Circuit Descriptions with Layout ...
CHAPTER 4. VERIFYING CIRCUIT LAYOUTS 102 B C A D Figure 4.20: The surround combinator Appendix C.4 gives the Quartz description and correctness proof for this combinator’s layout. Validity of height and width expressions are proved by auto configured to expand let defin- itions and using Theorem 11 (z aleq bc). Containment proofs can also most be completed purely by auto however one requires the use of a variant of Theorem 9. The true value of the verification methodology comes into play with the intersection proofs. Once again, these are proved entirely automatically using purely auto - however the error that was discovered in the layout was discovered because an intersection theorem was not proved. The error was that C was naively placed with its y co-ordinate defined by heightA+heightD however this did not take into account of the fact that it was possible for it to overlap block E under some circumstances. A simple correction to define the y co-ordinate as the maximum of the height of E or A and D was sufficient to produce a valid layout. This is still a relatively simple layout for this combinator. A more complex layout description could use conditionals to compare the heights and widths of the various blocks and adjust their relative placement accordingly (for example, the B and E blocks could be aligned with the bottom of the combinator as a whole rather than the bottom of the A block if they have a greater height than A). E
CHAPTER 4. VERIFYING CIRCUIT LAYOUTS 103 4.8 Discussion Our approach to layout verification is effective, both at verifying the correctness of combina- tors and in finding the source of errors. However, it does have some drawbacks: 1. It generates many proof goals for blocks. 2. Many proofs that should be completed automatically require some manual intervention to tweak the role of the automated tactics. 3. We have not formally established the link between the proof obligations we generate for each block and the original definitions of correctness. The first issue stems from the increased role of the size inference system over what was originally expected. When this work was begun it was presumed that size inference would be inefficient and it would almost always be preferable to manually specify block sizes. However, we have found that the opposite is often the case. Except for primitive blocks, where sizes must always be specified manually, size inference is usually easier than writing complex size expressions by hand. In addition, while hand-coded size expressions are more efficient than inferred ones, the differences between the two tend to follow common patterns (some of which we have proved as theorems during the course of this work). It seems likely that in most cases the manually specified size functions could be produced by applying correctness-preserving transformations to the inferred size expressions automatically in the compiler. Using the size inference system, it should no longer be necessary to prove validity and con- tainment for each block’s size expressions if these properties could be proved for the inference algorithm itself. We can satisfy ourselves by inspection that sizes inferred by the inference system have correct containment properties since the inference algorithm is designed to select the topmost, rightmost possible co-ordinate of a layout 3 . We can also prove a theorem about the size inference function to show validity of its results: Theorem 22 For all blocks A, where R is the set of higher-order parameters of A and for 3 “Correct by definition” is not totally satisfactory, however it is sufficient for our purposes.
- Page 61 and 62: CHAPTER 3. GENERATING PARAMETERISED
- Page 63 and 64: CHAPTER 3. GENERATING PARAMETERISED
- Page 65 and 66: CHAPTER 3. GENERATING PARAMETERISED
- Page 67 and 68: CHAPTER 3. GENERATING PARAMETERISED
- Page 69 and 70: CHAPTER 3. GENERATING PARAMETERISED
- Page 71 and 72: CHAPTER 3. GENERATING PARAMETERISED
- Page 73 and 74: CHAPTER 3. GENERATING PARAMETERISED
- Page 75 and 76: Chapter 4 Verifying Circuit Layouts
- Page 77 and 78: CHAPTER 4. VERIFYING CIRCUIT LAYOUT
- Page 79 and 80: CHAPTER 4. VERIFYING CIRCUIT LAYOUT
- Page 81 and 82: CHAPTER 4. VERIFYING CIRCUIT LAYOUT
- Page 83 and 84: CHAPTER 4. VERIFYING CIRCUIT LAYOUT
- Page 85 and 86: CHAPTER 4. VERIFYING CIRCUIT LAYOUT
- Page 87 and 88: CHAPTER 4. VERIFYING CIRCUIT LAYOUT
- Page 89 and 90: CHAPTER 4. VERIFYING CIRCUIT LAYOUT
- Page 91 and 92: CHAPTER 4. VERIFYING CIRCUIT LAYOUT
- Page 93 and 94: CHAPTER 4. VERIFYING CIRCUIT LAYOUT
- Page 95 and 96: CHAPTER 4. VERIFYING CIRCUIT LAYOUT
- Page 97 and 98: CHAPTER 4. VERIFYING CIRCUIT LAYOUT
- Page 99 and 100: CHAPTER 4. VERIFYING CIRCUIT LAYOUT
- Page 101 and 102: CHAPTER 4. VERIFYING CIRCUIT LAYOUT
- Page 103 and 104: CHAPTER 4. VERIFYING CIRCUIT LAYOUT
- Page 105 and 106: CHAPTER 4. VERIFYING CIRCUIT LAYOUT
- Page 107 and 108: CHAPTER 4. VERIFYING CIRCUIT LAYOUT
- Page 109 and 110: CHAPTER 4. VERIFYING CIRCUIT LAYOUT
- Page 111: CHAPTER 4. VERIFYING CIRCUIT LAYOUT
- Page 115 and 116: CHAPTER 4. VERIFYING CIRCUIT LAYOUT
- Page 117 and 118: Chapter 5 Specialisation In this ch
- Page 119 and 120: CHAPTER 5. SPECIALISATION 109 opera
- Page 121 and 122: CHAPTER 5. SPECIALISATION 111 // Ha
- Page 123 and 124: CHAPTER 5. SPECIALISATION 113 circu
- Page 125 and 126: CHAPTER 5. SPECIALISATION 115 const
- Page 127 and 128: CHAPTER 5. SPECIALISATION 117 block
- Page 129 and 130: CHAPTER 5. SPECIALISATION 119 Modif
- Page 131 and 132: CHAPTER 5. SPECIALISATION 121 Buffe
- Page 133 and 134: CHAPTER 5. SPECIALISATION 123 a fas
- Page 135 and 136: CHAPTER 5. SPECIALISATION 125 block
- Page 137 and 138: CHAPTER 5. SPECIALISATION 127 y y y
- Page 139 and 140: CHAPTER 5. SPECIALISATION 129 with
- Page 141 and 142: CHAPTER 6. LAYOUT CASE STUDIES 131
- Page 143 and 144: CHAPTER 6. LAYOUT CASE STUDIES 133
- Page 145 and 146: CHAPTER 6. LAYOUT CASE STUDIES 135
- Page 147 and 148: CHAPTER 6. LAYOUT CASE STUDIES 137
- Page 149 and 150: CHAPTER 6. LAYOUT CASE STUDIES 139
- Page 151 and 152: CHAPTER 6. LAYOUT CASE STUDIES 141
- Page 153 and 154: CHAPTER 6. LAYOUT CASE STUDIES 143
- Page 155 and 156: CHAPTER 6. LAYOUT CASE STUDIES 145
- Page 157 and 158: CHAPTER 6. LAYOUT CASE STUDIES 147
- Page 159 and 160: CHAPTER 6. LAYOUT CASE STUDIES 149
- Page 161 and 162: CHAPTER 6. LAYOUT CASE STUDIES 151
CHAPTER 4. VERIFYING CIRCUIT LAYOUTS 103<br />
4.8 Discussion<br />
Our approach to layout verification is effective, both at verifying the correctness <strong>of</strong> combina-<br />
tors and in finding the source <strong>of</strong> errors. However, it does have some drawbacks:<br />
1. It generates many pro<strong>of</strong> goals for blocks.<br />
2. Many pro<strong>of</strong>s that should be completed automatically require some manual intervention<br />
to tweak the role <strong>of</strong> the automated tactics.<br />
3. We have not formally established the link between the pro<strong>of</strong> obligations we generate<br />
for each block and the original definitions <strong>of</strong> correctness.<br />
The first issue stems from the increased role <strong>of</strong> the size inference system over what was<br />
originally expected. When this work was begun it was presumed that size inference would be<br />
inefficient and it would almost always be preferable to manually specify block sizes. However,<br />
we have found that the opposite is <strong>of</strong>ten the case. Except for primitive blocks, where sizes<br />
must always be specified manually, size inference is usually easier than writing complex size<br />
expressions by hand. In addition, while hand-coded size expressions are more efficient than<br />
inferred ones, the differences between the two tend to follow common patterns (some <strong>of</strong> which<br />
we have proved as theorems during the course <strong>of</strong> this work).<br />
It seems likely that in most cases the manually specified size functions could be produced by<br />
applying correctness-preserving transformations to the inferred size expressions automatically<br />
in the compiler.<br />
Using the size inference system, it should no longer be necessary to prove validity and con-<br />
tainment for each block’s size expressions if these properties could be proved for the inference<br />
algorithm itself. We can satisfy ourselves by inspection that sizes inferred by the inference<br />
system have correct containment properties since the inference algorithm is designed to select<br />
the topmost, rightmost possible co-ordinate <strong>of</strong> a layout 3 . We can also prove a theorem about<br />
the size inference function to show validity <strong>of</strong> its results:<br />
Theorem 22 For all blocks A, where R is the set <strong>of</strong> higher-order parameters <strong>of</strong> A and for<br />
3 “Correct by definition” is not totally satisfactory, however it is sufficient for our purposes.