This clause summarizes the feature sets provided by the CSR Architecture and illustrates how these features are expected to be used. The CSR Architecture supports the concept of bus bridges, which (after being prop- erly initialized) can transparently forward transactions from one compliant bus to another. This simplifies software development and encourages the use of specialized (low-cost or high-performance) bus standards. By defining a common CSR Architecture for multiple buses, the amount of customized software necessary to support each bus standard is minimized. To improve the amount of software transparency in such multiple -bus configurations, the scope of the CSR specification includes the following: a) Physical Address Space Partitions. The partitioning of the address space between node CSRs and memory is defined. Both 32 -bit and 64 -bit addressing options are allowed. b) Common Transaction Sets. A common transaction set (including error -status codes) is defined. This transaction set can be transparently passed through bridges. c) Core CSRs. The location and meaning of the core CSRs, which are accessed during the system ini- tialization process, are defined. This provides a uniform software interface, independent of the phys- ical bus location. d) 1D -ROM. The format and meaning of the node's ROM data structures are defined. The ROM direc- tory structure supports standard and vendor -dependent data types. e) Interrupts. Standard target addresses are provided for interrupts that are broadcast on the bus to all nodes, or broadcast within the node (nodecast) to multiple units. Other vendor -dependent quadlet registers may be provided for interrupts that are directed to individual units. f) Messages. Standard target addresses are provided for messages that can be broadcast or nodecast to multiple nodes. Other vendor -dependent registers may be provided for messages that are directed to individual units