Apparent bug in LPDDR3 simulation (altera_emif:19.2.0) Arria 10

[KCMurphy]

During a long burst read from a (simulated) Micron LPDDR3 memory, the simulation of the Intel Arria 10 hard controller (quarter-rate) eventually drops a 32-bit word (it delivers xxx's for that portion of the 256-bit delivery).  Which kind of destroys the logic that follows.  Note that the data arrives from the Micron simulation correctly.

The ram is clocked with default automatic values (800MHz bus rate, 200 MHz reference).  It's a bit too much for me to debug, but one glaring issue is that the emif_usr_clk returned by the controller to the user design is not 200MHz but 199MHz.  This may account for an eventual data overflow in the controller.

I can mitigate this failure with a limitation on bursts, but that isn't really satisfactory.  I suspect that I will not see this issue in the actual hardware, but the controller simulation ought to be fixed.

Quartus IP folder zipped and attached.

[AdzimZM_Intel]

Hi KCMurphy,

Thank you for using Intel Community.

I want to clarify a few questions regarding this issue.

Do you able to take a snapshot when the problem is occurred or from your observation?

Are you using Intel BFM or other vendor BFM?

Is there any timing violation in the design?

If you're using the EMIF example design, may I have the design? Sharing the qar file should be fine.

Regards,

Adzim

[KCMurphy]

This project is a port of an existing, mature design into modern parts (Arria 10 for Cyclone 3, LPDDR3 for DDR2, etc).

As such, there is no use of the QSys-type structure.  The LPDDR3 controller is used bare as seen in the instantation file.   The memory simulation is from Micron, under NDA. The actual part being simulated is MT52L256M32D1PF.  All other models in the FPGA portion of the design are from Intel.

However, the emif_usr_clk signal is created in the Intel controller and that is inexplicably (and always) generated with a period of 5.024ns when provided at reference clock of 5.000ns (and an observed bus rate of 800 MHz exactly).  One would expect asynchronous clocks to be an issue.

The observed data failure is, after a long sequence of sequential reads in a single bank, with occasional row steps, the controller eventually drops data_valid and repeats the next-to-last 256 bits (32-bit transfers quarter rate).  Then it reasserts data_valid and returns a block with the first 32 bits "xxxxxxxx".  This, when fed into my DSP process, breaks everything in the simulation.

The controller is handling refresh and precharge.  Doing a predictive precharge myself did not affect the situation.  The effective workaround is to not ask for more than 8 long-words in a row.  The minimum necessary hold-off has not been determined.

The FPGA closes timing according to the Intel tools.  This isn't surprising as it ran fine in a Cyclone 3, although the memory clock rate has been doubled.

[KCMurphy]

I am not using the sample design, but the attached sample design was created from the emif ip block that I am using, using the parameter editor

[AdzimZM_Intel]

Hi KCMurphy,

Thank you for sharing the design.

I have run the simulation by using Questasim and the design has passed the calibration.

Usually the design that passed the calibration will work normally.

8 long-words will be equal to 256 bits which is the maximum width of the read and write data conduit.

Any data that exceed the limit will be invalid.

Let me know if you have different thought on this.

Thanks.

[KCMurphy]

Except that it does not proceed normally, as I have documented.

First, answer this:  after calibration, what period or frequency do you see on emif_usr_clk ?

This is the quarter-rate timing to the user logic and is supposed to be exactly 1/4 of the 800MHz DDR bus clock.

[AdzimZM_Intel · Accepted solution]

Hi KCMurphy,

The emif_usr_clk is around 199MHz and that is in the acceptable range.

The ref_clk is still at the 200MHz.