Introduction

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 the INICnet™ technology (network of INICs) to a highly cost-effective all-in-one multimedia network solution, supporting audio, video and IP data over a single cable. A high level of integration and encapsulation of the network functions grant robustness, ease of use and minimum time to market.

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 a highly flexible IC that can be implemented in a wide range of applications. However, not every application design needs the entire feature set or all of the peripheral ports. This is why Microchip extended the INIC family with new INICs that only provide a sub-set of features and ports. An overview of different INICs and the functionality they support is given in Section 2.2 .

The INICs covered by this specification are:

• • OS81118
• • OS81119
• • OS81210
• • OS81212
• • OS81214
• • OS81216

General Information

FBlock-Syntax Correlation

The table below gives an overview about each FBlock and its corresponding syntax version.

Chip-Specific Characteristics

Port Message Protocol

To be able to exchange control messages, the INIC provides a set of independent Port Message Protocol (PMP) channels. The communication is handled through the PMP as specified inside the Port Message Protocol V2.0.1 Specification [2] . 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 ).

Control Message Format

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.

Figure 3-1: Control Message Format

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

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

Figure 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 [2] .

Figure 3-2: PMP Payload

 

Table 3-2: PMP Payload Format Field Description

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

 

Configuration Interface

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

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

• • EHC controlled and
• • Remote controlled.

EHC Controlled

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

Figure 3-3: Configuration Interface – EHC Controlled

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

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

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

 

The ICM PMP channel is only used to access the local FBlock INIC.

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

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

Remote Controlled

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

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

Figure 3-4: Configuration Interface – Remote Controlled

Operation Modes

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

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

 

Figure 3-5: Configuration Interface Modes

 

Protected Mode

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

While in Protected Mode, the network remains Available and all pending diagnostic tasks (e.g., physical layer test) will be completed.

The Protected Mode incorporates the sub states:

• • Cleanup
• • Wait for local EHC
• • Synchronized
• • Wait for remote EHC

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

Cleanup

The transition to the cleanup state can be triggered by several indicators:

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

 

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

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

 

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

 

Wait for local EHC

This state is entered after the cleanup has been finished and the INIC is configured to be EHC controlled.

 

Wait for remote EHC

This state is entered after the cleanup has been finished and the INIC is configured to be remote controlled.

 

Synchronized

The synchronized state is entered as soon as the EHC has finished ICM and RCM PMP channel synchronization. The state is also entered after the EHC has finished DI2C message channel synchronization.

In the synchronized state, 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 are synchronized by the PMP channel synchronization procedure, which is described in the Port Message Protocol V2.0.1 Specification [2] .

Attached Mode

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

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

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

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

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

Figure 3-6: Steps to Reach Attached Mode

 

Remote Attached Mode

In general, the Remote Attached Mode is used by devices that have no local microcontroller connected to the Configuration Interface to control local INIC functionality, such as resource management. There can be a local microcontroller connected to the Application Interface though to handle application specific tasks.

In Figure 3-7 this device is called “Remote INIC”. All functionality is remotely controlled and must be handled by a remote application. In Figure 3-7 this device is called “INIC on Root Node”.

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

Figure 3-7: Remote Control Command Sequence

 

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

 

In Remote Attached Mode the FBlock INIC is visible to the 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 network side are only executable in Remote Attached 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 Attached Mode.

Table 3-4: Limited Write Operations

Operation
INIC.DevicePowerOff.SetGet()
INIC.DeviceAttach.StartResult()
INIC.NetworkStartup.StartResult()
INIC.NetworkStartupExt.StartResult()
INIC.NetworkShutdown.StartResult()
INIC.NetworkRBD.StartResult()
INIC.NetworkForceNotAvailable.SetGet()
INIC.NetworkDiagnosisFullDuplex.StartResult()
INIC.NetworkDiagnosisFullDuplexEnd.StartResult()
INIC.NetworkDiagnosisHalfDuplex.StartResult()
INIC.NetworkDiagnosisHalfDuplexEnd.StartResult()
INIC.NetworkFallback.StartResult()
INIC.NetworkFallbackEnd.StartResult()
Note 1: For details refer to Section 2.2 .

Application Interface

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

The application interface is shown in Figure 3-8 .

Figure 3-8: Application Interface

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

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

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

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

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

Operation Modes

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

• • Protected Mode – no network access
• • Attached Mode – network access

 

Figure 3-9: Application Interface Modes

 

Protected Mode

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

The Protected Mode incorporates the following sub states:

• Cleanup

• Wait for local EHC

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

 

Cleanup

