Documentation, Programming and Rate Questions with the 6583 DDR Connector CLIP

[Pie566942.0]

Hi All,

I have a few questions about the NI 6583 DDR Connector CLIP.

There are 16 LVDS pairs on the 6583.  The CLIP reference reads, "The LVDS data and direction lines on DDC B are accessed using a U16 data type (for rising, falling, reads, writes, and direction control)."  The data types of LVDS_Data_Dir, LVDS_Data_Rd/Wr_Rise/Fall are all U16 in 1.1.0\Ni6583ConnectorDdr.xml. However the CLIP reference contains the following figure:

Perhaps "U32" is a typo?  I assume "U32" should be "U16" in the figure.

The rightmost column is labeled "NI 6583 Connector Signal".  I also assume that "DIO 0" through "DIO 8" should show +/- similar to "DIO 9+, DIO 9-" through "DIO 15+, DIO 15-" as not to be blindly confused with the single-ended connections in Figure 3 of the 6583 User Manual labeled "DIO0" through "DIO31" as shown below:

Could you please verify these are typos and my corrections are correct?  My application will be internally clocked at 150MHz for asynchronous acquisition at the maximum DDR rate of 300MHz.

I need to know which edge will be sampled first?  Do I have to build something into the LabVIEW application to enforce a sampling order so the data gets packed and unpacked correctly?  When I look at the LabVIEW 2011/RIO 12.0 shipping example, the order is implied as Rising/Falling.  Perhaps this is handled under the hood in the CLIP?

Target	Host

Another thing I'm scratching my head about is the TI datasheet for the SN65LVDM180 lists the "Maximum Recommended Operating Speed" of the chip as 150 Mbps in Rx-only mode, yet both the CLIP and the constraints seem to support double that rate.  Can someone please help me understand this?

Thank you for your time and assistance,

Steve K

[Pie566942.0]

For anyone who cares, yes, they're all typos in the documentation, the rising edge is sampled first, and NI swears by the data rates in their specs.  Reference Service Request 7372926 if you need it in writing.

[Kyle_A.]

Hi Steve,

The errors in the documentation have been filed under Corrective Action Request #387771 and we will look to change what it says moving forward in the future.  We apologize for the inconvenience and thank you for bringing that to our attention.

The clocking specification that you mentioned was a change that was made after the release of the part, by TI.  We were aware of this change and retested the new revision and found that it still operates at the speeds we originally used it at, despite the derating of the chip.

I hope the assistance you received on your service request has helped you move forward with your application.  Thank you for your responses.

Kyle A.

HSDIO Product Support Engineer, R&D

[Pie566942.0]

Thanks for your help along the way Kyle.  I was posting to close the loop in case anyone needed the same information.

Best,

Steve K