Hello, I have a few questions about O3CPU and se.py.
1. In gem5 documentation it is stated that O3CPU is loosely based on Alpha 21264, and that issue, execute and writeback stages are implemented as a single stage. Does that mean it takes only one cycle for an instruction to pass through IEW stage (assuming that there are enough resources, no misses for load/stores, etc)? Or does it still take the same number of cycles as going through three different stages? 2. In one cycle, how many read/write requests can be sent to the data cache utilized in se.py? I am currently experimenting with se.py (Deriv3CPU cpu type) and other scripts in configs directory. From what I can tell, there is one port for the data cache through which the processor can send read/write requests. Is that correct? (I remember reading that one master port for sending requests to the cache, one slave port for receiving responses from the cache.) But it looks like multiple cache accesses can be handled by the cache at once, based on the trace output below. Am I missing something? > 173978: system.cpu.iew.lsq.thread0: Doing memory access for inst > [sn:14] PC (0x10470=>0x10474).(0=>1) 173978: system.cpu.dcache: recvTimingReq tags: set: 17 block: 0 > state: 5 (S) valid: 1 writable: 0 readable: 1 dirty: 0 tag: 0 set: 18 block: 0 state: 5 (S) valid: 1 writable: 0 readable: 1 dirty: > 0 tag: 0 set: 187 block: 0 state: f (M) valid: 1 writable: 1 readable: 1 > dirty: 1 tag: f 173978: system.cpu.dcache: access for ReadReq addr 0x484 size 4 173978: system.cpu.dcache.tags: set 12: moving blk 480 (ns) to MRU 173978: system.cpu.dcache: ReadReq addr 0x484 size 4 (ns) hit state: 5 > (S) valid: 1 writable: 0 readable: 1 dirty: 0 tag: 0 > ... > 173978: system.cpu.iew.lsq.thread0: Doing memory access for inst > [sn:18] PC (0x11134=>0x11138).(0=>1) 173978: system.cpu.dcache: recvTimingReq tags: set: 17 block: 0 > state: 5 (S) valid: 1 writable: 0 readable: 1 dirty: 0 tag: 0 set: 18 block: 0 state: 5 (S) valid: 1 writable: 0 readable: 1 dirty: > 0 tag: 0 set: 187 block: 0 state: f (M) valid: 1 writable: 1 readable: 1 > dirty: 1 tag: f 173978: system.cpu.dcache: access for ReadReq addr 0x144c size 4 173978: system.cpu.dcache: ReadReq addr 0x144c size 4 (ns) miss 173978: system.cpu.dcache.cpu_side: Port is blocking new requests 3. I read in gem5 documentation that the default cache in gem5 is a non-blocking cache with MSHRs. What I'm wondering is, is it based on the primary data cache used in Alpha 21164 or 21264. I read that the data cache in 21164 is duplicated to provide dual-port support, and the one in 21264 operates at twice the frequency of the processor clock. I was wondering whether gem5's cache implementation followed one of these two or not. Thanks.
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users