cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
2,181 Views
Registered: ‎12-03-2018

Zynq RFSOC Multi Tile Sync Failure - Error Code 128

We are working with a Zynq RFSOC Board designed by Xilinx's Partner Hitech Global (ZRF16), but are having issues performing the Multi Tile Sync Operation.  

We have followed the configuration procedures in PG-269 and configured the onboard clocking network as outlined below.  

DAC Input Clock: 3.93216 GHz (External PLL LMX2594 Device), Internal PLL disabled.  
DAC SysRef: 7.68MHz (per guidelines in PG-269)
PL DAC Axis Clk: 245.76 MHz - Matching the required PL clock
PL DAC Sysref:  7.68MHz (per guidelines in PG-269)
 
image.png
 
The boards clocking architecture is as follows:
 
clk_arch.png
 
However, running the API MTS function: "XRFdc_MultiConverter_Sync" is returning an error code of 128, which is linked to the error: "XRFDC_MTS_DTC_INVALID".  
 
This error is indicating to us that the Analog Sysref is not being correctly captured.  
 
We have gone through and verified by probing that the sysref signal is being output as expected from the Clock Chip (LMK04832).  
 
Additionally, when provided Waveform Data, the DAC channels output at the correct frequency, leading us to believe all the clocks are being provided.  However, the DAC data when put into a timescope shows that Quads 1/2 are aligned and stable, however quads 3/4 appear to be drifting and are not stable in reference to quads 1/2.  
 
Any help in debugging this issue would be greatly appreciated.  
 
Additional Info:

We have also tried using the onboard PLL and providing a 245.76MHz reference with the same error and unsuccessful MTS.  
 
Please let us know if there is any additional information required to assist us in our debug.  
0 Kudos
17 Replies
klumsde
Moderator
Moderator
2,146 Views
Registered: ‎04-18-2011

can you set the log level of the metal log to DEBUG in you metal log handler. 

Can you show us what the log is outputting during the DTC scan. 

The DAC clock must be going in because the tile is started as you say. 

Can you try to add just the tiles that look stable here to the synchronization group and see if MTS synch's these two tiles for you?

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
2,117 Views
Registered: ‎12-03-2018

We are operating using Bare Metal, How do I access the metal-log?  I have called the functions:

struct metal_init_params init_param = METAL_INIT_DEFAULTS;

if (metal_init(&init_param)) {
printf("ERROR: Failed to run metal initialization\n");
return XRFDC_FAILURE;
}
printf("metal_init\n\r");
metal_set_log_level(METAL_LOG_DEBUG);
printf("metal_set_log_level\n\r");

But I am unable to figure out how to access the Metal Log or get it to printout using xil_printf.  

 

Thanks

 

0 Kudos
2,107 Views
Registered: ‎12-03-2018

I have resolved the metal-log handler issue, was missing the "metal_set_log_handler(my_metal_default_log_handler);" function.  Below is the log of attempting to sync all 4 converter quads using the MTS procedure.  

Quads 1/2/3/4: DAC_Sync_Config.Tiles = 0xF;

