Fix serial_deglitch.sv

[jimaandro]

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

[niwis]

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.

[phsauter]

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.