Who I am
I'm Casey Petzel, and I've been doing FPGA work for about a decade. I started in defense hardware, then latency-critical trading systems at a couple of firms, then a few years as a Prototyping Application Engineer at Siemens EDA helping customers bring up billion-gate prototypes. These days I'm the Principal FPGA Architect at Spartak Trading, back in high-frequency trading.
Why I'm building this
For years now, I've had the same conversation over and over: with students asking which way to point themselves, with junior engineers I've mentored asking how some concept actually works, with peers trading notes on things we all wish somebody had explained earlier. And every time, the conversation ended the same way. “Where can I read more about this?” And every time, I didn't have a good answer.
There are textbooks, and some of them are excellent, but they're expensive, they're dense, and they assume you already speak the language of the field before you've had a chance to learn it. There are scattered blog posts, a few of them great, most of them half-finished. There are manufacturer datasheets written for people who already know the thing the datasheet is supposed to teach. There are forum threads where the right answer is buried three replies deep under two wrong ones.
What's missing is the thing in the middle: a place you can start at zero, read your way up, and come out the other side knowing enough to hold a real conversation with a senior engineer. Not just “what does this acronym mean,” but why it exists, when you'd reach for it, and what happens if you pick wrong.
So I'm building that place. Or at least, I'm trying to. I also happen to love LaTeX and building websites, so honestly I couldn't resist.
A fair warning
Everything on this site is how I understand this profession. It's the mental model I've built over years of designing, debugging, reading datasheets at 2am, and teaching people younger than me how to do the same. Some of it is textbook-correct. Some of it is shop-floor practical. And some of it, honestly, might be wrong.
I'll be clear when I'm giving you rules that are universal, when I'm giving you conventions that are common but not required, and when I'm giving you opinions that are just mine. But I'm one engineer with one perspective, and the field is enormous. If you read something here and your instinct says “that's not quite right,” trust that instinct, go check, and if I got it wrong, tell me.
The goal isn't to be the final authority. The goal is to be a starting point: the resource I wish I'd had when I was the one asking the questions.
Who this is for
If you're a student staring down your first HDL class and wondering what you've signed up for, this is for you.
If you're a software engineer getting dropped into a hardware team and nodding along in meetings while quietly googling acronyms, this is for you.
If you're a working engineer who learned by osmosis and has never had someone explain why the things you do every day actually work, this is for you too.
And if you're an expert who just wants to see how someone else frames a concept you've known for twenty years, welcome. Tell me where I'm wrong.
Thanks for being here. Let's figure this stuff out together.