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

Re: [f-cpu] about register mapping

Le Dimanche 11 Janvier 2004 02:32, Yann Guidon a écrit :
> '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.

sure... many clock for the same system, is for sur a safest choice... There 
are no chance of skew and all that kind of mess. 
DMA are for the peripherals. Some PCI card cary there own DMA. We could even 
speak on one it manager that should be managed to spread IT to all cpu. I 
don't think tied one IT to one cpu is very healty...

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

I would see those url so i could speak with the PCI expert at my work.

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

So how do you transfert the data ? What happen if you want to read a RS232 
input data ? You freeze the computer until the data is read ? You wait for an 
iterrupt call ? (so polling became impossible) You must use a dma ? (which 
could be a real mess)

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

What a mess !! All memory protection are there and you want to create some new 

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

Because you have all the flexibility of the memory sub-system (protection, 
ordering, only mecanism to handle all of this inside the cpu). Memory 
controler are not as fast as L1 cache, it's in other place on the die. So L1 
will be faster than SDRAM controler register.

It's only a problem of decoding and "typing" of pages to access the  internal 
register by memory port.

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

It's surely to be compatible with old hardware. New one didn't used that. 
That's an old mess from x86.

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

Sorry but i can not imagine how it's possible to dare to write that kind of 


> >nicO
> YG

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