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

Reply via email to