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(?)
Instruction decoding on a real Z80 CPU works pretty much like that, as it happens. There's a big PLA table that takes the IR inputs and a handful of other control signals (like "is 0xED prefixed") and lights up output control signals to say what the instruction to be executed is. See https://static.righto.com/files/z80-pla-table.html for this table laid out nicely.
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.
That switch-case gets optimized and compiled down to logic gates by the synthesis tools. It'll be a different set of gates from the original netlist (which might also have used a more regular grid structure for this), but it won't be _that_ different. It's not somehow running this switch-case in software emulation on a different CPU instantiated in this design.
So what? A re-implementation of a CPU doesn't require the netlist to be equal. That would mean just moving to a new process node or tooling suddenly means your new brand new CPU is "software emulating" the old one just because it might do somethings slightly differently. A frankly ridiculous proposition.
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...)