> 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
> [ 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.
Waldorf Electronics GmbH | Phone: +49 (0)2636-80294
R&D Department | Fax: +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email: firstname.lastname@example.org