Session F1C DCMSIM: DIDACTIC CACHE MEMORY SIMULATOR. Eduardo S. Cordeiro 1, Italo G. A. Stefani 2, Tays C. A. P. Soares 3, Carlos A. P. S.

Transcription

1 DCMSIM: DIDACTIC CACHE MEMORY SIMULATOR Eduardo S. Cordeiro 1, Italo G. A. Stefani 2, Tays C. A. P. Soares 3, Carlos A. P. S. Martins 4 Abstract We present a functional and structural didactic simulator of Cache Memory Systems developed at the Pontifical Catholic University of Minas Gerais, Brazil. The development occurred during the undergraduate Computer Architecture discipline, in the Computer Science course. Its implementation is one part of a new didactic method, in which developers (students of the Computer Architecure discipline) must learn the concepts and theory of the discipline topics to correctly apply them in the simulator. In our simulator, DCMSim, there are features to allow students to construct and verify knowledge, testing and comparing several different configurations and memory access traces. Index Terms Cache Memory Simulation Tool, Cache Memory Systems, Computer Architecture Education, Learning Tool and documentation that the current API provides and transform the simulator in a web-based application in the future [4]. The DCMSim comes to supply the need for a learning aid tool in the field of memory systems [5][6][7], providing ways in which students can construct and verify knowledge in a simple and practical way. The objectoriented paradigm used in this project allows for easy expansibility, since the different memory systems and the memory structures are implemented through inheritance, and the interface itself also uses inheritance to read configuration data and display the different memory system structures in their particular way. A memory representation is shown in Figure 1: INTRODUCTION We present and analyze a didactic memory simulation software developed during a computer architecture undergraduate discipline in the Computer Science course, in the second semester of This simulator development is one part of the application of a new learning method [1] in computer architecture disciplines the students must learn the theory to apply it in the simulator development, while an already developed simulator helps them understand the functioning and structure of a memory system. Our main goals are: improve and optimize the learning of memo ry topics (concepts and techniques) using the development of memory simulators; aid knowledge verification and facilitate and optimize the execution of practical exercises related with memory systems using an easier and more optimized tool (method) than the manual method of resolution; develop a simulator that provides a simple but didactic simulation functionality for use by students of our and other courses. Other goals include the use of Java language for programming, since our idea to represent all the components of the memory systems, would be made easy with the use of a fully object-oriented language [2][3]; besides, the use of this language allowed us to build a platform-independent software with all the support FIGURE 1 CACHE MEMORY REPRESENTATION The fields in Figure 1 represent the following structures: Field 1: the valid bit, which indicates whether or not the data contained in that slot is valid or invalid; Field 2: the tag, which identifies a block, a number that is used by the controller to check whether or not the present block in a memory slot is the one that is being accessed (for the set-associative and direct-mapped systems only). The tag is the block number itself on a fully associative architecture; 1 Eduardo Santos Cordeiro, Pontifical Catholic University of Minas Gerais, Graduation Program in Computer Science Student, 500 Av. Dom Cabral Coração Eucarístico Belo Horizonte Minas Gerais, escordeiro@hotmail.com 2 Italo Giovani Abdanur Stefani, Pontifical Catholic University of Minas Gerais, Graduation Program in Computer Science Student, 500 Av. Dom Cabral Coração Eucarístico Belo Horizonte Minas Gerais, italogiovani@terra.com.br 3 Tays Cristina do Amaral Pales Soares, Pontifical Catholic University of Minas Gerais, Graduation Program in Computer Science Student, 500 Av. Dom Cabral Coração Eucarístico Belo Horizonte Minas Gerais, tayscristina@hotmail.com 4 Carlos Augusto Paiva da Silva Martins, Pontifical Catholic University of Minas Gerais, Graduation Program in Computer Science Professor, Graduate Program in Electrical Engineering Professor, 500 Av. Dom Cabral, Coração Eucarístico, Belo Horizonte, Minas Gerais, capsm@pucminas.br F1C-14

