Interfacing to OS81118 INIC

The OS81118 INIC provides a Universal Serial Bus (USB) 2.0 High-Speed Port. The USB Port allows connection to the INIC (USB device) by an EHC (USB Host Controller) and supports on-PCB upstream USB 2.0 high-speed bulk transfers using a standard USB 2.0 physical layer at a rate of 480 Mbps. The USB Port provides access to the MOST network via an interface commonly found in most applications. This is especially useful for microcontrollers that do not support the typical interfaces (i.e., MediaLB ® ) found in an automotive application. USB can transport streaming data and packet data simultaneously.

Furthermore, the INIC provides a Serial Peripheral Interface (SPI) Port that supports the transmission of asynchronous packets over an interface that is compatible with many micro-processors, data converters, and other devices. When the SPI Port is created, it operates as an SPI bus slave.

In addition to these ports, an I 2 C Port and a MediaLB (Media Local Bus) Port are offered.
The I 2 C Port can transport control data. Simple designs with OS81118 can make use of the traditional I 2 C Port, enabling cost-effective realizations, while more advanced solutions may use the I 2 C Port in combination with USB for versatile and high-speed data transport.
The MediaLB Port serves as an on-PCB, serial inter-chip communication bus which can simultaneously transport all types of multimedia signals that are found in modern infotainment systems including streaming data, control data, and packet data. The MediaLB interface is synchronized to the MOST network thus providing seamless streaming capabilities to and from the MOST network without buffering and without delay. MediaLB allows cost effective interfacing of multiple ICs and their inter-chip communication. The communication between all participants of MediaLB is administered by INIC.

The MOST Port enables support of port-specific network handling, including the selection of the physical layer to be used.

Encapsulation of Network Services

The INIC encapsulates all network functionality including the major parts of the transport layers on chip. The result of this encapsulation is that INIC is a full network interface on silicon that cannot be set in undefined states, which can happen with traditional register controlled chips. Its command interface is the INIC API, which is an object-oriented software interface. In addition, the MOST NetServices V3.2.x that is running on the EHC, represents the application socket, implementing for example the application message service, a command interpreter, and a resource management.

A very small number of high-level commands with MOST syntax are used for chip control. For management of the streaming resources of INIC, a port and socket concept is provided. Streaming connections can be managed easily by this high-level object-oriented control interface, usually known for example from some operating systems.

The INIC architecture handles all time-critical, resource-intensive, and fail-safe relevant parts of the network functionality on-chip. Porting of the sensitive and time-critical portions of the network driver to customer’s environments is no longer required. This simplifies the implementation of MOST technology into a device and reduces time to market and development costs.

Since all functions necessary to operate the MOST network including a minimum NetBlock are implemented on chip, INIC can independently start/join the network quickly, without waiting for an application to start. INIC is independent from the EHC’s startup behavior allowing immediate availability of the network. A MOST device based on INIC is able to answer requests to the NetBlock and run MOST, even if the application on EHC is not running or not yet started, thus providing maximum robustness for the network. This self-contained operation of the network is called Network Protected Mode. INIC leaves this mode and provides the services of the MOST network to the application only after the application has executed an attach procedure with INIC.

MOST NetServices V3.2.x on EHC

MOST NetServices V3.2.x is the driver for the INIC running on the EHC. It implements the functionality of the MOST Network Service required by the MOST Specification [1] .
The MOST NetServices API is easy to learn, which minimizes the risk of errors, simplifies evaluation, expedites development time, and spares configuration efforts especially for engineers starting with MOST.

It is recommended to use the MOST NetServices V3.2.x, since it encapsulates the INIC API and it includes extended functionality. Thus the MOST NetServices V3.2.x provides the ideal solution for optimal network access.

Port Message Protocol

To be able to exchange control messages, the INIC provides a set of independent Port Message Protocol (PMP) channels. The communication is handled through the PMP as specified inside the Port Message Protocol V2.0.1 Specification [3] . In PMP terms, the EHC will be referred to as the Primary Device (PD), the INIC as the Secondary Device (SD).

The PMP provides multiple virtual channels, stated as FIFO channels. Each PMP channel is assigned to a unique FIFO channel. This allows running multiple PMP channels through sockets on a single physical port, e.g., MediaLB Port. Flow control and hand-shaking mechanisms of the protocol prevent starvation or deadlocks when PMP channels share a common physical medium. Besides the bi-directional exchange of packet-based data, the protocol is used to communicate the delivery status back to the EHC and allows taking actions on delivery failures.

The PMP is not designed for a specific application and thus its definition must be completed per application. This chapter extends the PMP specification in a way that is necessary to establish INIC-specific PMP channels. Therefore, INIC-specific details of the protocol will be defined hereinafter as part of a higher communication layer. This includes the assigned PMP channel numbers (see Table 2-1 ), the data message content types and format, and the status message failure codes (see Table 2-3 ).

Control Message Format

Figure 2-1 shows the Data Message format used to transport a control message. The message format consists of two main sections, the PMP header and the PMP payload.

Figure 2-1: Control Message Format

The PMP header contains the ExtType field that must be 0x00 (only one format type is supported).

If the INIC receives messages, any number of stuffing bytes is allowed. However, when transmitting messages to the INIC, it is strongly recommended to use 2 stuffing bytes. Control messages sent by the INIC will always use 2 stuffing bytes.

Figure 2-2 depicts the PMP payload fields. For the explanation of the PMP header fields refer to the Port Message Protocol V2.0.1 Specification [3] .

Figure 2-2: PMP Payload

 

Table 2-2: PMP Payload Format Field Description

Format Field	Size	Description
SrcDeviceID	16 bit 1	Source Device ID. Indicates the Logical Address of the device that sent the message. SourceID 0x0001 (LocalID) indicates a message coming from an internal FBlock. SourceID 0x0002 indicates a message coming from the EHC.
TgtDeviceID	16 bit 1	Target Device ID. Indicates the device address to which the message is sent (DeviceID). The following addresses are reserved: 0x0000, 0x0001, 0xFFFF. 0x0000 and 0xFFFF return format failure (0010) as transmitted message status. 0x0001 (LocalID) is the Local ID. A message using this address is used for internal communication between EHC and INIC.
FBlockID	8 bit	Function Block ID. Determines the function block that is addressed.
InstID	8 bit	Instance ID. Determines the instance of the FBlock to unambiguously address FBlocks of the same type.
FktID	16 bit 1	Function ID. Determines the property or method that is addressed.
TelID	4 bit 2	Telegram ID. Identifies the telegram type. Zero for a single transfer, non-zero (1...4) when transferring segmented messages.
OPType	4 bit 2	Operation Type. Determines the operation on the property or method. Also indicates the direction in which messages are exchanged. This field is defined in the MOST Specification [1] .
LLRBC	8 bit	Low-Level Retry block count. The maximum block count number is limited to 100. If a higher number is entered, the value will be set to 100 automatically.
TelCnt	8 bit	Telegram Count. Counts the number of messages in the telegram. Starts at 0x00 for the first telegram and increases by 1 for each following telegram. When 0xFF is reached, the counter restarts at 0x00.
TelLen	8 bit	Telegram Length. Number of data bytes that are valid in the telegram. The maximum number is 45 bytes.
TelData	0...45 bytes	Contains the payload of the message.

Note 1: Big-endian

2: TelID and OPType share one byte; TelID is stored in the high-nibble (bits 4-7), OPType information is stored in the low-nibble (bits 0-3).

 

Configuration Interface

The configuration interface is used by an EHC to control the INIC and to access the MOST network for management purposes.

Typically, a MOST network device includes a microcontroller that manages the local INIC via the configuration interface. However, not all MOST network devices must necessarily incorporate a microcontroller. To cover these different approaches, the configuration interface supports the following cases of application:

• • EHC controlled and
• • Remote controlled.

EHC Controlled

The EHC-controlled configuration interface is shown in Figure 2-3 .

Figure 2-3: Configuration Interface – EHC Controlled

A local EHC can utilize the ICM and RCM channels to access the configuration interface. It has to use the internal Device ID 0x0002 as the source address when sending messages.

The address handling of a message forwarded by the INIC to the configuration interface is done as follows:

• • The source address is always the Local ID 0x0001 if the message was not received from the MOST network.
• • The target address for a received single cast message is replaced by the EHC’s internal Device ID 0x0002.
• • The target address for a multi cast message is not replaced.

 

The usage of the ICM PMP channel is as follows:
Only access to local FBlock INIC.

The usage of the RCM PMP channel is as follows:
Full access to the MOST network for management purposes, which includes the control of remote INICs, NetworkMaster functionality and system diagnosis. Control messages received via the MOST network and/or the application interface (targeted to the Local ID 0x0001) are forwarded to the RCM PMP channel by using the following routing rules:

• • All FBlock INIC status messages
• • All FBlock NetBlock status messages
• • All FBlock NetworkMaster request messages
• • All FBlock ExtendedNetworkControl status message

Remote Controlled

A remote EHC controls the INIC via the MOST network. For that it is required to set the Configuration Interface to None (Remote Control Mode).

The remote-controlled configuration interface is shown in Figure 2-4 .

Figure 2-4: Configuration Interface – Remote Controlled

Operation Modes

Depending on the application design that requires either an EHC-controlled or a remote-controlled solution, the device needs to pass dedicated operation modes, see Figure 2-5 . Operation modes are:

• • Protected Mode - used by the EHC-controlled and the remote-controlled application
• • Attached Mode - solely used by the EHC-controlled application
• • Remote Control Mode - solely used by the remote-controlled application

 

