Hi, Yes, more info would be helpful. I would specifically look for log messages regarding refresh and self-refresh operations. Those are some conditions that would put the controller / memory in a busy state. The READ command would be delayed until either the refresh completes or a self-refresh exit completes for these cases. However as Jason indicated, more info would help confirm the actual scenario that is occurring.
Regards, Wendy From: Jason Lowe-Power via gem5-users <[email protected]> Reply-To: gem5 users mailing list <[email protected]> Date: Friday, June 5, 2020 at 10:27 AM To: gem5 users mailing list <[email protected]> Cc: "[email protected]" <[email protected]>, Jason Lowe-Power <[email protected]> Subject: [gem5-users] Re: a problem about memory access latency of HMC Hello, This is a good question for which I don't have a simple answer. I think we would need more context in the access stream/debug trace. I also suggest digging into the code to see what happens when the line "Single request, going to a busy rank" is printed. The code around that DPRINTF will probably have some hints. Cheers, Jason On Fri, Jun 5, 2020 at 12:08 AM yangyuqing--- via gem5-users <[email protected]<mailto:[email protected]>> wrote: I'm using HMC as my memory in my system. And I found a problem that once a simobject sent a read request, the latency of the response was different. I print out the DRAM trace. 1. if a read request is processed by dramctrl as follow, the latency is longer. 377334000: system.hmc_dev.mem_ctrls00: recvTimingReq: request PIMRead addr 1775248 size 8 377334000: system.hmc_dev.mem_ctrls00: Read queue limit 32, current size 0, entries needed 1 377334000: system.hmc_dev.mem_ctrls00: Address: 1775248 Rank 0 Bank 0 Row 3467 377334000: system.hmc_dev.mem_ctrls00: Read queue limit 32, current size 0, entries needed 1 377334000: system.hmc_dev.mem_ctrls00: Adding to read queue 377334000: system.hmc_dev.mem_ctrls00: Request scheduled immediately 377334000: system.hmc_dev.mem_ctrls00: QoS Turnarounds selected state READ 377334000: system.hmc_dev.mem_ctrls00: Single request, going to a busy rank 377334000: system.hmc_dev.mem_ctrls00: No Reads Found - exiting 2.if a read request is processed by dramctrl as follow, the latency is shorter. 344235000: system.hmc_dev.mem_ctrls00: recvTimingReq: request PIMRead addr 1774464 size 8 344235000: system.hmc_dev.mem_ctrls00: Read queue limit 32, current size 0, entries needed 1 344235000: system.hmc_dev.mem_ctrls00: Address: 1774464 Rank 0 Bank 0 Row 3465 344235000: system.hmc_dev.mem_ctrls00: Read queue limit 32, current size 0, entries needed 1 344235000: system.hmc_dev.mem_ctrls00: Adding to read queue 344235000: system.hmc_dev.mem_ctrls00: Request scheduled immediately 344235000: system.hmc_dev.mem_ctrls00: QoS Turnarounds selected state READ 344235000: system.hmc_dev.mem_ctrls00: Single request, going to a free rank 344235000: system.hmc_dev.mem_ctrls00: Timing access to addr 1774464, rank/bank/row 0 0 3465 344235000: system.hmc_dev.mem_ctrls00: Activate at tick 344241000 344235000: system.hmc_dev.mem_ctrls00: Activate bank 0, rank 0 at tick 344241000, now got 1 active 344235000: system.hmc_dev.mem_ctrls00: Access to 1774464, ready at 344264300 next burst at 344254400. 344235000: system.hmc_dev.mem_ctrls00: Precharging bank 0, rank 0 at tick 344262600, now got 0 active 344235000: system.hmc_dev.mem_ctrls00: Auto-precharged bank: 0 I think the point is Single request, going to a free or busy rank. I want to know in which case the rank is busy and why latency is different. _______________________________________________ gem5-users mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ gem5-users mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
