Post Go back to editing

CSSI clock polarity in DDR mode not following cmosClkInversionEn

Category: Software
Product Number: ADRV9002
Software Version: TES 0.24.1, Device Driver 68.8.1, ADRV9002 revision C0

Hi,

We are using the CSSI on ADRV9002 in DDR, 4 lanes, 16 bits I/Q mode like this:

Using TES, we have generated C code and adjusted the value of cmosDdrPosClkEn and cmosClkInversionEn to match this configuration as explained in the "ADRV9001 System Development User Guide":

This what I have in the generated initializeinit7.c:

		.rxSsiConfig = {
		.ssiType = ADI_ADRV9001_SSI_TYPE_CMOS, 
		.ssiDataFormatSel = ADI_ADRV9001_SSI_FORMAT_16_BIT_I_Q_DATA, 
		.numLaneSel = ADI_ADRV9001_SSI_4_LANE, 
		.strobeType = ADI_ADRV9001_SSI_LONG_STROBE, 
		.lsbFirst = 0, 
		.qFirst = 0, 
		.txRefClockPin = ADI_ADRV9001_SSI_TX_REF_CLOCK_PIN_DISABLED, 
		.lvdsIBitInversion = false, 
		.lvdsQBitInversion = false, 
		.lvdsStrobeBitInversion = false, 
		.lvdsUseLsbIn12bitMode = 0, 
		.lvdsRxClkInversionEn = false, 
		.cmosDdrPosClkEn = true, 
		.cmosClkInversionEn = true, 
		.ddrEn = true, 
		.rxMaskStrobeEn = false}

Despite this configuration, the actual CSSI behavior does not always match the configuration.

Here are oscilloscope captures of the RX1 CSSI, with RX_DCLK_OUT+, RX_STROBE_OUT+ and RX_IDATA_OUT+ (RX_IDATA0_OUT).

Sometimes we get this which what we expect (rising edge of RX_STROBE_OUT with rising edge of RX_DCLK_OUT):

But sometimes we get this unexpected behavior (rising edge of RX_STROBE_OUT with falling edge of RX_DCLK_OUT):

We see that the clock polarity changes several times (between both above oscilloscope captures) while the calibration is being done by the ADRV9002, is this expected ?

Then after the calibration, the clock polarity settle on its final state, which is sometimes the wrong polarity.

Additional version information:

/* Silicon Revision: Presumed C0*/
/* */
/* Device Driver API: v0.0.0*/
/* Device Driver Client: v68.8.1*/
/* Firmware: v0.22.24*/
/* Profile Generator: v0.53.1.0*/
/* Stream Generator Assembly: v0.7.9.0*/
/* Transceiver Evaluation Software: v0.24.1*/
/* ADRV9001 Plugin: v0.24.0*/

Thanks,

Alexis Murzeau



Emphasis on the polarity changes while the calibration is being done by the ADRV9002.
[edited by: amurzeau at 1:48 PM (GMT -4) on 19 Apr 2024]
  • Hi Alexis,

    We are looking into it 

    Regards 

    Rahul

  • Hi Alexis,

    We've been investigating the phase relationship between the RX_DCLK_OUT clock, RX_STROBE_OUT strobe, and RX_IDATA_OUT data signals in CSSI DDR mode 4 lane. Our experiments focused on the default settings (cmosDdrPosClkEn=False, cmosClkInversionEn=False) for both long and short strobes, with and without Multi-Chip Synchronization (MCS) enabled.

    Our findings indicate that without MCS enabled, the phase relationship between the clock and strobe exhibits inconsistencies across power cycles. These variations resemble the behavior depicted in Figures 59 and 61 of the user guide (UG). In contrast, enabling MCS establishes a consistent phase relationship between the clock and strobe.

    Here are some key recommendations:

    • In CSSI DDR operation, the strobe sent out at clock rising edge or falling edge is not critical as long as the first bit of strobe and data is well aligned. Even if the clock edge relative to the strobe changes between power cycles, it should not impact the BBIC’s ability to retrieve samples from the SSI interface.
    • We recommend using the default CSSI settings for DDR mode (cmosDdrPosClkEn=False, cmosClkInversionEn=False) , the clock edge is center aligned with the strobe which offers the BBIC more time to process the SSI signals accurately.
    • To ensure consistent clock-to-strobe phase alignment for every power cycle, enabling MCS.

    MCS ensures consistent signal timing (latency) across data paths within a single ADRV9001 device or between multiple devices. ADRV9001 achieves this by internally sampling a synchronization pulse signal using the device clock (DEV_CLK). This method guarantees that the reference signal used for synchronization is precisely aligned across all devices. As can be seen from Figure 85 in UG. 

    MCS feature uses six pulses to align timing across multiple ADRV9001 devices. The first four pulses synchronize the analog and digital clock dividers, while the last two synchronize the Serial Synchronous Interface (SSI). Enabling MCS ensures consistent data transfer delays (latency) between the radio frequency (RF) ports and the SSI. Even if data experiences varying delays across different channels within the SSI, the ADRV9001 can compensate. It measures the time difference between the last MCS pulse and the transmitter/receiver strobe signal for each channel. This difference is called "MCS_to_Strobe latency." To achieve consistent data timing across all channels and devices, you can calculate separate "Sample Delay" and "Read Delay" values based on the measured MCS_to_Strobe latency. These delay values are then programmed into the ADRV9001 to compensate for any variations. As can be seen from Figure 90 in UG. Hence MCS ensure to preserve the phase relation between the clock and strobe for each power cycle.

    Regards,

    Rahul