[Gems-users] Can Simics memory requests vary with different Ruby protocols?


Date: Wed, 11 Oct 2006 00:31:56 +0200
From: mehmetderin.harmanci@xxxxxxx
Subject: [Gems-users] Can Simics memory requests vary with different Ruby protocols?


  Hello all,

  I would like to ask whether the access requests from Simics can vary among
  different protocols. At first sight this does not seem possible to me.
  But maybe I'm missign something. Here are some details of my simulations:

  0) I'm doing two simulations to compare two different memory architecture
     In one simulation I'm using MOESI_SMP_directory and in the other I'm
     using MSI_MOSI_CMP_directory. The architecture using MOESI_SMP_directory
     is meant to be a CMP with private L2 caches, while the other is used
     for a shared L2 cached CMP. I'm using a system with 4 processors.
  1) The simulations are started from the same checkpoint.
  2) The same programs are run from the simulated machine console.
  3) When I print the memory address requests sent from Simics
     (I do the printf's in the makeRequest function at SimicsProcessor.C file),
     I see that for the same processor the address requests may differ.
     Generally the address request match for a good bunch of addresses but
     later a stream of different addresses are seen at the same processor
     for different simulations. After that stream, again the addresses match
     for a while.
     Also for some processors, I have even seen that in one simulation the
     processor is asked some addresses while in the other simulation these
     addresses were not present at all in the processor request trace.

  What am I missing? Why are the traces show differences? (I do not think
  different protocols create different exceptions such that the operating
  system reacts differently because exceptions related to memory system are
  raised in the MMU as far as I know,so I was confused).

  Any help will really be appreciated.

  Best Regards,


     Derin Harmanci.



[← Prev in Thread] Current Thread [Next in Thread→]