Figure 2-5: Configuration Interface Modes

 

Protected Mode

In Protected Mode the INIC autonomously controls all device management functionality including power management. In this mode all MOST sockets are destroyed and new sockets cannot be opened.

While in Protected Mode, the MOST network remains Available ; all diagnosis tasks (e.g., RBD, physical layer test) will be finished.

The Protected Mode incorporates the sub states:

• • Cleanup process
• • Unsynchronized
• • ICM/RCM PMP channels synchronized

In Protected Mode INIC.DeviceStatus.Status.ConfigInterfaceMode is Protected .

 

Cleanup process

The cleanup process can be triggered by several indicators:

• • PMP channel synchronization loss, which can occur on ICM and RCM PMP channels under the conditions shown in Figure 2-5 . Loss of synchronization can be based on different criteria, such as:
• - The INIC receives a PMP SYNC command that addresses the ICM or RCM channel
• - The PMP watchdog has expired
• - PMP channel re-synchronization occurred due to an EHC reset
• • The NetInterface Off state has been entered while being in Remote Control Mode.
• • The application controlling the INIC remotely has sent an INIC.DeviceSync(Synchronization = Sync) or INIC.DeviceSync(Synchronization = UnSync) message.

 

After the cleanup process state has been entered, the INIC performs the following actions:

• • Regains power management control
• • Broadcasts NWM.Configuration.Status(NotOK) , if FBlock NetworkMaster is local. Will be forwarded to the application interface if in Attached Mode.
• • Disables message routing to the ICM and RCM PMP channels
• • Destroys all resources created during runtime
• • Removes all FBlock INIC notifications
• • Drives the MUTE/ RSOUT /GP8 pin low for 10 ms if the pin is configured to signal reset (see MUTE/RSOUT Configuration)
• • Cancels a pending startup process that was initiated by function INIC.MOSTNetworkStartup()

 

Note: The INIC remains in the cleanup process state until all actions listed above have been finished. Therefore, all ICM and RCM PMP channel re-synchronization attempts are blocked during this period of time.

 

Unsynchronized

The unsynchronized state is the default state that is entered after the INIC is reset or a cleanup process has been finished.

 

ICM/RCM PMP channels synchronized

The PMP channel synchronized state is entered as soon as the EHC has finished ICM and RCM PMP channel synchronization. Now, the EHC has full access to all API functions.

Before PMP channel synchronization can start, the ICM and RCM PMP channels must have been setup and configured as explained in Section 2.1 . ICM and RCM PMP channels get synchronized by the PMP channel synchronization procedure, which is described in the Port Message Protocol V2.0.1 Specification [3] .

 

Attached Mode

In Attached Mode, the EHC takes over responsibility for the power management.

When the Attached Mode is entered by calling the API command INIC.DeviceAttach() , DeviceAttach (0x223), the INIC performs the following steps:

• • Notifications to all API properties are set, except INIC.GPIOPortTriggerEvent()
• • Enables message routing to the ICM and RCM PMP channels

In Attached Mode INIC.DeviceStatus.Status.ConfigInterfaceMode is Attached .

The following sequence chart shows the required steps to reach Attached Mode.

Figure 2-6: Steps to Reach Attached Mode

 

Remote Control Mode

In general, the Remote Control Mode is used only by devices that do not incorporate a local microcontroller. Hence, all functionality is remotely controlled and must be handled by a remote application.

To enable the Remote Control Mode, the configuration string property Configuration Interface must be set to None . The synchronization of the remote application to the INIC and entering the Remote Control Mode is done by sending the command sequence as shown in Figure 2-7 .

Figure 2-7: Remote Control Command Sequence

 

Note: To allow a clean synchronization, the command sequence must be executed by the remote application whenever: - the network transitions from state NotAvailable to Available , - the remote application restarts, or - the remotely controlled INIC restarts.

 

In Remote Control Mode the FBlock INIC is visible to the MOST network and reported by the INIC's FBlockIDs.Status() message. Hence, a proper InstID for the FBlock INIC should be assigned. This can be done by using the configuration string property Default Instance ID.

Control messages with OPTypes Set, SetGet, Start, and StartResult initiated from MOST network side are only executable in Remote Control Mode. However, the use of these operations is limited, see Table 2-4 . The following function operations are not accessible and therefore will return a function-specific error if the configuration interface is in Remote Control Mode.

Table 2-4: Limited Write Operations

Operation
INIC.DevicePowerOff.SetGet
INIC.DeviceAttach.StartResult
INIC.MOSTNetworkStartup.StartResult
INIC.MOSTNetworkShutdown.StartResult
INIC.MOSTNetworkRBD.StartResult
INIC.MOSTNetworkForceNotAvailable.SetGet
INIC.MOSTNetworkSystemDiagnosis.StartResult
INIC.MOSTNetworkSystemDiagnosisEnd.StartResult

 

Application Interface

The application interface is used by a local EHC to send and receive application-specific control messages. This interface can be used independently from the configuration interface. This allows to have a local EHC connected to the application interface although the INIC is remote controlled.

The application interface is shown in Figure 2-8 .

Figure 2-8: Application Interface

A local EHC can utilize the MCM PMP channel as the communication interface. It has to use the internal Device ID 0x0003 as the source address when sending messages.

The address handling of a message forwarded by the INIC to the application interface is done as follows:

• • The source address is always the Local ID 0x0001 if the message was not received from the MOST network.
• • The target address for a received single cast message is replaced by the EHC’s internal Device ID 0x0003.
• • The target address for a multi cast message is not replaced.

The usage of the MCM PMP channel is as follows:
Full access to the MOST network for application purposes. Control messages received via the MOST network and/or the configuration interface (targeted to the Local ID 0x0001) are forwarded to the MCM PMP channel by using the routing rules as follows:

• • All FBlock NetBlock request messages
• • All NetworkMaster status messages
• • All request or status messages that don’t match the other rules

Operation Modes

The application interface can reside in the following operation modes, see Figure 2-9 :

• • Protected Mode - no network access
• • Attached Mode - network access

 

Figure 2-9: Application Interface Modes

 

Protected Mode

In Protected Mode the application interface is not connected. The INIC autonomously answers to any NetBlock.FBlockIDs() request message.

The Protected Mode incorporates the following sub states:

• Cleanup process

• Unsynchronized

In Protected Mode INIC.DeviceStatus.Status.AppInterfaceMode is Protected .

 

Cleanup process

The cleanup process can be triggered by PMP channel synchronization loss, which can occur on the MCM PMP channel under the conditions as shown in Figure 2-5 . Loss of synchronization can be based on different criteria, such as:

• • The INIC receives a PMP SYNC command that addresses the MCM PMP channel.
• • The PMP watchdog has expired.
• • PMP channel re-synchronization occurred due to an EHC reset.

 

After the cleanup process state has been entered, the INIC performs the following actions:

• • Regains NetBlock handling
• • Unregisters all application FBlocks by sending an appropriate FBlock list, if a NetworkMaster is known
• • Disables message routing to the MCM PMP channel

 

Note: The INIC remains in the cleanup process state until all actions listed above have been finished. Therefore, all MCM PMP channel re-synchronization attempts are blocked during this period of time.

 

Attached Mode

In Attached Mode, the local EHC has full access to the MOST network.

When entering the Attached Mode, the INIC performs the following actions:

• • Sends the latest NWM.Configuration.Status() to the EHC
• • Stops autonomous NetBlock handling; this means, it stops answering FBlockID list requests and routes all appropriate NetBlock request to the EHC
• • Enables message routing to the MCM PMP channel

In Attached Mode INIC.DeviceStatus.Status.AppInterfaceMode is Attached.

Configuration

As outlined in Section 22.1 , the configuration string allows the configuration of the peripheral ports used by the Configuration Interface and Application Interface.

The INIC automatically creates appropriate sockets and other resource objects. The chosen configuration will be available after chip startup.

If the Configuration Interface is set to None , the controlling application can only be a remote application, which excludes the use of an local EHC for configuration purposes. In this case the application interface can still be used.

Configuration

The behavior of the power management can be defined in the configuration string, but it is also possible to interfere in the INIC’s operational behavior during runtime if there is a condition detected that requires such an action. This means, if the INIC is in Attached Mode and an erroneous PowerState is detected, the EHC can send INIC.DevicePowerOff.SetGet(PowerOff = True) , DevicePowerOff (0x222), to set the state of the PWROFF pin to high. Since it could be also required to force the network interface to enter NotAvailable state due to an erroneous PowerState , the EHC can send INIC.MOSTNetworkForceNotAvailable.SetGet(Force = True) , MOSTNetworkForceNotAvailable (0x52B).

The behavior of the PWROFF pin after detecting an erroneous power condition and thus INIC’s automatic handling of the network interface in Protected Mode, can be defined in the configuration string, see properties Action On U_Low and Power Off Time. In addition, if PS0 and PS1 pins indicate the respective power state conditions, property Action On STP can trigger an RBD, see Table 3-1 .

If the INIC is in Attached Mode, it reports the respective power state in INIC.Device-Status(PowerState) to the EHC without initiating any action, DeviceStatus (0x220).

Power States

Figure 3-1 gives an overview of the INIC’s power states, which are UNormal , ULow , STP , and UCritical . Whenever a change occurs, the power management will be updated on any of the following triggers:

