-
Notifications
You must be signed in to change notification settings - Fork 189
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Off-by-one in glasgow.gateware.clockgen.ClockGen
#667
Comments
Thanks! The whole idea with |
I think one big concern here is that a bunch of applets use |
I could search the codebase for any uses of |
It looks like these are the direct uses of
and these are the indirect uses of
|
All in all it's just five applets total, of which only one (UART) uses |
I'll create a PR then. |
This addresses GlasgowEmbedded#667.
This addresses GlasgowEmbedded#667.
The
ClockGen
module has an off-by-one error when deriving a clock using.derive
or.calculate
. The output clock period is one input clock cycle shorter than necessary. This happens only when the ratio between the input and output frequencies is >= 3.Amaranth playground link.
Here, the input clock is 4Hz and the output clock is 1Hz. Since the input is evenly divisible by the output, we should get an output clock that is exactly 4 input clock cycles long. And, since the ratio is divisible by 2, we should get a 2 clock high pulse and a 2 clock low pulse on the output. Instead, we get 3 cycles - 1 high, 2 low.
The issue is that
calculate
computescyc = round(input_hz // output_hz) - 1
, and then the implementation uses this value for the counter if it's >= 2. Ifcyc == 0
orcyc == 1
, then we get into one of the two special cases (same frequency or half frequency), and there everything works fine.I think the fix should be something like:
Simulation with the fix.
On a related note, the special case where the output frequency is half the input frequency has a strobe behaviour different from the normal case. In the special case
stb_r
andstb_f
rise one cycle before their respective clock edges. In the normal case they rise on the same cycle. Not sure which behaviour is the correct one, but I think they should at least be consistent.In terms of actual impact the whole thing may not be a big deal. Assuming most applets derive clocks that are much slower than the system clock, the off-by-one deviation should be negligible.
The text was updated successfully, but these errors were encountered: