From owner-riscy@pyramid.com  Fri Jul 16 18:00:14 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA26290; Fri, 16 Jul 93 18:00:14 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA19494; Fri, 16 Jul 93 14:59:50 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA22942; Fri, 16 Jul 93 14:58:12 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA22933; Fri, 16 Jul 93 14:58:09 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9307162158.AA22933@sword.eng.pyramid.com>
Subject: Current status
To: riscy@pyramid.com
Date: Fri, 16 Jul 93 14:58:09 PDT
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

Neil Russell awakens from a long day dream, and says:


We may have arived at a point that we cannot continue from.  We have
four possible solutions to the peripheral controller problem.  It should
be noted (if its not already obvious) that without the peripheral
controller the whole project is pointless.

1)  Use a IDT 79R3730.  This is the simplest and most attractive solution.
    The 3730 provides all of the right things, with the possible exception
    of video display support, which we have a solution for provided by
    Steve Ligett.  However, IDT are not forth comming on this part.  I am
    getting reluctance from the salesman at IDT in Santa Clara, and
    Andy Busse has had similar problems trying to get information though
    IDT in Germany.  In fact, Andy has been told that if we want a design
    now, don't use the 3730.  Quite frankly, I don't have the confidence
    in IDT to use it.  So this option is out.

2)  Use the MotherChip-set from Visual.  Their chips will be available
    in a few weeks, and for a good price.  However, while they solve
    the video problem quite nicely, there have no real support for
    DMA, which makes SCSI and Ethernet difficult.  As for providing
    extra logic to suplement their short commings, it would be a
    daunting task to do anything that would provide an efficient for
    software solution.  In fact, we may implement a good portion of
    a peripheral controller in doing so, thus making the MOM chips
    less useful.

3)  Use Ligett and Callen approach and do a DRAM controller in simple
    logic and use another CPU (a 3041 in their case) to do the I/O
    support.  This would certainly provide the efficiency for
    software that is needed, but the complexity and the fact that
    a good DRAM controller is hard, especially for the 30x1, may make
    this too complicated.

4)  Implement a 3730 like thing in readily available logic.  We could
    use a load of PALs and various logic, or maybe one or two FPGA's.
    Alternatively, we could have a semi-custom chip made.  I'm told that
    this may be cheap enough to consider.  Prices for semi-custom are
    based mostly on the pin count of the package used.  I'm still
    investigating this one, so I could be mis-informing you here.

5)  Wait 6 months and begin again.  By this time, the 3730 should be
    out along with some possible R4000 solutions.  I have heard that
    R4200's may be available for as little as us$200 (quantity unknown).
    However, we may well have the same peripheral controller problems.


While typing this, I had the thought that we could combine solutions
(2) and (3).  So, the main CPU would have a MOM3000i (and maybe a
MOM3000d) and so would handle all the video.  A single DMA interface
from the 3041 would be implemented with assistance from the MOM3000i.
All of the remaining peripherals are connected to the 3041 using its
bus sizing stuff.  DMA is implemented using software loops in the 3041.

Some price guesses (for the peripheral and video sections):

	MOM3000 chipset			50
	3041				45
	EPROM				 5 (8-bit wide)
	SRAM (for the 3041)		20 (not necessarily 32-bit wide)
	RAMDAC				30 (is this price right?)
	glue				10
				----------
				       160

We then add to that the prices that we have already established for
the SCSI, Ethernet, Serial, PCB, CPU, etc, and you have it.

As for the software in the 3041, it would be a seriously real-time
collection of interrupt driven loops, using registers and some SRAM
for buffering, with most of the data going directly to the main memory.
I do not see this would be a major problem.
-- 
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 owner-riscy@pyramid.com  Fri Jul 16 18:27:18 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA27111; Fri, 16 Jul 93 18:27:18 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23434; Fri, 16 Jul 93 15:26:56 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA25302; Fri, 16 Jul 93 15:26:18 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA25295; Fri, 16 Jul 93 15:26:16 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA23422; Fri, 16 Jul 93 15:26:41 -0700
Message-Id: <9307162226.AA23422@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA20694; Fri, 16 Jul 93 18:25:43 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Re: Current status
To: riscy@pyramid.com
Date: Fri, 16 Jul 1993 18:25:43 -0500 (EDT)
In-Reply-To: <9307162158.AA22933@sword.eng.pyramid.com> from "Neil Russell" at Jul 16, 93 02:58:09 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 694       
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> 4)  Implement a 3730 like thing in readily available logic.  We could
>     use a load of PALs and various logic, or maybe one or two FPGA's.

Anyone have a good idea how hard the above would?

> 	RAMDAC				30 (is this price right?)

From the mailing list I have:
2 Mac-compatible 512K VRAM SIMMS  $30/ea
1 TI tlc34076 RAMDAC              $32/ea
1 NSC LM1882 Video sync generator  $8/ea
                                 ----
total                            $100 1152x900 x 8 bit 


