From caret@pyramid.com Wed Jun 23 07:42:22 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA06007; Wed, 23 Jun 93 07:42:13 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA07897; Tue, 22 Jun 93 22:42:08 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA04363; Tue, 22 Jun 93 22:42:05 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306230542.AA04363@sword.eng.pyramid.com>
Subject: MIPS R3000 hardware design specification revision 1
To: riscy@pyramid.com
Date: Tue, 22 Jun 93 22:42:05 PDT
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

This is the first of a series of specifications for this board.
As the specification becomes more detailed and complete, it will
be re-mailed to the list.  Occasionally it will be summarized and
sent to comp.os.linux.

-----

*  Mechanical details

	The finished board must fit in a standard IBM compatible case,
	and should if possible fit in a mini-case.  The CPU may need
	one of those 486 "chip fans" or something like that in this
	case; this needs investigation.

	Because of the cost of assembly, the board should not have any
	Surface Mount Devices at all (J-lead components that can be
	socketed are ok).  Hand assembly of SMD boards is *very*
	difficult in all cases except maybe prototyping.  The cost
	of setting up and having boards assembled automatically is
	not cost effective until you get into the thousands.  I expect
	to be hand assembling the first few production runs of this
	board to save costs.

*  CPU
	IDT 79R3051E or IDT 79R3081E running at 20, 25, 33 or 40 MHz
	(probably 40MHz).

	The choice of CPU is based on price, flexibility (hardware wise)
	suitability for the project, and of course, availability.
	My preference is for the 3051E-40.  I have a price from one
	distributor for us$155 in units of 100.

	There is some difficulty in designing hardware to run at 40MHz,
	however, this will be mitigated by the use of the  IDT 79R3730
	(see below).

*  Peripheral controller
	IDT is just about to release the IDT 79R3730.  This is titled
	"Raster Image Processor".  It features:
		*  DRAM controller:
			- can drive some reasonable numbers of RAM chips;
			- can interleave banks;
			- can generate burst mode accesses;
			- can handle different sized DRAM dynamically;
			- can check parity;
		*  Has two separate buses (aside from the main bus) that
		   can handle talking to slower devices without holding
		   up the main bus.  This happens by use of a DMA controller,
		   bus sizer and FIFO's.  Each bus can have several DMA
		   running concurrently and still allow access to other
		   peripherals on the same bus;
		*  DMA logic to read and then rasterize data.  This is
		   intended for printer engines, but could easily be
		   adapted to a CRT;
		*  Individually programmable I/O pins (some of which
		   get used for parity checking);
		*  PGA, PLCC or MQUAD packages;
		*  Handles reading 8-bit EPROMS 4 bytes at a time
		   to allow the use of a single boot ROM.

	The CPU needs only to talk to the 3730 and one set of buffers
	for the RAM.  This will make a big difference to how hard it is
	to design the high speed stuff, making 40MHz probable.

	The problem is that IDT aren't going to release it until some
	time around September.  I'm working on them to get some advance
	samples and a more complete data sheet.  Until then the latest
	IDT CPU data book contains advance information.

*  32 SIMMS sockets
	The IDT 79R3730 allows the use of DRAM up to 4MB in size.
	32 SIMM sockets allows 128MBytes of RAM.  If more than one
	bank is installed, then they can be interleaved giving almost
	double the bandwidth to the memory (it reduces every 2nd
	cycle to a single cycle).  I'm guessing that using 70ns
	SIMMs that we would need 3 wait states per access.

	The SIMM sockets should handle the standard 30 pin IBM
	compatible SIMMs, for price reasons.

*  Boot EPROM
	Because of the 3730, we can get away with just one EPROM.
	Maybe two just for kicks.  Access to this is slow, so if
	speed were are problem, then code could be copied to RAM.

*  Feature selector
	Some of the I/O pins on the IDT 79R3730 should be used for
	a "feature selector".  This could allow setting things like:
		- use of parity;
		- big endian/little endian;
		- use of video;
		- diagnostic mode;
		- etc.

	This part of the design is trivial.  I expect it to just
	fall into place when the time is right.

