Path: utzoo!attcan!uunet!pcrat!rick
From: rick@pcrat.UUCP (Rick Richardson)
Newsgroups: comp.arch
Subject: Re: Cretinous status/control register access (Was: Re: 80960 IO)
Keywords: status registers control registers IO chips uarts usarts disk serial
Message-ID: <510@pcrat.UUCP>
Date: 12 Jun 88 13:58:37 GMT
References: <3358@omepd> <10320@steinmetz.ge.com> <40@radix> <11026@mimsy.UUCP> <253@babbage.acc.virginia.edu> <1086@mcgill-vision.UUCP> <4
Reply-To: rick@pcrat.UUCP (Rick Richardson)
Organization: PC Research, Inc., Tinton Falls, NJ
Lines: 66

In article <5136@nsc.nsc.com> stevew@nsc.UUCP (Steve Wilson) writes:
>In article <418@cf-cm.UUCP> mch@computing-maths.cardiff.ac.uk (Major Kano) writes:
>>
>>   Can anyone out there who designs these things or knows more than I do (not
>>difficult :-) say why these abominations exist or if (shock horror !) there is
>>actually a good reason for it ?
>>
>
>One reason that most software guys are just gonna love is that I/O can be
>REAL expensive in hardware designs.  There is usually a single path for
>data to exit a given logic module(board or chip), and if you have 27
>local registers that are to be R/W, you've got one heck of a data funnel
>to create.  This is a favorite place of hardware types(read me here ;-)
>to make design trade-offs. 

There are several common design flaws in device register architectures
that, finally, the chip designers I work with are aware of and attempt
to avoid.  These are:

	1) Write only registers, which force software types to keep
	   a "softcopy".
	2) Poor partitioning of control functions, such that one
	   register might control both the "guzinta" and the "guzoutta"
	   functions.  The "guzinta" and the "guzoutta" software
	   might be completely ignorant of each other (read "modular")
	   except that they have to share this one lousy register.
	3) Register bank modes where you might first have to select
	   the register address, and then do your read/write.  This
	   forces critical regions in software.

Finally, even with read/write registers in the chips, not all
operations can be done with a (non-interruptible) "move", "and",
or "or" instruction into the register.  Sometimes you have to
read the old value from the register, "and" the value with a mask,
then "or" in the new control bits, and then do your write
back to the control register.  When you get this situation in
combination with the "poor partitioning" problem, your only
alternative is to shut off interrupts for this operation.  Many
times I've wished that the processor implemented a non-interruptable
read-and-or-write instruction.

Note that shutting off interrupts isn't the end of the world.
However, it annoys me because the interrupt(s) you may have to
shut off is for some other unrelated piece of software.  Again,
modularity goes out the window.

In the last three years, I've had to work with no less than 8
new peripheral chip designs that went into a product design.
Only 2 of those chip design teams failed to include input
from the software team.  Those two chip designs are the ones
that have write only registers and poor partitioning.  Those
chips are also the only chips which have limited the software
team such that some of the features that the systems engineers
wanted could not be provided.

At least one of our chip designers has listened so carefully
to the software team that his chips regularly include bunches of
creeping features.  As long as he stills brings in the chip at
the quoted price, I'll refrain from making the judgement on
whether this is a "good thing".

-- 
		Rick Richardson, President, PC Research, Inc.

(201) 542-3734 (voice, nights)   OR     (201) 834-1378 (voice, days)
uunet!pcrat!rick (UUCP)			rick%pcrat.uucp@uunet.uu.net (INTERNET)