Hello, To simulate a correct execution time, although it's an cycle approximate in-order simulator, you should do this in the O3 model:
- Patch the O3: - to issue only the oldest instruction in the IQ, except re-issuing instructions - to implement and extra register scoreboard to track register dependencies and cancel the register renaming - Set Rob=squashWidth=commitWidth=renameWidth=dispatchWidth quite large (for a hypothetical dual Cortex-A8, 512 is large enough) - Set physIntReg and physFloatRegs quite large too (512 may suffice) - Delays to and from Rename, Commit and Rob = 1 I had good execution time estimations. Hope it helps. -- Fernando A. Endo, PhD student and researcher Université de Grenoble, UJF France 2014-03-10 16:42 GMT+01:00 Sudarshan <sud...@gmail.com>: > ROB not keeping pipeline depth 1 is to resemble more closely intel inorder > atom core. They have dispatch width 2 and issue2 and issue queue entries of > 16 > > This is OOO core. If ROB is not pipeline depth then you can plug in the > above parameters . You can do ROB=1 with issue queue entries to be 1 but > previously i found out that, this scenario causes severe performance loss > and actual inorder core performance is higher than this. If issue > queue entries more than 1 any ready instruction can be picked to execute > from issue queue. > If you have more entries in issue queue and you want to make it strictly > inorder then you need to switch of the register renaming and check for WAW > and WAR hazards in issue queue. Which involves some modification in issue > queue. > > If you were right about LSQ since it involves performance loss, but my > previous simulations with issue width =2, fetch2, dispatch=2,ROB=7,LSQ=7 > gave reasonable IPC estimate for inorder core. > > Let me know what you think are parameters for inorder which will help in > cross check with my IPC values. > > Thanks > > > > > Sudarshan > Graduate student > Electrical Engineering > Univ of Massachusetts Amherst > > > On Mon, Mar 10, 2014 at 11:16 AM, Zhiguo Ge <zhiguo.ge.w...@gmail.com>wrote: > >> Hi, Sudarshan >> Thanks for your reply. >> My concern is the load store queue in O3CPU may cause performance error >> as loads and stores are executed out of order which is not the case in >> InOrder CPU. >> >> You said that "ROB entries can be made to pipeline depth than keeping it >> 1". May I know why ROB entry should be set to pipeline depth? >> >> Regards, >> Zhiguo >> >> >> >> >> >> On Mon, Mar 10, 2014 at 8:06 PM, Sudarshan <sud...@gmail.com> wrote: >> >>> Yes u can do that..ROB entries can be made to pipeline depth than >>> keeping it 1.if Rob is made to 1 then u can't keep issue width of 2 since >>> Intel atom inorder processor have fetch and issue width 2.. Intel atom does >>> not have a load store queue...but load store queue entries could be made to >>> have same as Rob..increasing entries in lsq will not have any effect in >>> performance unless entries in Rob have increased.. >>> On Mar 10, 2014 5:18 AM, "GE ZHIGUO" <ge.zhi...@huawei.com> wrote: >>> >>>> Hi, All >>>> >>>> In GEM5, there is a separate InOrderCPU model which is not as well as >>>> supported as O3CPU. >>>> >>>> My question is why not modify the dispatch/issue part of O3CPU to >>>> emulate an InOrderCPU? >>>> >>>> Are there any issues to affect the accuracy of InOrderCPU model by >>>> making the O3CPU issuing the instructions in-order? >>>> >>>> >>>> >>>> Thanks! >>>> >>>> >>>> >>>> Zhiguo >>>> >>>> >>>> >>>> _______________________________________________ >>>> gem5-users mailing list >>>> gem5-users@gem5.org >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>> >>> _______________________________________________ >>> gem5-users mailing list >>> gem5-users@gem5.org >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >> >> >> _______________________________________________ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
