Sure, this may not be as hard as you think.  To model different clock  
frequencies, you could find the least common multiple (LCM) of the  
various frequencies you care about.  For example, suppose you want  
core 1 to be 1GHz and core 2 to be 2GHz.  The LCM would be 2GHz in  
this case.  You can operate the simulation at a 2GHz frequency  
(basically just set the memory latencies to the appropriate number of  
cycles) and then insert a stall cycle on every other clock tick in  
core 1.  This example is simple and your choice of frequencies may  
require more complex stall cycles (e.g., 1 stall every N cycles), but  
I believe it's doable.

Let me know if you run into trouble with this.

- Brian


On Jan 27, 2009, at 5:48 PM, Sergio Tota wrote:

> Hello Brian,
>
> Thanks to your help I succeeded both to inspect the opcode in the  
> doCycle() as well as perform
> a test of the current processor instance in the Execute module for  
> multiprocessor configurations.
> I just finished a quick test but it *seems* to work.
>
> I have another question concerning the possibility of running each  
> processor instance at a different clock frequency.
> I guess that here things become much more complicated for a  
> synchronization issue among the cores.
>
> Any suggestion would be of great help.
>
> Really thank you for the great support you are giving to me.
>
> Sergio
>
> On Tue, 27 Jan 2009 14:41:59 -0500
> Brian Gold <bgold at cmu.edu> wrote:
>> Oops, that should have been:
>>> unsigned long opcode = theROB.front()->instruction().opcode();
>> I haven't tried this, so you may have to tweak it a bit.
>> - Brian
>> On Jan 27, 2009, at 2:36 PM, Brian Gold wrote:
>>> Hi Sergio,
>>>
>>> You can do this in doCommit().  To get the opcode, try:
>>>
>>> unsigned long opcode = theROB.front()->instruction()->opcode();
>>>
>>> In a multiprocessor simulation, each core gets its own Execute   
>>> module, so yes, you can selectively control the behavior of each   
>>> processor instance.
>>>
>>> Let us know if you have any other questions.
>>>
>>> - Brian
>>>
>>> On Jan 27, 2009, at 12:24 PM, Sergio Tota wrote:
>>>
>>>> Dear Brian,
>>>>
>>>> Thanks for your help.
>>>>
>>>> I succeeded to add a wait-state to the doCommit() function.
>>>> I'm still not sure where to inspect the opcode to decide if wait-  
>>>> state should be enabled though.
>>>> Should I inspect it in the doCommit() or somewhere else like  
>>>> inside  "SimicsTracer.hpp" around line 588?
>>>>
>>>> Another question I have is about performing a multiprocessor   
>>>> simulation using this wait-state approach.
>>>> Can I selectively control the behaviour of every processor  
>>>> instance  to decide if a given instruction should be performed in  
>>>> one cycle  or two cycles?
>>>>
>>>> Thanks.
>>>>
>>>> Sergio
>>>>
>>>>
>>>> Brian Gold wrote:
>>>>
>>>>> Hi Sergio,
>>>>>
>>>>> I recommend you look at the Execute module (components/Execute/   
>>>>> ExecuteImpl.cpp).  Look at the doCommit() function around line   
>>>>> 866.   This function gets called every cycle, so you can simply   
>>>>> insert wait  states after inspecting the opcode accordingly.   
>>>>> You  can alternatively  stall the dispatch() side of the  
>>>>> pipeline in  the Execute module, but  it may take a little bit  
>>>>> more work.  Let  us know if you have further  questions.
>>>>>
>>>>> - Brian
>>>>>
>>>>>
>>>>>
>>>>> On Dec 12, 2008, at 12:00 PM, Sergio Tota wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm quite new to Simics & Flexus so probably some of my  
>>>>>> assumptions  are wrong.
>>>>>> What I'm trying to do is to make some instructions multi-cycle.
>>>>>> For what I got Flexus increases the cycles-counter every new    
>>>>>> instruction fetch.
>>>>>>
>>>>>> What I would like to do is to analyze every instruction and    
>>>>>> selectively decide if the given instruction
>>>>>> is one cycle (cycles-counter= cycles-counter +1) or multi- 
>>>>>> cycle   (cycles-counter= cycles-counter +2).
>>>>>> (For now my multi-cycle is 2 c.c. instead of normal 1 c.c.)
>>>>>>
>>>>>> To implement this behavior I can see two main steps:
>>>>>> 1)Analyze the op-code every instruction fetch
>>>>>> 2)Selectively increase Flexus cycles-counter of 1 or 2.
>>>>>>
>>>>>> For both the points I think that I have to work at the   
>>>>>> "SimicsTracer.hpp",
>>>>>> in the Instruction Fetch section starting from line 588.
>>>>>>
>>>>>> What I would do for Point-1 is to use the   
>>>>>> "SIM_read_phys_memory()"  function
>>>>>> to inspect the opcode at every instruction fetch in order to   
>>>>>> decide  if the given instruction
>>>>>> will be 1-cycle or 2-cycles.
>>>>>> Once I have decided the cycle-length of the instruction I  
>>>>>> would  use  the Flexus function
>>>>>> "theCycleManager->advanceFlexus()" twice instead of only one  
>>>>>> as  it  is in the original code
>>>>>> in case of 2-cycles operations to perform Point-2.
>>>>>>
>>>>>> For what I got, at every instruction fetch this function is   
>>>>>> called  at the very beginning of the code.
>>>>>> I would add a second call to this function every time I detect  
>>>>>> a   particular op-code that I want to make 2-cycles.
>>>>>>
>>>>>> I'm particularly worried about synchronization problems  
>>>>>> between   Flexus and Simics,
>>>>>> especially in case of CMP simulation where more instances of  
>>>>>> the   processor are running.
>>>>>>
>>>>>> Can you give me some advices about what I'm trying to do?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Sergio
>>>>>> _______________________________________________
>>>>>> SimFlex mailing list
>>>>>> SimFlex at ece.cmu.edu
>>>>>> https://sos.ece.cmu.edu/mailman/listinfo/simflex
>>>>>> SimFlex web page: http://www.ece.cmu.edu/~simflex
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> SimFlex mailing list
>>>> SimFlex at ece.cmu.edu
>>>> https://sos.ece.cmu.edu/mailman/listinfo/simflex
>>>> SimFlex web page: http://www.ece.cmu.edu/~simflex
>>>
>>> _______________________________________________
>>> SimFlex mailing list
>>> SimFlex at ece.cmu.edu
>>> https://sos.ece.cmu.edu/mailman/listinfo/simflex
>>> SimFlex web page: http://www.ece.cmu.edu/~simflex
> _______________________________________________
> SimFlex mailing list
> SimFlex at ece.cmu.edu
> https://sos.ece.cmu.edu/mailman/listinfo/simflex
> SimFlex web page: http://www.ece.cmu.edu/~simflex

Reply via email to