Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!usc!apple!voder!dtg.nsc.com!waggoner From: waggoner@dtg.nsc.com (Mark Waggoner) Newsgroups: comp.sys.amiga.tech Subject: Re: Bus Latency Keywords: bus dma latency Message-ID: <333@berlioz.nsc.com> Date: 20 Nov 89 19:40:44 GMT References: <322@blenheim.nsc.com> <128061@sun.Eng.Sun.COM> <329@berlioz.nsc.com> <128120@sun.Eng.Sun.COM> Reply-To: waggoner@berlioz.UUCP (Mark Waggoner) Organization: National Semiconductor, Santa Clara Lines: 116 In article <128120@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <329@berlioz.nsc.com> waggoner@dtg.nsc.com (Mark Waggoner) writes: >>I am not sure I understand all of this. Some questions: >>(Perhaps I should RTFM) > >A good suggestion, the Hardware manual for the Amiga is excellent. > >> 1. Can the CPU be locked out of chip memory for long periods of >> time? I thought it alternated cycles with the video dma. > >It works this way. There are several things that want bus cycles in >the Amiga. The Custom chips, the CPU, and the peripherals. There is >a great chart that shows what gets what, but basically the video gets >the odd cycles and the CPU/CustomChips/Peripherals get the even cycles >except during VBLANK and HBLANK when video doesn't need them. So yes, >the CPU is on the alternate cycle but it shares those alternate cycles >with other things. > Actually, I got the hardware manual over the weekend and it is, for the most part, excellent. As I now understand it, the CPU gets alternating cycles in some video modes, but as the number of bit planes increases, it starts losing some of those. When you get to interlaced, hi-res mode with 4 bit planes, the CPU and other custom chips don't get any cycles at all. (Anyone care to confirm that this is correct?) When you increase the size of the screen (overscan) you start losing the HBLANK time and can, potentially, lose all the cycles for the entire video frame. If the CPU tries to access chip memory, it will get locked out until the VBLANK time. I didn't see much information in the hardware manual on how the arbitration is done when there are DMA devices present other than the standard custom chips. There is also no description of the bus timings and definitions that I could find. >> If it DOES NOT alternate cycles and can be locked out of chip memory, >> then "fast" memory is indeed fast only in that you can perform your >> dma bursts faster. > >Also there is a problem where the CPU can grab the bus in an attempt to >get to something in CHIP ram and block access to the expansion RAM so that >in some cases you just loose period. I haven't looked real closely at the >bus timing for the 500/2000 though so this may not be a problem any more. I think we are describing the same thing here. As I understand it, this can still happen. > >> 2. When a peripheral is dma'ing to/from chip memory, what >> restrictions are placed on it in terms of burst size. Can it use >> consecutive cycles? How is this handled? > >Peripherals get low DMA priority, when someone else wants the bus (like >Agnus so she can stuff some bits into Denise) you lose it and have to >wait. How do you lose the bus? This goes back to a lack of information on the bus arbitration scheme. Using plain 68000 bus arbitration signals, once the 68000 grants bus access to someone, it doesn't have any way of preempting the bus master (except maybe through a bus error). I guess my actual question was: When dma'ing to/from chip memory, do you just get wait stated around the cycles where video is accessing the bus or is there some other mechanism for this. What happens when you do consecutive memory reads or writes. > >> 3. 14 mS of latency is a VERY long time. Doesn't this mean that >> almost any peripheral will have to have local buffer ram? Take >> Ethernet, for example (something I can talk about without getting >> too confused). In 14ms, you could receive >> 14mS / (800nS/byte) = 17500 bytes of data. >> Of course, this is neglecting the fact that you shouldn't get packets >> that big and packets can't come back to back. But still, there is no >> way you could ever count on getting hold of the system bus in time to >> buffer a packet unless you had either a FIFO or local memory big >> enough to hold at least 20K. This makes peripherals much more >> expensive. Could you even transfer 20K over to the system memory >> in the time between video frames? (OK, so you aren't likely to >> get a burst of packets like that, but it IS possible). > >A) You can get packets "back to back", and B) a 32K X 8 static RAM chips is >only $10 and comes in a nice compact 28pin skinnydip. But that aside, you >can do like 3Com did on their early boards and provide just enough ram for >1 packet (2K) and drop any that come in when you can't buffer them. This >works because the protocols allow for lost packets but it does cut down >on your efficiency. By back to back I was only referring to the fact that there will be a gap between every packet of at least 9.6 uS. This doesn't do much to reduce the amount of data you could receive. In addition to the requirement that you provide local buffer ram, you will also have to do one of two things: 1. Use the CPU to copy the data from the buffer ram to system ram. 2. Build or buy a DMA machine to transfer the buffer ram to system ram. Option 1 leads to a lower performance board and option 2 is higher cost. If your ethernet controller already supports DMA, it seems a waste to have another DMA to copy the data between the two ram's. It would be nice to be able to DMA directly into system ram, but that would require a *HUGE* fifo on your ethernet controller, both for transmitting and receiving. I guess this is the price we pay for all the fancy video modes. Video memory separate from system memory would eliminate the long latency times, but reduce flexability and video performance. I am asking all of this because I am trying to get a grasp on what it would take to stick an ethernet controller I have been working on onto an Amiga card. Looks like a lot of work to build a high performance interface. -- ,------------------------------------------------------------------. | Mark Waggoner (408) 721-6306 waggoner@dtg.nsc.com | `------------------------------------------------------------------'