• • A change on the PS0 and PS1 pins
• • A change in the operation mode (on a transition to Protected Mode or on a transition to Attached Mode)
• • Timer Power Off Time has expired
• • INIC.DevicePowerOff() message was received
• • INIC.MOSTNetworkForceNotAvailable() message was received
• • Start of Ring Break Diagnosis failed
• • Start of network startup failed

Figure 3-1: Power States

Figure 3-2 through Figure 3-5 depict the power states in detail and show environmental conditions that can influence these states.

Figure 3-2: Power State is U Normal

Figure 3-3: Power State is U Low

Figure 3-4: Power State is STP

Figure 3-5: Power State is U Critical

NetInterface

The INIC contains a MOST Supervisor kernel, which implements the NetInterface state diagram and the flow between the states. NetInterface states are abstracted to the general states Available and NotAvailable , see Figure 4-1 . If the network is in NetInterface Normal Operation state, the network is considered available and data communication including packet, control, and streaming data, is possible. In all other NetInterface states it is considered not available; in these states data communication is not possible.

Figure 4-1: NetInterface State Diagram

Startup

By command or network activity

Before the MOST network can be available, it must be started by an application request, whereas the application is a device that is configured as TimingMaster. The MOST network can be started by the EHC using the INIC.MOSTNetworkStartup() function. After function INIC.MOSTNetworkStartup() has been called, the INIC is started as TimingMaster. The function must be called only by the TimingMaster device to avoid a multi-master failure situation.

If the INIC is woken up by network activity, it starts up as TimingSlave, which is the default device mode of the INIC. As long as the INIC detects activity at its Rx, it enables its signal on Tx.

By PS0 and PS1 pins

Another way for the TimingMaster to start the MOST network is checking the signals on the PS0 and PS1 pins. The feature can be enabled in the configuration string by selecting NetworkStartup in property Action On STP. In this case two additional properties become visible: Auto Forced Not Available Time and Packet Bandwidth.

A network startup is triggered when PS0 and PS1 indicate STP, see Table 3-1 . If a network startup should be executed on every INIC reset and no power state needs to be signaled by PS0 and PS1 , STP can be applied statically. If the network startup should be controlled by an external controller, STP can be applied on demand. If the network should not be started after reset, U Normal must be applied, see Table 3-1 .

Triggering a network startup on PS0 and PS1 is only possible after a reset of the INIC and if the configuration interface resides in Protected Mode. Once the configuration interface has changed to Attached Mode or a network startup on PS0 and PS1 was triggered, an additional network startup on PS0 and PS1 is no longer possible, until the INIC goes through reset again.

The INIC starts the network on a PS0 and PS1 trigger condition until the INIC gains NetInterface Normal Operation (Network Available) state or until the timer Auto Forced Not Available Time has expired. In case the INIC gains Normal Operation state and the configuration interface resides in Protected Mode, the network will be set to ForcedNA state, in case the Auto Forced Not Available Time timer has expired. To avoid an Auto Forced Not Available Time timer expiration, the EHC has to attach to the INIC within Auto Forced Not Available Time or the Auto Forced Not Available Time timer has to be set to 0xFFFF, which is not recommended.

Failed

If the MOST network startup was initiated by sending the INIC.MOSTNetworkStartup() command to the INIC, the INIC tries to start the network until NetInterface Normal Operation state is gained or until INIC.MOSTNetworkShutdown() is called by the EHC. The INIC cancels a pending startup, if it enters Protected Mode. If the network startup was canceled, a new startup can be tried immediately again.

Reasons for a failed network startup are as follows:

• • stable lock cannot be gained (e.g., the MOST ring is not closed) or
• • the network has a multi-master condition (only one TimingMaster is allowed).

In addition, a MOST network startup is not possible if the INIC is in ForcedNA state or in Diagnosis state. If in this situation the network was started up by using INIC.MOSTNetworkStartup() function, an immediate error is returned. A new startup is only possible after the error state has been freed.

Available

If the startup was successful, the MOST network and its port will enter the available state, meaning INIC.MOSTNetworkStatus.Availability (MOSTNetworkStatus (0x520)) and INIC.MOSTPortStatus.Availability (MOSTPortStatus (0x602)) change their state to Available , which in turn means that the network is now in NetInterface Normal Operation state, see Figure 4-1 .

AvailabilityTransitionCause indicates one of the initial startup reasons: Command or RxActivity . During the startup period, only the first initiated startup trigger is reported, even if there are several reasons that have been received from INIC.

Network-management related information is reported by the INIC.MOSTNetworkStatus() function; port-specific information, such as streaming data bandwidth, is reported by the INIC.MOSTPortStatus() function.

As soon as the MOST network is available, the last valid NodePosition and MaxPosition are returned within INIC.MOSTNetworkStatus() . The MaxPosition is synchronized with the Network Change Event (see Events), which is delayed at least 100 ms after the MaxPosition information has been changed. Also, the valid PacketBW in INIC.MOSTNetworkStatus() and the valid FreeStreamingBW in INIC.MOSTPortStatus() are reported.

If a network unlock occurs during the time that the network is available, AvailabilityInfo changes to Unstable , indicating that network communication is disturbed. It changes back to Stable as soon as stable lock is re-gained.

Shutdown

By command

Similar to the network startup scenario, also the network shutdown function call INIC.MOSTNetworkShutdown() , MOSTNetworkShutdown (0x525), can occur at the same time on several nodes. The device triggering the network shutdown can be either the TimingMaster or a TimingSlave. For all network nodes AvailabilityTransitionCause changes to Normal . However, if a TimingSlave shuts down the network, the TimingMaster ignores the Shutdown Flag and reports AvailabilityTransitionCause ErrorSuddenSignalOff .

If the network is already being shut down by another node and INIC.MOSTNetworkShutdown() function is called again, the running shutdown process will not be affected. If the network shutdown is initiated by the INIC.MOSTNetworkShutdown() function and the shutdown process has been finished, the status is returned. The result is delayed and sent until t Restart is expired; hence an immediate startup procedure can be initiated.

Network-management related information is reported by the INIC.MOSTNetworkStatus() function. Port-specific information, such as streaming data bandwidth, is reported by the INIC.MOSTPortStatus() function.

By error

An error shutdown can have different reasons:

• • ErrorSuddenSignalOff ,
• • ErrorCriticalUnlock , or
• • ErrorSystem .

AvailabilityTransitionCause indicates the reason for the network shutdown trigger.

NotAvailable

When the network starts the shutdown process, AvailabilityInfo changes to NotAvailable in INIC.MOSTNetworkStatus() (MOSTNetworkStatus (0x520)) and in INIC.MOSTPortStatus() (MOSTPortStatus (0x602)). NotAvailable indicates that the network is in NetInterface Off state.

NodePosition , MaxPosition , PacketBW , and FreeStreamingBW values are invalid if the network is in NotAvailable state.

Ring Break Diagnosis

To verify the integrity of the MOST network, the INIC embeds the Ring Break Diagnosis (RBD) as specified in the MOST Specification [1] .

System Diagnosis

The system diagnosis defines a process that is used to collect diagnostic relevant information of all devices present in the network. It can be also used to examine the physical connection status between two devices. The system diagnosis process is controlled by the system diagnosis module, which is part of the application layer. The INIC provides functionality, which is needed to interact with the system diagnosis module; in addition, the INIC completely encapsulates methods required by the system diagnosis processes, such as e.g. cable link verification.

Since the system diagnosis needs a diagnosis module running on the application layer of the TimingMaster, the TimingMaster node requires an EHC. TimingSlave nodes do not require an EHC. Hence, also remote-controlled devices can run the system diagnosis. The communication between the TimingMaster and the TimingSlaves is done by use of MOST Control Messages via the MOST network. Therefore, the system diagnosis process can be executed without any additional hardware, such as electrical trigger lines.

Cable Link Diagnosis

The cable link diagnosis is used to verify the physical connection between two INIC MOST Ports running in full duplex coax mode. The cable link diagnosis is started with ExtendedNetworkControl.CableLinkDiagnosis.StartResult() . Typically, this is done by the system diagnosis module. The cable link diagnosis can be performed only on a single MOST Port of the INIC at the same time. Parameter PortNumber identifies the MOST Port on which the cable link diagnosis should be performed.

The Result of the verification process can be either

• • a not connected or shorted cable,
• • a physically terminated connection,
• • a passive connection,
• • an active connection or
• • a failure detected during execution.

Note: A connected debug tool (e.g., INIC Explorer Interface Box) can affect the cable link diagnosis execution. A failure will be reported by a respective result.

All necessary tasks and algorithms of the cable link diagnosis are encapsulated in the INIC firmware. In order to perform a proper cable link diagnosis, the INIC firmware is no longer responsive to the outside, neither via the MOST Port interface nor via the configuration interface. Also the I 2 C Port is not serviced during the verification phase, which may lead to I 2 C clock stretching. For this reason the application has to take care that the application watchdog is adjusted to a safe timeout value and that the I 2 C Port on EHC side handles clock stretching in a proper way.

Physical Layer Test

The INIC provides integrated functions to support testing of the physical layer as defined in the MOST150 Limited Physical Layer Compliance Specification [12] .

For executing the test, a Physical Layer Stress Test Tool (PhLSTT) is needed. The tool must be connected via MOST to the OS81118 Device Under Test (DUT). During the test it feeds the OS81118 DUT with a defined stress test pattern (see the MOST150 oPhy Automotive Physical Layer Sub-Specification [13] ). Both the test tool and the DUT log coding errors and unlocks to evaluate the physical layer for errors.

