Feasibility

A HDL logic module can be seen as a cause-effect mapping from inputs to outputs, as figure 6-4 shows. A bidirectional signal can be treated as a group of (usually three) inputs and outputs. Every output signal can trace backwards to a number of input signals as its source (unless it is driverless), which builds up a causality tree, like Oj0 in figure 6-4. The causality tree corresponding to an output

port is a general tree structure that represents the logic dependency.

Figure 6-4 General logic and the causality tree

. . .

*

*

In terms of presence, a tree can be originated or derivative. An originated tree will be explicitly printed in the final rewritten HDL file and a derivative one not. In terms of type, a tree can represent an arithmetic, a logical, a function, or an aggregate. The root index is pointed to the node index in the node/symbol table. For universality, the tree has leaf properties such as slice, aggregate choice, and condition tree information. The trees can be concatenated to build up paths from inputs/drives to outputs/loads. During the path enumerating, if a path has no drive or no load, it will be not calculated, because the rewrite is end-to-end bounded.

The initial purpose of our logic rewrite is to keep the external timing of the dynamic module after synchronous pipelines are attached to it. This involves two parts of change,

a) the input sequence is cycle-delayed (d). b) the output sequence is cycle-advanced (p).

In terms of the timing sequence, cycle-delayed means the signal comes a cycle of clock later and cycle-advanced means the signal comes a cycle earlier. Both rewrites are often not so straightforward because the available pipeline stages to be processed may be implicitly scattered in multiple branches of the causality trees. In the DPR practice, we have another alternative, in which both the dynamic module and the static module are rewritten in cycle-delayed-input pattern. We use this approach in this paper, so that the tool needs only to process the input compensation. Of course there are modules, in which no delayed units are found along a causality tree and the cycle delayed rewrite is therefore impossible. Fortunately in most high-speed DPR projects, which need the synchronous pipeline compensation, there are enough pipelines to be shifted in the module. In low-speed DPR projects, the timing closure is not critical along the boundary and therefore, the HDL code can stay untouched. The automatic HDL reuse tool to fulfil this requirement has “dynamic reuse” property, which is able to make sound modification upon the reused code meanwhile keeping the external behaviour of the whole logic. Correspondingly, the conventional HDL code reuse can be named “static reuse”, in which the code can be reused by slight modification. Such modification might be some parameter (generic) changes, for example, data bus width, switching off ECC, etc. Actually the simplicity of the “static” code reuse is achieved by designer’s extra work to make those parameterized logic run properly. Apart from the static HDL code reuse, the dynamic HDL code reuse discussed here targets on using the existing logic code for a non-copied and non-switched purpose. For example, an SDRAM controller which needs lower latency might probably be generated from an existing SDRAM control logic that has longer latency.

6.2.1 Underlying rules

Basic rules applied to the reuse tool include the extended boolean equations such as, d(A • B) = d(A) • d(B)

d(~A) = ~d(A)

d k+1_{(A) = d(d} k _{(A)), k > 1}

Here, A and B are signal names. The operator d means a cycle of clock delay is applied to the operand, assuming that all the calculations are in the same clock domain. The tilde ~ denotes a unary

Chapter 6 HDL code reuse tool inversion (NOT). And • represents a binary logic operator like AND, OR, XOR, etc.

A rewrite can be achieved by logical expression transformation. For example, the tree in figure 6-5 is from within a dynamic module, where Oj is the output and Ik0, Ik1, ... Ik3 are the inputs of the dynamic

module. As discussed before, the inputs should be rewritten to compensate the synchronous pipelines. This original causality tree can be behaviourally expressed as

Oj = d((d( Ik0) OR Ik1) OR d(Ik1 AND Ik2 AND Ik3)).

Figure 6-5 Original causality tree

In figure 6-5, ~d means delayed NOT, dAND means delayed AND, and dOR means delayed OR. Similarly we can also have dXOR for delayed XOR, and so forth. To do a cycle-delayed rewrite upon the inputs, the tree in figure 6-5 can be transformed to figure 6-6 and expressed as

Oj = (d( d(Ik0)) OR d(Ik1)) OR d(d(Ik1) AND d(Ik2) AND d(Ik3)).

Figure 6-6 Transformed causality tree from figure 6-5

d OR O_j d AND OR ~d Ik0 I_k1 I_k2 I_k3 OR O_j d AND OR ~d d(Ik0) d(I_k1) d(I_k2) d(I_k3)

Now the inputs are explicitly synchronous units. The logic is then rebuilt to equip the boundary with synchronous pipelines. This example is quite simplified, just to demonstrate the idea. Rewrite technology is based on expression-matching approach. For example, the cycle-delayed rewrite is equal to the expression replacement

A → d (A).

Here the right-side expression is to be replaced by the left-side one. If no match can be found for all branches of any one causality tree, the tool reports the user with impossibility messages. Some other rewrite examples could be

A → A AND d (B), A OR B → A AND d (B).

Such replacements, other than the pure cycle-delayed one, are much more complicated to be done manually. They are to be supported by the tool of next version. The reuse tool will try all possible equivalent variations of the target causality trees, search along it, and match the sub-expression with the given one if possible.

6.2.2 Path management

All paths must be firstly enumerated and only then operations upon them are possible. Figure 6- 7 shows a simple example of path enumeration.

Figure 6-7 path enumeration and association table

The interested units in the design are allowed to be shared among multiple paths, where path coupling happens. If one of the coupled units is used for replacement with respect to one path, the other paths should be carefully treated in the way unexpected changes are avoided. This often involves path decoupling. In current version, because we deal with only the synchronous units (FFs), we duplicate

0 1 2 0 1 a b d c I₀ I₁ O₀ O₁ 2 - 2 2 I₂ 1 2

Chapter 6 HDL code reuse tool the necessary coupled FFs when path coupling happens. Figure 6-8 shows a case, in which two (actually four) paths couple, where the rings denote pipeline positions and the clouds are asynchronous logic.

Figure 6-8 Path coupling