Verification of Parameterised FPGA Circuit Descriptions with Layout ...

More documents

Recommendations

Info

CHAPTER 2. BACKGROUND AND RELATED WORK 20 We are then able to use the induction hypothesis: R ; S = S ; R ⇒ S ; S n ; R = S n+1 ; R and fold back using the definition of repeated composition to complete the proof: R ; S = S ; R ⇒ S n+1 ; R = S n+1 ; R When R is a functional block and S is the polymorphic delay element D (which can be implemented using D flip-flops) the pre-condition of this theorem is called the timeless condition and is the basis of many re-timing theorems which allow us to prove the equivalence of pipelined Quartz circuits to their combinational equivalents. Quartz transformations can be used as part of a transformational design methodology where a correct but inefficient or non-implementable specification is gradually refined into a useful implementation. Each step in this refinement is proved correct and thus the final result is correct by design, requiring no additional verification. The T-Ruby design system [74] is an example of a transformational design environment that provides assistance for this process. Transformational design has its critics [16] and its suitability for general-purpose circuit design remains questionable, however it can be effective for carrying out certain operations. One issue with transformational design is the question of completeness - whether for every valid specification and implementation there is a chain of correct transformations that can be applied to transform one into the other. The same problem applies to general theorem proving in a language such as Quartz, with is effectiveness the same process in a different direction. The completeness property is not well understood but it has been proved that complete transformation systems can not exist for languages that support unbounded recursion or iteration constructs (such as while loops) [83]. 2.4 Automated Verification In recent years design validation has become the key bottleneck in the digital circuit design industry. Formal methods for verifying the correctness of hardware designs are one possible solution to this problem. With this approach hardware behaviour is described mathematically and a formal proof is produced to verify that the implemented circuit meets a rigorous
CHAPTER 2. BACKGROUND AND RELATED WORK 21 specification. The aim of automated verification is to have this formal verification process carried out auto- matically, or to provide substantial machine assistance allowing users to carry out verification more easily. Formal verification, however conducted, usually begins with the construction of a specification. This provides a high level description of the expected behaviour of the system being described given a particular sequence of inputs. In order to be useful, a formal specification should be constructed that is an unambiguous description in some formalism. Logic is a popular formalism for describing hardware functionality and logics such as first-order logic, higher-order logic and modal/temporal logic have all been used to describe hardware speci- fications. The choice of formalism depends on the style of verification to be performed (for example, what properties are to be verified). It is also necessary to build an implementation model of the system. For some systems, this may be the hardware description of the system itself but in others it may be necessary to apply some abstraction in order to produce a usable model. The key to verification is to relate these mathematical models at different levels of abstraction. A set of desired mathematical expressions proved in the specification model should be shown to hold in the implementation model. The correctness of the original specification is absolutely essential to formal verification since without this it is not possible to make meaningful statements about the implementation model. One popular means of relating specification and implementation models is model checking. This approach has key benefits (such as its ease of use) but quickly becomes computational intractable as the size of the hardware to be verified increases. An alternative is theorem proving, where the formal semantics of hardware descriptions are shown to be equivalent through a chain of mathematical reasoning. Theorem proofs can be extremely large and complex, so mechanised theorem-proving tools are often used to help construct them. A fundamental point that must be laboured is that formal methods can not guarantee the correctness of the final product, only of the design process. At some level all formal methods involve assumptions about the correct behaviour of underlying layers - if not the tools that
Page 1 and 2: Imperial College of Science, Techno
Page 3 and 4: Acknowledgements Firstly, I’d lik
Page 5 and 6: TABLE OF CONTENTS iv 2.5 Isabelle:
Page 7 and 8: TABLE OF CONTENTS vi 5.3.1 Speciali
Page 9 and 10: TABLE OF CONTENTS viii C.1.1 fst .
Page 11 and 12: Chapter 1 Introduction This thesis
Page 13 and 14: CHAPTER 1. INTRODUCTION 3 B A C Fig
Page 15 and 16: CHAPTER 1. INTRODUCTION 5 pler, all
Page 17 and 18: CHAPTER 2. BACKGROUND AND RELATED W
Page 29: CHAPTER 2. BACKGROUND AND RELATED W
Page 45 and 46: 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:
Page 85 and 86:
Page 87 and 88:
Page 89 and 90:
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
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:
Page 145 and 146:
Page 147 and 148:
Page 149 and 150:
Page 151 and 152:
Page 153 and 154:
Page 155 and 156:
Page 157 and 158:
Page 159 and 160:
Page 161 and 162:
Page 163 and 164:
Page 165 and 166:
Page 167 and 168:
Page 169 and 170:
Page 171 and 172:
Page 173 and 174:
Page 175 and 176:
CHAPTER 7. CONCLUSION AND FUTURE WO
Page 177 and 178:
Page 179 and 180:
Page 181 and 182:
Page 183 and 184:
Page 185 and 186:
Bibliography [1] A. Aggoun and N. B
Page 187 and 188:
BIBLIOGRAPHY 177 [19] H. Gelernter.
Page 189 and 190:
BIBLIOGRAPHY 179 [41] Y. Li and M.
Page 191 and 192:
BIBLIOGRAPHY 181 [60] L. C. Paulson
Page 193 and 194:
BIBLIOGRAPHY 183 [83] J. Voeten. On
Page 195 and 196:
APPENDIX A. QUARTZ LANGUAGE GRAMMAR
Page 197 and 198:
Appendix B Theoretical Basis for La
Page 199 and 200:
APPENDIX B. THEORETICAL BASIS FOR L
Page 201 and 202:
Page 203 and 204:
Page 205 and 206:
Page 207 and 208:
Page 209 and 210:
Page 211 and 212:
Page 213 and 214:
Page 215 and 216:
Page 217 and 218:
Appendix C Placed Combinator Librar
Page 219 and 220:
APPENDIX C. PLACED COMBINATOR LIBRA
Page 221 and 222:
Page 223 and 224:
Page 225 and 226:
Page 227 and 228:
Page 229 and 230:
Page 231 and 232:
Page 233 and 234:
Page 235 and 236:
Page 237 and 238:
Page 239 and 240:
Page 241 and 242:
Page 243 and 244:
Page 245 and 246:
Page 247 and 248:
Page 249 and 250:
Page 251 and 252:
Page 253 and 254:
Page 255 and 256:
Page 257 and 258:
Page 259 and 260:
Page 261 and 262:
Page 263 and 264:
Page 265 and 266:
Page 267 and 268:
Page 269 and 270:
Page 271 and 272:
Page 273 and 274:
Page 275 and 276:
Page 277 and 278:
Page 279 and 280:
APPENDIX D. CIRCUIT LAYOUT CASE STU
Page 281 and 282:
Page 283 and 284:
Page 285 and 286:
Page 287 and 288:
Page 289 and 290:
Page 291 and 292:
Page 293 and 294:
Page 295 and 296:
Page 297 and 298:
Page 299 and 300:
Page 301 and 302:
Page 303 and 304:
Page 305 and 306:
Page 307 and 308:
Page 309 and 310:
Page 311 and 312:
Page 313 and 314:
Page 315 and 316:
Page 317 and 318:
Page 319 and 320:
Page 321 and 322:
Page 323 and 324:
Page 325 and 326:
Page 327:
show all

Verification of Parameterised FPGA Circuit Descriptions with Layout ...

Create successful ePaper yourself

Delete template?

Save as template?