The PhLSTT uses the FBlock ExtendedNetworkControl (see Section 21.4 ) in the INIC to start the Physical Layer Test and to retrieve the corresponding result.

At test start the INIC switches to RetimedBypassMaster or RetimedBypassSlave , depending on the Type selected. After the test is finished, the INIC switches back to its original mode.

The test duration spans the time of LeadIn and Duration and LeadOut . During the test, the MOST network is in NotAvailable state, AvailabilityInfo is Diagnosis .

Figure 4-2: Physical Layer Test Flow

Events

Events are generated on the INIC and reported to the EHC inside an event field of a status function. Events related to changes on the MOST network are reported by the INIC.MOSTNetworkStatus() function.

A status function does not only incorporate event fields, but also general network parameters. The handling of event fields and general network parameters is different: An event is only reported once. This means, if the status function incorporates an event, this event will be cleared or reset to its default value after it has been sent to the EHC. General network parameters, also sent within the status function, still keep their values and will remain untouched.

INIC events are always in relation to the notification; therefore, to get an event, the EHC should be notified for the appropriate functions. Once the EHC has set a notification for a status function containing an event field, previous events are not remembered and hence not reported. When a notification is set, the event field is cleared or set to its default value.

Addressing

The addresses recognized by the INIC define on which address types distributed over the MOST network the INIC does react. This can be considered as an address matching mechanism. Address types are:

• • NodeAddress
• • NodePositionAddress
• • GroupAddress
• • MAC Address

NetBlock

The FBlock NetBlock incorporates all functions that are relevant for network management. These functions have been implemented in the FBlock NetBlock according to the definitions prescribed by the MOST Cooperation in the MOST FunctionBlock NetBlock, Rev. 3.0.3 [2] specification.

The behavior for some FBlock NetBlock functions is different depending on whether the application interface is in Protected or Attached Mode; for more details refer to Section 21.1 .

All functions that are not supported by the FBlock NetBlock will be answered with error code 0x03, FktID not available, or forwarded to the EHC, if it is attached.

NetworkMaster

In the following situations the INIC acts as a NetworkMaster substitute to send NetworkMaster.ConfigurationStatus(NotOK) :

• • On any transition to NetInterface Off state and the NetworkMaster is remote.
• • After a NetBlock.Shutdown.Start(Execute) message was received and the NetworkMaster is remote. The NetworkMaster configuration status message is only sent to the internal NetworkMaster Shadow.
• • PMP channel synchronization is lost and the NetworkMaster is local; ICM/RCM PMP channels synchronized for information on how the INIC handles PMP synchronization loss.

NetworkMaster Shadow

The INIC contains a controller for the FBlock NetworkMaster functionality, which is called FBlock NetworkMaster Shadow. The FBlock NetworkMaster Shadow checks status messages that come from the FBlock NetworkMaster and stores its address information (logical address) and system configuration state. Additionally, when the application interface is in Attached Mode, all status messages will be forwarded to the EHC without changing the content of the received message.

FBlock ExtendedNetworkControl

The FBlock ExtendedNetworkControl provides functions which are used to administer the INIC. In opposite to FBlock INIC, FBlock ExtendedNetworkControl is accessible from MOST network side as well as from the configuration interface, regardless of whether the INIC resides in RemoteControl Mode or not.

FBlock ExtendedNetworkControl functions are used to control and support:

• • System Diagnosis
• • Device diagnosis
• • UNICENS
• • Physical Layer Test execution
• • Memory read and write functionality (see Section 21.4.11 and Section 21.4.12 )

Resource Objects

The INIC allows the customer to configure advanced routing of packet and streaming data in a simple and object-oriented fashion through a concept of on-chip resources, such as ports, sockets, and connections objects.

INIC supports a limited number of concurrent resources; therefore a free slot in the resource table is reserved on-demand by the call to the specific resource create function, e.g., INIC.MOSTSocketCreate() . A free slot is required to be able to create a new resource. If no free slot is available, an error code is reported. See Table 6-1 for information on how many tables and resources the INIC supports. After a resource has been created, a handle to the created resource is reported to the caller.

Object Type, Identifier, and Index

To identify any kind of resource, so-called resource handles are used. A resource handle is a 16-bit value that is a combination of the resource identifier and its unique index. The resource identifier is stored in the high byte and its index is stored in the low byte.

Table 6-1 shows the assignment between object type, resource identifier and index.

Examples:

The MediaLB Port is represented by port resource identifier 0x0A. The port index for this port is 0x00. Hence, the port resource handle 0x0A00.

The MediaLB socket is represented by socket resource identifier 0x0B. For the seventeenth MediaLB socket the resource handle will be 0x0B10.

An invalid resource handle has the value 0xFFFF.

Resource Destruction

The INIC provides a mechanism where multiple resources can be destroyed by a single request.

INIC.ResourceDestroy() , ResourceDestroy (0x800), takes a list of resource handles as a parameter. Each resource handle is processed one at a time and an empty result message is returned when all resources have been destroyed. The order in which resources should be destroyed is: connection first, followed by socket and port.

If an error occurs, the handle of the failed resource is included in the error message returned to the EHC. All handles prior to the failed handle in the list can be acknowledged as successfully destroyed, while all resource handles after the failed handle in the list are unprocessed.

Resource States

A resource can be in one of the following states:

• • Valid: This is the normal state.
• • TemporaryInvalid: This is a temporary state in which it cannot be guaranteed that the resource is fully functional. This state can be reached for example during a network unlock.
• • Invalid: This is a permanent state in which the resource is unrecoverable.
  This state can be reached due to an event (e.g., the network has entered NetInterface Off state) that makes the resource unrecoverable. For information on events that can make resources invalid, refer to Section 6.7 .

While an Invalid resource state requires the resource to be destroyed (see Section 6.3 ), the TemporaryInvalid resource state can change back to the Valid state after recovering from the temporary condition.

In either case, the EHC must be able to quickly detect invalid resources and mute the output of the routed data, see Section 6.5.1 .

Figure 6-1: State Diagram of a Monitored Connection

The INIC sets monitored connections to TemporaryInvalid if an event occurs that either requires verification of the resources or the event is temporary. After the condition has ended or if the resources became Invalid, the EHC is notified.

Monitoring

The INIC contains a resource monitor that monitors the states of resources and handles the muting. As long as it does not require attention from the EHC, it is in State OK . In the case there are events that require the EHC to take an action, the resource monitor enters the state ActionRequired , and notifies the EHC. It stays in this state until the EHC requests the resource monitor to reset itself. Resetting the resource monitor means that it will go back to the default state and release the MUTE/ RSOUT /GP8 pin, if possible (the pin was configured as MUTE pin, see MUTE/RSOUT Configuration). If there are still resources that are Invalid, it will immediately go back to State ActionRequired and notify the EHC; in this case there will be no intermediate notification of State OK .

The handling of resource monitoring is the same for all resources. However, the resource monitoring mechanism shown in Section 6.5.2.1 can be extended by implementing the muting concept, see Section 6.5.2.2 .

EHC Implementation

Without Muting

When the EHC receives a ResourceMonitor.Status(ActionRequired) , it must check for any invalid resources and destroy all of them, see Figure 6-2 . It does this by first sending ResourceInvalidList.Get() , which will return invalid handles in the order they must be destroyed. Any returned handles are then sent in ResourceDestroy.StartResult() , ResourceDestroy (0x800). When the handles have been successfully destroyed, the EHC reads the list again and continues the process until it has received the END identifier in the list of invalid resource handles. While destroying resources, the resource monitor stays in State ActionRequired until receiving a Reset. Therefore, the EHC only has to care about handling this processing. Finally, it sends ResourceMonitor.Set(Reset) , ResourceMonitor (0x802), to request the resource monitor to go back to the default state. The process is then done.

The resource handles reported to the EHC are sorted for immediate processing. The sort order is predefined by INIC. Handles of socket connections are reported first, then all sockets, and last all ports. This is to simplify processing on EHC side, in that no special consideration has to be taken to the destruction rules. A port resource cannot be destroyed if there are still sockets attached to it, and a socket resource cannot be destroyed if it is still being used in a connection.

Figure 6-2 depicts a recommendation for a proper EHC implementation without considering the muting concept. An EHC example implementation with muting is shown in Section 6.5.2.2 .

 

Figure 6-2: EHC Implementation Proposal for Resource Handling without Muting

 

With Muting

Figure 6-3 shows an EHC implementation example that supports muting.

If the EHC has sink connections muted by the MUTE pin, it should ensure that the MUTE pin is not asserted when receiving State OK and if so, unmute them. Since the sink connections must mute immediately if the signal is set, it is recommended to do the implementation in a way that avoids short unmuted pulses.

Figure 6-3: EHC Implementation Proposal for Resource Handling with Muting

 

Application Examples

Temporarily Invalid Connections

Figure 6-4 shows an example in which a network unlock temporarily invalidates connections that are registered for MUTE pin changes. When Stable Lock has been acquired, the connections will go back to Valid; this event is notified with ResourceMonitor.Status(ActionRequired) . The EHC reads the list of invalid resources. Since there are no invalid resources, the EHC will get an empty list with the END identifier. It then resets the resource monitor. After the EHC has received the response that the INIC had released the signal, it unmutes the devices; however, they must mute immediately if the MUTE pin has been driven high again .

Figure 6-4: Unlock with Temporarily Invalid Connection

Permanently Invalidated Connections

