Describing Hardware, Not Writing Software

1. Intuition — built, not executed

In software, code is a list of instructions and a processor walks them one at a time: line 1, then line 2, then line 3. Time is the order of execution.

In VHDL there is no processor walking your lines. Your code is a description of a circuit, and once that circuit exists, every part of it is live at once — exactly like a schematic where every gate is always powered. Nothing "runs first." The right question is never "what happens next?" but "what is connected to what?"

2. Everything is concurrent

Consider two concurrent assignments in an architecture:

architecture rtl of two_gates is
begin
  y1 <= a and b;     -- one AND gate
  y2 <= a or  b;     -- one OR gate, side by side
end architecture rtl;

These are not "step 1: compute y1, step 2: compute y2." They are two gates wired in parallel. Both watch their inputs continuously; the moment a or b changes, both outputs re-evaluate at the same instant. There is no first.

A direct consequence: order does not matter. Swap the two lines and the circuit is byte-for-byte identical, because text order is not execution order — it is just the order you happened to write two independent gates.

3. Parallelism you can see

The clearest proof that concurrent statements run together is a waveform. With y1 <= a and y2 <= not a driven by the same input, a single change in a updates both outputs at the same instant — not one cycle apart, not in source order:

If these were software statements, y2 could only update after y1. In hardware they are independent, so they move as one.

4. Assignments are wires, not variable updates

y <= a and b; does not "store the value of a and b into y." It permanently wires y to the output of an AND gate fed by a and b. The connection is the hardware; it holds for all time, not just at the moment a line executes. This is why you cannot drive the same signal from two concurrent statements — that is two gates fighting over one wire, a short circuit, not a "last assignment wins."

5. A loop builds hardware — it does not iterate in time

The software instinct says a for loop runs N times over time. In synthesizable VHDL a for ... generate loop is unrolled at build time into N copies of hardware that all exist at once:

gen_inv : for i in 0 to 3 generate
  y(i) <= not a(i);     -- this is FOUR inverters, built in parallel
end generate;

There is no "loop counter ticking through time" in the resulting circuit — there are four inverters, side by side, all live. The loop was a way to describe repeated structure, not a runtime iteration. (A process is similar: it is a parallel block that reacts to its inputs, not a function the program calls.)

6. Common software-brain mistakes

• Reading line order as execution order. Concurrent statements have no order; only inside a process do statements run top-to-bottom (and even there they describe hardware, covered later).
• Driving one signal from two places. Not "the second wins" — it is two drivers on one wire (contention), which is a real hardware fault.
• Expecting a loop to take time. A synthesizable loop is unrolled structure, not a timed iteration.
• Thinking a signal updates the instant you assign it. Signals schedule their new value (the next lessons on the signal model and delta cycles make this precise) — they are wires, not variables you mutate in place.

7. Summary & next step

VHDL describes hardware: a parallel structure that is built and then lives all at once, not a sequence of steps a CPU executes. Concurrent statements run together and in no particular order; an assignment is a permanent wire, not a stored update; a loop builds repeated hardware rather than iterating through time. Hold this mindset and the rest of the language stops being surprising.

With the mindset set, the foundations turn to the vocabulary that mindset uses — the design units that VHDL files are built from, and the std_logic type that models a real wire. The next lessons build that vocabulary up.