Project

General

Profile

MMU description » History » Version 46

Alexander Kamkin, 02/19/2013 12:32 PM

1 24 Alexander Kamkin
h1. MMU Description
2 1 Taya Sergeeva
3 35 Alexander Kamkin
A _memory management unit_ (_MMU_) is known to be one of the most complex and error-prone components of a modern microprocessor. MicroTESK has a special subsystem, called _MMU subsystem_, intended for (1) specifying memory devices and (2) deriving testing knowledge from such specifications. The subsystem provides unified facilities for describing memory buffers (like _L1_ and _L2 caches_, _translation look-aside buffers_ (_TLBs_), etc.) as well as a means for connecting several buffers into a memory hierarchy.
4 34 Alexander Kamkin
5 38 Alexander Kamkin
h2. Address Description
6
7 40 Alexander Kamkin
A buffer is accessed by an _address_, which is typically a _bit vector_ of a fixed length (width). Different buffers are allowed to have a common address space (e.g., L1 and L2 are usually both addressed by physical addresses). However, in general case, each buffer has its own domain.
8
9 43 Alexander Kamkin
An address space is described using a construct *address*. A couple of examples are given below.
10 38 Alexander Kamkin
11 1 Taya Sergeeva
<pre>
12 42 Alexander Kamkin
address Void { width = 0  }
13 45 Alexander Kamkin
</pre>
14 46 Alexander Kamkin
15 45 Alexander Kamkin
<pre>
16 41 Alexander Kamkin
address PA   { width = 40 }
17 38 Alexander Kamkin
</pre>
18
19 44 Alexander Kamkin
The code above defines two address spaces: (1) a single-element space @Void@ and (2) a space @PA@ consisting of 40-bit addresses (_PA_ usually stands for _physical address_).
20 10 Alexander Kamkin
21 2 Taya Sergeeva
h2. Buffer Description
22
23
For instance, this is an example of the buffer below:
24
25
<pre>
26
buffer L1 
27
{
28
	sets = 4
29
	lines = 128
30
	line = (tag:30 data:256)
31
	index(addr:PA) = addr<9**8> 
32
	match(addr:PA) = line.tag == addr<39**10>	
33
	policy =  lru
34 10 Alexander Kamkin
}
35 1 Taya Sergeeva
</pre>
36
37
38
_Description of each constructor_ in the buffer example is below:
39 19 Taya Sergeeva
40
h3. ''address'' 
41
42
<pre>
43
  gives the width of the field occupied in bytes;
44
  ''address'' has a name; ''PA''(Physical Address) in our case; it also can be virtual (VA);
45
</pre>
46
47 21 Taya Sergeeva
h3. ''buffer''
48
49
<pre>
50
  has a name, ''L1'' in pur example; it can have names ''L2'' and ''TLB'' also;
51
  ''buffer'' can be described by different parameters, such sets, lines, index, match, policy, and so on, which number is infixed;
52
</pre>
53 1 Taya Sergeeva
54 15 Taya Sergeeva
h3.  ''set'' 
55 16 Taya Sergeeva
56 15 Taya Sergeeva
<pre>
57 1 Taya Sergeeva
  is an associativity of a buffer; it returns the number of lines in a one set;
58 15 Taya Sergeeva
</pre>
59 1 Taya Sergeeva
60 15 Taya Sergeeva
h3.  ''lines''
61 17 Taya Sergeeva
62 15 Taya Sergeeva
<pre>
63 1 Taya Sergeeva
  is the number of lines in a given buffer;
64 15 Taya Sergeeva
</pre>
65 13 Taya Sergeeva
66 15 Taya Sergeeva
h3.  ''line''
67 17 Taya Sergeeva
68 15 Taya Sergeeva
<pre>
69 1 Taya Sergeeva
  designates the specific line in which the necessary data will be looking for; 
70
  ''line'' includes its own parameters in the braces: ''tag'' and ''data'', each of them has an appropriate width of the fields kept in bytes;
71
  in our example ''line'' has only two parameters, but in general case it can include more;
72 15 Taya Sergeeva
</pre>
73 14 Taya Sergeeva
74 15 Taya Sergeeva
h3.  ''index''
75 17 Taya Sergeeva
76 15 Taya Sergeeva
<pre>
77 1 Taya Sergeeva
   returns the initial and the final points of the field kept in bytes; they are marked in a three-cornered brackets, after ''addr'';
78 14 Taya Sergeeva
  ''index'' depends on an ''address'', which is ''physical'' (PA) in our case; the type of an address is set in the braces after ''index''; 
79 15 Taya Sergeeva
</pre>
80 1 Taya Sergeeva
81 15 Taya Sergeeva
h3.  ''match'' 
82 17 Taya Sergeeva
83 1 Taya Sergeeva
<pre>
84 16 Taya Sergeeva
  returns ''true'' or ''false'' depending on if the data required is in the given line or not; 
85
  it returns ''true'' if there is a ''hit'' in the line, and returns ''false'' otherwise;
86 14 Taya Sergeeva
  ''match'' description contains the the initial and the final points of the address field in the triangle brackets after ''addr''; 
87 1 Taya Sergeeva
  as ''index'' in the round braces ''match'' also has the type of the address used; ''PA'' in our case;
88
</pre>
89
90
h3.  ''policy''
91
92
<pre>
93
  sets a policy which will be applied to our buffer, ''lru'' (Least Recently Used) in our example;
94
  policy also can be ''plru'' (Pseudo LRU) and ''fifo'' (First Input First Out).
95
</pre>
96 25 Alexander Kamkin
97
h2. Code Structure
98
99
The MMU grammar is in ru.ispras.microtesk.translator.mmu.grammar folder. It contains Lexer, Parser and TreeWalker files. These files can be compiled by build.xml file (microtesk++/build.xml). The files generated (MMULexer.java, MMUParser.java, MMUTreeWalker.java) are in microtesk++.gen.ru.ispras.microtesk.translator.mmu.grammar folder. 
100
101
The folders ru.ispras.microtesk.translator.mmu.ir.* contain the inner representation of the MMU hierarchy of one buffer.  
102
103
MMU translator is in the ru.ispras.microtesk.translator.mmu.translator folder. 
104 1 Taya Sergeeva
105
Files in ru.ispras.microtesk.model.api.mmu folder contain different policies of cache. Folder ru.ispras.microtesk.model.api.mmu.buffer contains the model of MMU - the files which describe Buffer, Set, Line, Address expressions.  
106 26 Alexander Kamkin
107
After grammar files being generated the file ''BufferExample'' can be loaded to the translator.