... but they are not adapted for the function I want to design.
Let me explain.
I found an old collection of free FIFO samples and they come in all sizes, packages, geometries, signaling standards...They complete the pulls (IDT7132) and the eBay finds (384K×8, that's deeeeeep) so there should be a reference that matches my application.
After the turn of the century, I have had the chance to work for a famous company that use(d?) to build huge machines that simulate huge digital circuits at rather high speed. One of their defining features was the ability to store the value of each gate for the last thousands (and possibly more) cycles, which further speeds up development. It is easy to go back in time to identify the root cause of obscure bugs.
My intention is to add a similar "trace board" to the prototype, and even as an option for some later units. It would contain FIFOs to record the state of all the internal bus signals so they can be "replayed" or sent to a host computer.
It is rather easy to attach FIFOs to the internal buses but things become more complex around it. For example : how do you send these data to the host computer ? How do you let the host control the FIFOs ? And how do you manage FIFO overflow, does the part stop writing (and trigger a trap) or does it overwrite old states ? How is it possible to use the traces without a host computer ?
Then I realised that FIFOs are not the right memory type for this purpose. For example, FIFOs are adapted for the transmission of data from one clock domain to another. The trace board however works in two phases : record then replay. There is no need of two separate ports because they are not used at the same time.
Going further, I want it to "replay" the CPU states by reinjecting the captured data back to the buses (without triggering the latch signals). Magic happens : the P1B display can show the signals without external host intervention. And the host can access those stored states by using the P1B serial emit circuit.
Of course, the type of memory that can be read and written through the same IO pins is our old friend, the classic SRAM chip. The memory boards already use them so the same chips are reused. 64K/2=32K instructions trace depth should be enough for most cases, right ?
Now the question is how to generate the addresses. Well there are two cases : record and replay. I think I'll use a set of 2 up-down counters (remember the registers ?), MUXed depending on the state.
- the "record" counter counts up during each phase of the CPU cycle (to record the 2 instruction words and register values). This is not modifiable (but could be reset).
- the "replay" counter gets selected when entering the "replay" mode. At this moment, the value of the "record" counter gets written to the "replay" counter (so it catches the paused free-running counter) The up and down strobes come from P1A (keyboard or serial input) and the SRAM chips drive the buses so P1B can display the values and send them to the host.
Maybe there is enough room on later versions of P1B to hold the SRAM circuits, instead of the separate board. Or the trace functions can be grouped with the breakpoints comparators...
Anyway I hope you get the idea. It's pretty cool in fact :-)