=== Run DAC Sync ===
metal: info: DTC Scan T1
metal: debug: Target 64, DTC Code 27, Diff 37, Min 37
metal: debug: RefTile (0): DTC Code Target 64, Picked 27
metal: info: DAC0: 303302330330320200200000000*000000000100101303303302310330130120#003003022020000000001003103002012032033033003103303303203002002
metal: debug: Tile (1): Max/Min 27/27, Range 0
metal: debug: Tile (1): Code -1, Range Prev 0, New 128
metal: info: DAC1: 110130030032002302302302202#0000000010010030030130330330230033033033032030020020000001003003033033033023103303301301003003002000
metal: error: Unable to capture analog SysRef safely on DAC tile 1
metal: debug: Tile (2): Max/Min 27/27, Range 0
metal: debug: Tile (2): Code -1, Range Prev 0, New 128
metal: info: DAC2: 003003303303313313033333332#1230000100320330330230031033033033030111133133033220212033033033023003303303301300000123333333332333
metal: error: Unable to capture analog SysRef safely on DAC tile 2
metal: debug: Tile (3): Max/Min 27/27, Range 0
metal: debug: Tile (3): Code -1, Range Prev 0, New 128
metal: info: DAC3: 230031033133333332333333333#3312001003003303302300310330330331321113133331330220020320330330330030033033033033010111033033232203
metal: error: Unable to capture analog SysRef safely on DAC tile 3
metal: debug: Marker Read Tile 0, FIFO 0 - 00006000 = 0000: count=41, loc=0, done=1
metal: info: DAC0: Marker: - 41, 0
metal: debug: Marker Read Tile 1, FIFO 0 - 0000A000 = 0000: count=41, loc=0, done=1
metal: info: DAC1: Marker: - 41, 0
metal: debug: Marker Read Tile 2, FIFO 0 - 0000E000 = 0000: count=41, loc=0, done=1
metal: info: DAC2: Marker: - 41, 0
metal: debug: Marker Read Tile 3, FIFO 0 - 00012000 = 0000: count=41, loc=0, done=1
metal: info: DAC3: Marker: - 41, 0
metal: debug: Count_W 16, loc_W 8
metal: info: SysRef period in terms of DAC T1s = 1024
metal: info: DAC target latency = 656
metal: debug: Tile 0, latency 656, max 656
metal: debug: Tile 1, latency 656, max 656
metal: debug: Tile 2, latency 656, max 656
metal: debug: Tile 3, latency 656, max 656
metal: debug: Target 656, Tile 0, delta 0, i/f_part 0/0, offset 0
metal: debug: Target 656, Tile 1, delta 0, i/f_part 0/0, offset 0
metal: debug: Target 656, Tile 2, delta 0, i/f_part 0/0, offset 0
metal: debug: Target 656, Tile 3, delta 0, i/f_part 0/0, offset 0
ERROR : DAC Multi-Tile-Sync did not complete successfully. Error code is 128
MTS failed

Additionally, I have attempted syncing quads 1/2 and quads 3/4.  Results below.  

Quads 1/2: DAC_Sync_Config.Tiles = 0x3;

 

=== Run DAC Sync ===
metal: info: DTC Scan T1
metal: debug: Target 64, DTC Code 114, Diff 50, Min 50
metal: debug: RefTile (0): DTC Code Target 64, Picked 114
metal: info: DAC0: 0300200200000000010130330330230013013013003000030230230220200000#0101103103103100110030030030000302300200000000000*0000000000011
metal: debug: Tile (1): Max/Min 114/114, Range 0
metal: debug: Tile (1): Code 12, New-Range: 102, Min-Range: 102
metal: debug: Tile (1): Code 64, New-Range: 50, Min-Range: 50
metal: debug: Tile (1): Code 114, New-Range: 0, Min-Range: 0
metal: debug: Tile (1): Code 114, Range Prev 0, New 0
metal: info: DAC1: 000000000000000000000000001003012032032032022102302302202000000000000000100300200203203203302210330330320200200000*0000001003002
metal: debug: Marker Read Tile 0, FIFO 0 - 00006000 = 0000: count=41, loc=0, done=1
metal: info: DAC0: Marker: - 41, 0
metal: debug: Marker Read Tile 1, FIFO 0 - 0000A000 = 0000: count=41, loc=0, done=1
metal: info: DAC1: Marker: - 41, 0
metal: debug: Count_W 16, loc_W 8
metal: info: SysRef period in terms of DAC T1s = 1024
metal: info: DAC target latency = 656
metal: debug: Tile 0, latency 656, max 656
metal: debug: Tile 1, latency 656, max 656
metal: debug: Target 656, Tile 0, delta 0, i/f_part 0/0, offset 0
metal: debug: Target 656, Tile 1, delta 0, i/f_part 0/0, offset 0
INFO : DAC Multi-Tile-Sync completed successfully

