RECEIVE CONSOLE DATA REGISTER (RXCD)

node other

is master times is

Each VAXBI console has a node:pace register, the Receive Console Data Register (RXCD), for receiving data from other VAXBI consoles. The RXCD Register occupies the address bb + 200 in the nodespace of the node (bb is the starting address for the node's nodespace). The RXCD Register address is reserved for the RXCD. If a VAXBI node does not

implement a VAXBI console, then that node must respond to reads to that location with either a NO ACK confirmation or a longword in which the RXCD Busy 1 bit is set (described below).

The RXCD Register will respond to longword VAXBI transactions. Since VAXBI interlock commands are used in the protocol, locks must be implemented for the RXCD Register. This is true notwithstanding the VAXBI rule that interlock commands are implementation dependent with respect to interlocking when the operand is in I/O space outside of node window space. However, in a UWMCI command to the RXCD the mask bits may be ignored; that is, the command may act as if the mask bits were all set, regardless of whether they are set. VAXBI nodes that do not implement a VAXBI console need not implement locks for the RXCD Register location.

The RXCD Register is described in Section 7.17.

c

c'

0···'

^.,

9.3

DIGITAL CONFIDENTIAL & PROPRIETARY Digital Internal Use Only

VAXBI CONSOLE PROTOCOL

CONSOLE COMMUNICATIONS

To send a character in a console communication, the sending console carries out the following protocol:

Each

1. Issue a VAXBI IRCI to the receiving console's RXCD Register.

Examine the Busy 1 bit (bit 15) of the returned value. If i t is one, go to step 2; otherwise go to step 3.

2. The Busy 1 bit is a one, so the receiving node is not ready to receive. Write back what was read with a VAXBI UWMCl transaction to unlock the RXCD. After a short wait (the length of which is implementation dependent), start again at step 1. If the Busy 1 bit remains set for over 1 second, the sending console can WRITE a longword of all zeros into the receiving console's RXCD Register to clear the Busy 1 bit, if the following conditions are met:

o The sending console is the master console.

o The sending console is transmitting on behalf of input from the console terminal; that is, the console terminal is in console mode.

After attempting to clear the RXCD Register, the sending console can repeat step 1 above. Note that, since the sending console is the master console in this case, no other console can be writing to the receiving console, and the RXCD contents that were erased must have been deposited by the sending console itself.

3. The Busy 1 bit is a ~ero, so the receiving node is ready.

node

Issue a VAXBI UWMCI with the mask bits set to 1111, conveying one character to the receiving node. The issuing node must load the Node ID field with its node 10 and set the Busy 1 bi t.

monitors its RXCD Register. The Busy 1 bit, which is initially zero, is set to one when the RXCD is written by another console. The local node then issues an IRCI transaction to read the character, followed by a UWMCI to clear the Busy 1 bit and unlock the RXCD.

*

The protocol for the RXCO Register is described in pseudocode in Figure 9-2.

The receiving node should sort incoming characters according to sending node, using the node 10 in the Node ID field of the RXCD. In this way, if two nodes simultaneously send characters to the same node, the two messages will not be interleaved.

*In the KA820 case, if the processor is not halted, generated when the RXCO receives the character.

9-3

DIGITAL CONFIDENTIAL & PROPRIETARY

an interrupt is

VAXBI CONSOLE PROTOCOL

Send to Remote VAXBI Console byte to send ( )

more-to-send new

old my id dest RXCD

while more to send begin new<15> :;- 1;

new<II:8> := my id;

new<7:0> := byte to send();

locked := true;

while (locked = true) begin issue (IRCI, dest RXCD, if (01d<15> = 0) then

begin

Character of command/data to be sent There are more characters to send Longword, set up ready to transmit Longword, read from destination RXCD 4-bit encoded node 10 of sending node Address of RXCD of destination node

01 d) ;

issue (UWMCI, dest RXCD, new);

locked := false;

end else

issue (UWMCI, dest RXCD, old);

end end

Receive from Remote VAXBI Console newcha r ( )

issue (trans, addr, data) my_RXCD

process newdata

while newchar() begin

RXCD Busy 1 bit became set

Initiate transaction to address

Address of this node's RXCD Register Start processing new character

Longword for holding RXCD contents

issue (IRCI, my RXCD, newdata);

issue (UWMCI, my RXCD, 0);

process(newdata);

end

Figure 9-2: RXCD Protocol

9-4

c

o

c

9.4

DIGITAL CONFIDENTIAL & PROPRIETARY Digital Internal Use Only

VAXBI CONSOLE PROTOCOL THE Z CONSOLE COMMAND

All VAXBI consoles must implement the Z console command. The Z command causes console commands received or typed at one console to be forwarded to another console. The format and effect of the command are as follows:

Z <value>

The <value>

Subsequent destination echoes back

is a hexadecimal digit indicating the destination node.

characters input at this console are forwarded to the console, except as described below. The destination node to this console.

The first ASCII escape character indicates that a That is, any character immediately following character is to be forwarded, including CTRL/P character. Since the character immediately after forwarded as a literal, an escape can also be manner.

"literal" follows.

the first escape or another escape the first escape is forwarded in this Unless it is a literal, a CTRL/P is not forwarded. Instead, it terminates the Z command (that is, i t terminates the forwarding) and causes the local console to enter console mode.

Figure 9-3 shows how the z console command handles escape characters.

Two Z commands must not be issued from a processor when i t is master console, without an intervening CTRL/P. For instance, consider the configuration shown in Figure 9-1. Suppose"Z 5" and

"z

7" are issued from processor A as master console, without an intervening CTRL/P.

The first Z command causes sursequent commands to be forwarded to node 5, while the second Z command might be expected to cause subsequent commands to be forwarded first to node 5 (processor B) and then to node 7 (processor C). The effect of subsequent console commands issued from processor A is undefined in this case.

9-5

DIGITAL CONFIDENTIAL & PROPRIETARY

1

I

VAXBI CONSOLE PROTOCOL

,

GE7 A CHARAC7ER

, i

YES

I

(NEX7 CHARAC"ER IS A i..ITERAl;

, I

GE7 ANOTHER CHARAC7ER

NO ;

,

I

NO

I

. ,

FORWARD THE CHARAC7ER

YES

7E~M!NA7E

FORWARDING.

EN7E~ lC::":"L C::NSO~E VlCDE

T

L-________________________________ T

Figure 9-3: Handling of Escape Characters in the Z Console Command

9-6

f"

'\.J

c

(

^'

, '-, ;,~

o

DIGITAL CONFIDENTIAL & PROPRIETARY Digital Internal Use Only

CHAPTER 10 PERFORMANCE

This chapter discusses bus bandwidth and bus access latency and interrupt latency on the VAXBI bus. These measures in general cannot be calculated because they are dependent largely on factors such as memory performance characteristics, which are not characteristics of the bus. However, if the specified restrictions on the number of certain types of cycles are adhered to (or if violations of the restrictions are documented and i t is known how many of which violating nodes are in the configuration), an upper bound can be determined from clock frequency and protocol limits.

Dans le document System Reference Manual (Page 183-188)