Skip to content

Fix serial_deglitch.sv #252

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

jimaandro
Copy link

if we want to count zeros, then we should check if count_q != 0. Checking count_q!=SIZE will lead to stuck in 1 for q_o

if we want to count zeros, then we should check if count_q != 0. Checking count_q!=SIZE will lead to stuck in 1 for q_o
Copy link
Collaborator

@niwis niwis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you. Actually, I think there might be more issues with this module (why count to SIZE[SIZE-1:0]? Default value for q_o? q not used?). Because any of these changes will have behavioural implications, I'm marking this as v2 for now.

@niwis niwis added the v2 label Feb 4, 2025
@niwis niwis added this to the v2.0 milestone Feb 4, 2025
@phsauter
Copy link

I just had a look at src/serial_deglitch.sv and src/mv_flilter.sv both added in this commit.

For serial_deglitch (as mentioned by others):

  • q_o has an incomplete assignment which means a latch should be inferred.
  • the threshold seems wrong

For mv_filter:

  • Commit says it is a 'moving deglitcher'
  • Implementation only counts 1s since the last clear and when it reaches a threshold, a 1 is latched
  • To me this feels like it doesn't match the description and isn't super useful (its a counter with a sticky overflow)

Imo what all these try to implement is a majority voting system used for eg UART, SPI or I2C (or any other serial interface where you want to oversample).
I see that the counter/integrator implementation saves state compared to a shift register style implementation but I am actually not convinced it is better.
This needs more logic than a simple majority vote computation from a shift register (though again, the area difference is likely trivial) and just based on my feeling, I think the linear shift register may add some more meta-stability recovery when a sync is used before it (which I would assume is the most common use-case anyway).

So I think this should probably be redesigned anyway to maybe feature an optional integrated sync (?), settable threshold(s) and maybe a linear approach instead of a counter/integrator one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants