3.3. Isolation Protocol
A simple algorithm is used to isolate each Plug and Play card. This algorithm uses the signals on the ISA bus and requires lock-step operation between the Plug and Play hardware and the isolation software.
Figure 4. Plug and Play ISA Card Isolation Algorithm
The key element of this mechanism is that each card contains a unique number, referred to as the serial identifier for the rest of the discussion. The serial identifier is a 72-bit unique, non-zero, number composed of two, 32-bit fields and an 8-bit checksum. The first 32-bit field is a vendor identifier. The other 32 bits can be any value, for example, a serial number, part of a LAN address, or a static number, as long as there will never be two cards in a single system with the same 64 bit number. The serial identifier is accessed bit-serially by the isolation logic and is used to differentiate the cards. Refer to section Serial Identifier, for further information.
Figure 5. Shifting of Serial Identifier
The shift order for all Plug and Play serial isolation and resource data is defined as bit[0], bit[1], and so on through bit[7].
3.3.1. Hardware Protocol
The isolation protocol can be invoked by the Plug and Play software at any time. The initiation key, described earlier, puts all cards into configuration mode. The hardware on each card expects 72 pairs of I/O read accesses to the READ_DATA port. The card's response to these reads depends on the value of each bit of the serial identifier which is being examined one bit at a time, in the sequence shown in figure 5.
If the current bit of the serial identifier is a "1", then the card will drive the data bus to 0x55 to complete the first I/O read cycle. If the bit is "0", then the card puts its data bus driver into high impedance. All cards in high impedance will check the data bus during the I/O read cycle to sense if another card is driving D[1:0] to "01." During the second I/O read, the card(s) that drove the 0x55, will now drive a 0xAA. All high impedance cards will check the data bus to sense if another card is driving D[1:0] to "10."
If a high impedance card sensed another card driving the data bus with the appropriate data during both cycles, then that card ceases to participate in the current iteration of card isolation. Such cards, which lose out, will participate in future iterations of the isolation protocol.
Note During each read cycle, the Plug and Play hardware drives the entire 8-bit data bus, but only checks the lower 2 bits.
If a card was driving the bus or if the card was in high impedance and did not sense another card driving the bus, then it should prepare for the next pair of I/O reads. The card shifts the serial identifier by one bit and uses the shifted bit to decide its response.
The above sequence is repeated for the entire 72-bit serial identifier.
At the end of this process, one card remains. This card is assigned a handle referred to as the Card Select Number (CSN) that will be used later to select the card. Cards which have been assigned a CSN will not participate in subsequent iterations of the isolation protocol. Cards must be assigned a CSN before they will respond to the other commands defined in the specification.
It should be noted that the protocol permits the 8-bit checksum to be stored in non-volatile memory on the card or generated by the on-card logic in real-time. The same LFSR algorithm described in the initiation key section is used in the checksum generation. The exact description of the checksum algorithm and an example are shown in Appendix B.
Plug and Play cards must not drive the IOCHRDY signal during serial isolation. However, cards may drive IOCHRDY at any other time.
3.3.2. Software Protocol
The Plug and Play software sends the initiation key to all Plug and Play cards to place them into configuration mode. The software is then ready to perform the isolation protocol.
The Plug and Play software generates 72 pairs of I/O read cycles from the READ_DATA port. The software checks the data returned from each pair of I/O reads for the 0x55 and 0xAA driven by the hardware. If both 0x55 and 0xAA are read back, then the software assumes that the hardware had a "1" bit in that position. All other results are assumed to be a "0."
During the first 64 bits, software generates a checksum using the received data. The checksum is compared with the checksum read back in the last 8 bits of the sequence.
There are two other special considerations for the software protocol. During an iteration, it is possible that the 0x55 and 0xAA combination is never detected. It is also possible that the checksum does not match. If either of these cases occur on the first iteration, it must be assumed that the READ_DATA port is in conflict. If a conflict is detected, then the READ_DATA port is relocated. The above process is repeated until a non-conflicting location for the READ_DATA port is found. The entire range between 0x200 and 0x3FF is available, however in practice it is expected that only a few locations will be tried before software determines that no Plug and Play cards are present.
During subsequent iterations, the occurrence of either of these two special cases should be interpreted as the absence of any further Plug and Play cards (i.e. the last card was found in the previous iteration). This terminates the isolation protocol.
Note The software must delay 1 msec prior to starting the first pair of isolation reads, and must wait 250 µsec between each subsequent pair of isolation reads. This delay gives the ISA card time to access information from possibly very slow storage devices.