miket@bnrmtv.UUCP (Michael Thompson) (04/15/89)
Greetings fellow Unix PCers, After reading various responses to my SCSI postings and talking with a few people over the phone, I have come up with three basic variations on the design of the SCSI adapter. The general ideas are each shown below in a form which I hope is easily understandable. I feel each is valid from a hardware standpoint, but the actual implementation of each varies in complexity. Following each diagram is a short listing of what I feel are the Pros and Cons for each design. Please let me know what you think. *** DESIGN #1 *** 16K Static RAM Buffer with Single Chip CPU Control of SCSI Chip TB = Tristate Bi-Directional Buffer (74LS245s) --+ | +--+ +--+ Address +------+ | | | Address Bus | | Bus | | |----------->|TB|---+-------------+--------------|TB|<--+----->| SCSI |--\ | Address | | | | | | | | Chip | > U | Bus +--+ | +------+ | +------+ +--+ | +-->| |--/ N | | | 8K | | | 8K | | | | | I | +-->| SRAM | +-->| SRAM | | | +------+ X | | | | | | | | +-->| Lo | +-->| Hi | | | +------+ P | | | Byte | | | Byte | | | | | C | | +------+ | +------+ +--|---|Single| | +--+ | | +--+ | | Chip | B |<---D0-D7-->| |<--+--------------------------->| | | | CPU | U | |TB| | |TB|<-----+-->| | S |<--D8-D15-->| |<----------------+------------->| | Data Bus | | | +--+ 8 Bit Data Busses +--+ +------+ | 16 Bit | Data Bus --+ Pros: 1 Easiest to implement in hardware. 2 Low chip count. 3 Unix device driver easy to code. 4 Buffer contention handled in Unix device driver and firmware. 5 Don't have to worry to much about timing of Unix PC bus. Cons: 1 Difficult to debug firmware on single chip CPU. 2 68010 must transfer data to buffer (slow and CPU overhead). 3 Hard to update firmware in single chip CPU. Must be burned in. 4 SCSI chip may not be able to transfer at max. rate. *** DESIGN #2 *** 16K Static RAM Buffer with DMA Control of SCSI Chip During Data Xfer TB = Tristate Bi-Directional Buffer (74LS245s) --+ | +--+ | | | Address Bus |----------->|TB|------------+---+-------------+-------------+ | Address | | | | | | U | Bus +--+ | | +------+ | +------+ | +------+ N | +------+ | | | 8K | | | 8K | | | | I | | DMA |--+ +-->| SRAM | +-->| SRAM | +-->| SCSI |--\ X | | Chip | | | | | | Chip | > | +-------------->| | +-->| Lo | +-->| Hi | +-->| |--/ P | | | 6844 | | | Byte | | | Byte | | | | C | | +------+ | +------+ | +------+ | +------+ | | +--+ | | +--+ | B |<-+-D0-D7-->| |<---------------+------------------>| | | U | |TB| | |TB|<---+ S |<--D8-D15-->| |<-----------------------------+---->| | | +--+ 8 Bit Data Bus's +--+ | 16 Bit | Data Bus --+ Pros: 1 Moderate difficulty to implement in hardware. 2 SCSI chip can transfer at max. rate. 3 No firmware. 4 Buffer contention handled in hardware. 5 DMA transfer independent of Unix PC bus. Cons: 1 68010 must transfer data to buffer (slow and CPU overhead). 2 Device driver will be complex to write. 3 Moderate amount of glue logic to contol Tri-State Buffers. *** DESIGN #3 *** DMA Control of SCSI Chip During Data Xfer TB = Tristate Bi-Directional Buffer (74LS245s) --+ | +--+ | | | Address Bus |--+------------>|TB|---------------------------+ | | Address | | | U | | Bus +--+ +------+ | +------+ N | | | | +-->| | I | +--------------------->| DMA | | SCSI |---\ SCSI X | | Chip | | Chip | > | +-------------------->| | | |---/ LAND P | | +------------------>|68450 | +-->| | C | | | | | | +------+ | | | +--+ +------+ | B |<--+----D0-D7-->| | | U | | |TB|<--------------------------+ S |<----+-D8-D15-->| | | +--+ 8 Bit | 16 Bit Data Bus | Data Bus --+ Pros: 1 SCSI chip can transfer at max. rate. 2 No firmware. 3 Buffer contention handled in hardware. 4 Probably most elegant solution. 5 Buffer does not have to first be loaded with data. Cons: 1 Device driver will be complex to write. 2 Lots of glue logic to contol Tri-State Buffers. 3 DMA must meet stringent Unix PC bus timing specs. 4 Overall design is hard because it must work intimately with the Unix PC hardware. One problem each design must overcome is the problem of attaching an 8 bit device to the Unix PCs 16 data bus. This can be solved by use of tristate buffers to select the lower and upper byte in the data word seperately. Where an SRAM buffer is used, each half of the word goes to a seperate SRAM chip and in Design #3, one word will be requested from every two bytes requested by the SCSI chip. The logic which performs this function is not shown in the diagrams. Surely these three designs are not the only solutions, but I am pretty sure that the final design will closely resemble one of them. If anyone sees a major or even minor problem in one of the designs, please let me know. Obviously the figures up above cannot convey the level to which I have thought each out, but I don't want to overlook something. I also am still waiting to get a hold of the Unix PC bus specs (they should be on their way) so some of the designs may have to be altered. We shall see. I plan on attending next weeks AT&T Users Group meeting in Sunnyvale so I hope to get good feedback from people there. Hope to see you there. Mike Thompson ----------------------------------------------------------------------------- | Michael P. Thompson, Member Scientific Staff | ### | BNR/Northern Telcom, Dept. 4Z15 | #### ##### ######### | 685A E. Middlefield Road | ############ ########### | Mountain View, CA 94039-7277 | #### #### #### | PH. (415) 940-2575 FAX. (415) 966-1067 | #### ####### ######## | amdahl! --\ | #### ##### ###### | UUCP. ames! ----->-- bnrmtv!miket | | hplabs! --/ | -----------------------------------------------------------------------------
jbm@uncle.UUCP (John B. Milton) (04/18/89)
In article <5255@bnrmtv.UUCP> miket@bnrmtv.UUCP (Michael Thompson) writes:
[ Three SCSI designs ]
I would go with the single chip processor design, with some mods:
Add a latch to hold the processor in the reset state. Make the program memory
for the processor dual port RAM. Download the code with a program in /etc/rc.
This would eliminate the need to burn ROMs to change the firmware. With PALs,
this change would not be too hard to implement. DMA could also be added to this
design. Because one of the prime devices we want access to over SCSI would be
a tape drive, I think that 16k would be WAY too small. Large memory means
dynamic RAM, more complexity and cost.
Another completely different design would fall along the lines of a project
I have started working on: An IBM PC bus adapter. Some thoughts:
May have to be connected "closer" into the UNIXpc than the expansion bus for
speed and noise reduction. By closer, I mean it would probably be a piggy
back card in the 68000 socket. It would not be as messy as my hard disk board.
There would be some kind of ribbon cable over to a PC box (the same one you
will have your second hard drive in :) There you would have a driver card to
receive the signals from the UNIXpc and drive the PC bus. There should not be
too many more problems supporting an AT 16 bit bus.
There are bound to be some boards that just won't work right. Software would
be an ongoing bitch. Most vendors and so afraid of being put out of business,
they will not cooperate with someone trying to write new code for the hardware,
even if it is to their advantage. Those of you who have tuned into what the
MINIX folks are doing know what I mean. The obvious reason to go this route is
the plentiful and cheap hardware available for the PClones. A SCSI board
for $25 is a typical example.
I have thought of a high speed connection to a regular PC, and it doesn't seem
like the proper (or cheap) way to go. From the programming point of view, I
would much rather talk directly to a VGA card, rather than telling a PC over
there to do it. For those of you who are wondering, I don't think it's going
to be possible to use PC RAM cards, as they expect full memory cycles to do
refresh. The UNIXpc uses more efficient short (RAS only) cylces to do refresh.
But, there might be a way.
Well folks what do you think? What am I mising? You might end up spending more
money going the PC bus interface route, then again maybe not.
John
--
John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu
(614) h:294-4823, w:764-2933; AMPR: 44.70.0.52; Don't FLAME, inform!bdb@becker.UUCP (Bruce Becker) (04/19/89)
In article <510@uncle.UUCP> jbm@uncle.UUCP (John B. Milton) writes: | [...] |Another completely different design would fall along the lines of a project |I have started working on: An IBM PC bus adapter. Some thoughts: | [...] John, what happened to your 2nd hard drive kit? I (and several others) have been waiting for you to announce its completion so we can get more DISK SPACE! ...please... |John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu |(614) h:294-4823, w:764-2933; AMPR: 44.70.0.52; Don't FLAME, inform! Thanks, -- O . Bruce Becker Toronto, Ont. o _///_ // Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu <`)= _<< BitNet: BECKER@HUMBER.BITNET \\\ \\ "The Net *has* died, and we've taken its place" - Altzilla
jim@syteke.UUCP (Jim Sanchez) (04/24/89)
I would second the previous message. Lets get the second hard disk
mod fixed FIRST before proceeding to something else.
--
Jim Sanchez {sun,hplabs}!sun!sytek!syteke!jim OR
Sytek Brussels mcvax!prlb2!sunbim!syteke!jimdet@nsscb.UUCP (Dennis Erwin Thurlow) (04/29/89)
In article <5255@bnrmtv.UUCP> miket@bnrmtv.UUCP (Michael Thompson) writes: > >Surely these three designs are not the only solutions, but I am pretty >sure that the final design will closely resemble one of them. > Mike, John Kopaz, of Honeywell in Pheonix,AZ, has suggested that the clip on daughter board made for the Macintosh would fit the 68010 and might be modified for SCSI. He was thinking about doing this before I told him about your project (he is currently un-networked). If someone wants to look into the feasability and send me mail, I will forward same to John. nsscb!det
gil@limbic.UUCP (Gil Kloepfer Jr.) (04/30/89)
In article <212@syteke.UUCP> jim@syteke.UUCP (Jim Sanchez) writes: >I would second the previous message. Lets get the second hard disk >mod fixed FIRST before proceeding to something else. >-- >Jim Sanchez {sun,hplabs}!sun!sytek!syteke!jim OR >Sytek Brussels mcvax!prlb2!sunbim!syteke!jim What are you talking about (ie. make specific references in your posting)? There *are* working second hard disk modifications (and they work well, believe me). Don'tcha wish ya had one? ;-) The theory behind the second hard disk is already old hat. I would also like to start seeing more on the SCSI idea (I wish I lived closer to California so I could help out more ;-) . ---- | Gil Kloepfer, Jr. | ICUS Software Systems/Bowne Management Systems (depending on where I am) | {decuac,boulder,talcott,sbcs}!icus!limbic!gil or gil@icus.islp.ny.us