Re: [gem5-users] Small entry table creation in gem5
Hello. I think it depends on the purpose of the table and modeling features. For example, let's look a cache tag modeling case. BaseTags class (/mem/cache/tags/base.hh), which is a kind of table to store tags, inherits the ClockedObject, because BaseTags needs to model the clock latency. However, Cacheset class (/mem/cache/tags/cacheset.hh), which is used in BaseSetAssoc (it inherits BaseTags class), doesn't inherit any class. Because, Cacheset is just a data structure, which doesn't model clock latency. The latency to access Cacheset (it sounds wired actually, because latency is for tag access and Cacheset is subset of tag model) is modeled in BaseSetAssoc class, which inherits ClockedObject. Haeyoon Cho 2017-10-10 13:17 GMT+09:00 Muhammad Avais : > Hi, > > I want to create small table (256 entries) in gem5 that is accessed on > each cache miss and follows LRU replacement policy. > > Can someone guide me how to do it? (Which classes i should use or inherit) > > Many Thanks > > Avais > > ___ > 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] (no subject)
Hi, Does GEM5 follows any specific cache coherence protocol? If yes? then which one? Thanks ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Fwd: Issue related to requests having no contextID
Read requests to the memory addresses that are in the write queue and not
written yet to the memory has to be responded from the write queue. I am
not sure if this answer your question, but seems like this is what you are
observing.
Thanks,
Prathap
On Oct 10, 2017 2:17 AM, "Prakhar Javre" wrote:
> A gentle reminder for our last query. Please have a look.
> [Edit] We printed the command name of packets in writeQueue inside the
> chooseNext function.
>
>for(auto i = queue.begin(); i != queue.end() ; ++i) {
> DRAMPacket* dram_pkt = *i;
>if(!dram_pkt->pkt->req->hasContextId()){
> inform("command : %s, read: %d, addr: %lu",
> dram_pkt->pkt->cmdString(), dram_pkt->pkt->isRead(), (dram_pkt)->addr);
> }
> if (ranks[dram_pkt->rank]->isAvailable()) {
> queue.erase(i);
> queue.push_front(dram_pkt);
> found_packet = true;
> break;
> }
> }
>
> Turns out that some of the packets in write queue have isRead() true and
> their command is changed to readReq and readResp.
> Can anyone help us in understanding why this peculiar behavior is getting
> observed.
>
> Thanks
> Prakhar Jawre
> IIT Kanpur, India
> -
>
> Hi guys,
>
> We are implementing a scheme for protection against timing channel attacks
> in DRAM controllers. In that, it is required to choose request (for DRAM
> controller) from a specific core at any particular time. While checking for
> it, we found that a lot of requests are not having contextIDs. We also
> modified cache code to assign contextIDs to writeback requests, but
> apparently, even some of the read requests (and other requests also) are
> not having any contextID. Can you guys help us in figuring out from which
> place exactly are these requests coming?
>
> System config -
> 2 Cores, L1I, L1D, L2(shared), Prefetch off.
>
> Thanks,
> Prakhar Jawre
> IIT Kanpur, India
>
>
>
> ___
> 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] Fwd: Issue related to requests having no contextID
A gentle reminder for our last query. Please have a look.
[Edit] We printed the command name of packets in writeQueue inside the
chooseNext function.
for(auto i = queue.begin(); i != queue.end() ; ++i) {
DRAMPacket* dram_pkt = *i;
if(!dram_pkt->pkt->req->hasContextId()){
inform("command : %s, read: %d, addr: %lu",
dram_pkt->pkt->cmdString(), dram_pkt->pkt->isRead(), (dram_pkt)->addr);
}
if (ranks[dram_pkt->rank]->isAvailable()) {
queue.erase(i);
queue.push_front(dram_pkt);
found_packet = true;
break;
}
}
Turns out that some of the packets in write queue have isRead() true and
their command is changed to readReq and readResp.
Can anyone help us in understanding why this peculiar behavior is getting
observed.
Thanks
Prakhar Jawre
IIT Kanpur, India
-
Hi guys,
We are implementing a scheme for protection against timing channel attacks
in DRAM controllers. In that, it is required to choose request (for DRAM
controller) from a specific core at any particular time. While checking for
it, we found that a lot of requests are not having contextIDs. We also
modified cache code to assign contextIDs to writeback requests, but
apparently, even some of the read requests (and other requests also) are
not having any contextID. Can you guys help us in figuring out from which
place exactly are these requests coming?
System config -
2 Cores, L1I, L1D, L2(shared), Prefetch off.
Thanks,
Prakhar Jawre
IIT Kanpur, India
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
