openpowerbot | [slack] <Michael Neuling> @Matt Johnston I'm looking at your GPIO PR. We double buffer the GPIOs for metastability reasons, but you are doing edge detect between the first and second FF which would seem a bit dangerious. I would have thought we'd want to add another FF stage | 03:30 |
---|---|---|
openpowerbot | [slack] <Matt Johnston> ah, I wasn't sure of the reason for those FFs, right | 03:30 |
openpowerbot | [slack] <Michael Neuling> ok 👍 | 03:31 |
openpowerbot | [slack] <Michael Neuling> we should probably add a comment as to why they are there | 03:31 |
openpowerbot | [slack] <Michael Neuling> also, why this: | 03:31 |
openpowerbot | [slack] <Michael Neuling> ``` -- latch current value on interrupt hit | 03:31 |
openpowerbot | [slack] <Michael Neuling> if not reg_intr_hit(i) then | 03:31 |
openpowerbot | [slack] <Michael Neuling> reg_in2 <= reg_in1; | 03:31 |
openpowerbot | [slack] <Michael Neuling> end if;``` | 03:31 |
openpowerbot | [slack] <Michael Neuling> I would have thought we'd keep `reg_in2 <= reg_in1` always | 03:31 |
openpowerbot | [slack] <Michael Neuling> @Matt Johnston ^ | 03:32 |
openpowerbot | [slack] <Matt Johnston> hm, I think I had intended to have `reg_in2(i) <= reg_in1(i)` , so the interrupting value is captured. though perhaps that isn't useful? | 03:34 |
openpowerbot | [slack] <Michael Neuling> I think we'd ways want to read to be the current state of the pin | 03:35 |
openpowerbot | [slack] <Michael Neuling> I think we'd always want to read to be the current state of the pin | 03:35 |
openpowerbot | [slack] <Michael Neuling> I think we'd always want to wishbone read to be the current state of the pin | 03:36 |
openpowerbot | [slack] <Matt Johnston> ok | 03:36 |
openpowerbot | [slack] <Michael Neuling> Other than that, PR looks good. Thanks @Matt Johnston | 03:39 |
openpowerbot | [slack] <Matt Johnston> thanks for looking at it | 03:39 |
openpowerbot | [mattermost] <lkcl> Matt, yes, to do ASync clock-domain-crossing you need bare minimum 2 FFs. in some cases 3 or more can be adviseable. | 15:32 |
openpowerbot | [mattermost] <lkcl> Ericsson's GPIO design on elinux.org uses a Schottky symbol for transient spike suppression yet good edge-detection | 15:33 |
openpowerbot | [mattermost] <lkcl> let me find it... | 15:33 |
openpowerbot | [mattermost] <lkcl> yeah here we go https://elinux.org/images/b/b6/Pin_Control_Subsystem_Overview.pdf | 15:34 |
openpowerbot | [mattermost] <lkcl> the hysteresis is for when you have buttons that do massive "bouncing" on contact (cheapo toggle switches) | 15:35 |
openpowerbot | [mattermost] <lkcl> STM32F series ECs have slow/medium/fast control on that, because some peripherals you do obviously want them to be capable of running at e.g. 50 mhz | 15:35 |
openpowerbot | [mattermost] <lkcl> and any kind of filter would scramble that, badly | 15:36 |
openpowerbot | [mattermost] <lkcl> from that Ericsson PDF, we might reasonably surmise that edge-detection is ok to do *after* Async-FF-stabilisation-chains | 15:44 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!