*  Keyboard controller
	This should certainly handle IBM compatible style keyboards.
	The only way I know to do this is to use the 8051(?) micro-
	controller to drive the keyboard exactly the same way as
	every mother-board I've seen does.  This circuit should
	connect easily to the 8-bit bus of the 3730.

*  Non-Volatile-RAM and Real-Time-Clock
	This should be looked into.  The clock is almost a requirement
	but the NV-RAM could be replaced with the feature selector.

*  Serial port
	Because of the ISA bus, serial is always possible.  It might
	be a good idea, if just for debugging to have some serial
	ports on the mother-board.  If this is the case, they should
	be at least as good as 16550's.

*  ISA bus
	This is probably the hardest part, but necessary.  There are
	plenty of ASIC's out there that can handle the whole ISA spec,
	however, they are designed to interface to x86 CPU's and are
	usually surface mount.  With the possible exception of the
	-MASTER signal, the ISA spec could be implemented using not
	too much glue logic.  Remember that in the quantities that
	we would be buying in it may be cheaper to buy a handful
	of PALs than one ASIC and a few PALs to interface to the
	R3000.

	If the -MASTER signal was not implemented, no ISA device that
	does first party DMA would work (read Adaptec SCSI controllers).
	Other than Adaptec, I know of no other devices that use
	-MASTER.  Anyhow, we have a SCSI controller on the mother-board
	that can replace the Adaptec.

*  SCSI port
	It has been suggested that we use a NCR 53C94 SCSI controller
	chip.  I know nothing about this chip.  I expect that it could
	be connected to the 8-bit or 8/16-bit bus of the 3730.

*  Ethernet port
	It has been suggested that we use an Am7990 (Lance) Ethernet
	controller.  I know nothing about this chip.  I expect that it
	could be connected to the 8-bit or 8/16-bit bus of the 3730.

*  Video
	The IDT 79R3730 handles the DMA of rasters from DRAM and the
	serialization into 1, 2 or 4 bits per pixel.  This could be
	buffered to form 8-bits per pixel then fed into a suitable
	colour palette.  Then all that remains is to generate the
	pixel clock and the appropriate sync signals.  The sync stuff
	could come from a motorola 6845 or the like.  Because of the
	3730, this section should be real cheap.  If it doesn't turn out
	that way, then we should abandon this for some video controller
	on the ISA bus.  Resolutions up to 1280x1024x256 should be
	supported.

*  Floppy
	Floppy disks are not high bandwidth items.  They can and should
	be supported by some floppy only controller on the ISA bus.
	Using some cheap IDE controller with floppy connectors might
	be an even cheap solution.

	Note that this machine doesn't do DOS, so a floppy is probably
	optional in lue of a SCSI tape drive.

-- 
Neil Russell		(The wizard from OZ)
Pyramid Technology			Email:  caret@pyramid.com
3860 N. First Street			Voice:  (408) 428-7302
San Jose, CA 95134-1702			  FAX:  (408) 428-8845

 
From caret@pyramid.com Tue Jun 22 05:50:30 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA00287; Tue, 22 Jun 93 05:50:21 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18959; Mon, 21 Jun 93 20:52:40 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15758; Mon, 21 Jun 93 20:49:43 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306220349.AA15758@sword.eng.pyramid.com>
Subject: MIPS R3000 hardware design specification revision 1
To: riscy@pyramid.com
Date: Mon, 21 Jun 93 20:49:43 PDT
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

This is the first of a series of specifications for this board.
As the specification becomes more detailed and complete, it will
be re-mailed to the list.  Occasionally it will be summarized and
sent to comp.os.linux.

-----

*  Mechanical details

	The finished board must fit in a standard IBM compatible case,
	and should if possible fit in a mini-case.  The CPU may need
	one of those 486 "chip fans" or something like that in this
	case; this needs investigation.

	Because of the cost of assembly, the board should not have any
	Surface Mount Devices at all (J-lead components that can be
	socketed are ok).  Hand assembly of SMD boards is *very*
	difficult in all cases except maybe prototyping.  The cost
	of setting up and having boards assembled automatically is
	not cost effective until you get into the thousands.  I expect
	to be hand assembling the first few production runs of this
	board to save costs.

