| Date: | Fri, 14 May 2010 10:37:01 +0800 |
|---|---|
| From: | "张轶" <zhangyi@xxxxxxxxxxxxxx> |
| Subject: | [Gems-users] 回复: 回复: 回复: 回复: 回复: Latency and number of memory request |
------------------ 原始邮件 ------------------
发送时间: 2010年5月12日(星期三) 晚上9:12
收件人: "Gems Users"<gems-users@xxxxxxxxxxx>;
主题: Re: [Gems-users]回复: 回复: 回复: 回复: Latency and number of memory request According to my foggy recollection of the GEMS memory controller, MEM_CTL_LATENCY ends up as part of the enqueue-message delay, and BANK_BUSY_TIME is part of modeling the utilization of the banks themselves. E.g.:
At time T, a request is sent to Bank B. Total service time for that request is MEM_CTL_LATENCY + MEM_FIXED_DELAY, so when the request is issued, a response message is enqueued with that delay (the delay of the memory is modeled as a queueing delay in MemoryController.C). However, Bank B will be in operation servicing the request for BANK_BUSY_TIME, which is less than MEM_CTL_LATENCY, so the bank is marked as busy that number of cycles as well.
In other words, it is not double-charging for tRCT+CL+AL -- it is simply accounting for delay and contention.
Regards,
Dan 2010/5/12 张轶 <zhangyi@xxxxxxxxxxxxxx>
-- http://www.cs.wisc.edu/~gibson [esc]:wq! |
| [← Prev in Thread] | Current Thread | [Next in Thread→] |
|---|---|---|
| ||
| Previous by Date: | Re: [Gems-users] Help: simulation is hanged in LL or EL protocols., Polina Dudnik |
|---|---|
| Next by Date: | Re: [Gems-users] Help: simulation is hanged in LL or EL protocols., ritchie wang |
| Previous by Thread: | Re: [Gems-users] 回复: 回复: 回复: 回复: 回复: 回复: Latency and number of memory request, Dan Gibson |
| Next by Thread: | Re: [Gems-users] 回复: 回复: 回复: 回复: 回复: Latency and number of memory request, Dan Gibson |
| Indexes: | [Date] [Thread] |