Re: [f-cpu] about register mapping

[Nicolas Boulay <nico@seul.org>]

Le Jeudi 1 Janvier 2004 20:41, Yann Guidon a écrit :
> hi,
>
> Nicolas Boulay wrote:
> >I would like to read some information about register mapping.
>
> google is your fiend ;-)
nc...
> however you will certainly find references to "register renaming" which
> is another issue.
>
> >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. Because it the simple way to add peripherals 
to an existeing cpu. The question was better how to access efficaly to the 
TLB, DMA, clock which are low level but are very often seen in both 
possibility memory mapped or register mapped.

> 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. 

> 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.

> 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' ?

> 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.

> >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.

>
> 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 ?

> 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 ?

>  - bandwidth separation (sending a single-word access request in the middle
>      of block-wise requests can cause slowdown and make control logic
> more complex)
>  - single-CPU vs multi-CPU (some I/O may be common to the whole system but
>      some others depend on each CPU, such as configuring the local clock
> or stuff like that)
>  - centralised vs per-CPU I/O (the PC centralises all accesses to the
> CPUs so
>      its I/O uses a single address space but a F-CPU system could have
> some specific
>      I/O per CPU, making a heterogeneous system)
>  - memory hierarchy coherency (caches and cachability) as well as access
> time
>     (it may be slower  to access  external I/O if it has to go through
> the same bus)
>  - what we want to access
>  - how we want to access (and memory address decoding can become very
> complex)
>  - synchronicity (I/O must be strictly ordered, while memory access can
> be reordered)
>  - the ability to emulate I/O (for example, emulating memory-mapped I/O
> is difficult,
>      it requires a modification to the TLB miss handler)
>  - the number of additional instructions
>
> 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.

>
> 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.

???

>
> 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 !

> 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... :)

nicO

> Happy new year,
>
> >nicO
>
> YG
>

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