Clocks and Timing on an FPGA

LabVIEW NXG implements FPGA code with a synchronous digital circuit that enforces the standard dataflow model. This synchronous digital circuit is driven by a clock, which is a periodic digital signal that determines the allowed propagation delay. Propagation delay is the time it takes a signal to travel along a combinatorial logic path from one register to the next. The combinatorial path is the collection of logic and wiring that a signal encounters between two registers.

Propagation delay consists of the following components:

• Logic delay—A function of the number and type of logic gates the signal traverses. It often represents the most significant component of propagation delay.
• Routing delay—A function of the length of the wire path the signal traverses. It is generally small because the FPGA compiler attempts to cluster the components of a combinatorial path as tightly as possible on the FPGA. However, as the FPGA VI approaches the size limits of the FPGA, the physical separation between functions increases, and the routing delay can become a significant component of the total propagation delay between two registers.

Because registers update every clock cycle, the propagation delay must not exceed the clock period. By default, the LabVIEW NXG FPGA Module produces circuits that run at a clock rate of 40 MHz outside the Clock-Driven Loop. A 40 MHz clock rate corresponds to a 25 nanoseconds clock period.

Automatically Inserting Registers to Reduce Propagation Delay

For paths that exceed the 25 ns constraint, LabVIEW NXG automatically inserts registers that break up the overall propagation delay into smaller delays to ensure that the propagation delay in the generated circuit is under the limit.

For example, the following figure includes a chain of nodes: A, B, C, and D. Each node has a certain amount of logic delay. The wires between the nodes have routing delay. The logic delay and the routing delay add up to a total delay of 29 ns, which is greater than the 25 ns timing constraint.

To meet the delay propagation constraints, LabVIEW NXG automatically inserts registers along that path. In the following figure, the register breaks up the path into two paths, making both paths within the 25 ns timing constraint.

Automatic Loop Pipelining for Faster Execution

LabVIEW NXG executes loops with only algorithmic code in a pipelined fashion. In other words, a loop iteration may start before the previous iteration is complete as long as all the data dependencies for the iteration are satisfied, which makes the loop execution more efficient.

The following diagram illustrates loop pipelining with two loops and a Sequence Structure. The diagram includes five independent code units.

	The controls execute simultaneously at the startup of the VI because they do not have any data dependencies.
	The For Loop is an independent code unit with data dependency on the x control. The For Loop executes in a pipelined fashion because it includes only algorithmic code.
	The While Loop is an independent code unit with data dependency on the y control. The While Loop executes in a pipelined fashion because it includes only algorithmic code.
	The Sequence Structure is an independent code unit with data dependencies on the z control and the output of the While Loop.
	The element indicator is an independent code unit with data dependency on the Sequence Structure.

The following figure illustrates the execution time of two consecutive calls to this VI, each big box representing one call to the VI. Each small box or group of small boxes represents the execution time of the corresponding code unit in the VI. With pipelining, loop iterations of the For Loop and While Loop have overlap in time, which results in faster loop execution.

For each call of the VI, the For Loop always iterates five times with a definite execution time because the Count input is set to 5. The While Loop iterates a variable number of times with an indefinite execution time because the number of loop iteration depends on the value of the y input, which can vary from call to call.