I'll rant for a moment here, because I think this is something that the Simple CPU link has the potential to get right, and that I think is a common pitfall with digital design tutorials.

I think one of the pain points that you commonly see with tutorials is the concept that the hard part is the language. As a digital designer, I think that's explicitly not the case: just like teaching functional programming, the syntax is not the challenge, but the mode of thinking. Digital design is a skill that really requires deep thought about what a given piece of syntax will compile down to; it's possible to skim over the "building blocks" of software (for instance, it is possible to be a very good JavaScript programmer without knowing what the JIT will transform your code to), but in order to build effective (or even possible-to-synthesize!) hardware designs, I believe that it is very important to start with the fundamentals of how hardware actually works.

So, I plead: if you have cause to write a digital design book, don't write it as a "Verilog for Computer Scientists"! Verilog is a big language, and not all of it is good for writing hardware. What you really want is "Digital Design for Computer Scientists".

Yes, the two key hurdles to HDL are (in my opinion):

- Being able to think parallel. Software is sequential by default, HDL is parallel by default.

- Understanding what you want to build. If you can't draw what you want, you probably can't write good HDL. There's a reason it's called Hardware Description Language, and not "JS2GATES". In a sense, HDL is really just text-based schematics.

Case in point:

http://www.allaboutcircuits.com/vol_5/chpt_7/8.html

When you think "HDL" you probably think of Verilog or VHDL, but SPICE netlists is also an HDL.

>Being able to think parallel. Software is sequential by default, HDL is parallel by default.

Totally. When working through the nand2tetris stuff, several of my designs fell on their face because I started thinking of multistep circuit logic as sequential, forgetting that junk results aren't discarded by the "flow" but that their values are always "evaluated" and fed into downstream logic.

I'm not sure how and where or indeed if to contribute, but as a programmer who learned digital electronics (stack of free 74xx chips) before diving into programmable logic, one thing that really helped make these things click for me was thinking about hardware as transistors and learning the very basics of electricity and related physics. This helped me see digital electronics not as a sequential process but as a consequence of natural laws, like something dropping due to gravity.

Thinking of a transistor as a voltage controlled switch (obviously simplified to the point of being wrong but works for understanding digital) and seeing how you can use those to build logic gates, and then use gates to build muxes and flip-flops and so on up was essential for my understanding HDLs.

(Incidentally, all that has also made how computers and machine code work much clearer to me).

I don't think I could've really done it without that foundation. And I certainly couldn't have done it by just thinking of Verilog with my programmer's idea of concurrency.

It's obviously very low level and you'd have to gloss over a bunch of things, but I'd definitely start with transistors if I had to explain programmable logic to somebody.

I had a similar experience. Digital logic is very clean and neat, but the part where things broke down for me are things with feedback loops like latches. It's a bit tricky to tell what's going to happen in such devices without some analog background.

For me, I think visualising the timing really helps - and remembering that signals and gates do not act "instantaneously"; there is always a propagation delay. This is also why shift registers work. Things like edge-triggered flip-flops would be impossible if gates and signals were infinitely fast.