The transition to the cleanup state can be triggered by synchronization loss, which can occur on the MCM PMP channel under the conditions as shown in Figure 3-9 . Loss of synchronization can be based on different criteria, such as:

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

 

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

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

 

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

 

Wait for local EHC

This state is entered after the cleanup has been finished and the INIC is configured to be EHC controlled.

 

Attached Mode

The Attached Mode is entered as soon as the EHC has finished MCM PMP channel synchronization or after it has finished DI2C message channel synchronization.

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

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

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

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

Configuration

As outlined in Section 24.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.

Remote Administration

Remote administration is used for administrative purposes, such as the programming of the configuration and identification strings, on a dedicated device. During the remote administration phase, the INIC

• • reports Availability = NotAvailable (device is not available for application communication),
• • reports AvailabilityInfo = Diagnosis and
• • gets a temporarily assigned AdminNodeAddress.

To enter the remote administration phase, the network must be in NetInterface state NetOn. The remote administration phase is started with ExtendedNetworkControl.Welcome.StartResult() by assigning a temporary AdminNodeAddress.

The remote administration phase is left by either a transition to NetOff or by sending an ExtendedNetworkControl.Init.Start() message.

Power Management

Configuration

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

The behavior of a power-off request 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 the power management interface indicates the respective power state conditions, property Action On STP can trigger an RBD or network startup, 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 155 .

Power States

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:

• • A change of the power state signaled by the power management interface
• • A change in the operation mode (on a transition to Protected Mode or on a transition to Attached Mode)
• • Timer Power Off Time has expired
• • INIC.DevicePowerOff() message was received
• • INIC.NetworkForceNotAvailable() message was received
• • Start of Ring Break Diagnosis failed
• • Start of network startup failed

 

Figure 4-1: Power States

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

Figure 4-2: Power State is U Normal

 

Figure 4-3: Power State is U Low

 

Figure 4-4: Power State is STP

 

Figure 4-5: Power State is U Critical

 

Network Management

NetInterface

The INIC contains a network 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.

 

Figure 5-1: NetInterface State Diagram

Startup

By command or network activity

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

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

By power management interface

Another way for the TimingMaster to start the network is checking the power states at the power management interface. The feature can be enabled in the configuration string by selecting NetworkStartup in property Action On STP, which allows for additional property settings.

A network startup can be triggered by power state STP, see Table 4-1 . If a network startup should be executed on every INIC reset and no voltage levels need to be handled, STP can be signaled 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 via the power management interface 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 has been triggered by the power management interface, an additional network startup on STP is no longer possible, until the INIC goes through reset again.

The INIC starts the network on an STP 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 if the Auto Forced Not Available Time timer has expired. To avoid an Auto Forced Not Available Time timer expiration, the EHC has to attach to the INIC within Auto Forced Not Available Time or the Auto Forced Not Available Time timer has to be set to 0xFFFF, which is not recommended.

Failed

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

Reasons for a failed network startup are as follows:

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

In addition, a 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 either the INIC.NetworkStartup() or the INIC.NetworkStartupExt() function, an immediate error is returned. A new startup is only possible after the error state has been cleared.

Available

If the startup was successful, the network and its port(s) will enter the available state, meaning INIC.NetworkStatus.Availability (see page 164 ) and INIC.NetworkPortStatus.Availability (see page 190 ) 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.

Automatically established network channels

A TimingMaster device can automatically establish the following network channels:

• • Control channel – This channel has a size that is fixed to 4 bytes. It is reserved in the header of the network frame when the network has become Available . In this state, all devices are granted access to the channel.
• • Proxy channel – This channel size is defined by parameter ProxyChannelBW of the INIC.Network- StartupExt() function. The channel is established in front of the packet channel within the network frame. Hence, the lowest frame byte index that can be used for mapping connection labels is 0x0C. Only devices that have Network sockets created with a static (mapped) connection label are granted access to this area.
• • Packet channel – This channel is defined by parameter PacketBW of either the INIC.NetworkStartup() or the INIC.NetworkStartupExt() function. All devices are granted access to this area.

For streaming purposes, the remainder of the network frame is available for dynamic allocation of connection labels. All devices that have Network sockets created for which the INIC is responsible to manage bandwidth reservations are granted access to this area.

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

As soon as the network is available, the last valid NodePosition and MaxPosition are returned within INIC.NetworkStatus() . 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.NetworkStatus() and the valid FreeStreamingBW in INIC.NetworkPortStatus() are reported.

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

Shutdown

By command

Similar to the network startup scenario, the network shutdown function call INIC.NetworkShutdown() can also occur at the same time on several nodes, see page 174 . 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 the INIC.NetworkShutdown() function is called again, the running shutdown process will not be affected. If the network shutdown is initiated by the INIC.NetworkShutdown() function and the shutdown process has been finished, the status is returned. The result is delayed and sent after t Restart is expired; hence an immediate startup procedure can be initiated.

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

