Introduction 1394 Open Host Controller Interface Specification Release 1.1 Printed 1/10/00 1.3.2.2 Asynchronous receive DMA The asynchronous receive DMA(AR DMA),contains two DMA controllers:the Physical Request Unit and the AR DMA controller. The Physical Request Unit takes control when a request with a physical address is received.There are three types of physical addresses:host memory addresses(corresponding to the 4Gbyte address of a typical 32-bit CPU),compare-swap management addresses,and the bus info block The AR DMA controller handles all incoming asynchronous packets not handled by the other functions in the AR DMA. It consists of two contexts,one for asynchronous response packets,and one for asynchronous request packets.Each packet is copied into the buffers described by the corresponding DMA context program.Note that received lock requests not targeted to one of the four compare-swap management registers are always handled by the AR DMA request context. It is recommended that Open HCI asynchronous receive support dual-phase retry. 1.3.2.3 Isochronous transmit DMA The isochronous transmit DMA controller supports a minimum of four isochronous transmit DMA contexts and may be implemented to support up to 32 isochronous transmit DMA contexts.Each context is used to transmit data for a single isochronous channel.Data can be transmitted from each IT DMA context during each isochronous cycle. 1.3.2.4 Isochronous receive DMA The isochronous receive DMA controller supports a minimum of four isochronous receive DMA contexts and may be implemented to support up to 32 isochronous receive DMA contexts.All but one IR DMA context is used to receive packets from a single isochronous stream(channel).One context,as selected by software,can be used to receive packets from multiple isochronous streams (channels). Isochronous packets in the receive FIFO are processed by the context configured to receive their respective isochronous channel numbers.Each DMA context can be configured to strip packet headers or include the headers and trailers when moving the packets into the buffers.In addition,each DMA context can be configured to receive exactly one packet per buffer(packet-per-buffer),concatenate packets into a stream that completely fills each of a series of buffers(buffer-fill), or concatenate a first portion of payload of each packet into one series of buffers and a second portion of payload into another separate series of buffers(dual-buffer mode). 1.3.2.5 Self-ID receive DMA Self-ID packets(received during the bus initialization self-ID phase)are automatically routed to a single designated host memory buffer by 1394 Open HCI self-ID receive DMA.Each time bus initialization occurs,the new self-ID packets will be written into the self-ID buffer from the beginning of the buffer,thereby overwriting the old self-ID packets. 1.3.3 Global unique ID(GUID)interface The optional GUID (EUI-64)interface is intended to interface to an external ROM device from which the 1394 64-bit "node_unique ID"may be loaded.If this interface is provided and an external device is present,the GUID ROM bit in the Version Register is set and the GUID shall be automatically written from the external ROM device following a hardware reset.This interface is required for Host Controllers that are intended to be used on add-in cards.The specifics of the interface to the external ROM device are outside the scope of this specification. Annex F.,"Extended Config ROM Entries,"specifies a format of the GUID ROM,if implemented,to provide vendor specific configuration ROM information and extended entries through the GUID ROM interface. Copyright 1996-2000 All rights reserved. Page5
Copyright © 1996-2000 All rights reserved. Page 5 Introduction 1394 Open Host Controller Interface Specification / Release 1.1 Printed 1/10/00 1.3.2.2 Asynchronous receive DMA The asynchronous receive DMA (AR DMA), contains two DMA controllers: the Physical Request Unit and the AR DMA controller. The Physical Request Unit takes control when a request with a physical address is received. There are three types of physical addresses: host memory addresses (corresponding to the 4Gbyte address of a typical 32-bit CPU), compare-swap management addresses, and the bus_info_block. The AR DMA controller handles all incoming asynchronous packets not handled by the other functions in the AR DMA. It consists of two contexts, one for asynchronous response packets, and one for asynchronous request packets. Each packet is copied into the buffers described by the corresponding DMA context program. Note that received lock requests not targeted to one of the four compare-swap management registers are always handled by the AR DMA request context. It is recommended that Open HCI asynchronous receive support dual-phase retry. 1.3.2.3 Isochronous transmit DMA The isochronous transmit DMA controller supports a minimum of four isochronous transmit DMA contexts and may be implemented to support up to 32 isochronous transmit DMA contexts. Each context is used to transmit data for a single isochronous channel. Data can be transmitted from each IT DMA context during each isochronous cycle. 1.3.2.4 Isochronous receive DMA The isochronous receive DMA controller supports a minimum of four isochronous receive DMA contexts and may be implemented to support up to 32 isochronous receive DMA contexts. All but one IR DMA context is used to receive packets from a single isochronous stream (channel). One context, as selected by software, can be used to receive packets from multiple isochronous streams (channels). Isochronous packets in the receive FIFO are processed by the context configured to receive their respective isochronous channel numbers. Each DMA context can be configured to strip packet headers or include the headers and trailers when moving the packets into the buffers. In addition, each DMA context can be configured to receive exactly one packet per buffer (packet-per-buffer), concatenate packets into a stream that completely fills each of a series of buffers (buffer-fill), or concatenate a first portion of payload of each packet into one series of buffers and a second portion of payload into another separate series of buffers (dual-buffer mode). 1.3.2.5 Self-ID receive DMA Self-ID packets (received during the bus initialization self-ID phase) are automatically routed to a single designated host memory buffer by 1394 Open HCI self-ID receive DMA. Each time bus initialization occurs, the new self-ID packets will be written into the self-ID buffer from the beginning of the buffer, thereby overwriting the old self-ID packets. 1.3.3 Global unique ID (GUID) interface The optional GUID (EUI-64) interface is intended to interface to an external ROM device from which the 1394 64-bit "node_unique_ID" may be loaded. If this interface is provided and an external device is present, the GUID_ROM bit in the Version Register is set and the GUID shall be automatically written from the external ROM device following a hardware reset. This interface is required for Host Controllers that are intended to be used on add-in cards. The specifics of the interface to the external ROM device are outside the scope of this specification. Annex F., “Extended Config ROM Entries,” specifies a format of the GUID ROM, if implemented, to provide vendor specific configuration ROM information and extended entries through the GUID ROM interface
Introduction 1394 Open Host Controller Interface Specification Release 1.1 Printed 1/10/00 1.3.4FIF0s Data quadlets entering or leaving the FIFOs are conditionally byte-swapped.The 1394 Open HCI is designed to run in both little-endian environments(x86/PCI)and byte-swapped big-endian environments (PowerMac/PCI).Note,however, that the 1394 standard specifies that data is treated as big-endian,with the most significant byte of a doublet,quadlet,or octlet transmitted first.This means that the data coming through the FIFOs may be byte swapped if it is intended for a byte-swapped little-endian PCI like the PowerMac(two byte-swap operations leaves the data in the original big-endian 1394 format).Little-endian x86 systems may or may not want the data byte swapped,so there is an Open HCI control flag to enable byte swapping for 1394 packet data. 1.3.4.1 Asynchronous transmit FIFOs The asynchronous transmit FIFOs are temporary storage for non-isochronous packets that will be sent from the Host Controller to devices on 1394.The asynchronous request FIFO is loaded by the asynchronous request DMA unit,the asynchronous response FIFO is loaded by the asynchronous response DMA unit and the physical response FIFO is loaded by the physical DMA response unit. It is not required that these FIFOs be implemented as separate physical entities.A single FIFO may be used for all asyn- chronous transmit packets as long as the implementation prevents pending asynchronous requests and asynchronous responses from blocking each other.For example,if a read request is being sent to a 1394 device that is returning ack_busy,this shall not prevent responses from either the physical DMA unit or the asynchronous response unit from being sent.Furthermore,a busied response from the asynchronous response unit shall not block responses from the physical DMA unit.Other sections of this specification will provide implementation guidelines that will help ensure that the non-blocking requirements can be met with a single asynchronous transmit FIFO. 1.3.4.2 Isochronous transmit FIFO The isochronous transmit FIFO is temporary storage for the isochronous transmit data.It is filled by the ITDMA and is emptied by the transmitter. 1.3.4.3 Receive FIFOs Conceptually there are several receive FIFOs for handling incoming asynchronous requests,asynchronous responses, isochronous packets and self-ID packets.The FIFOs are used as a staging area for packets which will be routed to the appropriate handler.There is no requirement on the number of hardware FIFOs that shall be implemented to provide the required functionality set forth in this document.However,any specific FIFO implementation shall ensure that physical requests,asynchronous requests,asynchronous responses,isochronous packets,and self-ID receive contexts proceed independently and do not block each other. For example,if a unified receive FIFO is used and the transaction layer request queue is busy or stopped,all other received packet types (physical requests,asynchronous responses,isochronous packets,and self-ID packets)shall still pass through the FIFO and be delivered to the transaction layer or host bus interface.Other sections of this specification will provide implementation guidelines that will help ensure that the non-blocking requirements can be met with a single receive FIFO. 1.3.5 Link The link module sends packets which appear at the transmit FIFO interfaces,and places correctly addressed packets into the receive FIFO.It includes the following features. Transmits and receives correctly formatted 1394 serial bus packets. .Generates the appropriate acknowledge for all received asynchronous packets,including support for both the single and dual phase retry protocol for received packets. Page 6 Copyright 1996-2000 All rights reserved
Page 6 Copyright © 1996-2000 All rights reserved. Introduction 1394 Open Host Controller Interface Specification / Release 1.1 Printed 1/10/00 1.3.4 FIFOs Data quadlets entering or leaving the FIFOs are conditionally byte-swapped. The 1394 Open HCI is designed to run in both little-endian environments (x86/PCI) and byte-swapped big-endian environments (PowerMac/PCI). Note, however, that the 1394 standard specifies that data is treated as big-endian, with the most significant byte of a doublet, quadlet, or octlet transmitted first. This means that the data coming through the FIFOs may be byte swapped if it is intended for a byte-swapped little-endian PCI like the PowerMac (two byte-swap operations leaves the data in the original big-endian 1394 format). Little-endian x86 systems may or may not want the data byte swapped, so there is an Open HCI control flag to enable byte swapping for 1394 packet data. 1.3.4.1 Asynchronous transmit FIFOs The asynchronous transmit FIFOs are temporary storage for non-isochronous packets that will be sent from the Host Controller to devices on 1394. The asynchronous request FIFO is loaded by the asynchronous request DMA unit, the asynchronous response FIFO is loaded by the asynchronous response DMA unit and the physical response FIFO is loaded by the physical DMA response unit. It is not required that these FIFOs be implemented as separate physical entities. A single FIFO may be used for all asynchronous transmit packets as long as the implementation prevents pending asynchronous requests and asynchronous responses from blocking each other. For example, if a read request is being sent to a 1394 device that is returning ack_busy, this shall not prevent responses from either the physical DMA unit or the asynchronous response unit from being sent. Furthermore, a busied response from the asynchronous response unit shall not block responses from the physical DMA unit. Other sections of this specification will provide implementation guidelines that will help ensure that the non-blocking requirements can be met with a single asynchronous transmit FIFO. 1.3.4.2 Isochronous transmit FIFO The isochronous transmit FIFO is temporary storage for the isochronous transmit data. It is filled by the ITDMA and is emptied by the transmitter. 1.3.4.3 Receive FIFOs Conceptually there are several receive FIFOs for handling incoming asynchronous requests, asynchronous responses, isochronous packets and self-ID packets. The FIFOs are used as a staging area for packets which will be routed to the appropriate handler. There is no requirement on the number of hardware FIFOs that shall be implemented to provide the required functionality set forth in this document. However, any specific FIFO implementation shall ensure that physical requests, asynchronous requests, asynchronous responses, isochronous packets, and self-ID receive contexts proceed independently and do not block each other. For example, if a unified receive FIFO is used and the transaction layer request queue is busy or stopped, all other received packet types (physical requests, asynchronous responses, isochronous packets, and self-ID packets) shall still pass through the FIFO and be delivered to the transaction layer or host bus interface. Other sections of this specification will provide implementation guidelines that will help ensure that the non-blocking requirements can be met with a single receive FIFO. 1.3.5 Link The link module sends packets which appear at the transmit FIFO interfaces, and places correctly addressed packets into the receive FIFO. It includes the following features. • Transmits and receives correctly formatted 1394 serial bus packets. • Generates the appropriate acknowledge for all received asynchronous packets, including support for both the single and dual phase retry protocol for received packets
Introduction 1394 Open Host Controller Interface Specification/Release 1.1 Printed 1/10/00 Performs the function of cycle master. Generates and checks 32-bit CRC. Detects missing cycle start packets. Interfaces to 1394 PHY registers. Receives isochronous packets at all times(does not ignore isochronous packets received outside of the expected pe- riod between cycle start and a subaction gap).This supports asynchronous streams and allows isochronous data to be received even if there is a CRC error in a received cycle start. Ignores asynchronous packets received during the isochronous phase (such packets are not ack'ed and isochronous phase continues). The acknowledges generated by the link depend on the type of received packet,the address and the state of the Open HCI FIFOs: Table 1-2-Link generated acknowledges Acknowledge Condition ack_complete A packet with good CRC in both the header and data block(if there is one)and which also falls into one of the following classifications: a)Any response that is accepted from 1394. b) A write request with the offset address between 48'h0!and the configurable (optional)PhysicalUpperBound-1 or 48'0000_FFFF_FFFF when i)posted writes are enabled,ii)the request will be handled as a physical request,and iii)the number of outstanding posted writes is within the implementation specific limit. c)A write request with the offset address between either the configurable (optional) PhysicalUpperBound or 48'h0001_0000_0000,and 48'hFFFE FFFF_FFFF that can be fully copied into the host memory receive buffer. NOTE:For further information on implementation requirements for posted writes,see Section 3.3.3. ack pending A packet with good CRC in both the header and data block(if there is one)and which also falls into one of the following classifications: a) Any read request that can be fully loaded into the receive buffer. b)Any lock request that can be fully loaded into the receive buffer. c) Any block request with a non-zero extended tcode. d) A write request with the offset address between 48'hFFFF_0000_0000 and 48'hFFFF_FFFF_FFFF(the top 4GB,which includes the register space)that can be fully loaded into the receive buffer. ack _busy X, Any received packet with a good CRC in both the header and data block (if there is one)that ack busy A, cannot be fully loaded into the receive buffer.This acknowledge is also sent when a packet is ack busy_B received with a valid header CRC and either a invalid data CRC or a data length err.The choice of_X,A,or B depends on the choice of acknowledge algorithm and the particular"rt"value of the received packet. ack data_error Open HCI's compliant with Release 1.1 shall not send ack_data_error(see section 8.4.2.2). ack_type_error For a block write request with a good CRC in both the header and data block,this error ack: May be returned when the data length is larger than the size indicated in the max rec field of the Bus_Info Block of the Host Controller. Shall be returned if data length is larger than max rec and the request is not handled by the physical response unit. For a block read request with a good CRC in the header,this error ack may be returned when the data length is larger than the size indicated in the max rec field of the Bus Info Block of the Host Controller and the request is handled by the physical response unit. Numeric notation description is given in section 2.1.2 Copyright1996-2000 All rights reserved. Page7
Copyright © 1996-2000 All rights reserved. Page 7 Introduction 1394 Open Host Controller Interface Specification / Release 1.1 Printed 1/10/00 • Performs the function of cycle master. • Generates and checks 32-bit CRC. • Detects missing cycle start packets. • Interfaces to 1394 PHY registers. • Receives isochronous packets at all times (does not ignore isochronous packets received outside of the expected period between cycle start and a subaction gap). This supports asynchronous streams and allows isochronous data to be received even if there is a CRC error in a received cycle start. • Ignores asynchronous packets received during the isochronous phase (such packets are not ack’ed and isochronous phase continues). The acknowledges generated by the link depend on the type of received packet, the address and the state of the Open HCI FIFOs: 1 Numeric notation description is given in section 2.1.2 Table 1-2 — Link generated acknowledges Acknowledge Condition ack_complete A packet with good CRC in both the header and data block (if there is one) and which also falls into one of the following classifications: a) Any response that is accepted from 1394. b) A write request with the offset address between 48’h01 and the configurable (optional) PhysicalUpperBound-1 or 48’0000_FFFF_FFFF when i) posted writes are enabled, ii) the request will be handled as a physical request, and iii) the number of outstanding posted writes is within the implementation specific limit. c) A write request with the offset address between either the configurable (optional) PhysicalUpperBound or 48’h0001_0000_0000, and 48’hFFFE_FFFF_FFFF that can be fully copied into the host memory receive buffer. NOTE: For further information on implementation requirements for posted writes, see Section 3.3.3. ack_pending A packet with good CRC in both the header and data block (if there is one) and which also falls into one of the following classifications: a) Any read request that can be fully loaded into the receive buffer. b) Any lock request that can be fully loaded into the receive buffer. c) Any block request with a non-zero extended tcode. d) A write request with the offset address between 48’hFFFF_0000_0000 and 48’hFFFF_FFFF_FFFF (the top 4GB, which includes the register space) that can be fully loaded into the receive buffer. ack_busy_X, ack_busy_A, ack_busy_B Any received packet with a good CRC in both the header and data block (if there is one) that cannot be fully loaded into the receive buffer. This acknowledge is also sent when a packet is received with a valid header CRC and either a invalid data CRC or a data length err. The choice of _X, _A, or _B depends on the choice of acknowledge algorithm and the particular “rt” value of the received packet. ack_data_error Open HCI’s compliant with Release 1.1 shall not send ack_data_error (see section 8.4.2.2). ack_type_error For a block write request with a good CRC in both the header and data block, this error ack: • May be returned when the data_length is larger than the size indicated in the max_rec field of the Bus_Info_Block of the Host Controller. • Shall be returned if data_length is larger than max_rec and the request is not handled by the physical response unit. For a block read request with a good CRC in the header, this error ack may be returned when the data length is larger than the size indicated in the max_rec field of the Bus_Info_Block of the Host Controller and the request is handled by the physical response unit
Introduction 1394 Open Host Controller Interface Specification Release 1.1 Printed 1/10/00 1.4 Software interface overview There are three basic means by which software communicates with the 1394 Open HCI:registers,DMA,and interrupts. 1.4.1 Registers The host architecture(PCI,for example)is responsible for mapping the 1394 Open HCI's registers into a portion of the host's address space. In the normal operation of some systems,the SCLK clock signal from the PHY may not be present.The Host Controller may be unable to service requests to certain registers without the SCLK signal.If a register access fails because the SCLK signal is not present,the Host Controller will set IntEvent.regAccessFail to communicate this error.When a register access fails the Host Controller shall not signal a host bus error.Failed read operations return undefined values,and failed write operations shall have no effects. 1.4.2 DMA operation DMA transfers in the 1394 Open HCI are accomplished through one of two methods: a) DMA.Memory resident data structures are used to describe lists of data buffers.The 1394 Open HCI automatically sequences through this buffer descriptor list.This data structure also contains status information regarding the transfers.Upon completion of each data transfer,the DMA controller conditionally updates the corresponding DMA Context Command and conditionally interrupts the processor so it can observe the status of the transaction.A set of registers within the 1394 Open HCI is used to initialize each DMA context and to perform control actions such as starting the transfer. b) Physical response DMA.The 1394 Open HCI can be programmed to accept 1394 read and write transactions as reads and writes to host memory space.In this mode,the 1394 Open HCI acts as a bus bridge from 1394 into host memory The formats for the data sent and received in all these modes are specified in the applicable chapters. 1.4.3 Interrupts When any DMA transfer completes (or aborts)an interrupt can be sent to the host system.In addition to the interrupt sources which correspond to each DMA context completion,there is also a set of interrupts which correspond to other 1394 Open HCI functions/units.For example,one of these interrupts could be sent when a selflD packet stream has been received. The processor interrupt line is controlled by the IntEvent and IntMask registers.The IntEvent register indicates which interrupt events have occurred,and the IntMask register is used to enable selected interrupts.Software writes to the IntEventClear register to clear interrupt conditions in IntEvent. In addition,there are registers used by the isochronous transmit and isochronous receive controllers to indicate interrupt conditions for each context. Page 8 Copyright 1996-2000 All rights reserved
Page 8 Copyright © 1996-2000 All rights reserved. Introduction 1394 Open Host Controller Interface Specification / Release 1.1 Printed 1/10/00 1.4 Software interface overview There are three basic means by which software communicates with the 1394 Open HCI: registers, DMA, and interrupts. 1.4.1 Registers The host architecture (PCI, for example) is responsible for mapping the 1394 Open HCI’s registers into a portion of the host’s address space. In the normal operation of some systems, the SCLK clock signal from the PHY may not be present. The Host Controller may be unable to service requests to certain registers without the SCLK signal. If a register access fails because the SCLK signal is not present, the Host Controller will set IntEvent.regAccessFail to communicate this error. When a register access fails the Host Controller shall not signal a host bus error. Failed read operations return undefined values, and failed write operations shall have no effects. 1.4.2 DMA operation DMA transfers in the 1394 Open HCI are accomplished through one of two methods: a) DMA. Memory resident data structures are used to describe lists of data buffers. The 1394 Open HCI automatically sequences through this buffer descriptor list. This data structure also contains status information regarding the transfers. Upon completion of each data transfer, the DMA controller conditionally updates the corresponding DMA Context Command and conditionally interrupts the processor so it can observe the status of the transaction. A set of registers within the 1394 Open HCI is used to initialize each DMA context and to perform control actions such as starting the transfer. b) Physical response DMA. The 1394 Open HCI can be programmed to accept 1394 read and write transactions as reads and writes to host memory space. In this mode, the 1394 Open HCI acts as a bus bridge from 1394 into host memory. The formats for the data sent and received in all these modes are specified in the applicable chapters. 1.4.3 Interrupts When any DMA transfer completes (or aborts) an interrupt can be sent to the host system. In addition to the interrupt sources which correspond to each DMA context completion, there is also a set of interrupts which correspond to other 1394 Open HCI functions/units. For example, one of these interrupts could be sent when a selfID packet stream has been received. The processor interrupt line is controlled by the IntEvent and IntMask registers. The IntEvent register indicates which interrupt events have occurred, and the IntMask register is used to enable selected interrupts. Software writes to the IntEventClear register to clear interrupt conditions in IntEvent. In addition, there are registers used by the isochronous transmit and isochronous receive controllers to indicate interrupt conditions for each context
Introduction 1394 Open Host Controller Interface Specification/Release 1.1 Printed 1/10/00 1.5 1394 Open HCI Node Offset(Address)Map Open HCI divides the 48-bit node offset space as depicted below: 48'hFFFF FFFFFFFF 48'hFFFF_F000_0000 CSR Space some Physical 48'hFFFF_EFFF_FFFF Upper Address Space 48'hFFFF_0000_0000 48'hFFFE FFFF_FFFF Middle Address Space physicalUpperBound physicalUpperBound-1 Low Address Space Physical Range 48'h00000000_0000 Figure 1-2-Node Offset Map Low Address Space is from 48'h0 up to physicalUpperBound.Asynchronous read and write requests into this range can be handled by the Physical Request/Physical Response units,providing an efficient mechanism for moving asynchronous data.Whether or not a request can be handled in this manner depends on a set of criteria as described in section 12.For write requests which are handled by the Physical Request unit,the Host Controller may issue an ack_complete immediately,even before the data has been written to host memory,to maximize packet transaction efficiency (this is referred to as a Posted Write).Or,depending on circumstances,the Host Controller may instead issue an ack_pending for such requests. The physicalUpperBound is an optional register that some Host Controllers may implement which provides a means to change the upper bound of the low address space.If not implemented,the Host Controller shall use a default physical upper bound of 48'h0001_0000_0000,which provides a physical range of 4GB.If implemented,systems use the physicalUpperBound register to increase the size of the Physical Range. Middle Address Space is from physicalUpperBound through 48'hFFFE_FFFF_FFFF.Packets with destination offsets within this range are not candidates for handling by the Physical Request/Response units,and are instead passed to software for processing.Although there will be added latency while software performs processing,the Host Controller nevertheless issues an ack complete for all write requests within this range which normally require an ack(e.g.,broadcast write requests are never ack'ed).This is to maximize packet transaction efficiency.However,although the node that issued the write request is informed(via the ack complete)that the write succeeded,it is possible that an error occurred and that the write did not in fact reach its destination.This address range is best suited to protocols such as TCP/IP for example which have their own mechanisms for detecting and recovering from lost packets. Copyright 1996-2000 All rights reserved. Page9
Copyright © 1996-2000 All rights reserved. Page 9 Introduction 1394 Open Host Controller Interface Specification / Release 1.1 Printed 1/10/00 1.5 1394 Open HCI Node Offset (Address) Map Open HCI divides the 48-bit node offset space as depicted below: Low Address Space is from 48’h0 up to physicalUpperBound. Asynchronous read and write requests into this range can be handled by the Physical Request/Physical Response units, providing an efficient mechanism for moving asynchronous data. Whether or not a request can be handled in this manner depends on a set of criteria as described in section 12. For write requests which are handled by the Physical Request unit, the Host Controller may issue an ack_complete immediately, even before the data has been written to host memory, to maximize packet transaction efficiency (this is referred to as a Posted Write). Or, depending on circumstances, the Host Controller may instead issue an ack_pending for such requests. The physicalUpperBound is an optional register that some Host Controllers may implement which provides a means to change the upper bound of the low address space. If not implemented, the Host Controller shall use a default physical upper bound of 48’h0001_0000_0000, which provides a physical range of 4GB. If implemented, systems use the physicalUpperBound register to increase the size of the Physical Range. Middle Address Space is from physicalUpperBound through 48’hFFFE_FFFF_FFFF. Packets with destination offsets within this range are not candidates for handling by the Physical Request/Response units, and are instead passed to software for processing. Although there will be added latency while software performs processing, the Host Controller nevertheless issues an ack_complete for all write requests within this range which normally require an ack (e.g., broadcast write requests are never ack’ed). This is to maximize packet transaction efficiency. However, although the node that issued the write request is informed (via the ack_complete) that the write succeeded, it is possible that an error occurred and that the write did not in fact reach its destination. This address range is best suited to protocols such as TCP/IP for example which have their own mechanisms for detecting and recovering from lost packets. Figure 1-2 — Node Offset Map 48’h0000_0000_0000 48’hFFFF_FFFF_FFFF } Physical Range physicalUpperBound -1 physicalUpperBound 48’hFFFE_FFFF_FFFF 48’hFFFF_0000_0000 Low Address Space Middle Address Space Upper Address Space CSR Space } some Physical 48’hFFFF_F000_0000 48’hFFFF_EFFF_FFFF