MMU description » History » Version 56
Taya Sergeeva, 02/22/2013 02:26 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 | 56 | Taya Sergeeva | address Void { width = 0; } |
13 | 45 | Alexander Kamkin | </pre> |
14 | 46 | Alexander Kamkin | |
15 | 45 | Alexander Kamkin | <pre> |
16 | 56 | Taya Sergeeva | address PA { width = 40; } |
17 | 38 | Alexander Kamkin | </pre> |
18 | |||
19 | 55 | Taya Sergeeva | 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_). It also can be virtual (_VA_). |
20 | 10 | Alexander Kamkin | |
21 | 2 | Taya Sergeeva | h2. Buffer Description |
22 | 1 | Taya Sergeeva | |
23 | 56 | Taya Sergeeva | Buffer is described by the construct *buffer*. Buffer can have different parameters, such as the associativity, *sets*, i.e. the set''s size, and the number of sets in the buffer, *lines*. |
24 | 1 | Taya Sergeeva | |
25 | 56 | Taya Sergeeva | <pre> |
26 | buffer TLB |
||
27 | { |
||
28 | sets=8; |
||
29 | lines=64; |
||
30 | } |
||
31 | </pre> |
||
32 | 1 | Taya Sergeeva | |
33 | 56 | Taya Sergeeva | The example above describes translation lookaside buffer (_TLB_), which has an associativity being equal to 8, (i.e. the number of lines in one set in this TLB buffer is equal 8), and has the number of lines being equal to 64. |
34 | |||
35 | Each line of the buffer can be described optionally by tag and data parameters. |
||
36 | For example, |
||
37 | |||
38 | 1 | Taya Sergeeva | <pre> |
39 | 56 | Taya Sergeeva | line = (tag:22, data:1024); |
40 | </pre> |
||
41 | |||
42 | describes lines of the cache, each of them containing a 22-bit tag and 1024-bit data. |
||
43 | |||
44 | Each device stores some data which can be accessed (read from or written into) by their address. If a device contains a line with a given address, this situation is called a ''hit''; the opposite situation referes to as a ''miss''. If a ''miss'' occurs, the device usually displaces one of the set''s line with the line associated with the address given. The predicate which determines if there is a ''miss'' or ''hit'' situation is called *match*. |
||
45 | |||
46 | <pre> |
||
47 | ... |
||
48 | </pre> |
||
49 | |||
50 | The strategy which will be used for line displacement is specified by *policy*. |
||
51 | |||
52 | <pre> |
||
53 | policy = LRU; |
||
54 | </pre> |
||
55 | |||
56 | Example above sets the strategy of data replacement to be Last Recently Used policy, i.e. if the ''miss'' occured, the cache displaces the least-recently-used line of the set. |
||
57 | |||
58 | --- |
||
59 | When accessing data, the cache determines a set by calculating a 2-bit index (index) |
||
60 | -- |
||
61 | Buffer also can have the index computing function, the match checking predicate. *match* |
||
62 | tag computing function, the index computing function, and the structure of data unit displacement, the controlling bits, the strategies of data changing when ''miss'' occurs, and so on. |
||
63 | -- |
||
64 | |||
65 | |||
66 | |||
67 | |||
68 | For instance, there is the example of the buffer L1 below: |
||
69 | |||
70 | <pre> |
||
71 | 2 | Taya Sergeeva | buffer L1 |
72 | { |
||
73 | 53 | Taya Sergeeva | sets = 4; |
74 | lines = 128; |
||
75 | line = (tag:30, data:256); |
||
76 | index(addr:PA) = addr<9..8>; |
||
77 | match(addr:PA) = line.tag == addr<39..10>; |
||
78 | policy = lru; |
||
79 | 10 | Alexander Kamkin | } |
80 | 1 | Taya Sergeeva | </pre> |
81 | |||
82 | |||
83 | _Description of each constructor_ in the buffer example is below: |
||
84 | 19 | Taya Sergeeva | |
85 | h3. buffer |
||
86 | 49 | Taya Sergeeva | |
87 | 21 | Taya Sergeeva | <pre> |
88 | 55 | Taya Sergeeva | has a name, ''L1'' in our example; it can have names ''L2'' and ''TLB'' also; |
89 | 21 | Taya Sergeeva | _buffer_ can be described by different parameters, such _sets_, _lines_, _index_, _match_, _policy_, and so on, which number is infixed; |
90 | 1 | Taya Sergeeva | </pre> |
91 | 51 | Taya Sergeeva | |
92 | 16 | Taya Sergeeva | h3. sets |
93 | 15 | Taya Sergeeva | |
94 | 54 | Taya Sergeeva | <pre> |
95 | 15 | Taya Sergeeva | _sets_ is an associativity of a buffer; it returns the number of lines in a one set; |
96 | 1 | Taya Sergeeva | </pre> |
97 | 49 | Taya Sergeeva | |
98 | 17 | Taya Sergeeva | h3. lines |
99 | 15 | Taya Sergeeva | |
100 | 54 | Taya Sergeeva | <pre> |
101 | 15 | Taya Sergeeva | _lines_ is the number of sets in a given buffer; |
102 | 13 | Taya Sergeeva | </pre> |
103 | 49 | Taya Sergeeva | |
104 | 1 | Taya Sergeeva | h3. line |
105 | 17 | Taya Sergeeva | |
106 | 54 | Taya Sergeeva | <pre> |
107 | _line_ is an optional description of line''s fields; |
||
108 | 1 | Taya Sergeeva | it designates each line of the cache; |
109 | 52 | Taya Sergeeva | _line_ includes its own parameters in the braces: _tag_ and _data_, each of them has an appropriate width of the fields kept in bytes; |
110 | 54 | Taya Sergeeva | in our example _line_ has only two parameters, but in general case it can include more; |
111 | 14 | Taya Sergeeva | it contains a 30-bit tag and a 256-bit data; |
112 | 1 | Taya Sergeeva | </pre> |
113 | |||
114 | 49 | Taya Sergeeva | h3. index |
115 | 17 | Taya Sergeeva | |
116 | 54 | Taya Sergeeva | <pre> |
117 | _index_ is the function for index calculation; |
||
118 | 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_; in our case index has 2 bits; |
119 | _index_ depends on an _address_, which is ''physical'' (PA) in our case; the type of an address is set in the braces after _index_; |
||
120 | </pre> |
||
121 | |||
122 | 49 | Taya Sergeeva | h3. match |
123 | 17 | Taya Sergeeva | |
124 | 54 | Taya Sergeeva | <pre> |
125 | _match_ is a predicate checking whether the line and the address match each other or not; |
||
126 | it returns ''true'' or ''false'' depending on if the data required is in the given line or not; |
||
127 | 1 | Taya Sergeeva | it returns ''true'' if there is a ''hit'' in the line, and returns ''false'' otherwise; if the set contains a line with the tag equal to the 30 upper bits of the physical address, this is a ''hit''; if the set does not contain the line, this is a ''miss'' situation; |
128 | _match_ description contains the the initial and the final points of the address field in the triangle brackets after _addr_; |
||
129 | 52 | Taya Sergeeva | as _index_ in the round braces _match_ also has the type of the address used; ''PA'' in our case; |
130 | 1 | Taya Sergeeva | </pre> |
131 | |||
132 | h3. policy |
||
133 | 49 | Taya Sergeeva | |
134 | 1 | Taya Sergeeva | <pre> |
135 | 54 | Taya Sergeeva | _policy_ is the strategy of data displacement; |
136 | 56 | Taya Sergeeva | sets a policy which will be applied to our buffer, ''lru'' (Least Recently Used) in our example; |
137 | 52 | Taya Sergeeva | policy also can be ''plru'' (Pseudo LRU) and ''fifo'' (First Input First Out). |
138 | 1 | Taya Sergeeva | </pre> |
139 | 25 | Alexander Kamkin | |
140 | h2. Code Structure |
||
141 | |||
142 | 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. |
||
143 | |||
144 | The folders ru.ispras.microtesk.translator.mmu.ir.* contain the inner representation of the MMU hierarchy of one buffer. |
||
145 | |||
146 | MMU translator is in the ru.ispras.microtesk.translator.mmu.translator folder. |
||
147 | 1 | Taya Sergeeva | |
148 | 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. |
||
149 | 26 | Alexander Kamkin | |
150 | After grammar files being generated the file ''BufferExample'' can be loaded to the translator. |