2 Field 3: the data, a group of words (block) contained in several main memory addresses; Field 4: the slot, a memory position where a block can be placed - depending on the memory architecture being implemented, more than one block can be placed in each slot. CACHE M EMORY SIMULATOR The simulator was designed as a learning tool, using problem-based learning and group projects concepts. We use the design of didactic architectural constructive blocks, in this case the memory system, and development of its simulator as motivation for theory study/learning and verification of designed constructive blocks through functional simulators also developed by students [8]. An even deeper motivation came with a challenge presented by the discipline professor: the building of a structural simulator, which would imply in more difficulties than the functional one, but also presenting better results as a learning and didactic tool. Our simulator is structurally correspondent to real memory systems, both in the interface and internally, and fo r that we built logic blocks corresponding to the constructive blocks of real memory hierarchy systems such as the main memory, the comparator and the memory slots and structures. The main purpose of this simulator is to serve as a tool for learning and analysis of functionality and performance of memories. Users can analyze many possibilities in memory configurations and techniques and also verify results and effectiveness of these possibilities. This verification can be made with the use of the log output files generated after each simulation or during its steps the DCMSim creates a file which indicates the sequence of occurrences in the memory system for the given memory trace; this file also includes the configuration in which the simulation happened and the hit ratio of the execution sequence. The project difficulties came in correctly building the logic blocks needed for the simulation of a memory system and also in the relationship between these blocks; building a simple and effective interface also proved itself difficult, since the use and layout of the Swing components demanded most of the time dedicated to the project [2][3]. DCMSIM DESCRIPTION AND ITS FEATURES DCMSim s interface has been built to be easy to use while showing all the structure of memory systems. It presents three main menu items: Configuration, Simulation, and Information. In the first one, the user can change the default simulation configuration, create a new one or load a previously created configuration from a cannot begin unless the user has selected a memory hierarchy configuration, so students must always prepare their simulations before using DCMSim. After selecting (setting) a configuration, the user can begin the simulation in the Simulation menu, where a memory trace file must be chosen if the memory trace file is incompatible with the chosen configuration (e.g. one of the memory addresses in the memory trace is greater than the memory size), an error message will be shown with a correction hint, and the user must then set another configuration before trying to load the memory trace file again. Information about the developers can be obtained in the Information menu. The initial interface (before the selection of a configuration and a memory trace file) is shown in Figure 2. FIGURE 2 THE USER INTERFACE Simulator interface The user can create, change, save or load simulation configurations using the interface; the main blocks of memory systems simulated in the program are shown in different interface tabs, and the entries on the memory hierarchy system are controlled by the user the interface allows step-by-step simulation (with the Next input button) or a leap to the last step of the simulation (with the Last input button), where all the process can be viewed. The occurrences box shows the result of each input, displaying hit, miss or miss with a substitution, and shows which block has entered the memory system due to a miss occurrence. Once a memory trace file has been loaded, the interface presents four tabs, which will be listed here and explained later in this paper: Cache memory Comparator configuration file it is important to notice that a simulation F1C-15

3 Inputs Main memory For the simulation itself and the verification of results and occurrences, there are three interface components: Occurrences box: shows a hit, miss or miss with a substitution, and the blocks that enter the upon miss occurrences; at the end of the simulation, the log file is generated using this information Next input button: goes to the next step of the simulation Last input button: goes to the last step of the simulation block size of 16 cells, 4 slots, write back mode and the FIFO substitution politics. The next step in configuration is the selection of the following variables: Main memory size Block size Number of slots Write mode Substitution politics Associativity degree These variables are shown in Figure 4. The complete interface, after the choice of a configuration and a memory trace file, with the inputs tab selected, is shown in Figure 3. FIGURE 3 THE INTERFACE READY FOR A SIMULATION Configuration The configuration interface allows the user to change various parameters of the simulation; one may also load the configurations from a previously created file, or, after creating his own configuration, he can save a new file for later use and verification. The parameters mentioned before include the memory architecture [5][7], where the user can select direct-mapped, set-associative or fully-associative architecture (in the current version, with easy expansibility possibilities); this selection is show in Figure 2. The examples given in this paper are related to the set-associative architecture configuration, since it is the one that uses a greater number of configuration variables, but the interface adapts itself to show only those variables needed to the simulation of the selected architecture. The variables in the example configuration are related to a 2-way set-associative memory, with the main memory size of 1024 cells, FIGURE 4 SELECTION OF THE SET -ASSOCIATIVE ARCHITECTURE VARIABLES Data inputs (memory trace file) The memory accesses are simulated with a memory trace file, simple text file (TXT), like the example shown in Figure 5; each access is represented by a line in this file, with the first item meaning the main memory address (an integer number), the second meaning a data (d) or instruction (i) access, the third meaning a read (r) or write (w) access and the last meaning the data/instruction itself (another integer number). In this input format, we consider that the user has converted the instructions and data to decimal values. The configuration file will not be shown in this paper, since it s generated automatically in the simulator, and its structure depends on the chosen memory architecture. F1C-16

