I copy basically the same test system from project to project plugging in a different CPU or other components every time. But much of the test system remains identical. This topic is to describe the test system. The test system acts as a host for many of my cores.

Added a config timeout to the system. A timeout signal was needed to force the data bus to all one’s if there was no response to the config circuit select. This is like a bus timeout but with a much shorter interval. A PCI style approach is now being used for device access, and PCI expects to read all one’s when reading the config info if the device is not available.

The config space for PCI is given a 256MB region of memory beginning at $D0000000 to $DFFFFFFF. The space is broken down into busses, devices, and functions with a 4kB config area reserved for each. When the system starts up the PCI config space is scanned for devices. This amounts to checking a 32-bit word spaced 32kB apart, 8192 addresses, to see whether it contains all ones or not.

I was just motoring along with updates today for PCI config space compatibility. Added to the list of devices with config spaces are the keyboard, uart, and interval timers. The frame buffer, text controller and sprite controller were done yesterday. While the code has been adapted for the config space I do not know yet if it works. It builds fine.

Still got a bunch of devices to go. It looks like the config space does not use up very many resources, approximately 100 LUTs per instance. And it should provide a level of software compatibility.

Updated the documentation for the corresponding modules. The interval timer docs were completely out of date. I completely re-wrote the timer core last year but forgot to update the docs. The timer module originally only supported four timers,, but now it supports up to 32 timers, each which can be 64-bits.

Still working on the PCI software compatibility for devices. Decided to implement “invisible” I/O bridge components rather than try to develop a PCI bridge. These bridges have no registers or configuration to them. They just pass through a 128-bit wide master bus to a 32 or 64-bit slave bus. So, the bridge transforms the bus width but does little else. A bridge adds two clock cycles to the IO access time. One to get from the master to the slave, and then one for a response of the slave back to the master. Since many I/O devices are much slower than the system there is little impact on performance.

Added an MMU as a PCI I/O device. The MMU is a simple mapping device. It has an internal mapping table rather than using a TLB and fetching from a table in main memory. The system can get away with this because system memory is very limited, 512 MB. The mapping table allows for 1024 64kB pages per address space or 64MB max per address space. An address space is thus limited to 1/8th of the RAM. Up to 64 address spaces are supported. This table uses 38 BRAMs or about 10% of the BRAM.

One issue is access to the mapping table before address maps are set up. The ROM and mapping table have specific physical addresses in the system. Unless some map entries are pre-set these devices would not be accessible, and the system would not be able to boot. This is handled by specifying a few entries to be defaulted in the mapping RAM on configuration and not allowing those entries to change. So, the last five of 1024 entries for all address spaces are set to point to the MMU table and the system ROM. These entries were setup by manually editing a ROM config file.

It helps to have documentation as a guide. Here is a table of system IO addresses and other information.

A very impressive list of peripherals! What's the meaning of the bridge numbers? Are some of these peripherals on the FPGA or are they all off-chip?

Yeah, there are more peripherals available than will usually fit on the chip. I spent quite a bit of time working on I/O devices. There is generally a faster development time for the I/O opposed to something like an CPU.

The bridge numbers are the number of the I/O bridge component that the device is routed through. The I/O bridges are in the FPGA chip. The peripheral controllers are all on the FPGA. But most peripherals are off-chip connected with I2C and SPI and other interfaces. Other peripherals are on-chip. For instance, there are four different video devices, but they all end up outputting to an HDMI port. Semaphores are exclusively on-chip, random number generator is on-chip, and Datetime core is on-chip too. The xbus bridge is used for external I/O but it is not currently used for anything. The I/O bridges are "invisible" pass-through bridges that modify the bus width appropriately for the peripheral device.
The bridges are connected to the processor bus / system bus which is 128-bits wide while most of the peripherals are 32-bit and a few are 64-bit.

Rough diagram of the system.