WO2009062952A1

WO2009062952A1 - Communication interface and scan message for scanning link properties and writing link settings

Info

Publication number: WO2009062952A1
Application number: PCT/EP2008/065378
Authority: WO
Inventors: Gerrit Willem Besten
Original assignee: Nxp B.V.
Priority date: 2007-11-12
Filing date: 2008-11-12
Publication date: 2009-05-22

Abstract

The invention relates to a communication interface in which one or more control commands in at least on operating mode is exploited to scan the overall link properties.

Description

COMMUNICATION INTERFACE AND SCAN MESSAGE FOR SCANNING LINK PROPERTIES AND WRITING LINK SETTINGS

FIELD OF THE INVENTION

High-speed serial data communication networks are typically build-up from point-to-point connections; Routers, switches, and/or hubs are used to extend the network beyond two devices. This is illustrated in Fig. 1.

In a communication interface that include optional and/or configurable features, where not all allowed possibilities are supported, there needs to be a method to exchange information between the devices at both ends in order to make sure that the system is operated at settings which are supported by both sides.

If the devices at both ends include the complete interface stack including protocol and physical/electrical layers, it is pretty straightforward to define an interaction between the two sides using packets/messages to exchange the properties of the other side. It is assumed that the local properties are known by the local protocol.

However, this requires involvement of the higher level protocols. This implies that devices, that do not include (almost) the complete protocol stack, are not accessible themselves and their properties cannot be set or read, also not for the layers that are still present, for example PHY layer and/or the lower level protocols.

In many cases that is not a problem, but it is a restriction that can be cumbersome.

It is therefore an object of the invention to overcome the above problem. The invention is defined by the independent claims. Dependent claims describe advantageous embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be describes using the following figures in which Fig.1 depicts a state of the art system;

Fig 2 depicts an embodiment of the invention

Fig. 3 depicts a chain of devices; and

Fig. 4 a state diagram according to the invention. DETAIL DESCRIPTION OF THE EMBODIMENTS

An example case for which this is important is shown in Fig. 2. The 2 devices at the ends of the complete chain of point-to-point links contain the full interface stack and can exchange their properties with messages in the higher protocol layers. However, the devices C and D in between the end-points have restricted functionality.

These can be there for instance as repeaters or conversion devices towards another transmission medium.

Their behavior is such that device B wouldn't suffer from the fact that there are other devices between device A and B, if the settings of all devices are matched.

However, the properties of devices C and D still needs to be known to select the correct settings in device A and B.

Implicit in this reasoning is that it is possible to find a commonly supported setting. This can be enforced by requiring (in a standards or specification document) baseline functionality and performance, with incremental optional upgrade possibilities. This ensures that the actual settings are bounded by the capabilities of least advanced device. Note that with multiple independent optional choices the 'least advanced device' must be considered for each option individually.

The invention provides a method to access the properties of C and D without involving the higher level protocols.

Assume a communication interface includes at least one interface mode, which supports at least one control command, next to commands to initiated one or mode data transmission modes. Furthermore, assume that all devices support at least one base operation setting. If a command in the base operating mode is assigned for 'scan' functionality, the first device of a chain can send the 'scan' command. Because this is in the base operating mode, this is by definition supported by all devices in the chain. All devices receiving this command will add their properties to the command and forward it. Adding information can be done in multiple ways. For example, device may concatenate a fixed amount of property- data to the incoming command plus 'scanned data' of preceding devices. This can be any length, but for example be two bytes per device. Alternatively the amount of data per device might be flexible. In order to distinguish the information of device, a length counter can be added to individual scan results of each device or by separating all results with recognizable delimiter control sequences. In order to make sure that each device does not need to interpret all data, a length counter can be included in or after the 'scan' command (so before scan data) to indicate to what size the scanned data has accumulated. Furthermore it can be indicated how many devices are already scanned. Furthermore a 'type of scan' identifier can be added to include for example writing feature to the scan concept (next to the described reading concept) Furthermore the can include specific actions to a certain specific device or type of device.

Not all these features are required simultaneously.

Any subset that provides sufficient info to interpret the information is also covered by this invention. Any method to include information inside or add information after the command can be used for implementations of this invention. Furthermore any order of fields like for example counters, device numbers, type of scan, can be used or even be (partial) together be encrypted in another format.

