Would you like to make this site your homepage? It's fast and easy...
Yes, Please make this my home page!
================================================================================
Note 33.0 System Config of DL Devices No replies
FURILO::GIORGETTI 758 lines 21-AUG-1985 23:27
--------------------------------------------------------------------------------
+---------------+ +-----------------+
| d i g i t a l | | uNOTE # 033 |
+---------------+ +-----------------+
+----------------------------------------------------+-----------------+
| Title: System Configuration of DL-type Devices | Date: 28-Jun-85 |
+----------------------------------------------------+-----------------+
| Originator: Art Bigler | Page 1 of 14 |
+----------------------------------------------------+-----------------+
DL-type devices are single, asynchronous serial line unit (SLU)
interfaces used on Digital's Q-bus and UNIBUS processors. On PDP-11s
the DL-type SLU is required as the console terminal interface for use
with console octal debugging technique (ODT), diagnostics, and operating
system consoles. They are also used to provide interfacing to a wide
variety of peripherals on both PDP-11 and VAX processors.
This MicroNote will examine the proper use and configuration of DL-type
SLUs in system environments. It will first discuss the characteristics
of these popular options, and then, some of the applications in which
they are used. Lastly, the configuration of DL-type SLUs in the system
environment will be discussed and a number of recommendations for their
use will be presented.
It should be noted that the examination of a system configuration, and
any resulting recommendations, is based upon the particular application
of the system. The configuration guidelines presented here are not
necessarily suitable for all. The system designer must determine the
extent to which this information is used.
1.0 CHARACTERISTICS OF THE DL-TYPE SLU
The DL-type SLU is an interface to asynchronous serial peripherals, such
as terminals, consisting of a host bus interface (to the Q-bus or
UNIBUS), a receiver and transmitter (usually an industry-standard UART),
and an electrical interface to the peripheral (20 ma. current loop, EIA
RS-232-C, RS-422, etc.). Additional features (e.g. the line time clock
register on the UNIBUS DL11 or modem control on the Q-bus DLVE1) may or
may not be present on a DL-type SLU. These features have nothing to do
with the basic function of the SLU which is transmit and receive
asynchronous serial data via the data leads only ( modem control is a
extension of the capabilities of the interface, not a basic function).
A block diagram of a DL-type SLU is presented in figure 1.
Page 2
------------------------------------------------------------------------
Q-BUS OR UNIBUS
------------------------------------------------------------------------
^
|
|
|
v
+--------+ +--------+ +--------+
| | | | | |
| | | | | ELECT | -+
| HOST |------->| ASYNC |------->| INTF |-------> | TO/FROM
| BUS | | TRANS | | TO | +-- SERIAL
| INTF |<-------| /REC |<-------| SERIAL |<------- | LINE
| | | | | LINE | -+
| | | | | |
+--------+ +--------+ +--------+
Figure 1
Block Diagram, DL-type SLU
1.1 DL-TYPE SLU REGISTERS
All DL-type SLUs must implement four registers, two control and status
registers (CSRs) and two data buffer registers (BUFs). The same base
configuration of bits within these registers must also be implemented.
These registers, and their functions, are listed below:
1. The receiver control and status register (RCSR) provides, at
a minimum, control and status of the receive interrupt
enable (bit 06) and status of the receiver done flag (bit
07). The receiver done flag is set by the SLU whenever a
character has been received. It may be polled by a program
or it may generate an interrupt if the receive interrupt
enable has been set. The receiver done flag is reset by an
initialization from the host bus or by reading the character
from the receiver data buffer register.
2. The receiver data buffer register (RBUF) provides, at a
minimum, received character data (bits 00 through 07) and
received data error information (bits 12 through 15). The
received data is valid whenever the receiver done flag is
set in the RCSR. The error bits are implemented in all DL-
type SLUs except the DLV11 and provide status information
for the received data. All DL-type SLUs implement framing
error (bit 13), overrun error (bit 14), and error summary
(bit 15). Additionally, all DL- type SLUs, except those
implemented with the DC319-AA DLART, implement parity error
status (bit 12). Error summary is set whenever any of the
other error bits are set. Overrun error is set when a newly
Page 3
received character is received before the receiver done flag
is reset. Framing error is set whenever a character is
received without a valid stop bit, usually by a break
character. Parity error is set whenever a character is
received with the incorrect parity, if the interface has
been configured to check parity.
3. The transmitter control and status register (TCSR) provides,
at a minimum, control and status of the transmit interrupt
enable (bit 06) and the transmit break enable (bit 00), and
status of the transmitter ready flag (bit 07). The
transmitter ready flag is set by the SLU whenever the
transmitter is ready to transmit another character or by an
initialization from the host bus. It may be polled by a
program or it may generate an interrupt if the transmit
interrupt enable has been set. The transmitter ready flag
is reset by transferring another character to the
transmitter data buffer register. The transmit break enable
forces the transmitter to generate a continuous break
character (continuous space level) while it is set.
4. The transmitter data buffer register (TBUF) holds, at a
minimum, the last character to be transmitted (bits 00
through 07). Transferring a character to this register
resets the transmitter ready flag in the TCSR.
Transfers to these registers are performed by programmed I/O, the result
of the execution of an instruction by the host processor. The only
other bus operation a DL-type SLU may initiate is an interrupt from the
transmitter or receiver.
Figure 2 provides graphic representations of these registers.
Page 4
1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0
5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
RCSR | | | | | | | | | | | | | | | | |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
^ ^
| |
| |
RECEIVER DONE FLAG ---+ +--- RECEIVE INTERRUPT
ENABLE
1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0
5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
RBUF | | | | | | | | | | | | | | | | |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
^ ^ ^ ^ ^ ^
| | | | +-------------+-------------+
| | | | |
| | | +--- PARITY ERROR |
| | | RECEIVED
| | +--- FRAMING ERROR CHARACTER
| | DATA
| +--- OVERRUN ERROR
|
+--- ERROR SUMMARY
Figure 2
DL-type SLU registers
Page 5
1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0
5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
TCSR | | | | | | | | | | | | | | | | |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
^ ^ ^
| | |
| | |
TRANSMITTER READY FLAG ---+ | TRANSMIT BREAK ---+
| ENABLE
TRANSMIT INTERRUPT ENABLE ---+
1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0
5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
TBUF | | | | | | | | | | | | | | | | |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
^ ^
| |
+-------------+-------------+
|
|
TRANSMIT
CHARACTER
DATA
Figure 2, continued
DL-type SLU registers
1.2 DL-TYPE SLU ADDRESSES AND VECTORS
DL-type SLUs must implement their addresses and vectors in the following
manner:
1. The four registers, RCSR, RBUF, TCSR, and TBUF, occupy four
contiguous words in the I/O page address space. The first
address is called the base address.
1. RCSR is assigned base address +00.
2. RBUF is assigned base address +02.
3. TCSR is assigned base address +04.
Page 6
4. TBUF is assigned base address +06
2. The receive interrupt vector and the transmit interrupt
vector occupy two contiguous vectors in the vector address
space.
1. The first vector is the receive vector.
2. The second vector is the transmit vector.
For the console SLU on a PDP-11 processor the base address is always
17777560 (octal) and the receive vector is at 60 (octal). DL-type SLUs
used for applications other than the console SLU are usually assigned
address and vectors in the floating address and vector spaces.
1.3 DL-TYPE SLU PROGRAMMING CONSIDERATIONS
There are two methods of programming DL-type SLUs; polled I/O and
interrupt driven I/O.
1. In polled I/O the software executing on the host processor
polls, or tests, the receiver done flag in the RCSR or the
transmitter ready flag in the TCSR to determine if a
character has been received or is ready to be transmitted.
If the flag is set the software executes an instruction to
move the character from the RBUF or to the TBUF. The
polling is then resumed. Polled I/O is used by PDP-11
diagnostics because it is the simplest method and requires
the least amount of hardware working in a system, a definite
advantage when attempting to service a system which is
operating improperly.
2. In interrupt driven I/O the software sets the receive
interrupt enable in the RCSR or the transmit interrupt
enable in the TCSR. If the receiver done flag or the
transmitter ready flag is set, an interrupt is generated
through the appropriate vector. Execution is transferred to
an interrupt service routine (ISR) and an instruction is
executed to move the character from the RBUF or to the TBUF.
A return from interrupt (RTI) instruction is then executed
to return control back to the main program. All Digital
operating systems and most user software utilize interrupt
driven I/O because processor time is optimized.
When programming a DL-type SLU, several restrictions must be taken into
account. Most of these are due to the design of the asynchronous
receiver and transmitter and its implementation in the SLU. The
important restrictions are detailed below.
Page 7
1. There is only a one character buffer in the receive side of
the SLU. Therefore, any character which has been received
must be moved from the RBUF prior to the next character
being assembled in the receiver. If characters are actually
being received at the maximum character rate as defined by
the bit data rate of the serial line, the RBUF must be read
within one character time or an overflow error will occur on
the SLU and data will be lost.
2. The transmitter also has only a one character buffer.
However, while this restriction may result in the
transmission of characters at a rate lower than the maximum
character rate, the transmitter can wait a theoretically
infinite time for the next character. No data will be lost
and no errors will occur.
3. Direct memory access (DMA) I/O has precedence over interrupt
I/O. Therefore, if a DMA device and DL-type SLU wishing to
interrupt the processor are both requesting use of the bus,
the DMA device will be granted it. While this does not
normally cause problems in systems which make use of
single-cycle DMA transfers (except, of course, where the
system is heavily loaded with a number of active DMA
devices), the use of burst-mode DMA or, on the Q-bus,
block-mode DMA could conceivably lock out the interrupts
from the SLU for an appreciable length of time. This should
have little effect on the transmitter since it can wait
indefinitely for interrupts, but it could have a disastrous
effect on the receiver, allowing the loss of data and
generating overrun errors.
1.4 DIGITAL'S DL-TYPE SLUs
Digital manufactures a variety of DL-type SLUs for both the Q-bus and
the UNIBUS. The following list is compilation of those currently
available.
1. Q-bus compatible, DL-type SLUs
1. DLV11 - a single line, DL-type SLU on one dual
height module. Data rate from 50 to 9,600 bits
per second, full duplex, data leads only (no
modem control). RS-232-C and 20 ma. current
loop serial line interfaces.
2. DLVE1 (formerly DLV11-E) - a single line,
DL-type SLU on one dual height module. Data
rate from 50 to 19,200 bits per second, full
duplex with limited modem control. RS-232-C
serial line interface.
Page 8
3. DLVJ1 (formerly DLV11-J) - four individual,
DL-type SLUs on one dual height module. Data
rate from 150 to 38,400 bits per second, full
duplex, data leads only (no modem control).
RS-232-C serial line interface.
2. UNIBUS compatible, DL-type SLUs
1. DL11 - single line, DL-type SLU on one quad
height small peripheral controller (SPC) module.
Data rate from 50 to 9600 bits per second, full
duplex. A number of variations are available
some including modem control and line time clock
interfaces. RS-232-C and 20 ma. current loop
available.
3. Digital produces two multifunction modules for the Q-bus,
the MXV11-A and the MXV11-B, which contain DL-type SLUs.
These are intended for the board-level applications where
RAM and ROM memory and SLUs in a single compact board are
required.
4. Additionally, Digital manufactures a DL-type SLU on a chip,
the DC319-AA DLART. The DLART is used in several of
Digital's systems as the console terminal SLU for processor
modules such as the KDJ11-B.
2.0 DL-TYPE SLU APPLICATIONS
The following are examples of the potential uses for DL-type SLUs in
systems.
1. In general, DL-type serial line units are required for the
console device interface on all PDP-11 processors for three
functions:
1. Console ODT - the console ODT routines in these
processors can communicate with DL-type
interfaces only.
2. Diagnostics - diagnostics which run under XXDP
and DEC/X11 assume the use of a DL-type console
interface.
3. Operating system console - the operating systems
which run on the PDP-11 processors require
DL-type SLUs for the system console. Even if
the console interface device can be redirected
to another serial line, as is possible in the
Page 9
RSX operating systems, the crash and panic dumps
routines usually require the use of a DL-type
SLU.
The reason that DL-type interfaces are used for these
functions is that they are the simplest, most reliable
serial line unit available. If a system is down, having a
DL-type SLU as the console interface will almost always
eliminate the possibility that the problem is with the
console interface.
2. DL-type SLUs are also used, in some systems, to provide
interactive terminal support. Their use for this
application is not recommended for reasons which are
discussed in following sections.
3. Applications requiring the use of a serial hardcopy terminal
as a low-cost system printer may use the DL-type SLU as the
interface.
4. Applications which require as immediate attention as
possible to a serial data stream may require the use of a
DL-type SLU as the interface. The serial data stream is
most often from an instrumentation device, such as a
thermocouple, in a process control environment.
The next sections will examine the configuration of DL-type SLUs in
system environments. Some specific recommendations for configuration
and use of these devices, including the recommendation of using other
types of SLUs wherever possible, will be presented.
3.0 SYSTEM CONFIGURATION OF DL-TYPE SLUS
There are several items which must be considered when configuring
DL-type SLUs into systems.
1. The data rate at which the SLU is expected to transfer data
to and from the serial line, and therefore, the host
processor's bus.
2. The aggregate data rate expected from all devices on the
host processor's bus. This includes the amount and mode of
DMA activity on the bus and its potential effect on the
DL-type SLU.
3. The interrupt priority of the SLU on the host processor's
bus.
In the following discussions, much use will be made of an example based
upon the configuration of a DLVJ1 quad SLU in a Q-bus system. With the
exception of block-mode DMA, which does not exist on the UNIBUS, the
example is, in general, valid for Q-bus and UNIBUS PDP-11 and VAX
Page 10
processors. It must be remembered that the configuration is largely
dependent upon the system application which may alter some of the rules
presented.
3.1 DLVJ1 DESCRIPTION AND CONSIDERATIONS FOR USE
The DLVJ1 is a dual height Q-bus module consisting of four individually
programmed RS-232-C/RS-449/RS-423 compatible DL-type SLUs. Although
they share common Q-bus transceivers and device selection and data
gating logic, the four SLUs each have their own sets of serial line
interfaces circuits, Universal Asynchronous Receiver Transmitter (UART)
circuits, and DC003 interrupt controller circuits. This, in effect,
gives the system designer four individual DL-type serial line units each
with its own CSRs and data buffer registers and with data rate
capabilities of up to 38.4K bits per second per channel.
The four DC003 interrupt controllers are configured and wired in the
proper Q-bus compatible fashion for bus request level four only (BR4)
devices (i.e. BIAKI comes in from the bus, through the first DC003, and
out as BIAKO which then goes to the BIAKI input of the second DC003.
The second DC003 then routes the BIAK signal to the third DC003 and the
third to the fourth which then routes its BIAKO signal out to the Q-bus
for continuation of the daisy chain.). The Q-bus specification provides
for two methods of establishing device priority:
1. Distributed arbitration - priority levels are implemented in
hardware on the device. Devices must monitor all interrupt
requests with higher priority than their own and pass
through the interrupt acknowledge if one exists. When
devices of equal priority request an interrupt
simultaneously , priority is given to the device
electrically closest to the processor.
2. Position-defined arbitration - priority is determined solely
by electrical position on the bus. The closer a device is
to the processor, the higher its priority is. Devices which
use position-defined arbitration must be placed in
descending bus request order after any devices which
implement distributed arbitration.
It should be noted that Digital has produced only one Q-bus device with
multiple interrupt request levels, the TSV05. All other devices
produced to date have implemented BR4 only, and depend upon
position-defined arbitration for their priority. This is largely due to
the standard Q-bus interface chips' lack of circuitry required for
performing the higher level request monitoring. Due to the
implementation of the bus, UNIBUS devices do not have this restriction.
For further information on the subjects of interrupt priorities and
device placement consult the PDP-11 Architecture Handbook and the
Microcomputers and Memories Handbook.
Receiver done and transmitter done interrupt requests are wired to the
Page 11
DC003's so that the four receiver done interrupts have a higher priority
than the four transmitter done interrupts. Elevating the receiver done
interrupt priorities over that of the transmitter done interrupts helps
reduce the potential for lost input characters due to receiver data
overrun errors. Transmitter operation is essentially not affected,
except potentially in throughput, since the transmitters will hold their
interrupt requests indefinitely. This configuration is, in fact,
preferable to that of four individual DL-type interfaces (DLVE1, etc.
on the Q-bus or DL11 on the UNIBUS) which would have the transmitter
done interrupts placed between the receiver done interrupts.
The device address selection circuits and vector address generation
circuits allow for the DLVJ1 to be configured at a number of different
base addresses and vectors. Channel three may be configured for use as
the system console device interface and it is this capability, not its
cost, that has made the DLVJ1 an extremely popular option.
The serial interfaces are capable of data-leads-only interfacing (i.e.
transmit data, receive data and ground) to external equipment. Thus
there is no modem control capability in the DLVJ1. This is usually of
no consequence since the largest use of this device is for local console
device and terminal interfacing. If the user requires modem control,
the DLVE1 is available. If the interface is not being used for the
console terminal, asynchronous multiplexers with modem control such as
the DZV11 and DHV11 are available and are preferable in almost all
applications.
3.2 SLU DATA RATE CONSIDERATIONS
The UART used in the DLVJ1 is the 6402 which is a member of a generic
UART family in wide use in a large number of Digital and third party
vendor products, including the DLVE1 and DLV11 Q-bus options, and the
DL11 UNIBUS option. They are very similar in nature to Digital's DLART
interface chip which is used on the MXV11-B multifunction module, the
MicroPDP-11/23 and PDP-11/23-PLUS processor board, the KDF11-B, and the
MicroPDP-11/73 processor board, the KDJ11-BC.
The 6402 provides one level of buffering on input and output data with
the implementation of a receiver data holding register and a transmitter
data holding register respectively. While the level of buffering is
relatively unimportant to the transmitter due to its ability to wait
indefinitely for additional characters, it is extremely important to the
receiver. To illustrate this the following example is used:
The 6402 provides a receiver register which holds the current,
incoming character. The data is transferred into this register
at the bit data rate at which the serial line is running. The
time required to fill the receiver register can be calculated as
follows.
t=1/(bit data rate)*(number of bits per character)
Page 12
Where t is the character time and the number of bits per
character includes the start bit, all data bits, parity
bit if used, and all stop bits.
Picking some common numbers for this example:
Bit data rate = 9600. bits per second.
Number of data bits = 8.
Number of parity bits = 0.
Number of stop bits = 1.
The character time is therefore:
t=1/9600*(1+8+0+1)
t=1.041 msec. per character
Therefore, at a 9600 bits per second data rate, the time from
the start of transmission of the character to the time the
character is loaded into the receiver buffer register is
approximately one millisecond.
If the next character starts transmission immediately, the
processor has at least one character time before the receiver
buffer register must be emptied so that it can accept the
current input character, in this case one millisecond. This
implies that the receiver done interrupt must be serviced within
that time also. So long as the combination of software and
hardware is capable of servicing the interrupt within a
character time the receive data should never overrun.
Therefore, the limiting of the serial data rate will help to reduce the
amount of system resources required to service the SLU and optimize
processor time.
3.3 HOST PROCESSOR AGGREGATE DATA RATE CONSIDERATIONS
The above example does not take into account any other bus interrupt or
DMA activity which will, of course, impact the speed at which the DLVJ1
interrupt is serviced. To minimize the effects of the host processor's
aggregate data rate two configuration rules should be followed:
1. The data rate on the DLVJ1 devices should be kept to a
reasonable limit which is usually considered to be at, or
below, 1200 bits per second. This will allow additional
time for the processor to service the receiver done
interrupt and will keep the the amount of bus activity due
to serial line interrupts reasonable.
2. Careful attention should be given to the amount and mode of
DMA activity on the host processor's bus. Large quantities
of DMA traffic mean that the processor has less time to
Page 13
service interrupts which have a lower priority than DMA
operations. Devices doing burst and block mode DMA
operations may hold the bus for long periods of time,
resulting in interrupts being blocked for the duration of
the DMA operation.
3.4 INTERRUPT PRIORITY OF THE DL-TYPE SLU
The DL-type SLU should be configured as the highest priority
interrupting device on the bus if at all possible. In most cases this
will result in the SLU being the first device on the bus, with the
possible exception of the line time clock or BEVENT line. This is
consistent with the MicroPDP-11's, PDP-11/23-PLUS's , and the UNIBUS
processors, all of which have their console device interfaces very close
to the beginning of the bus.
By placing the DL-type SLUs as close to the front of the bus as
possible, the interrupt priority is elevated above that of the other
devices on the bus. This will allow the interrupt requests to serviced
before the rest of the devices and immediately after the DMA activity,
resulting in a reduced possibility of data loss.
4.0 SUMMARY AND RECOMMENDATIONS
The DL-type SLUs are required by PDP-11 systems as their console
interface. There are several options which may be used to provide this
function. Theses include the DLVxx series options on the Q-bus and DLxx
series options on the UNIBUS. Additionally, several multifunction
options and processors have DL-type interfaces integrated into them.
These include MXV11-As, MXV11-Bs, KDF11-Bs and KDJ11-Bs.
The use of all DL-type SLUs should be limited in most systems (special
applications may have valid uses of DL-type devices). They should , in
most circumstances, be used only for the console device interface and
serial printer applications. The use of an asynchronous multiplexer is
recommended for all other serial line requirements, excepting infrequent
special applications.
The use of any DL-type SLU for an interactive terminal on a multiuser
system is indicative of a poor system configuration. In this case, the
proper configuration would include asynchronous multiplexers such as
DZV11's, DZQ11's, or DHV11's (or their UNIBUS counterparts) to provide
efficient handling of terminal interfaces with the minimum of bus
activity and operating system overhead.
The use of a DL-type SLU as a low cost printer port is exempt from the
above statement because it requires approximately the same overhead as
the LPV11 or LP11-type line printer controller. However, the use of an
Page 14
asynchronous multiplexer with DMA output, such as the DHV11, may provide
a more efficient method of handling printers, depending upon the
implementation.
The data rate at which any DL-type SLU operates should be kept to a
minimum, particularly when receiving data, to ensure that the amount of
bus activity is as low as possible since these interfaces are interrupt
intensive. This holds for any interrupt intensive device (parallel I/O
devices such as DRV11s, etc.), in general. The problem is not that of
the inadequacies of the interface but of the amount of bus bandwidth
available to support the aggregate bus data rate.
The DL-type SLU should be placed in as high an interrupt priority
position as possible to insure adequate servicing by software. This
will not affect DMA activity since it holds priority over interrupts.
The performance of most systems will not be affected by the increased
priority level of the maximum one or two DL-type interfaces which are
recommended to be active at one time.
Under no circumstance should any device, including a DL-type interface,
be placed on the bus after a RQDX1 disk controller. The RQDX1 does not
pass through the DMA and interrupt grant lines properly, thus producing
completely unpredictable results and often times "hung" devices.
Recommendations for the DL-type SLUs, and any other interrupt intensive
devices, are:
1. Limit their use whenever possible. Use asynchronous
multiplexers or other more advanced interfaces whenever
possible. The cost savings of a DLVJ1 over a DZQ11 must not
overshadow the performance issues.
2. Limit the rate at which they operate. For DL-type
interfaces a good limit appears to be 1200 bits per second
or less although in some applications a higher rate may be
possible.
3. Place them so that they have as high an interrupt priority
as possible, in most cases the highest priority.
Following these few recommendations will result in improved system
performance and far less headaches when configuring DL-type SLUs into
systems.
