Resources for learning FPGA

[rstofer]

This book deals with both VHDL and Verilog in the implementation of a MIPS type processor.   They discuss pipelining but they don't provide logic for it.

https://www.amazon.com/Digital-Design-Computer-Architecture-Harris/dp/0123944244

There is an ARM specific version that deals with VHDL and System Verilog

https://www.amazon.com/Digital-Design-Computer-Architecture-ARM/dp/0128000562

Both are really good but pricey.  Again, I need a project in order to keep my interest.  Both of these books present enough code to become a complete processor.

[OwO]

A worthy project is to take some of these constructs, like the FSMs and synthesize them.  Then look at the RTL schematic.  The synthesizer will warn you if you have inferred a latch but what it won't tell you is whether you have inferred a priority encoder and whether that priority encoder is realized as a long string of logic which doesn't help with Fmax.

I don't disagree that case statements are preferable when you have many possible states. Personally I would restrict it to one or a few signal assignments per process and enforce that every branch of the "case" has exactly the same assignments. Never think of it as "control flow" like in programming; a case statement with signal assignments is a mux.

Regarding big state machines, the answer is avoid them in optimized designs  . Inherently a big state machine with many inputs will generate a big combinatorial circuit, which is always going to mess up your timing. Instead, design the system as many smaller "building blocks", where each building block may have small state machines.

I still prefer to see all possible sources of a signal, rather than all things that "happen" at a state because this way tells me right away what the circuit is like and any possible timing bottlenecks. When I need to reason about the design, I don't read the code, I go back to the diagram.

Btw I don't think of it as a single "machine" that does "actions"; rather a circuit that has some state variables, plus some independent "circuit fragments" that data passes through and may behave differently depending on the state. When I look at an output-forming circuit, the possibilities of the circuit are more relevant than other circuits that happen to change their behavior during the same state.  In other words, I don't think the output forming logic are part of the state machine, and different output forming circuits may be completely independent (e.g. the part generating sync signals vs the part that computes next synthesizer frequency).

[rstofer]

Regarding big state machines, the answer is avoid them in optimized designs  . Inherently a big state machine with many inputs will generate a big combinatorial circuit, which is always going to mess up your timing. Instead, design the system as many smaller "building blocks", where each building block may have small state machines.

Assuming that ultimate speed isn't a criteria, we need to figure out who/what the code is written for.  I have seen the disjointed approach to machine design and I don't see it as being nearly as easy to read as the single case statement generating all of the outputs.  Having to look through a few thousand lines of code to find every occurrence of a state variable (even with the editor 'find' feature).  Since I view the code as something I write for me to understand, I don't worry much about the difficulty imposed on the toolchain.  The compiler writers are pretty smart, they'll come up with a decent solution.

For my IBM1130 project, the main FSM is 907 lines of code, 52 inputs, 41 outputs and 111 states.  Non-restoring division is probably the worst instruction with 7 states and a 15 count loop within one of them.  It's a really good thing I found a pseudo microcode example in a textbook or I never would have gotten this worked out.

I realize I could break this up into MANY smaller blocks but it just wouldn't be as clear to the observer what exactly is happening.  If I ported the code to one of the Artix devices, I could probably run at 100 MHz (on a Spartan 3E it easily runs at 50 MHz) while the original machine ran at about 400 kHz.  Modestly fast for 1965...

I see your point about small blocks of  code representing small circuits and I realize that with one-hot encoding, my state variables are 111 bits wide (insane register width).  Maybe next time I will try the disjointed approach.

I'm not sure there are any 'absolutes' in HDL, I think it comes down to choice.

[coldfiremc]

HDL is like HTML. Aestethically and syntactically have nothing in common, but conceptually had lots, specially that there's no "Program Counter", file orientation and all code at once, except when explicitly programmer asked for it.

[james_s]

That's because neither one is a programming language, they're both used to describe something.