On Sun, Jul 3, 2011 at 5:57 PM, Julius Baxter <[email protected]> wrote: > I'm looking at how caches should be invalidated on OR1K. I don't think > it's clearly defined in the architecture specification. > > The OR1k cache control registers contain a block invalidate register > xCBIR (x=I for instruction cache, x=D for data cache.) The > specification contains the following regarding the DCBIR's behavior. > > The data cache block invalidate register is a special-purpose > register accessible > with the l.mtspr/l.mfspr instructions in supervisor mode. It is 32 > bits wide in 32-bit > implementations and 64 bits wide in 64-bit implementations. > The DCBIR is written with the effective address. If coherency is > required then the > corresponding: > * Unmodified data cache block is invalidated in all processors. > * Modified data cache block is invalidated in all processors. > * Missing data cache block in the local processor causes that data > cache blocks in other > processors are invalidated. > If coherency is not required then corresponding: > * Unmodified data cache block in the local processor is invalidated. > * Modified data cache block in the local processor is invalidated. > * Missing cache block in the local processor does not cause any action. > > In the OR1200 at present, with a single way, set associative cache, > the cache block invalidate function, simply determines the set/block > number for that address and clears the tag RAM's valid bit by writing > zeroes into the RAM entry. It does not match the set's tag against > what was written into the xCBIR. Is this behavior OK? > > This becomes relevant at reset, where the contents of the tag RAM are > undefined (there is no FSM in the RTL ensuring that RAM is cleared at > reset). At present, the software reset code loops through, writing > addresses from 0, incrementing by the set size, into the xCBIR. This > works because, as previously stated, the RTL does not check if that > the tag of the effective address written to xCBIR is actually what is > in the tag RAM - it clears the corresponding set's tag regardless. > > I think this behavior should be cleared up, as to whether or not this > is allowed. If the cache should check the tag for the set and only > invalidate if it matches, then we'll probably need an initialisation > FSM to zero that tag ram at reset. Or, we modify the architecture spec > to say that the set in all ways is cleared. > > Multi-way caches, unless we specify that the xCBIR clears all ways for > that set/block, will need a way to have their tags cleared reliably at > reset.
I've documented what I think should be added to the architecture spec on the appropriate page on the wiki: http://opencores.org/or1k/Architecture_Specification#Cache_Block_Invalidate_Behaviour_Clarification Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
