Date: Wed, 21 May 1997 13:07:25 +0200 From: Poul-Henning Kamp <phk@dk.tfs.com> To: Stefan Esser <se@FreeBSD.ORG> Cc: doc@FreeBSD.ORG Subject: Re: isa bus and boca multiport boards Message-ID: <1808.864212845@critter> In-Reply-To: Your message of "Wed, 21 May 1997 12:16:33 %2B0200." <19970521121633.51265@x14.mi.uni-koeln.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks Stefan! Isn't this raw material for documentation ? Poul-Henning In message <19970521121633.51265@x14.mi.uni-koeln.de>, Stefan Esser writes: >On May 21, Bruce Evans <bde@zeta.org.au> wrote: >> >> On a P5/133, about 300 pointer dereferences can be >> >> done in the time it takes to do one i/o instruction. >> > >> >I know this discussion was concerning I/O ports on the ISA bus, >> >but I'm curious if you know: How long does a single I/O (read or >> >write) take when accessing an I/O port on the PCI bus? >> >> PCI accesses port accesses seem to average about 3 times faster on my >> system: >> >> Times in usec for inb() from selected ports on an ASUS P55TP4XE with >> a P5/133: >> >> min av max speed important for FreeBSD? >> ----- ----- ----- ---------------------------- >> 0x3d4 (crtc data) 0.393 0.393 0.395 no >> 0x3d5 (crtc data) 0.393 0.393 0.395 no >> 0xe428 (de0 status) 0.332 0.333 0.334 yes (if = data access speed) >> addr+0x14 (ncr0 status) 0.363 0.363 0.394 yes (if = data access s >peed) >> >> I think the minimum access time is 30 nsec for PCI. There are no signs >> of that here. Accesses can be wider than for ISA, but cheap serial >> boards based on 8-bit UARTs are unlikely to implement anything other >> than 8-bit accesses. > >No, PCI uses a bus cycle time of 30ns (33MHz) maximum, >but the shortest access latency to a single data item >is 4 bus clocks (120ns). Your fastest register accesses >seem to require 11 and 13 PCI bus cycles, though. >The NCR chip uses a 12 cycle micro-program that controls >all its operations, which explains the delay you found. > >1) The CPU has to apply all the signals for the port > access, and the host to PCI bridge has to decode > them before it can start a PCI cycle. > >2) The PCI bus may have been "parked" at some other > bus master. In order to give the output drivers > of the current master time to go into a high > impedance state, one cycle of delay is added. > >3) The adresses are driven on the address/data bus > and the byte selects are applied. The PCI chips > now have a few cycles to claim the transaction. > Each device announces its maximum decode delay > in a configuration space register, and it is > typical to specify "middle" speed, which means > one wait state is added while addresses are on > the bus. (This is controlled by a chip-set > register, which is set after the PCI BIOS has > identified the waits required by the slowest > device on the bus.) > >4) While PCI uses positive decoding of address > ranges throughout, there is one exception for > a legacy bus allowed. This means, that after > no PCI device decoded the address on the bus, > the PCI to ISA bridge will claim it and will > generate an ISA port access. > >5) If the ISA compatibility devices are part of > the PCI chip set, this chip set should claim > the transaction. (I.e. there should never be > a ISA transaction generated for accesses to > these ports.) > >6) After the PCI chip (or the PCI to ISA bridge) > has applied the DEVSEL signal, the bus has to > be turned around. This means changing the bus > owner chip, if the host to PCI bridge and the > ISA devices chip are on seperate silicon and > will add the one cycle delay to turn off the > drivers of the chip set. > >7) After the device has claimed the transaction, > it must send data after a maximum of 8 PCI bus > cycles, or it must signal a retry to the chip > set and release the bus (similar to a SCSI > diconnect, but the initiator is responsible > for retrying the transfer at a later time). > >8) After the device sent its data, it will give > up the bus. There will be another cycle of > delay, before the host to PCI bridge will be > able to put an address on the bus again ... > >9) The CPU will receive the data with some delay, > since it flows through a FIFO in the host to > PCI bridge. > >10) There appears to be a "built-in" delay in > the x86 CPUs, which adds a few wait states > independently of any delays caused by the > devices. There also are wait states added > for each I/O by the chip set (I've forgot > the name of that register, but it was some > thing like "I/O recovery"), typically 2 to > 4 cycles, IIRC. > >Regards, STefan -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1808.864212845>