MMU description » History » Version 41
Alexander Kamkin, 02/19/2013 12:19 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 | 41 | Alexander Kamkin | An address space is described using a construct *address*. Some examples are given below. |
10 | 38 | Alexander Kamkin | |
11 | 1 | Taya Sergeeva | <pre> |
12 | 41 | Alexander Kamkin | address void { width = 0 } |
13 | address PA { width = 40 } |
||
14 | 38 | Alexander Kamkin | </pre> |
15 | |||
16 | 41 | 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. |
17 | 10 | Alexander Kamkin | |
18 | 2 | Taya Sergeeva | h2. Buffer Description |
19 | |||
20 | For instance, this is an example of the buffer below: |
||
21 | |||
22 | <pre> |
||
23 | buffer L1 |
||
24 | { |
||
25 | sets = 4 |
||
26 | lines = 128 |
||
27 | line = (tag:30 data:256) |
||
28 | index(addr:PA) = addr<9**8> |
||
29 | match(addr:PA) = line.tag == addr<39**10> |
||
30 | policy = lru |
||
31 | 10 | Alexander Kamkin | } |
32 | 1 | Taya Sergeeva | </pre> |
33 | |||
34 | |||
35 | _Description of each constructor_ in the buffer example is below: |
||
36 | 19 | Taya Sergeeva | |
37 | h3. ''address'' |
||
38 | |||
39 | <pre> |
||
40 | gives the width of the field occupied in bytes; |
||
41 | ''address'' has a name; ''PA''(Physical Address) in our case; it also can be virtual (VA); |
||
42 | </pre> |
||
43 | |||
44 | 21 | Taya Sergeeva | h3. ''buffer'' |
45 | |||
46 | <pre> |
||
47 | has a name, ''L1'' in pur example; it can have names ''L2'' and ''TLB'' also; |
||
48 | ''buffer'' can be described by different parameters, such sets, lines, index, match, policy, and so on, which number is infixed; |
||
49 | </pre> |
||
50 | 1 | Taya Sergeeva | |
51 | 15 | Taya Sergeeva | h3. ''set'' |
52 | 16 | Taya Sergeeva | |
53 | 15 | Taya Sergeeva | <pre> |
54 | 1 | Taya Sergeeva | is an associativity of a buffer; it returns the number of lines in a one set; |
55 | 15 | Taya Sergeeva | </pre> |
56 | 1 | Taya Sergeeva | |
57 | 15 | Taya Sergeeva | h3. ''lines'' |
58 | 17 | Taya Sergeeva | |
59 | 15 | Taya Sergeeva | <pre> |
60 | 1 | Taya Sergeeva | is the number of lines in a given buffer; |
61 | 15 | Taya Sergeeva | </pre> |
62 | 13 | Taya Sergeeva | |
63 | 15 | Taya Sergeeva | h3. ''line'' |
64 | 17 | Taya Sergeeva | |
65 | 15 | Taya Sergeeva | <pre> |
66 | 1 | Taya Sergeeva | designates the specific line in which the necessary data will be looking for; |
67 | ''line'' includes its own parameters in the braces: ''tag'' and ''data'', each of them has an appropriate width of the fields kept in bytes; |
||
68 | in our example ''line'' has only two parameters, but in general case it can include more; |
||
69 | 15 | Taya Sergeeva | </pre> |
70 | 14 | Taya Sergeeva | |
71 | 15 | Taya Sergeeva | h3. ''index'' |
72 | 17 | Taya Sergeeva | |
73 | 15 | Taya Sergeeva | <pre> |
74 | 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''; |
75 | 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''; |
76 | 15 | Taya Sergeeva | </pre> |
77 | 1 | Taya Sergeeva | |
78 | 15 | Taya Sergeeva | h3. ''match'' |
79 | 17 | Taya Sergeeva | |
80 | 1 | Taya Sergeeva | <pre> |
81 | 16 | Taya Sergeeva | returns ''true'' or ''false'' depending on if the data required is in the given line or not; |
82 | it returns ''true'' if there is a ''hit'' in the line, and returns ''false'' otherwise; |
||
83 | 14 | Taya Sergeeva | ''match'' description contains the the initial and the final points of the address field in the triangle brackets after ''addr''; |
84 | 1 | Taya Sergeeva | as ''index'' in the round braces ''match'' also has the type of the address used; ''PA'' in our case; |
85 | </pre> |
||
86 | |||
87 | h3. ''policy'' |
||
88 | |||
89 | <pre> |
||
90 | sets a policy which will be applied to our buffer, ''lru'' (Least Recently Used) in our example; |
||
91 | policy also can be ''plru'' (Pseudo LRU) and ''fifo'' (First Input First Out). |
||
92 | </pre> |
||
93 | 25 | Alexander Kamkin | |
94 | h2. Code Structure |
||
95 | |||
96 | 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. |
||
97 | |||
98 | The folders ru.ispras.microtesk.translator.mmu.ir.* contain the inner representation of the MMU hierarchy of one buffer. |
||
99 | |||
100 | MMU translator is in the ru.ispras.microtesk.translator.mmu.translator folder. |
||
101 | 1 | Taya Sergeeva | |
102 | 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. |
||
103 | 26 | Alexander Kamkin | |
104 | After grammar files being generated the file ''BufferExample'' can be loaded to the translator. |