kasli-soc & zc706: Fix GTX Clock Path during Initialization #280

linuswck · 2023-11-07T16:34:08+08:00

linuswck commented

2023-11-07 16:34:08 +08:00

Description of Changes

This PR fixes two issues that is caused by wrong GTX TX clock path at initialization.

Non-deterministic Phase of System Clock at different resets and startups

For details of the causes and fix for the non-deterministic Phase, please read this artiq repo PR.

Satellite panic at startup due to "System Clock does not switch" (Issue #246)

Tests Done

Kasli-Soc

The test setup for Kasli-Soc is similar to the related PR in the artiq repo. For all DRTIO roles(standalone, master, satellite), the phase of system clock is deterministic relative the outside analog clock source.

To check if Issue #246 is resolved, the additional delay added in commit dc08c382a2 is rolled back. Then, Kasli-Soc Satellite is compiled and booted on SD card. The system starts up normally without the panic message "System Clock does not switch" in multiple restarts.

ZC706

The following variants are compiled and checked if the system can startup correctly.

zc706-nist_clock
zc706-nist_clock_master
zc706-nist_clock_satellite

Artiq Repo: https://github.com/m-labs/artiq/pull/2278

Closes #246

Action required

Update the flake dependency for artiq repo

# Description of Changes This PR fixes two issues that is caused by wrong GTX TX clock path at initialization. 1. Non-deterministic Phase of System Clock at different resets and startups - For details of the causes and fix for the non-deterministic Phase, please read this artiq repo [PR](https://github.com/m-labs/artiq/pull/2275). 2. Satellite panic at startup due to "System Clock does not switch" (Issue #246) ## Tests Done ### Kasli-Soc The test setup for Kasli-Soc is similar to the related PR in the artiq repo. For all DRTIO roles(standalone, master, satellite), the phase of system clock is deterministic relative the outside analog clock source. To check if Issue #246 is resolved, the additional delay added in commit dc08c382a23329e18f91fc61056d15d5174ac5b6 is rolled back. Then, Kasli-Soc Satellite is compiled and booted on SD card. The system starts up normally without the panic message "System Clock does not switch" in multiple restarts. ### ZC706 The following variants are compiled and checked if the system can startup correctly. 1. zc706-nist_clock 2. zc706-nist_clock_master 3. zc706-nist_clock_satellite ## Related PR Artiq Repo: https://github.com/m-labs/artiq/pull/2278 ## Related Issue Closes #246 ## Action required 1. Update the flake dependency for artiq repo

linuswck added 4 commits 2023-11-07 16:34:09 +08:00

zynq_clocking: expose mmcm_locked for SYSCRG e3a4c13944

- mmcm_locked -> self.mmcm_locked

zynq_clocking: add ext_async_rst to AsyncRstSYNCR d507b6f60f

zynq_clocking: Allow ext signal to set cur_clk csr 4a2d9dc597

- for example, current_clock csr can be connected to tx_init.done

kasli_soc & zc706: Fix GTX Clock Path during INIT 0e3987c887

mwojcik commented

2023-11-07 17:20:00 +08:00

the additional delay added in commit dc08c382a2 is rolled back

Do you think we could roll back the delay for both runtime and satman with these changes? Hard to say if it actually fixes that issue, as it was not affecting all Kasli-SoC boards, have you tried rolling back the delay without introducing the fix?

> the additional delay added in commit dc08c382a2 is rolled back Do you think we could roll back the delay for both runtime and satman with these changes? Hard to say if it actually fixes that issue, as it was not affecting all Kasli-SoC boards, have you tried rolling back the delay without introducing the fix?

linuswck commented

2023-11-07 17:44:41 +08:00

the additional delay added in commit dc08c382a2 is rolled back

Do you think we could roll back the delay for both runtime and satman with these changes? Hard to say if it actually fixes that issue, as it was not affecting all Kasli-SoC boards, have you tried rolling back the delay without introducing the fix?

I think we can roll back the delay.

The root cause of problem is in indeed due to wrong GTX Clock Path is set before Init. Before the fix, the determination of whether the clock is switched is done through the monitoring of the clk sw fsm. Only if the GTX TX initialization has been completed, the clock switch FSM starts. If GTX TX's clock path is not configured correctly in the first place, this can explain why it takes longer time to init or GTX TX fails to init.

Will test rolling back the delay without introducing the fix later.

> > the additional delay added in commit dc08c382a2 is rolled back > > Do you think we could roll back the delay for both runtime and satman with these changes? Hard to say if it actually fixes that issue, as it was not affecting all Kasli-SoC boards, have you tried rolling back the delay without introducing the fix? I think we can roll back the delay. The root cause of problem is in indeed due to wrong GTX Clock Path is set before Init. Before the fix, the determination of whether the clock is switched is done through the monitoring of the clk sw fsm. Only if the GTX TX initialization has been completed, the clock switch FSM starts. If GTX TX's clock path is not configured correctly in the first place, this can explain why it takes longer time to init or GTX TX fails to init. Will test rolling back the delay without introducing the fix later.

sb10q merged commit e1b2c45813 into master

2023-11-07 18:55:09 +08:00

Sign in to join this conversation.

No reviewers