Documente Academic
Documente Profesional
Documente Cultură
Decentralized
Decentralized arbitration there isn't an arbiter, so the devices have to decide who goes next. This makes the devices more complicated, but saves the expense of having an arbiter.
Multibus
uses three lines: an Arbitration line, Busy line, and a Bus Request Line
Busy
once a device has determined that no other device is using the bus, or a device with a higher priority is using the bus it asserts this line, deemed the BUSY line. This will let all other devices that this device is using the bus. Once the BUSY line is asserted, the OUT line is asserted.
Bus Request
This line indicates whether another device has made a request. If Busy is negated, then the device negates OUT and waits an undetermined amount of time to see if its IN will be negated.
Bus Mastering
Defn: Refers to a feature supported by some bus architectures that
enables a controller connected to the bus to communicate directly with other devices on the bus without going through the CPU. Normally, the processor is required to control the transfer of this information. In essence, the processor is a "middleman", It is far more efficient to "cut out" the middleman and perform the transfer directly. This is done by having capable devices take control of the bus and do the work themselves. In theory this frees up the processor to do other work simultaneously.
ISA (Industry
Standard
Architecture)
Bus mastering really hasnt been successful with the ISA bus. Any ISA device
can take control of the bus, but it must be done with caution. There are no safety mechanisms involved, so if a device incorrectly takes control of the bus, it may crash the system. For example, we all know the DRAM needs to be refreshed periodically. If the ISA bus master doesnt relinquish control of the bus every 15 ms, to generate its own DRAM refresh, the DRAM will become corrupted. To take control of the bus, the device first asserts its DRQ line. The DMAC sends a hold request to the CPU, and when the DMAC receives a hold acknowledge, it asserts the appropriate DAK line corresponding to the DRQ line asserted. The device is now the bus master. AEN is asserted, so if the device wishes to access I/O devices, it must assert MASTER16 to release AEN. Control of the bus is returned to the system board by releasing DRQ.
MCA (Micro
channel Architecture)
The MCA bus was IBM's attempt to replace the ISA bus with something
"bigger and better". When the 80386DX was introduced in the mid-80s with its 32-bit data bus, IBM decided to create a bus to match this width. MCA is 32 bits wide, and offers several significant improvements over ISA. (One of MCA's disadvantages was rather poor DMA controller circuitry.) The main idea behind the MCA bus was, instead of constraining the computer to working on one problem at a time, multiple problems can be approached simultaneously. It allows the bus to be used by two or more bus masters at the same time, by setting up a control system for coordinating their operations. The way this is accomplished is by using a master/slave concept. If two or more devices via-ing for the bus. The bus slave functions just as an ordinary expansion device in a non-mastering PC. The difference between the bus master and the bus slave is entirely functional. In the MCA scheme one bus master can take control over another, making the second its slave. Later the two devices can reverse their roles when another situation demands it.
MCA (Micro
EISA (extended
Introduced in 1987, the EISA bus was AST Researchs, Compaqs, Epsons,
Hewlett Packards, NECs, Olivettis, Tandys, WYSEs, and Zenith Data Systemss answer to IBMs MCA Bus. The EISA Bus provided 32-bit slots at an 8.33 MHz cycle rate for the use with 386DX, or higher processors. Some of the Key features of this bus are: ISA Compatibility: ISA cards would work in EISA slots. 32 bit bus: Like MCA this bus was expanded to 32 bits. Giving it a throughput of 31.8 MBs Bus Mastering: supported bus mastering cards for greater performance, including bus arbitration PnP: EISA automatically configures adapter cards, similar to the Plug and Play standards of modern systems. There were two main reasons for the downfall of the EISA bus architecture: 1: EISA based systems tended to be more expensive 2: There just werent many EISA-based cards available
The VESA (Video Electronics Standards Association) a nonprofit organization founded by NEC, released the VLB or VESA Local Bus in 1992. The VLB is a 32-bit bus that gave direct access to the system memory at the speed of the processor, commonly the 486 CPU. Unfortunately, because the VLB heavily relied on the 486 processor when the Pentium Processor arose in the Market place. The VLB is in a way a direct extension of the 486 processor/memory bus. A VLB slot is a 16-bit ISA slot with third and fourth slot connectors added on the end. The VLB normally runs at 33 MHz with a total Bandwidth of 127.2 MBs, although higher speeds are possible on some systems. Since it is an extension of the ISA bus, an ISA card can be used in a VLB slot, although it makes sense to use the regular ISA slots first and leave the (small number of) VLB slots open for VLB cards, which won't work in an ISA slot of course. Use of a VLB video card and I/O controller greatly increases system performance over an ISA-only system. Four reasons for its downfall were:
1: The bus was heavily based on Intels 486, so adapting it to the Pentium was difficult 2: Tricky electronics. Not many cards could be supported on the bus, namely one or two. And even when more than one expansion card was used, there were timing problems 3: No bus arbitration scheme 4: No PnP support
DMA (Direct
Memory Access)
bus architectures that allows data to be transferred to and from RAM without burdening the CPU. This is accomplished by a DMA controller chip. In addition some add-on cards need to transfer data to the systems memory through a DMA channel. Each expansion card which supports DMA uses at least one DMA channel. The PC supports up to 7 DMA channels (though some of these are not compatible with all expansion cards). No two expansion cards can be using the same DMA channel at the same time (and only a few cards support sharing of a DMA channel when they are not using it). You must select a DMA channel which is not used by another card installed in the computer (sound cards frequently use one or even two DMA channels), and configure it for that DMA channel. If you accidentally choose a DMA channel which another card is using, the symptom is usually that no DMA transfers take place. No data is acquired or if the conflict is with a sound card, sounds may not play.
DMA (cont)
How is works: The peripheral (a LAN adapter, for example) writes from its
memory directly to the PC's memory in one bus cycle (reducing the load on the bus), rather than the two-step process of the CPU's DMA controller first reading the data (from the adapter) and then writing it to the PC's memory in a second bus cycle. Often, the adapter will do its transfer as the data are received from the LAN, so no, or little, on-board LAN adapter memory is required (this saves money). Uses much less CPU time than other methods. For example, programmed input-output (PIO) requires the CPU to first check for the availability of the data, then read the data, and then write the data. This requires bus and CPU time for both fetching the CPU's instructions and for reading and writing the data. Also, bus master DMA is faster than standard DMA, since the CPU does not even need to load the DMA registers (for example, with the source and destination addresses) to set up each transfer.
Addresses on the 370 are 24 bits and device addresses are only 16 bits. The leftmost eight bits are set to zero. Eight bits are used to designate the channel allowing up to 256 channels. The next four bits indicate the control unit in the channel. The last four bits designate the device within the control unit. When more than one routes are available, then a device will have a different address for each path.
Bibliography
http://www.pcguide.com/ref/mbsys/buses/types/index.htm http://www.webopedia.com Heath, Chet and Rosch, L. Winn The Micro Channel architecture. Simon &
Schuster, Inc., 1990. Cormier, R., Dugan, R., Guyette, R. "System/370 Extended Architecture: The Channel Subsystem" IBM Journal of Research and Development. May 1983. IBM Corp. IBM System/370: Principals of Operation. GA22-7000-9. May, 1983. IBM Corp. IBM System/370 Extended Architecture: Principals of Operation. SA22-7085-0. May, 1983.