Clavier: an Fpga-Based Mechanical Keyboard with Usb Hub and Comms Interfaces
Posted3 months agoActive3 months ago
github.comTechstory
excitedpositive
Debate
20/100
FpgaMechanical KeyboardEmbedded SystemsOpen-Source Hardware
Key topics
Fpga
Mechanical Keyboard
Embedded Systems
Open-Source Hardware
The Clavier is an FPGA-based mechanical keyboard with USB hub and comms interfaces, sparking interest and discussion among HN users about its design and potential applications.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
3d
Peak period
19
72-84h
Avg / period
7.6
Comment distribution38 data points
Loading chart...
Based on 38 loaded comments
Key moments
- 01Story posted
Oct 1, 2025 at 1:05 PM EDT
3 months ago
Step 01 - 02First comment
Oct 4, 2025 at 5:10 PM EDT
3d after posting
Step 02 - 03Peak activity
19 comments in 72-84h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 9, 2025 at 7:03 AM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45440180Type: storyLast synced: 11/20/2025, 5:33:13 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
The headers on the keyboard look like they'd be easier to hit accidentally, but probably not with enough force to cause a serious injury. I'd still prefer having some covers over them.
https://www.digikey.com/en/products/detail/lattice-semicondu...
Btw, that's a 256 pin BGA part, grandad's Weller cannot help.
> 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.
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...
But it appears from the project description that the author's motivation was indeed performance (irrespective of merit). A neat VHDL + HW project nevertheless.
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.
So you can do openscad (its weird language) or you can do python and use the STL lib.
Which do you like better?
OpenSCAD is simply not worth the pain unless you're using it to demonstrate abstract geometry.
Build123D or CadQuery could well be viable, though IMO both have slightly frustrating dependencies. But since they can both load STEP files then customisations can be applied to designs built mostly elsewhere.
USB 2, on the other hand, is fairly trivial. You almost have to try to get it wrong - especially when you are not concerned about certification.
Usagi Electric did a nice video if that's your kind of thing: https://youtube.com/watch?v=sSiVYgot9SI
I think the video does a nice job of showing the mechanical components that encode the keypresses and generate the 45.5 baud serial output. The printing side isn't given quite as much coverage but you do get to see close-up views of it in operation.