By error

An error shutdown can have different reasons:

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

AvailabilityTransitionCause indicates the reason for the network shutdown trigger.

NotAvailable

When the network starts the shutdown process, AvailabilityInfo changes to NotAvailable in INIC.NetworkStatus() (see page 164 ) and in INIC.NetworkPortStatus() (see page 190 ). NotAvailable indicates that the network is in NetInterface Off state.

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

Network Diagnosis

The network diagnosis can be utilized to detect network disruptions between two network devices. A diagnosis phase must be explicitly started by using dedicated diagnoses functions.

The network diagnosis comprises the following diagnoses modes:

• • Centralized Diagnosis, which covers half-duplex and full-duplex diagnoses and
• • Ring Break Diagnosis, which is the legacy diagnosis mode.

Physical Layer Diagnosis

Physical Layer Test

Note: This functionality is chip-specific.
For details refer to Chip_PhysicalLayerTest .

The INIC provides integrated functions to support testing of the physical layer.

For executing the test, a Physical Layer Stress Test Tool (PhLSTT) is needed. The tool must be connected via the network 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 23.4 ) in the INIC to start the Physical Layer Test and to retrieve the corresponding result.

At the beginning of the test the INIC switches to RetimedBypassTimingMaster or RetimedBypassTimingSlave , 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 network is in NotAvailable state and AvailabilityInfo is Diagnosis .

Figure 5-2: Physical Layer Test Flow

 

Fallback Operation

Fallback operation is a functional mode that can be entered for application use cases in which for example the network has been physically interrupted, but still should be able to sustain Synchronous Streaming data communication and limited control communication.

Using this mode implies a change of the communication direction – the standard communication direction is switched to the opposite direction. It also means that the functionality of the TimingMaster will be shifted to another network device. Hence, another network device must take over the role of a TimingMaster to preserve communication.

During Fallback operation, network communication is limited and it is no longer possible to reach all network devices – from now on device communication can only happen in downstream direction in the guarded chain of the network. The guarded chain is that section that contains devices which have been defined as Guard or Monitor via property Fallback Mode in the configuration string.

The Fallback operation consists of the following phases:

Initiation/trigger phase

In this phase the communication over the network flows in standard direction.

• • The Fallback mode is initiated via INIC.NetworkFallback.StartResult() function, see Section 23.2.3.14 .
• • The initiator acts as a TimingMaster. All guards switch to Fallback mode trigger phase.

Master negotiation phase

In this phase, the network switches the communication direction from standard direction to opposite direction. This phase is also used to determine the new TimingMaster.

• • The master negotiation phase is triggered by the ExtendedNetworkControl.ReverseRequest.-
  StartResult() message, see Section 23.4.10 . The message is sent as broadcast and received by all network nodes. Only devices that have been configured as Guard will take an action.
  Devices not configured as Guard will ignore this phase.
• • The new TimingMaster is defined; this is the furthermost guard in the guarded chain that does not see any network activity at its input.

Guarded Fallback operation phase

In this phase, the network communication is still in opposite direction and will never change back.

With entering this phase, the node addresses of all devices are calculated. The node address is derived by 0x0F00 plus the node position. Once the node address has been calculated, it will not change during Fallback operation. The initiator is given a predefined node address, which is 0x0F40.

Any guard that acts as a TimingSlave will immediately take over the role as a TimingMaster in case it does not detect any longer network activity at its input.

Once a guard has switched from TimingSlave to TimingMaster mode, it will remain in TimingMaster mode, even though it may detect network activity at its input again. As a consequence, the guarded chain will shrink with respect to the number of active nodes if additional TimingMaster shifts occur.

• • This phase cannot be left, except:
• - Power off or a reset is applied to the device or
• - an exit timer has been defined. The exit timer, t_Back, must be sent with the ExtendedNetworkControl.ReverseRequest() function.

Events

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

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

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

Addressing

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

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

NetBlock

The FBlock NetBlock incorporates all functions that are relevant for network management. These functions have been implemented in the FBlock NetBlock according to the definitions prescribed in the FunctionBlock NetBlock, Rev. 3.0.3 [1] 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 23.1 .

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

NetworkMaster

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

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

NetworkMaster Shadow

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

ExtendedNetworkControl

Note: This functionality is chip-specific.
For details refer to Section 2.2.4 .

The FBlock ExtendedNetworkControl provides functions which are used to administer the INIC. In contrast to FBlock INIC, FBlock ExtendedNetworkControl is accessible from 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:

