On Sat, Aug 1, 2009 at 1:17 PM, Devraj Chapagain <[email protected]>wrote:

> Hi Steve,I checked the simulations changing the lines of code you suggest.
> Now I always get output 1 unlike 0 previously. That means, it also does not
> help to differentiate whether it is data or instruction.
>
> Thanks,
> drc
>
>
>
> On Fri, Jul 31, 2009 at 11:38 PM, Steve Reinhardt <[email protected]>wrote:
>
>> This is the way to do what you want.  If it's not working, then it's a
>> bug.
>>
>> It looks like the O3 CPU does not set this flag on instruction fetches
>> like it should.  I know the SimpleCPU does but hadn't look at the
>> others.
>>
>> Try changing line 599 of src/cpu/o3/fetch_impl.hh from:
>>
>>     RequestPtr mem_req = new Request(tid, block_PC, cacheBlkSize, 0,
>>                                      fetch_PC,
>> cpu->thread[tid]->contextId(),
>>                                      tid);
>>
>> to:
>>
>>     RequestPtr mem_req = new Request(tid, block_PC, cacheBlkSize,
>>                                     Request::INST_FETCH,
>>                                      fetch_PC,
>> cpu->thread[tid]->contextId(),
>>                                      tid);
>>
>> Let me know if that fixes it.
>>
>> Steve
>>
>> On Fri, Jul 31, 2009 at 6:55 PM, Devraj Chapagain<[email protected]>
>> wrote:
>> > Hi,
>> > I could not figure out whether it is data or instruction using
>> isInstFetch(
>> > ) as it always returns 0. Is there any different way (or parameters)
>> which
>> > can be used to distinguish whether the packet is data or instruction?
>> > Could anyone please help regarding this problem.
>> > Thanks in advance,
>> > drc
>> >
>> >
>> > On Wed, Jul 29, 2009 at 11:02 AM, Devraj Chapagain <
>> [email protected]>
>> > wrote:
>> >
>> >>
>> >> I'm using O3 CPU model.
>> >>
>> >>
>> >> On Wed, Jul 29, 2009 at 7:28 AM, Steve Reinhardt <[email protected]>
>> wrote:
>> >>>
>> >>> Which CPU model are you using?
>> >>>
>> >>> On Wed, Jul 29, 2009 at 1:21 AM, Devraj Chapagain<
>> [email protected]>
>> >>> wrote:
>> >>> > Hi steve,
>> >>> > I have update my m5 from the repository and tries to figure out this
>> >>> > problem. But still I face the same problem, that is,  isInstFetch()
>> >>> >  always returns 0.
>> >>> >
>> >>> > ...drc
>> >>> >
>> >>> > On Thu, Jul 9, 2009 at 8:39 AM, Steve Reinhardt <[email protected]>
>> >>> > wrote:
>> >>> >>
>> >>> >> There may be a bug where some of the CPU models don't set the
>> request
>> >>> >> flag
>> >>> >> properly.  The easiest thing to do is update from the (newly
>> updated)
>> >>> >> m5-stable repository and see if that fixes your problem.
>> >>> >>
>> >>> >> Steve
>> >>> >>
>> >>> >> On Tue, Jul 7, 2009 at 1:09 PM, Devraj Chapagain
>> >>> >> <[email protected]>
>> >>> >> wrote:
>> >>> >>>
>> >>> >>> Hi,
>> >>> >>> Actually I have not update the from the repository and i still
>> have
>> >>> >>> isInstRead(). When i use isInstRead(), it always return 0. What i
>> >>> >>> understand
>> >>> >>> from this is that the packet contains data only or instructions
>> only.
>> >>> >>> That
>> >>> >>> means, the bus passes similar type (data or instruction) of
>> datatypes
>> >>> >>> only
>> >>> >>> through out the whole simulation, which probably not the case. So,
>> I
>> >>> >>> think i
>> >>> >>> can't dump the exact data types.
>> >>> >>> Another thing is that is it necessary to update the modifications
>> >>> >>> done by
>> >>> >>> M5 like isInstRead() to isInstFetch() in order to distinguish data
>> or
>> >>> >>> instruction in the packet.
>> >>> >>> Could anyone please let me know how can i fix this problem.
>> >>> >>> Thanks in advance,
>> >>> >>> devraj
>> >>> >>> On Tue, Jun 16, 2009 at 6:58 AM, Steve Reinhardt <
>> [email protected]>
>> >>> >>> wrote:
>> >>> >>>>
>> >>> >>>> An easier approach is to call req->isInstFetch().  Note that this
>> >>> >>>> used
>> >>> >>>> to be called isInstRead() but was renamed a few months ago in the
>> >>> >>>> development tree:
>> >>> >>>> http://repo.m5sim.org/m5/rev/a27c0934de24
>> >>> >>>>
>> >>> >>>> Steve
>> >>> >>>>
>> >>> >>>> On Mon, Jun 15, 2009 at 11:16 PM, ef <[email protected]>
>> wrote:
>> >>> >>>>>
>> >>> >>>>> Hello,
>> >>> >>>>> The only way I believe is you need to use tracing setting
>> >>> >>>>> trace=Config,
>> >>> >>>>> and it will tell what ports are connected to where, and you can
>> >>> >>>>> then tell
>> >>> >>>>> what the src and dest are, as they are just numbers (no names).
>> I
>> >>> >>>>> guess you
>> >>> >>>>> can add couts and modify the code to distinguish. So basically
>> >>> >>>>> there is no
>> >>> >>>>> elegant solution, you have to hardcode it in.
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>> On Tue, Jun 16, 2009 at 1:01 AM, Devraj Chapagain
>> >>> >>>>> <[email protected]> wrote:
>> >>> >>>>>>
>> >>> >>>>>> Hi ef,
>> >>> >>>>>> yes... I mean whether the packet is from icache or dcache.
>> >>> >>>>>>
>> >>> >>>>>> On Mon, Jun 15, 2009 at 1:22 PM, ef  wrote:
>> >>> >>>>>>>
>> >>> >>>>>>> What do you mean, you mean whether it is from the icache or
>> >>> >>>>>>> dcache?
>> >>> >>>>>>>
>> >>> >>>>>>> On Mon, Jun 15, 2009 at 2:53 PM, Devraj Chapagain
>> >>> >>>>>>> <[email protected]> wrote:
>> >>> >>>>>>>>
>> >>> >>>>>>>> Hi,
>> >>> >>>>>>>> I am interested in analyzing packets. I could not figure out
>> >>> >>>>>>>> that
>> >>> >>>>>>>> the requested packet is data or instruction.
>> >>> >>>>>>>> Could anyone please help me,  what parameters tell us that
>> the
>> >>> >>>>>>>> requested packet is whether data or instruction?
>> >>> >>>>>>>>
>> >>> >>>>>>>>
>> >>> >>>>>>>>
>> >>> >>>>>>>> Thanks in advance,
>> >>> >>>>>>>> DRC
>> >>> >>>>>>>> _______________________________________________
>> >>> >>>>>>>> m5-users mailing list
>> >>> >>>>>>>> [email protected]
>> >>> >>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>> >>> >>>>>>>
>> >>> >>>>>>>
>> >>> >>>>>>> _______________________________________________
>> >>> >>>>>>> m5-users mailing list
>> >>> >>>>>>> [email protected]
>> >>> >>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>> >>> >>>>>>
>> >>> >>>>>>
>> >>> >>>>>> _______________________________________________
>> >>> >>>>>> m5-users mailing list
>> >>> >>>>>> [email protected]
>> >>> >>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>> _______________________________________________
>> >>> >>>>> m5-users mailing list
>> >>> >>>>> [email protected]
>> >>> >>>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>> >>> >>>>
>> >>> >>>>
>> >>> >>>> _______________________________________________
>> >>> >>>> m5-users mailing list
>> >>> >>>> [email protected]
>> >>> >>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>> >>> >>>
>> >>> >>>
>> >>> >>> _______________________________________________
>> >>> >>> m5-users mailing list
>> >>> >>> [email protected]
>> >>> >>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>> >>> >>
>> >>> >>
>> >>> >> _______________________________________________
>> >>> >> m5-users mailing list
>> >>> >> [email protected]
>> >>> >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>> >>> >
>> >>> >
>> >>> > _______________________________________________
>> >>> > m5-users mailing list
>> >>> > [email protected]
>> >>> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>> >>> >
>> >>> _______________________________________________
>> >>> m5-users mailing list
>> >>> [email protected]
>> >>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>> >>
>> >
>> >
>> > _______________________________________________
>> > m5-users mailing list
>> > [email protected]
>> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>> >
>> _______________________________________________
>> m5-users mailing list
>> [email protected]
>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>>
>
>
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users

Reply via email to