AD9375 0x254 register infos

The 6th bit is The VCO comparator output.  Low = VCO voltage is lower than desired; high = VCO voltage is higher than desired.

This is a read only bit.

There are no cases where the VCO voltage is as desired?

Hello, 
Is it a misunderstanding and 0 = lower than expected and 1 = OK?

Which pin (alim) affect the VCO voltage?
VDDA_CLK
VDDA_SER
VDDA_DES
VDDA_TXLO
VDDA_TXVCO
VDDA_TXSYNTH
VDDA_RXTX
VDDA_BB
VDDA_RXRF
VDDA_RXLO
VDDA_RXVCO
VDDA_SNRXVCO
VDDA_RXSYNTH
VDDA_SNRXSYNTH
VDDA_CLKSYNTH
VDDA_CALPLL
VDIG

Thanks

DamienL said:

Is it a misunderstanding and 0 = lower than expected and 1 = OK?

Yes 1=Ok.

Is  the JESD framer and deframer status fine?

Is the VDDA_RXSYNTH voltage rail fine ? Are all the power supply voltages as expected or you are seeing any droop in the analog voltage rails.

Can you check the PLL Lock status using MYKONOS_checkPllsLockStatus() API.

To be precise, the problem occurs during synchronization of the JESD link and it seems to be random.

• We have carried out tests and obtained results in cases where it works and doesn't work :

• We don't yet have any results for the VDDA_RXSYNTH voltage rail or power supply voltages between a working and a non-functioning case.
  
  
• MYKONOS_checkPllsLockStatus returns MYKONOS_ERR_OK in both cases.

canardintrigue23 said:

We have carried out tests and obtained results in cases where it works and doesn't work :

The framer and deframer status should be 0x3E and 0x28 respectively. This means that the deframer status is not correct in the working case as well.

As the 6th bit is asserted , it means that the IRQ interrupt has occurred  from the Deframer status.

To check on the IRQ error in detail , can you readback the GP interrupt status using  MYKONOS_readGpInterruptStatus() API. 

Is there any JESD link parameter conflicts between FPGA and Mykonos? Can you check if there is any mismatch between them using MYKONOS_jesd204bIlasCheck() API.

After further testing, we noticed two distinct cases of non-functioning. Here are our results:

It seems that in any case the gpInterruptStatus gives information on calibration PLL unlock and JESD204b deframer interrupt occured.
On the other hand, jesd204bIlasCheck informs us of problems with CS and N parameters in all 3 cases.
Perhaps the root of the problem is a configuration conflict?

We can't make the link between these results and the random nature of our problem (~5% occurrence on average).

canardintrigue23 said:

On the other hand, jesd204bIlasCheck informs us of problems with CS and N parameters in all 3 cases.

There should not be any mismatch with the JESD204B parameters on both FPGA and Transceiver. This could be the reason for this issue.

Can you please ensure there is no mismatch in the parameters and then check if there is any issue with the JESD status .

Sorry for the late reply, we've made some progress on the subject:
We've managed to solve the mismatch problem on the transceiver side. We now have the values 0x3E and 0x28 for framer and deframer respectively. In fact, jesd204bIlasStatus returns the value 0. We had a conflict over the values of CS and N.

Here are our new observations:
We're still experiencing the problem and have noticed some new differences, which are shown in the following table.

Furthermore, in a non-functional case, the value of jesd204bIlasStatus is always 0xC7E0. Further investigation revealed that this value is due to the absence of data in the fields retrieved at address MYKONOS_SUBADDR_DEFRAMER_LANE0_ILAS_RECVD. In fact, all the fields are set to 0, so there's bound to be a conflict with the fields read at address MYKONOS_SUBADDR_DEFRAMER_LANE0_ILAS_CFG containing our parameters.

Is there a link between our different observations?

canardintrigue23 said:

We've managed to solve the mismatch problem on the transceiver side. We now have the values 0x3E and 0x28 for framer and deframer respectively. In fact, jesd204bIlasStatus returns the value 0. We had a conflict over the values of CS and N.

Hope the JESD204B link between the AD9375 and FPGA solved now, as you are able to readback the status fine.

canardintrigue23 said:

We're still experiencing the problem and have noticed some new differences, which are shown in the following table.

I do not exactly understand the new observations stated ,are these parameters part of the SOC ?

canardintrigue23 said:

Furthermore, in a non-functional case, the value of jesd204bIlasStatus is always 0xC7E0.

Is this in a different board? When you say non- functional at what situation exactly do you see see the ILAS status not being zero?

There should not be any mismatch with the JESD204B parameters on both and Transceiver.

Have you tested the PRBS to check on the  signal integrity of the chip on both sides?