Hi Sergio, No problem. What we usually do is model the microarchitecture parameters -- ROB size, issue width, L1 size/associativity/ports, etc. -- after a processor such as the Intel Core 2 or similar. As you've seen, this is independent of the ISA used. The underlying implementation in modern x86 cores decodes the CISC x86 into RISC-like uops, so the ISA should be quite independent (to the first order).
- Brian On Apr 16, 2009, at 8:43 AM, Sergio Tota wrote: > 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 > ************************************* > _______________________________________________ > 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
