You have been writing concurrent assignments since your first HDL statement. The binary lesson handed you one and told you to read it as solder; Anatomy of a Component filled whole architectures with them. This topic makes the statement itself the subject. Everything between an architecture's begin and its end, everything inside a module body, is concurrent territory: a list of circuits that are all active at once. This lesson pins down how the plain assignment works, and proves the claim those earlier lessons made in passing: the order of statements in the file changes nothing.
A concurrent assignment has two sides with different jobs:
siren <= any_zone and armed;
The right side is a circuit: any expression built from the operators of Operators and Expressions, reading as many signals as it needs. The left side is one wire, and this statement is its only legal driver: the one-driver rule from Anatomy of a Component. The statement never starts and never finishes: whenever any signal on the right changes, the expression recomputes and the wire follows.
CAUTION
Common Mistake: assigning to the same signal twice, expecting the second statement to win. There is no "second"; there is no order. Two assignments are two drivers soldered to one wire, fighting, and the waveform shows the fight as 'X'.
Real designs are chains: one assignment's output feeds the next one's input. To build a chain you need wires that are neither ports nor constants: internal signals, declared the way Signals and Data Types showed you.
The declaration sits between the architecture's is and its begin:
signal any_zone : std_logic;
Here is the complete logic of this lesson's example, a four-zone burglar alarm. The zones are ORed into one named wire, and that wire fans out to two consumers:
any_zone <= zone(3) or zone(2) or zone(1) or zone(0);
lamp <= any_zone;
siren <= any_zone and armed;
Trace a zone tripping: a bit of zone goes high, the OR recomputes, and any_zone rises. Both consumers react: the lamp directly, the siren only if armed is high. The intermediate signal is computed once and read twice; that's fan-out doing the work of two copies of the OR gate. How the simulator schedules that ripple through the chain is the subject of Simulation Semantics. For now it's enough that the whole chain settles together.
Now the proof. Those three statements describe three circuits connected by wires. Nothing about the wiring depends on which statement you typed first, so this version describes the identical hardware:
siren <= any_zone and armed;
lamp <= any_zone;
any_zone <= zone(3) or zone(2) or zone(1) or zone(0);
Read it as software and it's broken: any_zone is "used before it's set". But nothing executes top to bottom here. The tools first read all the statements and connect the wires; only then does time start. The file is a parts list, not a recipe, and a parts list in any order builds the same machine. When you read someone else's design, this is the habit to build: don't read top to bottom. Pick the output you care about, find its one driver, and follow the wires backward.
One more concurrent statement has been hiding in plain sight: the dut instantiation block every testbench uses to place your design (One Interface, Many Implementations showed it). Instantiation is just another part on the list; you'll write your own in Hierarchy and Reuse. And there is a second domain where statements do have order: procedural blocks, the subject of Procedural Blocks. Everything in this topic lives outside them.
The example panel on the right holds the alarm twice: alarm_in_order lists the statements cause to effect, alarm_shuffled lists the consumers first and the driver of any_zone last. Open both file tabs and compare: same three statements, opposite order. One testbench drives both copies with the same zones and arming switch. In the waveform, ord_lamp/ord_siren and shuf_lamp/shuf_siren are identical on every step: the lamp follows the zones even while disarmed, the sirens only sound once armed is high. Then open the Netlist tab and flip between the two file tabs. The tools built the same gates from both files.
sync-content --examples to generate.