26.11.2014 Views

System Management Bus (SMBus) Specification, version 2.

System Management Bus (SMBus) Specification, version 2.

System Management Bus (SMBus) Specification, version 2.

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

<strong>System</strong> <strong>Management</strong> <strong>Bus</strong> (SM<strong>Bus</strong>) <strong>Specification</strong> Version <strong>2.</strong>0<br />

<strong>2.</strong> If a pre-assigned unique ID is used, at least 16-bits must be unique. However, 32-bits is<br />

recommended.<br />

3. If a random number is implemented in this field, Random Number Requirements must be met.<br />

4. Devices that support a fixed device address must still implement this field but not uniquely.<br />

Uniqueness is important to guarantee that two like devices are identified discretely. It is the<br />

responsibility of the device/system manufacturer to determine the possibility of like devices, and<br />

the mechanism for providing uniqueness via the UDID and slave address fields.<br />

5.6.1.6. Random number requirements<br />

If a random number is utilized the following requirements must be met:<br />

1. It must be at least 16 bits in length.<br />

<strong>2.</strong> The device is not allowed to support a persistent slave address.<br />

3. The device is not allowed to support fixed addresses. (If the device has a fixed address mode, the<br />

Vendor Specific ID should be a constant, and therefore not random – this is required to guarantee that<br />

the SM<strong>Bus</strong> ARP resolution order is maintained)<br />

4. The random number must be retained while the device has power with the exceptions described in<br />

items 5 and 6.<br />

5. The random number must be regenerated when the device receives the Reset Device command.<br />

6. The random number must be regenerated when the device senses a bus collision during a read<br />

operation directed to its Assigned Slave Address. When this happens, the device must issue a host<br />

notify protocol if the device supports it.<br />

5.6.<strong>2.</strong> Power-on reset<br />

Power-on reset is described in section 3.1.4.<strong>2.</strong> In the case of ARP-capable devices, ‘operational state’<br />

implies the ability to respond to ARP commands as required in this section.<br />

Each slave device must fit into only one of these categories and must obey the power on reset state:<br />

Device Type AR Flag AV Flag SMB Address UDID<br />

PSA<br />

CLEAR Read from Read from NVR; NO CHANGE<br />

(Persistent Slave Address)<br />

NVR<br />

undefined if AV<br />

Flag is CLEAR<br />

Non-PSA / Non-Random Number CLEAR CLEAR undefined NO CHANGE<br />

Non-PSA / Random Number CLEAR CLEAR undefined Generate Random<br />

Number<br />

Table 6: Internal state of ARP-capable devices on power-on reset<br />

5.6.3. ARP commands<br />

The ARP Master can issue general commands and directed commands. A general command is targeted at<br />

all devices and is required for the address resolution process. A directed command is targeted at a single<br />

device. All packets originated by the ARP Master use Packet Error Checking (See Section 7.5) and begin<br />

with the basic format:<br />

<br />

SBS Implementers Forum 38

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!