Post Go back to editing

ADRV9029 DPD Model Compiling Issue

Category: Software

Hi, we have encountered an unclear situation with regards how DPD model is written to the Transceiver IC.

On API ver 6.3.0.5, in the file, adi_adrv9025_dfe_types.h

it is defined that the per feature size is 12 bytes

#define ADI_ADRV9025_NUM_BYTES_PER_FEATURE 12u

If I am not mistaken, this assumes that the dpd feature LUT (enum) element has an allocation of 1 byte.

However, the compiler that we use Xilinx Vitis (MicroBlaze) compiles enum with 4 bytes.

I examined the ADRV9025 library a little bit; so far, I found out that the API just takes the start address of the model meta data and adjusts the offset of each feature accordingly.

Is my understanding correct that even if Vitis compiles enum with 4 bytes, if we load a DPD feature into memory in 12byte format, the API will parse each feature without any problem?

Thank you in advance.

  • Is your question , if the enum /define size will affect the software ? . This is not the case as we don't take how much space does the enum/define occupies in memory, but we take the value of this enum or #define to do our logic.

     So if my understanding of the question is correct there is no problem.

    What is the issue that you are facing ? 

  • Hi Vinod
    the first time we checked the data written on memory, Vitis parsed the contents differently so we were reading weird values for each feature contents.
    for example,
    in the picture below, for feature[0]
    we were expecting

    i =0, j=0, k=0, lut=0, coeffReal = 0, coeffImag = 0

    but what showed up was

    i =0, j=0, k=0, lut=0, coeffReal = 0, coeffImag = 9.1...E-41 (0x00010000)

    this was because Vitis treated enum as 4byte-wide data, effectively offsetting the addresses of all other data that comes after.

    We were concerned that if the data written into the transceiver is parsed the same way, it might break the transceiver or the PA when an incorrectly pre-distorted signal is input.

  • The API should take care of this. 

    Can you read back the model using, adi_adrv9025_DpdModelConfigGet API ?

  • (sorry, i pressed the wrong button)

    Okay, I will check the read back model.

    It should return the same model if DPD Tracking is not enabled after calling adi_adrv9025_DpdModelConfigSet(), right?

  • Hi! i would like to reopen this issue(should I open a new case?), because we are hitting an error with

    /private/src/adrv9025_dfe.c: adrv9025_DpdModelConfigSetRangeCheck()

    because Vitis Compiles Enum with 4 bytes, it seems like the LUT data is being parsed differently than expected, therefor causing the dpdModelConfig->dpdFeatures[featureIndex].lut check to fail.

    In our debug environment, we tried the following fix:

    we added the following line in adi_adrv9025_user.h:

    #define adi_adrv9025_DpdLut attribute((__packed__)) adi_adrv9025_DpdLut

    this is to force Vitis to compile enum adi_adrv9025_DpdLut_e with the minimum byte (for this case, 1 byte) needed to represent the enum.
    However, we understand that modifying the API isn't supported.

    What action should we take to fix the problem?

  •   Mik-san provided more detailed information via offline. This issue will be continued via email. Please close this ticket to avoid confusion.