Path: utzoo!attcan!uunet!husc6!purdue!decwrl!nsc!stevew
From: stevew@nsc.nsc.com (Steve Wilson)
Newsgroups: comp.arch
Subject: Re: More On Write-Only Control Registers
Keywords: read-only write-only
Message-ID: <5181@nsc.nsc.com>
Date: 21 Jun 88 16:13:56 GMT
References: <439@cf-cm.UUCP> <22150@amdcad.AMD.COM> <2007@alliant.Alliant.COM>
Reply-To: stevew@nsc.UUCP (Steve Wilson)
Organization: National Semiconductor, Sunnyvale
Lines: 60

In article <2007@alliant.Alliant.COM> steckel@alliant.UUCP (Geoff Steckel) writes:
>
>This happened with an old DEC serial interface (DZ-11 I think),
>and the PDP11/04.  The DZ-11 had a read-only input FIFO and a write-only output
>register at the same address.  With most machines, this would cause no problems.
>It required very careful coding to be sure that only READ accesses were used
>to get data from the input register, and WRITE accesses to send to the output.
>
>Unfortunately, in order to save some complexity in the 11/04 CPU, DEC had
>made the MOV instruction ALWAYS READ ITS MEMORY DESTINATION.  This meant that
>	MOV	Rn, OUTPUT_REGISTER
>would first read (and discard!) the top of the input FIFO.
>
>There was absolutely nothing that could be done to make this combination of
>CPU and peripheral work.  We wound up junking 5 11/04s, which at the time cost
>us some $50K in all, not to mention the time spent debugging mysterious lost
>input characters.
>
>      Geoff Steckel (steckel@alliant.COM)

Isn't this really a problem with the CPU architecture, and not a problem with
the I/O implementation?

What I find funny is that nobody has brought up what code optimizers tend to
do to drivers where hardware like this exists.  I've spent alot of time with
software guys who forgot to compile without the optimizer. 

All it takes is reading the value of some location, then writting too it 
again.  The optimizers have this neat idea that the read really didn't 
count since you aren't using the data.  Now this might be the best reason
of all to avoid having In and Out registers mapping to the same address.
Now-a-days I try to avoid this particular pitfall, even if I continue the
sin of having write-only registers.

A spoke with another friend of mine who had an interesting perspective on
this.  He has spent a number of years writting disk firmware.  Recently
he has put his hardware design hat back on.  He really is qualified at
both sides of the coin.  His point of view was that when there are registers
that require constant bit manipulation, that these registers should be
read and writeable. If this can't be done, he insists on placing each
bit function at a different address.  Most designs have registers which are 
usually write once and forget.  This class doesn't require read back for
normal operation. 

As has been stated by others, all of this goes begging when testing the 
design is considered either for powerup diagnostics of in manufacturing.
A good method of testing write-only registers is to implement them
with parallel-loadable shift registers.  If your read path is expensive,
(and it always is ;^) then a single readable register is necessary which
all of the other registers can be shifted into.  This allows programatic
testing of your actually registers and the write-decode logic.  Shift
register management takes some extra hardware, but there is usually a 
limited overhead of 3-5% of the board space as oppossed to the 10%-20%
that can be gobbled up by muxes.

Steve Wilson
National Semiconductor

[ The above opinions are mine only, and don't reflect those of
  my employer.]