On 01/20/2012 08:43 PM, Alexander Graf wrote:
Am 20.01.2012 um 21:01 schrieb Scott Wood<address@hidden>:
I'm not sure what happens when you write
an entry to TLB1 with an invalid TSIZE.
What it says, the ISA means it's implementation dependent. What e500mc actually
implements is an different question. Which still needs to be answered.
AFAIK it's not documented what e500mc does for invalid sizes in TLB1, so
I think anything that complies with the architecture's statement of any
supported size is OK.
However for now I think wde 're ok by not modeling every odd corner case.
Sure. I was just curious about the architectural statement.
+ /* XXX only applies for MAV 1.0 */
+ size_tlb = (tlb->mas1& MAS1_TSIZE_MASK)>> (MAS1_TSIZE_SHIFT + 1);
+ size_min = (tlbncfg& TLBnCFG_MINSIZE)>> TLBnCFG_MINSIZE_SHIFT;
+ size_max = (tlbncfg& TLBnCFG_MAXSIZE)>> TLBnCFG_MAXSIZE_SHIFT;
+ if ((size_tlb> size_max) || (size_tlb< size_min)) {
+ /* set to min size */
+ tlb->mas1&= ~MAS1_TSIZE_MASK;
+ tlb->mas1 |= size_min<< (MAS1_TSIZE_SHIFT + 1);
+ }
You could just implement a bitmap now, which will work for MAV 2.0 as well.
Especially since we're using the MAV 2.0 definition of tsize already, so
min/max isn't an accurate way to describe what we support.
Not sure I follow. In MAV 1.0 the size constraints are defined in TLBnCFG,
while for MAV 2.0 they are defned in their own bitmap registers (TLBnPS)
Would you like to have a function called that returns a bitmap of
supported sizes for the TLB depending on its MAV value based on
either TLBnCFG or TLBnPS? We could then check if that size value bit
is set.
Yes, use a bitmap internally regardless of how the programming model
says we convey the information to the target code.