mch@computing-maths.cardiff.ac.uk (Major Kano) (06/17/88)
In my earlier posting, I cannot have explained clearly what I meant. The few replies that I saw/recieved suggested that there was no point in putting write-only or read-only registers at different addresses. Now that's all very well, but what I was trying to get at was why the **** have write-only control registers or read-only status registers AT ALL ? I do not like the idea of not being able to read from a register that I've written to. Maybe this is just paranoid and OS's should keep a copy ANYWAY of whatever they load into a chip, but you can bet your next three pay checks that SOMEDAY there will be a situation where a register must be read from; eg., a faulty privileged program has used a chip before it was killed, and you (the OS or super-user) have to know EXACTLY what it did. Any comments ? Regards, -- Martin C. Howe, University College Cardiff | "Can YOU do the Milano Mosh ?" mch@vax1.computing-maths.cardiff.ac.uk. | -------------------------------------------+------------------------------------ These opinions are mine, but YOU can have them for just a few $$$ !
phil@amdcad.AMD.COM (Phil Ngai) (06/19/88)
In article <439@cf-cm.UUCP> mch@computing-maths.cardiff.ac.uk (Major Kano) writes: >Now that's all very well, but what I was trying to get at was why the **** have >write-only control registers or read-only status registers AT ALL ? Why have write only control registers at all? Cost. Plain and simple. It costs more to be able to read it. Whether it is worth the cost can be debated for every application. But that there can be a reason is not debatable. I don't understand what you mean about read only status registers. Most of the time it doesn't make sense to think about writing them. -- I speak for myself, not the company. Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.com
steckel@Alliant.COM (Geoff Steckel) (06/20/88)
An anecdote might make it clearer why write-only registers are a real problem,
if they share addresses with any other function.
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)stevew@nsc.nsc.com (Steve Wilson) (06/20/88)
In article <439@cf-cm.UUCP> mch@computing-maths.cardiff.ac.uk (Major Kano) writes: >In my earlier posting, I cannot have explained clearly what I meant. The few >replies that I saw/recieved suggested that there was no point in putting >write-only or read-only registers at different addresses. >Now that's all very well, but what I was trying to get at was why the **** have >write-only control registers or read-only status registers AT ALL ? > >I do not like the idea of not being able to read from a register that I've >written to. Maybe this is just paranoid and OS's should keep a copy ANYWAY >of whatever they load into a chip, but you can bet your next three pay checks >that SOMEDAY there will be a situation where a register must be read from; >eg., a faulty privileged program has used a chip before it was killed, and you >(the OS or super-user) have to know EXACTLY what it did. > >Any comments ? > >Regards, >-- >Martin C. Howe, University College Cardiff | "Can YOU do the Milano Mosh ?" >mch@vax1.computing-maths.cardiff.ac.uk. | As has been explained by others on the net, giving read-back capability is expensive in real-estate. If the decision comes down to providing read-back capability or making the design producable, guess which wins. This may sound extreme, but EVERY design I've done in the last 9 years has had this issue raised. Normally, the first place that the issue occurs isn't when considering production code, but in examining the design for testability via software. More often than I care to admit, I've had to design out testing features (read this as read-back capability) because there just wasn't enough pcb space to fit it in. In my last design, it would have cost an additional 20% in logic to provide read-back for all of the registers utilizing hugh muxes. I did come up with a solution for the testing side of the problem, though the applications using the board couldn't make use of the feature. It may be hard to believe, but hardware guys don't normally go out of their way to make life difficult for programmers. Consider that hardware guys usually would prefer having the read-back feature because it makes our life easier during initial design verification. This is an area where design trade-offs are made by hardware engineers. When the cost is not having the product versus not having read-back of ALL of the registers, the designer is forced into making decisions. It is not a trade-off that is made lightly, but it is one that occurs quite often. Steve Wilson National Semiconductor [The opinions stated previously are mine, not those of my employer.]
stevew@nsc.nsc.com (Steve Wilson) (06/21/88)
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.]
baum@Apple.COM (Allen J. Baum) (06/23/88)
[] >In article <5184@nsc.nsc.com> stevew@nsc.UUCP (Steve Wilson) writes: > >Sometimes side effects are desirable, i.e. do you want to eliminate use >of input/output fifos? >As an example, all USARTS that I'm aware of clear the data read port >after they are read. Steve also listed potential problems of such a scheme, like what happens when you RETRY, or what happens on out-of-order execution. A simple fix is to allow the FIFO, but don't advance it on a simple read; advance it explicitly, with a write operation. This fixes most of the problems, which are caused by read operations with side effects. Writes are allowed to have side effects (naturally), so there are no problems there. -- {decwrl,hplabs,ihnp4}!nsc!apple!baum (408)973-3385
radford@calgary.UUCP (Radford Neal) (06/23/88)
In article <2007@alliant.Alliant.COM>, steckel@Alliant.COM (Geoff Steckel) writes: > ... 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... I'm not sure which was more brain-damaged - the 11/04 for reading the destination, or the peripheral device for placing the read-only and write-only registers at the same address. Lest anyone think the above poster's experience was unique, I had a rather similar problem with a Motorola 68008 and an Intel timer chip (I forget its number). The timer chip required that one write the two bytes of the time interval to a register _with no intervening accesses_. The C code to do it was something like: *reg = 100; /* Low-order part of time interval */ *reg = 0; /* High-order part */ Unfortunately, the compiler (quite reasonably) implemented the last statement with a CLR instruction, and the 68008 (and 68000) does a CLR by first reading the destination... This only took about an hour to debug, since I had a hardware person with a scope on the bus lines to help in debugging (this was an embedded application in ROM - no debugging tools). I shudder to think how long it could take to find this sort of problem in another context, or with a less experienced programmer. The fact that the 68000 reads the destination of a CLR I find rather boggling. The performance penalty alone would seem to be enough to rule this out - particularly since they had the option of leaving the CLR out alltogether if it was that much of a problem, since this was the first processor of that architecture. Reading the destination on _every_ move in the 11/04 is far worse, of course... Radford Neal