You can configure board clocking in your system in one of the following ways. Choose only one of these configuration methods across all boards on the CT bus. Otherwise, the two methods interfere with one another, and board clocking will not operate properly.
|
Method |
Description |
|
Using the clockdemo application model |
Create an application that assigns each board its clocking mode, monitors clocking changes, and reconfigures clocking if clock fallback occurs. A sample clocking application, clockdemo, is provided with Natural Access. clockdemo provides a robust fallback scheme that suits most system configurations. clockdemo source code is included, allowing you to modify the program if your clocking configuration is complex. For more information about clockdemo, refer to the NMS OAM System User's Manual. Most clocking applications (including clockdemo) require that all boards on the CT bus be started in standalone mode. To learn how to set the board to start in standalone mode, refer to the board manual. |
|
Using board keywords with or without application intervention |
For each board on the CT bus, set the board keywords to determine the board's clocking mode and to determine how each board behaves if clock fallback occurs. Unlike the clockdemo application, which allows several boards to take over mastery of the clock in a fallback situation, the board keyword method allows you to specify only a fixed primary and secondary master. For this reason, the board keyword method is best used only if you do not want to implement clock fallback in your system, or in test configurations where clock reliability is not a factor. The board keyword method does not create an autonomous clock timing environment. An application must still intervene when clock fallback occurs to reset system clocking before other clocking changes occur. If both the primary and secondary clock masters stop driving the clocks (and an application does not intervene), the boards default to standalone mode. |