[spi_device] Check whether clock inverter can be removed

[msfschaffner]

As detailed in @tjaychen's slide deck here, inverters on the clock network can cause significant skew, which in turn can result in very long build times or even infeasible configurations. Ideally, we would want to use negedge flops instead of inverting the clock explicitly.

@eunchan can you check whether that would be feasible in case of spi_dev?

CC @tjaychen @a-will

[tjaychen]

i'm not sure this is worth doing now, unless we find major issues related to this.

[a-will]

Just to clarify a bit, behavioral logic on clock signals can be a source of greater skew, uncertainty, and routing congestion in FPGAs (due to going in and out of the fabric, instead of using the dedicated resources). At these low speeds and by itself, that one inverter is probably not a major problem. If we wanted to go at full speed on the FPGA, then it might be an obstacle.

The biggest source of skew was actually the use of a global clock buffer after the inverter. This created an inherent imbalance of multiple nanoseconds between clk_spi_out and clk_spi_in, leading to hold time problems.

[tjaychen]

that sounds good. Thanks for clarifying Alex.

@weicaiyang
I would say if we do want to make a change like this, it would be nice to do it after DV is stable.
That way if we do make a change, we can be reasonably certain we did not break anything.

[andreaskurth]

Triaged for spi_device. Assigning to M2.5 with Priority:P4 Priority: propose to move to backlog because I think this is worth keeping in mind when analyzing synthesis/implementation results for tapeout, but unless we see a need there, we should not fix this for M2.5. If we see there's no need, we can defer to Type:Icebox Changes deferred to future milestones / Type:FutureRelease Not relevant to currently planned releases/milestones .

[hcallahan-lowrisc]

estimate 8
remaining 2023-03-19 8