Honored ContributorHi,everybody
Will you please explain what's the "Local maximum burst count" meaning in the DDR IP Controller setttings? If I don't use the avalon-bus ,can I use the burst count function? Thank you for you answer~~ Best regards, ANGEL
Honored ContributorIt's the burst count associated to the local side (the part you interface with in your logic). A burst of greater than 1 means you are performing back to back accesses by issuing a single address and providing data for multiple beats (words) of data. The controllers are now able to accept small bursts or non-burst (burst length = 1) transactions and form bursts off-chip to the SDRAM to ensure the interface is being used efficiently.
I never use that controller in non-Avalon mode but I'm certain you can still use the burst signal since it's a fundamental signal for achieving higher memory performance.Honored ContributorAppreciated for your answer~~~It's helpful~~~
But I have another question in my ealier thread, do you mind offering your help? It's about the local_ready singal. Thanks~~~Honored ContributorCan you link to your other thread, I couldn't find it.
Honored ContributorThank you ,please try this link http://www.alteraforum.com/forum/showthread.php?t=31628,
and I try to upload more pictures for your analyses, but the picture size is so big that I can't upload it... My MSN: wuditj@hotmail.com , do you mind adding me as you buddy?Honored ContributorI'm not sure in the case of the non-Avalon mode, but in the Avalon mode local_ready (or waitrequest_n using Avalon naming) must be used to throttle reads and writes to the memory controller port. So if the read or write signal is asserted but local_ready is deasserted then you must prolong your access by keeping the same address, write data (assuming you are writing to memory), local burst count, and write/ready asserted until local_ready is asserted once again. local_ready == 0 means that the interface cannot handle any more accesses and so your logic accessing the memory must wait until the interface is ready to accept more requests. The reasons for local_ready being low could be due to a refresh cycle and the command queue is full, or the memory is in the middle of calibration, etc...
Honored ContributorOK，I just generate the 32bits write data , and the write_req is like this:
but I really don't understand why the simulation local_ready is period signal... code: always @(posedge clk or negedge reset_n) begin if (reset_n == 0) begin write_req <= 1'b0; read_req <= 1'b0; end else if(local_ready) begin if((cycle_cnt >= 10'd1) && (cycle_cnt <= ({5'b0,{5{1'b1}}}))) write_req <= 1'b1; else write_req <= 1'b0; end else if (local_ready) begin if((cycle_cnt > {5'b0,{5{1'b1}}}) && (cycle_cnt <= 10'b1)) read_req <= 1'b1; else read_req <= 1'b0; end end Thank you so much~~~Honored ContributorYou shouldn't wait for local_ready to be high before accessing memory, you should use local_ready to determine if you should prolong the current access. For example your process will begin writing when local_ready is high but during the write that signal could be driven low which your logic isn't handling.
Is there a particular reason why you are attempting to interface directly to the memory controller instead of using some IP block in SOPC Builder/Qsys that could do this for you?Honored ContributorThank you for your answer.
But , if the local_ready is driven low periodly, dose it mean that my logic isn't handled? Then why this happens??? Cause I never used SOPC before, and know little about the Avalon-bus， so I plan to achieve the project using my own logic, and then try the SOPC method. Is that OK?Honored ContributorThe local_ready signal can be deasserted at times when the memory controller command queue is full. The queue can become full due to off chip refresh cycles or other commands being sent off chip that cause the queue to back up. A good example of this is if you attempt to perform a bunch of back to back reads or writes right after the memory controller comes out of reset. local_ready when the memory controller exists reset can be driven low after the command queue fills up for around 150us while the controller calibrates the interface.
This behavior has nothing to do with SOPC Builder or Qsys, this is just how the memory controller behaves. So if you instantiate the controller outside of SOPC Builder or Qsys it's still going to have this same behavior that you need to take into consideration in your mastering logic. If you plan on implementing this outside of SOPC Builder/Qsys first then I recommend just using the Avalon-MM mode of the memory controller. This will make the transition easier since you'll be working with standard interfaces at that point. I believe in non-Avalon mode the memory controller uses interleaved address and data phases which you may find more difficult to work with as well. Make sure your logic throttles when local_ready is low otherwise your reads and write *will* fail.Honored ContributorHi BadOmen,
I see how the local_ready signal works,thanks~ But I still fell confused about using the Avalon-MM mode of the memory controller outside of SOPC, now I just build my own logic based on the driver example generated automaticlly...
