• No results found

3.2 Logical Component Decomposition

3.2.1 LC Nodes as Components

LC Nodes seem a natural way to decompose an FPGA into components. To confirm whether they are suitable, however, we must ensure they meet the three component requirements presented at the beginning of this chapter. We will come back to the first requirement later, for now we examine the second and third.

The second component requirement states that we must be able to incrementally compose components to get the delay of a path as the path grows in length. Growing paths in this way allows us to easily run shortest paths algorithms. To prove that LC Nodes meet this requirement, we first show that any path between source sink registers in the physical resource graph can be represented by a corresponding path through the LC Node graph.

Theorem 3.2.1 Given Pphys= (r1, c2, . . . , cn−1, rn), a path that starts at a register and ends at a register, we can construct a corresponding path,PLC= (s1, m2, . . . , mm−1, em), in the LC Node

graph that covers the same nphysical resources with mLC Nodes.

Proof LC Nodes represent short paths between physical nodes that are either registers or physical resources with fan-in greater than one. Thus, to construct the corresponding LC Node path, we find nodes in the original path that are either registers or have fan-in greater than one, extract the short paths between these special nodes, and find the corresponding LC Nodes that cover the same short path. By doing this in the order in which these special nodes appear in the original path, we can construct the corresponding LC Node path.

Since the original path has only two registers, one at either end, our LC Node path will have a Start Node at the beginning, an End Node as the last Node, and all other LC Nodes will be Mid Modes.

Corollary 3.2.2 LC Nodes can be incrementally composed to construct any measurable path in the physical resources graph.

Proof From Theorem 3.2.1, we know that every measurable path in the physical resource graph has a corresponding path in the LC Node graph. Therefore, by selecting, in-order, the LC Nodes that form a given path, we can incrementally construct the measurable path at the granularity of LC Nodes.

Assuming we have the delay of all LC Nodes, Corollary 3.2.2 shows that we can incrementally get the delay of any path at an LC Node granularity. Since, by definition, we do not care to know the delay of resources below the LC Node granularity, LC Nodes satisfy the second component condition.

The third component condition requires that components be small and of similar shape. LC Nodes, by definition, are as small as we care to measure. To show that they are of similar shape we appeal to the regularity of FPGAs. Although modern FPGAs are heterogeneous, containing logic blocks, embedded blocks, and advanced hierarchical interconnect, there’s only one or a few logic block designs repeated throughout the FPGA. The same holds true for embedded blocks. Moreover, the interconnect follows a regular repeating pattern throughout the FPGA fabric with few to no exceptions. As such, when we construct the physical resource graph of an FPGA, we see many identical subgraphs repeated throughout. All repeated subgraphs will decompose into the same set of LC Nodes. Therefore, we will have many LC Nodes of the same shape, meeting the third component condition.

Finally, the first component requirement states that we must be able to compute the delay of components. To get the delay of a component, Timing Extraction measures the delay of a number

of paths and takes a linear combination of these delays to get the component delay. Although LC Nodes meet the second and third component constraints, they fail the first.

An LC Node-based solution for Timing Extraction will use the measured delay of paths to compute a unique delay for each LC Node. It is easy, however, to construct a second solution given a first, demonstrating that we cannot know the delay of LC Nodes. Theorem 3.2.3 formalizes this.

Theorem 3.2.3 For a given LC Node graph, at least two different solutions for the delay of LC Nodes exist when computed from measured path-delays.

The proof hinges on the fact that every path hasexactly oneStart Node andexactly oneEnd

Node.

Proof Given a solution to the delay of all LC Nodes, we can construct a second, equally consistent

solution as follows. First, increase the delay of every Start Node byα. Since a path uses exactly

one Start Node, using the new Start Node delays to compute the delay of any one path will

result in a path-delay that is exactlyαgreater than the real delay of that path. Thus we need to

reduce the delay of some other node in the path byαto achieve the correct result. We do this by

subtractingαfrom every End Node. Doing this will reduce the new delay byαsince a path uses

exactly one End Node. At this point we have a second solution for the delay of LC Nodes that is consistent with the measured path-delay.