We are testing a set of profiles on the AD9371 + KCU105 no-OS evaluation setup. All of these are generated with no errors using the AD9371 Filter Wizard. Two of these work on the hardware and two of them fail the JESD initialization.
These work:1. full_rate profile - 122.88 MHz Tx, 122.88 MHz Rx2. half_rate profile - 61.44 MHz Tx, 61.44 MHz Rx
But these two very similar profiles fail:3. three_quarter_rate profile - 92.16 MHz Tx, 92.16 MHz Rx4. three_eighths_rate profile - 46.08 MHz Rx, 46.08 MHz Rx
We're using a 122.88 MHz Device clock for all configurations.
Here's the configuration and console output for the full_rate profile that works:
I forgot about this, sorry. Most likely this issue is fixed for know, having hdl_2019_r1 release at the moment. If you somebody have a similar issue, please feel free and open up a new thread.
Can you also show us the AD9528 configuration?
The profiles including myk_ad9528init.c are attached. At the top level of each profile is the output from the AD9371 Filter Wizard along with a screen shot of the configuration. The TES folder has the script output from the Transceiver Evaluation Software. The eval folder has the myk.c and myk_ad9528init.c files used on the eval board, along with the console output.
The Ref clock into the AD9528 on our eval board is 15.36 MHz (our signal generator is limited to 20 MHz). The Device Clock is set to 122.88 MHz. We're using the same myk_ad9528init.c file for both profiles:
/* AD9528 data structure initialization file */
static spiSettings_t clockSpiSettings =
1, //chip select Index
0, //Write bit polarity
1, //16bit instruction word
1, //MSB first
0, //Clock phase
0, //Clock polarity
1 //uint8_t fourWireMode;
ad9528pll1Settings_t clockPll1Settings =
ad9528pll2Settings_t clockPll2Settings =
ad9528outputSettings_t clockOutputSettings =
ad9528sysrefSettings_t clockSysrefSettings =
ad9528Device_t clockAD9528_ =
Have you guys had a chance to look at this? We would like to get these profiles working as configuration options for our customer.
Sorry for the delay. We'll look into this.
Have you been able to reproduce this problem?
We're still interested in solving this problem.
We're on the hdl_2018_r1 release. Were these problems addressed in hdl_2018_r2?
I already made some debug on hdl_2018_r2 and master, and I could replicate a similar behavior. Will come back to you as soon as I have a fix or solution.