=== Multi-Tile Sync Report ===
DAC0: Latency(T1) =656, Adjusted DelayOffset(T8) = 0
DAC1: Latency(T1) =656, Adjusted DelayOffset(T8) = 0
RFdc MTS Success

 

 

This result seems to be successful and consistent run after run.  

 

Quads 3/4: DAC_Sync_Config.Tiles = 0xC;

=== Run DAC Sync ===
metal: info: DTC Scan T1
metal: debug: Tile (2): Max/Min 0/128, Range -128
metal: debug: Tile (2): Code -1, Range Prev -128, New 128
metal: info: DAC2: #3303303313313231131333333312200001003203303303300300330330330331323313333333233021000100300320320330030033033033133332333333323
metal: error: Unable to capture analog SysRef safely on DAC tile 2
metal: debug: Tile (3): Max/Min 0/128, Range -128
metal: debug: Tile (3): Code -1, Range Prev -128, New 128
metal: info: DAC3: #0330330130000010330332332222020330330330330230031033033033032111113133133033220212033033033033003003303303303313231133333313302
metal: error: Unable to capture analog SysRef safely on DAC tile 3
metal: debug: Marker Read Tile 2, FIFO 0 - 0000E000 = 0000: count=41, loc=0, done=1
metal: info: DAC2: Marker: - 41, 0
metal: debug: Marker Read Tile 3, FIFO 0 - 00012000 = 0000: count=41, loc=0, done=1
metal: info: DAC3: Marker: - 41, 0
metal: debug: Count_W 16, loc_W 8
metal: info: SysRef period in terms of DAC T1s = 1024
metal: info: DAC target latency = 656
metal: debug: Tile 2, latency 656, max 656
metal: debug: Tile 3, latency 656, max 656
metal: debug: Target 656, Tile 2, delta 0, i/f_part 0/0, offset 0
metal: debug: Target 656, Tile 3, delta 0, i/f_part 0/0, offset 0
ERROR : DAC Multi-Tile-Sync did not complete successfully. Error code is 128
MTS failed

This consistenty fails the MTS procedure.  

 

 

 

0 Kudos
klumsde
Moderator
Moderator
2,098 Views
Registered: ‎04-18-2011

You can see from the the log that when it's trying to safe capture the sysref in the tile that the quality of the clock is not very good. 

The 1/2/3 you see are transitions on the clock, but since thy are so prevalent it shows that the clock is jittery. it needs on a longer string of consecutive 0s bounded by transitions to place the sysref in.

We use a similar RF pll architecture on the zcu111 board. So I'm wondering how these PLLs are set up

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
klumsde
Moderator
Moderator
2,035 Views
Registered: ‎04-18-2011

Hi alex@epirussystems.com 

For your reference, Here is the metal log for a "Good" run on my ZCU111

RFdc MTS Example Test

metal: debug:     registered generic bus

 

initializing reset & powerdown...ADC Tile 0 powered downADC Tile 1 powered downDAC Tiles powered downADC Tile 0 PowerUp Status: 0

ADC Tile 0 State: 1

ADC Tile 1 PowerUp Status: 0

ADC Tile 1 State: 1

DAC Tile 0 PowerUp Status: 0

DAC Tile 0 State: 1

DAC Tile 0 powered upADC Tile 0 powered upADC Tile 1 powered upADC Tile 0 PowerUp Status: 1

ADC Tile 0 State: 15

ADC Tile 1 PowerUp Status: 1

ADC Tile 1 State: 15

DAC Tile 0 PowerUp Status: 1

DAC Tile 0 State: 15

=== RFdc Initialized - Running Multi-tile Sync ===

 

=== Run DAC Sync ===

metal: info:      DTC Scan PLL

metal: debug:     Target 64, DTC Code 11, Diff 53, Min 53

metal: debug:     Target 64, DTC Code 27, Diff 37, Min 37

metal: debug:     Target 64, DTC Code 43, Diff 21, Min 21

metal: debug:     Target 64, DTC Code 59, Diff 5, Min 5