• • Centralized Diagnosis
• • Remote administration
• • Node Discovery, if enabled
• • Physical Layer Test execution
• • Memory read and write functionality (see Section 23.4.14 and Section 23.4.15 )

Resource Management

Resource Objects

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

The INIC supports a limited number of concurrent resources that are administrated in the respective resource tables; therefore a free slot in the resource table is reserved on-demand by the call to the specific resource create function, e.g., INIC.NetworkSocketCreate() . 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. For information on handles refer to Section 7.2 .

Table 7-1 shows the assignment between object type, resource identifier and number of resource table elements.

Note: Availability of resource objects is chip-specific, see Section 2.2 .

Resource Handles

Resources are referenced by a resource handle, which is used to uniquely identify a resource object. A resource handle is a 16-bit value that is a combination of the resource identifier and an object identifier. The object identifier is either the index pointing to the associated resource table or a user-defined tag.

The resource identifier is stored in the high byte and the object identifier is stored in the low byte.

Figure 7-1: Resource Handles

Every resource object has always an associated index handle.

To an index handle a tag handle can be created as an alias. A tag handle can only coexist with an existing index handle. Both handles can be used equivalent as a resource handle within the API. If a resource gets destroyed, both handles will become invalid.

An invalid resource handle has the value 0xFFFF.

Resource Builder

The INIC provides a resource builder mechanism to assist an EHC in creating resources configured in the INIC’s configuration string. For this purpose, the configuration string enables up to four configurations. Each configuration is a collection of parameters for a Streaming Port socket, a Network socket and a synchronous connection.

The Streaming Port configuration is set independently of the resource builder configurations.

Network sockets only support static connection labels. These labels are located in the proxy area of the network channel.

Configurations can be always triggered to be created by the EHC using the FBlock INIC API function INIC.ResourceBuilder() , see Section 23.2.12.6 .

While using INIC.ResourceBuilder() , a so-called collection handle is returned together with handles for each of the created resources. The collection handle may be used instead of the individual handles with INIC.ResourceDestroy() .

Resources created by the resource builder mechanism are automatically tagged, see Table 7-3 .

In addition, resources can be built automatically on an event set in the configuration string, see Auto-Build Trigger.

Resource Destruction

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

INIC.ResourceDestroy() , see page 248 , 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 should be considered as successfully destroyed, while all resource handles after the failed handle in the list are unprocessed.

Resource States

A resource can be in one of the following states:

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

While an Invalid resource state requires the resource to be destroyed (see Section 7.4 ), 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.6.1 .

Figure 7-2: State Diagram of a Monitored Connection

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

Monitoring

The INIC contains a resource monitor that monitors the states of resources and handles the muting. As long as it does not require attention from the EHC, it is in State OK . In the case there are events that require the EHC to take an action, the resource monitor enters the state ActionRequired , and notifies the EHC. It stays in this state until the EHC requests the resource monitor to reset itself. Resetting the resource monitor means that it will return to the default state and release the MUTE pin, if it was configured as Enabled , see MUTE 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.6.2.1 can be extended by implementing the muting concept, see Section 7.6.2.2 .

EHC Implementation

Without Muting

When the EHC receives a ResourceMonitor.Status(ActionRequired) , it must check for any invalid resources and destroy all of them, see Figure 7-3 . It does this by first sending ResourceInvalidList.Get() , which will return invalid handles in the order they must be destroyed. The invalid resource handles are returned in ResourceDestroy.StartResult() , see page 248 . 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 ResourceMonitor.Set(Reset) from the EHC 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 such that no special consideration has to be taken to the destruction rules. The sorting is required since 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-3 depicts a recommendation for a proper EHC implementation without considering the muting concept. An EHC example implementation with muting is shown in Section 7.6.2.2 .

 

Figure 7-3: EHC Implementation Proposal for Resource Handling without Muting

 

With Muting

Figure 7-4 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: EHC Implementation Proposal for Resource Handling with Muting

Application Examples

Temporarily Invalid Connections

Figure 7-5 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 has deasserted the MUTE pin, it unmutes the devices; however, it must mute immediately if the MUTE pin has been asserted high again .

Figure 7-5: Unlock with Temporarily Invalid Connection

 

Permanently Invalidated Connections

Figure 7-6 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. Multiple reads may be required to obtain all invalid handles in the list. The EHC may not be able to pass all the received handles to the destroy function and must then send multiple destroy requests. For simplicity it can request the list again after each completed destruction, the destroyed handles are then removed. In the figure it is assumed that all the handles could be sent in the final destroy.

Figure 7-6: Permanently Invalidated Connection

 

 

