UNIBUS <-> PCI bridge

On Fri, 07 Aug 2009 07:29:19 +0200 Philipp Hachtmann <hachti at hachti.de> wrote: If we take a 18 bit PDP like the PDP-11/34 everything lives on the UniBus. Everything has at max. 18 bit addresses. No DMA problems here. Every UniBus master can reach all memory when doing DMA. Now imagin somthing like a PDP-11/70 or a VAX. The CPU has more then 18 address bits and memory lives on another bus then the UniBus. The OS needs the data somewhere in memory. If the bus bridge does no address translation a UniBus peripheral can reach only the lower 256 kB of RAM. So if output has to happen the OS needs to copy the data somewhere into the lower 256 kB RAM. Then it needs to initiate the I/O. If this has finished (interrupt) it needs to copy possible input from the lower 256 kB to somewhere else in RAM where the OS needs it. This is ugly. All data needs to be touched twice from the CPU. The OS has to reserve a region of _continious,_physical_ RAM that can be seen by the UniBus. This may be difficould to archieve for the OS or its memory management. What 22 bit PDP-11s and VAXen do is somthing like this: The UniBus bridge has an I/O Memory Management Unit build in. DEC calls it the UniBus map. The UniBus map has a page table. If a UniBus master initiates a memory access the UniBus map takes the addess issued by the bus master. It splits the UniBus address in a lower and upper part to construct the CPU side address. The lower part is 9 bits (= 512 bytes, the VAX page size). These lower 9 bits are copied 1:1 from the UniBus address into the CPU side address. The upper 9 bits of the UniBus address are used as an index into the IOMMU page table. The page table entry contains some permission bits (read, write, ...) and the upper 23 bits of the 32 bit CPU address. This way a 18 bit UniBus address is translated into a 32 bit CPU address. This is very elegant. If I/O has to be done the OS programms the UniBus map with the apropriate translation and initiates the I/O. Due to the address translation, that happens invisible to the UniBus device, a UniBus master DMA can reach the full range of the 32 bit CPU address space. It also enables scatter gather DMA for UniBus peripherals that don't support it. The UniBus peripheral may see only a single continious UniBus DMA memory target. But the UniBus map can split up this into several regions. If there is no valid entry in the page table of the UniBus map main memory is protected against UniBus peripherals go amok, because the bus bridge will not allow access from any UniBus device into main memory. UniBus access must be granted explicitely and can be limited to ceartin regions. Therefore: If you design a PCI-UniBus bridge _*PLEASE*_ implement a proper IOMMU / UniBus map. Everything else will be a ugly kludge. Just copy the VAX UniBus map and you are done. It does exactely what is needed. That would be a DMA bounce buffer in hardware. This is still ugly and defeats the reason for DMA. You will, as it simplifies your hardware design. But it will be a nightmare to the OS programmer that has to fight with it writing a device driver for it. PeeCees suffered from this in the ISA bus era. Now PeeCees suffering from the same problem as PeeCee CPUs have gone 64 bit but PCI is still 32 bit and there is no proper IOMMU in a PeeCee PCI host bridge. Have a look into Suns or Alphas. They have PCI host bridges with IOMMU build in. -- tsch??, Jochen Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/