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
demandé il y a 3 ans163 vues
2 réponses
0
Réponse acceptée

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
répondu il y a 3 ans
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
répondu il y a 3 ans

Vous n'êtes pas connecté. Se connecter pour publier une réponse.

Une bonne réponse répond clairement à la question, contient des commentaires constructifs et encourage le développement professionnel de la personne qui pose la question.

Instructions pour répondre aux questions