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

Reply via email to