*  CPU
	IDT 79R3051E or IDT 79R3081E running at 20, 25, 33 or 40 MHz
	(probably 40MHz).

	The choice of CPU is based on price, flexibility (hardware wise)
	suitability for the project, and of course, availability.
	My preference is for the 3051E-40.  I have a price from one
	distributor for us$155 in units of 100.

	There is some difficulty in designing hardware to run at 40MHz,
	however, this will be mitigated by the use of the  IDT 79R3730
	(see below).

*  Peripheral controller
	IDT is just about to release the IDT 79R3730.  This is titled
	"Raster Image Processor".  It features:
		*  DRAM controller:
			- can drive some reasonable numbers of RAM chips;
			- can interleave banks;
			- can generate burst mode accesses;
			- can handle different sized DRAM dynamically;
			- can check parity;
		*  Has two separate buses (aside from the main bus) that
		   can handle talking to slower devices without holding
		   up the main bus.  This happens by use of a DMA controller,
		   bus sizer and FIFO's.  Each bus can have several DMA
		   running concurrently and still allow access to other
		   peripherals on the same bus;
		*  DMA logic to read and then rasterize data.  This is
		   intended for printer engines, but could easily be
		   adapted to a CRT;
		*  Individually programmable I/O pins (some of which
		   get used for parity checking);
		*  PGA, PLCC or MQUAD packages;
		*  Handles reading 8-bit EPROMS 4 bytes at a time
		   to allow the use of a single boot ROM.

	The CPU needs only to talk to the 3730 and one set of buffers
	for the RAM.  This will make a big difference to how hard it is
	to design the high speed stuff, making 40MHz probable.

	The problem is that IDT aren't going to release it until some
	time around September.  I'm working on them to get some advance
	samples and a more complete data sheet.  Until then the latest
	IDT CPU data book contains advance information.

*  32 SIMMS sockets
	The IDT 79R3730 allows the use of DRAM up to 4MB in size.
	32 SIMM sockets allows 128MBytes of RAM.  If more than one
	bank is installed, then they can be interleaved giving almost
	double the bandwidth to the memory (it reduces every 2nd
	cycle to a single cycle).  I'm guessing that using 70ns
	SIMMs that we would need 3 wait states per access.

	The SIMM sockets should handle the standard 30 pin IBM
	compatible SIMMs, for price reasons.

*  Boot EPROM
	Because of the 3730, we can get away with just one EPROM.
	Maybe two just for kicks.  Access to this is slow, so if
	speed were are problem, then code could be copied to RAM.

*  Feature selector
	Some of the I/O pins on the IDT 79R3730 should be used for
	a "feature selector".  This could allow setting things like:
		- use of parity;
		- big endian/little endian;
		- use of video;
		- diagnostic mode;
		- etc.

	This part of the design is trivial.  I expect it to just
	fall into place when the time is right.

*  Keyboard controller
	This should certainly handle IBM compatible style keyboards.
	The only way I know to do this is to use the 8051(?) micro-
	controller to drive the keyboard exactly the same way as
	every mother-board I've seen does.  This circuit should
	connect easily to the 8-bit bus of the 3730.

*  Non-Volatile-RAM and Real-Time-Clock
	This should be looked into.  The clock is almost a requirement
	but the NV-RAM could be replaced with the feature selector.

*  Serial port
	Because of the ISA bus, serial is always possible.  It might
	be a good idea, if just for debugging to have some serial
	ports on the mother-board.  If this is the case, they should
	be at least as good as 16550's.

*  ISA bus
	This is probably the hardest part, but necessary.  There are
	plenty of ASIC's out there that can handle the whole ISA spec,
	however, they are designed to interface to x86 CPU's and are
	usually surface mount.  With the possible exception of the
	-MASTER signal, the ISA spec could be implemented using not
	too much glue logic.  Remember that in the quantities that
	we would be buying in it may be cheaper to buy a handful
	of PALs than one ASIC and a few PALs to interface to the
	R3000.

	If the -MASTER signal was not implemented, no ISA device that
	does first party DMA would work (read Adaptec SCSI controllers).
	Other than Adaptec, I know of no other devices that use
	-MASTER.  Anyhow, we have a SCSI controller on the mother-board
	that can replace the Adaptec.

