Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!princeton!allegra!amdcad!rpw3 From: rpw3@amdcad.UUCP Newsgroups: comp.arch Subject: Re: Word vs. Byte Orientation Message-ID: <16174@amdcad.AMD.COM> Date: Wed, 15-Apr-87 19:55:09 EST Article-I.D.: amdcad.16174 Posted: Wed Apr 15 19:55:09 1987 Date-Received: Sun, 19-Apr-87 05:51:48 EST References: <16122@amdcad.AMD.COM> <16125@amdcad.AMD.COM> <305@winchester.mips.UUCP> Reply-To: rpw3@amdcad.UUCP (Rob Warnock) Organization: [Consultant] San Mateo, CA Lines: 107 Keywords: bus-width byte word Summary: Can still use old 8-bit chips In article <305@winchester.mips.UUCP> mash@winchester.UUCP (John Mashey) writes: >In article <16125@amdcad.AMD.COM> phil@amdcad.UUCP (Phil Ngai) writes: >>[...sequence begun by inconvenience of I/O Controllers and >> word-addressing, with rebuttals, and comments....] [...then some bemoaning the difficulties of interfacing old chips...] >>If we're talking about building new controllers there's no reason why >>you couldn't give each register its own word. It uses a little more >>address space but only a few bytes more, nothing really. Note that you can do the same thing with the older chips, by using "partial address decode" in your I/O address decoders. Say you have a chip with an 8-bit data path, and it has 16 internal registers (byte-wide) which are addresses with A<3:0>. Simply connect chip D<7:0> to bus D<7:0>, and connect chip A<3:0> to bus A<5:2>, and there you are -- "word-addressed" registers. Of course, you'll read garbage on D<31:8>, so if you want to avoid masking that in software, you should add some gates to drive zeros on D<31:8> whenever an 8-bit device is being read. This need exist only once per system, and can be enabled by the central I/O decode system or, if you have plug-in cards with 8-bit I/O on them, can be a common bus line that such devices pull when they are being read. (Exercise for the reader: Make this work if you have a mix of 8- & 16-bit devices, without adding any extra "zero" drivers. Hint: You may have to add another common bus line.) If you put on your hardware/software tradeoff hat, you'll remember that we have all been through this before, in one form or another. Nobody "waited" for Motorola to come out with 68k peripheral chips, we just took our old favorite Z-80 (or whatever) peripherals and glued them on. <> Sometimes the solutions get really weird, such as once when I had to use Z-80 PIO chips to build a 16-bit PIO. But I needed to be able to talk to the Z-80 PIOs separately, since only one set of registers on each was involved in the 16-bit thing. Solution? Use "unary decoding" in the address decoder. (Now that address space is really cheap, at least in the I/O sub- systems, we shouldn't forget this ancient but useful technique.) "Unary decode" or "unit select" or linear selection" (it never really had a standard name) means using a single bit of the address space to select a device (usually using some high-order binary-decode field to say we were doing this, so as not to chew up the WHOLE address space!) In this way, if you turn on more than one address bit at a time (in the affected range), you select ALL of the addressed devices! (Obviously, not good for reading, unless they drive different bits on the data bus.) So for example, let's say we have a 32-bit word machine, and we want to create a 32-bit parallel register for some I/O function, and for some godawful reason we want to use Z-80 PIOs to do this, rather than 74F374's. (Look, contrived examples are contrived, o.k.?) So use four Z-80 PIOs, and put each PIO on a separate byte of the data bus. Then let's say that address 0x87650000 enables this whole mess as a unit (that is, we tie up 64K of address space -- no biggy). Then give the upper unit (the one on D<31:24>) a unit select address of 0x8000, the next 0x4000, and so on. Finally, wire each chip's address <1:0> to bus A<3:2>. (There is another, even weirder way to do this, described below.) So to simultaneously access Register 2 of all the chips, use the address 0x8765F008. To access Register 1 of the D<23:16> chip (but no others), use the address 0x87654004 (but remember that the data is going in and out on bits <23:16>, so your code has to shift/mask). If you wanted to, this arrangement could give you three 32-bit registers, or six 16-bit ones, or twelve 8-bit registers, OR... one 32-bit register plus two 16-bit plus four 8-bit, etc. (permutations ad nauseum). If you want to get even weirder (as mentioned above), wire the address lines of the PIOs to separate bit fields (we've got plenty), for example, the <31:24> PIO's A<1:0> could be wired to bus A<11:10> (mask 0xC00), the <23:16> PIO's A<1:0> to A<9:8> (mask 0x300), etc. Then to simultaneously access register 0 of the high byte, register 1 of the next, register 2 of the next, and register 3 of the low (<7:0>) byte use address 0x8765F1B0. [I know, I know, PIOs only have 3 data regs.] Actually, if I were to do this again, I would probably allocate the addresses a bit differently, putting the unit select and the register address in a separate nybble for each PIO, making hex debugging easier. In that case, you's use address 0x87658888 to access reg0 of all chips, and 0x876589AB to get the weird ripple addressing of the previous example. <> Finally, the existence of 8- or 16- or 32-bit "peripheral chips" is not going to make any difference at all the the deployment of the new 32-bit processors, since any good-sized system is going to have complete CPUs as I/O processors anyway, and it's on the I/O processor that such games as the above examples will be played. The real factor will be the bandwidth *and* latency of the channel between the "main" CPU (or CPUs, in an mP system) and the I/O system as a whole. Note that for development reasons one may choose to use the same processor chip on the I/O system as for the "main" CPU(s), but it's on the I/O system that the compatibility interface with 8-bit chips will take place. [Counter-point: We may find these new 32-bit chips also being used in "embedded controller" applications for traditional mainframes, where some of the bit-tweaking above still applies.] Rob Warnock Systems Architecture Consultant UUCP: {amdcad,fortune,sun,attmail}!redwood!rpw3 ATTmail: !rpw3 DDD: (415)572-2607 USPS: 627 26th Ave, San Mateo, CA 94403