Unexpected behavior of DDR3 controller on Arria V GZ when using manual refresh

[JuanEscobedo]

deHello,

I am using the DDR3 controller IP on an Arria V GZ FPGA and I am noticing a different behavior when issuing a refresh request using the manual refresh interface.

When issuing the refresh after a read request, the ready signal stays asserted and rdata_valid is asserted after the next read request and stays asserted for the expected interval:

However, when issuing the refresh request after a write, the ready signal is de-asserted. Then, after it is re-asserted, and we issue the next read request, the rdata_valid signal starts "glitching":

Can anyone point where can I find further information about this behavior? I checked the DDR3 SDRAM High-Performance Controller User Guide and External Memory Interface Handbook Volume 2: Design Guidelines For UniPHY-based Device Families documents with no luck.

Any help would be appreciated.

Thanks beforehand,

Juan Escobedo, Ph.D.

[JuanEscobedo]

Another example: here is a read, followed by a write, followed by a refresh request:

But some time later, we have the exact same sequence: read, write, refresh req, but on the next read, data valid starts glitching, which throws off the control state machine (that is why we get another refresh request shortly after).

This is the complete view:

[AdzimZM_Intel]

Hi Juan Escobedo,

I'm Adzim from Altera. I will assist you in this forum.

Is there activation signal that you are controlling when running the test?

Is it having any temperature dependency for the readatavalid to toggle suddenly?

Can you try without burst mode or burst of 8 transactions?

Regards,

Adzim

[JuanEscobedo]

Hello Adzim,

Thank you for your help with this issue. Sorry it took me a bit to circle back to this project.

Can you clarify what you mean with activation signal? I hold everything in reset (DDR controller and state machines), and when I release it, everything just starts. The first thing all state machines check if the DDR controller ready signal is asserted. If it is, then we proceed with the read/write operations.

I doubt temperature is an issue but I am unsure how to check that. 

About burst mode, we have another design that is simpler: just reads and writes the same burst length to the same address, then increments address, and repeats that works fine:

Each read/write cycle is 341 clock cycles and the refresh signal is sent every 3 of the read/write cycles (1023 clocks total). Could there be an issue with the timing of my refresh signal?

I also noticed in the working old design the ready signal does get de-asserted for 1 clock cycle after a write.

I can work on changing the control logic to have bursts of 8.

Juan

[AdzimZM_Intel]

Hi Juan,

The activation signal is the ACT signal. I think you haven't touch that signal from your controller module.

Why do you sent the refresh on every 1023 clock cycle? is it to match the tRFC?

Regards,

Adzim

[AdzimZM_Intel]

Hi Juan,

Do you have any feedback in this thread?

Regards,

Adzim

[JuanEscobedo]

Hello Adzim,

Yes, the ~1023 cycle refresh rate is to mee the timing of the memory. 

I changed the logic of my FSM a bit so that there is a gap, single clock, state between the read and write transactions and the code behaves as expected.

Thanks for your support.

Juan

[AdzimZM_Intel]

As we do not receive any response from you on the previous reply that we have provided, I now transition this thread to community support. Please login to ‘https://supporttickets.intel.com’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.