Filter
Top Products
Intel® 460GX Chipset Software Developer’s Manual 3-1
System Architecture 3
This chapter provides an explanation of the 460GX chipset’s handling of various aspects of the
system architecture. It covers coherency, ordering, interrupts and related issues.
3.1 Coherency
For any computer system, data coherency between processor caches and other elements within the
system is one of the main concerns of the system designer. In a Symmetric Multiprocessor (SMP)
system, hardware is usually required to maintain this coherency. In some instances, though,
software may assume responsibility for coherency. The use of WC (write-combining) memory
requires software to manage coherency. Coherency applies to the processor caches, the I/O sub-
system and graphics traffic. The programming model for a particular architecture determines
precisely how the hardware must behave. A loosely coupled system may require that software
guarantee that different processors which need to use the same piece of data are able to do so. For
most SMP systems, the hardware in the system guarantees that a piece of data is updated to all
processors if it is shared. For coherent data or code, there can exist only one valid version. There
may be shared copies of this data or code, but all elements in the system have the same value. If the
data is not coherent, then different elements may have different values for the identical address. For
example, non-coherent AGP traffic is not kept coherent with processor caches, since non-coherent
AGP addresses are not snooped on the bus. Coherency is related to, but different than cacheability.
3.1.1 Processor Coherency
Intel processors do not have a specific bit to specify coherency for each transaction. Data and code
are usually considered fully coherent with respect to other processors and to each other. There are
exceptions to this - such as the WC (write combining) memory type. Data that is marked as WC in
the page table will not be coherent between processors. The Itanium processor uses the standard
MESI (Modified/Exclusive/Shared/Invalid) protocol for its caches. As well, the Itanium processor,
when in EM mode, does not guarantee in hardware that the instruction caches are coherent with
data transfers. Software must flush the i-cache and reload it when self-modifying code is running.
Processors maintain coherency with each other by placing the addresses for referenced memory on
the common system bus. Each of the other processors snoops this address to see if it has the data in
any of its own caches. If one has the data unmodified, then it signals this using the HIT# pin, and
memory, since it has the latest version of that address, provides the data. Both the responding and
the requesting processors will then go to the shared state in the cache. If the snooping processor has
the data modified, it asserts the HITM pin and provides the data, since it owns the most up-to-date
copy of that address. The memory system will also take the data provided and update the copy in
SDRAM, unless the OWN# signal is active, in which case the memory is not updated.
For WB memory space the MESI protocol requires that only one processor has a copy of modified
data. Therefore if processor A is writing the data, it was required to gain ownership of the line
before updating it, and as it gained ownership the other processors in the system would have gone
to the invalid state for that line.