Here is a first draft. Anything wrong/missing architecturally?
Ethernet Bus Interface Board
2013-12-21 aek
+--------------+
| 4Mx16 BBSRAM |
+------+ | AS6C1616 |
| | +------+-------+
LEDs - + ARM | |
SD -- + uCtl | JTAG +------+-------+
USB -- + +-----------+ | -> Simulated Peripheral Registers
ENET - + +-----------+ FPGA | Bus Monitor / Adr Mapper
SER?-- | | ARM intf | | Bus Master Controler
+------+ +------+-------+
|
+------+-------+
| |
| 5v<->3.3v |
| Bus Buffers |
+--------------+
The entire address space of the host is maintained in the SRAM
ARM performs DMA by placing the data to be transfered where it
will appear on the host. If the local memory is the system memory,
we're done, just clean up the DMA registers. If not the FPGA does DMA
to synchronize local memory with core. 3 cycle data break side effects
will have to be investigated. Does any driver watch the value of ADR,WC
in memory while a DMA is occurring?
Bus transactions are snooped to maintain consistency on the PDP-8
where some core memory is on the Omnibus. This may work OK on small
11's, too but won't be the right thing to do on an 11/70 where
memory transactions occur that are invisible to the Unibus.
It should be possible to simulate all the front panel functions of
an Omnibus machine and to capture all of the state in real time for
all of the major registers from watching Omnibus transactions.
It is also possible to adapt the board to be a dedicated bus analyzer or
soft front panel or peripheral/ memory exerciser for any supported bus
architecture.
All registers and supported peripherals are obviously soft. The configuration
is stored on the SD, along with the FPGA bitstream. Everything should be
reconfigurable through transactions across the Ethernet by updating files on
the SD card.
Battery-backed SRAM was chosen over FRAM because of cost.
I'm not sure if a local serial interface would be that useful other than
for debugging messages.
There are a small number of LEDs hung off of a STP08DP05
Small local SPI NOVRAM for configuration/bitstream storage? SD hot-swap?
Larger local storage? Is performance an issue on Omnibus/Qbus/Unibus CPUs?
They are slow enough busses that they'll saturate in the couple MB/sec range.
Write-through track caching in SRAM?
Block mode on QBus
.. and on and on
Ethernet Peripheral Controller
This is the mirror of the Bus Interface Board. It provides block-level data
that the Bus Interface sends into the computer. In its simplest form, there
is no hardware at all, it is just a simulation running on a computer on the
network. The second simplest is hardware that understands the Ethernet
peripheral command protocol but has a simple enough interface to the physical
device that no FPGA is required. It may also not need any local storage. The
most complicated could look like the Bus Interface Board, with local SRAM and
FPGA. A Diskferret-like forensic disk interface would be an example of this.