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