I really encourage people to take a look at Verilog as well. I think it is much easier to learn and much more expressive. To get equivalent functionality with VHDL, you usually have to write three times more code.
Agreed. SystemVerilog is now 90% of the market in the US. VHDL is now mostly used by a few fancy UK companies and the Defense industry.
I'm still looking for an online community of hardware developers like HN. Smenow, John Cooley's mailing list feels too 80s for me and Janick Bergeron's verification guild just never had enough traction. Is HW intrinsically more boring?
Not trying to be snarky at all, but can you cite a reference re: SystemVerilog = 90% of the US market? Very curious as I would consider myself to be a pretty experienced HDL user and have never seen SystemVerilog in the wild. I am guessing this is a FPGA vs. ASIC thing.
I just skimmed over this, and was rather bothered by the fact that they just jump directly into syntax. There's essentially zero discussion about simulation or design.
Writing VHDL isn't programming. If you treat it like it is, you might get something that works in simulation, but it's going to be horribly inefficient at best, and will more likely not work at all in hardware.
I don't think it's helpful to refer to VHDL as "not programming". It is programming, just in an inherently parallel, declarative fashion rather than an imperative one. My favourite metaphor for programming in an HDL is to think of it as building a computer or writing a program using expressions in a spreadsheet.
I have a background in Electrical Engineering, and when coding in a hardware description language, I feel that instantiating and connecting entities is like drawing a hierarchical schematic but in text mode. And writing the RTL implementation of an entity is like giving requirements to the synthesis tools that I need a bunch of gates and flip flops that implement this functionality. When coding in some programming language, I have a completely different mindset.
Programming usually means coding in some language that will be compiled to machine language, and hardware description is so different kind of "programming" that I think it's dangerous to call it programming at all.
I agree, but, in that case, someone will need to combine teaching digital design along with a HDL.
I believe the authors assume that the reader is actually familiar with architecting digital systems or learning it concurrently from some other source.
Why do they sometimes include other signals than clock and asynchronous reset/set in sequential process sensitivity lists? For example D in Listing 6.2. The extra signals in the sensitivity list don't add any functionality, and might be confusing to the reader.
It's probably good to teach the two process FSM first, because it resembles the mathematical model, but back when I did VHDL design, I found single process FSMs more straightforward. Can't remember what they looked like exactly, but something like Thompson's answer here: http://stackoverflow.com/questions/5961751/encoding-state-ma...
You're right - including 'D' in the sensitivity list is incorrect and is a good way to lead to the synthesis of latches. Sensitivity lists should only include the clock, or clock and an asynchronous reset, or if it's combinatorial logic, all signals (with no clock).
The best explanation I've seen for two and three process FSMs is that older synthesis tools weren't smart enough to infer an FSM from anything else. At least with FPGAs, it seems like the professionals are only using the single process model. Why wouldn't you? It doesn't separate related pieces of code over multiple pages and the chance for stuffing it up is reduced significantly.
Teach people to use the single process model. Teach them that two and three process FSMs exist so that they can identify and understand them, but don't waste too much time on it. Some of the textbooks I've read devote a chapter to the distinction between Mealy and Moore state machines. Time to let this one die!
This will be immensely useful for me. I just began to self-study "From NAND to Tetris in 12 steps", and going to use actual real world HDL instead of the authors toy language.
The second, sixth, and twelfth pages of the PDF file are blank. The fifth page is nearly blank, except for the auto-erroneous notation that is was intentionally left blank. We are left with the ambiguity of unintentionally blank pages, or pages that refused to be corrupted by self negating declarations of their absence of content.
