4 ms·

Is the benefit of the FPGA here that you can program the whole stack? Like a kind of super-charged QMK based board?

pedro_caetano 1y ago
Well the project description seems to hint at to their motivation: > 1000 Hz polling rate > No multiplexing, no ghosting > FPGA-based, VHDL only, no ALU It looks like a pure HW 'described' keyboard with no running software meaning it is fully parallel (plus some serialization when reaching the USB device/interface). So arguably on top of true parallelism the only ceiling for the latency of the whole thing will be the clock period configured in the design and the physics and electrical behaviour of the switches themselves + circuitry. Probably someone who enjoys working close to hardware and wants to optimize performance.
- crote 1y ago
  Most MCU-based keyboards have a 1000Hz polling rate - and some mainstream gamer-focused keyboards are even going for 8000Hz these days. Getting rid of multiplexing is a result of having a high number of IO pins: an MCU like the STM32F429BE also has enough pin for direct-attach switches. Ghosting hasn't been an issue for ages, even with a traditional keyboard matrix it's just a matter of adding per-key diodes. In theory it has a sliiightly lower latency than an MCU-based keyboard using the same USB interface, but I doubt the difference is big enough to even be measurable in real-world scenarios. We're talking about, at most, a few thousand cycles of an MCU running at a few hundred megahertz - and that's only relevant when you press the key right before a polling request arrives. That's the difference between an average input latency of 0.500 ms and 0.505 ms. Meanwhile on the output side, your fancy 480Hz monitor is only showing one frame every 2.1 milliseconds...
  - deleted 1y ago
    [deleted]
  - pedro_caetano 1y ago
    The optimization here is somewhat theoretically specially when you take into account the USB bottleneck as well as real-world Human reaction times and Perception. But it appears from the project description that the author's motivation was indeed performance (irrespective of merit). A neat VHDL + HW project nevertheless.
- tremon 1y ago
  In that light, it's odd that they specify a polling rate at all, since they use direct-attached key pins linked to an 48MHz clock. There is no grid/matrix sensing period, which is usually what is meant by polling rate. And the claimed value of 1kHz is doubly weird since the debouncing logic uses a period of 5ms, which means they can at most mimic a 200Hz polling rate: entity Debouncer is generic ( FILTER_DURATION: delay_length := 5 ms ); edit: looked up what the typical bounce time is for a keyboard switch, and 5ms seems to be pretty standard. It's also the default that QMK uses. It seems quite excessive to me, I'd have expected bouncing times to be closer to tens of microseconds than multiple milliseconds.
crote 1y ago
Because you can? It looks like a great project for getting started with nontrivial FPGA design. Programming-wise I'd say full FPGA is less useful than QMK. Doing a direct 1:1 mapping from key inputs to USB HID report isn't too bad to do in an FPGA, but dynamic behavior like macros, layers, leader keys, mod tap, auto shift, and so on are significantly easier to implement in a regular programming language. If you want flexibility you're basically forced to have your FPGA run a soft core, so at that point why not go for a regular MCU? In theory you could make an argument for lower latency, but that doesn't really apply when you're limited by USB 2's 1000Hz polling rate while some off-the-shelf MCU-based keyboards use USB 3 for 8000Hz polling.
- privatelypublic 1y ago
  Yea. Fun, but not optimal for a product. 1000Hz is already comically faster than any human muscle reaction.
  - wtallis 1y ago
    With regards to latency: reaction time is the wrong thing to compare against, since input latency can be noticeable even when it is much smaller than a human's reaction time. And wanting to have your keyboard latency be no worse than 1ms can make sense given that it's only one of many components of the total input latency of a computer. Reducing mouse or keyboard latency from 8ms (125Hz) to 1ms (1000Hz) is pretty much the low-hanging fruit; it's not as cheap or easy to squeeze 7ms out of the other parts of the chain.
ginko 1y ago
I think the main motivation was the ability to assign each key to a separate pin (fpgas can have lots) so no multiplexing is needed.

Well the project description seems to hint at to their motivation: > 1000 Hz polling rate > No multiplexing, no ghosting > FPGA-based, VHDL only, no ALU It looks like a pure HW 'described' keyboard with no running software meaning it is fully parallel (plus some serialization when reaching the USB device/interface). So arguably on top of true parallelism the only ceiling for the latency of the whole thing will be the clock period configured in the design and the physics and electrical behaviour of the switches themselves + circuitry. Probably someone who enjoys working close to hardware and wants to optimize performance.

crote 1y ago
Most MCU-based keyboards have a 1000Hz polling rate - and some mainstream gamer-focused keyboards are even going for 8000Hz these days. Getting rid of multiplexing is a result of having a high number of IO pins: an MCU like the STM32F429BE also has enough pin for direct-attach switches. Ghosting hasn't been an issue for ages, even with a traditional keyboard matrix it's just a matter of adding per-key diodes. In theory it has a sliiightly lower latency than an MCU-based keyboard using the same USB interface, but I doubt the difference is big enough to even be measurable in real-world scenarios. We're talking about, at most, a few thousand cycles of an MCU running at a few hundred megahertz - and that's only relevant when you press the key right before a polling request arrives. That's the difference between an average input latency of 0.500 ms and 0.505 ms. Meanwhile on the output side, your fancy 480Hz monitor is only showing one frame every 2.1 milliseconds...
- deleted 1y ago
  [deleted]
- pedro_caetano 1y ago
  The optimization here is somewhat theoretically specially when you take into account the USB bottleneck as well as real-world Human reaction times and Perception. But it appears from the project description that the author's motivation was indeed performance (irrespective of merit). A neat VHDL + HW project nevertheless.
tremon 1y ago
In that light, it's odd that they specify a polling rate at all, since they use direct-attached key pins linked to an 48MHz clock. There is no grid/matrix sensing period, which is usually what is meant by polling rate. And the claimed value of 1kHz is doubly weird since the debouncing logic uses a period of 5ms, which means they can at most mimic a 200Hz polling rate: entity Debouncer is generic ( FILTER_DURATION: delay_length := 5 ms ); edit: looked up what the typical bounce time is for a keyboard switch, and 5ms seems to be pretty standard. It's also the default that QMK uses. It seems quite excessive to me, I'd have expected bouncing times to be closer to tens of microseconds than multiple milliseconds.

crote 1y ago

Because you can? It looks like a great project for getting started with nontrivial FPGA design. Programming-wise I'd say full FPGA is less useful than QMK. Doing a direct 1:1 mapping from key inputs to USB HID report isn't too bad to do in an FPGA, but dynamic behavior like macros, layers, leader keys, mod tap, auto shift, and so on are significantly easier to implement in a regular programming language. If you want flexibility you're basically forced to have your FPGA run a soft core, so at that point why not go for a regular MCU? In theory you could make an argument for lower latency, but that doesn't really apply when you're limited by USB 2's 1000Hz polling rate while some off-the-shelf MCU-based keyboards use USB 3 for 8000Hz polling.

privatelypublic 1y ago
Yea. Fun, but not optimal for a product. 1000Hz is already comically faster than any human muscle reaction.
- wtallis 1y ago
  With regards to latency: reaction time is the wrong thing to compare against, since input latency can be noticeable even when it is much smaller than a human's reaction time. And wanting to have your keyboard latency be no worse than 1ms can make sense given that it's only one of many components of the total input latency of a computer. Reducing mouse or keyboard latency from 8ms (125Hz) to 1ms (1000Hz) is pretty much the low-hanging fruit; it's not as cheap or easy to squeeze 7ms out of the other parts of the chain.

ginko 1y ago

I think the main motivation was the ability to assign each key to a separate pin (fpgas can have lots) so no multiplexing is needed.