Figure 6-5 shows an example in which monitored connections become permanently invalid, due to the INIC entering the NetInterface Off state. The EHC reads the list of invalid resources. Since there are more results to be reported than can fit in one message, the END identifier is not included and the EHC detects that it must read again. As destroyed resources are removed, the EHC can read and destroy in sequence; it will get the next handles in the following read. The EHC may not be able to pass all the received handles to the destroy function and must then send multiple destroy requests. For simplicity it can request the list again after each completed destruction, the destroyed handles are then removed. In the figure it is assumed that all the handles could be sent in the final destroy.

Figure 6-5: Permanently Invalidated Connection

 

Events That Make a Resource Invalid

Routing Budget

Routing memories and channels are shared between multiple resource objects. To use these resources in an optimum manner, resource planning is important. If an application is to be defined, the resource budget must be planned, to prevent resource conflicts and waste of memory space.

Configuration

In contrast to other resources, a MOST Port is always created at startup. The port cannot be destroyed during runtime and it also remains persistent when the INIC enters Protected Mode.

Physical Layer

This configuration setting defines the physical layer to be used.

Sockets

A MOST Port socket encapsulates the configuration settings that are required to access data streams on specific MOST network channels. The DataType can be specified by function INIC.MOSTSocketCreate() . Packet and control sockets are automatically managed by the INIC, MOSTSocketCreate (0x611).

To establish MOST based data routing, the MOST socket must connect to a MOST Port using the MOSTSocketHandle .

INIC attempts to allocate the required network bandwidth when a MOST socket of direction Output is created. While creating an Input socket, INIC will attempt to connect to the provided MOST ConnectionLabel . If the allocation or connection attempt fails, an error message is reported back with failure information. INIC automatically handles cleanup of partially allocated or connected MOST network bandwidth in the event of an error.

The network bandwidth, specified by parameter Bandwidth when creating a socket, must be large enough to allow a safe data transmission. The selection of this value depends on the transmission class used, see Section 19.4 .

Additionally, each MOST socket requires a routing channel according to the data type for which it is created, see Table 6-3 .

For general socket information refer to Section 6.1.2 .

Configuration

The MediaLB Port can be created either by customization of the Configuration String or via the INIC.MediaLBPortCreate() function, MediaLBPortCreate (0x621).

If the MediaLB Port is created via the configuration string, the port cannot be destroyed during runtime and it also remains persistent when the INIC enters Protected Mode.

If it is desired to create the MediaLB Port during runtime, the INIC.MediaLBPortCreate() function must be used. This time, the port will be destroyed when the INIC enters Protected Mode.

Clock Config

This configuration setting provides various speed grades to define the clock speed on which the MediaLB Port should be run. The speed grades can be customized by the configuration string via property Port Speed or during runtime by changing parameter ClockConfig . Based on the chosen speed grade, either the MediaLB 3-Pin Port or the MediaLB 6-Pin Port will be created.

Sockets

A MediaLB socket encapsulates the configuration settings that are required to access data streams on specific MediaLB channels. The DataType can be specified by function INIC.MediaLBSocketCreate() , MediaLBSocketCreate (0x631).

To establish MediaLB-based data routing, the MediaLB socket must connect to the
MediaLB Port using the MediaLBPortHandle .

When a MediaLB socket is created, INIC attempts to allocate the required bandwidth and assigns the allocated channel to the specified application channel address. If the allocation attempt fails, an error message is reported back with failure information. INIC automatically handles cleanup of partially allocated MediaLB bandwidth in the event of an error.

For general socket information refer to Section 6.1.2 .

Packet Multiplexing

MediaLB sockets of type Packet provide a packet multiplexing feature, which allows two MediaLB sockets of opposite direction to share the same physical channel(s). Using this feature requires a socket Bandwidth of at least 12 bytes.

Figure 8-1 depicts the packet multiplexing feature. Two physical channels are reserved: one for Tx and one for Rx direction. The remaining physical channels are used as multiplexed channels (see also Table 8-1 ).

Figure 8-1: Packet Multiplexing

The INIC monitors the Command field for activity. If the command is idle (NoData) or when an RxStatus busy has been detected, the controller will switch the ChannelAddress (e.g., from transmit address to receive address). It takes 12 bytes after a ChannelAddress has been transmitted until the MediaLB controller can detect if a channel is idle. Hence, an address switch will only occur every 12 bytes for an idle channel. As soon as the Command field signals Tx (or Rx), the shared physical channels will lock to that direction.

Table 8-1 gives an overview over the allocated MediaLB Bandwidth and the number of physical channels available for multiplexing.

Table 8-1: Packet Multiplexing - Physical Channel Allocation

Bandwidth in Bytes	Physical Channels
	Reserved		Multiplexed
	Tx	Rx	Tx or Rx
12	1	1	1
16			2
20			3
...			...

 

The packet multiplexing feature can be enabled via Multiplexing in the configuration string. For the MediaLB address and bandwidth settings refer to properties: MediaLB Input Address, MediaLB Input Bandwidth, MediaLB Output Address, and MediaLB Output Bandwidth.

The feature can also be enabled during runtime. Function INIC.MediaLBSocketCreate() is required to create a Packet socket, see Section 21.2.5.2 . The MediaLBSocketHandle returned is then used with the INIC.MediaLBPacketMuxSocket-Create() function to enable the multiplexing mechanism, see Section 21.2.5.3 .

When calling INIC.MediaLBPacketMuxSocketCreate() , the INIC creates a new socket based on the characteristics of the provided socket. It has the

• • same data type,
• • same size,
• • opposite direction, and
• • MediaLB ChannelAddress of the provided socket address + 2 (e.g., 0x0006 and 0x0008)

Note: Due to the dependency established, the socket created by INIC.MediaLBPacketMuxSocketCreate() must be destroyed first if the packet multiplexing feature is no longer used.

 

To enable packet data routing, the handle of both sockets may be used with function INIC.PacketAttach() , see Section 21.2.13.1 .

Configuration

The SPI Port can be created either by customization of the Configuration String or via the INIC.SPIPortCreate() function, SPIPortCreate (0x641).

If the SPI Port is created via the configuration string, the port cannot be destroyed during runtime and it also remains persistent when the INIC enters Protected Mode.

If it is desired to create the SPI Port during runtime, the INIC.SPIPortCreate() function must be used. This time, the port will be destroyed when the INIC enters Protected Mode.

ClockMode

This configuration setting provides various SCLK clock modes for the phase and polarity signals used by the SPI bus slave.

Sockets

An SPI Port socket encapsulates the configuration settings that are required to access data on the SPI. The DataType can be specified by function INIC.SPISocketCreate() , SPISocketCreate (0x651).

To establish SPI-based data routing, the SPI socket must connect to an SPI Port using the SPIPortHandle . This, as well as further socket-related parameter settings, can be accomplished by using the INIC.SPISocketCreate() function.

For general socket information refer to Section 6.1.2 .

Requirements

The INIC contains a limited number of internal resources. In respect to this, data-type dependent USB Endpoint requirements as listed in this section need to be considered to achieve proper operation. If the requirements are not met, data loss can happen.

The requirements define the least required number of bulk transactions per USB Microframe used for one USB Endpoint. The number of transactions depends on the desired data bandwidth of the connection.

With one bulk transaction per USB Microframe, a maximum data bandwidth of
32 Mbit/s is reachable. Whenever a higher data bandwidth is required, the number of bulk transactions per Microframe needs to be increased.

A/V Packetized

For A/V packetized connections the number of required bulk transactions per Micro-frame of a desired data bandwidth depends on the isochronous packet size and the number of frames packed into one bulk transaction. More details can be found in Table 19-2 .

Synchronous

For synchronous connections the number of required bulk transactions per Microframe is fixed to 1.

Control and Packet

The packet connection has no dedicated requirement to the number of bulk transactions per Microframe. In general, the number of bulk transactions needs to be in a range that covers the maximum throughput required.

Configuration

The USB Port can be created either by customization of the Configuration String or via the INIC.USBPortCreate() function, USBPortCreate (0x661).

If the USB Port is created via the configuration string, the port cannot be destroyed during runtime and it also remains persistent when the INIC enters Protected Mode.
If it is desired to create the USB Port during runtime, the INIC.USBPortCreate() function must be used. This time, the port will be destroyed when the INIC enters Protected Mode.

PhysicalLayer

This configuration setting allows to define the USB Port’s physical layer either as standard USB 2.0 layer or as HSIC layer.

DeviceInterfaces

The USB interfaces that the device should support must be defined once the USB Port is created. This configuration is persistent as long as the port exists. The setting affects the content of the USB configuration descriptor returned by the INIC, see Section 10.5.3 . In full-speed mode, e. g. if connected to a USB 1.x Port, the returned device configuration will only contain an empty interface with no Endpoints, independent from the configuration. In this mode, the creation of USB sockets is not possible.

The following device interfaces are supported:

• • Control Interface
  This interface provides the Endpoints 0x0F (OUT) and 0x8F (IN). These Endpoints can be used for the communication of control messages. For more information see Device Management.
• • Packet Interface
  This interface provides the Endpoints 0x0E (OUT) and 0x8E (IN). These Endpoints can be used later on for USB socket creation, restricted to the packet data type.
• • Streaming Interface
  This interface provides a configurable amount of up to 10 OUT and up to 10 IN Endpoints. These Endpoints can be used later on for USB socket creation, restricted to the Sync and AVPacketized data types.
  The USB Port configuration allows to specify the number of Endpoints for each direction. Endpoint allocation starts with the Endpoint number 1 (Endpoint address 0x01 for the OUT, and Endpoint address 0x81 for the IN direction). Table 10-1 shows the maximum range of Endpoint addresses available for the streaming interface.

