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] |