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

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

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.

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.

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.