Progress Report - 2

1 Details of Simplescalar Functioning

Before making any changes to the simulator, i felt that it was very important to know what exactly the simulator is doing and changing which variable will do what. The mt.base file presented as the result of the experiment done before the last milestone had information relevant to the processor architecture, caches and simulation details. But to get a deeper knowledge of the values stored in the register files and the stage an instruction was in at each cycle, I had to understand the working of the simulator itself. It was quite interesting, infact because i am learning the same thing in Computer Design and Technology class. The algorithm which SimpleScalar is based on is called Tomasulo's Algorithm.

In this algorithm we see that there are a bunch of stages that each instruction goes through in a manner such that instructions are fetched / decoded and retired in order but in between they may be executed out of order (OOO). OOO execution is helpful because this helps our program run faster. But at the same time the architecture is a little bit more complex. I have written a detailed explanation of Tomasulo's Algorithm as applied to simplescalar here.

2 Experiments

So i ran our 'test' program again and debugged it line by line through the simulator. Initially it goes into the simulator.cc, this is the main function and first of all it initializes the fetch unit and the cache.

Then there's an infinite loop in the function simulator() that calls the various stages as talked about in the Tomasulo's Algorithm. The stages are executed backwards. So first of all it sees whether any instruction has to Retire, then if any instruction can be Executed, Issued, Dispatched or Fetched, in this order.

ROB is basically the random order buffer where all the instructions are stored and in our case has a field called State which defines which state the instruction is in, instead of the instruction actually roaming about various stages.

I made changes to the simulator and added some output instructions in the files:

·           process.cc ( to check the value of rob_head and    value of ROB[scan].state )

• The code looks something like this:
• // added by Neha Kumar for CSC-714 project on 15 Nov 2005

• #ifdef __SIB_DEBUG__
•   std::cout<<" ROB HEAD is: "<< rob_head<<std::endl;
• #endif //__SIB_DEBUG__

·           fetch.cc ( to check the value of PC )

·           frontend.cc ( value of S in Dispatch() )

·           dispatch.cc (value of rob_tail - tail of ROB ;

                                  ROB[rob_tail].pc - program counter of tail ;

                                  ROB[rob_tail].next_pc - next program counter ;

                                  ROB[rob_tail].flags - implies the type of instruction and its latency ;                                                                        

ROB[rob_tail].latency - no. of cycles required to execute ;                                                           

ROB[rob_tail].is_decision - branch instruction or not ;

                                  ROB[rob_tail].state - current state of the instruction )

All the above variables tell about the functioning of the processor stage by stage.

I would have displayed the values but the no. of cycles are just huge. and displaying all the values is not possible.

I also observed the functioning during the branch. How the processor changed the PC etc.

3 Next Step

Next step would be to see what happens when the input of branch is not known. This will be quite tricky and i myself do not know how to represent the NAN value in memory and register file and how the processor will react to it.

The major problem faced was definitely debugging the huge Simplescalar code. Seeing which function is called when and filtering out the relevant information from the general information.

Back to Home Page