30.9.1.7 Initialization

At power up, the MediaLB Controller might output a MLBReset command in the System Channel (all System commands are optional). Upon reception of the MLBReset command, all MediaLB Devices will cancel any current transmissions or receptions and clear their buffers.

Two scenarios are supported to configure MediaLB Devices and ChannelAddresses:

  • Static pre-configured before startup. The system implementor decides which ChannelAddresses are to be used for every communication path on MediaLB. This static MediaLB configuration can be communicated by the EHC to the Controller through pre-defined power-up logical channels or through a secondary port.
  • Dynamically at run-time. Dynamic configuration allows the board designer to support multiple build options where the EHC can query to find out if a particular Device is present or not on a particular board. The EHC instructs the Controller to scan for a particular DeviceAddress in the System Channel. The Controller uses the MLBScan command to look for a Device. The Controller then notifies the EHC whether the Device is present or not. If the Device is present, then the EHC can instruct the Controller to set the ChannelAddresses for the Device found. The EHC sends messages to the Controller to set each Indices/Logical channel, and waits the appropriate amount of time between each message as specified in the Devices documentation. When that particular Device is configured, the EHC can instruct the Controller to scan for the next Device.

Since the MediaLB Controller is the interface between the MediaLB Devices and the MOST Network, the Controller provides the MLBC signal and will also continue to operate even when the MOST Network is unlocked. When no activity exists on MediaLB, the Controller can shut off the MLBC placing MediaLB in a low-power state. The ChannelAddress assignments are not affected in low-power state; therefore, the same communication paths exists once MLBC is restarted.

MediaLB Devices are synchronously cliented to the MediaLB Controller through the MLBC signal. Since the Controller is synchronized to the MOST Network, the MLBC signal provides Network synchronization to all MediaLB Devices. Once the Controller starts up MLBC, all MediaLB Devices must synchronize to the MediaLB frame before communication can commence. When not frame-locked, Devices must search for the FRAMESYNC pattern, which defines a byte and physical channel boundary. Additionally, the start of the MediaLB frame (PC0) occurs one quadlet after FRAMESYNC is present on the bus. Even when a Device is frame-locked, it should check every frame continuing to validate that it remains frame-locked. While frame-locked, the Device can access MediaLB according the rules of the MediaLB protocol.

A MediaLB Device must perform the following operations:

  • Rules for synchronization to MediaLB:
    • When locked, as long as FRAMESYNC is detected at the expected time, the Device must not synchronize to unexpected FRAMESYNC patterns.
    • When locked and FRAMESYNC is not detected at the expected time for two consecutive frames, declare unlock, and the Device stops driving MLBS and MLBD.
    • When unlocked and FRAMESYNC is detected at the same time for three consecutive frames, declare lock, and the Device can resume driving MLBS and MLBD when appropriate.
  • When the Tx Device for a physical channel, it drives Command onto MLBS at the beginning of the physical channel and then sets MLBS to a high impedance state. In addition, the Tx Device drives the data quadlet onto MLBD line for the duration of the physical channel, and then sets the MLBD line to a high impedance state. The NoData command is the default for the MLBS line and does not need to be driven by the Tx Device.
  • When the Rx Device for a physical channel, it drives RxStatus onto MLBS in the second byte of the physical channel and then sets MLBS to a high impedance state for asynchronous, control and isochronous (non-broadcast) transmissions. When no RxStatus is driven, the MLBS line defaults to ReceiverReady; however, it is recommended that the Rx Device drive the ReceiverReady response for non-broadcast transmissions.
  • When the Rx Device for a physical channel, it must not drive any RxStatus (defaulting to ReceiverReady) for synchronous and isochronous (broadcast) transmissions.