[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [f-cpu] about register mapping

'soir,

sorry i forgot to answer this email,
many important things need to be explained
and sleep deprivation is not a good way to
write good explanations .... here i give a second try.

Nicolas Boulay wrote:
Le Jeudi 1 Janvier 2004 20:41, Yann Guidon a écrit :

hi,

Nicolas Boulay wrote:
Memory mapped register to speak to device is a good way to extend easly a
design.

what do you mean by "Memory mapped register to speak to device" exactly ?
Do you mean that I/O is memory-mapped ? If so, then history says that
it always end up in a big mess, look at the Ralph Brown lists

That's the way all design goes.


not "all".


Because it the simple way to add peripherals to an existeing cpu.


"easy", probably, but not "best".


The question was better how to access efficaly


ispell coredumped on "efficaly"
to the TLB, DMA, clock which are low level but are very often seen in both possibility memory mapped or register mapped.

there is no doubt that these particular examples (TLB, DMA and clock) are CPU-dependent resources
and must therefore be tied to the CPU, so a multi-CPU computer has no delicate situations to handle.

http://www.cs.cmu.edu/~ralf/interrupt-list/inter61d.zip
files Port.a, Port.b and port.c
For example, port 0x300 was "reserved" for prototype cards,
but today it is used by more than ten "commercial" cards
and probably much more, since the RBIL can't list everything.
Fortunately, the PCI standard reduced the pressure on the I/O port
addressing space with providion for dynamic address allocation

That's a PC problem.
the "PC mentality" has leaked everywhere and certainly impacts all other recent designs.
i want to make sure that this does not impact the F-CPU project in a negative way.

but the "legacy" remains : the PCI standard is and will remain
tainted by the original PC-XT definition.

:) PCI is used everywhere and is not tied to the PC at all.

i say : "tainted".
i know that there are PCI slots in almost all new computers, even non-x86
but the basic definition of the PCI standard contains several x86 and PC-XT idioms.
if i was not lazy to spend 5 minutes on google to search the examples,
i would drop a few URLs.

The morale is : if it is possible to do something messy, it will become
a mess. Even if you make something a bit better later, it's too late.

Nooo ? sans dec' ?


si j'tel'dis ....
If I/O boards, or even any board is to be designed, then it would be
better to use a few wires for a I²C or SPI bus. When booting,
the main CPU will read the parameters from a serial EEPROM
and configure the addresses and other internal registers.

But it is not a panacea, because the main CPU needs a "device driver"
in order to interpret the embedded parameters. This could cause
more problems (CPU compatibility etc.) than it solves.

All of this is how to deal with memory mapped IO. That's out of topic here.

i thought it was indeed on topic,
as i tried to imagine a system that would address our concerns.
But it restric the kind of interraction we could have with the device.
f-cpu tend to throught every thing in special register.
So i would like to better know pro and cons about that.

There are many points to consider.

First, we must NOT forget that there are "slow" I/O and "high-bandwidth"
I/O.

It is not the point too. Slow IO could be a real nightmarre to handle by register mapped system. Because it slow everything down unless a kind of OO system look after it.
Slow IO also are a nightmarre for memory mapped device but less because memory are known to be slow.

ok, i made a mistake here : i should have said : "low-bandwidth I/O",
that is : only for querying status and controlling I/O, not for the data itself.
i did not address the "access time" of the register itself, only its purpose.

High-bandwidth requires specific hardware that performs the data moves
automatically
(a sort of DMA). Configuring this DMA typically requires "slow I/O"
access to the

Nop this is fast. Why a DMA will be slow to be configured ?

because i made a mistake in the naming.
you coud try to find a better name.
address registers (source + destination) and count register for example.
But this could be much more complex for ATA/IDE, USB or SCSI.

The DMA for fast I/O is not yet studied for F-CPU because it depends on
the kind of peripheral : Disk, network, even video. The DMA engine for each
case is best examined globally, and defining a "one-fits-all" DMA engine
could cause problems if a completely new kind of peripheral is created.

Yep and most of the time it come with the device.


So all we do now is manage "slow I/O" at the CPU core level.
One has to consider :
- resource protection (access rights per thread or process)

so memory mapped are controlled by TLB. Register mapped (SR) ? by user/superuser mode ?

yes, for example.
later, a finer (probably hierarchy-based) protection system
could be implemented so certain software modules/task/threads
can access a specific set of registers, using a mask per thread,
but a simple user/superuser method is enough to get started.
For F-CPU, we need something both simple and very flexible
that does not interfere with the rest. It is not impossible to
use memory-mapped I/O but their absence makes it easier
to design a simple high-bandwidth memory bus.

Nop :) It's much easier to do the opposite. A flag on tlb could say ordered or not ordered access. I had looked at openrisc 1000 to see how they do it. Since it's not defined in F-cpu, yet. We could inspired from them.

i'd rather not spend time on it, due to potential
patent problems with MIPS ...
Furthermore, the CPU core and probably some integrated HW
need a way to be configured : for example, the clock generator,
or the external memory banks (SDRAM for example) need
some tuning and probably run-time modifications, so it does not
make sense to go through the whole memory hierarchy to manage that.

???

if you speak to the onchip SDRAM controller,
why bother with the caches, addresses and all the other stuffs
when you can access the registers directly in ordered way ?
The GET and PUT instructions in F-CPU are similar to the
RDMSR and WRMSR instructions for x86 (they are local to the CPU).
IN and OUT are other instructions that apply globally to the system.

In and out are alias for read/write on the "I/O bus" of the x86. This io bus is the normal bus + a bit saying "we make a IO transfert". So in fact, it's like a adresse bit !

it was something like that in the 8080, 8085, 8086 and maybe 80286
but today, and at least since the P2 core, it's different considering
address space (64K max), strong access ordering, memory buffers
and many other subtleties that don't make it a real memory.
There is also a similarity with the "coprocessor" instructions
of the MIPS and ARM architectures which are used to
configure the internal registers (memory protection/TLB,
IRQ configuration...)

I think this mail gives some ideas to discuss about but
i guess that you (nicO) have heard and read enough on
the matter of SRs to know the principal pros and cons
of this approach, since you have argued about it.
Here, i try to give a deeper insight and a general
overview, without saying "what shall and shall not be done",
but only "what is".

So modest... :)

don't feed the troll, design instead.
nicO

YG

*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/