Disabling DDR4 autoprecharge

0

Hello,

I understand from other threads (https://forums.aws.amazon.com/thread.jspa?messageID=897290 , https://forums.aws.amazon.com/thread.jspa?messageID=895575 , https://forums.aws.amazon.com/thread.jspa?threadID=269319) that the DDR4 controllers have their autoprecharge signal connected to axi_addr[8]. If I understand correctly, this means that whenever the controller receives a request whose address bit 8 is 1, it will immediately close the row after the access. I understand that this is results in a higher bandwidth when requesting bursts of at least 1024B but may be inefficient in other scenarios and makes the controller open/close row policy somehow random for applications that intrinsically have shorter and irregular accesses.

Is there a way to either 1) manually control the autoprecharge for every request or at least 2) disable autoprecharge, resulting in a pure open-page policy?

Thanks,

Mikhail

mikhai
posta 3 anni fa163 visualizzazioni
2 Risposte
0
Risposta accettata

Hi,

Yes, the DDR Controller provided by AWS in sh_ddr.sv is a Xilinx IP that is hard configured to perform auto-precharge when axi_addr[8] is set. This is beneficial for sequential access patterns, but it can be inefficient for random access patterns.

Unfortunately, as of now, we do not have support for user configurable DDR Controllers. Having said that, please feel free to provide any details on your desired use-case and configurations if possible. I will be happy to provide this feedback for the team internally.

Thanks!
Chakra

AWS
con risposta 3 anni fa
0

Hi Chakra,

Thanks for your reply. It's a pity that the setting cannot be changed. I'm building an accelerator for large-scale graph analytics and some of the DDR accesses are single-beat and irregular, which would benefit from a closed-page policy. I was also considering to use our throughput-oriented memory controller ( https://www.epfl.ch/labs/lap/wp-content/uploads/2020/03/CsordasDec19_InSearchOfLostBandwidthExtensiveReorderingOfDramAccessesOnFpga_ICFPT19.pdf ) that reorders requests on a much larger scale than general-purpose controllers to maximize the row hit rate, but that would require an open-page policy or, at least, a reasonably simple policy that is not dependent on the access pattern.

Best regards,

Mikhail

mikhai
con risposta 3 anni fa

Accesso non effettuato. Accedi per postare una risposta.

Una buona risposta soddisfa chiaramente la domanda, fornisce un feedback costruttivo e incoraggia la crescita professionale del richiedente.

Linee guida per rispondere alle domande