FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
5887 Discussions

Stratix IV GX - QDR w/ Uniphy

Altera_Forum
Honored Contributor II
788 Views

I have a custom board with two x18 250MHz QDRs (GS8662D18E-250I). I am using the example project to test each QDR individually. One of the QDRs passes all the tests from the example driver while the other always fails. I do not have any trouble getting through calibration and the echo clock, as measured at the QDR looks good.  

I did run the pin_assignments.tcl and timequest reports 0 failures. 

I modified the example driver to only write 1's and a typical failure is shown in the attached screenshot. This should be a burst of 4 so it is as if the last x18 stage is not getting clocked in correctly.  

Any thoughts as to what might be causing this? What can I do to correct this?
0 Kudos
2 Replies
Altera_Forum
Honored Contributor II
62 Views

I'm suspecting it has to do with the postamble timing. From the external memory interface handbook: Volume 4 Section III Debugging. 

 

Postamble Timing Issues and Margin 

The postamble timing is set by the PHY during calibration. You can diagnose 

postamble issues by viewing the pnf_per_byte signal from the example driver. 

Postamble timing issues mean only read data is corrupted during the last beat of any read request. 

 

That is the only information that it provides on the topic. How would one make adjustments to correct this?
Altera_Forum
Honored Contributor II
62 Views

Getting through calibration was a false positive. The sequencer will eventually get the correct data for the valid calibration part of the state machine. The latency calibration usually fails right away further complicating things when it added margin causing the latency counter to roll over.  

Now that I have added protection to that counter my bad results are more consistent. Usually only 1 sometimes 2 beats of the read are wrong. I do occasionally get the correct value, as calibration has shown. I'm not sure there is anything I can do on-die to correct this. I still don't know why it is occurring, but it seems to have something to do with the QDR itself. Any thoughts?
Reply