Norman

It is possible to use Cheops' resources in a fully static fashion, compiling code that sets up the crosspoint switch in a specific way and assigns tasks to specific hardware devices. Indeed, several simple programs (mostly for diagnostic purposes) were written to operate in this manner. However, because the stream processors are on removable submodules and thus the configuration may change from time to time or from system to system, this solution isn't desirable. Further, static scheduling becomes nearly unworkable in a multitasking environment like Magic7, where several processes may be competing for the same resources.

In order to alleviate these problems, we have developed a resource management daemon named Norman. It manages the system resources, such as the currently installed stream processors and the Nile Buses, maintaining scoreboards and queues for each. A user program -- a process which handles file I/O, interaction, and so forth -- will pass a linked-list data structure describing the data-flow portion of the algorithm to Norman. An individual stream transfer making up a sub-part of the data-flow graph occurs when all prerequisite data, an appropriate stream processor, and a destination are available. Transfers may optionally be made dependent upon a real-time clock (counting video frames on a selected input or output module) to permit process synchronization with video sources or displays. The programmer may associate a callback routine with any individual transfer, to inform the invoking process of the status of the data-flow processing.

Norman can be said to be a fully dynamic scheduler, as it assigns tasks to specific processors only at run time. A still finer distinction needs to be made, though: does the daemon assign physical devices to elements in the entire data-flow graph as soon as received, or does it assign devices as they become needed and available? The initial implementation of Norman did the former, a strategy which entailed less dynamic decisionmaking, but ultimately proved less efficient as well as not amenable to a multitasking environment. The current version of Norman does all scheduling on the fly.

For more information on Norman, you might check what was written by its first author :

I. J. Shen, "Resource Manager for a Video Processing System," SM Thesis, MIT, 1992.

Although conceptually part of the operating system, Norman runs as a separate application. User applications communicate with Norman in the same way they communicate with Magic7, via the i960 system call mechanism. If using the Rman library with your application (as do all our demos and examples), Norman will be automatically started up if needed when the program calls RmanInit(). The version of Norman installed in $CHEOPS_LOCAL_BIN will be used.

If you want to use a different version of Norman, or you want additional debugging statements enabled, you need to manually start Norman before running your program for the first time after a Magic7 reboot. Use this command :

chex -ser 0 norman

                                                                   Default
     norman [ ( -ramlog | -console ) ]     # dest for debug info   (ramlog)
            [ -d <debug_suite> [<debug_suite>] ... ] # see below   (none)
            [ -filter ]                    # disable all mojo SPs  (no)
            [ -quiet ]                     # no init printout      (no)
            [ -nile (white|blue|all) ]     # enable nile bus       (all)
            [ -m1 <id> (white|blue|all) ]  # enable M1 nile bus  (white)

chex -ser 0 norman -debug general nile

Creating the linked list describing the data-flow graph is the only unconventional task facing the programmer. Although these can be created and manipulated directly by the user application, a saner approach is to build them using the Rman library.

This is a "fix it yourself" page, located at ${CHEOPS_BASE}/WWW/norman/index.html