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.]