Hi Brian,

Thanks for your help.
I also just realized that I never mentioned that I was 
using a x86 target.
The reason is that in the paper "Characterizing 
Chip-Multiprocessor Variability-Tolerance" (Herbert S. and 
Marculescu D.) in section 5.1,
the four cores considered (small, medium, large and 
monolithic) are described to be based on the Intel P54C, 
Intel Pentium III and Intel Core 2 Duo.
Thus I wrongly assumed that also the microarchitectural 
models on Flexus were x86-ISA based.
Instead I guess that those specific processors have been 
used only for the Area calculation.
Now that I'm reading better the section 5.2 the use of 
CMPFlex.OoO simulator was mentioned in the paper and in 
the Flexus manual is clearly written
that OoO models are SPARC based.
At that time, when I first read the paper, I didn't know 
it yet.
I think that I can switch to the SPARC simulator to model 
fast/slow processors to throttle instruction retirement.

Thanks again for your great help.

Regards.

Sergio


On Wed, 15 Apr 2009 13:21:59 -0400
  Brian Gold <bgold at cmu.edu> wrote:
> Hi Sergio,
> 
> I don't think I realized you were using x86 as a target. 
> We don't  decode non-memory instructions for x86, so 
>that's why the opcode is  always zero.  See the following 
>mail message from our archive for some  possible 
>workarounds (thanks to Vaggelis for pointing this out to 
>me):
> 
> https://sos.ece.cmu.edu/pipermail/simflex/2008-October/000436.html
> 
> As for your second question, this is again a limitation 
>of our x86  models.  In our papers we use a detailed, 
>cycle accurate processor  model for SPARC architectures 
>(e.g., CMPFlex.OoO or DSMFlex.OoO).   There we can vary 
>the details of the microarchitecture to model very 
> aggressive out-of-order cores, lean in-order cores, or 
>even multi- threaded cores.  Changing the target 
>processor in Simics will not get  you this effect.  You 
>could throttle instruction retirement to get a  very 
>simple mix of faster versus slower processors, though. 
> But, as  noted above, this is tough if you want to 
>examine the opcode when  making that decision.
> 
> Hope this helps,
> Brian
> 
> On Apr 15, 2009, at 12:17 PM, Sergio Tota wrote:
> 
>> Hi Brian,
>>
>> I'm having some problems on getting the opcode of the 
>>fetched  
>> instruction. The opcode I get is always zero.
>> Which part of flexus do you suggest me to tweak?
>>
>> Just another question. In some papers flexus was adopted 
>>to perform  
>> multiprocessor simulations using different cores 
>>(small,medium and  
>> monolithic).
>> What I don't get exactly is how it would be possible to 
>>use flexus  
>> in this way varying the type of processors. I simply use 
>>the CMPFlex- 
>> x86 simulator
>> and I'm wondering how I can change the "target" 
>>processor to be used  
>> in the simulation.
>> I guess that I can do that changing the simics 
>>configuration like  
>> "test.simics" working with the "target" (add-directory 
>>"%simics%/ 
>> targets/x86-440bx").
>> Is that correct?
>>
>> Thanks.
>>
>> Sergio
>>
>> Brian Gold 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
>>>
>>>
>>>
>>
>>
>> -- 
>> *************************************
>> Sergio Tota, PhD
>> Dept. of Electronic (VLSI Lab)
>> Politecnico di Torino
>> Corso Duca degli Abruzzi 24,
>> 10129 Torino, ITALY
>> Tel. +39 011 564 4004
>> Fax: +39 011 564 4099
>> *************************************
>>
> 

*************************************
Sergio Tota, PhD
Dept. of Electronics (VLSI Lab)
Politecnico di Torino
Corso Duca degli Abruzzi 24,
10129 Torino, ITALY
Tel. +39 011 564 4004
Fax: +39 011 564 4099
*************************************

Reply via email to