4 d r d r d w d w 3 0 d w d r d w 5 3 d w d w d w 8 FIGURE 5 A MEMORY TRACE FILE EXAMPLE The simulation The simulation itself begins with the selection of a configuration; this action enables the Simulation menu, where the user must chose the memory trace file to be used in the execution. During the simulation, the user can change between the interface components using the tabs that appear in Figure 3. The DCMSim will then load the memory trace file (input file) and make the necessary calculations of block numbers, slot numbers (applicable in the set-associative and direct-mapped architectures) and tag numbers (applicable in the set-associative and direct-mapped architectures). The table created with this data is represented in the Inputs tab, as shown in Figure 6 as a detail of Figure 3. This tab is a didactic artifice to show the user the calculations made by the controller; this data is not kept in the hardware, but the values shown in DCMSim are the ones that will be used by the memory controller in every memory access. The memory address to be accessed is given by the user in the input memory trace file, as the one shown in Figure 5; the block address is calculated as the integer quotient of the division between memory address and block size; the tag is the integer quotient of the division between block address and the number of slots in the memory, and the slot is the integer remainder of this division. system controller simply assigns groups of bits to each one of the variables needed (block address, tag and slot). For the configuration shown in Figure 4, a visual representation of the use of a memory address is in Figure 7. FIGURE 7 THE CONVERSION OF A MEMORY ADDRESS Once the inputs have been loaded and the necessary calculations concluded, the simulation itself begins; from this point on, the interface buttons that control the execution become enabled, and the user can verify a step-by-step simulation or go to the end of the execution and check the occurrences box or the log file. If a miss occurs, the input loads data into the memory, which is represented in the Cache memory tab; the slot in which the data has been placed in the memory is highlighted in this interface, shown in Figure 8. FIGURE 8 THE CACHE MEMORY INTERFACE The comparator is represented in the Comparator tab, shown in Figure 9. This component makes the necessary comparations needed to verify the data in the memory; if a block is in the memory, it will be found in its calculated slot. If a block is not on the memory, a miss situation will be found with the use of the Valid bit or the comparation of the block tag number; the Comparator interface also show the slot in which the comparation is being made. FIGURE 6 THE INPUTS INTERFACE It is very important to notice that, although the data calculated with a memory address in the simulator is always available to be seen by the user, as in Figure 6, the FIGURE 9 THE COMPARATOR INTERFACE The last interface component that can be verified during the simulation is the Main memory; in this tab, the main memory is represented with its block addresses and the write accesses made in each block to show the difference between write modes such as write-back and write-through: in the write-back mode, the interface updates only the memory data when a write hit access is made, and the main memory is updated when a block leaves the F1C-17

5 memory; in the write-through mode, the interface updates both the memory data and the main memo ry data every time a write hit access is made. The Main memory interface is shown in Figure 10. FIGURE 10 THE MAIN MEMORY INTERFACE RESULTS VERIFICATION The simulator allows students of memory systems to analyze the difference between the memory architectures and different configurations of an unique architecture. By the step-by-step execution and visualization in the interface of memory traces and the generation of log files, the user can check advantages and disadvantages of different memory configurations used with one or many memory traces. To show the didactic purpose of our simulator, we will show the simulation results of the same memory trace shown in Figure 5 with two different configurations changing only the substitution politics (from FIFO to LRU) for a 2- way set-associative memory; in this simple example, the change of the substitution politics might cause a change in the hit ratio, showing the user ways to find out why a difference occurred. The log files given as a result of these executions are shown in Figure 11. Cache memory simulation log 01: Input 0: Cache Miss-> block 32 enters the Input 1: Cache Miss-> block 31 enters the Input 2: Input 3: Cache Miss-> block 6 enters the Input 4: Cache Miss-> block 0 enters the Input 5: Input 6: Cache Miss/Subst-> block 16 enters the Input 7: Cache memory simulation log 02: Input 0: Cache Miss-> block 32 enters the Input 1: Cache Miss-> block 31 enters the Input 2: Input 3: Cache Miss-> block 6 enters the Input 4: Cache Miss-> block 0 enters the Input 5: Input 6: Cache Miss/Subst-> block 16 enters the Input 7: Cache Miss/Subst-> block 0 enters Input 8: Cache Miss-> block 25 enters the Input 9: Hit ratio: 0.4 Cache memory configurations: Main memory size: 1024 Block size (cells): 16 Number of slots: 4 Substitution politics: FIFO Associativity degree: 2 Set-associative memory architecture the Input 8: Cache Miss-> block 25 enters the Input 9: Hit ratio: 0.3 Cache memory configurations: Main memory size: 1024 Block size (cells): 16 Number of slots: 4 Substitution politics: LRU Associativity degree: 2 Set-associative memory architecture FIGURE 11 SIMULATION RESULTS LOG FILES The difference in the two results is in input 7; when we try to access block 16 (input 6), it will cause a compulsory miss in the FIFO politics, block 32 will leave the, since its the first one to enter slot 0; in the LRU politics, block 0 will leave the, since it is the one with an older access (made in input 4, while the latest access to block 32 is made in input 5). Because of this difference in the substitution made in slot 0 at the entrance of the block 16, block 0 can be accessed in the first execution but it will have to be placed in slot 0 again in the second execution, due to its previous removal. CONCLUSIONS We have reached our goals with the development of DCMSim both the professor s goals and the students s goals; by verification with many different configurations and memory traces, we conclude that the simulator is functionally correct and serves well as a simple but effective didactic tool for the memory topics and techniques study and learning. The effectiveness of the development of the simulator as a learning-aid tool itself has also been proven with discipline tests, where students s results improved as the development of the simulators progressed. The main contribution of the simulator development activities, in which DCMSim was only one of the several simulators developed, is that it allows students to better understand the theory of memory systems and visualize the advantages and disadvantages of several architectures and their configurations. The simulator development improves the learning curve of the developers (students) and also, in the following semesters, the teaching activities of topics such as computer architecture, memory systems, memory hierarchy and other important disciplines in the Computer Science course. The object-oriented design of DCMSim allows for expansibility and the study and creation of other memory architectures, using the current software architecture as a basis for the construction of a memory system and its comparator that can be integrated and easily inserted in the interface. Since all the logic blocks F1C-18

6 of memory systems are represented as different classes, the software is fully adaptable to the simulation of new memory architectures and techniques. The learning of the Java Swing components was also achieved in this project, where the building of a simple interface with all the structure of the memory systems required the study of a great number of interface components and layouts. However, the simulator was proposed as an undergraduate discipline task, and the short time available for its development didn t allow us to implement all the features that would improve its performance as a didactic tool. Future plans include a web-based application, the inclusion of a help system and connecting this simulator with other simulators also developed in our Computer Science course, such a CPU and an Operating System simulators. Other future works in DCMSim are the inclusion of configuration parameters that are unavailable in the current version, such as the main memory access time, the choice between split or unified, number of levels, memory access time, write miss allocation, and main memory access modes (sequential, parallel) and the choice between different types for the variables in the simulator, allowing specification using bits, bytes and words (the only parameter currently available). The writing of this paper is one consequence of the DCMSim that wasn t initially planned, and came only when we realized that it had achieved a satisfying standard of quality. We had noticed the benefits from the development of a simulator as a didactic tool in previous disciplines, and used this knowledge as a motivation for the development of a structural simulator with a simple and easy to use interface. The simulator [9] can indeed be used as a didactic tool and has already been requested by the Computer Architecture discipline [10] professor to be presented and used as a learning-aid tool for the current discipline students. We strongly believe that the development and the use of this kind of tool can help the learning process of students, saving time in the classes and making the structure and functioning of the memory systems visible. [3] Horstmann, Cay S.; Cornell, Gary. Core Java 2, Vol. 2, Prentice Hall, [4] Sun Microsystems, The Source for Java Technology, [5] Smith, Alan J. Cache memories, Computing Surveys, Vol. 14, No. 3, 1982, pp [6] Hennessy, John L; Patterson, David A. Computer Organization and Design: The Hardware/Software Interface, second edition, Morgan Kaufman, [7] Hennessy, John L; Patterson, David A. Computer Architecture: A Quantitative Approach, second edition, Morgan Kaufman, [8] Costa, Alexandra S.; Pousa, Christiane V.; Martins, Carlos A. P. S. "Projeto e desenvolvimento de um simulador de memória : análise funcional e de desempenho", III Workshop em Sistemas Computacionais de Alto Desempenho WSCAD 2002, 2002, pp ,. (in Portuguese) [9] DCMSim Home Page [10] Computer Architecture Discipline Home Page, ACKNOWLEDGMENT We would like to thank the Informatics Institute for their support and the Computer Science professor Fabio Tirelo for his help on the Java Swing technology. REFERENCES [1] Martins, Carlos A. P. S.; Corrêa, João B. T.; Góes, Luis F. W.; Ramos, Luiz E. S.; Medeiros, Talles H. "A New Learning Method of Microprocessor Architecture", 32nd ASEE/IEEE Frontiers in Education Conference FIE 2002, Boston, 2002, pp. S1F16- S1F21. [2] Horstmann, Cay S.; Cornell, Gary. Core Java 2, Vol. 1, Prentice Hall, F1C-19