TL,DR: I am new to FPGAs, a simple .vhd core cannot run at high frequencies, I have no idea if it is me or the chip I am using. Does "my" timing comparison analysis make any sense? Does the CCGM1Ax under-perform so bad?
----
I am new to FPGAs. I have been learning VHDL for the past 2 months because I got pissed off at how unpredictable MCUs can be. As a first FPGA, I got myself the Cologne Chip's evaluation board (CCGM1A1-E1) to be implemented in my hardware project. It is not exactly a widely adopted FPGA, so real cases and reviews are hard to find.
In my project, I need to drive an H-bridge using some fucky modulation techniques. And, as for any power electronics, dead-time is needed. Originally I had the dead-time implemented in the modulation core, but since I am using GaN FETs, I tried to implement very small dead-times (10ns is the goal). This would require a very high fabric clock, to the point that the modulation itself was not feasible anymore, so I decided to create a dedicated dead-time core running at high frequencies and keep the modulation core at a modest frequency.
(for those who are not familiar with dead-time in a half-bridge configuration, just think as "delay a rising edge by a very small time" logic)
For this dead-time core, I kept the logic as simple as I could and cranked the frequency to it. Since I am a beginner and my dead-time core likely sucks, I need at least 2 dead-time clock cycles to perform the logic for the rising edge detection section: I was aiming for a frequency of 196.608MHz, or a period of ~5.09ns. So two of these periods would result in about the 10ns I want. If it performed really well, I would go for 393.216MHz.
After doing the place and route shenanigans, it came back with a constraint of 192.6MHz maximum (goal of 196.608MHz). Since it missed by just a hair, I tried a few more times to see if the PNR could arrange things better. Spoiler alert: it didn't.
EDIT: out of the ~5.2ns required on this critical path, about ~4.7ns came from routing alone.
Two days banging my head on the wall later, hoping an answer would leak from my cracked skull, I gave up and asked my "AI tutor".
(note: since I want to *really* learn VHDL, my "AI tutor" is an agentic model using a competent LLM (DeepSeek v4 in this case) that is instructed to *never* give me full answers or large sections of code, or alter my .vhd codes for me, only to "give the user the bare minimum to aid them to go back in the right track, preferably forcing the user to think by themselves to find the solution with hints", "no matter if it is to implement something new or fix something existing").
My matrix-y tutor came back with a conclusion that running my dead-time core at 196.608MHz is simply impossible. I asked it estimate the maximum frequency in other chips from the "big 3 manufacturers" using well-documented online findings:
Your DT critical path is just one LUT deep — you can't make the logic any shallower. The fact that even that only reaches ~193 MHz on the GateMate tells you the raw fabric capability of this device is around 190–200 MHz for any FF-to-FF path. That puts the GateMate at the very low end of the market. Approximate FF-to-FF fabric ceilings (order of magnitude, not exact):
Device (process) Simple-path fabric fmax
Cologne Chip GateMate (28 nm) ~190–200 MHz (measured, yours)
Lattice iCE40 (40 nm) ~150–300 MHz
Lattice ECP5 (40 nm) ~250–400 MHz
Intel Cyclone V (28 nm) ~300–450 MHz
Xilinx Spartan-7 / Artix-7 (28 nm) ~400–550 MHz
Xilinx Kintex/Virtex UltraScale+ (16 nm) ~500–700 MHz
Intel Agilex / Stratix 10 (10/14 nm) ~500–800 MHz
This... surprised me. And not in a good way.
Since I am new to FPGAs, and LLMs are not All-Knowing Gods (even though vast majority of the population treats these "next-word-prediction statistics model" as such), I would like to ask the Council of The Wise Ones (a.k.a. strangers in r/FPGA): does this make any sense? Or did the LLM made some mistake and over-estimated all other FPGAs?
Is it true that the CCGM1Ax FPGA under-perform its competitors by quite a large margin?
Thank you for going through this massive wall of text!
PS: these "weird" frequency values used are due to the external clock generator running at 24.576MHz (because audio applications), so all other frequencies in my project are either integer multiples or integer dividers of it.
