Hi Ryan, You're right that that packet has to do with the membus and the physmem, but the contextID means it *originated* from cpu3. For the lifetime of a request as it travels from the cpus to its destination in memory and back, it has the same contextId(). However, as it travels, it will have intermediate bus port sources as it will be traveling from cpu to DL1 cache to the tol2bus to the L2 cache to the membus to physmem (if it goes that far). I believe at each intermediate point the pkt->src is overwritten by the latest src as it forward the packet down the line.
A contextId of -1 indicates either a writeback or a device access. Lisa On Fri, Dec 19, 2008 at 7:57 PM, Ryan Markley <[email protected]> wrote: > Hello Lisa thanks for your answer, that Flag was very helpful. > > I have a question I am printg all the time the cpu origin, and I > always get a cpu origin with pkt->req->contextId(), but reviewing the > ports some packets does not seem to be related with the cpu, for > example: > > CPU: 3 <-> src_port: 0, SRC: 0 DEST: 1 > 550000: system.membus: recvTiming: src 0 dst 1 ReadResp 0x8e240 > 550000: system.membus: The bus is now occupied from tick 550000 to 552000 > > I think that this packet has nothing to do with the cpu 3 and it is > only related with membus and physical memory, this is also confirmed > with the output of the Config flag:, that says that the connection > between the physical memory and the membus, is doing with a port with > id 0. > > 0: system.membus-p0: setting peer to system.physmem-port0 > 0: system.physmem-port0: setting peer to system.membus-p0 > > So my question is, is there any way to know when a packet is really > coming from a cpu and it is not a mistake of the contextId() function > that I believe that is giving sometimes worngly information saying > that a packet is from a cpu when is not. I just want to know when the > packet is coming from a CPU and when is coming from other thing. > > And another question which one is the destination -1?, I do not see > any port with -1 id in the output generated by the config file. I > believe is the L2 cache but is this right?. Thanks so much for your > help. > > > On Fri, Dec 19, 2008 at 2:31 PM, Lisa Hsu <[email protected]> wrote: > > Hi Ryan, > > > > The CPU is indeed connected to several ports, like for example the icache > > port and a dcache port. > > > > if you turn on the trace flag "Config" you will be able to see who is > > connecting to which ports and which port numbers. > > > > As of now, (I think) there is no way to easily connect a port to the > > specific SimObject it is connected to except perhaps by printing out its > > name. Someone correct me if I'm wrong here. > > > > Lisa > > > > On Fri, Dec 19, 2008 at 4:42 PM, Ryan Markley <[email protected]> wrote: > >> > >> Hello, > >> > >> I am exploring the circulation of packages along the bus using the Bus > >> flag and some information that I am printing, and I have several > >> questions, I am using the detailed cpu and the configuration that > >> comes with the se.py file, with --caches and --l2cache options. > >> > >> I am printing the origin of the cpu with pkt->req->contextId(), and I > >> get outputs likes this: > >> > >> CPU: 1 <-> src_port: 1, SRC: 1 DEST: -1, here we see the cpu number, > >> the src_port ( pkt->getSrc() ) and the destination ( pkt->getDest() ) > >> 70000: system.membus: recvTiming: src 1 dst -1 ReadReq 0x1aa180 > >> 70000: system.membus: The bus is now occupied from tick 70000 to 71000 > >> > >> CPU: 1 <-> src_port: 0, SRC: 0 DEST: 1 > >> 100000: system.membus: recvTiming: src 0 dst 1 ReadResp 0x1aa180 > >> 100000: system.membus: The bus is now occupied from tick 100000 to > 102000 > >> > >> CPU: 1 <-> src_port: 8, SRC: 8 DEST: 6 > >> 162500: system.tol2bus: recvTiming: src 8 dst 6 ReadResp 0x1aa180 > >> 162500: system.tol2bus: The bus is now occupied from tick 162500 to > >> 175000 > >> 162500: system.tol2bus: Remove retry from list 8 > >> > >> > >> Can anyone tell me why for the same cpu there are several different > >> origin ports?, I guess is because the cpu is connected to several > >> buses with different ports, maybe one for the cache and another one > >> for the main memory, but can anyone confirm this?. but if this is > >> right I do not understand why if the port 1 is for the membus why I > >> see after port 0 also for the membus, can anyone please clarify this?. > >> > >> And also is there anyway to identificate the ports?, if one is for the > >> cache and another one for the memory is there any way to tell wich one > >> is for the cache and one for the memory?. > >> Regarding the destination I have a similar question, is there any way > >> to identify id's (pkt->getDest() ) with high level information such > >> as, main memory, L2 cache..., thank you. > >> > >> Thanks in advance. > >> _______________________________________________ > >> 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