Table 10-1: Endpoint Directions and Addresses

Endpoint Direction	Endpoint Address
OUT	0x01...0x0A
IN	0x81...0x8A

Sockets

A USB socket encapsulates the configuration settings that are required to access data streams on specific USB pipes. The DataType can be specified by function INIC.USBSocketCreate() , USBSocketCreate (0x671).

To establish USB-based data routing, the USB socket must be connected to a USB Port using the USBPortHandle . This, as well as further socket-related parameter settings, can be accomplished by using the INIC.USBSocketCreate() function, USBSocketCreate (0x671). The Endpoint address used to create sockets must be made available by the port configuration, once the USB Port is created. Otherwise the request will fail.

The parameter FramesPerTransaction defines the number of data frames that are transferred within one USB bulk transaction. The value depends on the data type being used, see Chapter 19 for details.

For general socket information refer to Section 6.1.2 .

For USB-related information refer to the USB 2.0 Specification [5] .

Padding in Synchronous Bulk Transactions

Since the duration of the MOST network frame is six times shorter than the duration of one USB Microframe, the minimum number of FramesPerTransaction must be 7. ‘n’ is the maximum number of FramesPerTransaction. The value of ‘n’ depends on the MOST socket bandwidth. The data bytes per one transaction must not exceed 512 bytes. Therefore, the product of FramesPerTransaction multiplied by the specified MOST socket bandwidth must be less than or equal to 512 bytes, see also the example shown below.

If the data bytes within a bulk transaction are less than 512 bytes, padding is applied by the INIC. This means, INIC always sends a packet of 512 bytes to the EHC, whereas the remaining number of bytes will be filled with dummy bytes. If the EHC is sending the packets to the INIC, it can either send shorter packets (without dummy bytes) or the packets with dummy bytes. In the latter case, the INIC discards the dummy bytes.

Example:

The MOST socket bandwidth is 30 bytes. The value defined in parameter FramesPerTransaction is 0x000F. The calculated number of bytes results in a valid number, which is 450 bytes.

Figure 10-1: Synchronous Bulk Transaction with Padding

 

Padding in A/V Packetized Bulk Transactions

FramesPerTransaction defines the number of isochronous packets filled-in into one USB transaction. The size of an isochronous packet can either be 188, 196, or 206 bytes.

If FramesPerTransaction is 0x0002, padding is applied if the INIC is the transmitting device. This means, if INIC is sending a packet of 512 bytes to the EHC with two A/V packets filled in, the remaining bytes will be filled with dummy bytes. If the EHC is sending the packets to the INIC, it can either send shorter packets (without dummy bytes) or the packets with dummy bytes. In the latter case, the INIC discards the dummy bytes.

Figure 10-2: A/V Packetized Bulk Transaction with Padding

 

If FramesPerTransaction is 0xFFFF, no padding is applied.

Figure 10-3: A/V Packetized Bulk Transaction without Padding

 

The number of bulk transactions per USB Microframe depends on the performance of the USB host, which is the EHC and the initiator of USB transactions. Higher speeds require more than one transaction per Microframe, therefore it must be ensured that the performance of the EHC is suitable.

The maximum number of bulk transactions per Microframe is 13. Therefore, the maximum number of A/V Packetized Isochronous Streaming connections depends on the number of USB bulk transactions required.

 

Vendor-Specific Requests

All parameters of a USB vendor request are transported in little-endian format. This section describes all vendor-specific requests the INIC supports.

Descriptors

Configuration

Some of the parameters of the Streaming Port configuration define the base configuration. These are static parameters that are set once and not intended to be changed during runtime. Parameters of this type are: OperationMode , PortOption , ClockMode , and ClockDataDelay .

Other parameters of the Streaming Port configuration can be set when the port is created. These settings can be changed by destroying and recreating the Streaming Port resource, hence these are dynamic configuration options. Parameters of this type are: ClockSpeed and DataAlignment .

The base configuration can be set either through the Configuration String or by using the FBlock INIC API function INIC.StreamPortConfiguration() , StreamPortConfiguration (0x680). If the configuration string is used, the property Base Configuration Load enables the base configuration to be automatically loaded at startup. If the FBlock INIC API function is used, the base configuration has to be set on EHC attaching to INIC, since it is cleared on a detach event. A defined base configuration for both Streaming Port A and Streaming Port B is required in order to create the respective port resources.

Sockets

A Streaming Port socket encapsulates the configuration settings required to enable routing of streaming data between a MOST network channel and a serial interface pin. The DataType can be specified by function INIC.StreamSocketCreate() .

Parameter PortOption of the Streaming Port’s base configuration configures the availability and direction of the data pins. The direction of a socket must comply with the direction of the pin to which it is associated.

The size of the socket specifies the number of bytes per Streaming Port frame to be routed. The clock speed configured for the Streaming Port and the chosen routing format limit the compatible sizes.

See Section 11.3.1 for an example where a routing format, compliant to the I 2 S standard, is configured. Refer to Section 21.2.8.4 for a reference of the API command used in INIC.StreamSocketCreate() .

For general socket information refer to Section 6.1.2 .

Typical Application Examples

Configuration

The output frequency on the RMCK pin is decided by parameter Divisor , which divides a 3072Fs clock that is phase locked to the network, i.e., the output frequency is synchronous to the network clock.
The RMCK Port can be opened by default by enabling it in the configuration string (see Port Create) and configured by setting the desired divisor (see Divisor).

Configuration

The I 2 C Port can be created by customization of the Configuration String or via the INIC.I2CPortCreate() function, I2CPortCreate (0x6C1).

If the I 2 C Port availability is configured via the configuration string, the port cannot be destroyed during runtime and it also remains persistent when the INIC enters Protected Mode.

If it is desired to create the I 2 C Port during runtime, the INIC.I2CPortCreate() function must be used. In this case, the port will be destroyed when the INIC enters Protected Mode.

Slave mode

When the I 2 C Port is created at startup (Port Create in the configuration string must be set to CreatedAtStartup ), the INIC operates as an I 2 C-bus slave. This mode is static and therefore cannot be changed during runtime.

Master mode

To use the I 2 C Port as I 2 C-bus master, Port Create in the configuration string must be set to NotCreatedAtStartup . In addition, the interfaces for PMP communication (Configuration Interface and Application Interface) must be set to MediaLB or USB . If the INIC is not connected to an EHC, None must be selected.

Calling the INIC.I2CPortCreate() function during runtime and setting the OperationMode to Master , enables the I 2 C-bus master mode. Using this mode makes the INT pin available as GPIO.

Slave Mode

Once the I 2 C Port is created in slave configuration, the port will be available to the EHC as the communication interface. Control message exchange is processed bi-directional, over the PMP channels, see Section 2.1.1 . The EHC acts as I 2 C bus master.

The I 2 C bus master may drive the bus with a clock rate of up to 400 kHz. Clock stretching provides an appropriate handshake mechanism to let the INIC adapt the data transfer rate dynamically. The actual processing time varies, based on the overall load of tasks.

The I 2 C slave address of the INIC is specified in the 7-bit slave addressing scheme. The value defaults to 0x20, however the Port Address can be changed via the configuration string.

Besides the standard I 2 C signals ( SDA and SCL ), the INIC provides an interrupt line, INT (see the OS81118 Hardware Data Sheet [4] ), which is used for byte-level flow control such as required for half-duplex transmission. The INT line is used to signal the communication status to the bus master, which eliminates the need for a polling mechanism.

The INT pin is an open-drain, active-low output that must be connected to the bus master’s interrupt logic, see Figure 13-1 .

Figure 13-1: I²C Port Pin Connection

Limitations in slave mode:

Driving the I 2 C bus in slave mode does not support a repeated START condition. Therefore, each message must be terminated by a STOP condition before the next message can be started.

Sending a Message

Figure 13-2: I²C Write Transaction

Sending a message to the I 2 C Port can be initiated by performing an I 2 C write transaction. Thus, the device address and the write identifier have to be exposed on the I 2 C bus. After the reception of the acknowledge bit, the message can be written to the port. A write transaction allows only a single message to be transmitted.

Sending messages to the INIC does not involve the INT line.

 

Receiving a Message

Figure 13-3: I²C Read Transaction

A read transaction allows only one message to be fetched. After an entire message is read, the INIC will drop the message from the queue. In addition, if more bytes are read than the message length specified by the PML or if no more messages are queued, the INIC will return zero values in the read result.

 

Every time a message is available for reception, the INIC will drive the INT pin low to inform the bus master. The bus master has to react on this event and initiates a read transaction to fetch the pending message from the INIC queue.

Figure 13-4: Single Read Transaction

When the INIC is addressed by a read operation, it will release the INT line. The INT line may also be released if the INIC cancels the transmission of a message and empties its queue.

 

During the STOP condition of a read transaction, the INT line will be driven low again if not all message bytes were read, see Figure 13-5 . This signals the master to repeat the read transaction for this message.

Figure 13-5: Two-Staged Read Transaction

After a message was completely fetched, the INIC sets the INT line low to signal that it is ready to transmit the next message from its queue. If there are no further messages in the queue, the INT line remains high.

