I think you can safely generate asymmetric clock:
If careful done, it could help with ringing too (or make it worse), it depends on breaking (or amplifying) the resonance.
I know many despise overclocking, but this is the way I was able to reliably drive the QSPI Flash at 400 MHz 1/3 133 MHz on RP2040 using CPU. In reality, the pulses tends to widen, edges to be delayed (many times asymmetrically), this way you can compensate. Reality is a little bit different than 'perfect' datasheets, one can generate 'perfect' signals, and 'perfectly' fail, for Nature cannot be fooled.
When generating clock, you have to take in account all the delays and RTT. Even without overclocking, it can be better to have let's say RP2350 at 150 MHz and have more granularity 1/3, 2/3 steps, at 6.6 ns instead of 10 ns, it depends from case to case.
Actually an odd divider can help, you can tune the slopes changing the driving strength.Clock Period 1 Full V 15.38 ns
CLOCK Pulsewidth High (2) Full V 3 ns
CLOCK Pulsewidth Low (2) Full V 3 ns
Output Delay Full V 3.5 7 ns
Pipeline Delay (Latency) Full V 7 Clock Cycles
(2) When MODE pin is tied to AVDD or grounded, the AD9226 SSOP is not affected by clock duty cycle.
If careful done, it could help with ringing too (or make it worse), it depends on breaking (or amplifying) the resonance.
I know many despise overclocking, but this is the way I was able to reliably drive the QSPI Flash at 400 MHz 1/3 133 MHz on RP2040 using CPU. In reality, the pulses tends to widen, edges to be delayed (many times asymmetrically), this way you can compensate. Reality is a little bit different than 'perfect' datasheets, one can generate 'perfect' signals, and 'perfectly' fail, for Nature cannot be fooled.
When generating clock, you have to take in account all the delays and RTT. Even without overclocking, it can be better to have let's say RP2350 at 150 MHz and have more granularity 1/3, 2/3 steps, at 6.6 ns instead of 10 ns, it depends from case to case.
Statistics: Posted by gmx — Sat Nov 30, 2024 4:18 pm