CDP1020 Просмотр технического описания (PDF) - Intersil

Номер в каталоге

Компоненты Описание

Список матч

CDP1020

SMBus/I2C ACPI Dual Device Bay Controller

Intersil 

CDP1020

the CDP1020 will transmit data to the master beginning at

the CDP1020 register location pointer to by the internal

address pointer. In accordance with I2C/SMBus protocols,

the CDP1020 will continue to transmit data to the master

until it receives a negative acknowledge from the master.

NOTE: Due to the nature of the CDP1020 I2C/SMBus interface

module, a master device cannot simply end a read operation by

transmitting a stop condition. The master is required to not-

acknowledge the last byte of a read operation. Only when the

CDP1020 detects this negative acknowledge will it end transmission

and wait for another start condition.

As with write operations, the internal address pointer of the

CDP1020 will automatically increment after each byte is

transmitted during a read operation. In this way multiple

bytes can be read from the CDP1020 register space within a

single I2C/SMBus transmission.

Figure 4 demonstrates single and multiple byte read

sequences, both of which begin with a send byte command

followed by a restart and read command. This technique forces

the address pointer to the desired address prior to the read(s)

and, while not strictly necessary, is strongly recommended.

Note that writing to un-implemented registers will be ignored

(the data will not be stored anywhere). Reading

unimplemented registers will produce undefined results.

I2C/SMBus Alert Function

The CDP1020 is a slave only I2C/SMBus device. As such, it

has no capability to start a transmission on the serial bus to

notify the master of an interrupt event within the CDP1020

control logic (Interrupt events are described in more detail in

the Device Bay Control Logic text). To notify the master of

such an event, the CDP1020 implements the SMBus alert

function as detailed in the SMBus specification.

When an interrupt event (interrupt events are described in

the Device Bay Control Logic text) within the CDP1020

occurs, it will assert its ALRT signal. The ALRT pin is an

active low, open drain output that must have an external pull-

up resistor. The assertion of this signal is an indication to the

master that an interrupt condition within the CDP1020 has

occurred and needs service.

REMREQ

REMREQ_EN

DEVSTSCHG

DEVSTSCHG_EN

REMREQ

REMREQ_EN

DEVSTSCHG

DEVSTSCHG_EN

BAY 0

BAY 1

FIGURE 4. ALRT OUTPUT LOGIC

ALRT

feature of SMBus control modules (such as the PiiX4/PiiX6)

and the other way using a general purpose I/O to monitor the

ALRT signal of the CDP1020 and I2C messaging to service

the alert.

In the SMBus method, the ALRT pin of the CDP1020 should

be tied to the general purpose SMBus alert signal going into

the SMBus controller. This signal may have many other

devices connected to it in addition to the CDP1020. When

the SMBus alert line is pulled low by any of the SMBus

devices, the SMBus controller will send out an Alert

Response Address (ARA), %00011001 ($19, with the R/W

bit set). Any slave device that is currently asserting its ALRT

signal will respond to the ARA by sending the master its

slave address. If there are multiple devices asserting the

ALRT signal, they will use standard SMBus arbitration

techniques to determine ownership of the bus. Once a slave

successfully transmits a response to the ARA, it will de-

assert its ALRT signal. On the occurrence of any interrupt

event, the CDP1020 will assert its ALRT pin. Once this pin is

asserted, the CDP1020 will now respond to an SMBus ARA.

NOTE: The present CDP1020 does not support the SMBus ARA

response, but a future mask option fully implements it. The same is

true for a General Call ($00 address to broadcast to all devices on

bus). Thus, if the SMBus alert signal is used, the SMBus controller

should poll the CDP1020 (similar to the description in the next

paragraph) to determine if it created the interrupt (it can separately

issue the ARA to see if any other device responds to it; the

CDP1020 will not).

For I2C systems or SMBus systems that do not implement

the SMBus alert feature, the ALRT pin of the CDP1020

should be connected to a separate interrupt pin or general

purpose input of the I2C/SMBus master and monitored.

When the master detects that the ALRT signal of the

CDP1020 has been asserted, it should perform a read

operation on the CDP1020 using the standard read protocol

described in the previous section. If multiple devices share

the same input to the master, the software will have to check

each device to determine which one caused the Alert.

Note that if the ALRT pin is only monitored in software

(instead of using a more immediate interrupt), then the

latency needs to be considered, such that there is not a

noticeable or objectionable delay in the response time (for

example, if the user pushes the REMREQ button repeatedly,

or inserts and removes a device repeatedly because of no

apparent response).

As shown in Figure 4, the CDP1020 will only de-assert its

ALRT signal when the cause of the interrupt event is cleared

(by clearing either the status or enable bit). This is true

whether the SMBus ARA or the general purpose I/O method

is used.

The master device may respond in two different ways to the

assertion of the ALRT pin - one way using the SMBus Alert

2-425

Share Link: