a b Week 3 I have ran a few programs from SPLASH suite on SESC. I am now studying the source code to get familiar with the simulator. Week 4 I spent most of the week going through the SESC source code. The questions that I had to look into were: how does timing model and the emulator, MINT, interact which each other?, how clean is the interface between the two? Would it be necessary to create two objects - one for the timing model and one for the functional simulator in order to migrate applications between different instances of the SESC simulator? I found that the interface between the timing model and the functional simulator is well defined and the two interact only through a fixed set of functions. Also, timing model doesn't store any kind of physical state. I confirmed some of the things by emailing Professor Jose Renau at UC, Santa Cruz. This week I am going to focus on the next step towards building the simulator infrarstructure. I will be modifying source code in order to support multiple instances of SESC - including timing model and MINT. Week 5 What I've been doing: Past week, I studied the SESC source code to find out what kind of changes are to be made in order to create multiple instances of the SESC simulator. Which variables and structures are global? When creating two instances of SESC in a single process, they shouldn't share any global variables (for now). OS wrapper, event queue, task handler, SESC configuration, etc are some of the global variables in SESC source code. I started to modify the source code by creating a simulator class, and making OSSim instance a member of this class. And have the classes which make use of OSSim functions inherit from this class. I then digged into event scheduler and MINT, to see what kind of changes are necessary in order to support multiple SESC instances. Since MINT being written in C, the MINT source code will have to be modified to look more like object-oriented code. I also discussed this with Adam to get his input on this task. Your suggestion (friday's meeting) - to have the simulator instances and NOC communicate using sockets, seems to be a better approach than to try and modify the simulator like we had discussed earlier. I am now working on adding the socket interface. An idea I had: I had thought off pulling the event queue out of the event scheduler and change the callback and event scheduler interface so as to have one event queue per each simulator. And I had started to make changes accordingly. Although, this would have worked, looking at the changes that are needed to be made to the MINT and SESC as a whole - socket approach does seem better. One idea so far in creating the socket interface is to pass the port numbers as a command line argument to each SESC instance. NOC will communicate with each instance on a separate port.What I've been doing: I have completed the driver code, which will serve as the interface between the Network On-Chip (NOC) and multiple SESC instances. Here, the NOC acts as a client and will communicate with each SESC instance on an assigned port. And each SESC instance will serve as a server, listening on the assigned port. I have spent rest of the week trying to understand the MemorySystem and MemoryOS code - the goal being to have multiple SESC instances now share physical memory. What functions of MemoryOS are called by the SESC code for translations? How is page allocation and eviction implemented? I have found answers to these and other related questions while studying the source code. I have also traced the initialization calls made to the MemorySystem and MemoryOS during SESC's boot up process. An idea I had: After studying the MemoryOS code, I am thinking of implementing one page table per SESC instance. SESC instances can start by having equal number of physical pages, and they can then communicate to a driver which will handle requests for page allocations when all the pages of a current SESC instance have been used up. The next step then is to create this driver to handle page allocation requests, and modify SESC code which makes page allocation and eviction decisions. Week 6 - above. Week 7 Beginning of last week, I tried to further improve my understanding of the SESC source code to better compare the two plans for implementing shared memory. And I met with you to discuss some of the questions that I had regarding the overall design. I then went on to implement the central page handler. I have also started hacking SESC to work with this interface. This week I will continue working on this. An idea I had: I wouldn't call it an idea, just something I thought might work which actually didn't. I haven't had a lot of experience in socket programming, so I thought I would be able implement non blocking sockets without having to use select or similar routine. But indeed, a part of the handler that I have implemented needs to be modified to now use select. Week 8 What I've been doing: Week before last, I had started implementing shared memory by going with having page tables located at SESC instance. Adam and I discussed the two approaches a little more after he had gone through the source code, and we both decided to have page tables at the Central Page Handler. Past week I began hacking the SESC source code to have TLB's only, and pull out the page table to Central Page Handler. I have done most of the implementation required for this design at both SESC and Driver side. And we are now working towards integrating everything, and then proceed with testing. An idea I had: I did quite a bit of coding last week, so there were quite a few implementation related ideas that I had. For example, I chose to use the HASH_MAP for implementing TLB at the Central Page Handler. It was fun creating this interface. Spring Quarter Week 3 What I've been doing: The past week I spent time debugging the NoC Interface and its interaction with SESC. An unusual problem that I stumbled across was that the messages sent from SESC were not being seen at the NoC Interface. I ruled out the possibility of there being a bug at the NoC Interface, seen it was checking the input queues every cycle. I've now been hacking the changes that we have decided to make to the coherence protocol. After I am done with these changes, next week I will be spending time debugging and testing the code with the new coherence policies. An idea I had: There were a few code related ideas that I've had over the past week. What I've been doing : Again, most of the past week I spent debugging the simulator. We also made some minor changes to the coherence policies. We are now able to successfully simulate one SESC instance by keeping all the latencies 1 cycle and things are fine even when I varied the L2, NoC, and memory latency. I also added support for multiple L2 banks. We are also able to simulate two SESC instances with 10,000 instructions. I now have to debug the simulator for >10000 instructions, and figure out what the problem is. An idea I had : Since, I have been doing lot of debugging and testing. I have been making lot of choices at code level. What I've done : I have been debugging the memory system. There are a quite a few race conditions we are seeing for longer simulations like 50M instructions. Upto, 40M instructions both the sesc instances reach the instruction count without any errors or warnings. This seems to be a little hard to debug because replicating the bugs is not easy. But I have been able to find a few bugs. Debugging using direct mapped caches seems to be much better because the race conditions seen for 4 -way associative caches appear much earlier. I will be continuing with more debugging and testing for the rest of the week.