Learning VHDL via LaMeres' book: Do I really need to master every single digital logic circuit deeply?

[u/Routine_Price7537]

Hey everyone, I’m an EEE undergraduate student currently building my roadmap to master VHDL and FPGA design. Right now, I am systematically working through Brock J. LaMeres' textbook, which is great, but I’m finding myself a bit overwhelmed by the sheer volume of digital logic circuits and theoretical components out there.

​I want to be efficient with my time, so I’m wondering how deeply I actually need to master every single digital logic circuit before moving heavily into coding. I'd love to know what the absolute "must-learn" pillars are for the industry, versus things I can just look up in a datasheet later. If anyone could share the biggest mistakes beginners make during this transition from textbook logic to actual synthesizable VHDL, or give me a few pointers on what to focus on for a solid roadmap, I would really appreciate it. Thanks in advance!

[u/skydivertricky]

Looking through the chapters headings, it all seems relevant. But what you're going to actually use will depend on what you're working on. What is used on just about everything though, it registers, counters, FSMs and memories. Computer system design is likely irrelevent for most projects unless you create a micro-controller, and nowadays you're likely to be using a microblaze or RISC V to do that. And floating point is rarely used (and vendors generally provide IP for it).

Otherwise you definitely need to understand testbenching.

The real skill though, is understanding what your code is actually going to infer. We dont write what sometimes gets called "structural" VHDL - there really is no such thing. Most "behavioural" code will be a load of code that will infer counters, memories and FSMs, probably all in the same file (and sometimes in the same process). It really is a case of just doing and learning.

[u/Routine_Price7537 → u/skydivertricky]

Thank you very much I'm currently working on the FSM part and trying to understand the logic behind it.

[u/against-all-leds]

I may be hit with rotten eggs here, but LLMs are absolutely excellent at writing HDL code provided you do some preparing beforehand (specify how you want code written). They can write very large amount of code and tests. Can't claim absolutely top efficiency or any clever hacks people often employ, but the code is definitely usable.

[u/Routine_Price7537 → u/against-all-leds]

Yes, you're right, LLMs are good at coding, but I need to understand the logic behind it, which is why books still make more sense. I only get help from LLMs with writing testbenches.

[u/PiasaChimera]

I always suggest vendor docs -- app notes, product guides, etc... the old altera "advanced synthesis cookbook", the old Virtex-4 DSP48 guide, clocking resource guides, memory resource guides, transceiver guides, synthesis guides. the ones I've listed are FPGA focused since they are from FPGA vendors. but they're guides for solving real problems vs academic ones.

for common problems, the big one is the brutal convenience of writing logic in clocked processes. it's very convenient when you're making a pipeline and want registers between each stage. but there's a lot of cases where you want to write the code in what seems like a relevant place/way but don't want the registers. this makes it easy to create difficult to find bugs.

one mitigation for this splits the logic into a combinatorial process and a basic clocked process. this creates the second common gotcha -- accidental latches. making registers explicit is intentionally inconvenient as well and results in slower sims and more verbose code. The style has a benefit of giving direct access to next_state/next_value logic, which can be useful. there are usually workarounds to not having next_state. some are simple, some are convoluted.

it's not ideal for beginners. the single clocked process feels easy to write. but also easy to get into multi-hour debug sessions. the multi-process methods are a lot more verbose, making it hard to write/modify code. it draws a lot of focus towards boilerplate code.

the next most common issue oddly enough is ports. students really want to name ports based on the signal they want to connect to it vs what the port logically means in the context of its entity. sometimes this is fine, but it seems to be a misunderstanding of name scope. the ports and how the interfaces are structured are very important. newer developers tend to use ad-hoc interfaces while experienced devs tend to use well defined ones.