Events That Make a Resource Invalid

INIC continuously monitors events that render created resources invalid. The following sections give an overview of possible events.

Routing Budget

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

Configuration

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

Transceiver Mode

This configuration setting defines the transceiver mode to be used.

Behavior for INICs that provide two Network Ports

A Network Port can be set to Used or Unused either by customization of the Configuration String or via the INIC.NetworkPortUsed() function, see page 192 .

Port Mode

This configuration setting defines the initial operation mode of the Network Port.

Proxy Channel

A proxy channel is a reserved network frame area that is used for streaming transmission. To configure this area as reserved is up to the system integrator. The reservation is executed by the INIC (TimingMaster) on network startup.

Within this reserved area, connection labels can be mapped to individual frame bytes. The correct frame byte mapping is in the responsibility of the system integrator and must be done according to the following rules:

• • The frame bytes must be consecutive - a gap in-between the frame bytes is not allowed
• • The connection label value denotes the highest index of the frame bytes used

A mapped connection label is a static connection label; it remains on the network as long as the network is available (it is not deallocated dynamically). A static connection label has the highest bit set to indicate that it is static, once the Network socket is created. The range of valid values goes from 0x800C to 0x817F, for both input- and output sockets.

Sockets

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

Each Network socket requires a routing channel according to the data type for which it is created, see Section 2.2.1 .

To establish data routing, the Network socket must connect to a Network Port using the NetworkPortHandle.

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 channel used, see Section 21.4 .

Configuration

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

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. The port will be destroyed when the INIC enters Protected Mode.

Clock Config

The clock configuration setting provides various speed grades 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.

Sockets

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

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 MediaLB 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 .

Packet Multiplexing

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

Figure 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 ).

Figure 9-1: Packet Multiplexing

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

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

Table 9-2: Packet Multiplexing – Physical Channel Allocation

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

 

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

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

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

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

 

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

 

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

 

Requirements

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

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

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

A/V Packetized

For A/V Packetized connections the number of required bulk transactions per 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 21.4.1 .

Synchronous

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

Control and Packet

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

Configuration

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

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. The port will be destroyed when the INIC enters Protected Mode.

PhysicalLayer

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

DeviceInterfaces

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

The following device interfaces are supported:

• • Control Interface

This interface provides endpoints that can be used for the communication of control messages. Available OUT and IN endpoints are Chip_USBCtrlEpOutAddr and Chip_USBCtrlEpInAddr .

• • Packet Interface

This interface provides endpoints that can be used for USB socket creation, restricted to the packet data type. Available OUT and IN endpoints are Chip_USBPktEpOutAddr and Chip_USBPktEpInAddr .

• • IPC Packet Interface
  This interface provides endpoints 0x0D (OUT) and 0x8D (IN). These endpoints can be used for IPC packet communication. For more information on IPC packet connections refer to Section 20.4 .
• • Streaming Interface

This interface provides a configurable amount of maximum 10 (OUT) and 10 (IN) endpoints, see Chip_USBStreamMaxEpCnt . If the configured range of endpoints overlaps the control and/or the packet interface, the amount of available endpoints is reduced. Streaming interface endpoints can be used for USB socket creation, restricted to the Sync and AVPacketized data types.
The USB Port configuration specifies the number of endpoints for each direction. Endpoint allocation starts with the endpoint number 1 (endpoint address 0x01 for the OUT, and endpoint address 0x81 for the IN direction).

Sockets

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

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 212 . The endpoint address used to create sockets must be made available by the port configuration when 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 21.0 for details.

For general socket information refer to Section 7.1.2 .

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

Padding in Synchronous Bulk Transactions

Since the duration of the network frame is six times shorter than the duration of one USB microframe, the minimum number of FramesPerTransaction must be 7. The maximum number of FramesPerTransaction (‘n’) depends on the Network socket bandwidth. The number of data bytes per transaction must not exceed 512 bytes. Therefore, FramesPerTransaction multiplied with the specified Network socket bandwidth must be less than or equal to 512 bytes, as shown in the example below.

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

Example:

The synchronous socket bandwidth is 28 bytes. The value defined in parameter FramesPerTransaction is 0x000F. The calculated number of bytes is 420 bytes; this is a valid number since it is less than 512 bytes. Hence, the 512 byte USB microframe will be composed of 420 data bytes and 92 padded bytes.

Figure 10-1: Synchronous Bulk Transaction with Padding

 

Padding in A/V Packetized Bulk Transactions

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

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

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

 

If FramesPerTransaction is 0xFFFF, no padding is applied.

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

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

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

 

Vendor-Specific Requests

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

Descriptors