SDR SDRAM controller problem

Hi John,

--- Quote Start ---

Does this problem look familiar to anyone?

Any idea where should I look for a solution?

--- Quote End ---

Since you made no comments about the design meeting timing, that is where I would first look.

You need to constrain the FPGA pins so that the control signals from the FPGA to the SDR meet timing, and so that the data bus meets timings for both write and read.

Cheers,

Dave

Thanks for your answer.

I have chosen loose timing requirements so I believe I would have no issue on that and that's why I did not mention it at all.

I have also checked signals at the oscilloscope and by sending always the byte 0x00 and sometimes I see that some wires of the data bus become logic '1' instead of staying always at logic '0' as the stored data would have been logic '1'.

--- Quote Start ---

I have chosen loose timing requirements so I believe I would have no issue on that and that's why I did not mention it at all.

--- Quote End ---

You don't get to chose the timing requirements, you must meet the timing requirements stated in the SDR data sheet.

You can make your timing requirements easier to meet by using a lower clock frequency to the SDR. However, you still need to meet refresh timing requirements.

Cheers,

Dave

Noting that you have written your own SDRAM controller, have you included refresh behavior? If not, it would be best to go back and re-read the SDRAM datasheet.

You will also need to constrain the timing so your design will synthesize properly. If you do not constrain your design, it will most likely not function properly.

Hi John,

Let's say your design must comply with two sets of timing requirements:

- SDRAM timing specification itself, namely row precharge time, data latency, refresh period, and so on. This is sort of 'functional' timing and depends uniquely on your hdl code.

- FPGA timing; you must make sure all sdram signals generated by fgpa mantain a good synchronization across routing and i/o pins, namely they have no excessive skew or trasmission delays. For this part, you need to carefully constrain your design.

Thank you all for your answers.

--- Quote Start ---

You can make your timing requirements easier to meet by using a lower clock frequency to the SDR. However, you still need to meet refresh timing requirements.

--- Quote End ---

First I had applied SDRAM clock at 50MHz but the design did not work even when I reduced the frequency at 12.5MHz.

Refresh behaviour has been provised but I am not sure if it is working properly since even if I remove it same problems occur.

--- Quote Start ---

You will also need to constrain the timing so your design will synthesize properly. If you do not constrain your design, it will most likely not function properly.

--- Quote End ---

--- Quote Start ---

FPGA timing; you must make sure all sdram signals generated by fgpa mantain a good synchronization across routing and i/o pins, namely they have no excessive skew or trasmission delays. For this part, you need to carefully constrain your design.

--- Quote End ---

Since all you are telling me that I need to constrain my design I will follow that. I thought I do not need to do it if frequency is low but probably I am wrong.

Regards,

John

--- Quote Start ---

Since all you are telling me that I need to constrain my design I will follow that. I thought I do not need to do it if frequency is low but probably I am wrong.

--- Quote End ---

Yes, you are wrong :)

You have to have timing constraints on the clock(s) and the I/Os, so that the synthesis tool can make placement decisions related to the internal routing delays, and so that it can program the delay lines in the I/O elements (these delay lines are used to meet external setup and hold time requirements).

Rysc has a tutorial on the Altera Wiki

http://www.alterawiki.com/wiki/timequest

and this thread has a document I wrote when asking Rysc some questions:

http://www.alteraforum.com/forum/showthread.php?t=31457

Cheers,

Dave

Thanks again for your answer.

I will study the links you provided and also Altera's documents.

I am convinced about constraining the design and I am working on that but I still have a question.

In the design so far I used to launch data on a falling edge and SDRAM or other peripherals latch them on rising edge. In such a way I believed that the design will meet timing requirements since there is not high frequency. Even if I have not constrain the design shouldn't be working?

Regards,

John

--- Quote Start ---

In the design so far I used to launch data on a falling edge and SDRAM or other peripherals latch them on rising edge. In such a way I believed that the design will meet timing requirements since there is not high frequency. Even if I have not constrain the design shouldn't be working?

--- Quote End ---

What makes you think using the falling-edge will help? That only makes sense if you know what the clock-to-output delay of the FPGA is, and the setup and hold requirement of the SDR is, and then determine that you would have excessive setup time and minimal hold time using the rising-edge, so then you use the falling-edge to trade-off setup time for increased hold time. However, that type of analysis is not possible on an FPGA without applying timing constraints. FPGAs have programmable delays in their I/O elements that are used adjust timing.

But, sure, it might be possible to meet timing without constraints. Have you looked at the external signals with an oscilloscope? Perhaps your timing is ok, but you have ringing on your signals that are corrupting the data.

Cheers,

Dave

Problem solved, SDRAM controller is now working very good.

There were 2 issues. The first was that I did not apply constraints as you all noticed that. The second issue was concerning the clock signal I lead to the SDRAM. It seems it had ringing or some kind of a noise by causing malfunction to the communication between controller and SDRAM. By placing a small capacitor (15pF) between the clock line and the GND signal all errors disappeared. As you realize hardware is custom too.

Thank you very much for your help and for the time you spent.

Regards,

John