Microchip Technology Inc. provides a family of Intelligent Network Interface Controllers (INICs) that combine the physical layer, MAC (Media Access Control), link layer and network layer on a single chip. These characteristics make an INIC to a highly cost-effective all-in-one multimedia network solution. A high level of integration and encapsulation of the network functions grant robustness, ease of use and minimum time to market. In addition, the INIC already implements most of the elements of MOST ® core compliance on-chip, which is of interest when the INIC is being used in a MOST network environment.
The INIC family consists of various ICs that support different network speed grades and physical layers. Electrical transmission, for example over unshielded twisted pair (ePHY) or over the coax electrical physical layer (cPHY), is supported as well as transmission over the optical physical layer (oPHY). In addition, ample features and a variety of peripheral ports make the INIC to a highly flexible IC that can be implemented in a wide range of applications. However, not each application design needs the entire feature set or all of the peripheral ports. This is why Microchip extended the INIC family by new INICs that only provide a sub-set of the available characteristics. An overview of the different INIC types and the features they support is given in Section 2.2 .
The table below gives an overview about each FBlock and its corresponding syntax version.
Characteristic: |
||||
---|---|---|---|---|
Variable: |
||||
AVPacketized, QoSPacket, DiscFramePhase:
|
||||
Note 1: Available only after the Reduced Transmission Buffer functionality has been enabled in the configuration string. |
The device management handles device-related tasks such as:
The configuration interface and the application interface are two separate interfaces. This approach allows to operate the application interface without running the configuration interface and vice versa.
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 3-1 ), the data message content types and format, and the status message failure codes (see Table 3-3 ).
There are different kinds of PMP channels available:
To address a specific PMP channel, the channel number must be specified in the FPH field of the PMP header when a message is transmitted. Received PMP messages can be matched to a specific PMP channel through the same FPH field. Addressing all PMP channels at once allows to transmit a message that will be received by all PMP channels. Typically, this feature will be used to transmit an UNSYNC command message to all channels. For all other communication, the destination channel should be unique. Table 3-1 contains a list of channel assignments.
All PMP channels use the same Data Message format to transport a control message, as described in Section 3.1.2 .
Figure 3-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.
![]() |
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 3-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] .
![]() |
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. |
||
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. |
||
Function Block ID. Determines the function block that is addressed. |
||
Instance ID. Determines the instance of the FBlock to unambiguously address FBlocks of the same type. |
||
Function ID. Determines the property or method that is addressed. |
||
Telegram ID. Identifies the telegram type. Zero for a single transfer, non-zero (1...4) when transferring segmented messages. |
||
Operation Type. Determines the operation on the property or method. Also indicates the direction in which messages are exchanged. |
||
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. |
||
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. |
||
Telegram Length. Number of data bytes that are valid in the telegram. The maximum number is 45 bytes. |
||
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). |
If the INIC fails to deliver a control message, the affected PMP channel will turn into an error state and block further communication. If a PMP channel is blocked, the EHC is responsible to take action and perform error handling to unblock the channel and continue its operation. Other channels still remain usable, even if they share the same physical port. For more information refer to the Port Message Protocol V2.0.1 Specification [3] .
A channel failure will be reported through the PMP in form of a FIFO Control Message status, see Port Message Protocol V2.0.1 Specification [3] . The reason for the failure will be encoded into the status value with the TX_FAILURE type, see Table 3-3 . The error type categorizes the error values and indicates if a retry of the transmission is reasonable. If it is not reasonable, a retry will probably not solve the issue and instead result in the same error state again.
The value 0x01 is reported only for control messages targeted to INIC internal FBlocks and Shadows. All other values are reported if any transmission error on the MOST network has occurred.
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:
The EHC-controlled configuration interface is shown in Figure 3-3 .
![]() |
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 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:
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 3-4 .
![]() |
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 3-5 . Operation modes are:
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:
In Protected Mode INIC.DeviceStatus.Status.ConfigInterfaceMode is Protected .
The cleanup process can be triggered by several indicators:
After the cleanup process state has been entered, the INIC performs the following actions:
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 3.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] .
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() , see page 137 , the INIC performs the following steps:
In Attached Mode INIC.DeviceStatus.Status.ConfigInterfaceMode is Attached .
The following sequence chart shows the required steps to reach Attached 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 3-7 .
![]() |
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 3-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.
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 3-8 .
![]() |
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 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:
The application interface can reside in the following operation modes, see Figure 3-9 :
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:
In Protected Mode INIC.DeviceStatus.Status.AppInterfaceMode is Protected .
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 3-5 . Loss of synchronization can be based on different criteria, such as:
After the cleanup process state has been entered, the INIC performs the following actions:
In Attached Mode, the local EHC has full access to the MOST network.
When entering the Attached Mode, the INIC performs the following actions:
In Attached Mode INIC.DeviceStatus.Status.AppInterfaceMode is Attached.
As outlined in Section 23.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.
The INIC is able to handle several power states, see Section 22.2.2.1 . For this purpose, it provides a power management interface, which consists of two input pins ( PS0 and PS1 pins) and one output pin ( PWROFF pin). The power management interface can be used to signal the current power state of a device and to trigger a Ring Break Diagnosis or a network startup by using an external glue logic or hardware power management (Microchip’s MPM85000 [11] ). The power management is based on the configuration interface.
Possible states that can be signaled by the power management interface are described in the table below:
U
Normal,
|
||||
Switch-To-Power (STP), |
||||
Protected Mode: |
||||
Protected Mode: |
||||
U
Critical,
|
||||
U
Low,
|
||||
Device enters NotAvailable state. |
||||
Device sets PWROFF pin high and enters NotAvailable state. |
The INIC provides a timer, Power Off Time, to set the PWROFF pin to high when the MOST network is in NetInterface Off state (see Figure 5-1 ) and the INIC has entered Protected Mode. The timer starts counting when both conditions are met and stops when one of the conditions has left its state, which means, either the MOST network leaves NetInterface Off state or INIC leaves Protected Mode. Then, the timer is cleared and the PWROFF pin will either stay low or be driven low if it was high.
Take into account, if Power Off Time is used to control the power supply of the device via the PWROFF pin, the timer value must be chosen higher, compared to the time a device would require to stay in NetInterface Off state and Protected Mode. This timing requirement must be fulfilled for example when the EHC is flashed, otherwise a power off will interrupt the flash process.
The PWROFF pin is set high due to the following conditions:
As long as one of the above mentioned conditions is true, the PWROFF pin will stay high.
If the PWROFF pin was set to high because of PS0 and PS1 pins signaled ULow in Protected Mode, the PWROFF pin will stay high even when INIC switches to Attached Mode. In order to drive the PWROFF pin low, INIC.DevicePowerOff.SetGet(PowerOff = FALSE) must be sent to INIC.
If the PWROFF pin was set to high due to sending INIC.DevicePowerOff.SetGet(PowerOff = True) and INIC switches to Protected Mode, the PWROFF pin may be driven low if no other condition occurs that forces the PWROFF pin to be set high.
The network interface is set to NotAvailable and remains in this state based on the following conditions:
As long as one of the above mentioned conditions is true, the network interface remains in NotAvailable state, regardless of the MOST network activity state on Rx. If NotAvailable state was set since the PS0 and PS1 pins signaled ULow in Protected Mode, the INIC will stay in NotAvailable state, even when INIC switches to Attached Mode. In order to clear NotAvailable , INIC.MOSTNetworkForceNotAvailable.SetGet(Force = FALSE) must be sent to INIC.
If ForcedNA was set due to sending INIC.MOSTNetworkForceNotAvailable.SetGet(Force = True) and INIC switches to Protected Mode, ForcedNA may be cleared if no other condition occurs that requires ForcedNA to be set.
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) , see page 137 , 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) , see page 154 .
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 4-1 .
If the INIC is in Attached Mode, it reports the respective power state in INIC.DeviceStatus(PowerState) to the EHC without initiating any action, see page 133 .
Figure 4-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:
![]() |
Figure 4-2 through Figure 4-5 depict the power states in detail and show environmental conditions that can influence these states.
![]() |
The network management handles MOST network related tasks, such as:
MOST network management for the EHC is only provided when the configuration interface is in Attached Mode, see Section 3.3.1.2 .
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 5-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.
![]() |
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.
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 4-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 4-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.
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:
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.
If the startup was successful, the MOST network and its port(s) will enter the available state, meaning INIC.MOSTNetworkStatus.Availability (see page 141 ) and INIC.MOSTPortStatus.Availability (see page 158 ) change their state to Available , which in turn means that the network is now in NetInterface Normal Operation state, see Figure 5-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.
Similar to the network startup scenario, also the network shutdown function call INIC.MOSTNetworkShutdown() , see page 151 , 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.
An error shutdown can have different reasons:
AvailabilityTransitionCause indicates the reason for the network shutdown trigger.
When the network starts the shutdown process, AvailabilityInfo changes to NotAvailable in INIC.MOSTNetworkStatus() (see page 141 ) and in INIC.MOSTPortStatus() (see page 158 ). 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.
To verify the integrity of the MOST network, the INIC embeds the Ring Break Diagnosis (RBD) as specified in the MOST Specification [1] .
|
RBD can be triggered either by a INIC.MOSTNetworkRBD() command or via the power management, signaling STP on the PS0 / PS1 pins, see also Table 4-1 . If the RBD is triggered via PS0 / PS1 , the INIC performs the RBD as specified.
If the network has been already started up by the INIC.MOSTNetworkStartup() function or was woken up due to activity, it is also possible to start RBD.
The MOST Specification [1] requires that the RBD must be started in all nodes within the time window t Diag_Start, so that the result of the diagnosis is reliable and interpretable.
During RBD all network and port values are invalid; this includes NodePosition , MaxPosition , FreeStreamingBW and PacketBW.
If INIC enters ForcedNA state during the period that RBD is performed, it leaves RBD.
When RBD is entered, Availability changes to NotAvailable in INIC.MOSTNetworkStatus() (see page 141 ) and INIC.MOSTPortStatus() (see page 158 ). In this stage, no network communication is possible. AvailabilityInfo changes to Diagnosis .
If a network-related failure is detected, either PosDetected , DiagFailed or Pos0WeakSig can be returned. If RBDResult is PosDetected , the exact position can be read by means of parameter RBDPosition . If the result is DiagFailed , RBD exits and RBD Phase 3 will not be entered. For PosDetected or Pos0WeakSig , RBD is continued with Phase 3 (for additional information refer to the MOST Specification [1] ).
The result is sent by the INIC that is directly located after the ring break; in this case the INIC broadcasts the NetBlock.RBDResult.RBDStatus message (see page 129 ) to the MOST network and to the EHC.
RBD is finished after the INIC.MOSTNetworkRBD.Result message has been sent to the EHC. The result is presented in function INIC.MOSTNetworkRBDResult() , see page 153 . If the value inside INIC.MOSTNetworkRBDResult() has not yet been updated or RBD was just started, then the content is Pending . After RBD is finished, the INIC enters NetInterface Off state, even if the ring is closed.
Note: This functionality is chip-specific.
For details refer to
Chip_SystemDiagnosis
.
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 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.
The diagnosis state is signaled on a system wide level by use of a special system bit distributed by the TimingMaster. By using the system bit during the diagnosis phase, a TimingSlave will always end up in diagnosis mode, even in case of a reset. During the presence of the system bit, the network is in NotAvailable state. Thus, any application communication using the MOST network is not possible in diagnosis state.
Whenever the network is started in diagnosis mode, the TimingMaster and a TimingSlave perform the actions as described below:
Above described actions are always executed by a TimingMaster on any successful reception of INIC.MOSTNetworkSystemDiagnosis.StartResult and respectively by a TimingSlave on any transition from NetInterface Off to system diagnosis state.
In order to run the system diagnosis, the INIC provides several functions that are used to run and complete the system diagnosis process, see below:
For further information contact: support-ais-de@microchip.com.
Note: This functionality is chip-specific.
For details refer to
Chip_CableLinkDiagnosis
.
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
|
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.
|
Note: This functionality is chip-specific.
For details refer to
Chip_PhysicalLayerTest
.
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 Device Under Test (DUT). During the test it feeds the DUT with a defined stress test pattern. 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 22.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 .
![]() |
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.
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:
This is the logical address of the INIC and used for MCMs and MDPs. The NodeAddress and its customizable ranges are as follows:
Defines the mechanism of calculating the node address. In general, this value is only valid in the identification string. The final node address is then calculated as described below. |
|
This range is used for dynamic calculated node addresses and depends on the device's position in the network (node address = 0x0100 + position). It is calculated on transition to Available state if the value is 0xFFFF. It is also calculated on each reception of command NWM.Configuration.Status(NotOK) . If a value in the dynamic node address range is entered as a default value, it will be used as a valid node address, until the next reception of command NWM.Configuration.Status(NotOK) , which leads to a new calculation of the node address. |
|
These ranges are used for static node addresses, which are independent of the node position. The reception of command NWM.Configuration.Status(NotOK) does not lead to a new address calculation. |
|
This range is used for administrative purposes. The values of this range can only be set by AdminNodeAddress. |
|
As long as the node is not welcomed, this node address is used when System Mode is UNICENS or the device is in system diagnosis mode. |
The NodePositionAddress of the INIC is used for MCMs and MDPs. The NodePositionAddress is a combination of 0x0400 (factory default value) plus the node position. Hence, 0x0405 indicates the INIC is on node position five in the MOST network.
The GroupAddress of the INIC is used for MCMs and MDPs. Devices of the same type can be assigned the same group address and thus can be administered together. A message sent to this group address controls the entire device group. If message transmission fails the error of the last retry is reported.
The INIC has three group addresses, defined as follows:
The value of this group address is fixed to 0x03C8 and is not user-configurable. The broadcast message sent to this address targets all MOST network nodes. The control communication over the MOST network is blocked unless not every device has acknowledged the broadcast message or all retries are exhausted. |
|
The value of this group address is fixed to 0x03FF and is not user-configurable. The control and packet communication over the MOST network is not blocked. The broadcast message is used for uncritical data transmissions. Hence, messages sent to this address are not required to reach every MOST network node. |
|
The value of the group address is user-configurable in the range of 0x0300 up to 0x03FE. A control or packet message that is sent to a group address targets all MOST network nodes that are part of the group, i.e., all nodes that have the same value for the GroupAddress . This parameter can be customized via the Identification String. |
For more information on addressing, refer to the MOST Specification [1] .
For MEPs the INIC uses 48-bit MAC-addressing. The MAC address can be configured by function INIC.MOSTNetworkConfiguration() or by using the Driver Control Interface, see Section 19.2.3 and Chapter 21.0 .
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 22.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.
In the following situations the INIC acts as a NetworkMaster substitute to send NetworkMaster.ConfigurationStatus(NotOK) :
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.
The INIC stores the address information of the FBlock NetworkMaster whenever the following conditions apply:
Based on this address information, the INIC is capable to determine the location of the FBlock NetworkMaster, which can be either:
After reset the address information is uninitialized; as a result the FBlock NetworkMaster location is unknown.
The INIC's internal system configuration state is derived as follows:
After reset, the system configuration state is initialized to NotOK .
Every time the INIC receives a NWM.Configuration.Status(NotOK) message, a re-calculation of the device's dynamic NodeAddress will be triggered.
Note: This functionality is chip-specific.
For details refer to
Section 2.2.5
.
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:
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 7-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.
A port encapsulates a dedicated on-chip hardware interface together with the associated configuration.
Some ports are created by default by INIC, for example a MOST Port. Others can be configured to be created either by default or manually, for example the SPI Port. Other ports can only be created manually by using an INIC API function, for example a Streaming Port.
Once a port has been created by using an INIC API function, it may be disabled and possibly re-created with a new configuration. This allows ports to be disabled when not currently in use.
|
A socket encapsulates a data channel of the port it is attached to. This data channel is where data is routed to or from, when the socket is connected; a socket can be seen as one of the end points of a data route through the chip.
A socket has a data type classifier, a direction, and a size. The direction specifies if data is received or transmitted on the interface. The size specifies the highest-required bandwidth value that is necessary to ensure a safe data transmission.
A socket cannot be destroyed if it is currently being used in a connection.
In order to enable routing of data between two sockets, the sockets are required to be connected – which is accomplished when creating a connection.
A socket of direction Input can only be connected to another socket of direction Output , where both sockets must be of the same data type.
Depending on the data type, different rules for connecting sockets may apply. The rules are introduced by INIC as a way to ensure safe data transmission when two sockets have been successfully connected.
INIC provides on-chip support for enforcing requirements defined by the MOST Specification [1] regarding system connection management and muting, where socket connections may be automatically muted or cleaned up depending on, for example, network-related events.
A combiner enables streaming data to be routed from a MOST socket to a specified segment of a peripheral socket. The same combiner may be used in multiple connections, which enables grouping of data streams from multiple MOST sockets into the same peripheral socket. For details refer to Chapter 16.0 .
A combiner cannot be destroyed if it is currently being used in a connection.
A splitter enables two variants of routing to be set-up. The first variant is a splitter created with a peripheral socket. It enables data routing from a specified segment of the peripheral socket to a MOST socket. The second variant is a splitter created with a MOST socket. This variant enables data routing in its whole (no segments) from the MOST socket to multiple peripheral sockets. For details refer to Chapter 17.0 .
A splitter cannot be destroyed if it is currently being used in a connection.
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 7-1 shows the assignment between object type, resource identifier and index.
Note: Availability of resource objects is chip-specific, see Section 2.2 .
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.
The INIC provides a mechanism where multiple resources can be destroyed by a single request.
INIC.ResourceDestroy() , see page 206 , 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.
A resource can be in one of the following states:
While an Invalid resource state requires the resource to be destroyed (see Section 7.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 7.5.1 .
![]() |
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.
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 GP8 Pin 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 7.5.2.1 can be extended by implementing the muting concept, see Section 7.5.2.2 .
Muting applies only to synchronous streaming sink connections. Apart from the manual muting that is set by API function INIC.SyncMute() , the INIC supports the features described in this section.
In order to provide a fast indicator to assist devices when muting is required, the INIC has a MUTE pin that can signal such conditions ( GP8 was configured as MUTE pin, see the INIC Hardware Data Sheet [4] ). It is enabled by registering streaming sink connections for mute signaling by setting their MuteMode to MuteSignal . If an event occurs that can corrupt the data for any registered connection, the MUTE pin will be raised. The devices that are receiving the data must be connected to the MUTE pin and mute when it is high. The MUTE pin is released by resetting the resource monitor from state ActionRequired , unless there is still a condition that prevents it. It cannot be released if any registered connection is in a TemporaryInvalid or Invalid state; in either case there will be another ActionRequired notification. The EHC can unmute the devices when receiving State OK from the resource monitor. However, devices must immediately mute again if the MUTE pin is already raised; if necessary, the EHC should check the MUTE pin state before attempting unmute, to reduce unnecessary glitches.
Setting the MUTE pin is global for all monitored connections.
The MuteMode configures how the resource monitor will handle events that have made a streaming sink connection invalid. The MuteMode can be configured as follows:
When the EHC receives a ResourceMonitor.Status(ActionRequired) , it must check for any invalid resources and destroy all of them, see Figure 7-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() , see page 206 . 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) , see page 209 , 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 7-2 depicts a recommendation for a proper EHC implementation without considering the muting concept. An EHC example implementation with muting is shown in Section 7.5.2.2 .
Figure 7-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 7-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 7-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.
![]() |
When the configuration interface enters Protected Mode, all MOST resources are marked invalid.
If the configuration interface is in Attached Mode, a transition from INIC.MOSTPortStatus.Availability = Available to NotAvailable will cause resources associated with the respective MOST Port to be marked invalid and reported to the EHC for processing.
Routing will be stopped automatically and any allocated network bandwidth will be released. The MOST Port is no longer available for streaming data.
An example of invalidated connections and the handling of them is shown in
Figure 7-5
.
|
The EHC is always in control of destroying resources, even when INIC has automatically marked them as invalid.
In Remote Control Mode, a transition from INIC.MOSTPortStatus.Availability = Available to NotAvailable will trigger the INIC to enter Protected Mode.
The INIC enables on-chip support for aiding an EHC application in fulfilling system connection management requirements for streaming data connections as defined in the MOST Specification [1] . The following event causes invalid resources:
The network configuration status NWM.Configuration.Status(NotOK) triggers a transition from system state OK to system state NotOK.
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.
Routing memory is required to ensure a safe routing path (no data loss) for data between two resource objects. INIC manages routing memory internally when creating or destroying resource objects. Allocation and deallocation of routing memory can occur frequently. Although INIC uses a best-fit algorithm when managing routing memory, fragmentation may occur if memory blocks of varying sizes are allocated and deallocated in a highly dynamic fashion.
A routing channel is required to enable data transfer between two resource objects (uni-directional). INIC manages the routing channels internally when creating or destroying resource objects.
For information on routing memory and routing channels refer to Section 2.2.4 .
Note: Availability of resource objects is chip-specific, see
Section 2.2
.
For details refer to
Chip_NumberOfMOSTPorts
.
A MOST Port enables support of port-specific network handling. It provides different interface capabilities, which are cPHY (coax electrical physical layer) or oPHY (optical physical layer). Different transmission classes are available for transferring data over the MOST network:
If a MOST Port is available, it provides information on FreeStreamingBW . If a port is not available, the FreeStreamingBW is 0xFFFF. The FreeStreamingBW depends on the configured PacketBW .
A MOST Port can be either Available or NotAvailable . Additional information is given in AvailabilityInfo .
If the MOST network is Available , a MOST Port becomes also Available .
Behavior for INICs that provide two MOST Ports
Since the FreeStreamingBW is shared between the MOST Ports, MOST Port 1 cannot administrate streaming resources; it always reports zero for FreeStreamingBW . If a port is Unused , the port is considered to be in bypass mode; AvailabilityInfo is switched to BypassedDisabled . If a port is Used , but inactive, the port is switched to BypassedRegular . When the port is active, AvailabilityInfo can be either Unstable or Stable , see also Section 22.2.4.2 .
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.
This configuration setting defines the physical layer to be used.
Behavior for INICs that provide two MOST Ports
A MOST Port can be set to used or unused either by customization of the Configuration String or via the INIC.MOSTPortUsed() function, see page 160 .
This configuration setting defines the initial operation mode of the MOST Port.
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, see page 161 .
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 20.4 .
Additionally, each MOST socket requires a routing channel according to the data type for which it is created, see Section 2.2.4 .
Behavior for INICs that provide two MOST Ports
A MOST socket can only be created on MOST Port 0.
For general socket information refer to Section 7.1.2 .
Note: Availability of resource objects is chip-specific, see
Section 2.2
.
For details refer to
Chip_NumberOfMediaLBPorts
.
The MediaLB Port is the interface to the Media Local Bus. It supports the handling of all MOST network data types and is available in two pin-out options: MediaLB 3-Pin (single-ended) and MediaLB 6-Pin (differential). Both pin-out options are available on chip, whereas the use of these options is mutually exclusive, i.e., either MediaLB 3-Pin or MediaLB 6-Pin can be used.
The clock speed on which the MediaLB Port is running, is a multiple of the MOST network frame rate Fs; thus the maximum frequency for MediaLB 3-Pin is 1024Fs and for MediaLB 6-Pin it is 8192Fs.
The MediaLB Port can be created either by customization of the Configuration String or via the INIC.MediaLBPortCreate() function, see page 165 .
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.
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.
Table 9-1 shows the coherences between the MediaLB clock speed and the supported pin modes. The maximum values for available bandwidth and channel addresses are also dependent on the selected clock speed.
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() , see page 167 .
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 7.1.2 .
Although bandwidth is allocated in quadlets, INIC is able to handle routing of a lesser number or a number not equally divisible by 4. Parameter Bandwidth specifies the number of bytes that should be routed. For example, a data stream which is 6 bytes wide – two 24-bit channels (stereo) – needs to have parameter Bandwidth set to 6 bytes. The allocated bandwidth on MediaLB will be padded to 8 bytes (2 quadlets). The padding mechanism must be considered when planning the resource budget for an application. The total available MediaLB bandwidth is decided by the configured clock speed.
|
The MediaLB bandwidth required to allow a safe data transmission depends on the transmission class selected.
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 9-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 9-2 ).
![]() |
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 9-2 gives an overview over the allocated MediaLB Bandwidth and the number of physical channels available for multiplexing.
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 22.2.5.2 . The MediaLBSocketHandle returned is then used with the INIC.MediaLBPacketMuxSocketCreate() function to enable the multiplexing mechanism, see Section 22.2.5.3 .
When calling INIC.MediaLBPacketMuxSocketCreate() , the INIC creates a new socket based on the characteristics of the provided socket. It has the
|
To enable packet data routing, the handle of both sockets may be used with function INIC.PacketAttach() , see Section 22.2.13.1 .
The Serial Peripheral Interface (SPI) Port of the INIC allows to directly interface with microcontrollers that provide a standard SPI.
Besides the standard SPI signals ( CS , SCLK , SDIN and SDOUT ), the INIC provides an interrupt line, SINT (see the INIC Hardware Data Sheet [4] ), which is used for byte-level flow control such as required for half-duplex transmission.
When the SPI Port is created, the INIC operates as an SPI bus slave and supports the exchange of asynchronous data packets (MDPs and MEPs).
The SPI Port can be created either by customization of the Configuration String or via the INIC.SPIPortCreate() function, see page 172 .
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.
This configuration setting provides various SCLK clock modes for the phase and polarity signals used by the SPI bus slave.
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() , see page 173 .
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 7.1.2 .
Note: Availability of resource objects is chip-specific, see
Section 2.2
.
For details refer to
Chip_NumberOfUSBPorts
.
The USB Port allows the connection of an INIC as a USB device to any USB 2.0-compliant host. It supports the handling of all MOST network data types (except QoSPacket ) and provides two physical layer options: a USB 2.0 default layer and a USB 2.0 HSIC (High-Speed Inter-Chip) layer, which is a layer variant designed for inter-chip communication. Both options are available on chip, whereas the use of these options is mutually exclusive, i.e., either the default USB 2.0 layer or the HSIC layer can be used.
The INIC implements a high-speed USB device with a rate of 480 Mbit/s. As with any USB-compliant device, it is capable of falling back to full-speed mode (12 Mbit/s) if connected to a USB 1.x Port. In this mode, the INIC does not provide any Endpoint, therefore creation of USB sockets is not possible.
USB device communication is based on pipes. A pipe is an association between a device Endpoint and the host controller. System software of the host controller establishes a pipe with each Endpoint address the host wants to communicate with. This is part of the enumeration process.
|
The USB Port only supports bulk transfers. The maximum packet size of a bulk transaction is 512 bytes.
An overview of descriptors reported by the INIC can be found in Section 11.5 .
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.
For A/V packetized connections the number of required bulk transactions per Microframe 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 Section 20.4.1 .
For synchronous connections the number of required bulk transactions per Microframe is fixed to 1.
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.
The USB Port can be created either by customization of the Configuration String or via the INIC.USBPortCreate() function, see page 175 .
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.
This configuration setting allows to define the USB Port’s physical layer either as standard USB 2.0 layer or as HSIC layer.
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 11.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:
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() , see page 177 .
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, see page 177 . 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 20.0 for details.
For general socket information refer to Section 7.1.2 .
For USB-related information refer to the USB 2.0 Specification [5] .
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.
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.
![]() |
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.
![]() |
If FramesPerTransaction is 0xFFFF, no padding is applied.
![]() |
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.
All parameters of a USB vendor request are transported in little-endian format. This section describes all vendor-specific requests the INIC supports.
The DCI provides direct access to an internal register set as an auxiliary INIC control interface. If the USB device driver has no access to the regular INIC API (e.g., through the ICM channel), it can read or write DCI registers by issuing vendor-specific requests over USB. The register set description can be found in Chapter 21.0 .
There are two vendor-specific device requests for reading and writing DCI registers:
Content 1 |
Diag ID-unique firmware built number e.g., “00AB-00000060” |
|
Note 1: The string consists of two values in zero-padded hex notation, concatenated by a hyphen: “XXXX-XXXXXXXX”. The first value is the Diag ID as defined in the configuration string. The second value is a unique firmware built number. |
The INIC enables a set of two Streaming Ports: Streaming Port A and Streaming Port B.
A Streaming Port can be configured to be compatible to one of the several industry-standard serial data formats, which support media connections to multimedia source and/or sink devices that handle frame-based data streams.
The Streaming Port supports the Synchronous Streaming MOST network transmission type.
Each Streaming Port has a dedicated set of serial data pins: SRXA0 and SRXA1 for Streaming Port A and SRXB0 and SRXB1 for Streaming Port B. Streaming Port A is the only instance that has a set of clock ( SCK ) and synchronization ( FSY ) signals in addition to the serial data pins. Streaming Port B can be configured to be linked to Streaming Port A, in which case these clocking signals are shared by all the data pins of the two ports.
The Streaming Port provides a loopback feature; streaming data received from a network channel can be routed back to the network on a different network channel, see Section 22.2.8.3 .
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() , see page 180 . 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.
This configuration setting defines the operation mode of the Streaming Port. The available operation mode is:
In this operation mode Streaming Port B is linked to Streaming Port A. All data pins share the FSY and SCK signals. Clocking signals are enabled when Streaming Port A is created. Creating Streaming Port B is optional. Therefore, the following conditions must be taken into account when creating ports:
When destroying the ports, the following must be taken into account:
This configuration setting defines the direction of the physical data pins of the port. Various options are available depending on the selected operation mode. See the INIC Hardware Data Sheet [4] for an overview of available options.
This configuration setting only applies to Streaming Port A when configured in operation mode Generic . If Streaming Port B is additionally configured in operation mode Generic , this means it shares the clock and synchronization signals with Streaming Port A, the clock configuration applies for data pins of both ports.
While configured as Output , INIC drives the FSY/SCK signals as outputs, frequency locked to the network clock.
When configured as Input , the FSY/SCK signals must be driven externally, where the RMCK, which is frequency locked to the network clock, is used as reference for clock generation.
Clock data delay (Streaming Port A)
This configuration setting applies only to Streaming Port A when configured in operation mode Generic . If Streaming Port B is additionally configured in operation mode Generic , this means it shares the clock and synchronization signals with Streaming Port A, the clock configuration applies for the data pins of both ports.
This setting indicates if there should be a single clock cycle delay between the start of frame and the start of the frame data. When enabled, start of frame data is required to occur on the falling edge of the synchronization signal. For example, left-channel audio data of a stereo stream should occur on the falling edge; this is required for I 2 S™ compatibility.
When set, only left-justified or sequential formats are available.
This configuration setting only applies to Streaming Port A when configured in operation mode Generic . However, if Streaming Port B is additionally configured in operation mode Generic , meaning it shares the clock and synchronization signals with Streaming Port A, the clock configuration applies for data pins of both ports.
This setting indicates the clock speed configuration of the SCK signal. Fs should be seen as an umbrella term referring to F Network , which is the MOST network sampling frequency used for the synchronous mode.
This configuration setting specifies in which way the data bytes are required to be located within the Streaming Port frame, so that they can be routed correctly. Multiple industry standard formats are supported, see the INIC Hardware Data Sheet [4] for more information.
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 12.3.1 for an example where a routing format, compliant to the I 2 S standard, is configured. Refer to Section 22.2.8.4 for a reference of the API command used in INIC.StreamSocketCreate() .
For general socket information refer to Section 7.1.2 .
This section gives an example of how to configure the Streaming Port and sockets to setup a use case for 16-bit stereo audio streaming between the INIC and an external audio codec using an I 2 S-compatible format. The INIC generates the clock signals required by the codec. The clock signals are frequency locked to the time base of the MOST network (synchronous).
Approach 1: base configuration using the configuration string (see Chapter 23.0 )
Implement the steps as follows to configure Streaming Port A and Streaming Port B:
1. Set Base Configuration Load to LoadedAtStartup .
|
2. Set
OperationMode
(Port A Operation Mode and Port B Operation Mode) to
Generic
.
Data pins of Streaming Port B share the clock and synchronization signals of Streaming Port A.
3. Set PortOption (Port A Option and Port B Option) to InOut .
4. Set the clock mode (Port A Clock Mode) to Output .
5. Set the clock delay for data (Port A Clock Data Delay) to
Delayed
.
This setting adjusts the start of frame such that it occurs on the falling edge of
FSY
. It also introduces one clock cycle of delay between start of frame and start of frame data. Enabling this setting is required for I
2
S compatibility.
Approach 2: base configuration using the INIC.StreamPortConfiguration.SetGet() command (see Section 22.2.8.1 )
Send the following command to configure Streaming Port A:
INIC.StreamPortConfiguration.SetGet()(Index = StreamPortA,
OperationMode = Generic,
PortOption = InOut,
ClockMode = Output,
ClockDataDelay = Delayed
Send the following command to configure Streaming Port B:
INIC.StreamPortConfiguration.SetGet()(Index = StreamPortB,
OperationMode = Generic,
PortOption = InOut,
ClockMode = Wildcard,
ClockDataDelay = Wildcard)
After the base configuration is done, proceed with the steps as follows:
1. Create the Streaming Port resource
INIC.StreamPortCreate.StartResult(Index
=
StreamPortA
,
ClockConfig
=
64Fs
,
DataAlignment
=
Left16Bit)
INIC.StreamPortCreate.Result (StreamPortHandle
= 0x1600
)
2. Create the Network Port socket of direction input (ConnectionLabel 0x0043 already exists on the network)
INIC.MOSTSocketCreate.StartResult(MOSTPortHandle
= 0x0D00,
Direction
=
Input
,
DataType
=
Sync
,
Bandwidth
= 0x0004,
ConnectionLabel
= 0x0043
)
INIC.MOSTSocketCreate.Result(MOSTSocketHandle
= 0x0E02
)
3. Create a Streaming Port socket of direction output
INIC.StreamSocketCreate.StartResult(StreamPortHandle
= 0x1600,
Direction
=
Output
,
DataType
=
Sync
,
Bandwidth
= 0x0004,
StreamPinID
=
SRXA1)
INIC.StreamSocketCreate.Result(StreamSocketHandle = 0x1703 )
INIC.SyncCreate.StartResult( SocketHandleIn
=
MOSTSocketHandle
(0x0E02),
SocketHandleOut
=
StreamSocketHandle
(0x1703),
DefaultMute
=
False)
INIC.SyncCreate.Result(SyncHandle = 0x0200 )
By using either approach 1 or 2 for the base configuration and performing the steps required to setup the socket connection, now the 16-bit audio stream is routed to the output pin SRXA1 on Streaming Port A according to the Delayed-Bit Alignment format, see the INIC Hardware Data Sheet [4] .
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).
The Inter-Integrated Circuit (I 2 C) Port of the INIC allows to directly interface with devices that provide a standard I 2 C interface.
The INIC offers two operation modes:
The I 2 C Port can be created by customization of the Configuration String or via the INIC.I2CPortCreate() function, see page 191 .
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.
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.
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. In this mode, the INIC offers two different settings for the transfer speed ( Speed ): 100 kHz (Standard-mode, default) and 400 kHz (Fast-mode).
Using this mode makes the INT pin available as GPIO, see the INIC Hardware Data Sheet [4] .
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 3.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.
For the I2C Port pin connection refer to the INIC Hardware Data Sheet [4] .
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; examples are shown in Section 14.3.1 . 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:
The following examples depict some standard communication sequences, which can be used for most use cases.
Figure 14-1 shows an example of a single read/write transaction.
![]() |
Figure 14-2 shows an example of a burst transaction writing multiple data chunks.
![]() |
Figure 14-3 shows an example of a repeated start transaction. At the beginning a write is initiated with a subsequent read.
![]() |
The INIC allows certain pins to be reprogrammed from their default functionality to support general purpose input/output (GPIO) functionality. GPIOs are not available as long as they are used in any of the INIC API functions (apart from those that are related to GPIOs configuration) or configured in the configuration string.
The GPIO Port can be created via the INIC.GPIOPortCreate() function, see Section 22.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 22.2.11.2 . Depending on the pin configuration, the controlling application (EHC or remote application) can receive a notification via INIC.GPIOPortTriggerEvent() , see Section 22.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. For detailed information refer to the INIC Hardware Data Sheet [4] .
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 following trigger classes are available:
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.
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 INIC Hardware Data Sheet [4] .
Figure 15-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 15-2 shows an example sequence chart of how an controlling application can use the GP0 pin with the trigger configuration InputTriggerHighLevel .
![]() |
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.
Figure 15-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.
![]() |
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.
Note: Availability of resource objects is chip-specific, see
Section 2.2
.
For details refer to
Chip_NumberOfMediaLBPorts
and
Chip_NumberOfUSBPorts.
A Combiner can be used for connections based on the synchronous data type ( Sync ). It is created with:
All combiner settings are configured through the INIC.CombinerCreate() function, see Section 22.2.14.6 . A combiner is shown in Figure 20-2 .
A routing channel is required to be allocated from the synchronous routing channel table. INIC handles allocation automatically. If there are no free channels, an error will be reported.
The number of resources required from the standard routing memory is decided by the value of combiner parameter BytesPerFrame .
|
If the socket used with the combiner is a USB socket, additional resources from the aggregation routing memory are required. The number of resources can be calculated using the following equation:
![]() |
MemorySpace = Number of bytes allocated in the aggregation routing memory
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.
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.
![]() |
Note: Availability of resource objects is chip-specific, see
Section 2.2
.
For details refer to
Chip_NumberOfMediaLBPorts
and
Chip_NumberOfUSBPorts
.
A Splitter can be used for connections based on the synchronous data type ( Sync ). It is created with:
All settings are configured through the INIC.SplitterCreate() function, see Section 22.2.14.7 . Splitter connections are shown in Figure 20-3 .
A routing channel is required to be allocated from the synchronous routing channel table, but only if it is not created with a MOST socket. INIC handles allocation automatically. If there are no free channels, an error will be reported and the connection cannot be created.
The number of bytes required from the standard routing memory is decided by the value of splitter parameter BytesPerFrame .
|
If the socket used with the splitter is a USB socket, additional bytes from the aggregation routing memory are required. The number of bytes can be calculated using the following equation:
![]() |
MemorySpace = Number of bytes allocated in the aggregation routing memory
The control connection is used to send/receive MOST Control Messages to/from the MOST network. MCMs are then forwarded to internal FBlocks or Shadows and to the MCM PMP channel, to be delivered to the EHC.
The data flow is shown in Figure 18-1 .
![]() |
The MOST network socket and its appropriate control connection are automatically managed by INIC.
The message transmission status that is reported when sending MCMs to the MOST network is shown in Table 3-3 .
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 18-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.
![]() |
Note: Availability of resource objects is chip-specific, see
Section 2.2
.
For details refer to
Chip_NumberOfMediaLBPorts
and
Chip_NumberOfUSBPorts
.
Packet connections are used to exchange MOST Data Packets (MDP) and/or MOST Ethernet Packets (MEP) between the MOST network and the EHC.
|
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 19-1 , Figure 19-2 and the data fields description below the figures.
![]() |
![]() |
The Port Message consists of a PML field that is followed by several data fields.
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:
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 19-3 .
![]() |
The information given in this section are based for applications that transmit packet data from one of the peripheral sockets to a MOST network socket.
BandwidthSource = Number of data bytes defined by PacketBW |
Parameter Bandwidth corresponds to Bandwidth Source.
The real size of the physical MediaLB channel allocated is quadlet aligned, as described in Section 9.2.1 .
Parameter FramesPerTransaction is fixed to 0xFFFF.
No padding is applied by the INIC. Packet synchronization is performed as described in Section 19.4 .
The utilized bandwidth is adjusted dynamically, depending on the traffic throughput.
The bi-directional MOST network socket is automatically managed by the INIC. The bandwidth of this socket corresponds to Bandwidth Source.
The information given in this section are based for applications that transmit packet data from a MOST network socket to one of the peripheral sockets.
BandwidthSource = Number of data bytes defined by PacketBW |
The bi-directional MOST network socket is automatically managed by the INIC. The bandwidth of this socket corresponds to Bandwidth Source.
Parameter Bandwidth corresponds to Bandwidth Source.
The real size of the physical MediaLB channel allocated is quadlet aligned, as described in Section 9.2.1 .
|
Parameter FramesPerTransaction is fixed to 0xFFFF.
No padding is applied by the INIC. Packet synchronization is performed as described in Section 19.4 .
The utilized bandwidth is adjusted dynamically, depending on the traffic throughput.
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.
|
Register values are always sent to the EHC device driver via the register status message by using an MDP read message (see
Figure 19-1
) that uses TelID 0x00. This TelID does not allow message segmentation.
A register status message is triggered whenever changes occur regarding
or it is triggered by the read register command as shown in Figure 19-4 .
The fields of the MDP read message carry the information as shown in Figure 19-1 and are described in detail below:
InstID is the current position in the network (0x00, if undefined, e.g., network is in NotAvailable state or if TimingMaster) |
||
d9 is 0x01, reports the current system configuration state. It will be ensured that no state change from OK to NotOK gets lost. |
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:
![]() |
A write register command is used by the EHC device driver to update register settings. For the available register set refer to Chapter 21.0 .
![]() |
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 19-6 shows the data flow for QoS packet connections between a MOST network socket and a MediaLB socket.
![]() |
A routing channel is required to be allocated for the MOST network socket, see Chip_RoutingChannels .
The number of resources required from the standard routing memory is decided by the allocated Bandwidth on MOST, see Table 19-1 .
As shown in Figure 19-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.
![]() |
DataRateE = Maximum burst throughput rate on Ethernet [Mbit/s]
Factor = 2.9297 [(byte) x (s/Mbit)]
Parameter Bandwidth corresponds to Bandwidth Source.
The real size of the physical MediaLB channel allocated is quadlet aligned, as described in Section 9.2.1 .
Parameter Bandwidth corresponds to Bandwidth Source.
The information given in this section are based for applications that transmit QoS packets from a MOST network socket to a MediaLB socket.
BandwidthSource = Number of data bytes allocated on the MOST network |
Parameter Bandwidth corresponds to Bandwidth Source.
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:
![]() |
Parameter Bandwidth corresponds to Bandwidth MediaLB.
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:
Depending on the communication characteristics of the peripheral interface involved in the packet connection, there are special synchronization mechanisms available, which are described below.
When the synchronization process is started, the INIC forces the transmission to terminate. In case of an outgoing transmission, the pending packet is terminated by an AsyncBreak command. In case of a pending packet reception, the INIC responds with a ReceiverBreak status to enforce the transmitter to break.
The next packet, after the synchronization process has been completed, starts with an AsyncStart command again.
Any pending transmission is stopped without an AsyncBreak command or a ReceiverBreak status. This behavior can result in a ProtocolError status from the INIC for the next incoming message after the synchronization has finished. For an outgoing transmission the EHC can respond to the next AsyncStart command with a ProtocolError status.
The synchronization process required for USB packet connections needs additional communication effort, since a USB transfer containing one packet message can be divided into several USB bulk transactions. A packet message with a maximum size of 1536 bytes takes up to three USB bulk transactions to complete.
The data transferred via a one-bulk transaction does not contain any additional information on data fragments. To keep synchronization, the following rules are applied:
The INIC automatically discards incoming packet messages on USB upon the following error conditions:
In such cases the synchronization process is not triggered.
In addition to the common synchronization triggers mentioned above, on USB there is a DCI register available for each Endpoint that can be used by a driver application to manually trigger the synchronization process. This is needed whenever a driver is restarted during runtime to ensure packet synchronization. The DCI register is described in Section 21.1 et seqq.
Whenever the synchronization process is triggered, the following sequence is executed by the INIC:
1. Endpoints respond with NACKs
2. IN Endpoint will be set to STALL state until the host driver sends ClearFeature(STALL)
A host driver has to implement the following rules to behave correctly in case of synchronization:
Note: Availability of resource objects is chip-specific, see
Section 2.2
.
For details refer to
Chip_NumberOfMediaLBPorts
and
Chip_NumberOfUSBPorts
.
Routing of streaming data is typically set-up by creating a connection between sockets that support the same data type, are of opposite directions, and located on different ports. Such a connection can be seen as a point-to-point connection and is the standard streaming connection type.
A standard streaming connection can be defined for all streaming data types that are supported by INIC.
In order to optimize the data transmission of streaming data, INIC internally uses advanced routing channels and memory resources that are allocated when a connection is created. The number of resources required depends on the routing objects used in the connection. All routing memory resources are shared. See section Routing Budget for more information.
Muting of synchronous connections
For synchronous connections the INIC supports muting-related features provided by function INIC.SyncCreate() . A connection can be kept muted when created or de-muted automatically. This setting is specified by parameter DefaultMute. The INIC's built-in resource monitoring mechanism supports individual handling of connections on detecting that the streamed data may be invalid. The configuration of this handling is done by parameter MuteMode. For more information on muting refer to Section 7.5.1 .
A Synchronous connection uses the synchronous transmission class on the MOST network for streaming data. A connection between two sockets is created by using the API function INIC.SyncCreate() . This command tells the INIC to setup a routing path through the chip between a MOST network channel and a port channel.
A special case for a synchronous connection is the loop feature. With this feature it is possible to create a MOST socket of data type Sync and direction Input with the same ConnectionLabel as an existing Output socket of the same type. This socket type is called a loop socket. Loop sockets do not support muting and cannot be connected to or used in combination with a splitter or combiner.
Figure 20-1 shows the data flow for synchronous connections between a MOST network socket and one of the peripheral sockets. It also shows the loop feature, in which the data is looped over the MOST network.
![]() |
A routing channel is required to be allocated for the MOST network socket, see Chip_RoutingChannels .
The number of bytes required from the standard routing memory (see Section 7.8.1 ) is decided by the Bandwidth of the sockets that need to be connected; the Bandwidth for both sockets must be equal.
|
If one of the sockets used in the connection is a USB socket, additional resources from the aggregation routing memory are required. The number of resources can be calculated using the following equation:
![]() |
MemorySpace = Number of bytes allocated in the aggregation routing memory
The number of required bulk transactions per USB Microframe is at least 1.
The information given in this section are based for applications that stream data from one of the peripheral sockets to a MOST network socket.
For this connection type parameter Offset must be written 0.
BandwidthSource = Number of data bytes that should be routed |
Parameter Bandwidth corresponds to Bandwidth Source.
The real size of the physical MediaLB channel allocated is quadlet aligned, as described in Section 9.2.1 .
Parameter FramesPerTransaction defines the number of MOST network frames filled-in into one USB transaction. The size of one network frame is defined by parameter Bandwidth of the MOST network socket.
If the data bytes within a bulk transaction are less than 512 bytes, padding is applied by the INIC, see Section 11.3.1 .
Parameter Bandwidth corresponds to Bandwidth Source.
Parameter Bandwidth corresponds to Bandwidth Source and defines the size of the network channel that should be allocated on the MOST network.
The information given in this section are based for applications that stream data from a MOST network socket to one of the peripheral sockets.
For this connection type parameter Offset must be written 0.
BandwidthSource = Number of data bytes allocated on the MOST network |
Parameter Bandwidth corresponds to Bandwidth Source.
Parameter Bandwidth corresponds to Bandwidth Source.
The real size of the physical MediaLB channel allocated is quadlet aligned, as described in Section 9.2.1 .
Parameter FramesPerTransaction defines the number of MOST network frames from which the synchronous data bytes are put and filled-in into one USB transaction. The size of one network frame is defined by parameter Bandwidth of the MOST network socket.
If the data bytes within a bulk transaction are less than 512 bytes, padding is applied by the INIC, see Section 11.3.1 .
Parameter Bandwidth corresponds to Bandwidth Source.
The API function INIC.SyncCreate() is used to create a routing path through the chip between a MOST network socket and a combiner.
Figure 20-2 shows the data flow for synchronous connections with a combiner. The explanation on how to create a combiner is given in Chapter 16.0 .
![]() |
A routing channel is required to be allocated for the MOST network socket, see Chip_RoutingChannels .
The information given in this section are based for applications that stream data from MOST network sockets to a combiner.
When using INIC.SyncCreate() the INIC establishes a routing path through the chip between a MOST network socket and a sub-section inside the peripheral socket that is connected to the combiner. The offset of the sub-section is specified by parameter Offset.
Any event that may render the MOST network socket invalid will also render the combiner and any associated connections invalid.
BandwidthSource = Number of data bytes allocated on the MOST network |
Parameter Bandwidth corresponds to Bandwidth Source.
Bandwidth Source must be considered by parameter BytesPerFrame, when the combiner is created. BytesPerFrame is the size of all MOST network sockets that are connected to the combiner.
The API function INIC.SyncCreate() is used to create a routing path through the chip between a splitter and a MOST network socket or a splitter and a peripheral socket.
Figure 20-3 shows the data flow for synchronous connections with a splitter. The explanation on how to create a splitter is given in Chapter 17.0 .
![]() |
A routing channel is either required to be allocated for the MOST network socket or for the connection with the peripheral socket, see Chip_RoutingChannels .
|
In this connection variant additional routing memory resources are required. The splitter parameter BytesPerFrame has to be used with the following equation to calculate the number of required bytes from the aggregation routing memory:
![]() |
MemorySpace = Number of bytes allocated in the aggregation routing memory
The information given in this section are based for applications that stream data from a splitter to MOST network sockets.
When using INIC.SyncCreate() the INIC establishes a routing path through the chip between a sub-section inside the peripheral socket that is connected to the splitter and the MOST network socket. The offset of the sub-section is specified by parameter Offset.
Any event that may render the MOST network socket invalid will also render the splitter and any associated connections invalid.
BandwidthSource = Number of data bytes that should be routed |
Bandwidth Source must be considered by parameter BytesPerFrame, when the splitter is created. BytesPerFrame is the size of all MOST network sockets that are connected to the splitter.
Parameter Bandwidth corresponds to Bandwidth Source.
The information given in this section are based for applications that stream data from a splitter connection to one of the peripheral sockets.
When using INIC.SyncCreate() the INIC establishes a routing path through the chip between the MOST network socket that is connected to the splitter and the peripheral socket.
Parameter Offset can only be 0. It is only possible to route the complete channel data from a MOST network socket. The splitter may be used in multiple connections with different peripheral sockets to stream the same MOST network data to multiple peripheral sockets.
Any event that may render the MOST network socket invalid will also render the splitter and any associated connections invalid.
BandwidthSource = Number of data bytes that should be routed |
Bandwidth Source must be considered by parameter BytesPerFrame, when the splitter is created. BytesPerFrame is the size of all MOST network sockets that are connected to the splitter.
Parameter Bandwidth corresponds to Bandwidth Source.
The real size of the physical MediaLB channel allocated is quadlet aligned, as described in Section 9.2.1 .
Parameter FramesPerTransaction defines the number of MOST network frames received by the splitter and filled-in into one USB transaction. The size of one network frame is defined by Bandwidth Source.
If the data bytes within a bulk transaction are less than 512 bytes, padding is applied by the INIC, see Section 11.3.1 .
Parameter Bandwidth corresponds to Bandwidth Source.
An AVPacketized connection uses the A/V Packetized Isochronous Streaming transmission class on the MOST network for streaming of data that is not locked to the MOST network frame rate. The data either contains a time base, which is encoded in the data stream, or it does not require any time base information for transmission and synchronization. The data flow is shown in Figure 20-4 .
![]() |
A connection between two sockets is created by using the API function INIC.AVPacketizedCreate() . This command tells the INIC to setup a routing path through the chip between the MOST network socket and the peripheral socket.
The packet sizes supported are specified by parameter IsocPacketSize in the call to INIC.AVPacketizedCreate() .
A routing channel is required to be allocated for the MOST network socket, see Chip_RoutingChannels .
The number of resources required from the standard routing memory is decided by the selected packet size, see Table 20-1 .
If one of the sockets used in the connection is a USB socket, additional resources from the aggregation routing memory are required, see Table 20-2 .
IsocPacketSize = 188 FramesPerTransaction = 0x0002 |
||
IsocPacketSize = 196 FramesPerTransaction = 0x0002 |
||
IsocPacketSize = 206 FramesPerTransaction = 0x0002 |
||
IsocPacketSize = 188, 196, or 206 FramesPerTransaction = 0xFFFF |
||
The information given in this section are based for applications that stream data from one of the peripheral sockets to a MOST network socket.
![]() |
DataRate = Maximum burst throughput rate [Mbit/s]
Factor = 2.6042 [(byte) x (s/Mbit)]
Parameter Bandwidth is calculated as follows:
![]() |
The real size of the physical MediaLB channel allocated is quadlet aligned, as described in Section 9.2.1.
Parameter 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 value is 0xFFFF, no padding is applied. Refer to Section 11.3.2 for more information.
Parameter Bandwidth is calculated as follows:
![]() |
The information given in this section are based for applications that stream data from a MOST network socket to one of the peripheral sockets.
BandwidthSource = Number of data bytes allocated on the MOST network |
Parameter Bandwidth corresponds to Bandwidth Source.
For data packets with an IsocPacketSize of 188 or 196 bytes, parameter Bandwidth corresponds to Bandwidth Source.
For data packets with an IsocPacketSize of 206 bytes, parameter Bandwidth corresponds to Bandwidth Source + 1.
The real size of the physical MediaLB channel allocated is quadlet aligned, as described in Section 9.2.1 .
Parameter 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 value is 0xFFFF, no padding is applied. Refer to Section 11.3.2 for more information.
A DiscreteFrame Isochronous Streaming phase connection uses the DiscreteFrame Isochronous Streaming transmission class on the MOST network for streaming time base information, which is asynchronous to the MOST network frequency. The supported use case is to transport the phase information over MediaLB and recover the clock with a companion device connected to MediaLB.
The data flow for the DiscreteFrame Isochronous Streaming phase connections is shown in Figure 20-5 .
![]() |
A connection between two sockets is created using the API function INIC.DiscFramePhaseCreate() . This command tells the INIC to setup a routing path through the chip between a MOST network socket and a MediaLB socket.
Each packet is required to be made up by 8 phase samples where each phase sample is a 16-bit value; hence the packet size supported is 16 bytes. The transmitting MediaLB device is responsible to adopt this requirement.
A routing channel is required to be allocated for the MOST network socket, see Chip_RoutingChannels .
The number of resources is 64 bytes.
The size of a socket specifies the least required bandwidth to allow a data transmission without data loss during peak conditions.
The information given in this section are based for applications that establish a phase connection between a MediaLB socket and a MOST network socket.
|
The bandwidth is fixed to 2 bytes indicating the maximum phase data throughput.
Parameter Bandwidth corresponds to Bandwidth Source.
The real size of the physical MediaLB channel allocated is quadlet aligned, as described in Section 9.2.1 .
Parameter Bandwidth corresponds to Bandwidth Source + 1. The additional byte is used to compensate for the isochronous transmission mechanism.
The information given in this section are based for applications that establish a phase connection between a MOST network socket and a MediaLB socket.
BandwidthSource = Number of data bytes allocated on the MOST network |
Parameter Bandwidth corresponds to Bandwidth Source.
Parameter Bandwidth corresponds to Bandwidth Source - 1. On the MOST network side there is one additional byte used to compensate for the isochronous transmission mechanism. This byte is not needed for the MediaLB Output socket.
The real size of the physical MediaLB channel allocated is quadlet aligned, as described in Section 9.2.1 .
Note: Availability of resource objects is chip-specific, see
Section 2.2
.
For details refer to
Chip_NumberOfMediaLBPorts
and
Chip_NumberOfUSBPorts.
The Driver Control Interface (DCI) can be used by EHC device drivers to retrieve status information from the INIC or to control low-level settings, such as the MAC address.
Normally, all settings are handled from the EHC via the communication interface. However, for EHC device drivers that have no direct access to the communication interface, the DCI provides the possibility to directly access status information and low-level settings from the peripheral port to which they are connected. In doing so, the DCI eases the device driver implementation.
The DCI consists of a dedicated, virtual register set that can be accessed remotely by read and write functions. The way registers can be accessed differs for each port.
![]() |
The DCI is supported by the USB Port (see Section 11.4.1 ) and the packet connection when connected with the SPI Port or the MediaLB Port (see Section 19.2.3 ).
Table 21-1 lists all common registers that can be read and/or written by the DCI.
See Availability |
|||
See PacketBW |
|||
See NodeAddress |
|||
See NodePosition |
|||
See PacketFilterMode |
|||
See PacketHash_15to0 |
|||
See PacketLLRTime |
|||
Bits are sticky and need to be written to ‘1’ to be cleared. |
Table 21-2 lists all USB registers that can be read and/or written by the DCI.
0x0001 = System configuration |
When read: Event flags, used to signal which property has changed. Can be polled to check for new events. When written: Clears event flags.
Used by the EHC to clear already processed event flags by writing a ‘1’ to the corresponding event flag. |
|||
Reports the current system configuration state. It will be ensured that no state change from OK to NotOK gets lost. |
||||
0x1100 |
Bits are sticky and need to be written to ‘1’ to be cleared. For DataType = Sync bit 0 signalizes either buffer underflow or buffer overflow. An underflow happens when data is transmitted to the network; it implies a non-continuous audio data stream on the network. An overflow happens when data is received from the network; it implies data loss. For DataType = AVPacketized bit 0 signalizes buffer overflow. |
|||
When written, the appropriate command will be executed. Sync request: Triggers the synchronization process needed for packet connections. See Section 19.4 for more information. |
||||
Denotes if the Endpoint is in use. |
||||
0xFFFF = Invalid |
Indicates the data type that is transfered via this Endpoint |
|||
Invalid: Indicates that no USB socket related to the given EndpointAddress was found. |
||||
0x1100 |
If DataType = Sync and the Endpoint used in a USB socket is connected with a MOST network socket, the value is the size of the MOST network socket. If the Endpoint is used in a USB socket that is connected to a splitter based on a MOST network socket, the value equals the size of the MOST network socket used with the splitter. If the Endpoint is connected to a combiner/splitter that is not based on a MOST socket, the value equals parameter BytesPerFrame of the combiner/splitter.
If
DataType
=
AVPacketized
, the value is the size of the transport stream packets. |
The access via USB is done through USB vendor requests. See Section 11.4 for more information.
If an EHC driver needs to be notified about changed register content, it may become necessary to poll the DCI periodically. To ease the polling mechanism, the INIC provides an ‘event flags’ register that can be used to retrieve information about the registers that have been updated. It is not mandatory to use the event flags. E.g., if the driver is only interested in a single register, it can periodically read this register and ignore the event flags.
Figure 21-2 describes the polling mechanism in detail.
![]() |
If the DCI is accessed using the packet connection, the INIC will send a register status message to the EHC device driver whenever a change in any parameter of the register status message occurs. To explicitly trigger the reception of the register status message, the command read registers can be send, see Section 19.2.3 . By using the command write register, any register content can be written.
FBlock NetBlock functions are implemented according to the definitions prescribed by the MOST Cooperation in the MOST FunctionBlock NetBlock, Rev. 3.0.3 [2] specification.
|
An overview of the NetBlock functions is shown in Table 22-1 .
This function inquires which function blocks are implemented within the device as well as the InstID of that function block. If the EHC is not attached, an empty list is returned from FBlock NetBlock. If the EHC is attached, the request is passed to the EHC.
List of FBlockID / InstID pairs for the FBlocks that are implemented in the device. When an EHC is attached, it must respond with a list of FBlockIDs with corresponding InstIDs that are available in the device. When no EHC is attached, FBlock NetBlock only responds with an empty list. When no EHC exists (both Configuration Interface and Application Interface are configured None ) , FBlock INIC and its InstID will be reported in the list. For all devices that contain an EHC, FBlocks INIC and NetBlock are generally not reported, since they will not appear in the central registry of the NetworkMaster.
This function obtains the node position address of a device. The node position address is determined by the node’s physical location in the MOST network, therefore this function is read only.
For details on parameter settings and the behavior of this parameter, refer to section Node Position Address. 0x0400 is reported, if MOST network is not available.
This function obtains the logical node address of the device.
For details on parameter settings and the behavior of this parameter, refer to section Node Address.
This function obtains the group address of a device.
For details on parameter settings and the behavior of this parameter, refer to section Group Address.
This function checks if a device is ready to shut down. If the application interface is in Protected Mode, the INIC does not suspend the NetBlock.ShutDown() procedure. If the application interface is in Attached Mode, the request is forwarded to the EHC.
This function returns fixed values for parameters RetryTime and RetryNumbers .
Control Low-Level Retries are used by the INIC when an error occurs during control message transmission over the MOST network. Retries are performed based on an optimized retry mechanism (see Section 18.1 ).
This function derives the 48-bit MAC address (also referred to as EUI-48) of an Ethernet network device.
EUI (Extended Unique Identifier) is a concatenation of a 24-bit OUI (Organizationally Unique Identifier) value and a 24-bit extension identifier.
This function identifies the version of the underlying MOST Specification, the NetBlock, and the MOST transceiver.
This function returns the result of the RBD test. It reports the status of the test and its diagnosis identifier via broadcast to the MOST network.
Status is activity, but no lock ( Pos0WeakSig ). |
|||
Status is no activity ( PosDetected ). |
Diagnostic identifier of the device. The length value should be large enough, so that the message can be sent as an unsegmented control message.
This parameter can be customized via the Configuration String.
This function administers the notification matrix of the function block INIC.
Determines where the entry in the notification matrix must be made or where the deletion has to occur.
List of functions with a maximum of four elements. This parameter is only required if Control is SetFunction or ClearFunction .
Besides the listed ErrorCode , ErrorInfo , a MOST application (see MOST Specification [1] ) may report specific errors during execution by using OPType Error as well. In this event, ErrorCode 0x20, function specific , is also used.
The functions in this section are used to handle device-relevant tasks, including the request of the revision information on the INIC’s hardware and firmware modules as well as the control of the power management behavior.
An overview of the INIC’s device management functions is shown in Table 22-2 .
This function reports several device properties. Its Status is sent to the EHC after the device has entered the Attached Mode.
This function supports notification.
The regular operation mode of the configuration interface is the Attached Mode. A mode change from Attached to Protected can happen in case of PMP channel synchronization loss, see Figure 3-5 .
At startup, the mode is set to Protected .
The application interface is in Attached Mode. A mode change from Attached to Protected can happen in case of PMP channel synchronization loss, see Figure 3-9 .
At startup, the mode is set to Protected .
State of PS0 and PS1 pins. For information on the power management refer to Chapter 4.0 .
Result of the Built-in Self-Test.
At startup, the mode is set to OK .
- an old boot-monitor was found, - a production string failure, |
|||
Shows the last reset reason of the device
Reset due to an internal reset request caused by function ExtendedNetworkControl.MemorySessionOpen() . |
|||
External RST pin is held low (see the INIC Hardware Data Sheet [4] ). |
This function contains information on the hardware and firmware modules of the INIC.
ProductIdentifier, MajorVersion,
MinorVersion, ReleaseVersion, |
|||
Build version number of the firmware. The number can be either a date code or the release build number.
Contains revision information. Information given within this stream is not used for validation purposes and should be seen only as additional information to the device’s version information.
{ ExtIdentifier, ExtMajorVersion, |
This function controls the PWROFF pin of the INIC. INIC.DevicePowerOff(PowerOff = True) may be triggered for instance when an INIC.DeviceStatus.Status(PowerState = ULow ) message is sent to the EHC, which drives the INIC’s PWROFF pin high. For normal operation, the EHC may call INIC.DevicePowerOff.SetGet(PowerOff = False) , which drives the PWROFF pin low.
|
This function is used by an EHC to attach to the INIC. If an INIC.DeviceAttach() command is sent to the INIC, the INIC’s notification service will be triggered for all properties that support notification, except INIC.GPIOTriggerEvent() . If it is desired to get notifications on INIC.GPIOTriggerEvent() , an INIC.Notification.Set(FktID = GPIOPortTriggerEvent) command must be sent explicitly.
A request will be blocked as long as INIC hasn’t finished a still running internal detach/cleanup process.
This function allows remote synchronization of devices that do not incorporate an EHC.
INIC.DeviceSync() must be called from MOST network side. In advance to the function call, it must be ensured that the settings in the configuration string support the command: Configuration Interface is None . Otherwise an error is returned.
For detailed information on how the command is used refer to Chapter 3.0 .
The functions in this section are used to handle network-relevant tasks, including the retrieval of network status and configuration information. It also provides the methods to startup and shutdown the MOST network as well as the capability to run the Ring Break Diagnosis.
An overview of the INIC’s MOST network management functions is summarized in Table 22-3 .
This function reports information on the whole MOST network, including MOST Supervisor states, system parameters and packet bandwidth.
This function supports notification.
Events, Availability, AvailabilityInfo, |
|||
The Events bit is related to the MOST network interface functionality. It is cleared once it was sent to all notified devices. A newly attached device gets a cleared Events field.
Indicates if the MOST network is available
Indicates the sub states of parameter Availability
Network is in NetInterface Off or Init state. It is pending to become available again. If AvailabilityTransitionCause is ErrorSystem , the error condition may be freed first, before the network can be started. |
|||
- INIC enters this state when RBD is started. It stays in this state until diagnosis is finished. After RBD is finished,
INIC.MOSTNetworkRBD.Result()
is returned, containing the result of the RBD. - INIC enters this state after starting the ExtendedNetworkControl.PhysicalLayerTest() , system diagnosis or device diagnosis. |
|||
INIC was forced to enter NotAvailable state. |
Indicates the transition cause of the MOST network going from NotAvailable to Available or vice versa. This parameter behaves like an event. Once reported, it is cleared to NoTransition . A new attached device will also see NoTransition , which implies that AvailabilityTransitionCause is not remembered from the past, e.g., after a device went through Protected Mode.
Startup is initiated by chip e.g., INIC.MOSTNetworkStartup() , MOSTNetworkStartup (0x524). |
||||
- Network is shutdown standardly by an INIC.MOSTNetworkShutdown() command (MOSTNetworkShutdown (0x525)), initiated locally or by a node positioned upstream (in the latter case, the shutdown flag indicates a Normal Shutdown). |
||||
Network is shut down due to an error. |
||||
Network is shut down due to an error. |
||||
Network is shut down due to a chip or system error. - INIC enters ForcedNA state. |
||||
For details on parameter settings and the behavior of this parameter, refer to section Node Address.
Current valid NodePosition if network is available. Zero is reported for a TimingMaster device. 0xFF is reported if the MOST network is not available.
Current number of nodes in the MOST network if network is available. Value is updated with the Network Change Event. 0xFF is reported if the MOST network is not available.
Current size of packet bandwidth while the MOST network is available, see the INIC Hardware Data Sheet [4] . 0xFFFF is reported if the MOST network is not available.
This function covers general MOST network-related configuration settings as well as packet and control data-related settings. Packet-related parameters can be modified by setting the appropriate bits inside the Mask parameter. Parameter PacketFilterMode enables various options for the destination address match logic for MOST Ethernet Packets (MEP). The packet hash parameters access the 64-bit hash table to allow reception of multi-cast Ethernet frames.
Changes a single, multiple or all parameters in one SetGet operation. Parameters which are not being set are transmitted as dummy values; they are not decoded by INIC.
The mask bits can either be set to 0 or 1 and behave as follows:
0: The parameter is not considered in the operation.
1: The parameter is considered in the operation.
NodeAddress
of the device. If the
NodeAddress
is set in the dynamic range (0x0100...0x013F), parameter
NodeAddress
in the Status message will return 0xFFFF. Values 0x0F00...0x0FEF, 0x0FFE and 0xFFFF cannot be set.
The actual
NodeAddress
is retrieved by function
INIC.MOSTNetworkStatus()
.
For details on parameter settings and the behavior of this parameter, refer to section Node Address.
This parameter can be customized via the Identification String.
For details on parameter settings and the behavior of this parameter, refer to section Group Address.
This parameter can be customized via the Identification String.
Defines the block count for control Low-Level Retries for all messages generated by the INIC itself. For more information refer to Section 18.1 .
This parameter can be customized via the Configuration String.
Determines the mode of the address match filter for MOST Ethernet Packets
1: Filter is inverted, i.e., all single- and multi-cast addresses that do not match the filter (broadcast addresses are not influenced) |
||
Defines bits 47:32 of the EUI-48.
This parameter can be customized via the Identification String.
Defines bits 31:16 of the EUI-48.
This parameter can be customized via the Identification String.
Defines bits 15:0 of the EUI-48.
This parameter can be customized via the Identification String.
Wait time between Low-Level Retries for data packets in number of MOST network frames.
A change of the Node Address is not allowed; either the device is in - System Mode UNICENS , |
|||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
This function is used to synchronize clocks on a MOST network frame basis.
The frame counter is automatically enabled at network startup. The counter cannot be disabled; it is always active, independent of the NetInterface state or the INIC’s device mode.
This function initializes the NetInterface, thus waking up the MOST network. The waking device always operates as TimingMaster.
If Available state is reached, the result is reported.
If INIC.MOSTNetworkStartup() is initiated in NET_OFF before either timer t Restart or timers t SSO_ShutDown + t Restart (timers are started in NET_OFF ) have timed out, the startup request will be postponed chip-internal and executed when the timer(s) have timed out. If INIC enters Protected Mode when a startup is pending, the startup process will be canceled automatically by INIC.
Determines the delay for network shut down after the INIC has entered Protected Mode. The INIC does not shut down the Network, if this value is set to 65535 ms.
After the timer is expired, state INIC.MOSTNetworkForceNotAvailable.Status(Force = True) is entered. The state can be left by calling INIC.MOSTNetworkForceNotAvailable.SetGet(Force = False) .
Packet data bandwidth on the MOST network configured by a TimingMaster device. The applied value is reported with INIC.MOSTNetworkStatus() , see page 141 .
Note: This parameter is chip-specific.
For the maximum value refer to Chip_Bandwidth_MaxValue.
- The last INIC.MOSTNetworkStartup() call has not yet been finished. |
|||
- physical layer test is running, or - ForcedNA was set, or |
|||
Available state cannot be reached, since - INIC.MOSTNetworkShutdown() is called, or - physical layer test is started, or - ForcedNA is set, or |
|||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
|||
Calling INIC.MOSTNetworkStartup() is not possible in Available state. |
This function shuts down the NetInterface. Once the NetInterface is in NetInterface Off state, the signal at the output turns off causing a chain reaction, shutting down all the devices in the MOST network. Typically, only the PowerMaster may switch off the signal, except during special error cases (see MOST Specification [1] ). The result will be sent after t Restart or timers t SSO_ShutDown + t Restart have expired. If the network is already in NetInterface Off state and t Restart is elapsed, the result is returned immediately without an error.
The INIC enters NetInterface Off state automatically, when no network signal is present at its input.
The last INIC.MOSTNetworkShutdown() call has not yet been finished. |
|||
- physical layer test is running, or - ForcedNA was set, or |
|||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
|||
This function starts the Ring Break Diagnosis. The INIC.MOSTNetworkStatus() function indicates the MOST network is in NotAvailable state and AvailabilityInfo Diagnosis has been entered. After RBD has been finished, the result is reported via function INIC.MOSTNetworkRBDResult() , see Section 22.2.3.6 . After RBD is finished, the INIC enters NetInterface Off state.
The last INIC.MOSTNetworkRBD() call has not yet been finished. |
|||
RBD is active because it was triggered by PS0 and PS1 pins or it was started previous to DeviceAttach. |
|||
- Physical layer test is running or - ForcedNA was set. |
|||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
|||
- The MOST Port is configured in full duplex coax mode. - RBD is triggered, but either the MOST Port in function INIC.MOSTPortUsed() was set to Used = False or Port Mode in the configuration string was set to Unused . |
This function contains the result of the Ring Break Diagnosis. The RBD can be started by PS0 and PS1 pins or by method INIC.MOSTNetworkRBD() , see Section 22.2.3.6 . If the method has been started, the results of the ring break can be inquired by using this function.
Relative position to the ring break. This parameter is only used for RBDResult PosDetected ; for all others 0 is returned.
Status of the RBD result after the ring break. The status is received via the NetBlock.RBDResult() message, distributed in Phase 3 of the Ring Break Diagnosis. 0xFF is reported when the message was not received.
Status is activity, but no lock ( Pos0WeakSig ). |
|||
Status is no activity ( PosDetected ). |
|||
This function controls the behavior of the MOST network interface. INIC.MOSTNetworkForceNotAvailable.SetGet(Force = True) may be triggered for instance when an INIC.DeviceStatus.Status(PowerState = ULow ) message is sent to the EHC. If Force is set to True , Availability in INIC.MOSTNetworkStatus() is set to NotAvailable , AvailabilityInfo is set to ForcedNA and AvailabilityTransitionCause is set to ErrorSystem . For normal operation, the EHC may call INIC.MOSTNetworkForceNotAvailable.SetGet(Force = False) .
|
Used to force the INIC to enter network NotAvailable state
INIC is forced to network NotAvailable state (static Tx-Off). |
This function is used to start the system diagnosis.
This function is used to end the system diagnosis.
Note: Availability of resource objects is chip-specific, see Section 2.2 .
The functions in this section are used to handle the behavior of a MOST Port, including the return of the port status, and the creation of a MOST socket. Furthermore, the functions are used to define all parameters that are required to enable data transfer over a port and its sockets.
A MOST Port is in direct relation to the MOST network management.
To get more information on the MOST Port, refer to Chapter 8.0 .
An overview of the INIC’s MOST Port functions is shown in Table 22-4 .
This function reports streaming-related information for a MOST Port, including the state of the port and available streaming bandwidth.
This function supports notification.
MOSTPortHandle, Availability, |
|||
Port resource handle. Valid value is a combination of resource identifier and index (yy).
0x0D yy |
Indicates if the MOST Port is available and ready for streaming data connections
MOST Port is not available for streaming data. FreeStreamingBW is set to 0xFFFF. All created sockets on this port become invalid. |
|||
MOST Port is available and it is possible to have streaming data connections. |
Indicates the sub states of parameter Availability
The MOST Port is not available for streaming data. This is for instance the case if the MOST network is shut down or Ring Break Diagnosis is running. |
|||
Specifies the number of free streaming bandwidth for a MOST Port, see also the INIC Hardware Data Sheet [4] . 0xFFFF is reported if the MOST Port is not available.
Note: Availability of resource objects is chip-specific, see
Section 2.2
.
For details refer to Chip_NumberOfMOSTPorts.
This function sets a MOST Port to used or unused for INICs that provide more than one MOST Port.
Port resource handle. Valid value is a combination of resource identifier and index (yy).
0x0D yy |
Indicates if the MOST Port is used or unused
MOST Port is unused. |
|||
If the MOST network is not available, AvailabilityInfo in
INIC.MOSTPortStatus()
is
Regular
. |
- The MOST Port cannot be set to Used = True , since it was set to Unused in the configuration string. - INIC.MOSTPortUsed() is called and either RBD is active or system diagnosis is running. |
|||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
This function creates a MOST socket bound to the MOST Port.
MOSTPortHandle, Direction, |
|||
Port resource handle. Valid value is a combination of resource identifier and index (yy).
Note: This parameter is chip-specific.
For details refer to
Chip_MOSTPortIndex.
0x0D yy |
Note: This parameter is chip-specific.
For details refer to
Chip_DataType.
Specifies the A/V Packetized Isochronous Streaming data type |
|||
Specifies the DiscreteFrame Isochronous Streaming data type, phase information |
Required socket bandwidth in bytes. Maximum value depends on currently free network resources.
Note: This parameter is chip-specific.
For details refer to
Chip_Bandwidth_MaxValue and Chip_DataType.
For calculating the required bandwidth refer to Equation 20-3 . |
|||||
MOST network connection label. When used as parameter with direction Input , the connection label is used to connect to the appropriate MOST network frame bytes. When used as parameter with direction Output , the connection label is not used and must be set to 0xFFFF.
When ConnectionLabel is used as Result, it specifies the MOST network connection label.
Note: This parameter is chip-specific.
For details refer to
Chip_MOSTPortIndex.
Socket resource handle of the created socket. Valid value is a combination of resource identifier and index (yy).
0x0E yy |
The last INIC.MOSTSocketCreate() call has not yet been finished. |
|||
A communication error has occurred, for example: the operation was interrupted by network disturbance. The EHC may try to create the socket again. It should wait at least 20 ms before retrying during normal network conditions or otherwise wait until stable network lock has been re-gained. |
|||
A socket of direction Input was requested to be created, and - there is no network channel available that matches the provided ConnectionLabel , or - there was already an Input socket created with the provided ConnectionLabel , or - an Output socket was found that is not a loop socket, or - the provided channel size mismatches with the actual size of the network channel, or |
|||
- A socket of direction Output was requested to be created, but the used ConnectionLabel is not 0xFFFF. - A socket of direction Input was requested to be created, but the used ConnectionLabel is 0xFFFF. |
|||
Parameter Bandwidth is invalid for the data type DiscFramePhase , or Bandwidth does not match the loop socket. |
|||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
|||
The MOST network is in NotAvailable state. |
|||
A socket of direction Output was requested to be created, and - there is not enough free bandwidth on the MOST network available to complete the allocation request or |
|||
The socket cannot be created, since there is no socket entry possible. |
Note: Availability of resource objects is chip-specific, see Section 2.2 .
The functions in this section are used to handle the behavior of the MediaLB Port, including the creation of the port and a socket on it. Furthermore, the functions are used to define all parameters that are required to enable data transfer over the port and its sockets.
To get more information on the MediaLB Port, refer to Chapter 9.0 .
An overview of the INIC’s MediaLB Port functions is shown in Table 22-5 .
Note: Availability of resource objects is chip-specific, see
Section 2.2
.
For details refer to
Chip_NumberOfMediaLBPorts.
This function creates the MediaLB Port with its associated port instance identifier.
If the MediaLB Port has been already created, an error message will be returned.
A MediaLB Port can be created when INIC starts up. In this case, the appropriate settings need to be written to the Configuration String. If the MediaLB Port is created at startup, it cannot be destroyed during runtime. It remains created when EHC re-attaches, since the port is part of the INIC’s default configuration.
If a MediaLB Port is created during runtime using INIC.MediaLBPortCreate() , it will be automatically destroyed when EHC detaches.
Stores the clock speed configuration. The value is a multiple of the MOST network frame rate Fs; this means the MediaLB Port can only be frequency locked to the network’s system clock.
This parameter can be customized via the Configuration String.
Note: This parameter is chip-specific.
For details refer to
Chip_MediaLBPinModes and
Table 9-1
.
Port resource handle. Valid value is a combination of resource identifier and index (yy).
0x0A yy |
Note: Availability of resource objects is chip-specific, see
Section 2.2
.
For details refer to
Chip_NumberOfMediaLBPorts.
This function creates a MediaLB socket bound to the MediaLB Port with the associated port instance identifier. If the EHC detaches, the MediaLB socket will be automatically destroyed.
Flow control is always disabled for data type Sync .
For all other data types, flow control is enabled when data is sent from the EHC to the INIC. Consequently, the INIC drives the RxStatus field to signal the EHC if it is ready to receive data (ReceiverReady) or if it is busy (ReceiverBusy). If data is sent from INIC to EHC, flow control is only enabled for Control and Packet data types. The INIC receives the RxStatus from the EHC and if the EHC signals ReceiverBusy, the INIC retransmits the last quadlet until the RxStatus changes.
Port resource handle. Valid value is a combination of resource identifier and index (yy).
Note: This parameter is chip-specific.
For details refer to
Chip_NumberOfMediaLBPorts.
0x0A yy |
Note: This parameter is chip-specific.
For details refer to
Chip_DataType.
Specifies the A/V Packetized Isochronous Streaming data type |
|||
Specifies the DiscreteFrame Isochronous Streaming data type, phase information |
Required socket bandwidth in bytes. As stated in Table 9-1 , the maximum socket bandwidth value is dependent on ClockConfig and ChannelAddress. The value is also dependent on the used DataType , therefore consider the following limitations:
Indicates the MediaLB ChannelAddress to which the socket is mapped. As stated in
Table 9-1
, the maximum channel address value is dependent on the ClockConfig and the ChannelAddress.
If the MediaLB Port is configured by the configuration string property Configuration Interface as default, channel addresses 0x0002 and 0x0004 are reserved and cannot be used.
Socket resource handle of the created socket. Valid value is a combination of resource identifier and index (yy).
0x0B yy |
Parameter ChannelAddress does not fit the range specified for the used MediaLB pin mode. |
|||
Parameter Bandwidth is invalid for the given data type. |
|||
Parameter ChannelAddress is already in use. |
|||
The port associated with the given MediaLBPortHandle was not created. |
|||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
|||
The MediaLB socket cannot be created, since there is no further socket entry possible. |
Note: Availability of resource objects is chip-specific, see
Section 2.2
.
For details refer to
Chip_NumberOfMediaLBPorts.
This function is used to enable the multiplexing feature.
Port resource handle. Valid value is a combination of resource identifier and index (yy).
Note: This parameter is chip-specific.
For details refer to
Chip_NumberOfMediaLBPorts.
0x0B yy |
- The generated multiplex channel address is already in use, or - the socket provided is already used in a multiplex configuration, or - the socket provided is already attached to the packet connection. |
|||
The socket associated with the given MediaLBSocketHandle was not created or the resource at the index does not match the specified resource type. |
|||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
|||
The MediaLB socket cannot be created, since there is no further socket entry possible. |
The functions in this section are used to handle the behavior of the SPI Port, including the creation of the port and the sockets on it. Furthermore, the functions are used to define all parameters that are required to enable data transfer over the port and its sockets.
To get more information on the SPI Port, refer to Chapter 10.0 .
An overview of the INIC’s SPI Port functions is shown in Table 22-6 .
This function creates the SPI Port with its associated port instance identifier.
If the SPI Port has been already created, an error message will be returned.
An SPI Port can be created when INIC starts up. In this case, the appropriate settings need to be written to the Configuration String. If the port was created at startup, it cannot be destroyed during runtime. It will also remain created when EHC re-attaches, since the port is part of the INIC’s default configuration.
If an SPI Port is created during runtime using INIC.SPIPortCreate() function, it will be automatically destroyed when EHC re-attaches.
Indicates the configuration of the phase and polarity of the SCLK signal.
This parameter can be customized via the Configuration String.
Port resource handle. Valid value is a combination of resource identifier and index (yy).
0x10 yy |
This function creates an SPI socket bound to the SPI Port with its associated port instance identifier. If EHC detaches, the SPI socket will be automatically destroyed.
Port resource handle. Valid value is a combination of resource identifier and index (yy).
0x10 yy |
Socket resource handle of the created socket. Valid value is a combination of resource identifier and index (yy).
0x11 yy |
The port associated with the given SPISocketHandle was not created. |
|||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
|||
The SPI socket cannot be created, since there is no socket entry possible. |
Note: Availability of resource objects is chip-specific, see Section 2.2 .
The functions in this section are used to handle the behavior of the USB Port, including the creation of the port and a socket on it. Furthermore, the functions are used to define all parameters that are required to enable data transfer over the port and its sockets.
To get more information on the USB Port, refer to Chapter 11.0 .
An overview of the INIC’s USB Port functions is shown in Table 22-7 .
Note: Availability of resource objects is chip-specific, see
Section 2.2
.
For details refer to
Chip_NumberOfUSBPorts
.
This function creates the USB Port with its associated port instance identifier.
If the USB Port has been already created, an error message will be returned.
Consider that a previously created port is not automatically destroyed by the INIC when doing another call to INIC.USBPortCreate() .
Selects the interface of the USB Port’s physical layer.
This parameter can be customized via the Configuration String.
Activates one or more of the USB device interfaces provided by the INIC.
|
1: Activates the control interface with Endpoints 0x0F (OUT) and 0x8F (IN) (default) |
||
1: Activates the packet interface with Endpoints 0x0E (OUT) and 0x8E (IN) |
||
1: Acitivates the streaming interface (default), count of OUT and IN Endpoints depends on parameters StreamingIfEpOutCount and StreamingIfEpInCount |
Defines the number of OUT Endpoints inside the streaming interface, starting with Endpoint 0x01. This value must be zero if the streaming interface is disabled.
This parameter can be customized via the Configuration String.
Defines the number of IN Endpoints inside the streaming interface, starting with Endpoint 0x81. This value must be zero if the streaming interface is disabled.
This parameter can be customized via the Configuration String.
Port resource handle. Valid value is a combination of resource identifier and index (yy).
0x12 yy |
Parameter values for
StreamingIfEpOutCount
or |
|||
EnableStreamingIf is disabled and the parameter values for StreamingIfEpOutCount and StreamingIfEpInCount have not been set to zero. |
|||
EnableStreamingIf is enabled and the parameter values for StreamingIfEpOutCount and StreamingIfEpInCount are set to zero. |
|||
The USB PhysicalLayer interface does not correspond with the initially selected one. |
|||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
Note: Availability of resource objects is chip-specific, see
Section 2.2
.
For details refer to
Chip_NumberOfUSBPorts
.
This function creates a USB socket bound to the USB Port with its associated port instance identifier. If the EHC detaches, the USB socket will be automatically destroyed.
USBPortHandle, Direction, DataType, EndpointAddress, |
|||
Port resource handle. Valid value is a combination of resource identifier and index (yy).
0x12 yy |
Specifies the address of a USB Endpoint as per its description in the USB 2.0 Specification [5] .
0x01...0x0F: Indicates the OUT Endpoints
0x81...0x8F: Indicates the IN Endpoints
|
Indicates the number of MOST network frames/packets per one USB transaction
Number of MOST network frames from which the synchronous data bytes are put and filled-in into one USB transaction. For more information refer to
Section 11.3.1
. |
|||||
Two A/V Packetized Isochronous Streaming data packets per USB transaction. For more information refer to
Section 11.3.2
. |
|||||
USB transaction is completely filled with A/V Packetized Isochronous Streaming data. |
|||||
Socket resource handle of the created socket. Valid value is a combination of resource identifier and index (yy).
0x13 yy |
The value in FramesPerTransaction does not match the data type. |
|||
The USB Endpoint does not match the socket’s direction setting. |
|||
The port associated with the given USBPortHandle was not created. |
|||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
|||
The USB socket cannot be created, since there is no socket entry possible. |
The functions in this section are used to handle the behavior of the Streaming Port, including the creation of the port and a socket on it. Furthermore, the functions are used to define all parameters that are required to enable data transfer over the port and its sockets. In addition the configuration of an internal loopback is provided.
To get more information on the Streaming Port, refer to Chapter 12.0 .
An overview of the Streaming Port functions is shown in Table 22-8 .
Streaming Ports can be configured either by using this function or by customizing the Configuration String. When using this function, the configuration is cleared on an EHC detach event. If the configuration is done by the configuration string, the setting will be persistent.
|
Since Streaming Port B has no external clock signals, the configuration of Streaming Port B is slightly different from that of Streaming Port A. Therefore, when assigning a configuration, some parameter values do not apply and wildcard values have to be used instead. If the configuration has not been set and INIC.StreamPortConfiguration.Get() is called, an error code is returned; an error code is also returned if the configuration has already been set and INIC.StreamPortConfiguration.SetGet() is called again.
Defines the operation mode of the Streaming Port.
This parameter can be customized via the Configuration String.
If Index is PortB , data pins are linked to PortA clock configuration. |
Configures the direction of the physical pins of the indexed Streaming Port.
This parameter can be customized via the Configuration String.
Two serial interface pins are available; one for direction IN (Streaming Port A: SRA0 , Streaming Port B: SRB0 ) and one for direction OUT (Streaming Port A: SXA1 , Streaming Port B: SXB1 ). |
|||
Indicates if FSY / SCK signals are configured as outputs or inputs. FSY / SCK signals are shared between all pins used for Generic streaming, including any linked pins to Streaming Port B.
This setting is only applicable to data pins used for Generic streaming including any linked pins to Streaming Port B. All data pins share the same FSY / SCK signals, hence this setting applies to all data pins.
There is a single SCK clock delay between the start of frame (falling edge of FSY ) and the start of the frame data on the data pins. |
|||
The wrong ClockMode parameter is used. |
|||
The wrong ClockDataDelay parameter is used. |
|||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
This function creates the Streaming Port with its associated port instance identifier.
If a Streaming Port is created during runtime using INIC.StreamPortCreate() , it will be automatically destroyed when EHC detaches.
Clock speed configuration of the SCK signal. Fs should be seen as an umbrella term referring to F Network , which is the MOST network sampling frequency used for the synchronous mode.
When creating the Streaming Port B resource, the Wildcard value should always be used for this parameter.
Defines the alignment of the data bytes within the streaming port frame. While ClockDataDelay is set to Delayed , only left-justified or sequential formats are available.
Port resource handle. Valid value is a combination of resource identifier and index (yy).
0x16 yy |
The wrong ClockConfig parameter is used. |
|||
The wrong DataAlignment parameter is used. |
|||
Streaming Port A and B are configured as linked, however Streaming Port A has not been created. |
|||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
This function enables an internal loopback on a Streaming Port: data of an output pin is internally looped back to an input pin. Loopback is only applicable if the port is configured for Generic streaming.
This function can be used for delay measurements in microphone array applications. When loopback is enabled, the output pin may be muted after the loopback, such that the delay measurement does not disturb external logic.
Port resource handle. Valid value is a combination of resource identifier and index (yy).
0x16 yy |
Enables or disables data on the output pin. This setting is only applicable if LoopbackMode is enabled. It is possible to alter the output mode by using INIC.StreamPortLoopback.SetGet() , with parameter LoopbackMode set to LoopbackEnabled , and providing different values to this parameter.
The wrong PinPair parameter is used. |
|||
The port associated with the given StreamPortHandle was not created. |
|||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
This function creates a Synchronous socket bound to the Streaming Port with the specified port instance identifier. If INIC enters Protected Mode, the socket will be automatically destroyed.
StreamPortHandle, Direction, |
|||
Port resource handle. Valid value is a combination of resource identifier and index (yy).
0x16 yy |
Required socket bandwidth in bytes
When used with 64Fs (0x03) or higher, and Left16Bit or Right16Bit data alignment, this size corresponds to a mono 16-bit channel that will be routed as left channel data. |
|||||
When used with 64Fs (0x03) or higher, and Left24Bit or Right24Bit data alignment, this size corresponds to a mono 24-bit channel that will be routed as left channel data. |
|||||
When used with 64Fs (0x03) or higher, and Left16Bit or Right16Bit data alignment, this size corresponds to a stereo 16-bit channel. |
|||||
When used with 64Fs (0x03) or higher, and Left24Bit or Right24Bit data alignment, this size corresponds to a stereo 24-bit channel. |
|||||
Variable size when used with 64Fs (0x03) and sequential data alignment. |
|||||
Variable size when used with 128Fs (0x04) and sequential data alignment. |
|||||
Variable size when used with 256Fs (0x05) and sequential data alignment. |
|||||
Variable size when used with 512Fs (0x06) and sequential data alignment. |
ID of the serial interface pin of the addressed Streaming Port instance to which the socket should be attached
Socket resource handle of the created socket. Valid value is a combination of resource identifier and index (yy).
0x17 yy |
The wrong Bandwidth parameter is used. |
|||
The wrong StreamPinID parameter is used for a Sync connection. |
|||
The wrong Direction parameter is used. |
|||
Parameter StreamPinID is already in use by a socket. |
|||
The port associated with the given StreamPortHandle was not created. |
|||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
|||
The Streaming Port socket cannot be created, since there is no socket entry possible. |
The function below is used to create an RMCK Port and to define the settings of it.
To get more information on the RMCK Port, refer to
Chapter 13.0
.
This function creates an RMCK Port with its associated port instance identifier.
If an RMCK Port is created during runtime using INIC.RMCKPortCreate() , it will be automatically destroyed when the EHC detaches.
Divisor of the clock source. Validity of the divisor depends on parameter ClockSource . The frequency of the clock source is divided by the Divisor to give the output frequency. An even Divisor gives a 50/50 duty cycle; an odd Divisor has a duty cycle of 1/ Divisor high and the rest low (for example a Divisor of 3 will have a duty cycle of 1/3 high and 2/3 low).
This parameter can be customized via the Configuration String.
Port resource handle. Valid value is a combination of resource identifier and index (yy).
0x1A yy |
The functions in this section are used to handle the behavior of the I 2 C Port, including the creation and configuration of the hardware port.
To get more information on the I 2 C Port, refer to Chapter 14.0 .
An overview of the I 2 C Port functions is shown in Table 22-9 .
This function is used to define the I 2 C Port working as I 2 C-bus master. The function creates the I 2 C Port with its associated port instance identifier.
If the I 2 C Port has been already created, an error message will be returned.
An I 2 C Port can be created when INIC starts up. In this case, the appropriate settings need to be written to the Configuration String. If the port was created at startup, it cannot be destroyed during runtime. It will also remain created when EHC re-attaches, since the port is part of the INIC’s default configuration.
If an I 2 C Port is created during runtime using the INIC.I2CPortCreate() function, it will be automatically destroyed when EHC re-attaches.
Specifies the 7-bit I 2 C Port slave address. This parameter is ignored in OperationMode Master .
Port resource handle. Valid value is a combination of resource identifier and index (yy).
0x0F yy |
This function reads a block of bytes from an I 2 C device at a specified I 2 C address.
Port resource handle. Valid value is a combination of resource identifier and index (yy).
0x0F yy |
This function writes a block of bytes to an I 2 C device at a specified I 2 C address. The function supports also a burst write mechanism for optimized transactions.
Port resource handle. Valid value is a combination of resource identifier and index (yy).
0x0F yy |
Specifies the write transfer mode
Repeated start mode is disabled. After transaction of the DataList a STOP condition is issued and the bus is released. This is the default operation mode. |
|||
Repeated start mode is enabled. After transaction of the DataList the STOP condition will be suppressed and the controlling application is able to initiate further read or write sequences. |
|||
Burst mode is enabled. This mode supports writing multiple blocks of bytes of the same size to the specified I 2 C address. |
Specifies the number of blocks to be written to the I 2 C address. If parameter Mode is not set to BurstMode, the value of BlockCount has to be set to 0. Otherwise the valid range for this parameter is from 1 to 30.
Number of bytes to be written to the I 2 C address. If parameter Mode is set to BurstMode, the valid range of this parameter goes from 1 to 30, since the maximum overall length for a burst transfer is limited to a size of 30 bytes ( BlockCount x Length ). For all other modes, the full range is applicable.
A timeout has been detected. Pending transfers will be canceled and terminated by a STOP condition. It should be considered to reset the slave device. |
|||
The wrong Mode or BlockCount value was chosen. |
|||
The maximum burst size value ( Length x BlockCount) was exceeded or the DataList does not match the product of Length and BlockCount . |
|||
The functions in this section are used to handle the behavior of the GPIO Port, including the creation and the configuration of the port.
To get more information on the GPIO Port, refer to Chapter 15.0 .
An overview of the GPIO Port functions is shown in Table 22-10 .
This function creates the GPIO Port with its associated port instance identifier.
If the GPIO Port has been already created, an error message will be returned.
Specifies the timeout for the GPIO debounce timer (in ms). Each pin is debounced with its own timer that starts to count on every pin event. The pin is debounced, when the signal stays stable for DebounceTime . Since the debounce timer is a software implemented timer, the debounce value may jitter to higher values than the DebounceTime . Note, the INIC needs some additional time to send the notification.
Port resource handle. Valid value is a combination of resource identifier and index (yy).
0x1D yy |
This function is used for GPIO pin configuration.
Port resource handle. Valid value is a combination of resource identifier and index (yy).
0x1D yy |
Defines the GPIO pin configuration and clears the trigger conditions on level-sensitive inputs and sticky inputs thereby allowing reporting of further trigger events. Note that trigger conditions are automatically cleared for all edge-sensitive input/output GPIO classes when the INIC.GPIOPortTriggerEvent.Status message is sent.
Defines the mode of the GPIO pin. Configuring an unused pin as GPIO may preclude the usage of special functions bound to this pin. For example, configuration of GP0 as a GPIO excludes the use of I 2 C in parallel.
The value Unavailable is not allowed to be used in combination with OpType SetGet. OpType Status returns Unavailable for pins that are not configurable as GPIO, since the pin is used in its special function, e.g., I 2 C for GP0 .
The value Unused in OpType Status indicates that the pin is neither used as GPIO pin nor in its special function mode. The value can be used in OpType SetGet to reset a GPIO pin, then the pin is without configuration.
When configuring the debounced edge trigger modes, the debounce logic must detect a stable debounced level before the first edge is notified. Debounce level is low for rising edge triggers and high for falling edge triggers. The detection of debounced values starts always with the configuration of the pin.
Sticky pin modes are capable to detect brief pulses using a dedicated hardware mechanism, see the INIC Hardware Data Sheet
[4]
. The dedicated hardware mechanism is also used to detect level triggers for input pins.
The used
Pin
or
Mode
value is out of range. |
||||
The used pin is not available for GPIO usage. |
||||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
This function is used for GPIO pin state configuration.
Port resource handle. Valid value is a combination of resource identifier and index (yy).
0x1D yy |
Specifies the GPIO pin to be written. For pins not configured as GPIO, the value is ignored. For the configuration of the GPIO pins refer to the INIC Hardware Data Sheet [4] .
Specifies the state of the GPIO pin to be written. For pins not configured as GPIO, the value is ignored. For the configuration of the GPIO pins refer to the INIC Hardware Data Sheet [4] .
Specifies the current state of the GPIO pin. For pins not configured as GPIO, the value is always set to False.
This function notifies controllers of trigger events detected on GPIO pins, on which an event trigger has been configured using INIC.GPIOPinMode.Set . In addition, the function is used to re-enable (via INIC.GPIOPinMode.Set ) the reporting of subsequent trigger events for level-sensitive inputs and sticky inputs.
This function supports notification.
Port resource handle. Valid value is a combination of resource identifier and index (yy).
0x1D yy |
||||
Specifies the GPIO pins on which a rising-edge trigger condition was detected by rising edge or dual edge detection logic. Detection logic is specified by the Mode parameter of INIC.GPIOPinMode.SetGet . If a rising edge has been detected for a given pin, the bit is set. A clear bit indicates that no rising edge was detected or that rising edge/dual edge detection logic is not enabled.
Specifies the GPIO pins on which a falling-edge trigger condition was detected by falling edge or dual edge detection logic. Detection logic is specified by the Mode parameter of INIC.GPIOPinMode.SetGet . If a falling edge has been detected for a given pin, the bit is set. A clear bit indicates that no falling edge was detected or that falling edge/dual edge detection logic is not enabled.
Specifies the GPIO pins on which a logic level condition was detected by level detection logic. The levels apply to high-level as well as to low-level detection. If high-level detection logic is enabled, high levels are indicated by a set bit, if low-level detection logic is enabled, low levels are indicated by a set bit. A clear bit indicates that no level was detected or that level detection logic is not enabled.
Detection logic is specified by the Mode parameter of INIC.GPIOPinMode.SetGet .
The functions in this section are used to handle resource management relevant tasks, these are tasks that are related to a resource object, e.g., a port, a socket, or a connection.
To get more information on the resource management, refer to Chapter 7.0 .
An overview of the INIC’s resource management functions is shown in Table 22-11 .
This function destroys the resource associated with the given resource handle. A resource is either a port, a socket, or a connection. For more information on destroying resources, refer to Section 7.3 .
ResourceHandle , { ResourceHandle } |
The last INIC.ResourceDestroy() call has not yet been finished. |
||||
The message length is wrong (must be a multiple of two bytes). |
||||
There are too many elements in parameter ResourceHandleList . |
||||
The handle currently being processed was not found or cannot be destroyed, because it is persistent. |
||||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
||||
Resource dependency violation. There are still resources remaining that have a dependency on the resource that was requested to be destroyed: - A connection still uses the socket, combiner, or splitter resource. - A combiner or splitter still uses the socket resource. - A socket still uses the port resource. - Streaming Port A and B are configured as linked. Streaming Port A was requested to be destroyed before Streaming Port B was destroyed. - A MediaLB packet multiplex socket still uses the socket resource. |
This function is used to get resources that were marked as invalid by the INIC.
The returned list always contains the currently invalid handles, sorted in the order they must be destroyed. If there are more handles as that can fit into one message, the preceding handles must be destroyed to get the remaining handles and to reach the END identifier.
For more information on how invalid resources are reported, refer to Chapter 7.0 .
This function notifies the state of the resource monitor in the INIC. The Status is only sent via notification; it notifies when the EHC must perform some actions and when it has returned to its default state. The Set operation is used to reset the resource monitor back to its default state.
This function supports notification.
Used to reset the resource monitor to its default state and release the MUTE pin. This will always trigger a notification.
Requests the resource monitor to go back to the OK state and release the MUTE pin |
Note: Availability of resource objects is chip-specific, see Section 2.2 .
The functions in this section are used to setup packet connections for different data types.
To get more information on packet connections, refer to Chapter 19.0 .
An overview of the packet connection functions is shown in Table 22-12 .
Note: Availability of resource objects is chip-specific, see Section 2.2 .
This function attaches the given peripheral sockets to the packet data connection.
Packet resource handle. Valid value is a combination of resource identifier and index (yy).
0x01 yy |
The resource handle of the Input socket that is attached to the packet connection. Valid value is a combination of resource identifier and index (yy).
Note: This parameter is chip-specific.
For details refer to
Port-Related Information.
MediaLB socket: 0x0B yy |
||||
SPI socket: 0x11 yy |
||||
USB socket: 0x13 yy |
The resource handle of the Output socket that is attached to the packet connection. Valid value is a combination of resource identifier and index (yy).
Note: This parameter is chip-specific.
For details refer to
Port-Related Information.
MediaLB socket: 0x0B yy |
||||
SPI socket: 0x11 yy |
||||
USB socket: 0x13 yy |
Parameter SocketHandleIn is invalid. This error can be returned for several reasons: - the socket is not of direction Input , or |
|||
Parameter SocketHandleOut is invalid. This error can be returned for several reasons: - the socket is not of direction Output , or |
|||
Resource type of SocketHandleIn and SocketHandleOut is different. |
|||
Parameter SocketHandleIn or SocketHandleOut indicates a resource that does not exist. |
|||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
This function detaches the given peripheral sockets from the packet data connection.
Packet resource handle. Valid value is a combination of resource identifier and index (yy).
0x01 yy |
Note: Availability of resource objects is chip-specific, see Section 2.2 .
This function creates a Quality of Service packet connection.
The ID number of the opened socket that is the starting point of the link. Must be a socket of type Input . Valid value is a combination of resource identifier and index (yy).
Note: This parameter is chip-specific.
For details refer to
Port-Related Information.
MediaLB socket: 0x0B yy |
||||
MOST socket: 0x0E yy |
The ID number of the opened socket that is the ending point of the link. Must be a socket of type Output . Valid value is a combination of resource identifier and index (yy).
Note: This parameter is chip-specific.
For details refer to
Port-Related Information.
MediaLB socket: 0x0B yy |
||||
MOST socket: 0x0E yy |
Resource handle of the Quality of Service packet connection. Valid value is a combination of resource identifier and index (yy).
0x05 yy |
Parameter
SocketHandleIn
is invalid. This error can be returned for several reasons: |
|||
Parameter
SocketHandleOut
is invalid. This error can be returned for several reasons: - the socket is of the wrong data type, or - the socket is already used in a connection or - both sockets are network sockets or peripheral sockets. In this case parameter SocketHandleOut will be in conflict with parameter SocketHandleIn . |
|||
The socket bandwidth is in conflict with the connection type requirements. |
|||
Parameter SocketHandleIn or SocketHandleOut indicates a resource that does not exist or the resource at the index does not match the specified resource type. |
|||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
|||
Parameter SocketHandleIn or SocketHandleOut indicates a resource that has been rendered invalid and may not be used in a new socket connection. |
|||
This error can be returned for several reasons: - no free slot in the connection table or |
Note: Availability of resource objects is chip-specific, see Section 2.2 .
The functions in this section are used to setup streaming connections for different data types.
To get more information on streaming connections, refer to Chapter 20.0 .
An overview of the streaming connection functions is shown in Table 22-13 .
Note: Availability of resource objects is chip-specific, see Section 2.2 .
This function creates an A/V Packetized Isochronous Streaming data connection.
The ID number of the opened socket that is the starting point of the link. Must be a socket of type Input . Valid value is a combination of resource identifier and index (yy).
Note: This parameter is chip-specific.
For details refer to
Port-Related Information.
MediaLB socket: 0x0B yy |
||||
USB socket: 0x13 yy |
||||
MOST socket: 0x0E yy |
The ID number of the opened socket that is the ending point of the link. Must be a socket of type Output . Valid value is a combination of resource identifier and index (yy).
Note: This parameter is chip-specific.
For details refer to
Port-Related Information.
MediaLB socket: 0x0B yy |
||||
USB socket: 0x13 yy |
||||
MOST socket: 0x0E yy |
Specifies the size of data packets that are to be transported over the isochronous channel
Resource handle of the A/V Packetized Isochronous Streaming connection. Valid value is a combination of resource identifier and index (yy).
0x04 yy |
Parameter
SocketHandleIn
is invalid. This error can be returned for several reasons: |
|||
Parameter
SocketHandleOut
is invalid. This error can be returned for several reasons: - the socket is of the wrong data type, or - the socket is already used in a connection, or - both sockets are network sockets or peripheral sockets. In this case parameter SocketHandleOut will be in conflict with parameter SocketHandleIn . |
|||
The socket bandwidth is in conflict with the connection type requirements. |
|||
Parameter SocketHandleIn or SocketHandleOut indicates a resource that does not exist or the resource at the index does not match the specified resource type. |
|||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
|||
Parameter SocketHandleIn or SocketHandleOut indicates a resource that has been rendered invalid and may not be used in a new socket connection. |
|||
No free slot in the connection table or insufficient free routing resources. |
Note: Availability of resource objects is chip-specific, see Section 2.2 .
This function creates a synchronous data connection between sockets, sockets and combiners as well as sockets and splitters.
|
|
SocketHandleIn, SocketHandleOut, |
|||
The ID number of the opened socket or splitter object that is the starting point of the link. Must be a socket of type Input . Valid value is a combination of resource identifier and index (yy).
Note: This parameter is chip-specific.
For details refer to
Port-Related Information.
Streaming socket: 0x17 yy |
||||
MediaLB socket: 0x0B yy |
||||
USB socket: 0x13 yy |
||||
MOST socket: 0x0E yy |
||||
Splitter: 0x08 yy |
The ID number of the opened socket or combiner object that is the ending point of the link. Must be a socket of type Output . Valid value is a combination of resource identifier and index (yy).
Note: This parameter is chip-specific.
For details refer to
Port-Related Information.
Streaming socket: 0x17 yy |
||||
MediaLB socket: 0x0B yy |
||||
USB socket: 0x13 yy |
||||
MOST socket: 0x0E yy |
||||
Combiner: 0x07 yy |
Configures how the resource monitor shall handle events that may make the streamed data invalid.
The MUTE pin will be asserted if any registered connection may stream corrupted data. |
|||
The INIC will route zeros during conditions that may corrupt the streamed data. |
Specifies the offset from where the socket data should be routed from a splitter; it also specifies the offset to where socket data should be routed to a combiner.
When a standard socket connection is to be created, the offset must be sent as 0. This applies also for connections between a socket and a splitter based on a MOST socket.
Resource handle of the synchronous connection. Valid value is a combination of resource identifier and index (yy).
0x02 yy |
Parameter SocketHandleIn is invalid. This error can be returned for several reasons: - the socket is not of direction Input , or - the socket is not of data type Sync , or - the socket is a loop socket, or - the socket is already used in a connection or with a splitter, or - the socket was requested to be connected with a combiner, but is not a MOST socket. |
|||
Parameter SocketHandleOut is invalid. This error can be returned for several reasons: - the socket is not of direction Output , or - the socket is not of data type Sync , or - the socket is already used in a connection or with a combiner, or - the socket was requested to be connected with another socket, but both are MOST sockets, or both are peripheral sockets, which are invalid combinations, or - the socket is tried to be connected with a splitter and both the socket and the splitter’s socket are created on peripheral ports (either the same or different ports), or - both the socket and the splitter’s socket are MOST sockets. If the resource is a combiner, then the following can happen in addition: |
|||
The bandwidth of the resources is in conflict with the connection type requirements. When connecting two sockets, the bandwidth must be equal. When connecting a splitter/combiner, the size of the socket being connected, considering the offset, must fit inside the splitter/combiner. |
|||
The Offset value of the connection variant is invalid, due to several reasons: - for a standard socket connection, the Offset must be 0. - for a connection between a socket and a splitter (based on a MOST socket) the Offset must be set to 0. |
|||
Parameter DefaultMute or MuteMode is invalid; the connection does not support muting or parameter MuteMode is MuteSignal , but there is no MuteSignal available, since the MUTE pin has not been enabled. |
|||
Parameter SocketHandleIn or SocketHandleOut indicates a resource that does not exist or the resource at the index does not match the specified resource type. |
|||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
|||
Parameter SocketHandleIn or SocketHandleOut indicates a resource that has been rendered invalid and may not be used in a new connection. |
|||
No free slot in the connection table or insufficient free routing resources. |
This function manually mutes a synchronous data connection.
Resource handle of the synchronous connection. Valid value is a combination of resource identifier and index (yy).
0x02 yy |
The resource indicated by SyncHandle does not support muting. |
|||
Parameter SyncHandle is invalid. The handle indicates a resource that does not exist. |
|||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
This function manually de-mutes a synchronous data connection.
Resource handle of the synchronous connection. Valid value is a combination of resource identifier and index (yy).
0x02 yy |
Parameter SyncHandle is invalid. The handle indicates a resource that does not exist. |
|||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
Note: Availability of resource objects is chip-specific, see Section 2.2 .
This function creates a DiscreteFrame Isochronous Streaming phase connection.
Resource handle of the DiscreteFrame Isochronous Streaming phase socket. Valid value is a combination of resource identifier and index (yy).
Note: This parameter is chip-specific.
For details refer to
Port-Related Information.
MediaLB socket: 0x0B yy |
||||
MOST socket: 0x0E yy |
Resource handle of the DiscreteFrame Isochronous Streaming phase socket. Valid value is a combination of resource identifier and index (yy).
Note: This parameter is chip-specific.
For details refer to
Port-Related Information.
MediaLB socket: 0x0B yy |
||||
MOST socket: 0x0E yy |
Resource handle of the DiscreteFrame Isochronous Streaming phase connection. Valid value is a combination of resource identifier and index (yy).
0x09 yy |
Parameter
SocketHandleIn
is invalid. This error can be returned for several reasons: |
|||
Parameter
SocketHandleOut
is invalid. This error can be returned for several reasons: - the socket is of the wrong data type, or - the socket is already used in a connection, or - both sockets are network sockets or peripheral sockets. In this case parameter SocketHandleOut will be in conflict with parameter SocketHandleIn . |
|||
Parameter SocketHandleIn or SocketHandleOut indicates a resource that does not exist or the resource at the index does not match the specified resource type. |
|||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
|||
Parameter SocketHandleIn or SocketHandleOut indicates a resource that has been rendered invalid and may not be used in a new socket connection. |
|||
No free slot in the connection table or insufficient free routing resources. |
This function creates a combiner for a synchronous data connection.
|
Resource handle of the synchronous socket. Valid value is a combination of resource identifier and index (yy).
Note: This parameter is chip-specific.
For details refer to
Port-Related Information.
Streaming socket: 0x17 yy |
||||
MediaLB socket: 0x0B yy |
||||
USB socket: 0x13 yy |
Port resource handle. Valid value is a combination of resource identifier and index (yy).
Note: This parameter is chip-specific.
For details refer to
Chip_MOSTPortIndex.
0x0D yy |
Specifies the total number of data bytes to be transferred each MOST network frame
Resource handle of the combiner. Valid value is a combination of resource identifier and index (yy).
0x07 yy |
Parameter SocketHandleOut is invalid. This error can be returned for several reasons: - the socket is not of direction Output , or - the socket is not of data type Sync , or - the socket is already used in a connection or with another combiner. |
|||
Parameter
BytesPerFrame
conflicts with the size of the socket indicated by parameter
SocketHandleOut
. |
|||
Parameter SocketHandleOut indicates a resource that does not exist or the resource at the index does not match the specified resource type. |
|||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
|||
No free slot in the combiner table or insufficient free routing resources. |
This function creates a splitter for a synchronous data connection.
|
Resource handle of the synchronous socket. Valid value is a combination of resource identifier and index (yy).
Note: This parameter is chip-specific.
For details refer to
Port-Related Information.
Streaming socket: 0x17 yy |
||||
MediaLB socket: 0x0B yy |
||||
USB socket: 0x13 yy |
||||
MOST socket: 0x0E yy |
Port resource handle. When the splitter is created with a MOST socket, the socket must be created on the same port indicated by this handle. Valid value is a combination of resource identifier and index (yy).
Note: This parameter is chip-specific.
For details refer to
Chip_MOSTPortIndex.
0x0D yy |
Specifies the total number of data bytes to be transferred each MOST network frame
Resource handle of the splitter. Valid value is a combination of resource identifier and index (yy).
0x08 yy |
Parameter SocketHandleIn is invalid. This error can be returned for several reasons: - the socket is not of direction Input , or - the socket is not of data type Sync , or - the socket is a loop socket, or - the socket is already used in a connection or with another splitter. |
|||
Parameter
BytesPerFrame
conflicts with the size of the socket indicated by parameter
SocketHandleIn
. |
|||
Parameter SocketHandleIn indicates a resource that does not exist or the resource at the index does not match the specified resource type. |
|||
Configuration interface is not in Remote Control Mode and a request to modify data was received from network side. |
|||
Parameter SocketHandleIn indicates a resource that has been rendered invalid and may not be used in a new splitter. |
|||
No free slot in the splitter table or insufficient free routing resources. |
This function provides debug events which are generated by the INIC and sent to the MOST network. For more information refer to Chapter 24.0 .
Debug message is sent if the NetInterface is in Normal Operation state after reset, in case the reset was caused by the appropriate reason.
Reset due to hardware watchdog that has snapped |
|||
Reset due to stack overflow |
ICM channel synchronization loss due to one of the following conditions:
Channel was unsynchronized due to a synchronization loss on the RCM channel. - DebugLevel is Error |
|||
Channel was unsynchronized due to a PMP SYNC or UNSYNC command. |
|||
Acknowledge time of previously transmitted message has expired. |
|||
PMP watchdog time has expired (communication got stuck). |
|||
Transmit time has expired and transmission was canceled. |
RCM channel synchronization loss due to one of the following conditions:
Channel was unsynchronized due to a synchronization loss on the ICM channel. - DebugLevel is Error |
|||
Channel was unsynchronized due to a PMP SYNC or UNSYNC command. |
|||
Acknowledge time of previously transmitted message has expired. |
|||
PMP watchdog time has expired (communication got stuck). |
|||
Transmit time has expired and transmission was canceled. |
MCM channel synchronization loss due to one of the following conditions:
Channel was unsynchronized due to a PMP SYNC or UNSYNC command. |
|||
Acknowledge time of previously transmitted message has expired. |
|||
PMP watchdog time has expired (communication got stuck). |
|||
Transmit time has expired and transmission was canceled. |
The functions in this section are used to control a device via the EHC or the MOST network.
An overview of the ExtendedNetworkControl functions is shown in Table 22-14 .
This function is used to get the unique Signature of an INIC device.
The requesting device sends ExtendedNetworkControl.Hello.Get as a broadcast message to the MOST network. Only those devices that have not successfully sent ExtendedNetworkControl.Welcome.Result will answer with the ExtendedNetworkControl.Hello.Status message. The ExtendedNetworkControl.Hello.Status message is sent by using source address 0x0FFE.
Node Address as entered in the identification string.
This parameter can be customized via the Identification String.
Group Address as entered in the identification string.
This parameter can be customized via the Identification String.
Packet EUI-48 Bits 47:32 of the MAC address as entered in the identification string.
This parameter can be customized via the Identification String.
Packet EUI-48 Bits 31:16 of the MAC address as entered in the identification string.
This parameter can be customized via the Identification String.
Packet EUI-48 Bits 15:0 of the MAC address as entered in the identification string.
This parameter can be customized via the Identification String.
Current valid NodePositionAddress if network is available. 0x0400 is reported if the MOST network is not available.
DiagID as entered in the configuration string.
This parameter can be customized via the Configuration String.
Major version number of the configuration string.
This parameter can be customized via the Configuration String.
Minor version number of the configuration string.
This parameter can be customized via the Configuration String.
Release version number of the configuration string.
This parameter can be customized via the Configuration String.
This function is used to welcome a device in the MOST network.
The function uses the
Signature
which was returned by the
ExtendedNetworkControl.Hello.Status
message.
The receiving device compares the signature of the
ExtendedNetworkControl.Welcome.StartResult
message with its own signature sent by the
ExtendedNetworkControl.Hello.Status()
message. If the signature matches and the
AdminNodeAddress
is in the range of 0x0F00...0x0FEF, the
NodeAddress
is set to the
AdminNodeAddress
.
The message is always send to the NodePositionAddress , see Section 5.11.2 .
The node address used during system diagnosis and device diagnosis. If 0xFFFF is applied, the Node Address configured in the identification string is used (only valid if device is not in system diagnosis mode and System Mode is UNICENS ).
Contains the Signature values as returned by parameter ExtendedNetworkControl.Hello.Status.Signature
Contains the NodeAddress as returned by parameter ExtendedNetworkControl.Hello.Status.Signature
Contains the GroupAddress as returned by parameter ExtendedNetworkControl.Hello.Status.Signature
Contains bits 47:32 of the MAC address as returned by parameter ExtendedNetworkControl.Hello.Status.Signature
Contains bits 31:16 of the MAC address as returned by parameter ExtendedNetworkControl.Hello.Status.Signature
Contains bits 15:0 of the MAC address as returned by parameter ExtendedNetworkControl.Hello.Status.Signature
Contains the NodePositionAddress as returned by parameter ExtendedNetworkControl.Hello.Status.Signature
Contains the NumberOfPorts as returned by parameter ExtendedNetworkControl.Hello.Status.Signature .
Note: This parameter is chip-specific.
For details refer to Chip_NumberOfMOSTPorts.
Contains the ChipID as returned by parameter ExtendedNetworkControl.Hello.Status.Signature .
Note: This parameter is chip-specific.
For details refer to
Chip_ID.
Contains the major firmware version as returned by parameter ExtendedNetworkControl.Hello.Status.Signature
Contains the minor firmware version as returned by parameter ExtendedNetworkControl.Hello.Status.Signature
Contains the release firmware version as returned by parameter ExtendedNetworkControl.Hello.Status.Signature
Contains the major configuration string version as returned by parameter ExtendedNetworkControl.Hello.Status.Signature
Contains the minor configuration string version as returned by parameter ExtendedNetworkControl.Hello.Status.Signature
Contains the release configuration string version as returned by parameter ExtendedNetworkControl.Hello.Status.Signature
- physical layer test is running, or - ForcedNA was set. |
|||
Device has not yet received an ExtendedNetworkControl.Hello.Get() message. |
|||
Device has already successfully received an ExtendedNetworkControl.Welcome.StartResult() message. |
|||
AdminNodeAddress is 0xFFFF. This value is not supported during system diagnosis state. |
|||
AdminNodeAddress is 0xFFFF. This value is not supported in System Mode MOSTNetServices . |
|||
Value of Node Address in the identification string is not valid. The value is either 0xFFFF or in the dynamic range (see Section 5.11.1 ) while AdminNodeAddress is 0xFFFF. |
|||
This function is used to get the unique Signature of an INIC device.
Every network device responds to this message, regardless of whether it was already welcomed or not.
Contains the Signature values as returned by parameter ExtendedNetworkControl.Signature.Status.Signature
Node Address as entered in the identification string.
This parameter can be customized via the Identification String.
Group Address as entered in the identification string.
This parameter can be customized via the Identification String.
Packet EUI-48 Bits 47:32 of the MAC address as entered in the identification string.
This parameter can be customized via the Identification String.
Packet EUI-48 Bits 31:16 of the MAC address as entered in the identification string.
This parameter can be customized via the Identification String.
Packet EUI-48 Bits 15:0 of the MAC address as entered in the identification string.
This parameter can be customized via the Identification String.
Contains the NodePositionAddress as returned by parameter ExtendedNetworkControl.Hello.Status() message. 0x04FF is reported in case no ExtendedNetworkControl.Hello.Get message was seen.
Diag ID as entered in the configuration string.
This parameter can be customized via the Configuration String.
Major version number of the configuration string.
This parameter can be customized via the Configuration String.
Minor version number of the configuration string.
This parameter can be customized via the Configuration String.
Release version number of the configuration string.
This parameter can be customized via the Configuration String.
This function is used to set back the FBlock ExtendedNetworkControl of a device into its initial state, which means:
This function is used to enable a particular MOST Port.
Note: This functionality is chip-specific.
For details refer to
Chip_CableLinkDiagnosis.
This function is used to start the cable link diagnosis. The cable link diagnosis is used to verify a full duplex MOST Port cable link.
Number of MOST Port the diagnosis is running on
Note: This parameter is chip-specific.
For details refer to
Chip_NumberOfMOSTPorts.
Result of the cable link diagnosis.
Cable link diagnosis was run without any test interruption.
Cable link diagnosis was run with test interruption.
Test was aborted since the Debug Header was used at the same time. |
|||
- The last INIC.CableLinkDiagnosis() call has not yet been finished. |
|||
- ForcedNA was set. |
|||
Device is not in system diagnosis state and therefore cable link diagnosis cannot be triggered. |
|||
Cable link diagnosis cannot be triggered on the slave’s clock reference MOST Port. |
Note: This functionality is chip-specific.
For details refer to
Chip_PhysicalLayerTest.
This function starts the physical layer test on a MOST Port.
Once the physical layer test is started it will force the MOST network to enter
NotAvailable
state, indicating sub state
AvailabilityInfo
Diagnosis
. After the test has been finished, it changes back to
Regular
and the chip is ready to start up again.
If the network is
Available
when starting the test, the
AvailabilityTransitionCause
will be
Normal
.
Number of MOST Port the test is performed on
Note: This parameter is chip-specific.
For details refer to
Chip_NumberOfMOSTPorts.
Indicates the type of physical layer test. The device is switched back to its original mode after the physical layer test is finished and the MOST network has been started up again.
Forces the device to enter RetimedBypassMaster mode independent of original mode. |
|||
Forces the device to enter RetimedBypassSlave mode independent of original mode. |
Note: This functionality is chip-specific.
For details refer to
Chip_PhysicalLayerTest.
This function returns the result for the tested MOST Port, after the physical layer test has been finished.
As soon as the physical layer test is started by executing function ExtendedNetworkControl.PhysicalLayerTest() , all parameters of ExtendedNetworkControl.PhysicalLayerTestResult() become invalid. This means:
If the test is erroneous, all values will stay invalid. If the test can be finished successfully, the PortNumber changes to a valid number given during the test and LockStatus and ErrorCounterValue also return with evaluated values.
After INIC reset, all values are invalidated. They are also invalidated after they have been read.
Number of MOST Port the test was performed on. If the handle is invalid, 0xFF is returned.
This function is used to open a memory session. A memory session is used to control access to the memory resources. Before a memory could be read or written, a session of the appropriate type has to be opened.
Only a single memory session is supported. Once opened, the session must be first closed before a new session of a different type could be used.
Some session types (0x01, 0x02 and 0x04) require a hardware reset after they were closed. If one of these sessions is opened to write the configuration string and/or the identification string, an INIC reset request is placed. Execution of the INIC reset happens when the INIC transitions to NetInterface Off state or after ExtendedNetworkControl.Init() was called, see Section 22.4.4 .
This function also performs some preprocessing, depending on the SessionType . This includes the clearing of the configuration and identification strings in advance to programming or erasing the error memory.
Defines the set of MemIDs and the memory access type(s) (read and/or write)
Writes to MemID 0x00, configuration string |
|||
Writes to MemID 0x01, identification string |
|||
Reads the information memory MemID 0x00, MemID 0x01, MemID 0x02 |
|||
Unique number used to authorize memory access. Required as a parameter in functions ExtendedNetworkControl.MemoryRead() and ExtendedNetworkControl.MemoryWrite()
Before a new session can be opened, a hardware reset must be applied. |
|||
The memory session using the SessionHandle is already active. |
|||
This function is used to close an active memory session that was previously opened by function ExtendedNetworkControl.MemorySessionOpen() . In addition, the function performs some post-processing on given session types. This includes validation of the newly programmed configuration and identification strings as well as the deactivation of the current configuration and identification strings. In these cases, the new configuration becomes active after a hardware reset.
Unique number assigned to the active memory session by function ExtendedNetworkControl.MemorySessionOpen()
This function provides read access to the memories described by parameter MemID . In addition, the function can be used to retrieve the active Configuration String and Identification String.
Reading the memory can only be done within an active memory session. Parameter SessionHandle authorizes the access to the memory resource defined by parameter MemID. The SessionHandle is provided by function ExtendedNetworkControl.MemorySessionOpen() , which must be called in advance to memory access.
Identifies the active memory session already opened to authorize the reading operation
Defines the memory location at which the reading operation starts.
|
Sets the number of memory units to be read. Memory units can be unsigned bytes, unsigned words or unsigned masked data depending on the memory type.
Contains the data read from the memory resource and formatted as memory units
{ ByteData } |
|||
{ ByteData } |
|||
{ ByteData } |
|||
{ WordData } |
|||
{ ByteData } |
|||
{ ByteData } |
|||
{ MaskedWordData } |
|||
{ MaskedWordData } |
|||
{ MaskedWordData } |
|||
{ ByteData } |
Defines a stream formatted as pairs of unsigned words and their corresponding word bit masks
The SessionHandle does not match the current memory session. |
|||
The memory session does not support the requested MemID . |
This function provides write access to the memories described by parameter MemID . In addition, the function can be used to program a new Configuration String and Identification String.
Writing the memory can only be done within an active memory session. Parameter SessionHandle authorizes the access to the memory resource defined by parameter MemID. The SessionHandle is provided by function ExtendedNetworkControl.MemorySessionOpen() , which must be called in advance to memory access.
Identifies the active memory session already opened to authorize the writing operation
Defines the memory location at which the writing operation starts.
|
Sets the number of memory units to be written. Memory units can be unsigned bytes, unsigned words or unsigned masked data depending on the memory type.
Contains the actual data written to the memory resource and formatted as memory units
{ ByteData } |
|||
{ ByteData } |
|||
{ WordData } |
|||
{ ByteData } |
|||
{ ByteData } |
|||
{ MaskedWordData } |
|||
{ MaskedWordData } |
|||
{ MaskedWordData } |
|||
{ ByteData } |
Defines a stream formatted as pairs of unsigned words and their corresponding word bit masks.
The SessionHandle does not match the current memory session. |
|||
The memory session does not support the requested MemID . |
|||
The Address is odd when writing the memory. |
|||
The UnitLen is odd when writing the memory. |
The INIC’s error reporting is based on standard error codes as provided by the MOST Specification [1] . This includes error codes (0x01-0x06) that indicate format failures. A format failure occurs whenever a function or parameter-related setting was done that is not supported by the INIC API. In addition to these error codes, error code 0x0C is reported if a segmentation error occurs. The standard error codes are listed in Table 22-15 , including error code 0x20, which is function-specific. Function-specific error codes are related to errors that can only happen during runtime.
Error code information consists of a code ( ErrorCode ) and a description of it ( ErrorInfo ), see Table 22-15 . A function-specific error code always has the ErrorCode number 0x20; its ErrorInfo contains the ErrorClass and the ErrorID. The ErrorClass describes the classification of the error, and the ErrorID and its description the details. A description of available error classes is given in Table 22-16 ; the ErrorID and its description can be found beneath the appropriate INIC API function in this chapter.
|
Parameter wrong/ out of range: One or more of the parameters were wrong, i.e., not within the boundaries specified for the function. |
Number of parameter (byte containing 1,2, …). Value of first incorrect parameter only (optional). Interpretation will be stopped then. |
||
After this error code, the following ErrorInfo 0x01 up to 0x07 can be sent. |
|||
Segmented message has not been finished before the arrival of another message set by the same node. |
|||
Refer to Table 22-16 . Additional error information can be found beneath the appropriate INIC API function. |
|||
Busy Example: Returned when a detach request is pending, but the application triggers an attach. |
|
Process could not be finished. Retries are possible. Example: The MOST network cannot reach Available state. |
|
Wrong configuration (values are temporarily out of range). Example: Application has already opened a port that was requested to be opened again with a different, but valid setting. |
|
Current state of INIC or network prevents a successful execution of the process and retries are not possible. Example: Occurs if it is requested to create streaming sockets while there is not enough streaming bandwidth available on the MOST network. |
The INIC provides two memory sections for configuration, namely the Configuration String and the Identification String. Each memory section consists of a list of properties, with a factory default value associated to each property. If the factory default values do not match the settings required for the application, the values can be adjusted and the string can be re-programmed.
This memory section includes the factory default values to be used as information on the INIC’s initial hardware configuration (e.g., the type of default port that is automatically opened for communication between the INIC and the EHC). Re-programming the configuration string is done during development or production.
This memory section includes the factory default values to be used for unambiguous device identification. Re-programming the identification string is done during device installation.
For information on how to program the configuration string and the identification string, refer to the Device Update Process User’s Guide [16] .
This section lists the properties of the configuration string. The properties are grouped (e.g., Device Management, Power Management). To each property a general description is given that explains the intended use of the property and its valid values. The default value associated to every property is given in Table 23-1 .
Defines the diagnostic identifier of the device.
For available parameters refer to
DiagID
.
Determines how the GP8 pin is used.
Note: This property is chip-specific.
For details refer to
Chip_GP8Configuration.
No action. GP8 pin can be used as GPIO pin, see Chapter 15.0 . |
||
GP8 pin signals reset. The pin is driven low for 10 ms as soon as INIC enters Protected Mode. |
||
Selects the port for the configuration interface. The configuration interface defines that the port is used for the ICM and RCM PMP channels.
|
Note: This property is chip-specific.
For details refer to
Port-Related Information.
Selects the port for the application interface. The application interface defines that the port is used for the MCM PMP channel.
For limitations refer to Configuration Interface.
Note: This property is chip-specific.
For details refer to
Port-Related Information.
By using the properties below, the following actions can be automatically initiated by INIC in Protected Mode.
Enables or disables the power management monitoring of the PS0 and PS1 pins
Disables the power management monitoring of the PS0 and PS1 pins, but allows for limited property settings: configuration of Power Off Time is possible. |
||
Enables the power management monitoring of the PS0 and PS1 pins with further property settings, see below. |
Determines the INIC’s behavior when it detects an erroneous power condition (U Low ) on the PS0/PS1 pins, see Table 4-1 .
Sets ForcedNA |
||
Drives PWROFF pin high and sets ForcedNA |
Determines the INIC’s behavior when it detects an STP condition on the PS0/PS1 pins, see Table 4-1 .
INIC starts Ring Break Diagnosis as TimingSlave when PS0 and PS1 pins indicate state STP, see Table 4-1 . |
||
INIC starts Ring Break Diagnosis as TimingMaster when PS0 and PS1 pins indicate state STP, see Table 4-1 . |
||
INIC starts the MOST network as TimingMaster when PS0 and PS1 pins indicate state STP, see Table 4-1 . This action provides the ability for two further property settings, see below. |
Sets the delay for network shut down when INIC resides in Protected Mode and NetInterface Off state has been left (e.g., network startup has been triggered).
For available parameters refer to
AutoForcedNotAvailableTime
.
Determines the packet data bandwidth on the MOST network configured by a TimingMaster device.
Note: This property is chip-specific.
For details refer to
Chip_Bandwidth_MaxValue.
Defines the time after which the
PWROFF
pin is set high. The precondition for timer start is that both conditions must occur: the Network must be in NetInterface Off state (see
Figure 5-1
) and INIC must have entered Protected Mode. If one of the conditions is no longer met, the timer will stop.
If the timer is set to 65535, it will be disabled and the INIC will never drive the
PWROFF
pin high, not even if the Network is in NetInterface Off state and INIC has entered Protected Mode.
The default value is 65535 s.
Defines the block count for control Low-Level Retries for all messages generated by the INIC itself.
For available parameters refer to
ControlLLRBlockCount
.
The configuration settings are per MOST Port.
Note: Availability of resource objects is chip-specific, see Section 2.2 .
Defines the initial operation mode of the MOST Port for INICs that provide more than one MOST Port.
Note: This property is chip-specific.
For details refer to
Chip_NumberOfMOSTPorts.
Defines the physical layer used for MOST network communication
Note: This property is chip-specific.
For details refer to
Chip_PhysicalLayer.
Sets the physical layer to Coax for AF devices and to Optical for BF devices. For information on AF and BF devices, refer to the INIC Hardware Data Sheet [4] . |
Creates the I 2 C Port of the device
|
Note: Availability of resource objects is chip-specific, see Section 2.2 .
Note: Availability of resource objects is chip-specific, see Section 2.2 .
Creates the USB Port of the device
Selects the interface of the USB Port’s physical layer.
For available parameters refer to
PhysicalLayer
.
Enables or disables the control interface communication over the USB Port. This interface provides the Endpoints 0x0F (OUT) and 0x8F (IN).
Enables or disables the packet interface communication over the USB Port. This interface provides the Endpoints 0x0E (OUT) and 0x8E (IN).
Enables or disables the streaming interface communication over the USB Port. This interface provides the Endpoints 0x01...0x0A (OUT) and 0x81...0x8A (IN), dependent on the configured count of OUT and IN Endpoints. The count is configured by parameters OUT Endpoint Count for Streaming Interface and IN Endpoint Count for Streaming Interface .
Creates the SPI Port of the device
Sets the phase and polarity of the SCLK signal.
For available parameters refer to
ClockMode
.
Loads the base configuration. For more information refer to Chapter 12.0 .
Defines the direction of the physical data pins of Streaming Port A.
For available parameters refer to
PortOption
.
Defines the operation mode of Streaming Port A.
For available parameters refer to
OperationMode
.
Defines the clock generation mode for Streaming Port A
Indicates if there should be a single clock cycle delay between the start of frame and the start of the frame data.
There is a single SCK clock delay between the start of frame (falling edge of FSY ) and the start of the frame data on the data pins. |
Defines the direction of the physical data pins of Streaming Port B.
For available parameters refer to
PortOption
.
Defines the operation mode of Streaming Port B.
For available parameters refer to
OperationMode
.
Creates the RMCK Port of the device
Determines the output frequency for the RMCK pin.
For available parameters refer to
Divisor
.
Note: Availability of resource objects is chip-specific, see Section 2.2 .
Enables or disables the driver control interface access of the packet connection. Driver control interface access is only possible over a MediaLB Port or an SPI Port.
Enables or disables the functionality for reduction of standard routing memory space used for packet transmission.
Note: This property is chip-specific.
For details refer to
Chip_StandardRoutingMemory.
Defines the physical port used for the packet connection
Note: This property is chip-specific.
For details refer to
Port-Related Information.
Packet connection uses the MediaLB Port and provides the ability for further property settings, see below. |
||
Enables or disables the packet multiplexing feature
- The values for MediaLB Input Bandwidth and MediaLB Output Bandwidth must be the same. - The MediaLB Input Bandwidth and the MediaLB Output Bandwidth must be each at least 12 bytes in size. - The difference between the MediaLB Input Address and the MediaLB Output Address must be 2 (e.g., 0x0006 and 0x0008). |
Sets the MediaLB Input address of the packet. The setting of this property is dependent on the selected Port Speed.
|
Determines the number of bytes reserved for a packet connection of direction Input. The setting of this property is dependent on the selected Port Speed.
- MediaLB Input Bandwidth and MediaLB Output Bandwidth used in a packet connection, - Configuration Interface and Application Interface (each PMP channel requires 4 bytes if MediaLB is selected). |
Sets the MediaLB Output address of the packet.
For available parameters and limitations refer to
MediaLB Input Address
.
Determines the number of bytes reserved for a packet connection of direction Output. For available parameters and limitations refer to MediaLB Input Bandwidth .
Defines the major version number of the configuration string.
For available parameters refer to ExtMajorVersion .
Defines the minor version number of the configuration string.
For available parameters refer to ExtMinorVersion .
Defines the release version number of the configuration string.
For available parameters refer to ExtReleaseVersion .
Note: Availability of resource objects is chip-specific, see Section 2.2 .
The properties and their associated default values are as follows:
This section lists the properties of the identification string. To each property a general description is given that explains the intended use of the property. The default value associated to every property is given in Table 23-2 .
Defines the second group address of the device.
For available parameters refer to
GroupAddress
.
Defines bits 47:32 of the EUI-48.
For available parameters refer to
PacketEUI48_47to32
.
Defines bits 31:16 of the EUI-48.
For available parameters refer to
PacketEUI48_31to16
.
Defines bits 15:0 of the EUI-48.
For available parameters refer to
PacketEUI48_15to0
.
The properties and their associated default values are as follows:
The INIC provides diagnosis functionality via the MOST debug message. The message is used to send debug events – these are events that are generated by the INIC and sent to the MOST network, to allow a standard analysis tool such as the OptoLyzer MOCCA Bundle 150o/c [10] focusing on these events.
MOST debug messages are always sent to debug address 0x0FF0; no retries are performed.
The FBlock DebugMessages is not included in the central registry. The InstID of the FBlock is equal to the node position of the device that implements the FBlock.
The function that provides the debug events is called
NIC_DebugMessage()
, see
Section 22.3.1
. Debug events are categorized to signal different debug levels, which are error and warning. The function cannot be adjusted; it always includes errors and warnings. Requests to this function are not supported.
The INIC provides a mechanism to indicate that the final control message retry has failed. In this case, the control message is sent to debug address 0x0FF0 instead to the original target address.
|
CableLinkDiagnosis, FktID = 0x211 239
MemorySessionClose, FktID = 0x301 245
MemorySessionOpen, FktID = 0x302 244
MemoryWrite, FktID = 0x303 248
PhysicalLayerTest, FktID = 0x220 241
AVPacketizedCreate, FktID = 0x861 209
CombinerCreate, FktID = 0x901 218
DeviceAttach, FktID = 0x223 130
DevicePowerOff, FktID = 0x222 129
DeviceStatus, FktID = 0x220 125
DeviceVersion, FktID = 0x221 127
DiscFramePhaseCreate, FktID = 0x881 216
GPIOPortCreate, FktID = 0x701 190
GPIOPortPinMode, FktID = 0x703 191
GPIOPortPinState, FktID = 0x704 193
GPIOPortTriggerEvent, FktID = 0x705 195
I2CPortCreate, FktID = 0x6C1 183
I2CPortRead, FktID = 0x6C3 185
I2CPortWrite, FktID = 0x6C4 187
MediaLBPacketMuxSocketCreate, FktID = 0x632 162
MediaLBPortCreate, FktID = 0x621 157
MediaLBSocketCreate, FktID = 0x631 159
MOSTNetworkConfiguration, FktID = 0x521 136
MOSTNetworkForceNotAvailable, FktID = 0x52B 146
MOSTNetworkFrameCounter, FktID = 0x523 140
MOSTNetworkRBD, FktID = 0x526 144
MOSTNetworkRBDResult, FktID = 0x527 145
MOSTNetworkShutdown, FktID = 0x525 143
MOSTNetworkStartup, FktID = 0x524 141
MOSTNetworkStatus, FktID = 0x520 133
MOSTNetworkSystemDiagnosis, FktID = 0x52C 147
MOSTNetworkSystemDiagnosisEnd, FktID = 0x52D 148
MOSTPortStatus, FktID = 0x602 150
MOSTPortUsed, FktID = 0x603 152
MOSTSocketCreate, FktID = 0x611 153
Notification, FktID = 0x001 122
PacketAttachSockets, FktID = 0x843 203
PacketDetachSockets, FktID = 0x844 205
QoSPacketCreate, FktID = 0x851 206
ResourceDestroy, FktID = 0x800 198
ResourceInvalidList, FktID = 0x801 200
ResourceMonitor, FktID = 0x802 201
RMCKPortCreate, FktID = 0x6A1 180
SPIPortCreate, FktID = 0x641 164
SPISocketCreate, FktID = 0x651 165
SplitterCreate, FktID = 0x911 220
StreamPortConfiguration, FktID = 0x680 172
StreamPortCreate, FktID = 0x681 174
StreamPortLoopback, FktID = 0x683 176
StreamSocketCreate, FktID = 0x691 178
GroupAddress, FktID = 0x004 116
MOSTVersionInfo, FktID = 0x014 120
NodeAddress, FktID = 0x003 115
NodePositionAddress, FktID = 0x002 114
FktID = 0x211, CableLinkDiagnosis 239
FktID = 0x220, PhysicalLayerTest 241
FktID = 0x221, PhysicalLayerTestResult 243
FktID = 0x300, MemorySessionOpen 244
FktID = 0x001, Notification 122
FktID = 0x220, DeviceStatus 125
FktID = 0x221, DeviceVersion 127
FktID = 0x222, DevicePowerOff 129
FktID = 0x223, DeviceAttach 130
FktID = 0x520, MOSTNetworkStatus 133
FktID = 0x521, MOSTNetworkConfiguration 136
FktID = 0x523, MOSTNetworkFrameCounter 140
FktID = 0x524, MOSTNetworkStartup 141
FktID = 0x525, MOSTNetworkShutdown 143
FktID = 0x526, MOSTNetworkRBD 144
FktID = 0x527, MOSTNetworkRBDResult 145
FktID = 0x52B, MOSTNetworkForceNotAvailable 146
FktID = 0x52C, MOSTNetworkSystemDiagnosis 147
FktID = 0x52D, MOSTNetworkSystemDiagnosisEnd 148
FktID = 0x602, MOSTPortStatus 150
FktID = 0x603, MOSTPortUsed 152
FktID = 0x611, MOSTSocketCreate 153
FktID = 0x621, MediaLBPortCreate 157
FktID = 0x631, MediaLBSocketCreate 159
FktID = 0x632, MediaLBPacketMuxSocketCreate 162
FktID = 0x641, SPIPortCreate 164
FktID = 0x651, SPISocketCreate 165
FktID = 0x661, USBPortCreate 167
FktID = 0x671, USBSocketCreate 169
FktID = 0x680, StreamPortConfiguration 172
FktID = 0x681, StreamPortCreate 174
FktID = 0x683, StreamPortLoopback 176
FktID = 0x691, StreamSocketCreate 178
FktID = 0x6A1, RMCKPortCreate 180
FktID = 0x6C1, I2CPortCreate 183
FktID = 0x6C3, I2CPortRead 185
FktID = 0x6C4, I2CPortWrite 187
FktID = 0x701, GPIOPortCreate 190
FktID = 0x703, GPIOPortPinMode 191
FktID = 0x704, GPIOPortPinState 193
FktID = 0x705, GPIOPortTriggerEvent 195
FktID = 0x800, ResourceDestroy 198
FktID = 0x801, ResourceInvalidList 200
FktID = 0x802, ResourceMonitor 201
FktID = 0x843, PacketAttachSockets 203
FktID = 0x844, PacketDetachSockets 205
FktID = 0x851, QoSPacketCreate 206
FktID = 0x861, AVPacketizedCreate 209
FktID = 0x881, DiscFramePhaseCreate 216
FktID = 0x002, NodePositionAddress 114
FktID = 0x003, NodeAddress 115
FktID = 0x004, GroupAddress 116
FktID = 0x007, RetryParameters 118
FktID = 0x014, MOSTVersionInfo 120
Figure 3-1: Control Message Format 5
Figure 3-3: Configuration Interface – EHC Controlled 8
Figure 3-4: Configuration Interface – Remote Controlled 10
Figure 3-5: Configuration Interface Modes 11
Figure 3-6: Steps to Reach Attached Mode 13
Figure 3-7: Remote Control Command Sequence 14
Figure 3-8: Application Interface 15
Figure 3-9: Application Interface Modes 17
Figure 4-2: Power State is U Normal 23
Figure 4-3: Power State is U Low 24
Figure 4-4: Power State is STP 25
Figure 4-5: Power State is U Critical 26
Figure 5-1: NetInterface State Diagram 27
Figure 5-2: Physical Layer Test Flow 33
Figure 7-1: State Diagram of a Monitored Connection 41
Figure 7-2: EHC Implementation Proposal for Resource Handling without Muting 44
Figure 7-3: EHC Implementation Proposal for Resource Handling with Muting 45
Figure 7-4: Unlock with Temporarily Invalid Connection 46
Figure 7-5: Permanently Invalidated Connection 47
Figure 9-1: Packet Multiplexing 53
Figure 11-1: Synchronous Bulk Transaction with Padding 58
Figure 11-2: A/V Packetized Bulk Transaction with Padding 59
Figure 11-3: A/V Packetized Bulk Transaction without Padding 59
Figure 14-1: I²C Read/Write 71
Figure 14-2: I²C Write Burst Mode 72
Figure 14-3: I²C Repeated Start 72
Figure 15-1: Edge Sensitive Input 74
Figure 15-2: Level Sensitive Input 74
Figure 16-1: Bulk Transaction with a Combiner 77
Figure 18-1: Control Connection 79
Figure 18-2: Control Low-Level Retries 80
Figure 19-1: MOST Data Packet Message Format 81
Figure 19-2: MOST Ethernet Packet Message Format 81
Figure 19-3: Packet Connection 83
Figure 19-4: Read Register Command 86
Figure 19-5: DCI Trigger Message Format 86
Figure 19-6: QoS Connection 87
Figure 20-1: Synchronous Connections 92
Figure 20-2: Combiner Connections 95
Figure 20-3: Splitter Connections 97
Figure 20-4: A/V Packetized Connections 100
Figure 20-5: DiscreteFrame Isochronous Streaming Phase Connections 105
Device Qualifier Descriptor 64
Device without Microcontroller 7
Message Transmission Status, TX_FAILURE
MOST Data Packet Message Format 81
Remotely Controlled Application 7
Resource Handling with Muting 45
Resource Handling without Muting 44