In practical cases typically one or maybe a few alternatives will be used. Next to reading-out properties, it is advantageous if the settings can be adapted.

It should be noted that the scan is operating in one direction. In the example of figure 2, finally, device B knows the properties of devices A, C, and D.

In order to configure the link there needs to be interaction between devices A and B. Therefore, if the link also needs to be configured, it is assumed that there is some return connection available. In many cases this will be a similar channel including a similar chain of devices, but this is not required for the invention. This invention just needs a means to return the scanned data to the originating device.

Although not restricted to this case, in the further description it is assumed that complete link consists of a link based on the similar PHY in both directions (not necessarily with the same properties or the same amount of devices, see figure 3) and that the end-to-end negotiation on the chain of device will be handled by higher level protocol layers.

Because for example a protocol like UniPRO contains a configuration protocol inside the higher protocol layers, this can be exploited for the end-point interaction. Via this configuration protocol device A gets to know the properties of devices C, D, and B. This means that device A has all information to determine the optimal settings.

Note that the invention is not limited to the number of devices or link compositions as mentioned in the examples. There can be any number of devices in the chain for each direction individually. Note that typically the devices at the end of the chain have a higher layer protocol stack, while the devices in between have a reduced or no higher layer protocol stack at all.

Although the intermediate device may include higher level protocol layers, these are then not used for the scanning of the chain. In can be defined in and controlled by the higher level protocols where the 'scan chains' start and end. Of course the start and end points must be devices that includes a higher level protocol stack.

If the composition is not a chain but a branched network, the scanning concept can also be used. Either the branch-point are devices with a higher protocol stack, which means that a certain chain of device can be appointed in the network to scan, by setting the connections in the desired way. Otherwise the signal might get broadcasted to multiple destination at the point where the network branches. In that case the scan results can be found at two or more endpoint, partially including the same information, which actually provides information about the network topology and which might be exploited at protocol level. Although the scan can also be exploited for roundtrip checks, this requires a correlation between the two directions at low level. It is beneficial to keep the directions independent at low level. For the scan (write-part of the) concept it is sufficient that a return path exist. Of course the return path itself may include a similar scan mechanism (but separately accessed by the protocol for the other side of the chain). Advantage of this approach is that for the physical/electrical interface layers the directions (data lanes) are independent, which provides maximum freedom to both lower (no correlation between input and output ports at PHY level) and higher protocol layers (usage of lanes is very flexible).

Now that device A has all info, it can 'scan' the chain again, but in writing mode, such that after this scan all devices in the chain can start to operate at the desirable settings. This may differ from the maximum performance setting if there is a system benefit for that like power consumption. However in many case it will be set to best performance match.

If the chosen settings are identical for all devices in the chain, the writing scan may do with a single settings write field. Of course, 'scan' concept also allows implementations which are capable to address each device individually with respect to writing settings or address devices with particular properties. This can be done conceptually similar to the before-described 'read scan', but then including 'write' setting fields and indications for where they need to go. Notice that with the scan read/write concept described it is also possible to add additional features, like for example switching branches and/or enabling/disabling outputs, on devices that do not includes higher layer protocols with switch/router capabilities. In a realization of this method, the control commands may exploit one (or more) control symbol(s) to indicate specific actions. Alternatively, a sequence starting from a certain known-state may always be considered as control command. An illustration of this can be found in the example state-machine, which is described here after: The first sequence of bits after entering 'CONTROL' mode is always interpreted as command for the next action.

Optional features and configurable items include, but are not restricted to:

Multiple transmission mode with different signaling schemes (for example Duty-Cycle Modulation and Non-Return-to-Zero).

Multiple speed grades for each transmission mode Terminated or unterminated far-end of the transmission line for NRZ symbol- coded transmission

Transmit drive levels

EXAMPLE CASE: Fig. 4 shown a state-machine of a system including this principle.

