Post Go back to editing

MCS Procedure

Category: Hardware
Product Number: ADRV9002

ADRV9002 multi-chip synchronization.

We are trying to synchronize two transceivers witin one ADRV9002 chip.

Following the Reference Manual (chapter: Multi-chip synchronization), we send 6 pulses to the MCS input (MCS+ and MCS- pins, LVDS, produced by the AD9528 chip).

Unfortunately, the procedure does not end successfully. After the fifth pulse, the system was stuck in this state. According to Table 42 / page 100 of the Reference Manual, function: adi_adrv9001_Mcs_SwStatus_Get(), returns: MCSSWSTATUS_DEVICE_PULSE5_RECEIVED

Can we get more detailed documentation regarding MCS in ADRV9002 ?

Regards,

Slawek

Parents
  • Hi Slawek,

    Can you share any details about your profile?

    In addition to that, what are the pulse length and the time between pulses that you're using for MCS?

    Kind Regards,
    Michał

  • Hi Michał,

    We started with 6 pulses with a duty cycle of 50%, time between rising edges of 120us.

    We then increased the time to 1 ms.

    Now we generate single pulses with a duration of T_ON = 60us, triggered "manually", checking the states for MCS. The intervals between pulses are then on the order of seconds.

    The SETUP and HOLD times for the MCS pulse are maintained.

    Regards,

    Sławek

  • Hi Sławek,

    Are you doing this on your own hardware, or on the EVB?

    Can you share the TES session file (.taxidi format) that you used when generating your profile?

    Kind Regards,
    Michał

  • Hi Michał,

    We use our own hardware.

    TES session save as requested.

    MCS_config.zip

    Best regards,

    Sławek

  • HI Sławek,

    Thanks. Are you able to re-create the issue on the EVB?

    Kind Regards,
    Michał

  • Hi Michał,

    We are currently unable to reproduce the MCS issue in EVB. The MCS block of our hardware is modeled on the EVB for the ADRV9008_9 (Thalise Design Package) using the AD9528 chip.

    To run the MCS mechanism on the ADRV9002 EVB board we need to connect another EVB - AD9528 or HMC7044.

    This will require a lot of work from us. We use Altera FPGA, running the above-mentioned synchronization will be quite a challenge.

    Looking back of our issue, after the fifth pulse, the system was stuck in this state. According to Table 42 / page 100 of the Reference Manual, function: adi_adrv9001_Mcs_SwStatus_Get(), returns: MCSSWSTATUS_DEVICE_PULSE5_RECEIVED

    Are there any special circumstances that HDL part has to follow in order to pass this last cycle? Does the HDL part actively participate in this process? Looking at "MCS to Strobe Timing Diagram" (page 101 of Reference Manual) we can see that first strobe puls appears after sixth pulse of the MCS. Is it required to keep LVDS in idle state before sixth MCS pulse?

    Best Regards,

    Sławek

  • Hi Sławek,

    Looking at "MCS to Strobe Timing Diagram" (page 101 of Reference Manual) we can see that first strobe puls appears after sixth pulse of the MCS. Is it required to keep LVDS in idle state before sixth MCS pulse?

    Yes, since the MCS procedure is performed in the calibrated state, and the ADRV9002 is is not expecting SSI data at this state.

    One other point important point that a colleague of mine discovered: the MCS procedure only works when performed in the first calibrated state after a reset. This means that if you bring the ADRV9002 to primed, perhaps continue to RF Enabled, and then back to calibrated, the MCS procedure will not work as this is not the first calibrated state after reset.

    Kind Regards,
    Michał

  • Yes, we know about MCS procedure in the first calibrated state after reset and we follow this requirement.

    We understand that ADRV9002 does not expect data from SSI in this state. However in our setup SSI is active before the sixth pulse appear. Is it acceptable?

    Best Regards,

    Sławek

Reply Children
  • Hi Sławek,

    While ideally, it wouldn't cause any issues, I don't have any other ideas about what could be causing your issue, so it's worth trying to see if waiting until after MCS is complete to start the SSI interface resolves your problem.

    One other suggestion may be to look beyond MCS and see if there's anything more fundamental that may be causing this issue. You can run adi_adrv9001_Utilities_SystemDebugPreCalibrate() to see if all the underlying systems are working correctly. You can then also try running adi_adrv9001_Utilities_SystemDebugPostCalibrate() after calibrating without MCS to see if anything else may be causing issues.

    Kind Regards,
    Michał