*  SCSI port
	It has been suggested that we use a NCR 53C94 SCSI controller
	chip.  I know nothing about this chip.  I expect that it could
	be connected to the 8-bit or 8/16-bit bus of the 3730.

*  Ethernet port
	It has been suggested that we use an Am7990 (Lance) Ethernet
	controller.  I know nothing about this chip.  I expect that it
	could be connected to the 8-bit or 8/16-bit bus of the 3730.

*  Video
	The IDT 79R3730 handles the DMA of rasters from DRAM and the
	serialization into 1, 2 or 4 bits per pixel.  This could be
	buffered to form 8-bits per pixel then fed into a suitable
	colour palette.  Then all that remains is to generate the
	pixel clock and the appropriate sync signals.  The sync stuff
	could come from a motorola 6845 or the like.  Because of the
	3730, this section should be real cheap.  If it doesn't turn out
	that way, then we should abandon this for some video controller
	on the ISA bus.  Resolutions up to 1280x1024x256 should be
	supported.

*  Floppy
	Floppy disks are not high bandwidth items.  They can and should
	be supported by some floppy only controller on the ISA bus.
	Using some cheap IDE controller with floppy connectors might
	be an even cheap solution.

	Note that this machine doesn't do DOS, so a floppy is probably
	optional in lue of a SCSI tape drive.

-- 
Neil Russell		(The wizard from OZ)
Pyramid Technology			Email:  caret@pyramid.com
3860 N. First Street			Voice:  (408) 428-7302
San Jose, CA 95134-1702			  FAX:  (408) 428-8845

 
From caret@pyramid.com Thu Jun 24 00:03:03 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA08779; Thu, 24 Jun 93 00:02:55 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA08166; Wed, 23 Jun 93 15:02:50 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA07359; Wed, 23 Jun 93 15:02:45 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306232202.AA07359@sword.eng.pyramid.com>
Subject: Re: MIPS R3000 hardware design specification revision 1
To: drew@nag.cs.Colorado.EDU (Drew Eckhardt)
Date: Wed, 23 Jun 93 15:02:45 PDT
Cc: riscy@pyramid.com
In-Reply-To: <199306231347.AA00538@nag.cs.Colorado.EDU>; from "Drew Eckhardt" at Jun 23, 93 7:47 am
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

Drew Eckhardt writes:

> Assuming that "average" users will be using something like 1024x768x256
> at 60hz, you'll be DMAing  45M a second.  Some people have problems at 
> < 72hz, which is 54M bytes a second.  Up the resolution to 1280x1024x256
> and you're looking at 90M/sec.
> 
> With 70ns DRAM, assuming that we are 2-way interleaved we can't get more
> than about 100M/sec.  So, we'd loose between 50 and 90 percent of our 
> memory bandwidth, our biggest performance bottleneck, if we put main
> memory on the same bus.

This is a good point; this certainly points to using VRAM.  At present there
are far too many unknowns about the video section to really address this
issue.  Someone needs to do some research as to what cheap video stuff
there is.  Using the S3 chip (as some one suggested) may be a good idea,
if we can get it in a J-lead or PGA package.  (See comments on surface
mount in the spec).

> Can the IDT 79R3730 handle DRAM on one of the other busses?  

Yes, but what I expect that your thinking is to put DRAM on another
bus to releive contention on the main bus.  That is not possible.
We should use VRAM for that.

> How expensive is VRAM?  Since it's inherently dual ported, you get 
> a lot more CPU->video memory bandwidth than you do when you're trying
> to share DRAM with video serializers that want 45-90M/sec, making 
> bitblits (ie, text drawing, the moving of windows, etc). 

I think its 3-4 times the cost of DRAM; once again I'm guessing...

-- 
Neil Russell		(The wizard from OZ)
Pyramid Technology			Email:  caret@pyramid.com
3860 N. First Street			Voice:  (408) 428-7302
San Jose, CA 95134-1702			  FAX:  (408) 428-8845

 
