Comment by flohofwoe | Hacker News Reader

Comment by flohofwoe | Hacker News Reader

Parent Full thread

Because it's a Verilog implementation which is much closer to a software CPU emulator than the real thing (e.g. it has nothing to do with the original Z80 "transistor layout").

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.

Just because this is done in verilog doesn't make it emulation. It's probably just machine placed and routed. Almost everything is these days in digital design.

But look here, it's even doing a switch-case over the opcode, which is very typical for a software CPU emulator:

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...)

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.

Thanks a lot for the thorough explanation, much appreciated!

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.

It only looks like that if you treat it as a C-like programming language, which it is not. Unless specified otherwise, all the statements are "executed" in parallel by the synthesized logic. There is no emulation.

Reply on news.ycombinator.com