Post B81hiNvlZP1DGPR224 by astraleureka@social.treehouse.systems
(DIR) More posts by astraleureka@social.treehouse.systems
(DIR) Post #B81f2QSbZh9H2Rexbk by brouhaha@mastodon.social
0 likes, 0 repeats
I'm gonna the next two to eight hours debugging one of my personal programming projects. If debugging goes well, maybe also adding features, but that's far less important.It's a Z80 simulator in C++, but it is low-performance and not intended for "production" use. There are much better existing simulators for that.#Z80 #simulator #retrocomputing1/
(DIR) Post #B81f2Qyrdkx8eUkitE by brouhaha@mastodon.social
0 likes, 0 repeats
This simulator is intended only to test my ideas for the parallel instruction decoding and pipelining of the high-performance VHDL Z80 core I've been designing. The target is to approach 1 clock per instruction for most instructions. Two clocks for instructions that do a read/modify/write of memory. One clock per byte for block compare (CPI, CPIR, CPD, CPDR). Two clock per byte of block move, input, and output (LDI, LDIR, INI, INIR, OTI, OTIR, and their decrement versions).2/
(DIR) Post #B81f2RFWdoHRUAY1rM by brouhaha@mastodon.social
0 likes, 0 repeats
Except, all of those block instructions will also cause a one cycle pipeline stall. BUT... for the repeating forms of the instruction, that's one cycle for the entire repeated operation, or if an interrupt intervenes, so that repeated operations take 2n+1 cycles, not 3n.Branches taken flush the prefetch queue and usually cause a stall, but I'll need the simulation (either the C++ or VHDL one) to determine the typical number of cycles of stall.3/
(DIR) Post #B81f2RaRO30iX2KjSa by brouhaha@mastodon.social
0 likes, 0 repeats
Unconditional branches (JP or JR, not CALL or RET) may have one fewer stall cycle than conditional branches taken, because the unconditional branch happens in the instruction decoder, not the execute stage of the pipeline.Prefetch flushes are less expensive than one might think, because the prefetch is done four bytes per cycle from 32-bit memory or cache.Anyhow, the design is still evolving, so the final, debugged core may differ from this description.4/
(DIR) Post #B81f2RsWIpTLR6nAdk by brouhaha@mastodon.social
0 likes, 0 repeats
I'm hoping to get over 200 MHz execution (so possibly over 100M instructions per second) from an AMD/Xilinx Artix-7 FPGA, but that may be overly optimistic.For comparison, Z80 instructions take a minimum of four clocks, and up to 23, while my core should still execute that Z80 23-clock instruction in one clock cycle (two if memory read/modify/write). Average clocks per instruction should well under three, maybe even under two.5/
(DIR) Post #B81f2S8TLWEUEaFuVM by astraleureka@social.treehouse.systems
0 likes, 0 repeats
@brouhaha 200MHz would be incredibly snappy, especially with your target CPI. it's been a while since I looked at the specs, but IIRC the eZ80 topped out at 50MHz and only a handful of instructions could complete in a single cycle, with typical latencies between 2-6 clocks and worst cases (esp. the 24 bit variants) upwards of 8-10 clocks. would you be releasing this core publicly?
(DIR) Post #B81f2SyaDlusqCdWjI by brouhaha@mastodon.social
0 likes, 0 repeats
The performance improvements come from:* 32-bit memory for prefetch (only 8 and 16 but accesses for operands)* single-cycle instruction decode (even for four-byte instructions)* PC and 16-bit incrementer/adder in instruction decoder, not register file* 16-bit adder for effective address computation* 16 bits wide ALU in data path* 16-bit wide register file* BC, DE, HL, SP, IX, IY registers each have their own incrementer/decrementer by 1/2* RISC-like execution pipeline6/
(DIR) Post #B81f2TrWvTrvacLPNI by brouhaha@mastodon.social
0 likes, 0 repeats
Zilog did parts of this in the Z380 and eZ80, which do have lower instruction cycle counts than the earlier Z80/Z180/Z280/Z800. By using the techniques I mentioned, I expect to do significantly better even than the Z380 and eZ80, though I am only initially implementing the Z80 and Z180 instructions.7/
(DIR) Post #B81f2Uvox0tYuDMLhY by brouhaha@mastodon.social
0 likes, 0 repeats
Writing to addresses that are contained in the prefetch queue or execution pipeline will also cause a queue and pipeline flush, because self-modifying code is unfortunately not uncommon in 8080 and Z80 code.8/
(DIR) Post #B81f2VmHnwrXWvuFTk by brouhaha@mastodon.social
0 likes, 0 repeats
The core also has separate instruction and data busses, so it can be run as a Harvard architecture machine. In an FPGA, dual-port block RAM can support simultaneous instruction fetch and operand read/write from the same cache or memory block. For memory outside that, a bus multiplexer will be provided, prioritizing the operand data accesses over instruction fetches.9/
(DIR) Post #B81f2WvXX1rJ5vF9Xc by brouhaha@mastodon.social
0 likes, 0 repeats
After I get everything else working, I may consider trying to make LDIR and LDDR move four bytes per pair of bus cycles rather than one. Obviously that would involve widening the operand read/write data bus to 32-bits, which should be no big deal since the instruction data bus is already 32 bits.This would depend on the bus and memory supporting djngle-cycle unaligned access, which is already an optional bus feature.10/
(DIR) Post #B81f2YzrpuVbVvHdZ2 by brouhaha@mastodon.social
0 likes, 0 repeats
CPIR/CPDR could possibly be sped up that way as well.11/
(DIR) Post #B81hiNAGQ11Mt5D5zU by brouhaha@mastodon.social
0 likes, 0 repeats
@astraleureka I may try to make some money selling specific system upgrade boards first, but I do intend to release it under an open license after I fall to make any money on it.
(DIR) Post #B81hiNekafPKPdTRVg by brouhaha@mastodon.social
0 likes, 0 repeats
@astraleureka In the unlikely event that I do make money on it, I'll still plan for an open release.
(DIR) Post #B81hiNvlZP1DGPR224 by astraleureka@social.treehouse.systems
0 likes, 0 repeats
@brouhaha it sounds like it'd be an appealing upgrade for anybody still running performance-sensitive workloads on a z80-based platform, although I gotta wonder how many of those are still out there at this point (or more specifically, those which aren't amenable to emulation and haven't been moved to a newer underlying architecture)
(DIR) Post #B81hiOiKeprnh29ojQ by brouhaha@mastodon.social
0 likes, 0 repeats
@astraleureka As usual, the prospect of making any money is an "it would be nice" objective, but nowhere near the top objectives, which are:* increase my hardware design skills* have fun
(DIR) Post #B821wnjqPdQqRU0hBg by brouhaha@mastodon.social
0 likes, 0 repeats
@astraleureka I don't expect it to seriously appeal to anyone other than retrocomputing hobbyists.If I'm reasonably successful with the FPGA, it would be really fun to tape out an ASIC, using a shuttle run.For either FPGA or ASIC, I consider it highly important to have AT LEAST 64K of on-chip RAM, and ideally 512K or 1M, supporting some of the existing bank-switching schemes.For a bank-switched system, changes to the map have to force a prefetch and pipeline flush (possibly conditional).