Function Library

Is the source code to the Gedae libraries available for modification and extension as you build your own library functions?

We do not make source code available for a vendor's optimized library. However, the source code for all embeddable primitives is available and can be viewed and/or edited by double clicking the primitive title bar on the graph. When primitives are modified in this way, it is the user's responsibility to save the primitive under a new name so that the library distributed with Gedae remains unchanged (the library is by default write protected).

The Gedae embeddable function library is constructed as shown in Figure 1. A Gedae embeddable primitive is constructed as described in the Gedae User's Manual. The embeddable primitives supplied with Gedae call a core set of functions whenever possible. The core functions are a set of routines that call functions in vendor's optimized libraries. Consequently, if the embeddable graph is targeted to the host, then a vanilla C code version of the core function is used.

The Gedae embeddable primitives are written using pseudo-code that is used during the automatic code generation process. The resultant generated code makes calls to core functions. The appropriate call will be referenced during the code generation process depending on the target hardware. This structure provides a convenient way to integrate with multiple optimized libraries depending on vendor library support. Not all of the embeddable primitives reference core functions and not all of the vendor-optimized functions are referenced.

Users are provided with a document describing the core library which is referred to as the E-library. The E-library contains a set of functions which are most often found in vendors optimized libraries. When constructing new primitives, users should call these functions to the maximum extent possible. This ensures that optimum performance is achieved and portability is maintained.

Does the Gedae library use a single or double precision functions?

The Gedae embeddable library provides single precision floating point, single precision complex, and integer functions, in addition to logical, source and sink functions.

When will an improved description of the primitive library be availble? When will the individual primitives have better descriptions? Can the box comments be viewed? How is the library validated?

Discussion

The documentation of the library was poor in early versions of Gedae, but efforts were made for Release 3.0 to provide a useful description of the library and its boxes. Appendix D of the user's manual outlines the content of the embeddable library. Tables are provided that group the boxes of the library by function type. Each table is arranged by data and token type to allow the user to easily pinpoint which box is needed. Documentation of individual primities is centralized in the boxes' Comment sections which can be viewed in several ways. The Comment descriptions are tersely worded but include full, precise formulas.

The Solution

The tables of Appendix D in the user's manual group all the functions of the library by function type. For instance, the first section of this Appendix is on "Binary Addition." The five tables in this section list all boxes included in Gedae that add two items. Each table is arranged by token and data type. If the user wanted to find the binary addition box that added a constant complex scalar to real variable vector stream, he would simply match the row marked for constant complex scalar to the column marked for real variable vector to find the box vv_addX.

The descriptions of the boxes in their Comment field provide the documentation for the boxes. These comments can be viewed by pressing the Help button in either the Add Box dialog or the Search dialog. Of course, they can alsobe viewed in the Embeddable Box Editor along with the source code of the box.The source code for all primitives is available by just double clicking onthe box to open the box editor.

The primitives supplied with Gedae call a set of core functions whenever possible. These core functions are referred to as the E underscore functions (e_functions for short). The e_functions are a set of routines which are typically supported by vendors in their optimized vector libraries. The routines allow Gedae to use the appropriate optimized library call when the box is run on an embedded processor. While looking through the code of the primitives, a description of the e_functions is useful, and this information is provided in Appendix C of the user's manual.

Steps have been taken to make finding a box easier. The tables in Appendix D that document the libraries' structure allow the user to find a box by function type. The directory structure of the embeddable library separates boxes by data (lower level directory) and token (higher level directory) type. A search utility is also available for finding boxes. The Keyword section of the box lists words describing the functionality of the box. These words along with the input and output data descriptions make up the database for the search utility.

All of the boxes in the library have been tested to some extent. At the least,each box has been successfully used in a simple graph and run on a simple data set. We call this type of testing "Level 1 Testing." All boxes in the library have been Level 1 Tested. Many boxes in the library have been more fully tested. The next level of testing, "Level 2 Testing," means the box has been included in a testing suite that is run successfully on all supported embedded architectures and at several different firing granularities. Approximately 1100 of the boxes in the library have been Level 2 Tested.

