Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!amdcad!phil
From: phil@amdcad.UUCP
Newsgroups: comp.arch
Subject: Re: Word vs. Byte Orientation (really about nasty hardware)
Message-ID: <16167@amdcad.AMD.COM>
Date: Wed, 15-Apr-87 13:49:08 EST
Article-I.D.: amdcad.16167
Posted: Wed Apr 15 13:49:08 1987
Date-Received: Fri, 17-Apr-87 03:22:49 EST
References: <16122@amdcad.AMD.COM> <16125@amdcad.AMD.COM> <305@winchester.mips.UUCP>
Reply-To: phil@amdcad.UUCP (Phil Ngai)
Organization: Advanced Micro Devices, Inc., Sunnyvale, Ca.
Lines: 64

In article <305@winchester.mips.UUCP> mash@winchester.UUCP (John Mashey) writes:
>>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.
>
>Yes, this is clearly the thing to do. I've been assuming that part of the
>logic behind all of this is to expect AMD to come out with carefully-
>designed controller chips that do this [which will help us all anyway].
>However, it is sad but true, that when you go to build densely-packed
>high-performance systems, your choice is often limited.
>I.e., the original posting was a current and near-term reality analysis,
>not a "how it should really be" discussion.

I think my point has been overlooked here. The question of whether a
chip's registers appear at byte, 16-bit, or 32-bit boundaries is
outside of the control of the chip designer. The board designer
determines this. 

To be boringly explicit about this, consider a chip with 8 registers.
You'll get 3 address pins (call them CA0, CA1, CA2) to select one of
the 8 registers and a Chip Select line (CS) to select the chip. Now,
if the board designer connects these three address lines to the low 3
address lines on the boards (CA0-BA0, CA1-BA1, CA2-BA2), the registers
will appear at byte boundaries. If the board designer skips the bottom
address line and instead hooks up (CA0-BA1, CA1-BA2, CA2-BA3), the
registers will appear at 16-bit boundaries. Finally, (CA0-BA2,
CA1-BA3, CA2-BA4) will space the registers on 32-bit boundaries. 

There are other problems associated with trying to fit all the needed
functionality into a limited number of pins but register placement is
not one of them. 

If you're not tired of reading about hardware yet, consider the
interface of the Z8530, a dual serial communications controller. Let
us consider just one half of the device, the other half is essentially
identical.  It has only one control "register" at the chip interface
level, (it has a data register too). First, you load the register with
a pointer value in the range 0-15 and then access the actual register,
one of 15. The problem comes in dealing with interrupts. If one comes
in after the pointer is loaded and before the actual register is used,
and the interrupt handler needs to use the SCC, two bad things happen.
1) the IH thinks it is writing a pointer when it is really writing a
register 2) after the IH returns, the routine thinks it is writing a
register but the chip thinks it is receiving a pointer. 

The only way to deal with this is to use a software locking mechanism
to reserve the SCC, since it has this hidden state. Unfortunately,
this makes using a DMA controller rather hard, since it won't respect
any software locks. Rather, the DMA controller must be turned off
before accessing the SCC. 

This interface saves three pins. Even though I design hardware, I
think this is incredibly ugly. 

Let's not talk about write only registers, chips with weird timing
dependencies (the SCC has a cycle recovery time requirement.  When I
first used it, I thought I could just warn the programmers about the
problem. But they don't read the board manual so I put in extra
hardware to hide the cycle recovery time.) and registers with inverted
logic and other atrocities perpetrated on helpless programmers by
narrow-minded or otherwise mis-guided hardware engineers. 

-- 
Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or amdcad!phil@decwrl.dec.com