If the bus master (or the controlling application) does not completely fetch the message, the INIC will run into a timeout after t TxDriver (see Port Message Protocol Specification [3] ). Then the INIC will cancel the transaction and remove the failed message from its queue. If there are no further messages in the queue, the INT line will be switched high again.

Note: If ICM, RCM or MCM PMP channels are connected to the I 2 C Port, then the INT pin will be pulled low right after power on or reset. This happens, since the INIC attempts to send a startup message for each control channel during startup. The INT pin will go back high after all messages were fetched, or if the EHC is not present at that time, all messages were canceled.

 

 

Messages can be polled by the EHC without using the interrupt mechanism. Reading the PML value inside the first two bytes of the PMP header (see Figure 2-1 ) indicates if a message is pending. If this value is zero, no message can be read from the INIC. However, such a polling mechanism will keep the bus busy, hence preventing other transactions from being processed.

The following methods can be used to fetch a pending message from the INIC. The methods are listed in recommended (most efficient to least efficient) order:

• • The most common method is to read the message directly in a single read transaction, as shown in Figure 13-4 . Therefore the I 2 C bus master must be capable to pause the communication after reading the PML (first 2 bytes of the message). During this time, the bus master can allocate the necessary heap and proceed with reading the remaining bytes of the message. Such a feature may not be supported by any I 2 C driver. In such a case, one of the alternative methods (listed below) should be used.
• • An alternative possibility is to read the control message in a two-staged transaction, as shown in Figure 13-5 . The first read transaction is necessary to acquire the length information (PML field). After allocating the required heap, the bus master must initiate a second read transaction to receive the entire message.
• • Another alternative is to read the maximum length of the port message in one read cycle, every time. This happens regardless of the actual PML value and may result in a very high bus traffic when transmitting the attached remaining zero's. Such an inefficient way should only be chosen if the other ways can't be used.

Master Mode

Once the I 2 C Port is created in master configuration, the read and write sequences are initiated with the INIC.I2CPortRead() and INIC.I2CPortWrite() functions. The functions specify the handle of the port, the transfer mode ( Mode ), the slave address, and the length of data.

The I 2 C-bus master driver supports the following message types:

• • Single message - master writes n data bytes to a slave device ( DefaultMode )
• • Single message - master reads n data bytes from a slave device ( DefaultMode )
• • Single message - master writes n data bytes, divided in m blocks of chunks, to a slave device ( BurstMode )
• • Combined message - master issues multiple reads/writes to one slave device ( RepeatedStartMode )

Addressing Mode

When operating as an I 2 C-bus master, the INIC supports the standard 7-bit addressing as well as the enhanced 10-bit addressing mode.

7-bit Addressing

This is the most commonly used addressing mode. The 7-bit address is transferred with the most significant bit first and followed by a direction bit.

Figure 13-6: 7-bit Address Write

 

Figure 13-7: 7-bit Address Read

 

10-bit Addressing

The 10-bit addressing expands the number of possible device addresses while maintaining backwards-compatibility with devices that only support 7-bit addressing.

Per the I 2 C-bus specification [9] , a '11110' following a START condition indicates the use of the 10-bit addressing mode.

For a 10-bit address write operation on a slave device, the first byte contains the two most significant bits of the 10-bit device address as well as the R/W flag. The remaining eight bits of the address are sent in the second byte. Therefore, if the message payload contains n data bytes, the length parameter must be set to n+1.

 

Figure 13-8: 10-bit Address Write

 

For a 10-bit address read operation on a slave device, a repeated start sequence has to be used. The first message ( INIC.I2CPortWrite() ) issues the 10-bit address and the second message ( INIC.I2CPortRead() ) initiates the read sequence.

Figure 13-9: 10-bit Address Read

 

Repeated Start (Combined Format)

Usually each I 2 C message consists of a START and STOP identifier. When the INIC is configured in RepeatedStartMode , it sends the START identifier, but suppresses the STOP condition. If the STOP condition is not issued, the bus remains busy and the controlling device can complete subsequent transactions.

A typical example is the communication flow to an EEPROM device. If data is to be written to a certain address inside the EEPROM, an I 2 C transfer is initiated using INIC.I2CPortWrite.StartResult.Mode.RepeatedStartMode . The INIC sets a START identifier and issues the slave address of the EEPROM device. The address will be acknowledged and the following byte will set the desired memory address inside the EEPROM. The next message, for example INIC.I2CPortWrite.Start-Result.Mode.DefaultMode will write the payload into the memory address and generate a STOP condition on the bus.

Figure 13-10: Repeated Start

 

Application Examples

The following examples depict some standard communication sequences, which can be used for most use cases.

Figure 13-11 shows an example of a single read/write transaction.

Figure 13-11: I²C Read/Write

 

Figure 13-12 shows an example of a burst transaction writing multiple data chunks.

 

Figure 13-12: I²C Write Burst Mode

Figure 13-13 shows an example of a repeated start transaction. At the beginning a write is initiated with a subsequent read.

Figure 13-13: I²C Repeated Start

Configuration

The GPIO Port can be created via the INIC.GPIOPortCreate() function, see Section 21.2.11.1 . Enabling the GPIO Port leaves the pin configuration untouched. To change a pin into a GPIO pin, it has to be configured via the INIC.GPIOPortPinMode() function, see Section 21.2.11.2 . Depending on the pin configuration, the controlling application (EHC or remote application) can receive a notification via INIC.GPIOPortTriggerEvent() , see Section 21.2.11.4 , when trigger events on the pins are detected.

To allow pin re-configuration during runtime, the pin configuration is separated from the port creation. The following table shows the configurable pins and their limitations.

Trigger

To get trigger events, the INIC.GPIOPortTriggerEvent() function must be entered in the notification matrix. For an EHC, notification is not supported when entering Device Attach Mode, instead the command INIC.Notification.Set() must be sent to activate notification on trigger events. The command must also be sent for a remote application.

The trigger condition is configured via the INIC.GPIOPortPinMode() function and describes the Mode on which the controlling application can react. The status message is sent when:

• • the GPIO Port is created,
• • the controlling application registers for notification, and
• • a trigger event has been detected.

The following trigger classes are available:

Edge trigger

Includes rising and falling edge triggers for input, debounced input and output (open-drain) pins. Each time a configured edge event is detected, a notification via
INIC.GPIOPortTriggerEvent() is sent by the INIC.

Level trigger

Includes high-level and low-level triggers for input, debounced input, and output (open-drain) pins. Level triggers are implemented as one-shot triggers. Triggers of this type are signaled once only. To receive further trigger events, the trigger must be re-enabled by re-configuring parameter Mode of INIC.GPIOPortPinMode() .

For more information on triggers refer to the OS81118 Hardware Data Sheet [4] .

Application Examples

Edge Sensitive Input

Figure 14-1 shows an example sequence chart that handles the GP0 pin as an input trigger with an edge sensitive trigger configuration. The GP0 pin is configured to react on the InputTriggerRisingEdge .

Figure 14-1: Edge Sensitive Input

Level Sensitive Input

Figure 14-2 shows an example sequence chart of how an controlling application can use the GP0 pin with the trigger configuration InputTriggerHighLevel .

Figure 14-2: Level Sensitive Input

Due to the fact that the trigger input is a level signal, the detection of any further input events of this signal will be disabled directly after the trigger message INIC.GPIOPortTriggerEvent.Status has been sent. The detection stays disabled until the controlling application calls INIC.GPIOPortPinMode() to tell the INIC that it can react on the next input level.

Sticky Input

Figure 14-3 shows an example sequence chart of how a controlling application can use the GP0 pin with the pin configuration InputStickyHighLevel to poll for small high level pulses.

Figure 14-3: Sticky Input

 

The sticky bit can be only reset when the controlling application calls INIC.GPIOPortPinMode() to tell the INIC that it can detect the next sticky level.

Combiner with a USB OUT socket

Since the duration of the MOST network frame is six times shorter than the duration of one USB Microframe, the minimum number of FramesPerTransaction must be 7. ‘n’ is the maximum number of FramesPerTransaction. The value of ‘n’ depends on the parameter BytesPerFrame. The data bytes per one bulk transaction must not exceed 512 bytes. Therefore, the product of FramesPerTransaction multiplied by the specified BytesPerFrame must be less than or equal to 512 bytes, see also the example shown below.

If the data bytes within a bulk transaction are less than 512 bytes, padding is applied by the INIC. This means, INIC always sends a packet of 512 bytes to the EHC, whereas the remaining number of bytes will be filled with dummy bytes. If the EHC is sending the packets to the INIC, it can either send shorter packets (without dummy bytes) or the packets with dummy bytes. In the latter case, the INIC discards the dummy bytes.

Example:

There are three MOST sockets, MOST socket A to MOST socket C. Each of them has a size of 15 bytes. Therefore, parameter BytesPerFrame must be set to 45 bytes. The value defined in parameter FramesPerTransaction is 0x000B. The calculated number of bytes results in 495 bytes.

Figure 15-1: Bulk Transaction with a Combiner

Control Low-Level Retries

Control Low-Level Retries are done block wise. A block consists of the initial transmission attempt and 10 retries (fixed number). The time between the retries is internally pre-defined and varies between 5 and 8 units (1 unit = 16 MOST network frames). For the first block the time is set to 5 units. The number is increased by 1 for every control message transmission, regardless of whether retries are performed or not. If the cycle has passed the 8 th unit, it starts over at 5.

