next up previous contents
Next: 5 Memory Management Up: Appnotes Index Previous:3 Introduction to Data Flow Graph Design

RASSP Data Flow Graph Design Application Note

4.0 Concept of State

In general, a pure DF graph architecture is greatly simplified if all the input data elements to a node can be processed the same way. In a general signal processing problem, however, the processing of data packets depends upon their position in the data stream. Usually the first and last packets of a data stream have to be augmented by additional data. For example: when running a FIR filter on a data stream, the filter must be initialized and terminated properly.

There are essentially two methods available in a DF graph to accomplish this data packet dependency processing. The first technique makes use of a feedback queue to keep the value of a counter. The processing performed internally by the node is made to depend upon the current value of this counter which is taken from this queue. For this implementation, the internal node processing was made to depend upon the node state i.e. the count of the data packet that is currently being processed. The code that implements the state update and processing of the state is in the node processing wrapper.

There are several tools that simulate and generate code for DF graphs. The tool that was used for RASSP was GEDAE™. Using GEDAE™, this state processing becomes part of the GEDAE™ methods. Alternately, the node processing state may be stored as a local variable as part of the GEDAE™ methods instead of being a queue variable where it would be a formal part of the graph.

The other technique that is used to mark the state of a data packet is to embed in each data packet its state. Each node will now have to extract the state marking to determine the processing required. This, in theory, this makes the DF graph non pure, i.e., data and control information are mixed in the same data stream. This technique may often be a preferred solution to the feedback queue because it insures synchronization of the processing with the data packet. The difficulty with the implementation of this technique is the actual insertion and removal of the state header. In a complete signal processing system, the data stream is usually prepared by an input processor. In many cases the state information can be inserted into the data stream as a header. However, each node that processes this packet with the header is now required, as a minimum, to remove the header. Each node that is used in the graph is now required to have a primitive method to remove the header from the data before the core processing associated with this node can be accomplished and then the header must be reinserted into the output stream.

A practical solution with the exiting DF software development systems would be to use the feedback queue to implement the state dependency during the initial design of the DF graph. This will allow the use of a maximum amount of library primitive nodes in the design. As soon as the basic DF ideas are implemented and tested on the workstation version of the graph implementation, the graph can be redesigned with the header packets. In practice, the state queue feedback method requires the designer to maintain synchronization of the processing of all the nodes with the correct packet state. This is made more difficult since the packet count must be kept locally on each node. The header method, which keeps the state information with the packet, is a direct method of synchronization.

4.1 Data Processing by Slices

An example of state dependent processing is illustrated by the ETC norm processing. In this case the data stream for each ping was divided up into slices which were batch processed. The first and last slice of each ping is required to be processed differently because the first slice data stream must be augmented by folding the first n data points and adding them to the beginning of the slice. Similarly, at the last slice of the ping the data is folded and added to the end of the last slice's data set. Figure 4-1 shows the feedback data queues that maintain the state or the slice count.

Figure 4 - 1: ETC Graph

The folder, median and smooth require the slice count and include the counter update code as:

counter = counter + 1 modulo number_slices

where counter is the value (state) stored on the feedback queue. The internal computation in the node makes use of the counter value to determine which slices require the additional folding to be processed.


next up previous contents
Next: 5 Memory Management Up: Appnotes Index Previous:3 Introduction to Data Flow Graph Design

Approved for Public Release; Distribution Unlimited Dennis Basara