 |
|
|
|
Suitably smart programming and a problem that suits the hardware. I doubt there are many of the latter. A Z80 has a 4-bit ALU (https://en.wikipedia.org/wiki/Zilog_Z80#Microarchitecture), making even integer addition take quite a few cycles (15 for 16-bit addition, reading http://www.z80.info/z80time.txt) And then there’s the clock speed difference. The first Pentium III ran at 450MHz, the fastest Z80 at 50MHz (https://en.wikipedia.org/wiki/Zilog_eZ80) I think those two combined already will cost you a factor of around 100 in speed versus that pipelined Z80, much more versus a Z80 proper. Things get worse if you want to add or subtract 32- or 64-bit integers (another factor of 2 or 4, ballpark) If you want to do integer multiplication and division of any size and all floating point operations you will have to do those in software, and likely lose whatever speed advantage you might still have. O, and each core will be limited to 64kB of memory. Those interconnects better be fast and use DMA, so you can keep computing while you shuffle data around. |
|
|
It could happen at any time to the 65C02. The Z80 was only EOLed a few weeks ago because they couldn’t get wafers from their fab any more. Any chip on an old process is at risk of this.
|
|
|
Any Z80 based (not eZ80) TI calculators on the market today have the Z80 core built into an ASIC instead of a discrete chip, meaning that they wouldn’t be impacted by parts availability.
|
|
|
So many good machines: the Amstrad CPC range, a whole slew of Sega consoles, the early MSX stuff and of course the Tatung Einstein. 3 inch disk machines of the world unite!
|
|
|
I couldn’t help but notice that the circuit layout looks like a uniform gate array rather something resembling a custom layout you usually see in die photos.
|
|
|
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. |
|
|
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. |
|
|
> Is this considered a major bottleneck? No, because an ALU instructions with a register as source is already running as fast as possible (at 4 clock cycles, which is the duration of an opcode fetch 'machine cycle'). Or from a different perspective: an 8-bit ALU wouldn't have made math instructions faster, but would have cost twice as many transistors. The 4-bit ALU is just an internal implementation detail that isn't visible to the outside (except maybe through the existence of the half-carry flag which indicated a carry from the lower into the higher nibble). And if you want a CPU replacement that plugs directly into old home computers, the CPU needs to have the original instruction timing, otherwise software that depends on 'cycle counting' won't work (probably less of an issue on the ZX Spectrum though because the Speccy didn't have a programmable video hardware like for instance the Amstrad CPC). The eZ80 is a modernised and more efficient design, with (among other things) a wider ALU: https://en.wikipedia.org/wiki/Zilog_eZ80. Not an option for keeping old home computers alive though, for this you'd want an exact Z80 clone with the original timings and undocumented behaviour. |
|
|
That's the expected clock rate for the TT07 run... but Tiny Tapeout designs only have 8 in, 8 out, and 8 bidirectional IOs (plus a reset and clock input) available, so they're using a multiplexing strategy where the Z80 clock runs at 1/4 of the base clock rate and alternates between control signals, A0-A7, control signals, and A8-A15 on the OUT pins: https://github.com/rejunity/z80-open-silicon/blob/68438f0019... So you'd get an effective 12.5MHz Z80 clock and need a bit of external logic to demultiplex the full IO interface. Still not too shabby! The goal (per the project README) appears to be to prototype with TT07 and then look into taping out standalone with ChipIgnite in QFN44 and DIP40 packages (which would be able to have the full traditional Z80 bus interface and run at the full clock rate). |
|
|
Because it’s easy to ‘cache’ the entire memory of the host system, it’s better described as a new computer that only slows down to access the memory locations that affect I/O (video, audio, keyboard, I/O ports, etc.) https://www.e-basteln.de/computing/65f02/65f02/: “The idea is to use this as a “universal” accelerator for 6502 and 65C02-based host computers – just plug it into the CPU socket. The only thing the FPGA board needs to know about its host is the memory map: Where does the host have memory-mapped I/O? Up to 16 different memory maps can be stored in the FPGA, and selected via a mini DIP switch. Upon power-on, the 65F02 grabs the complete RAM and ROM content from the host and copies it into the on-chip RAM, except for the I/O area. Then the CPU gets going, using the internal memory at 100 MHz for all bus accesses except for any I/O addresses – for these, the internal CPU pauses, and an external bus cycle is started at whatever the external clock speed is.” |
|
|
eBay says a Chinese Z80 clone is less than $4 with free shipping. This isn’t even going to be competitive with lower end FPGAs. It’s more of a fun “why not” type of project.
|
The tools look amazing as well. You'll won't design the next Intel CPU on that 130nm process but to think that the Z80 will fit on 0.064 mm2 is just amazing.
It's great that there will still be an alternative to the official chip now that it won't be manufactured any more.
Now I want that gorgeous mauve ceramic package with a gold-plated cover over the chip...
https://twitter.com/l_vanek/status/1783557817133039738/photo...
https://tinytapeout.com/