metal: debug:     Target 64, DTC Code 75, Diff 11, Min 5

metal: debug:     Target 64, DTC Code 91, Diff 27, Min 5

metal: debug:     Target 64, DTC Code 107, Diff 43, Min 5

metal: debug:     Target 64, DTC Code 123, Diff 59, Min 5

metal: debug:     RefTile (0): DTC Code Target 64, Picked 59

metal: info:      DAC0: 01112220000000000113222000000000011322200000000001132220000*0000#111222000000000011122200000000001132220000000000111222000000000

metal: info:      DTC Scan T1

metal: debug:     Target 64, DTC Code 5, Diff 59, Min 59

metal: debug:     Target 64, DTC Code 39, Diff 25, Min 25

metal: debug:     Target 64, DTC Code 87, Diff 23, Min 23

metal: debug:     Target 64, DTC Code 121, Diff 57, Min 23

metal: debug:     RefTile (0): DTC Code Target 64, Picked 87

metal: info:      DAC0: 0000000000001111222220000000000000000000000000000000000000011113#2222000000000000000000*0000000000000000000111132222000000000000

metal: debug:     Marker Read Tile 0, FIFO 0 - 00006000 = 0000: count=45, loc=0,done=1

metal: info:      DAC0: Marker: - 45, 0

metal: debug:     Count_W 8, loc_W 2

metal: info:      SysRef period in terms of DAC T1s = 512

metal: info:      DAC target latency = 360

metal: debug:     Tile 0, latency 360, max 360

metal: debug:     Target 360, Tile 0, delta 0, i/f_part 0/0, offset 0

INFO : DAC Multi-Tile-Sync completed successfully

 

=== Run ADC Sync ===

metal: info:      DTC Scan PLL

metal: debug:     Target 64, DTC Code 14, Diff 50, Min 50

metal: debug:     Target 64, DTC Code 30, Diff 34, Min 34

metal: debug:     Target 64, DTC Code 47, Diff 17, Min 17

metal: debug:     Target 64, DTC Code 62, Diff 2, Min 2

metal: debug:     Target 64, DTC Code 78, Diff 14, Min 2

metal: debug:     Target 64, DTC Code 94, Diff 30, Min 2

metal: debug:     Target 64, DTC Code 110, Diff 46, Min 2

metal: debug:     Target 64, DTC Code 124, Diff 60, Min 2

metal: debug:     RefTile (0): DTC Code Target 64, Picked 62

metal: info:      ADC0: 00001112220000000000111222000000000011122220000000000113220000*0#000111322000000000011132200000000001132220000000000111222000000

metal: debug:     Tile (1): Max/Min 62/62, Range 0

metal: debug:     Tile (1): Code 3, New-Range: 59, Min-Range: 59

metal: debug:     Tile (1): Code 17, New-Range: 45, Min-Range: 45

metal: debug:     Tile (1): Code 34, New-Range: 28, Min-Range: 28

metal: debug:     Tile (1): Code 49, New-Range: 13, Min-Range: 13

metal: debug:     Tile (1): Code 65, New-Range: 3, Min-Range: 3

metal: debug:     Tile (1): Code 81, New-Range: 19, Min-Range: 3

metal: debug:     Tile (1): Code 97, New-Range: 35, Min-Range: 3

metal: debug:     Tile (1): Code 114, New-Range: 52, Min-Range: 3

metal: debug:     Tile (1): Code 65, Range Prev 0, New 3

metal: info:      ADC1: 00000000111220000000000111322200000000011132200000000001112220#00*00000111322000000000011132200000000001113220000000000011322000

metal: info:      DTC Scan T1

metal: debug:     Target 64, DTC Code 7, Diff 57, Min 57

metal: debug:     Target 64, DTC Code 44, Diff 20, Min 20

metal: debug:     Target 64, DTC Code 93, Diff 29, Min 20

metal: debug:     RefTile (0): DTC Code Target 64, Picked 44

