The Programming Model
Verilog is not ordinary software with unusual keywords. It is a language for describing structure: Boolean functions, registers, wires, clocks, memories, pipelines, and the places where state can change.
That makes it a programming language in a very practical sense. A Verilog design still has modules, names, interfaces, state, constraints, and behavior. The difference is that allocation and timing are part of the program instead of hidden under a runtime.
What Changes From Application Code
- Allocation: hardware resources are reserved by the design instead of created later by
malloc,new, or a garbage collector. - Timing: clock boundaries, combinational paths, setup, hold, and pipeline latency are part of correctness.
- Parallelism: independent always blocks, modules, and data paths can be active in the same cycle.
- Interfaces: FIFOs, buses, handshakes, SerDes links, and clock-domain crossings are not library details; they are program structure.
- State: registers and memories have explicit owners, update points, and reset or initialization behavior.
Why It Matters For Software People
Streaming, low-latency paths, time-series processing, pattern matching, and model updates all expose the same question: where does the work live, when is data valid, and how does the next stage observe it?
Sequential application code can express those systems, but it often hides the schedule behind threads, queues, callbacks, locks, and runtime behavior. Verilog makes the schedule harder to avoid. That is uncomfortable, but it also makes some important boundaries readable.
The Reconfiguration Gap
The original post was also about wanting an application-style edit/run loop for hardware-shaped computation: change a piece of the design, install it quickly, and keep the larger machine alive.
Conventional FPGA workflows do not generally make that feel like editing a running application. Tool runtimes, placement, routing, static resource allocation, and partial-reconfiguration constraints all get in the way. That gap is one reason the Cartilage work explores visible local regions and reconfiguration ports.
Cartilage Visual Language
The 32 Cartilage cell-role codes are a compact body-type alphabet: reconfiguration port, cross, constants, four wire orientations, and six MUX modes in four orientations. The Cartilage Visual Language article shows the rendered key and decodes all 32 codes.
Related Experiment Path
The cellular automata experiments are a related way to read computation as local state and local rules. They are not Verilog, but they expose the same habit: look at what each cell, wire, region, or stage is allowed to do next.