-- 
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok

 
From owner-riscy@pyramid.com  Mon Jul 19 05:13:56 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA13813; Mon, 19 Jul 93 05:13:56 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA08273; Mon, 19 Jul 93 02:13:23 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA26878; Mon, 19 Jul 93 02:11:41 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA26871; Mon, 19 Jul 93 02:11:38 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA08014; Mon, 19 Jul 93 02:12:04 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.f) via EUnet
	id KN26695; Mon, 19 Jul 1993 11:08:28 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for unido
	id AA15627; Mon, 19 Jul 93 10:51:41 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Mon, 19 Jul 93 10:50:30 +0200
Message-Id: <9307190850.AA07154@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA07154; Mon, 19 Jul 93 10:50:30 +0200
To: riscy@pyramid.com
Subject: Re:  Current status
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


> Neil Russell awakens from a long day dream, and says:

Hope it was nice, Neil :-)

> We may have arived at a point that we cannot continue from.  We have
> four possible solutions to the peripheral controller problem.  It should
> be noted (if its not already obvious) that without the peripheral
> controller the whole project is pointless.

> 1)  Use a IDT 79R3730.  This is the simplest and most attractive solution.
>    The 3730 provides all of the right things, with the possible exception
>    of video display support, which we have a solution for provided by
>    Steve Ligett.  However, IDT are not forth comming on this part.  I am
>    getting reluctance from the salesman at IDT in Santa Clara, and
>    Andy Busse has had similar problems trying to get information though
>    IDT in Germany.  In fact, Andy has been told that if we want a design
>    now, don't use the 3730.  Quite frankly, I don't have the confidence
>    in IDT to use it.  So this option is out.

Neil is right here. A field engineer at IDT Germany told me that we
should not wait for the 3730. Although IDT is currently testing samples
they will *not* provide more informations, handbooks and parts as
long the design isn't *completely* finished. This may take a while...

> 2)  Use the MotherChip-set from Visual.  Their chips will be available
>     in a few weeks, and for a good price.  However, while they solve
>     the video problem quite nicely, there have no real support for
>     DMA, which makes SCSI and Ethernet difficult.  As for providing
>     extra logic to suplement their short commings, it would be a
>     daunting task to do anything that would provide an efficient for
>     software solution.  In fact, we may implement a good portion of
>     a peripheral controller in doing so, thus making the MOM chips
>     less useful.

I doubt that the MOM* chips are a good choice. They are intended
to be used in a x-terminal and therefore do not really support more I/O
than ethernet, video and serial for mouse and keyboard. 

> 3)  Use Ligett and Callen approach and do a DRAM controller in simple
>     logic and use another CPU (a 3041 in their case) to do the I/O
>     support.  This would certainly provide the efficiency for
>     software that is needed, but the complexity and the fact that
>     a good DRAM controller is hard, especially for the 30x1, may make
>     this too complicated.

This solution might work with a lot of effort and trouble. Although
some things would be done in software, we would still need a lot
of glue between the CPU's, for the DRAM controller and for video.

> 4)  Implement a 3730 like thing in readily available logic.  We could
>     use a load of PALs and various logic, or maybe one or two FPGA's.
>     Alternatively, we could have a semi-custom chip made.  I'm told that
>     this may be cheap enough to consider.  Prices for semi-custom are
>     based mostly on the pin count of the package used.  I'm still
>     investigating this one, so I could be mis-informing you here.

Using a lot of PALs might work and wouldn't cost that much. FPGA's
are perhaps too slow or too expensive. Using semi-custom chips is
so far I know *extremely* expensive in the design phase but then
cheaper than everything else. Neil is perhaps not thinking about
a real ASIC. I'll give you an idea: We (Waldorf) is currently
planning an ASIC with approx. 100K gates (7x10 mm die).
Design costs: us$120,000. Part costs: us$30. Of course, we wouldn't
need 100k gates, but I'm sure it will be still too expensive.

5)  Wait 6 months and begin again.  By this time, the 3730 should be
    out along with some possible R4000 solutions.  I have heard that
    R4200's may be available for as little as us$200 (quantity unknown).
    However, we may well have the same peripheral controller problems.

This may be in fact the best thing we could do. The Orion/R4400 chips
will become cheap, support chips are announced yet.

> While typing this, I had the thought that we could combine solutions
> (2) and (3).  So, the main CPU would have a MOM3000i (and maybe a
> MOM3000d) and so would handle all the video.  A single DMA interface
> from the 3041 would be implemented with assistance from the MOM3000i.
> All of the remaining peripherals are connected to the 3041 using its
> bus sizing stuff.  DMA is implemented using software loops in the 3041.

This a way worth to discuss if we don't want to wait for a R4x00
solution.

> [ prices deleted ]

> We then add to that the prices that we have already established for
> the SCSI, Ethernet, Serial, PCB, CPU, etc, and you have it.
> 
> As for the software in the 3041, it would be a seriously real-time
> collection of interrupt driven loops, using registers and some SRAM
> for buffering, with most of the data going directly to the main memory.
> I do not see this would be a major problem.

Agreed.


Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
