I'm trying to understand the LCU's software override section using the sync[x] input. I configured the following fields for Logic cell "0":
-SWVALUE=1
-LC0_SCTRL[SW_SYNC_SEL]=0
-LC0_SCTRL[SW_MODE]=1
-SWEN[0]=1
-LC0_LUTCTRL0[0] = 0b1010101010101010,(since I'm controlling INPUT 0 and OUTPUT 0.)
Using TRGMUX, I applied a rising edge to the sync[x] input and immediately saw the switching at SWOUT[0]. However, following the schematic in the manual (Software override section), with two flip-flops chained together, I expected the output to update on the second edge.
Why does the diagram show two chained flip-flops both with the same CLK source, but their behavior is different?
Although the diagram shows two flip‑flops connected in series and driven by the same clock, they are not intended to introduce a two‑edge delay. Both flip‑flops are synchronous and update on the same rising edge of the clock.
In this Software override path, the value to be forced (SWVALUE[0] - MUX) is already registered before the sync[x] event occurs. The purpose of the two chained flip‑flops is to internally synchronize the sync[x] control signal and to reduce metastability, not to require two separate trigger events.
When a rising edge is applied to sync[x], that edge is synchronized through the flip‑flop chain and then to the SWOUT[0]. As a result, the output changes after the first trigger event. So, even though two flip‑flops are shown, they serve as a synchronizer, not as a mechanism to delay the output until a second sync[x] edge.
BR, VaneB
Hi,
thank you for the clarification.
That makes sense — the two flip-flops are used purely as a synchronizer for the sync[x] control signal, not as a pipeline introducing a two-event latency.
My confusion came from interpreting the diagram as a sequential delay element, while in practice the SWVALUE is already registered and the synchronized sync[x] edge effectively updates SWOUT on the first trigger.
Thanks for confirming the intended behavior.