burst count

[Altera_Forum]

Hi,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

[Altera_Forum]

It'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.

[Altera_Forum]

Appreciated 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~~~

[Altera_Forum]

Can you link to your other thread, I couldn't find it.

[Altera_Forum]

Thank 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?

[Altera_Forum]

I'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...

[Altera_Forum]

OK，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~~~

[Altera_Forum]

You 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?

[Altera_Forum]

Thank 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&#65292; so I plan to achieve the project using my own logic, and then try the SOPC method. Is that OK?

[Altera_Forum]

The 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.

[Altera_Forum]

Hi 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...

[Altera_Forum]

Dear BadOmen, 

Will you please help me explain what's the "reads_remaining" mean in the following code which is from example driver generated by the controller IP? why the reads_remaining +(size-1) when local_rdata_valid is high, and why reads_remaining+size when local_rdata_valid is low... thank you~~~

[Altera_Forum]

reads_remaining: 

if ((read_req | p_read_req) & local_ready)  begin  if (local_rdata_valid)  reads_remaining <= reads_remaining + (size - 1);  else   reads_remaining <= reads_remaining + size;  end  else if ((local_rdata_valid) & (reads_remaining > 0))  reads_remaining <= reads_remaining - 1'b1;  else   reads_remaining <= reads_remaining;

[Altera_Forum]

If I had to guess it is tracking how many outstanding reads are issued to the memory controller in terms of beats (words). So you can post read accesses to the memory and after a handful of clock cycles the read data returns. So this is a counter that is counting down by 1 when read data returns and counts up when 'size' (burst size) is issued. 

 It's common to build this type of logic into a read master in SOPC Builder/Qsys as well since you normally have a FIFO internally to catch the data so knowing how many reads are posted allows you to back pressure to avoid overflowing the FIFO.

[Altera_Forum]

Dear BadOmen, 

I think your guess is right, and I understand it through the simulation wave~ Thanks!  Then, when I compile my project ,there is a critical warning  "Critical Warning: Fitter could not properly route signals from DQ I/Os to DQ capture registers because the DQ capture registers are not placed next to their corresponding DQ I/Os" . Should I take more attention on the DQ assignment? And how can I avoid the warning? Appriciated~~~

[Altera_Forum]

Did you remember to run the constraints .tcl script generated for the SDRAM controller as well as add the generated .sdc (timequest) file to your project? If not I would read the controller documentation since it goes through what you need to do step by step.