For instance here's the LD A,(DE) "instruction payload":
https://github.com/rejunity/z80-open-silicon/blob/974c7711b2...
And here's the same machine cycle in my software emulator:
https://github.com/floooh/chips/blob/bd1ecff58337574bb46eba5...
Both set the address bus to the content of the DE register (and at the same time the MREQ|RD pins need to be set somewhere to indicate a memory read to the outside world, in my emulator this happens in the _mread macro), and in the next clock cycle load the data bus into the A register.
What's interesting though is that the Verilog implementation doesn't seem to update the internal WZ register with DE+1, which makes me wonder if undocumented behaviour is correctly implemented, but maybe updating WZ is handled elsewhere (there are references to the WZ register in other places).
In the end, if it looks and feels like a Z80 from the outside (e.g. the right pins are active at the right time) the internal implementation doesn't matter.
https://github.com/rejunity/z80-open-silicon/blob/974c7711b2...
Instruction decoding on a real Z80 CPU doesn't work at all like that :)
A non-emulator-approach would probably use the reverse engineered Z80 netlist from visual6502.org to base the design on, no idea if this is even doable with modern chip design tooling(?)
If anything, the netlist is useful to verify the Verilog implementation (as is mentioned here in the readme: https://github.com/rejunity/z80-open-silicon?tab=readme-ov-f...)
Verilog isn't imperative code, to be executed one line after another in sequence. It's a description of combinatorial logic to be wired up to inputs and outputs, gated by a clock edge. Everything in the Verilog module "runs" at the same time, there's no jumping to a branch, there is instead logic to wire up one "casez" block or another to the relevant output signals. All the blocks are lit up, only one has its output selected to connect to the output wires.
The PLA block is more convenient to a hardware engineer laying out a CPU by hand. You can see everything together and trace execution easily. Downstream consequences of decode are done elsewhere. Upstream decode of control signals are done elsewhere. The Verilog is more convenient to a hardware engineer relying on tools to route logic: the Verilog does more than the PLA - it does the additional control signal inputs, and it does the downstream consequences like determining which register(s) are used on which register bus. It's laid out more like a software decode of the instruction bits because it's easier to think about groups of opcodes than individual ones.
In execution, though, they wind up doing very similar things.