Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!bruce!monu1!monu6!edp367s From: edp367s@monu6.cc.monash.edu.au (Rik Harris) Newsgroups: comp.sys.amiga.hardware Subject: Re: second serial port Keywords: 2232 7 port cpu Message-ID: <1990Dec4.111440.24893@monu6.cc.monash.edu.au> Date: 4 Dec 90 11:14:40 GMT References: <90334.151404DXB132@psuvm.psu.edu> <1990Dec2.141048.10108@NCoast.ORG> <1990Dec3.053356.26826@monu6.cc.monash.edu.au> <1990Dec4.025744.18641@NCoast.ORG> Organization: Monash University, Caulfield Campus Lines: 145 I was going to reply to David in email, but since three people have posted followups, I changed my mind. davewt@NCoast.ORG (David Wright) writes: > I am both an EE and a CS engineer. >> >>A CPU will add convenience to the design of a piece of hardware, not speed. >>A CPU needs to be clocked, and must access memory, and the hardware is >>limited by the speed the CPU can run at. > Not quite true. Having a CPU on the board allows you to run custom >software on the board, without needing the HOST CPU to do this. This is where a CPU is the most useful: flexability. If you have an on-board CPU, then the software you run can easily be changed, which can change the entire operation of the circuit. No argument here. Now, I obviously didn't explain myself very well when I first posted the article (I have been working on the project mentioned for too long :-). > It also allows >you have large buffers (most of the multiport boards by DigiBoard have at >least 128k of RAM on them too), and transfer this data (from all the various >ports) to the host in one big piece, rather than having to do character-level >I/O, which ties up the bus unneccessarily. Doing I/O this way at high speeds >is like trying to build a hard disk interface that doesn't use DMA. It can >be done, and for less money, but it won't run as fast as a DMA system, and >it will tie up the host CPU more than a DMA device. That is not quite what I meant. The hardware that we have designed does all the buffering *in hardware*. It does not interrupt the host CPU, because there is *no* host CPU. > Having ANY CPU on the board allows parallel proccessing. While the >host CPU is running some other program for you, the serial board is taking >care of all the little details, like flow control, watching hardware latches >(for things like DTR/DSR), etc. If you don't have a CPU on the board, you >have to expect the host cpu to: > a) Run the user programs which user programs would be run in the local CPU? I can't think of any at the moment (feel free to correct me :-) > b) Run the driver for the serial ports done in hardware > c) Watch for flow control on all ports done in hardware >both b & c must be done as often as possible, or you will lose data. >>For the last year I have been working on a Packet Switching Local Area >>Network (what it is/does is not really relevant) that is pushing away >>from the CPU, because it is too slow. We have built specialised >>circuits to have the hardware do all the buffering and switching of >>packets without CPU intervention. Doing this, we have increased the >>potential speed of the device by ORDERS OF MAGNITUDE (more than 3 >>orders). > I think you are either getting confused and meaning the host CPU >when you say "without CPU intervention", or you are using a very slow >proccessor on your I/O board. Ideally, a board for the Amiga would have >something like a 10 Mhz 68010, or even a 68000, and as the clock speed is >only on the board, it doesn't have to match up directly with the host CPU >speed. As I said before there is no host CPU anyway. I also mentioned orders of magnitude speed increases (which does not lend itself to RS232 applications). These increases were over a node that handled 4 i/o ports running at 9600bps each. > I have tried to fight around multi-I/O boards for the PC that >didn't have their own CPU, and I can tell you that their producers were happy >if they could get 4 9600 baud I/O transmissions going full blast at the same >time. I almost have to laugh when you compare those boards with something >that can handle *8* ports (or even 16), running at 38400 at the same time, >without any extra host CPU activity (except for simply reading in the >data to send, that is). Ahhh, but that's where the confusion lies. I was not comparing those dumb boards that run 4 9600 lines with a CPU driven board. I was talking about our hardware that runs 8 ports a 2Mb/s (hopefully scaleable to 20Mb/s). I think the problem is that I was not talking about multiple serial ports for PC's in particular, I was talking about communications equipment in general (and we're not talking about lots $$, either, its an *educational* research project) > The only advantage that a board without a CPU has is that it is >cheaper, and easier to build. For a PD project, that's fine. If you are interested in the project I am talking about, I will happily discuss it with you via mail. It is not PD, and it is fast. I might add that the project as a whole _does_ use a CPU, but it has nothing to do with data transfer. > But for >real multi-user use, especially under something like Amiga Unix, you are >going to want something that doesn't chew up your host CPU time. X >will take care of that just fine. :-) ahhh, a man after my own heart :-) :-) I'll just quickly mention the article from drysdale@cbmvax.commodore.com (Scott Drysdale) [no offence, Scott] > what you want a multiport serial card to do is annoy the host machine's CPU > as little as possible. > [very good justification deleted] couldn't agree more (see above) > of course, the latency between a character completing assembly in one of the > UART's receive registers and when the host actually sees it is potentially much > greater than the direct interrupt approach, so this kind of thing wouldn't be > great for midi or other timing sensitive applications, but with a little more > code on the card's CPU, you could do decent timestamping and pass the data > to the host with the timestamps already there. Yes, this is the advantage of an on-board CPU, It is very flexible, so this sort of thing can be done _very_ easily. (ie, I agree) > > certainly a pure hardware approach without CPU intervention (intelligent > DMA, for instance) would be even faster, but this is only 8 ports we're > talking about, running at fairly low speeds. i imagine your packet switch > has hundreds or thousands of "ports" to deal with. no, It's only 8 ports, but we do want a very large throughput (well, as much as we can). The original network was based on nodes with a Z80 CPU (approx 1 MIP) and four i/o ports. It could run at 9600 bps fine, but we wanted more speed. If we put in a 10 MIP processor, we would get a 10x increase in speed, but when we designed it with no processor, we could get (theoretically, its not finished yet!) 2Mb/s easily, and hopefully about 20Mb/s through each of 8 ports. For the same reason we avoid using the host processor for character interrupts, we removed the local processor so it would not need to be interrupted, instead all the controlling, and buffering is done in hardware. Please mail me if you are interested in the project, I don't really want to waste too much bandwith, for a fairly narrow (and non-amiga) topic. [sigh! maybe I shouldn't have brought up such a theoretical topic :-) ] > Dave > --Scotty Rik. -- Rik Harris - edp367s@monu6.cc.monash.edu.au | Build a system that new address! rik@sola.fcit.monash.edu.au | even a fool can use, Faculty of Computing and Information Technology, | and only a fool will Monash University, Caulfield Campus, Australia | want to use it.