But I also think that to do hardware design in VHDL or Verilog, you need to understand the underlying structures - latches, flip-flops, decoders, muxes, etc.
I'm enjoying this recent trend!
Mind, I don't fault the author for being surprised. It's a logical consequence of that remove. But as somebody who grew up with blinkenlights and core memory, the idea of not knowing this fact is completely foreign to me, even though I have no HW skills worth mentioning.
Part of me wonders if that means we should teach SW engs about those realities. Especially given the authors wide-eyed realization that all that code executes in parallel, all the time. It's a mental model that seems rather useful given the amount of parallelism we see and will be seeing.
Or maybe I'm just old and grumpy ;)
As I said, I don't see not knowing this as a fault - it's a product of our current environment and the fact that the gulf between HW and SW has widened. As such, it's not making me grumpy. I just thought it made an interesting point about how much we've progressed.
And good on you for pointing it out and teaching about it!
Only barely. Modern FPGAs are made up of LUTs and flip-flops, which can be abstracted as "cloud of programmable asynchronous logic surrounded by D Flip-Flops". I think if you start by explaining the abstract notion of asynchronous logic, and the notion of gating a design using D flip-flops, you can get someone up the HDL learning curve really fast without going into the depths of what boolean functions are, what a mux is, etc. Boolean functions and muxes aren't a central component of modern programmable logic anyway.
I've been thinking about writing up "30 minutes to your first HDL design" at some point. Dragging a competent C programmer up the learning curve is pretty easy, as long as you don't start off with "it's like C but...". I've trained a few SE interns to write some halfway-decent CPLD designs in just an hour or two, and consequently I think that the way they've taught it at school is way too low-level for someone that's going to be working with modern programmable logic, and it needn't be so painful.
entity and_entity is
x, y: in std_logic;
result: out std_logic
To me, it's making an always-on connection, such that any electricity on either line "x" or "y" will induce an identical electrical current on "result". This would obviously include any electrical signals, including HIGH/LOW pulses. And they're combined, so HIGH on either "x" or "y" outputs HIGH on "result".
Because of how I read code, I see that as: whatever is in buckets "x" and "y" are combined and copied into bucket "result".
I've never thought of lines, buses, leads, wires, etc as buckets. Yet that's how I think they're described in this code. But if you think about an individual clock cycle frozen in time, some wires have HIGH pulses, and the intention is to copy the HIGH pulse from that wire/bucket.
A really interesting mental-model barrier to watch hardware newbs overcome is to present them with designing a counter - and watching as the very first thing they want to type is a for loop, which is generally not how you'd do it, but almost reflexive to someone who has been programming for a while - particularly in an imperative style.