Verification of Parameterised FPGA Circuit Descriptions with Layout ...

Verification of Parameterised FPGA Circuit Descriptions with Layout ... Verification of Parameterised FPGA Circuit Descriptions with Layout ...

24.04.2013 Views

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

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.

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

Saved successfully!

Ooh no, something went wrong!