Future Plans

As mentioned above, the box comments can be viewed inside Gedae or by viewing the source code. It would also be beneficial if the comments were grouped in a separate document. Plans are in place to create a utility that automatically generates an HTML document for the library that includes all the primitive's comments. Two different versions will be created, one that will list boxes in alphabetical order, and one that groups, using the keywords, the boxes by function type.

More Information

Sections of the old user's manual, for instance Appendices C and D, are available to users by request.

How can cyclic primitives be used to reduce latency and improve memory usage?

Discussion

Primitives that have static data flow behavior - that is data flow behavior that does not change and is advertised by the box prior to runtime - have the advantage that they can be statically scheduled. Such schedules are efficient and predictable. But frequently a box does not have simple static data flow behavior. Rather its data flow behavior repeats in a predictable finite length cycle.

The Solution

Gedae allows the development of cyclic primitives. A cyclic primitive is one that has predictable data flow behavior but that behavior changes in a cyclic manner. A common example is the demux box. Consider a demux box with one input and 4 outputs whose behavior is to take in 4 tokens on the input and place one of the tokens on each of the output. A non cyclic version of this box would require all 4 tokens to be present on the input before any data was available on the output. A cyclic version of this function by contrast would break the single firing into 4 firings. On the first firing one token would be consumed from the input and placed on the first output. On the second firing a token would be consume on the input and placed on the second output. This continues until all 4 tokens are consumed and one token is delivered to each output. One benefit of using a cyclic demux is that it can get data to the first output without waiting for 4 input tokens. This reduces latency as the tokens are pushed to the output faster. It also reduces memory usage as all 4 input tokens do not have to be buffered up before they are used. If the input token is a large vector or image these savings can be quite significant.

Future Plans

Currently cyclic primitives can not have family inputs or outputs. Thislimitation will be removed in a release during the year 2001.

Will and, if so, when will a library of Gedae function boxes equivalent to the MATLAB core and signal processing functions be available?

Discussion

Great effort has been and will continue to be made to make Gedae's library as useful and complete as possible. Most non-linear algebra functions that are available in MATLAB's core library are also available in Gedae. Except for a few minor but still needed functions such as bitwise logic and inverse hyperbolic trigonometry, Gedae's core library is equal to MATLAB's. At its current state, the main deficiency of the Gedae library is its lack of special purpose libraries, most importantly signal processing. Gedae's signal processing library only contains the barest essentials, such as FIR filters, convolution, fourier transforms, simple interpolation routines, and several simple filters.

The Solution

Gedae will have a signal processing library with a breadth comparable to MATLAB's. This task will be time consuming, but it is of high priority, and we are committed to completing it in a timely fashion. Routines that MATLAB supplies in their library that are missing in Gedae have been identified, and work will begin on creating equivalents in Gedae after the release of 3.1.

Mathworks (the company behind MATLAB) has created a "MATLAB compiler" that generates C code given an m-file function. As a work around, the user may use the MATLAB compiler to generate C code and reference that C code in a Gedae box. The MATLAB compiler is described at the following webpage:

When will Gedae use a VSIPL compliant library?

Discussion

VSIPL and Gedae both take responsibility for managing memory. Gedae preschedules memory use for static data flow portions of the flow graph. The intent is to preplan and therefore reduce runtime overhead. Fortunately, the VSIPL libraries provide functionality that makes it possible to avoid the provided memory management. Further, the Apply method of each function box is invoked by the Gedae runtime static scheduler. So, at the moment, Gedae can not take advantage of chaining.

The Solution

As soon as the vendors supply VSIPL compliant libraries, and we see a demand, we will port the Gedae vector library (the "e_functions") to use the VSIPL libraries.