The system includes a SLEEP mode where the interconnect lines are at a defined and static state. If there is activity on the lines the system automatically changes to CONTROL mode (meaning a constant signal with opposite polarity for a period in order to settle the biases, followed by DCM encoded bits (for coding see figure 5 and patent 111). The first series of DCM encoded bits indicate the command to be executed. Not all commands need to have the same length, which allows to differentiate between fast actions and slower actions, as long as the set of command is interpretable without ambiguity.

Next to the high-lighted 'scan' mode, the diagram contains multiple other modes/features which are accessed via other commands. This may for example include 'back to SLEEP', going into HIBERnation (ultra low power state, but keeping all state information to do a recovery without a RESET involved), different data transmission schemes (DCM, NRZ) both encoded (e.g. 8Bl OB) to provide control symbols, CONFIG(uration) to configure the local device to the requested settings (possibly received via the SCAN or from higher protocol layers) On the left side the states SHUT, RESET, BOOT and OFF states are shown. SHUT is a 'determined-OFF' -state, which is exploited to prepare total link power-down. SHUT can keep certain state information if the device is not de-powered. Both

OFF and SHUT go through an initialization process via BOOT and RESET to SLEEP if the link needs to be powered-up.

Notice that on the right hand side of the state-machine there is a connection from DCM transmission straight into NRZ transmission. Because the DCM contains explicit clock information, this can be used both to transmit data in DCM mode and as synchronization sequence for the NRZ transmission mode. After a first order synchronization (while transporting data) the link can switch over to NRZ mode. Probably at that moment a short fine (re)sync is required, but this can be rather fast. This means the synchronization time it not lost but re-used for slower data transfer. Alternatively the NRZ transmission is accessed via the control mode but this requires a similar synchronization time which is not exploited for data transfer. This latter approach is the default approach in conventional systems. This more advanced feature via DCM transmission is more efficient.

The DCM and NRZ transmission processes include transmit schemes based on a line coding (e.g. 8Bl OB) including data and control symbols. Control symbols can for example be used for symbol synchronization, packet delimiting, start and end of transmission sequences, idling, skip-codes, and triggers. Notice that the bit signaling of DCM and NRZ transmission is apparently different, but the symbol encoding on top of the bit 'encoding' can be chosen to be different or the same.

It must be noticed that this example state diagram includes different standby states (SLEEP, SNOOZE, HIBER) to balance the needs power consumption and recovery time.

SLEEP and SNOOZE are both static unterminated line states to minimize static power consumption, but SNOOZE return immediately to high-speed Embedded-Clock transmission (e.g. 8Bl OB encoded), with predefined settings, enabling fast recovery. In SLEEP mode lower power consumption can be achieved and it allows all control options when returning to CONTROL state, but it takes more time to access the high-speed transmission modes compared to the SNOOZE state. The NRZ bit stream, with a symbol encoding must indicate whether the link returns to SNOOZE or CONTROL state after transmission of a burst. This can for example be done with a field identifying this choice which is added to the end of transmission burst possibly combined with the end of transmission signaling (options are to use different control code words for end-of- transmission or use a combination of a control code with a parameter field.

In order to switch signaling and or termination scheme, the line signals and/or devices need require settling time which can be accommodated for by insertion of sacrificial spacer sequences. For example, to switch-on the termination, the line can keep a fixed drive level for a sufficiently long period to ensure settling. The required settling time typically becomes shorter for physically short links. However, for the base operation settings the worst case situation needs to be accounted for. It should be noted that many alternatives state-diagram are possible where not all features, states, modes of connections of the state-diagram(s) are present. Furthermore not-shown additional features, states and connection might be present as far as they do not hamper the concept of the system.

Claims

CLAIMS:

1. A communication interface in which one or more control commands in at least on operating mode is exploited to scan the overall link properties.

2. A communication interface in which one or more control commands in at least on operating mode is exploited to write the overall link configurable setting.

3. A communication interface in which the same command and mode is used for both claim

4. A scan message that contains besides the command code also a field that includes in any order or format: device counter information, scan info length counter information, type of action identifier, and/or content for read data, and/or write data, or any subset of these, possibly extended with other parameter information

5. A scan message that transported through a chain of devices where each device concatenates its properties to the incoming message and forward the adapted message to the next device.

6. A scan message that transported through a chain of devices where each device concatenates its properties in a fixed field length to the incoming message and forward the adapted message to the next device.

7. A scan message that transported through a chain of devices where each device concatenates its properties in a flexible field length to the incoming message and forward the adapted message to the next device. The length of the information field is indicated in the field itself or the fields are separated by control symbols

8. A scan message that transported through a chain of devices where one particular device in the chain is addressed based on one of more detectable properties of that device.

9. A scan message that transported through a chain of devices to write matched settings through the whole chain of devices

10. A scan message that transported through a chain of devices to write settings to particular device in the chain of devices, based on detectable properties of these devices.