metal: info:      ADC0: 00000000000000011113222220000000000000000000*0000000000000000000#111322222200000000000000000000000000000000000000111122222000000

metal: debug:     Tile (1): Max/Min 44/44, Range 0

metal: debug:     Tile (1): Code 9, New-Range: 35, Min-Range: 35

metal: debug:     Tile (1): Code 47, New-Range: 3, Min-Range: 3

metal: debug:     Tile (1): Code 96, New-Range: 52, Min-Range: 3

metal: debug:     Tile (1): Code 47, Range Prev 0, New 3

metal: info:      ADC1: 00000000000000000001111322222000000000000000#00*00000000000000000001111322222000000000000000000000000000000000000000111132222200

metal: debug:     Marker Read Tile 0, FIFO 0 - 00014000 = 100007: count=7, loc=0,done=1

metal: info:      ADC0: Marker: - 7, 0

metal: debug:     Marker Read Tile 1, FIFO 0 - 00018000 = 100007: count=7, loc=0,done=1

metal: info:      ADC1: Marker: - 7, 0

metal: debug:     Count_W 16, loc_W 2

metal: info:      SysRef period in terms of ADC T1s = 512

metal: info:      ADC target latency = 112

metal: debug:     Tile 0, latency 112, max 112

metal: debug:     Tile 1, latency 112, max 112

metal: debug:     Target 112, Tile 0, delta 0, i/f_part 0/0, offset 0

metal: debug:     Target 112, Tile 1, delta 0, i/f_part 0/0, offset 0

INFO : ADC Multi-Tile-Sync completed successfully

 

 

=== Multi-Tile Sync Report ===

DAC0: Latency(T1) =360, Adjusted DelayOffset(T2) =  0

ADC0: Latency(T1) =112, Adjusted DelayOffset(T2) =  0

ADC1: Latency(T1) =112, Adjusted DelayOffset(T2) =  0

Successfully ran MTS Example

 

You can see the DTC scan has a much more stable clock. 

Can you maybe share how you set up the LMK/LMX PLLs

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
2,016 Views
Registered: ‎12-03-2018

Thanks for providing a reference log to see of a working MTS.  

For the LMK device, we are opperating in single loop mode with a externally provided 122.88 MHz signal source.  The Lock indicator is active.  The reason for using single loop is due to issues outlined in this TI forum post.  http://e2e.ti.com/support/clock-and-timing/f/48/t/833011

lmk_04832_cfg_2.png

 

lmk_04832_cfg_1.png

Our clock configuration of the LMX device is as below from TI's TICS GUI is:

lmx_2594_cfg.pngThe Lock indicator is active.  

 

Do you have any advice for settings that may provide better results?  

0 Kudos
1,969 Views
Registered: ‎12-03-2018

I have run some futher experiments and used our second HTG ZRF16 Board using the same lab setup.  I have consistently achieved a MTS success on this board.  Below is the DTC Log, it appears the jitter issue is not present on this board.  

 

=== RFdc Initialized - Running Multi-tile Sync ===

