The schematics are nearly done. I’ve finished all of them except the memory/device subsystem, which is proving to be difficult. Unlike the registers and all the other machine components, the RAM and the USB interface don’t use a clock. Instead, they have a write-enable signal that causes data to be written the instant the signal is asserted. That means I need to take extra care to prevent the write-enable signal from being momentarily asserted while the state of the machine is changing from one instruction to the next– something that’s not necessary for clocked components.

The common strategy I’ve seen is to combine these kinds of write-enable signals with another signal that’s guaranteed to be asserted only when the write-enable signal is sure to be valid. Typically, this is the clock signal itself, or something derived from the clock signal. For example, if the write-enable signal is active low, it can be OR-ed with the clock signal, and the result will only be low if write-enable is asserted and it’s the second (low) half of the clock cycle. This allows the write-enable signal to temporarily take on invalid values during the first half of the clock cycle without harm.

I did a static timing analysis, based on my schematics and the chip datasheets, and in the worst case it will be 233ns from the start of a clock cycle until the write-enable signal and memory address are guaranteed valid. If I use the clock signal to combine with the write-enable signal, then the clock period must be at least twice 233ns, so 466ns, or 2.14MHz. I’d like to go faster than that.

My clock module also generates a signal called Q1, that lags the main clock (Q0) by a quarter cycle. By OR-ing together Q0, Q1, and write-enable, the result will only be low if write-enable is asserted and it’s last quarter of the clock cycle. That implies a limit of 233ns for three-quarters of the clock cycle, so 310ns for the whole cycle, or 3.22MHz. That’s a little better.

Unfortunately, using Q1 and Q0 to mask write-enable until the last quarter-cycle causes problems with the USB inteface. The USBMOD4 needs to have its read-enable input gated as well, because reading actually changes the state of the device by advancing its internal FIFO. Once read-enable is asserted, it can take up to 50ns for the USBMOD4 to put valid data on the output pins. Data must then pass through the 74LS245 bus driver (40ns), and arrive at the destination register 20ns before the end of the clock cycle to observe the setup time requirements. Therefore the quarter cycle must be at least 50 + 40 + 20 = 110ns, so 440ns for the whole cycle, or 2.27MHz. That’s hardly any better than the 2.14MHz achieved by using Q0 alone and ignoring Q1.

So for two different reasons, it appears that the machine will be limited to a top speed of 2MHz. With some redesigning, I could probably speed that up, but I’m more interested in just getting it working right now than in getting the fastest possible performance. It’s entirely likely that in practice I’ll be able to run faster than 2MHz, since all of my numbers are the worst-case figures from the datasheets. The listed “typical” numbers are generally about 1.5x faster than worst-case, so it might be possible to run as fast as 3MHz with the current design.

For the curious, the time-limiting path from beginning of a clock cycle to valid read/write-enable and memory address is:

Follow up: After a more careful reading of the datasheets, things aren’t quite as bad as I’d first thought when combining Q1 and Q0 to mask the enable signals to the last quarter clock cycle. First, the worst-case data propagation delay for the 74LS245 is only 12ns, not 40. The 40ns figure is for the output-enable signal on the ‘245, which should already be set by the time the data is coming through. Second, the setup time at the data registers is actually 15ns, not 20. Add up the 50ns delay from the USBMOD4, 12ns at the ‘245 bus driver, and 15ns setup time, and you get 77ns. Coincidentally, that’s precisely the amount of time allowed by a 233ns time for three-quarters of the clock. So the limitation imposed to guarantee valid read-write/enable signals exactly matches the limitation imposed to guarantee valid data read from the USBMOD4, at a clock period of 310ns for the whole cycle, or 3.22MHz.