for the Address Bus
WHILE TRUE
ALT i = 0 FOR no.devices
data.in[i] ? data.item — wait for input data.out I data.item :— send data to CPU The two bus processes defined above individually satisfy the two requirements of the data bus. Still they are not sufficient in this form to completely model a
bi-directional bus. To do this they must be brought together and instanced within an occam PAR statement.
Finally all it is necessary to do is instance the data and address bus processes in parallel with the device
simulations. The system is 'wired up' by allocating channels to the bus and device processes in the manner
already explained. Each device process will have one channel for each bus process it communicates with. The
program code below shows an example system comprising a CPU and three components, communicating via an address and data bus.
VAL no.devices IS 3:
CHAN OF ANY CPU.to.address.bus, data.bus.to.CPU CPU.to.data.bus:
[no.devices]CHAN OF ANY address.bus.to.devices, devices.to.data.bus, data.bus.to.devices : PAR
— address bus simulation
CPU.to.devices.bus(CPU.to.address.bus, address.bus.to.devices, no.devices)
PAR — data bus simulation CPU.to.devices.bus(CPU.to.data.bus, data.bus.to.devices, no.devices) devices.to.CPU.bus(data.bus.to.CPU, devices.to.data.bus, no.devices) CPU(CPU.to.address.bus, CPU.to.data.bus, data.bus.to.CPU ) ROM(address.bus.to.devices[0], data.bus.to.devices[0], devices.to.data.bus[0]) RAM(address.bus.to.devices[1], data.bus.to.devices[1], devices.to.data.bus[1]) PIA(address.bus.to.devices[2], data.bus.to.devices[2], devices.to.data.bus[2]) 5.3.4 Control Bus
Due to the irregular nature of the control bus in most microprocessor systems, no attempt was made to define a
strict simulation structure. Instead, each device is merely allocated a channel for each control line which it uses. Control signals are then simply fed out to memory from the CPU or multiplexed to the CPU from memory by a simple
'control.bus1 process. This process operates in a manner identical to the bus simulation processes described above. 5.4 Implementation on a Single Transputer
Initially, simulations of a number of the basic components in the 6800 family were constructed. These include the 6800 and 6802 microprocessors, various memory devices, parallel and serial input-output controllers and an analogue-digital converter. Individual component simulations were then
brought together to form simulations of example MCSs, with components communicating via a bus system identical to the one described above. The CPU register values were displayed on a monitor, enabling the simulations to be fully debugged and tested. No attempts were made at this stage to optimise the performance of the simulations. In fact, the use of the monitor to display the state of the components caused a severe reduction in performance. A monitor screen is a slow output device, and causes the processor to wait while a character is written to the screen.
When all the simulations had been thoroughly tested, it was decided to carry out several experiments, in order to
measure the performance of simulations on a single
transputer. This would provide a useful reference point for comparison with the performance of equivalent simulations on networks of transputers. In order to achieve this, a sample MCS simulation was constructed comprising a 6800 microprocessor and clock, ROM, RAM and a PIA. All monitor output was removed from the component models (except start and finish messages), so that the observed execution times would not contain delays due to the screen. Varying assembler programs were then simulated using this
configuration, and the execution times recorded. The
transputer utilised to perform these experiments was an IMS T414 running at 20 MHz, which resided on the B004 board. Overall an average of approximately four hundred (6800) cycles per second were simulated.
As extra memory and 1-0 components were added, the
performance of the simulation deteriorated. This occurred due to the additional demand placed on the processor by the inclusion of more concurrent processes. On a single
transputer, the processor must be shared between the processes in the simulation. Consequently, as more processes are added, the overall performance of the transputer decreases. However, this problem should not occur when a network of transputers is used as the target architecture for the simulation. In this situation, as more components are added, more transputers can be incorporated into the network. This increases the computational power available for simulation, and compensates for the
additional workload.
5.5 Implementation on a Transputer Network 5.5.1 The Problem
Consider an example simulation of a MCS comprising a CPU, two 128-byte RAMs, one lK-byte EPROM and one PIA. If this simulation is executed on a single processor (transputer or otherwise), there is no need to make any changes to the system bus simulation. The channels which enable
communication between devices are implemented as memory locations. Consequently no severe restrictions are placed on their number. However problems are encountered if the simulation is mapped on to a network of transputers and each transputer simulates one component. Transputers have only four external communications links, each of which implements a pair of occam channels. Therefore one transputer can be linked to a maximum of four other transputers. This restriction makes the above scheme impossible to implement, as a situation such as the one shown in Figure 5.3 will arise, in which one component cannot be interfaced.
Possibly the simplest solution to the problem is achieved by configuring the transputers in a ring-type network as in