=== Run DAC Sync ===
metal: info: DTC Scan T1
metal: debug: Target 64, DTC Code 31, Diff 33, Min 33
metal: debug: Target 64, DTC Code 81, Diff 17, Min 17
metal: debug: RefTile (0): DTC Code Target 64, Picked 81
metal: info: DAC0: 3313313233033233203302202000000000000001101303311330330333303303#2233032022000000*0000001101301311331330333323303322320320220000
metal: debug: Tile (1): Max/Min 81/81, Range 0
metal: debug: Tile (1): Code 33, New-Range: 48, Min-Range: 48
metal: debug: Tile (1): Code 82, New-Range: 1, Min-Range: 1
metal: debug: Tile (1): Code 82, Range Prev 0, New 1
metal: info: DAC1: 333333333132330332232022022000000000000011013033313303313233233233303302200200000#*000000011033033033333313313333033033222202200
metal: debug: Tile (2): Max/Min 82/81, Range 1
metal: debug: Tile (2): Code 26, New-Range: 56, Min-Range: 56
metal: debug: Tile (2): Code 76, New-Range: 6, Min-Range: 6
metal: debug: Tile (2): Code 119, New-Range: 38, Min-Range: 6
metal: debug: Tile (2): Code 76, Range Prev 1, New 6
metal: info: DAC2: 3323323200200000000000000000000000000000001013313313233232022000000000000000*0000#0000000000101111333333323202200000000000000000
metal: debug: Tile (3): Max/Min 82/76, Range 6
metal: debug: Tile (3): Code 24, New-Range: 58, Min-Range: 58
metal: debug: Tile (3): Code 75, New-Range: 7, Min-Range: 7
metal: debug: Tile (3): Code 118, New-Range: 42, Min-Range: 7
metal: debug: Tile (3): Code 75, Range Prev 6, New 7
metal: info: DAC3: 333022020000000000000000000000000000000000110331323322220220000000000000000*00000#0000000000110331333323322220000000000000000000
metal: debug: Marker Read Tile 0, FIFO 0 - 00006000 = 0000: count=41, loc=0, done=1
metal: info: DAC0: Marker: - 41, 0
metal: debug: Marker Read Tile 1, FIFO 0 - 0000A000 = 0000: count=41, loc=0, done=1
metal: info: DAC1: Marker: - 41, 0
metal: debug: Marker Read Tile 2, FIFO 0 - 0000E000 = 0000: count=41, loc=0, done=1
metal: info: DAC2: Marker: - 41, 0
metal: debug: Marker Read Tile 3, FIFO 0 - 00012000 = 0000: count=41, loc=0, done=1
metal: info: DAC3: Marker: - 41, 0
metal: debug: Count_W 16, loc_W 8
metal: info: SysRef period in terms of DAC T1s = 1024
metal: info: DAC target latency = 656
metal: debug: Tile 0, latency 656, max 656
metal: debug: Tile 1, latency 656, max 656
metal: debug: Tile 2, latency 656, max 656
metal: debug: Tile 3, latency 656, max 656
metal: debug: Target 656, Tile 0, delta 0, i/f_part 0/0, offset 0
metal: debug: Target 656, Tile 1, delta 0, i/f_part 0/0, offset 0
metal: debug: Target 656, Tile 2, delta 0, i/f_part 0/0, offset 0
metal: debug: Target 656, Tile 3, delta 0, i/f_part 0/0, offset 0
INFO : DAC Multi-Tile-Sync completed successfully

=== Multi-Tile Sync Report ===
DAC0: Latency(T1) =656, Adjusted DelayOffset(T8) =  0
DAC1: Latency(T1) =656, Adjusted DelayOffset(T8) =  0
DAC2: Latency(T1) =656, Adjusted DelayOffset(T8) =  0
DAC3: Latency(T1) =656, Adjusted DelayOffset(T8) =  0
RFdc MTS Success

Thank you for your help decoding the error/debug logs.  If you have any additional feedback on our clocking network configuration please let us know, our goal is to eventually synchronize DACs accross multiple boards.  

0 Kudos
klumsde
Moderator
Moderator
1,919 Views
Registered: ‎04-18-2011

Hi alex@epirussystems.com 

It seems odd that the same settings on two boards can give rise to this poor sample clock going into the converter. 

Do these settings come from the board vendor or are you coming up with them yourself?

Is there another setting we could try? I am not familiar with the Eval board you are using. 

Keith 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
1,888 Views
Registered: ‎12-03-2018

Hi Keith,

We came up with these settings based on information in Xilinx PG269 and other forum posts.  There was no support provided by the board vendor for configuring the clocking network to the data converters.  

 

We have access to configure the clocks using the PS IIC bus.  We will be attempting using the internal PLL and a reference clock at 245.76 MHz as the board/traces may have issues supporting the 3.9GHz clock.  

 

If you have any suggestions of other clock configuration settings to try please let us know!

 

Thanks

0 Kudos
1,860 Views
Registered: ‎12-03-2018