Figure 17-2 exemplarily describes how Control Low-Level Retries are performed. At first, the example shows an initial control message transmission that has set the ControlLLRBlockCount to 0. This means, no retries are done. However, the used time unit is 5. Then, the ControlLLRBlockCount was set to 2. Two retries are done and it can be seen that the number of time units is continuously counted: the first retry starts at 6, the second retry is 7. Finally, the ControlLLRBlockCount was set to 4. The example depicts the start over of the time unit count after the 8 th unit was passed.

Figure 17-2: Control Low-Level Retries

Message Formats

Depending on whether the INIC exchanges data with an MDP or MEP sink/source device, the packet message format and the packet message length of the Port Message (PM) is different, see Figure 18-1 , Figure 18-2 and the data fields description below the figures.

Figure 18-1: MOST Data Packet Message Format

Figure 18-2: MOST Ethernet Packet Message Format

The Port Message consists of a PML field that is followed by several data fields.

• • PML - Port Message Length: 16-bit field that indicates the total number of bytes that follow the PML field.
• • TgtDevType - Target Device Type: 8-bit sub-field that indicates the addressing mode used in the received message. The addressing mode can be:
  0x00: Logical addressing
  0x01: Physical addressing (Node Position)
  0x02: Broadcast addressing
  0x03: Groupcast addressing
• • SrcDevID - Source Device ID: 16-bit sub-field that indicates the Logical Address of the device that sent the message.
  SourceID 0x0001 (LocalID) indicates that the message was sent from an internal FBlock.
• • Retry/Prio - Retry/Priority: 8-bit sub-field that contains additional Low-Level Retry information, see table below. Values for priority and Low-Level Retries are each 4-bits comprising. Number of Low-Level Retries can be set in a range from 0x00 up to 0x0F, whereas 0x00 indicates the lowest value and 0x0F the highest. Priority is not supported, the value must be set to 0x00.

Prio Bits	Description	Size (Bits)
7...4	Number of Low-Level Retries	4
3...0	Prio	4

• • TgtDevID - Target Device ID: 16-bit sub-field that indicates the device address to which the message is sent (DeviceID). The following addresses are reserved: 0x0000, 0x0001, 0xFFFF.
• • Length: 16-bit field that indicates the number of data bytes in the packet message (length of the Data[1:n] field)
• • Data[0:(n-1)]: contains the payload of the MDP message. The maximum message length is 1524 bytes.
• • DestAddr - Destination Address: 48-bit field that refers to an address of an Ethernet device that is being targeted.
• • SrcAddr - Source Address: 48-bit field that refers to the source address of an Ethernet device that is sourcing packet data.
• • Data[0:(k-1)]: contains the payload of the MEP message including VLAN (32 bits, optional), Type (16 bits) and FCS (32 bits). When the message is sent, the maximum message length is 1510 bytes.
• • QoSRxStatus - Quality of Service Rx Status: 8-bit sub-field that is only appended to the MEP message when QoS packets are transferred. The byte supports a verification mechanism, which helps to identify if the complete MEP reception was successful or erroneous. Bits [2:0] of the byte give information on the reception status that is as follows:
  110: Packet reception was successful and CRC was correct
  001: Packet reception was successful but CRC was incorrect
  010, 100: Packet reception failed due to another reason
  111: Network receive buffer overflow

Packet

The MOST network socket and the appropriate packet connection is automatically managed by INIC. Peripheral sockets must be created. This can be done in two different ways:

• • If the socket should be available at INIC startup, the Packet Connection must be set in the configuration string.
  In this case, the INIC automatically creates the required peripheral sockets at startup and attaches them to the packet connection.
  A packet connection of this type cannot be destroyed during runtime and it also remains persistent when the EHC enters Protected Mode.
• • If the socket is not required to be available at startup, the packet connection can be created during runtime by using the INIC.PacketAttachSockets() function, PacketAttachSockets (0x843). The function attaches the given peripheral sockets of the INIC to the packet connection. The port-specific sockets that were built during runtime are automatically detached from the packet connection and destroyed when INIC enters Protected Mode.
  The peripheral sockets can be detached by using the INIC.PacketDetachSockets() function.

To allow the exchange of packet data, enough PacketBW must be made available on the MOST network (minimum is 4 bytes per frame).

The data flow of a packet connection is shown in Figure 18-3 .

Figure 18-3: Packet Connection

Driver Control Interface Access

When Driver Control Interface Access is enabled in the configuration string , the EHC can access an internal register set by using the packet connection with a prescribed message structure.

Note: Driver Control Interface access is only possible via packet connection over a MediaLB Port or an SPI Port. For the USB Port, the Driver Control Interface access is done as described in Section 10.4.1 .

 

Register status message

Register values are always sent to the EHC device driver via the register status message by using an MDP read message (see Figure 18-1 ) that uses TelID 0x00. This TelID does not allow message segmentation.

A register status message is triggered whenever changes occur regarding

• • Parameter NodeAddress
• • Parameters PacketEUI48_47to32 , PacketEUI48_31to16 , and
  PacketEUI48_15to0 , see Section 21.2.3.2
• • Function INIC.MOSTNetworkStatus() , which can be either:
• - 0x00 : NotAvailable
• - 0x01 : Available

 

or it is triggered by the read register command as shown in Figure 18-4 .

 

The fields of the MDP read message carry the information as shown in Figure 18-1 and are described in detail below:

PML:	0x0018
TgtDevType:	0x00
SrcDevID:	0x0001
Length:	0x0010
Data [0...15]	Data[0]:	FBlockID is NetBlock, 0x01
	Data[1]:	InstID is the current position in the network (0x00, if undefined, e.g., network is in NotAvailable state or if TimingMaster)
	Data[2]:	FktID_H is 0x00
	Data[3]:	FktID_L_OPType is 0x3C
	Data[4]:	TelID_TelLen_H is 0x00
	Data[5]:	TelLen_L is 0x0A
	Data[6]:	d0 is the high byte of the NodeAddress
	Data[7]:	d1 is the low byte of the NodeAddress
	Data[8]:	d2 is the status of the NetInterface
	Data[9]:	d3 is Packet EUI-48™ 47:40
	Data[10]:	d4 is Packet EUI-48 39:32
	Data[11]:	d5 is Packet EUI-48 31:24
	Data[12]:	d6 is Packet EUI-48 23:16
	Data[13]:	d7 is Packet EUI-48 15:8
	Data[14]:	d8 is Packet EUI-48 7:0
	Data[15]:	d9 is 0x01, reports the current system configuration state. It will be ensured that no state change from OK to NotOK gets lost.

Read registers

A read register command is used to initiate a register status message being sent to the EHC device driver. The command has the following message format:

Figure 18-4: Read Register Command

 

Write register

A write register command is used by the EHC device driver to update register settings. For the available register set refer to Chapter 20 .

Figure 18-5: DCI Trigger Message Format

 

 

Quality of Service

A Quality of Service (QoS) packet connection uses the QoS IP Streaming isochronous subclass on the MOST network to transport MEPs over dedicated network Bandwidth . For the data transmission, the QoS IP Streaming sub-class utilizes the isochronous channel that is set up as a uni-directional point-to-point connection. The isochronous channel on the MOST network does not provide flow control, instead, the QoS Rx Status byte helps to identify if the transmission was successfully received.

QoS packet connections are used for IP-based applications that require a pre-specified bandwidth/throughput. In contrast to standard packet connections, the Bandwidth of a QoS packet connection is reserved exclusively for a single source. By reserving the bandwidth, 100% QoS is provided.

A connection between two sockets is created by using the API function
INIC.QoSPacketCreate() . This command tells the INIC to set up a routing path through the chip between a MOST socket and a MediaLB socket.

Figure 18-6 shows the data flow for QoS packet connections between a MOST network socket and a MediaLB socket.

Figure 18-6: QoS Connection

MediaLB to MOST

As shown in Figure 18-2 , the format of an MEP message that is sent from the EHC to the INIC incorporates 8 bytes of overhead compared to a standard Ethernet frame. Hence, the data rate required on the peripheral interface is higher than the Ethernet data rate (DataRate E ) . To take this overhead into account, the Ethernet data rate is considered with the Factor given in the formula below.

DataRate E = Maximum burst throughput rate on Ethernet [Mbit/s]

Factor = 2.9297 [(byte) x (s/Mbit)]

 

 

MediaLB socket

Parameter Bandwidth corresponds to Bandwidth Source.

The real size of the physical MediaLB channel allocated is quadlet aligned, as described in Section 8.2.1 .

MOST network socket

Parameter Bandwidth corresponds to Bandwidth Source.

 

MOST to MediaLB

The information given in this section are based for applications that transmit QoS packets from a MOST network socket to a MediaLB socket.

Bandwidth Source = Number of data bytes allocated on the MOST network

 

MOST network socket

Parameter Bandwidth corresponds to Bandwidth Source.

MediaLB socket

By definition, the INIC appends a QoSRxStatus byte to every Ethernet packet on MediaLB, to verify if the reception of the Ethernet packet was successful. Based on this overhead byte, the MediaLB socket Bandwidth is calculated as follows:

Factor = 1.0139

 

Parameter Bandwidth corresponds to Bandwidth MediaLB.

 

Synchronization

Synchronization is required to clean up internal routing resources and to synchronize external driver applications. There are two conditions on which the INIC needs to perform a synchronization process of a packet connection:

• • MOST network shutdown
• • Fatal packet communication errors caused by network disturbances, which can't be automatically recovered by hardware

Depending on the communication characteristics of the peripheral interface involved in the packet connection, there are special synchronization mechanisms available, which are described below.