Verilog isn't a programming language (it tries to be, unfortunately). For synthesis, it is a hardware description language. Someday I'll write up some decent Verilog tutorials because there aren't any good ones on the Internet.
It reminds of teaching some VHDL in a hackerspace a few years ago (I had learned it in college some years previously), and this software guy was constantly trying to write functions and loops, and was having trouble with the concept that all signals were propagated concurrently rather than sequentially!
Sure, it looks like code (in fact, VHDL's syntax is purposefully similar to ADA), but it sure isn't code.
Computer science grad here. I had to keep reminding myself about the HDL part of VHDL. It's not algorithmic description like programming is, but hardware description.
From memory:
- HDL code doesn't have variables the way programming code does. Sure, you can store state in latches (and other more roundabout ways), but a good design tries to avoid this.
- You can have "functions" that take parameters, but what you're really doing is instantiating blocks of hardware according to said parameters.
- Instead of variables to functions, what you really care about is signals as input and output to hardware blocks. (and ultimately at the final hardware implementation, propagation time and power of said signals. Especially the clock. OMG the clock...)
Honestly, I found VHDL made complete sense from approaching it after drawing digital circuit diagrams, as the description code mapped pretty clearly to that. Approaching it from an "imperative programming" background makes little sense, and saying it's "concurrent programming" just ends up confusing the issue more, IMHO.
Unfortunately all to many courses approach like learning a new programming language. To me this is like teaching CAD before teaching how to draw a rectangle.
And this kind of distinction was what we were having trouble conveying to said software guy (I say this as a software guy myself), and I think the author of the LISP CPU is having the same problem.
That's not a bad thing.
Maybe this is why a Lisp processor doesn't exist. Not only do you have to know Lisp well, which only a minority of programmers do, but you also need to want to know hardware. Which is something software people don't want to do. This guy already has a leg up.
For some strange reason I can't explain it's easier to imagine a software guy building hardware than a hardware guy writing a Lisp.
Now, most people who do primarily hardware work probably aren't that interested in Lisp, because there's not really much Lisp focus out there. I'm a computer engineer, I know how to write HDL and lay silicon, I like Lisp... actually it would be a pretty fun project to do in an FPGA.
Sounds like he hadn't written much software in a language with an actor-model. It's not nearly as hard a jump to VHDL if you've ever debugged an Erlang supervision tree, or a miscommunicating set of SOA web services.
Behavioral descriptions are very, very similar to programming, and a lot of programming concepts and skills (e.g. modularization) translate very well to HDLs.
The only thing in HDLs I remember that is totally alien to programmers is propagation delays. Well, even that is somewhat similar to multi-threading issues.
Unfortunately, the digital circuit book also doesn't have a modern table of content: SR flip-flops and 7400TLS are not exactly related to Verilog much at all.
Is there a place where such issues can be discussed?
EDIT: I started https://en.wikibooks.org/wiki/Programmable_Logic/Verilog_for...
You don't build more complex functions like adders or multiplexers from individual gates anymore, so don't put beginners into this outdated mindset. Sure, explain how to build a half-adder from ANDs and XORs, but make it clear that they shouldn't do this for anything except experimentation; you don't need any specific parts like the 7400s for this. Instead, teach them proper design techniques with HDLs (as horrible as VHDL and Verilog are, they are better than schematic designs).