Additional update, we have tried the internal PLL but it appears it was a step backwards as MTS procedure did not return successful (Error 128 again).  Continuing to debug the jitter of the clocks.  Any configuration suggestions is appreciated.  

0 Kudos
klumsde
Moderator
Moderator
1,841 Views
Registered: ‎04-18-2011

Hi alex@epirussystems.com

I can't really spend a lot of time on the PLL settings here because I'm not so expert on the optimal settings for the TI PLLs. 

What I can do is check if we have any general recommendations for the RF plls here. 

I'll check internally on how we arrived at our settings for zcu111

Keith

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
1,828 Views
Registered: ‎12-03-2018

Any recommendations on general use of the RF PLLs is appreciated.  We are also working to get help from the TI FAEs on our configuration as well.  

 

Thanks

0 Kudos
klumsde
Moderator
Moderator
1,793 Views
Registered: ‎04-18-2011

One thought:

have you ever tried with the TXCO as a reference to the jitter cleaner here? 

perhaps the issue is with the source you provide?

Can you also re-post the image of LMK output clock configuration page with better resolution.Looks like the LMK provides a 61.44 input to the LMX. 

 

Keith 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
klumsde
Moderator
Moderator
1,785 Views
Registered: ‎04-18-2011

maybe you can share your LMK .tcs file. …

I think you need to set the output of the LMK (61.44MHz) to the LMX2594s to LVDS if possible, it looks like it is LVPECL now, and If you want to mimic what we did on the ZCU111 I would set the output of the VCO at 3072MHz, I would also try to tweak the LMX2594s to accept a 122.88MHz refclk as well.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
1,775 Views
Registered: ‎12-03-2018

Hi Keith,

I will try these suggetions now.  Our external reference source is a Keysight MXG NS181B Signal Generator, but I will see about tracking down an alternative signal source to inject.  

Additionally, we have attempted to use the OSCin singled ended input clock reference onboard, however, the vendor did not put an AC cap to ground on the N side of the differential receiver pair so the interface is non-functional.  

Attached is our TICS file (Before trying these suggestions).  Note it would not allow me to upload as a .tcs so I altered the extension to .txt.  

I will update you with the results of the configuration experiments.  Thanks!

1,725 Views
Registered: ‎12-03-2018

Hi Keith,

I have tried the suggestions of changing the IO standard to LVDS as well as the input to the LMX2594 to 122.88 MHz.  Below is the DTC Scan Report

RFdc MTS Begin
=== RFdc Initialized - Running Multi-tile Sync ===

