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 3. GENERATING PARAMETERISED LIBRARIES WITH LAYOUT 38 〈stmt〉 ::= assert (〈expr〉) "〈string〉" . | 〈expr〉 = 〈expr〉 . | 〈arg〉 ; 〈blkref 〉 (; 〈blkref 〉 )* ; 〈arg〉 . | for 〈id〉 = 〈expr〉..〈expr〉 { 〈stmt〉* } . | if (〈expr〉) { 〈stmt〉* } ( else { 〈stmt〉* } )? . 〈blkref 〉 ::= 〈id〉 〈arg〉* | [ ] | [ 〈blkref 〉 (, 〈blkref 〉)* ] 〈arg〉 ::= 〈id〉 〈vecindex 〉 | 〈expr〉 | ( ) | ( 〈arg〉 (, 〈arg〉)* ) Figure 3.1: Grammar of Quartz statements itself, which describes the size of the statements within the block. Assertion statements are compile-time directives that check for the validity of particular pre- conditions and thus have no effect on the resulting layout. The assignment operation has three (overloaded) uses: 1. Assigning values to variables which may control elaboration. 2. Assigning static values to wires. 3. Connecting wires together. (1) clearly does not have any direct effect on layout (save that it may affect the way later statements are processed). In our model that concentrates on layout rather than routing we will assume that (2) and (3) also have no effect on layout. This is a reasonable assumption since FPGA routing resources are independent from computational ones and it is not generally necessary to allocate computational logic resources to either of these functions 1 . Conditional statements allow different hardware to be generated depending on the evaluation of a boolean expression. This is significant because the two possible branches of the condi- tional can have different sizes and thus any reference to the size of the overall conditional must take this into account. The easiest way to do this is to allow placement expressions to contain conditionals of their own, a simple and remarkably powerful approach. Loops allow the instantiation of multiple hardware blocks. An important realisation for the 1 Issues with insufficient routing resources are unusual in most cases when using the standard placer and router. However, if a lot of logic is packed with LOC/RLOC constraints regardless of the available routing resources this could increase the risk of routing congestion making it possible to describe circuits that can not be routed.
CHAPTER 3. GENERATING PARAMETERISED LIBRARIES WITH LAYOUT 39 general use of these constructs is that each iteration of the loop need not have the same size (though it often will), for example the loop statements could themselves contain a conditional. Additional functions will need to be added to the placement expressions to allow placement relative to arbitrary loop constructs to be described. Block instantiations include not just instantiations of individual blocks but also series and parallel compositions of blocks. Series and parallel compositions must be given their own layout interpretation to ensure that blocks within a composition are laid out correctly, while the whole composition itself can be placed using the at (x,y) command. An important requirement for a truly general Quartz framework is that it must be able to support the full range of Quartz block parameterisation. Two features of Quartz that differ from languages like Pebble/VHDL are a particular issue here: • Quartz blocks are relational and may have multiple possible interpretations in terms of inputs/outputs. During compilation a single input/output arrangement is selected for each block however when describing the size of a block in terms of its inputs it is not always clear which parameters supplied to the block are inputs and which are outputs. • Variable parameters are not restricted to a particular “generics” region of the block interface and can be distributed anywhere throughout the block’s domain/range. Fur- thermore, Quartz blocks can output variables as well as being parameterised by input variables. The compilation of one block may therefore produce a value which impacts the compilation of a later block. Since a block size can depend on any variable parameter it is important that the block size function should be in terms of all input variables, whether in the domain or range. However, this is complicated further by polymorphism – which signals are variables and which are real hardware is not in general known. While a polymorphic variable can not effect the compilation, and hence size, of the immediate block (otherwise its type would have been deduced as either int or bool during the type-checking stage), it could be supplied as a parameter to a higher-order parameter block and (sometimes) affect that block’s size, hence affecting the calling block’s size indirectly. In order to support this possibility block size functions must be phrased in terms of all domain and range signals, since any one of them
- 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 19 and 20: CHAPTER 2. BACKGROUND AND RELATED W
- Page 21 and 22: CHAPTER 2. BACKGROUND AND RELATED W
- Page 23 and 24: CHAPTER 2. BACKGROUND AND RELATED W
- Page 25 and 26: CHAPTER 2. BACKGROUND AND RELATED W
- Page 27 and 28: CHAPTER 2. BACKGROUND AND RELATED W
- Page 29 and 30: CHAPTER 2. BACKGROUND AND RELATED W
- Page 31 and 32: CHAPTER 2. BACKGROUND AND RELATED W
- Page 33 and 34: CHAPTER 2. BACKGROUND AND RELATED W
- Page 35 and 36: CHAPTER 2. BACKGROUND AND RELATED W
- Page 37 and 38: CHAPTER 2. BACKGROUND AND RELATED W
- Page 39 and 40: CHAPTER 2. BACKGROUND AND RELATED W
- Page 41 and 42: CHAPTER 2. BACKGROUND AND RELATED W
- Page 43 and 44: CHAPTER 2. BACKGROUND AND RELATED W
- Page 45 and 46: CHAPTER 3. GENERATING PARAMETERISED
- Page 47: CHAPTER 3. GENERATING PARAMETERISED
- Page 51 and 52: CHAPTER 3. GENERATING PARAMETERISED
- Page 53 and 54: CHAPTER 3. GENERATING PARAMETERISED
- Page 55 and 56: CHAPTER 3. GENERATING PARAMETERISED
- Page 57 and 58: CHAPTER 3. GENERATING PARAMETERISED
- Page 59 and 60: CHAPTER 3. GENERATING PARAMETERISED
- 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
CHAPTER 3. GENERATING PARAMETERISED LIBRARIES WITH LAYOUT 38<br />
〈stmt〉 ::= assert (〈expr〉) "〈string〉" .<br />
| 〈expr〉 = 〈expr〉 .<br />
| 〈arg〉 ; 〈blkref 〉 (; 〈blkref 〉 )* ; 〈arg〉 .<br />
| for 〈id〉 = 〈expr〉..〈expr〉 { 〈stmt〉* } .<br />
| if (〈expr〉) { 〈stmt〉* } ( else { 〈stmt〉* } )? .<br />
〈blkref 〉 ::= 〈id〉 〈arg〉* | [ ] | [ 〈blkref 〉 (, 〈blkref 〉)* ]<br />
〈arg〉 ::= 〈id〉 〈vecindex 〉 | 〈expr〉<br />
| ( ) | ( 〈arg〉 (, 〈arg〉)* )<br />
Figure 3.1: Grammar <strong>of</strong> Quartz statements<br />
itself, which describes the size <strong>of</strong> the statements <strong>with</strong>in the block.<br />
Assertion statements are compile-time directives that check for the validity <strong>of</strong> particular pre-<br />
conditions and thus have no effect on the resulting layout. The assignment operation has<br />
three (overloaded) uses:<br />
1. Assigning values to variables which may control elaboration.<br />
2. Assigning static values to wires.<br />
3. Connecting wires together.<br />
(1) clearly does not have any direct effect on layout (save that it may affect the way later<br />
statements are processed). In our model that concentrates on layout rather than routing we<br />
will assume that (2) and (3) also have no effect on layout. This is a reasonable assumption<br />
since <strong>FPGA</strong> routing resources are independent from computational ones and it is not generally<br />
necessary to allocate computational logic resources to either <strong>of</strong> these functions 1 .<br />
Conditional statements allow different hardware to be generated depending on the evaluation<br />
<strong>of</strong> a boolean expression. This is significant because the two possible branches <strong>of</strong> the condi-<br />
tional can have different sizes and thus any reference to the size <strong>of</strong> the overall conditional<br />
must take this into account. The easiest way to do this is to allow placement expressions to<br />
contain conditionals <strong>of</strong> their own, a simple and remarkably powerful approach.<br />
Loops allow the instantiation <strong>of</strong> multiple hardware blocks. An important realisation for the<br />
1 Issues <strong>with</strong> insufficient routing resources are unusual in most cases when using the standard placer and<br />
router. However, if a lot <strong>of</strong> logic is packed <strong>with</strong> LOC/RLOC constraints regardless <strong>of</strong> the available routing<br />
resources this could increase the risk <strong>of</strong> routing congestion making it possible to describe circuits that can<br />
not be routed.