Here’s how the ISA form factor is being re-used in my latest project. The project is to build a computer using an ISA backplane, that can fit into a regular case and use a typical PC power supply. The ISA bus is not being used verbatium. Instead a 90% incompatible bus is being adopted. The plan is to use a 32-bit multiplexed address then data bus. This frees up some signal space on the bus. Pins 81 to 88 might be used to expand the addressing to 40 bits. The bus is intended to be run at 8MHz, with hopefully a maximum bandwidth of 32MB/s. That’s substantially faster than the standard ISA bus, about ¼ PCI bus speed, and a whole bunch slower than PCI express. Why not use a more recent standard? (It’s an eventual goal). They’re closed or overly complex. I had a quick look at the RapidIO standard, but after reading about 50 of 600 pages decided to pursue another direction. There’s all kinds of protocol behind modern serial bus standards. That’s okay if you’re a professional engineer and have time to learn the standard. But it’s a bit much for hobby use IMO. I want to be able to get something working next week, not next year.
Currently there’s a design for a console I/O board, with keyboard, mouse, audio, and video interfaces.

For a quick and dirty bus setup, what about the S100 bus?
http://www.s100computers.com

Yes, S100 is very appealing. There’s a lot of good info at the site.
The first version of the schematics was for the S100 bus, but then I wanted a wider address / data path available, so it ends up being incompatible anyway. I plan on running the bus at 3.3v (or possibly 1.8v) so the termination on the S100 bus might need adjustment.
Other factors made me alter direction. (I already have a PC case and power-supply). I may change direction again in the future and use something like PCI express (PCIX x16) to get the performance. It would likely be my own incompatible serial protocol. Coming up with my own PCI express core is somewhat daunting.
I want a bus that can handle 64-bit address and data. That can be done by running two separate address latch cycles and two data cycles across 32 pins.
I’m somewhat hesitant to connect the FPGA pins directly to the bus and have them going through buffers that can take up to 5v. I worry about damaging the FPGA with insertion / removal of boards in the system. FPGAs can be on the expensive side. Buffer chips are inexpensive. The drawback is the buffers have time specs that might limit the bus performance.

The bus signals are generated in the master FPGA using an 80MHz (x10) clock. (Not sure about the following idea) For one clock cycle after the address should be latched, the complement of the address is placed on the bus to help discharge the bus before data is placed on it.

STD bus (either STD-80 or STD-32) might be another good choice. ("STD" stands for "simple to design," not "standard.")

I spent some more time looking at gigabit serial transceivers available in an FPGA to implement a bus.
Using a 1.2GHz clock, 90 bits need to be transferred. 1.2Ghz / 90 (x4 since 4 bytes are being transferred) = 53.3MB/s. 90 bits comes from encoding 32 address,32 data (64 bits) and 8 control in an 8/10b encoding. 53MB/s isn’t too shabby for a serial transfer. The way to get more bandwidth is to use more lanes. However, there are only eight transceivers in the FPGA. Assuming we want to both send and receive data that leaves four for each direction. This works out to three data lanes plus one clock. So, the max transfer rate would work out to be 3x53.3 = 160MB/s.
It turns out the FPGA carrier board doesn’t make the gigabit transceivers available on the connector. So, DDR2 style serial must be used. DDR2 is running with a 320MHz clock is still plenty fast. 640Mb/s per channel, 3 channels.

I changed the VGA output connection to HDMI. HDMI requires fewer pins on the FPGA, and offers 24-bit color instead of the 12-bit color that was present.
Added a couple of TMDS transceivers to the board and freed up some pins on the bus so that several serial channels can be implemented. There is now only a single IRQ* line to the cpu. The cpu runs an INT ack cycle upon receiving the IRQ and expects devices to place an IRQ signal on the data bus. Effectively the data bus is being used as the source of irq signals. There weren’t enough pins on the FPGA board to have separate interrupt lines.
This is now version two of the board. The first version not having serial channels. If the serial channels can be made to work, then perhaps the entire parallel bus will be dropped and replaced with serial channels.
Finally figured out how to do ground and power layers in KiCad.

> For one clock cycle after the address should be latched, the complement of the address is placed on the bus to help discharge the bus before data is placed on it.

Not sure this is a great idea, although it might do no harm. Depending on the drivers and the bus, it might make sense to drive all-high or all-low, in preparation for the next value.

True. The chance that it would hinder is just as much as the chance that it would help, if the next value is not known yet. The only way to help would be if you charged the bus to a state between 0 and 1 so it's less of a leap to either one; but logic inputs don't tend to like to be held at invalid states for any longer than the normal transition times. I'd say just leave it be.

Okay I have removed the flip from the bus control logic. I’m wondering what I can get away with in terms of a parallel serial bus. For example, PCIe pairs a clock line and data line together for every data line. This seems a bit wasteful to me, although it’s probably necessary to get the performance out of it. I’ve got the bus setup to use an HDMI style transfer with three data lines transferred along with a single clock line. I’m wondering if I can increase the number of data lines making the bus more parallel without adding additional clock lines. The bus would be running slightly slower to compensate. In any case more signal space was freed up on the bus by reducing the bus master acknowledge signals to an encoded signal. There’s enough room now for four, three-bit serial channels. Although there’s room for the channels, the FPGA board doesn’t have enough I/O’s to support more than two channels.

