|
Message
From: Matjaz Breskvar<phoenix@o...>
Date: Thu May 12 20:37:01 CEST 2005
Subject: [openrisc] [or1ksim #85] [RFC] Overhoul memory code
* Gy?rgy 'nog' Jeney (nog@s...) wrote:
> > if you do a l.sb (store byte) from architectual point of view only write
> > delay access should be incured. (though in principle l.sb could have
> > different delay than l.sw). what actually happens depends on memory
> > controler you are using.
> >
> > the most common thing with 'normal' memories is that 8-bit, 16-bit and
> > 32-bit writes all take the same amount of time (the same goes for reads).
> > this is assuming you have 32-bit wide access to the memory. if not the the
> > dalays will be longer, depending on the mc width...
>
> The preivious implementation added the read and write cycles if the access
> wasn't 32-bit access but I've changed it to add the read or write delay only
> once. Which behaviour do we want?
the new one.
> > > Also, how do peripherals not under the control of a memory controller (uart,
> > > ethernet, etc) react to writting less data to a register than the width of the
> > > register? As an example what happens when you do a 16-bit write to a 32-bit
> > > wide register in the ethernet?
> >
> > this is core dependand. some devices might even not allow less than 32-bit
> > accesses (or some other accesses). by not allowing i mean sending back bus
> > error, which raises 0x200 exception.
> [snip]
> > device dependant, the developer could have decided to implement 16-bit
> > access or not (so you could get the requested data back or bus error). if
> > the 16-bit access is supported (or 8-bit) the most natural assumption is
> > that it takes 1 'write/read delay' for any of 8, 16 or 32 bit accesses.
>
> Then the granularity `emulation' functions can be removed? And if an access
> happens to an area that did not register the appropriate granularity raise a bus
> error?
well yes, this is the Right Way (tm). probably ;)... i've got a funny feeling that
doing the Right Thing might break things... well i'll trust your judgment on
this one...
> > - openrisc functions in big-endian format (architectualy). the
> > representation of this in simulator running on real machine may or may not
> > be the same. all we care about is that the end result is identical (we get
> > the 'results' on outputs (which in some way depend on inputs, so it should
> > only be neccessey changing these two)). the also care about performance, so
> > we'd like to achieve the correct result using as few transformations as
> > possible
>
> This could lead to some pretty ugly hacks...
> >
> > - the added complication of peripherals that architectualy define
> > order of data on their input and output to be different than that of an
> > openrisc should be possible to avoid by some tranformations that are depend
> > on the archtectural order and it's representation in the host machine. i'm
> > not saying that this is trivial though...
>
> I see. I think I have a sort of idea on what needs to be done then. I'll try
> and express it below.
>
> For the ensueing discussion I'm going to use the following term:
> Relative byte order: Byte ordering relative to either the openrisc architechture
> or the host running the sim. More simply `opposite byte order' will mean to be
> big-endian if the byte order is relative to little-endian and vica versa. And
> `identical byte order' will mean to be big-endian if the byte order is relative
> to big-endian byte order.
>
> Now with the above definition it should be enough define that the sim works with
> byte ordering relative to the host system. In otherwords if the sim runns on a
> little-endian machine all arithmetic done by the (simulated) cpu will be in
> little-endian and data passed to and from the peripherals will be in
> little-endian order (and define clever macros to make it easy dealing with
> this). Eg. when data is returned from the ata peripheral it will be in
> big-endian order.
>
> Then we define that all peripheral implements its own byte ordering. Meaning
> that it is peripheral dependant wether we return the big end or the little end
> of the word when doing and 8-bit read from address & 3 = 0.
>
> With these two inplace it appears like we can shove most of this under the
> carpet and let the peripherals sort out byte ordering either on their sim
> interface or however they communicate with the outside world.
>
> Does this sound like something intelligent? (or am I just thinking about this
> too hard?)
this is what i had in mind.
regards,
p.
|
 |
Browse
