- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would like to use a waitrequestAllowance of 1 with a DDR4 EMIF core in an Arria 10 design. This parameter appears in the .sopcinfo file (which I don't want to mess with, for obvious reasons), but I can't find where it gets set (if at all) in the platform manager configuration tool.
I am using Quartus Prime Pro 18.1.
Thanks.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
HI,
You have the right mindset where user shouldn't mess around with DDR4 IP internal setting.
waitrequestAllowance looks exactly like one of these internal setting that shouldn't be touched by user.
- So, may I know why would you want to control it ?
- Or can you explain further what are you trying to do with DDR4 IP here ?
- Ideally user should only control the interface signal exposed on DDR4 IP top level design only
If I look at the EMIF user guide doc, the closest user controlled signal should be "amm_ready" signal that indicate whether DDR4 memory controller is busy or not.
- amm_ready is the inverse of amm_wait_request signal
- User should only send command request to DDR4 memory controller whenever it's ready to accept command when amm_ready assert high
Thanks.
Regards,
dlim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am trying to optimize the performance of the interface driving the slave interface of the DDR4 controller. Per the Avalon Interface Specification:
waitrequestAllowance:
Specifies the number of transfers that can be issued or
accepted after waitrequest is asserted.
When the waitrequestAllowance is 0, the write,
read and waitrequest signals maintain their existing
behavior as described in the Avalon-MM Signal Roles
table.
When the waitrequestAllowance is greater than 0,
every clock cycle on which write or read is asserted
counts as a command transfer. Once waitrequest is
asserted, only waitrequestAllowance more
command transfers are legal while waitrequest
remains asserted. After the waitrequestAllowance
is reached, write and read must remain deasserted
for as long as waitrequest is asserted.
Once waitrequestdeasserts, transfers may resume
at any time without restrictions until waitrequest
asserts again. At this time, waitrequestAllowance
more transfers may complete while waitrequest
remains asserted.
A waitrequestAllowance of greater than 0 (I am hoping for a value of 1) allows the master to send one more word of data after waitrequest is asserted by the slave (i.e. the EMIF). With a waitrequestAllowance of 1 I get an extra clock to decide on backing off, which allows registering control signals thus eliminating some asynchronous delays.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Alright, I get what you are trying to do now.
However since this is internal setting hardcoded in EMIF IP, we both aligned that we don't want to mess with it to prevent breaking the EMIF IP functionality.
Even if you manage to optimize the data transfer on Avalon bus but if memory controller is not ready to process the data then it won't help much in overall BW or throughput performance.
Therefore, as alternate option, feel free to checkout EMIF user guide doc (chapter 13) for some tips in optimizing memory controller.
Thanks.
Regards,
dlim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So it is hard-coded - I suspected this would be the case. Thanks for the clear answer.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Welcome !
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page