It just occurred to me that a board with blinky lights or other I/O on it is needed for testing.
I’ve been trying to pack the FPGA which about 50% full, full of features. One issue is the number of pins available. Been thinking of trying to reduce the number of signals required for bus mastering. There are currently seven possible master request lines and a three bit acknowledge line. This uses a lot of lines (10) on the FPGA. It would be nice if there were a way to reduce this.

?? "Parallel serial" sounds like a contradiction of terms.


Is that to get away from problems with skew? It's interesting that there are serial interfaces (like SATA 3.0 at 6 Gbit/s, or SATA Express at 16 Gbit/s) that are so fast in spite of being serial, apparently because there's no skew between lines of a parallel interface, ie, no problems with all bits of a parallel interface arriving at slightly different times. I have not looked into the details.

Yes, that's exactly the historical development. Serial lines carried no clock, needing tight frequency control and phase recovery, whereas parallel busses need a clock and a correspondingly low skew. It turns out that a suitable serial protocol which carries clock information can run a lot faster. The likes of HDMI push that slightly, but they do need skew control. It might be that such protocols include training periods and retraining periods so the receiver can adjust to the transmitter and the line conditions. This makes them far from simple!

And they're typically closed standards as well.

The HDMI receiver by Digilent has a 32 entry fifo for deskewing the data inputs. So, they can be off by several clocks between bits. The bus deskewing is a feature that appealed to me. When used for a communication bus this adds several clock cycles to the turn-around though.
There’s a 15us memory refresh signal on the bus. That’s almost like a 30us horizontal sync signal, so I figured I’d try using that as a synchronization signal. IIRC the IP core syncs the signals up using vertical sync, so it’s adjusting the skew every 16ms. I would think that the bus skew in the system would remain relatively constant. It shouldn’t be a big issue to generate a fake sync for deskew. There may be a need to send dummy data over the bus for a few frames to train the deskew logic. This might have to be done for each slot on the bus.
For software there’s already a three second startup delay coded in the boot to accommodate the training and initialization of devices like the dram before they can be used. The three seconds is also to allow me time to press a button to trigger debugging.
With a little bit of ingenuity, it might be possible to hook a monitor up to the bus to allow monitoring for debug.
At the moment things are bit moot as there aren’t enough signals available from the FPGA board. It looks like I first have to learn how to solder BGA parts (so I can build my own board with enough I/Os).

I was just looking at PCIe again, and it seems my memory failed me again . The PCIe standard only uses a single reference clock, not a clock for each lane. There is just one clock for all the lanes.

Having a fast general purpose wide extenal bus might not be the best idea in my mind.
The old style computers like the PDP-8 had a I/O bus and memory bus model and did the
big iron at the time. The PDP-11 and the 8 bit CPU's had the simple bus design.
Current computers now have a dirty bus interface with 8086 history. Dynamic ram also
takes a few cycles now to get data in/out. Do you want a super computer(1970) or
game machine like windows XYZ or some sort of networked computing cluster like
'DEEP THOUGHT' HG2G. For speed you can only pick one, and design the best bus for that.
My view point is software designed to memory bloated with concepts from the 1970's
and virtual memory is a good thing. That also gives a different memory access model than
just a simple CPU would imply.Food for thought.

I want to use it for general use and for experimentation. It must be fast enough to support modern peripherals (SATA etc). Also wanted for communication between cpu's experimenting with machine learning eventually.

Updated the schematics for the project.
Worked on the Open Peripheral Connect (OPC) bus, which is what I started calling the serial bus. It uses a 12/14b encoding to transfer 36-bits on a 3-bit wide lane, plus clock. In theory it can get up to 321MB/s for the lane. About 1/3 the speed of PCIe. There’s room for three lanes on the connector, so three different bus masters can be using the bus at the same time. Each lane and read/write has it’s own clock so the masters can communicate at different clock rates. The FPGA maxes out at about 1000MHz for DDR type signalling. Inside the FPGA the serial gets converted to a parallel bus running at 71MHz (1000/14). I hope to clock the cpu at that rate.
Updating the HDMI RTL code to support the bus was pretty much a no-brainer. Much of the code was just a matter of changing a few constants. As per usual I cloned the code then modified the copy leaving the original intact. This is all vaporware at the moment there’s no real hardware.

The text output screen has a bug in it. What are supposed to be the leftmost two columns are displaying on the right-hand side of the screen. If I didn’t know better I’d say calculating the display address is off.
I think it has to do with the horizontal counter reset position relative to sync. It looks like it sets the counter to zero a couple of character times too soon. It’s a fiddly thing so I’ve left it to be fixed later.

Calculating the addressing is pretty simple, I don’t see how it could be off:

It’s just the base address of the screen plus rowcol (row times column accumulated) plus the column. Rowcol just increments by the number of columns every time a row is finished. nvp = next vertical pixel

Column is reset to zero when hctr is zero, otherwise it just increments when drawing a scanline of the character is finished. nhp = next horizontal pixel

The text controller is the same basic controller I used for a few years now, varying in quality of output as minor changes have been made.