MEMC and video DMA question
Andrew Stevens
A question to the knowledgeable:
The recent comments on speeding up Arch's when using big modes
reminds me of something that has puzzled me for some time about
the Arch architecture:
In a basic Arch you get contention between the video-subsystem and the
CPU - the MEMC multiplexes the two onto the same memory sub-system. It
even generates the video-DMA addresses as I understand it. So, what
happends in a machine with 2 or more MEMC's?
Can you fix things up so that RAM controlled by one MEMC supports video
DMA (and runs slow), whilst a second bank with its own MEMC runs at full
tilt. In an A540, for example, does the machine run faster when more
than one RAM bank is added?
Also, does MEMC support general-purpose DMA as well as video?
E.g. for winchesters etc, or is all that sort of stuff (as I
heard rumoured) done by the main CPU?
The latter would at least partially explain the reputedly poor
through-put of Rxy0 UNIX systems when paging. A 32K page size certainly
doesn't help, but it shouldn't impact through-put all that much. If the
system isn't thrashing other runnable processes should happily soak up
CPU time while a page-fault is fixed. However, if the CPU was *busy*
during page-faults sluggish performance during paging would be no
suprise at all.
Andrew
Andrew Stevens
Programmming Research Group JANET: Andrew....@uk.ac.oxford.prg
Oxford University Computing Laboratory INTERNET: Andrew....@prg.ox.ac.uk
11 Keble Road, Oxford, England UUCP: ...!uunet!mcvax!ukc!ox-prg!as
Nicko van Someren
>In a basic Arch you get contention between the video-subsystem and the
>CPU - the MEMC multiplexes the two onto the same memory sub-system. It
>even generates the video-DMA addresses as I understand it. So, what
>happends in a machine with 2 or more MEMC's?
One MEMC is the master MEMC and all others are slave MEMCs. A MEMC knows
which it is by the state of the byte/word line when the last reset took place.
>Can you fix things up so that RAM controlled by one MEMC supports video
>DMA (and runs slow), whilst a second bank with its own MEMC runs at full
>tilt. In an A540, for example, does the machine run faster when more
>than one RAM bank is added?
No. The CPU memory accesses and the video DMA go along the same data bus
so one must hold up the other even if there is more than one bank or RAM.
>Also, does MEMC support general-purpose DMA as well as video?
>E.g. for winchesters etc, or is all that sort of stuff (as I
>heard rumoured) done by the main CPU?
The rumour you heard was right. MEMC provides DMA for video and sound but
has no general DMA.
>Andrew
Nicko
+-----------------------------------------------------------------------------+
| Nicko van Someren, nb...@cl.cam.ac.uk, (44) 223 358707 or (44) 860 498903 |
| "Go and buy an Aleph One ARM3 card and stop whining!!!" |
+-----------------------------------------------------------------------------+
Mark Taunton
problems trying to cancel the first attempt which went out with an
incorrect Reply-To field.]
In article <12...@culhua.prg.ox.ac.uk> a...@prg.ox.ac.uk (Andrew Stevens) writes:
>
>In a basic Arch you get contention between the video-subsystem and the
>CPU - the MEMC multiplexes the two onto the same memory sub-system. It
>even generates the video-DMA addresses as I understand it. So, what
>happends in a machine with 2 or more MEMC's?
>
>Can you fix things up so that RAM controlled by one MEMC supports video
>DMA (and runs slow), whilst a second bank with its own MEMC runs at full
>tilt. In an A540, for example, does the machine run faster when more
>than one RAM bank is added?
No. Multiple-MEMC machines (extended A440/R140, A540/R260) still have
only one data bus and one address bus, so there is no extra data
bandwidth from the extra MEMC. However the A540 and R260 have a
faster memory subsystem (12 MHz instead of 8 MHz) which provides a
useful increase in bandwidth and reduces the impact of high video data
rates (as does the ARM3 cache by reducing the processor's bus usage).
As you surmise, the first MEMC always handles the video (and other)
DMA traffic. It *might* be possible in a different design to have the
other MEMCs in a complex data bus buffering scheme, allowing the
processor to get at its own data while VIDC is loaded from screen
memory. However you should note that (a) the current multiple-MEMC
system design requires the MEMCs to be tightly synchronised at all
times, so breaking this would probably involve some quite complex
hardware glue, if it is indeed possible, and (b) I am not a hardware
designer, and haven't looked into this in any detail.
>Also, does MEMC support general-purpose DMA as well as video?
>E.g. for winchesters etc, or is all that sort of stuff (as I
>heard rumoured) done by the main CPU?
>
>The latter would at least partially explain the reputedly poor
>through-put of Rxy0 UNIX systems when paging. A 32K page size certainly
>doesn't help, but it shouldn't impact through-put all that much. If the
>system isn't thrashing other runnable processes should happily soak up
>CPU time while a page-fault is fixed. However, if the CPU was *busy*
>during page-faults sluggish performance during paging would be no
>suprise at all.
>
No, in current Acorn systems MEMC handle only special DMA for video
(two channels, one for main screen data, one for cursor data) and
sound. There is no separate DMA hardware for any other data traffic.
The built-in ST506 controller in the A4x0/R140 has its own buffering,
and the processor is required to transfer the data under interrupt on
each 256-byte sector boundary, or once every 500 microseconds or so
during a multi-sector transfer. On my last check, the RISC iX code to
handle this on an R140 takes in the region of 140 microseconds (more
in high bandwidth screen modes), so there is a definite reduction in,
but not a complete loss of, available CPU power during disc transfers.
The situation is similar on the R260 in that the data is moving in/out
via buffers on the SCSI expansion card. I have no figures for the
actual transfer rate there, but of course the memory end of the
transfer will go rather quicker than on an R140 because of increased
memory bus and processor speed, and because the transfer loop code
will be in the ARM3 cache.
>Andrew
> Andrew Stevens
> Programmming Research Group JANET: Andrew....@uk.ac.oxford.prg
> Oxford University Computing Laboratory INTERNET: Andrew....@prg.ox.ac.uk
> 11 Keble Road, Oxford, England UUCP: ...!uunet!mcvax!ukc!ox-prg!as
Mark Taunton
Acorn Computers Ltd
ma...@acorn.co.uk
Andras Kovacs
>CPU - the MEMC multiplexes the two onto the same memory sub-system. It
>even generates the video-DMA addresses as I understand it. So, what
>happends in a machine with 2 or more MEMC's?
>
>Can you fix things up so that RAM controlled by one MEMC supports video
>DMA (and runs slow), whilst a second bank with its own MEMC runs at full
>tilt. In an A540, for example, does the machine run faster when more
>than one RAM bank is added?
"A single MEMC will control up to 4M bytes of DRAM. A second MEMC can be
built into a system to extend the maximum addressable DRAM to 8M bytes. The two
MEMCs are configured as a Master and a Slave, where the Slave acts purely as a
DRAM driver (all DMA operations, I/O controller interactions, etc. are handled
by the Master)." (VL86C010 book from VLSI, Inc.)
>Also, does MEMC support general-purpose DMA as well as video?
>E.g. for winchesters etc, or is all that sort of stuff (as I
>heard rumoured) done by the main CPU?
It seems to me that there is no general-purpose DMA in the MEMC; I think
the designers thought that with the extra overlapping regs in FIQ mode, you
can emulate a DMA channel quite efficiently.
>The latter would at least partially explain the reputedly poor
>through-put of Rxy0 UNIX systems when paging. A 32K page size certainly
>doesn't help, but it shouldn't impact through-put all that much. If the
>system isn't thrashing other runnable processes should happily soak up
>CPU time while a page-fault is fixed. However, if the CPU was *busy*
>during page-faults sluggish performance during paging would be no
>suprise at all.
I am afraid that the 32K page size indeed a poor choiche in a demand-paged
virtual memory system; my understanding is (from the stuff floating on comp.
sys.arch) that in order to provide half-decent performance, you have to have
~4KB page sizes. Also, 'cause the MEMC does not provide statistical info about
the pages (dirty bit, # of hits) write-back and good page-fault replacement
strategy is a problem. Anyone could shed more light on this aspect?
>Andrew
Andras
--
Andras Kovacs
and...@alzabo.ocunix.on.ca
Nepean, Ont.
Graham Toal
There are 15 files of this to come? Argh! - havn't you been following the
discussions here at all? Can't you wait a week for comp.acorn.binaries
to appear?
If someone specifically asked for these you could have posted them directly.
Remember, the charter of this group says it is a discussion group. As
mathew@mantis pointed out earlier, we're liable to be blocked by sysadmins
who notice the abnormally high traffic in the group (from arbitron data)
Graham
PS We *do* aprreciate the thought; it's just the timing that's a bit off...
[I hope this gets to you before you post the rest of the files!]
--
(* Posted from tharr.uucp - Public Access Unix - +44 (234) 261804 *)
Tiggr
>| "Go and buy an Aleph One ARM3 card and stop whining!!!"
I object to this commercial advertisement.
Tiggr
roger...@uk.ac.man.cs
Stop whining - just like the man says.
[ H.J.Rogers (INTERNET: rogersh%p4%cs.man...@cunyvm.cuny.edu) ]
[ ,_, (BITNET/EARN: rogersh%p4%cs.man...@UKACRL.BITNET) ]
[ :-(_)-o (UUCP: ...!uunet!cunyvm.cuny.edu!cs.man.ac.uk!p4!rogersh) ]
[ _} {_ (JANET: rogersh%p...@uk.ac.man.cs) ]