=== Run DAC Sync ===
metal: info: DTC Scan T1
metal: debug: Target 64, DTC Code 35, Diff 29, Min 29
metal: debug: Target 64, DTC Code 86, Diff 22, Min 22
metal: debug: Target 64, DTC Code 121, Diff 57, Min 22
metal: debug: RefTile (0): DTC Code Target 64, Picked 86
metal: info: DAC0: 0000000001113323222000000000000000000000000000000000100303302330#20200200000000000000                  0*00000000000000010131321222020000000000000
metal: debug: Tile (1): Max/Min 86/86, Range 0
metal: debug: Tile (1): Code 38, New-Range: 48, Min-Range: 48
metal: debug: Tile (1): Code 85, New-Range: 1, Min-Range: 1
metal: debug: Tile (1): Code 85, Range Prev 0, New 1
metal: info: DAC1: 0000000001013033323202000000000000000000000000000000000010110333222020000000000000000                  *#00000000000000011030331323022022000000000
metal: debug: Tile (2): Max/Min 86/85, Range 1
metal: debug: Tile (2): Code 30, New-Range: 56, Min-Range: 56
metal: debug: Tile (2): Code 77, New-Range: 9, Min-Range: 9
metal: debug: Tile (2): Code 119, New-Range: 34, Min-Range: 9
metal: debug: Tile (2): Code 77, Range Prev 1, New 9
metal: info: DAC2: 00111213232220000000000000000000000000000000000001112132322200200000000000000*0000000                  0#00000011031121321223022020000000000000000
metal: debug: Tile (3): Max/Min 86/77, Range 9
metal: debug: Tile (3): Code 29, New-Range: 57, Min-Range: 57
metal: debug: Tile (3): Code 76, New-Range: 10, Min-Range: 10
metal: debug: Tile (3): Code 117, New-Range: 40, Min-Range: 10
metal: debug: Tile (3): Code 76, Range Prev 9, New 10
metal: info: DAC3: 1303312330320200000000000000000000000000000001013021321223022000000000000000*00000000                  0#00000101113132122222200000000000000000000
metal: debug: Marker Read Tile 0, FIFO 0 - 00006000 = 0000: count=41, loc=0, done=1
metal: info: DAC0: Marker: - 41, 0
metal: debug: Marker Read Tile 1, FIFO 0 - 0000A000 = 0000: count=41, loc=0, done=1
metal: info: DAC1: Marker: - 41, 0
metal: debug: Marker Read Tile 2, FIFO 0 - 0000E000 = 0000: count=41, loc=0, done=1
metal: info: DAC2: Marker: - 41, 0
metal: debug: Marker Read Tile 3, FIFO 0 - 00012000 = 0000: count=41, loc=0, done=1
metal: info: DAC3: Marker: - 41, 0
metal: debug: Count_W 16, loc_W 8
metal: info: SysRef period in terms of DAC T1s = 1024
metal: info: DAC target latency = 656
metal: debug: Tile 0, latency 656, max 656
metal: debug: Tile 1, latency 656, max 656
metal: debug: Tile 2, latency 656, max 656
metal: debug: Tile 3, latency 656, max 656
metal: debug: Target 656, Tile 0, delta 0, i/f_part 0/0, offset 0
metal: debug: Target 656, Tile 1, delta 0, i/f_part 0/0, offset 0
metal: debug: Target 656, Tile 2, delta 0, i/f_part 0/0, offset 0
metal: debug: Target 656, Tile 3, delta 0, i/f_part 0/0, offset 0
INFO : DAC Multi-Tile-Sync completed successfully

=== Multi-Tile Sync Report ===
DAC0: Latency(T1) =656, Adjusted DelayOffset(T8) =  0
DAC1: Latency(T1) =656, Adjusted DelayOffset(T8) =  0
DAC2: Latency(T1) =656, Adjusted DelayOffset(T8) =  0
DAC3: Latency(T1) =656, Adjusted DelayOffset(T8) =  0
RFdc MTS Success

I have observed that there is less Jitter on our DAC output on channels driven by tiles 1/2, but 3/4 is still unstable.  Additionally, it appears we still dont have as clean transitions as in your example DTC report as there are still some 0's between the 1113333222 area of the edge.  

I was unable to set the LMK VCO to 3072MHz based on our current FPGA firmware build as the PL DAC clock is expected to be 245.76 MHZ, which would be a divider of 12.5 from the VCO.  I would need to divide by 25 and use an internal MMCM to create that clock for the AXIS ports, as well as registering the sysref signal.  

To use an internal MMCM, I need to use the non-optimal MMCM placement constraint as the PL-DAC clock comes in on Bank 84 which is an HD bank.  I am in the process of putting this build together to run the experiment, but am curious to know if non-optimal PL side clocking is causing some of our pain.   

Additionally, the PL sysref is routed to Bank 66 which is an HP bank.  Swapping these clock outputs on the LMK device would allow for better clock resource placement, but would it impact any of the issues we are seeing with DAC output stability?

Thanks,

Alex

 

0 Kudos
donstp01
Observer
Observer
1,275 Views
Registered: ‎11-22-2011

Regarding the LMK04832 chip itself, is there an application note or reference design that configures that chip?  From a Xilinx perspective that is, where the FPGA is used to configure the LMK04832

Don St. Pierre - Director, Engineering Solutions
info@designlinxhs.com
www.designlinxhs.com
0 Kudos