In the source tree of the distribution, there are directories for the boards that I support – generally, these have the name of the board or some abbreviation of that; look at the files page or in the source tree to find these. Each board directory contains the specific files needed for that board; the generic parts are in the top level directory.
The top level source file in the hierarchy of VHDL that forms the PDP2011 systems is usually called top.vhd – which is different for each board, and thus a variant exists in each board directory. It contains the glue logic between the components surrounding the FPGA – memory, connectors, switches, and blinkenlights – and it instantiates the Unibus containing the system peripherals, the CPU and the MMU. In the instantiation of the Unibus component, you can configure many aspects of the system; what you can do with it is described below. Almost all attributes you can configure also have default values that allow you to omit anything you do not need – usually if you omit to configure something, it will not be included in the system; exceptions are those things that are likely to be required, like for instance the line clock, or those things that generally do no harm, like the blinkenlights register.
The configuration options described here are however also somewhat limited, for instance, it will not allow you to have more than 4 serial links, and also it will not allow you to have two of the same type of disk controller. If you want this, you’d have to change the unibus.vhd source – which is a bit beyond the scope of a howto, and requires you to have a deep understanding of VHDL and the structure of PDP11 systems and the PDP2011 implementation.
If you decide to have a go at making your own configuration, the easiest way is to start from a working configuration, and changing one thing at the time. And, unless you are sure you know what you’re doing, it is best not to touch anything that is not described here.
Look for the line in the unibus instantiation that sets the signal called ‘modelcode’.
pdp11: unibus port map( ... modelcode => 70, ... );
With this, you set the type of the system, and following from that, the type of CPU, MMU and whether or not an FPU will be available. The following model codes are available:
- 20; 11/20 system, no MMU, no FPU
- 34; 11/34 system, 18-bit MMU (2-bit ACF),FPU
- 44; 11/44 system, 22-bit MMU (2-bit ACF),FPU,Unibus map
- 45; 11/45 system, 18-bit MMU (3-bit ACF),FPU
- 70; 11/70 system, 22-bit MMU (3-bit ACF),FPU,Unibus map
- 94; 11/94 system, 22-bit MMU (2-bit ACF),FPU,Unibus map
Which system model you set makes a huge difference on the amount of FPGA resources that are needed to implement it. The 11/70 with it’s FPU is probably the biggest in terms of resources, and 11/20 the smallest – but there is also a marked difference between 11/34 and 11/45. But besides the resource consumption, there is also the question of software support to consider when choosing a system model; not every operating system necessarily needs the biggest system. Regarding speed, all are equal – unlike the real hardware, the PDP2011 systems all run at the same speed; there is no difference in the amount of MIPS or cycles-per-instruction, regardless of which model you choose.
Beyond that, there are several more subtle differences between the systems than suggested in this list; the original systems differed in many details, like exactly which additional instructions were available, or how the exact timing of interrupts would interact with the flow of instructions, which control registers were available to control the way the hardware would work or how it would report unusual conditions. For details, look in the cpu.vhd, mmu.vhd and cr.vhd files – this is where the main differences are implemented. In many cases, the modelcode is used in these files to set signals of the form have_X, where X is a specific attribute. As an example, whether or not the CPU will include the SOB instruction depends on the value of the have_sob signal. In the core, you will find many model codes that are not listed above, but these have not been fully tested, and also not all of these will produce a working system – most obviously those that refer to a non-Unibus system.
By default, the FPU is included for those system models that could optionally include it. This can be overridden however, by setting a signal named ‘have_fp’ in the unibus instantiation. A value of 0 will disable the FPU; a value of 1 will force its inclusion. Normally, you’d use this if you do not have enough FPGA resources to fit the FPU – it takes a lot of resources to include the FPU, and many systems include a software simulator that can replace it – even if not out-of-the-box, you can create systems that can do without the FPU hardware and still support floating point arithmetic; a good example of this is 2.11BSD. However, it’s also possible to create unlikely systems – like an 11/20 with an FPU; surprisingly, this will work with RT-11.
The following example creates an 11/70 without FPU:
pdp11: unibus port map( ... modelcode => 70, have_fp => 0, ... );
Serial lines (and the KL-11 like controllers that drive them) are defined with the have_kl signal. It can have values from 1 up to 4. For each serial line you configure, two signals named rxN and txN must be connected to the appropriate pins of the FPGA. Also, for each link you can set a signal klN_bps; valid values range from 1200 to 230400, and the default value is 9600. You should consider that each byte input or output generates an interrupt; running a link at high speed is a lot of work for the CPU. It is not generally a good idea to go beyond 38400.
For more reliable transmission at higher speeds, the serial link controller can implement RTS/CTS signals – by default it does not. This can be enabled by setting the signal klN_rtscts to 1; if you do, you must also connect the signals rtsN and ctsN. Also, setting to 1 causes that the controller will include a receive buffer, so that bytes will not be lost if the CPU does not respond to an interrupt in time.
Finally, there is the option to force the highest order bit of each byte received and transmitted to zero. This is mostly useful for the console line of systems running older operating systems; these sometimes assume that the hardware will only handle 7 bits. Enable this by setting klN_force7bit to 1.
The following example creates two serial links, the first one intended for the system console, and one high speed link for inter-system communication:
pdp11: unibus port map( ... have_kl11 => 1, rx0 => rxrx0, tx0 => txtx0, kl0_force7bit => 1, rx1 => rxrx1, tx1 => txtx1, cts1 => cts1, rts1 => rts1, kl1_rtscts => 1, kl1_bps => 38400, ... );
The kw11-l line clock is used to generate a periodic interrupt; it is required for all systems that do some kind of multitasking. Originally, the frequency was derived from the mains frequency; hence the usual rate of 60Hz for the US, and 50Hz for Europe. In the PDP2011 systems, the default frequency for the kw11-l is 60Hz; in this case this is derived from a crystal oscillator on the FPGA board. It can also be set to 50Hz, or even 400Hz. Mostly it is advisable to leave it at the default of 60Hz, as this is supported by more software – and it saves you from having to set it in a sysgen.
The following example sets the clock frequency to 50Hz:
pdp11: unibus port map( ... kw11l_hz => 50, ... );
There are three different disk controllers: rk, rl, and rh. You can only have one of each type, and whether or not each type is included is governed by the signals have_rk, have_rl, and have_rh; setting these to 1 includes the controller, and setting to 0 disables it.
If you include a controller, the signals of the form rX_sdcard_cs, rX_sdcard_mosi, rX_sdcard_sclk, and rX_sdcard_miso must be connected to FPGA pins that are in turn connected to where the SD card cage is located on the board. Additionally, the controllers include debug signals in a 4-bit vector called rX_sdcard_debug that will be enabled if you set have_rX_debug to 1. In general, it is advisable to include the debug signal and connect the 4-bit vector to leds on the FPGA board; it will allow you to see whether the sdcard is being read or written, and if the controller can communicate with the card.
The following example includes an RH controller:
pdp11: unibus port map( ... have_rh => 1, have_rh_debug => 1, rh_sdcard_cs => rh_cs, rh_sdcard_mosi => rh_mosi, rh_sdcard_sclk => rh_sclk, rh_sdcard_miso => rh_miso, rh_sdcard_debug => rh_sddebug, ... );
If you go about changing the disk controllers, you also need to consider booting from these disks. In the setups I distribute, there is a little bit of boot code in something resembling the M9312 bootstrap rom; the version included in the distributed project files is the T44 ‘triple boot’ that attempts to boot from the first existing controller from the list RK, RL, RH – in that order. If you want to change that behaviour, you will either need to select one of the other m9312xx.mac sources, or create your own – and take care that your code still fits in the limited space that the m9312 rom provides. Which of the sources is active you can select by including the right VHDL source in your project, and make sure that the .mac file is compiled into a .vhd file for it – look into the Makefile for how this is done.
The DEUNA/DELUA controller is called xu; it is a frontend for the ENC424J600 from Microchips, and most easily connected to the FPGA in the form of Digilent’s PMODNIC100. The xu controller actually contains a complete system, including unibus, CPU, microcode, line clock, and serial link – all this is hidden under the simple configuration described here. You enable the controller by setting the have_xu signal to 1. If you do, you must connect the signals xu_cs, xu_miso, xu_mosi, and xu_sck, and interface these to the appropriate pins of the ENC424J600 chip or PMODNIC100.
The following example includes an DEUNA/DELUA controller:
pdp11: unibus port map( ... have_xu => 1, xu_cs => xu_cs, xu_mosi => xu_mosi, xu_sclk => xu_sclk, xu_miso => xu_miso, ... );