<<< DISK$PUBLIC:[COVERT.DECUSERVE]MICRONOTE.NOTE;1 >>> -< TOEM MicroNotes >- ================================================================================ Note 1.0 MUL, DIV, ASH for Falcon(+) 6 replies JAWS::KAISER 7 lines 25-MAR-1985 09:13 -------------------------------------------------------------------------------- Welcome to the Micronotes Notesfile, public repository of Micronotes written by the OEM Technical Support Group. They are formatted for printing. Micronotes are numbered, and each one is in the notesfile note with the same number (except for Micronote 1, which is the reply to this note); so for the sake of simplicity, please don't WRITE in this file. Feel free to REPLY, however. ================================================================================ Note 1.1 MUL, DIV, ASH for Falcon(+) 1 of 6 JAWS::KAISER 144 lines 25-MAR-1985 09:13 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 001 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: MUL,DIV and ASH Instruction for the FALCON | Date: 13-APR-84 | | and the FALCON-PLUS | | +----------------------------------------------------+-----------------+ | Originator: Charlie Giorgetti | Page 1 of 4 | +----------------------------------------------------+-----------------+ There is no hardware support for the EIS, FIS, or FPP instruction sets. For FALCON SBC-11/21 applications that need the ability to perform the EIS instructions MUL, DIV, and ASH, equivalent software routines can be substituted. These callable routines do not do any form of error checking. A user should be aware that extensive use of these software routines for hardware instructions will have impact on system performance. These routines can be incorporated into an application and called as a subroutine. The calling sequence for the subroutines can be set-up in a macro. The following is a list of each of the subroutines and the macros that are used to set-up and call the software MUL, DIV, and ASH routines. Page 2 The following macro and subroutine can be used to perform the MUL instruction in software: .MACRO SMUL A,B,HI,LO MOV A,-(SP) ; Push a multiplier onto the stack MOV B,-(SP) ; Push the other multiplier as well JSR PC,$MUL ; Call the MUL subroutine MOV (SP)+,HI ; Get the most significant part of the result MOV (SP)+,LO ; Get the least significant part of the result .ENDM $MUL:: MOV R0,-(SP) ; Save some work registers MOV R1,-(SP) MOV 10(SP),R1 ; Obtain the value of A from the stack MOV #21,-(SP) ; Initialize the shift counter CLR R0 ; Initialize the high 16-bit accumulator 10$: ROR R0 ; Perform multiplication ROR R1 BCC 20$ ADD 10(SP),R0 CLC 20$: DEC (SP) ; Bump the shift counter BNE 10$ ; Not done ? TST (SP)+ ; Romove the counter from the stack MOV R1,10(SP) ; Save the low 16-bit value on the stack MOV R0,6(SP) ; Save the high 16-bit value on the stack MOV (SP)+,R1 ; Restore the work registers MOV (SP)+,R0 RTS PC ; Return Page 3 The following macro and subroutine can be used to perform the DIV instruction in software: .MACRO SDIV DIVSOR,DIVHI,DIVLO,REM,QUO MOV DIVSOR,-(SP); Push the divisor onto the stack MOV DIVHI,-(SP) ; Push the upper 16-bits of the dividend MOV DIVLO,-(SP) ; Push the lower 16-bits of the dividend JSR PC,$DIV ; Call the DIV subroutine MOV (SP)+,REM ; Get the remainder MOV (SP)+,QUO ; Get the quotient .ENDM $DIV:: MOV R5,-(SP) ; Get some work registers MOV R4,-(SP) MOV R3,-(SP) MOV R0,-(SP) MOV 14.(SP),R3 ; Get the divisor from the stack MOV 12.(SP),R4 ; Get the high 16-bits of the dividend MOV 10.(SP),R5 ; as well as low 16-bits CLR R0 ; Clear an accumulator MOV #32.,-(SP) ; Shift counter 1$: ASL R5 ; Perform the division ROL R4 ROL R0 CMP R0,R3 BLO 2$ SUB R3,R0 INC R5 2$: DEC (SP) BNE 1$ ; Not done ? TST (SP)+ ; Remove the counter from the stack MOV R0,12.(SP) ; Store the remainder on the stack MOV R5,14.(SP) ; Store the quotient as well MOV (SP)+,R0 ; Restore the work registers MOV (SP)+,R3 MOV (SP)+,R4 MOV (SP)+,R5 MOV (SP)+,(SP) ; Update the return PC RTS PC ; Return Page 4 The following macro and subroutine can be used to perform the ASH instruction in software: .MACRO SASH COUNT,VAL MOV COUNT,-(SP) ; Push the shift count MOV VAL,-(SP) ; Push what is to be shifted JSR PC,$ASH ; Call the ASH subroutine MOV (SP)+,VAL ; Get the results of the shift .ENDM $SASH:: MOV R0,-(SP) ; Get a couple of work registers MOV R1,-(SP) MOV 6(SP),R0 ; R0 = value to be shifted MOV 8.(SP),R1 ; R1 = direction and shift count BIC #^C<77>,R1 BEQ 20$ ; Get out if no shifting CMP R1,#31. ; What direction is the shift BGT 10$ ; go to the corection direction shift 5$: ASL R0 DEC R1 BNE 5$ BR 20$ 10$: NEG R1 BIC #^C<77>,R1 11$: ASR R0 DEC R1 BNE 11$ 20$: MOV R0,8.(SP) ; Store the shifted result on the stack MOV (SP)+,R1 ; Restore the work registers MOV (SP)+,R0 MOV (SP)+,(SP) ; Update the return PC RTS PC ; Return ================================================================================ Note 1.2 MUL, DIV, ASH for Falcon(+) 2 of 6 FURILO::JACKSON 13 lines 5-SEP-1985 13:50 -------------------------------------------------------------------------------- There is a small problem with this notesfile in that I don't want people to WRITE notes in this file. (there is good reason to this that is mentioned in 1.0) Anyway, there may be issues that the users of this notesfile need to be concerned about, therefore I am creating a new notesfile for this purpose. The notesfile is located at: krystl::sys$notes:micronote_questions.not for those with pre-V4... KRYSTL::"SYS$NOTES:MICRONOTE_QUESTIONS.NOT" -bill ================================================================================ Note 1.3 MUL, DIV, ASH for Falcon(+) 3 of 6 KRYSTL::SYSTEM 21 lines 10-JAN-1986 13:13 -------------------------------------------------------------------------------- This notefile will be converted to the new VAX Notes format on Saturday, 25 January. This means that VNotes and Notes-11 users will be unable to access the file after that date. There is an effort underway to upgrade Notes-11 so that it can access new-format files. However, it is currently unknown when this new Notes-11 will be available. Also, VAX Notes requires VMS V4.2 (at least) to be installed on a system. See the notefile CLT""::SYS$NOTES:NOTESUTIL.NOT for more information on VAX Notes. In particular, note 530 explains how to install it, and gives the location of documentation. VAX Notes is currently scheduled for external field text on 17 January. At that point, the newest field-test version of VAX Notes will be made available internally. If the external field test is delayed, the conversion of this file will be delayed also. After the conversion, the old file will be write-locked. The last note in the old file will contain information on the converted file. Bill Jackson Keeper of Notes on KRYSTL ================================================================================ Note 1.4 MUL, DIV, ASH for Falcon(+) 4 of 6 PULSAR::SILVER 10 lines 12-JAN-1986 16:25 -------------------------------------------------------------------------------- Why???? Don't you want PDP users to be able to take advantage of your work?? There are lots of sites around who use NOTES-11 on PDP systems, since they don't have access to VMS systems. Why not wait a bit longer until the new NOTES-11 is available? - Craig Silver ================================================================================ Note 1.5 MUL, DIV, ASH for Falcon(+) 5 of 6 FURILO::JACKSON 12 lines 13-JAN-1986 08:34 -------------------------------------------------------------------------------- For the past few months, I've been running a batch job that checks for open notes files on this system. (there are several). Anyway, most of the users are now accessing this file with VNOTES (you can tell by the process name of the process that opens the file (either FAL or NOTES_XXXX_X)) Unfortunately, both notes systems are mutually exclusive. I created another files (MICRONOTE_QUESTIONS) a while ago for discussion of this very issue, noone responded. -bill jackson ================================================================================ Note 1.6 MUL, DIV, ASH for Falcon(+) 6 of 6 FURILO::JACKSON 8 lines 21-JAN-1986 11:57 -------------------------------------------------------------------------------- You may have noticed that the VNOTES server is not running on this machine. This is because we have installed VMS V4.2 on this system and have not (or do not intend to) reinsall VNOTES on this system. Notesfile conversion is taking place this saturday....... -bill ================================================================================ Note 2.0 Block Mode DMA 1 reply JAWS::KAISER 560 lines 25-MAR-1985 09:14 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 002 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: Block Mode DMA | Date: 01-JUN-83 | +----------------------------------------------------+-----------------+ | Originator: Scott Tincher and Mike Collins | Page 1 of 11 | +----------------------------------------------------+-----------------+ What is Block Mode DMA? ----------------------- Block Mode DMA is a method of data transfer which increases throughput due to the reduced handshaking necessary over the Q-bus. In order to implement Block Mode DMA both the master and slave devices must understand the block Mode protocol. If either device does not have Block Mode capability the transfers proceed via standard DATI or DATO cycles. Conventional Direct Memory Access on the Q-bus ---------------------------------------------- Under conventional DMA operations, after a DMA device has become bus master, it begins the data transfers. This is accomplished by gating an address onto the bus followed by the data being transferred to or from the memory device. If more than one transfer is performed by the temporary bus master, the address portion of the cycle must be repeated for each data transfer. Block Mode Direct Memory Access on the Q-bus -------------------------------------------- Under block Mode DMA operations an address cycle is followed by multiple word transfers to sequential addresses. Therefore data throughput is increased due to the elimination of the address portion of each transfer after the initial transfer. There are two types of block Mode transfer, DATBI (input) and DATBO (output). An overview of what occurs during each type of block Mode transfer is outlined in figures 1 (DATBI, Block Mode input) and 2 (DATBO, block mode output). In the following discussion the signal prefix T(Transmit) indicates a bus driver input and the signal prefix R(Receive) indicates a bus receiver output. Page 2 DATBI Bus Cycle --------------- Before a DATBI block mode transfer can occur the DMA bus master device must request control of the bus. This occurs under conventional Q-bus protocol. o REQUEST BUS The bus master device requests control of the bus by asserting TDMR. o GRANT BUS CONTROL The bus arbitration logic in the CPU asserts the DMA grant signal TDMGO 0 nsec minimum after TDMR is received and 0 nsec minimum after RSACK negates (if a DMA device was previous bus master). o ACKNOWLEDGE BUS MASTERSHIP The DMA bus master device asserts TSACK 0 nsec minimum after receiving RDMGI, 0 nsec minimum after the negation of RSYNC and 0 nsec minimum after the negation of RRPLY. The DMA bus master device negates TDMR 0 nsec minimum after the assertion of TSACK. o TERMINATE GRANT SEQUENCE The bus arbitration logic in the CPU negates TDMGO 0 nsec minimum after receiving RSACK. The bus arbitration logic will also negate TDMGO if RDMR negates or if RSACK fails to assert within 10 usec ('no SACK timeout'). o EXECUTE A BLOCK MODE DATBI TRANSFER o ADDRESS DEVICE MEMORY a) The address is asserted by the bus master on TADDR<21:00> along with the negation of TWTBT. b) The bus master asserts TSYNC 150 nsec minimum after gating the address onto the bus. o DECODE ADDRESS The appropriate memory device recognizes that it must respond to the address on the bus. o REQUEST DATA a) The address is removed by the bus master from TADDR<21:00> 100 nsec minimum after the assertion of TSYNC. b) The bus master asserts the first TDIN 100 nsec minimum after asserting TSYNC. Page 3 c) The bus master asserts TBS7 50 nsec maximum after asserting TDIN for the first time. TBS7 remains asserted until 50 nsec maximum after the assertion of TDIN for the last time. In each case, TBS7 can be asserted or negated as soon as the conditions for asserting TDIN are met. The assertion of TBS7 indicates the bus master is requesting another read cycle after the current read cycle. o SEND DATA a) The bus slave asserts TRPLY 0 nsec minimum (8000 nsec maximum to avoid a bus timeout) after receiving RDIN. b) The bus slave asserts TREF concurrent with TRPLY if, and only if, it is a block mode device which can support another RDIN after the current RDIN. NOTE Block mode transfers must not cross 16 word boundaries c) The bus slave gates TDATA<15:00> onto the bus 0 nsec minimum after receiving RDIN and 125 nsec maximum after the assertion of TRPLY. o TERMINATE INPUT TRANSFER a) The bus master receives stable RDATA<15:00> from 200 nsec maximum after receiving RRPLY until 20 nsec minimum after the negation of RDIN. (The 20 nsec minimum represents total minimum receiver delays for RDIN at the slave and RDATA<15:00> at the master.) b) The bus master negates TDIN 200 nsec minimum after receiving RRPLY. o OPERATION COMPLETED a) The bus slave negates TRPLY 0 nsec minimum after receiving the negation of RDIN. b) If RBS7 and TREF are both asserted when TRPLY negates, the bus slave prepares for another DIN cycle. RBS7 is stable from 125 nsec after RDIN is received until 150 nsec after TRPLY negates. c) If TBS7 and RREF were both asserted when TDIN negated, the bus master asserts TDIN 150 nsec minimum after receiving the negation of RRPLY and continues with timing relationship 'SEND DATA' above. RREF is stable from 75 nsec after RRPLY asserts until 20 nsec minimum after TDIN negates. (The 0 nsec minimum represents total minimum receiver delays for RDIN at the slave and RREF at the master.) Page 4 NOTE The bus master must limit itself to not more than eight transfers unless it monitors RDMR. If it monitors RDMR, it may perform up to 16 transfers as long as RDMR is not asserted at the end of the seventh transfer. o TERMINATE BUS CYCLE a) If RBS7 and TREF were not both asserted when TRPLY negated, the bus slave removes TDATA<15:00> from the bus 0 nsec minimum and 100 nsec maximum after negating TRPLY. b) If TBS7 and RREF were not both asserted when TDIN negated the bus master negates TSYNC 250 nsec minimum after receiving the last assertion of RRPLY and 0 nsec minimum after the negation of that RRPLY. o RELEASE THE BUS a) The DMA bus master negates TSACK 0 nsec after negation of the last RRPLY. b) The DMA bus master negates TSYNC 300 nsec maximum after it negates TSACK. c) The DMA bus master must remove RDATA<15:00>, TBS7, and TWTBT from the bus 100 nsec maximum after clearing TSYNC. o RESUME PROCESSOR OPERATION The bus arbitration logic in the CPU enables processor-generated TSYNC or will issue another bus grant (TDMGO) if RDMR is asserted. Page 5 Figure 1 - DATBI CYCLE ---------------------- PROCESSOR I/O DEVICE MEMORY --------- ---------- ------ +- Request Bus | ----------- | Assert TDMR Grant Bus Control <--+ ----------------- . Near end of the current bus cycle (RRPLY is negated) assert TDMGO and inhibit new processor generated TSYNC for the duration of the DMA operation | | +----> Acknowledge Bus Mastership -------------------------- . Receive RDMGO . Wait for negation of RSYNC and RRPLY . Assert TSACK +--------- . Negate TDMR | V Terminate Grant Sequence ------------------------ . Negated RDMGO and wait for DMA operation to be completed | | +--> Execute a Block Mode DMA ------------------------ (DATBI) Data Transfer --------------------- . . . Address Device Memory --------------------- . Assert address on TADDR<21:00> . Assert TSYNC . Negate TWTBT -------+ | +---> Decode Address -------------- . Store "Device Selected" operation Page 6 Figure 1 - DATBI CYCLE (continued) ---------------------------------- PROCESSOR I/O DEVICE MEMORY --------- ---------- ------ +----> Request Data | ------------ | . Remove address from TADDR<21:00> | . Assert TDIN | . Assert TBS7 (request for an | additional DIN cycle after | the current one | | | +-----------> Send Data | --------- | . Data on TDATA<15:00> | . Assert TRPLY | . Assert TREF (to | indicates block | mode capability) | | | Terminate Input <---------+ | --------------- | Transfer | -------- | . Accept data and respond | by negating TDIN | | | +------> Operation Completed | ------------------- | . Negate TRPLY | | | +-----------+ | yes | are | +------------------------|RBS7 & TREF| | Asserted | | ? | +-----------+ | no Terminate Bus Cycle <------+ ------------------- and Release the Bus ------------------- . Negate TSACK . Negate TSYNC . Remove TDAL, TBS7, and, +----- TWTBT from the Bus | V Resume Processor Operation -------------------------- . Enable processor generated TSYNC or issue another grant if RDMR is asserted Page 7 DATBO Bus Cycle --------------- DATBO Bus cycles Before a block mode transfer can occur the DMA bus master device must request control of the bus. This occurs under conventional Q-bus protocol. o REQUEST BUS The bus master device requests control of the bus by asserting TDMR. o GRANT BUS CONTROL The bus arbitration logic in the CPU asserts the DMA grant signal TDMGO 0 nsec minimum after RDMR is received and 0 nsec minimum after TSACK negates (if a DMA device was previous bus master). o ACKNOWLEDGE BUS MASTERSHIP The DMA bus master device asserts TSACK 0 nsec minimum after receiving RDMGI, 0 nsec minimum after the negation of RSYNC and 0 nsec minimum after the negation of RRPLY. The DMA bus master device negates TDMR 0 nsec minimum after the assertion of TSACK. o TERMINATE GRANT SEQUENCE The bus arbitration logic in the CPU negates TDMGO 0 nsec minimum after receiving RSACK. The bus arbitration logic will also negate TDMGO if RDMR negates or if RSACK fails to assert within 10 usec ('no SACK timeout'). o EXECUTE A BLOCK MODE DATBO TRANSFER o ADDRESS DEVICE MEMORY a) The address is asserted by the bus master on TADDR<21:00> along with the assertion of TWTBT. b) The bus master asserts TSYNC 150 nsec minimum after gating the address onto the bus. o DECODE ADDRESS The appropriate memory device recognizes that it must respond to the address on the bus. o SEND DATA a) The bus master gates TDATA<15:00> along with TWTBT 100 nsec minimum after the assertion of TSYNC. TWTBT is negated. b) The bus master asserts the first TDOUT 100 nsec minimum after gating TDATA<15:00>. NOTE During DATBO cycles TBS7 is undefined o RECEIVE DATA a) The bus slave receives stable data on RDATA<15:00> from Page 8 25 nsec minimum before receiving RDOUT until 25 nsec minimum after receiving the negation of RDOUT. b) The bus slave asserts TRPLY 0 nsec minimum after receiving RDOUT. c) The bus slave asserts TREF concurrent with TRPLY if, and only if, it is a block mode device which can support another RDOUT after the current RDOUT. NOTE Blockmode transfers must not cross 16 word boundaries o TERMINATE OUTPUT TRANSFER The bus master negates TDOUT 150 nsec minimum after receiving RRPLY. o OPERATION COMPLETED a) The bus slave negates TRPLY 0 nsec minimum after receiving the negation of RDOUT. b) If RREF was asserted when TDOUT negated and if the bus master wants to transfer another word, the bus master gates the new data on TDATA<15:00> 100 nsec minimum after negating TDOUT. RREF is stable from 75 nsec maximum after RRPLY asserts until 20 nsec minimum after RDOUT negates. (The 20 nsec minimum represents minimum receiver delays for RDOUT at the slave and RREF at the master). c) The bus master asserts TDOUT 100 nsec minimum after gating new data on TDATA<15:00> and 150 nsec minimum after receiving the negation of RRPLY. The cycle continues with the timing relationship in 'RECEIVE DATA' above. NOTE The bus master must limit itself to not more than eight transfers unless it monitors RDMR. If it monitors RDMR, it may perform up to 16 transfers as long as RDMR is not asserted at the end of the seventh transfer. o TERMINATE BUS CYCLE a) If RREF was not asserted when RRPLY negated or if the bus master has no additional data to transfer, the bus master removes data on TDATA<15:00> from the bus 100 nsec minimum after negating TDOUT. b) If RREF was not asserted when TDOUT negated the bus master negates TSYNC 275 nsec minimum after receiving the last RRPLY and 0 nsec minimum after the the negation of the last RRPLY. Page 9 o RELEASE THE BUS a) The DMA bus master negates TSACK 0 nsec after negation of the last RRPLY. b) The DMA bus master negates TSYNC 300 nsec maximum after it negates TSACK. c) The DMA bus master must remove TDATA, TBS7, and TWTBT from the bus 100 nsec maximum after clearing TSYNC. o RESUME PROCESSOR OPERATION The bus arbitration logic in the CPU enables processor-generated TSYNC or will issue another bus grant (TDMGO) if RDMR is asserted. Page 10 Figure 2 - DATBO CYCLE ---------------------- PROCESSOR I/O DEVICE MEMORY --------- ---------- ------ +- Request Bus | ----------- | . Assert TDMR Grant Bus Control <----+ ----------------- . Near the end of the current bus cycle (RRPLY is negated) assert TDMGO and inhibit new processor generated TSYNC for the duration of the DMA operation. | | +-------> Acknowledge Bus Mastership -------------------------- . Receive RDMG . Wait for negation of RSYNC and RRPLY . Assert TSACK +-------- . Negate TDMR | V Terminate Grant Sequence ------------------------ . Negate TDMGO and wait for DMA operation to be completed. | +---------> Execute A Block Mode DMA ------------------------- (DATBO) Data Transfer --------------------- . . . Address Memory -------------- . Assert Address on TADDR<21:00> . Assert TWTBT . Assert TSYNC ------+ | +-----> Decode Address -------------- . Address match selects device Page 11 Figure 2 - DATBO CYCLE (continued) ---------------------------------- PROCESSOR I/O DEVICE MEMORY --------- ---------- ------ +----> Send Data | --------- | . Assert TDATA <15:00> | . Negate TWTBT | . Assert TDOUT ----+ | | | +--> Receive Data | ------------ | . Accept data and | RWTBT | . Assert TRPLY | . Assert TREF | (Indicates block | mode capability) | | | | | Terminate Output Transfer <-----+ | ------------------------- | | . Negate TDOUT --+ | | | +--> Operation Completed | ------------------- | . Negate TRPLY | | | +------------------+ +----------+ yes | | Does Master | yes | is RREF | +-| Wish to Transfer |<-----|Asserted ?| | More Data ? | +----------+ +------------------+ | no | | Terminate Bus Cycle and <-------+ ----------------------- Release the Bus --------------- . Negate TSACK . Negate TSYNC +----- . Remove TDAL, TDAL,TBS7, and TWTBT | from the Bus | | Resume Processor Operation -------------------------- . Enable processor generated TSYNC (processor is bus master) or issue another grant if RDMR is asserted ================================================================================ Note 2.1 Block Mode DMA 1 of 1 MOTHER::FRAZIER 12 lines 4-JUN-1985 14:48 -------------------------------------------------------------------------------- I'd like to point out a potential problem. The MXV11-B has been promoted as a usable companion for the KDJ11-AA. However the MXV11-B does NOT support "Block Mode" transfers. The MXV11-B also must have a starting address within the first 265kb. So now the ring buffer for the RQDX1/2 is in non-block mode memory. The results are predictably disastrous. James ================================================================================ Note 3.0 LSI-11/73 Bootstraps No replies JAWS::KAISER 114 lines 25-MAR-1985 09:14 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 003 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: Compatible Bootstraps for the LSI-11/73 | Date: 28-NOV-83 | +----------------------------------------------------+-----------------+ | Originator: Mike Collins | Page 1 of 2 | +----------------------------------------------------+-----------------+ The LSI-11/73 (KDJ11-AA) is a high performance CPU for the Q-Bus. It is a CPU only, which means that there is no boot capability on the module itself. Therefore a boot module must be selected to work with the LSI-11/73. This uNOTE will discuss the bootstrap modules which can be used with the 11/73. There are 4 possible modules which can be used for bootstrap. They are : MXV11-BF w/MXV11-B2 boot ROMs MRV11-D w/MXV11-B2 boot ROMs MXV11-AA or -AC w/MXV11-A2 boot ROMs BDV11 For an LSI-11/73 based system to be Field Serviceable the bootstrap code must execute a cache memory diagnostic on power-up. The only boot code which satisfies this requirement is found in the MXV11-B2 boot ROMs. Therefore an LSI-11/73 based, Field Serviceable system must use either the MXV11-BF w/MXV11-B2 ROMs or the MRV11-D w/MXV11-B2 ROMs. NOTE The MXV11-B2 ROMs will not work on the MXV11-A module. MXV11-BF or MRV11-D w/MXV11-B2 ROMs ----------------------------------- The MXV11-BF w/MXV11-B2 ROMs is the preferred choice since this module has 2 asynchronous serial lines as well as 128Kb of dynamic RAM in addition to the boot capability. However, if your application does not need the extra serial lines and RAM, an alternate choice would be the MRV11-D w/MXV11-B2 ROMs. The MXV11-B2 ROMs will boot the following devices : RLO1 / RLO2 (DL) RXO1 / RXO2 (DX,DY) TU58 (DD) TSV05 (MS) MSCP type Devices e.g. RD51, RX50 (DU) DECnet via DPV11, DLV11-E, DLV11-F, DUV11 Page 2 NOTE The MXV11-BF is not supported by RSTS due to its non-parity memory. An alternative configuration would be to use the MRV11-D with the MXV11-B2 boot ROMs, and a DLV11-J or other DLV11 serial line device. The remaining 2 boot modules do NOT have the necessary cache memory diagnostic code to make an 11/73 based system Field Serviceable. Below is a list of all of the KNOWN WORKING bootstraps for the 2 remaining boot modules. MXV11-A w/MXV11-A2 ROMs ----------------------- Working bootstraps : RLO1 / RLO2 RXO1 / RXO2 TU58 conventional boot TU58 standalone boot WARNING If the MXV11-A is used in a 22 bit system the on-board RAM must be disabled. Refer to uNOTE 106. BDV11 ----- Working bootstraps : RLO1 / RLO2 RXO2 RK05 WARNING Disable the processor and memory tests since an odd address trap does occur in each of them. See NOTE below. To disable the CPU test, set switch E15-1 to OFF. To disable the memory test, set switch E15-2 to OFF. (Refer to the Microcomputer and Interfaces Handbook for complete configuration information.) The 11/73 has an on-board Line Time Clock Register, therefore the BDV11 BEVNT switch E21-5 should be set to the OPEN position. This disables software control of the BEVNT signal via the BDV11 LTC register and allows software control of this signal via the 11/73 LTC register. If the BDV11 is used in a 22 bit system, it must be CS REV E or later or ECO M8012-ML0005 must be installed. NOTE ODD ADDRESS TRAPS. The 11/23 ignores an odd address reference whereas the KDJ11-A will trap to address 4. ================================================================================ Note 4.0 LSI-11/73 Upgrade Paths No replies JAWS::KAISER 300 lines 25-MAR-1985 09:15 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE #004 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: LSI-11/73 Upgrade Paths | Date: 28-NOV-83 | +----------------------------------------------------+-----------------+ | Originator: Mike Collins | Page 1 of 6 | +----------------------------------------------------+-----------------+ With the announcement of the KDJ11-A CPU module, there will be numerous questions regarding configuring the module into a current system. The purpose of this MicroNote is to address all possible configuration upgrade paths (within reason). Generally a KDJ11-A will be installed as an upgrade to a system built from components or DEC packaged system. In the case of a component upgrade it is assumed the processor is a KDF11-A and the boot mechanism is an MXV11-A with the MXV11-A2 Boot ROMs. System upgrades fall into 2 categories: 1. KDF11-A based systems and 2. KDF11-B based systems (11/23+ and Micro/PDP-11) There are 3 issues which must be addressed when considering a KDJ11-A upgrade. They are: 1. The Boot mechanism 2. 18 or 22 bit system 3. Single or multiple box system NOTE 1. In the following upgrade scenarios, the systems have been labeled as being Field Serviceable or not. A system which is Field Serviceable has a bootstrap which meets Field Service requirements. The requirement is that the bootstrap must execute an 11/73 cache memory diagnostic on power-up. There is no guarantee that the overall system will be Field Serviceable or that it will be FCC compliant. 2. Systems using CPU's other than the KDF11-A or KDF11-B (i.e. 11/03 systems) are not considered for upgrade. CAUTION: It is recommended that the AC and DC loading for the final configuration be checked for conformance with the Q-Bus loading rules. It is also recommended to check for overloading on the +5 Volt and +12 Volt Power Supplies. Page 2 For each system upgrade the following parameters are listed for both the 'Current' system and the 'Upgraded' system: 1. CPU 2. Boot Mechanism 3. System Size 4. Number of Boxes 5. Field Serviceable or not 6. Special Conditions COMPONENT UPGRADE PATHS: ----------------------- 1. Current System Upgrade 1 -------------- --------- KDF11-A KDJ11-A MXV11-A MXV11-B/MRV11-D with MXV11-B2 Boot ROMs 18 Bit System 18 Bit System 1 Box 1 Box Field Serviceable Upgrade 2 --------- KDJ11-A MXV11-A 18 Bit System 1 Box NOT Field Serviceable 2. Current System Upgrade -------------- ------- KDF11-A See upgrades for category 1 MXV11-A 18 Bit System More than 1 box 3. Current System Upgrade -------------- ------- KDF11-A See upgrades for category 1 MXV11-A (Memory Disabled) 22 Bit System 1 Box 4. Current System Upgrade -------------- ------- KDF11-A Not currently configureable with MXV11-A (Memory Disabled) DEC equipment. 22 Bit System More than 1 box This system is not currently configureable with DEC equipment. Page 3 PDP 11/23A SYSTEM UPGRADE PATHS: ------------------------------- 5. Current System Upgrade 1 -------------- --------- KDF11-A KDJ11-A BDV11 MXV11-B/MRV11-D with MXV11-B2 Boot ROMs 18 Bit System 18 Bit System 1 Box 1 Box Field Serviceable Upgrade 2 --------- KDJ11-A BDV11 18 Bit System 1 Box NOT Field Serviceable Disable the Processor and Memory tests and also the BEVNT register on the BDV11. Upgrade 3 --------- KDJ11-A MXV11-A (with MXV11-A2 boot ROMs) 18 Bit System 1 Box System NOT Field Serviceable Check AC loading since termination was removed when the BDV11 was removed from the system. 6. Current System Upgrade 1 -------------- --------- KDF11-A KDJ11-A BDV11 MXV11-B/MRV11-D with MXV11-B2 Boot ROMs 18 Bit System 18 Bit System More than 1 Box More than 1 box Field Serviceable Use BCV1A and BCV1B expansion cables. Upgrade 2 --------- KDJ11-A BDV11 18 Bit System More than 1 Box NOT Field Serviceable Disable the Processor and Memory tests and also the BEVNT register on the BDV11. Use BCV1B cable set between 1st and 2nd box and the BCV1A cable set between the 2nd and 3rd box. Note: If in a 3 box system the expansion cable set lengths must differ by 4 ft. Page 4 Upgrade 3 --------- KDJ11-A MXV11-A (with MXV11-A2 boot ROMs) 18 Bit System More than 1 Box NOT Field Serviceable Use BCV1A and BCV1B expansion cables. 7. Current System -------------- KDF11-A BDV11 22 Bit System 1 Box Systems with this configuration were never shipped by DEC. PDP 11/23 PLUS SYSTEM UPGRADE PATHS: ----------------------------------- 8. Current System Upgrade 1 -------------- --------- KDF11-B KDJ11-A Boot is on CPU MXV11-B/MRV11-D with MXV11-B2 Boot ROMs 22 Bit System 22 Bit System 1 Box System 1 Box Field Serviceable Upgrade 2 --------- KDJ11-A MXV11-A (with MXV11-A2 boot ROMs) 22 Bit System 1 Box NOT Field Serviceable Must disable RAM on MXV11-A. Upgrade 3 --------- KDJ11-A BDV11 22 Bit System 1 Box System NOT Field Serviceable Must have BDV11 ECO M8012-ML005 installed. Disable the Processor and Memory tests and also the BEVNT register on the BDV11. Page 5 9. Current System Upgrade 1 -------------- --------- KDF11-B Not currently configureable with Boot is on CPU DEC equipment. 22 Bit System More than 1 Box Upgrade 2 --------- Not currently configureable with DEC equipment. Upgrade 3 --------- Not currently configureable with DEC equipment. MICRO/PDP-11 SYSTEM UPGRADE PATHS: --------------------------------- 10. Current System Upgrade -------------- ------- Micro/PDP-11 Same as 11/23+ rules, see category KDF11-BE 8, Upgrade 1. Upgrades 2 and Boot is on CPU 3 are not recommended since the 22 Bit System MXV11-A and BDV11 cannot boot the 1 Box system 5 1/4" media in the Micro/PDP-11. 11. Current System Upgrade -------------- ------- Micro/PDP-11 Same as 11/23+ rules, see upgrades KDF11-BE for category 9. Boot is on CPU 22 Bit System More than 1 box NOTE It is not currently possible to expand out of the Micro/PDP-11 while maintaining FCC compliance. 11/23 PLUS and Micro/PDP-11 system upgrades will require an EXTRA backplane slot to accomodate the additional boot module (i.e. MXV11-A,-B or BDV11). Page 6 11/23-S SYSTEM UPGRADE SOLUTIONS: -------------------------------- 12. Current System Upgrade -------------- ------- KDF11-BA See upgrades for category 5. Boot is on CPU 18 Bit System 1 Box system 13. Current System Upgrade -------------- ------- KDF11-BA See upgrades for category 6. Boot is on CPU 18 Bit system More than 1 box NOTE It is not currently possible to expand out of the 11/23-S while maintaining FCC compliance. ================================================================================ Note 5.0 Q22 Compatible Options No replies JAWS::KAISER 319 lines 25-MAR-1985 09:15 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 005 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: Q22 Compatible Options | Date: 23-Apr-84 | +----------------------------------------------------+-----------------+ | Originator: Charlie Giorgetti | Page 1 of 6 | +----------------------------------------------------+-----------------+ This is a list of Q22 compatible options. A Q22 compatible option is defined as a Q-bus option that will work without restriction in an extended Q-bus system, that is a 22-bit Q-bus system. This list also includes options that are not compatible in Q22 systems and the reason for the restriction. The requirements for a device to be Q22 compatible are the following: 1. Processors, memories, and DMA devices must all be capable of 22-bit addressing. 2. Devices must use backplane pins BC1, BD1, BE1, BF1 and DC1, DD1, DE1, DF1, for BDAL18-21 only. Processors, memories, or DMA devices which are not capable of 22-bit addressing may generate or decode erroneous addresses if they are used in systems which implement 22-bit addressing. Memory and memory-addressing devices which implement only 16 or 18-bit addressing may be used in a 22-bit backplane, but the size of the system memory must be restricted to the address range of those devices (64 KB for systems with 16-bit devices and 256 KB for systems with an 18-bit devices). Any device which uses backplane pins BC1, BD1, BE1, BF1 or DC1, DD1, DE1, DF1, for purposes other than BDAL18-21 is electrically incompatible with the 22-bit bus and may not be used without modification. NOTE Eighteen or sixteen bit DMA devices can potenitially work in Q22 systems by buffering I/O in the 18- or 16-bit address space. I. Fully Compatible Options Options in this category meet both of the requirements mentioned above and may be used in any Q-bus configuration. A. Processors KD32-A M7135/M7136 MicroVAX I CPU Module KDF11-A M8186 LSI-11/23 CPU (Etch Rev. C or later) Page 2 KDF11-B M8189 LSI-11/23B CPU KDJ11-A M8192 LSI-11/73 CPU KDJ11-B M8190 MicroPDP-11/73 CPU KXT11-C M8377 Q-bus Perpherial I/O Processor KMV11-A M7500 Q-bus Perpherial Communication Processor B. Backplanes/Boxes H9270-Q 4 X 4 Q22/Q22 Backplane H9281-QA 2 X 4 Q22 Dual-height Backplane H9281-QB 2 X 8 Q22 Dual-height Backplane H9281-QC 2 X 12 Q22 Dual-height Backplane H9275 4 X 9 Q22/Q22 Backplane BA11-S H9276 4 X 9 Q22/CD Backplane Micro/PDP-11 H9278 4 X 3 Q22/CD and 4 X 5 Q22/Q22 Backplane C. Memory MCV11-D M8631 CMOS Non-volatile Memory MSV11-L M8059 MOS Memory (either 128 KB or 256 KB) MSV11-P M8067 MOS Memory (either 256 KB or 512 KB) MSV11-Q M7551 MOS Memory (1 MB) MXV11-B M7195 Multifunction Module MRV11-D M8578 PROM/ROM Module D. Options AAV11-C A6006 D/A Converter ADV11-C A8000 A/D Converter AXV11-C A0026 D/A and A/D Combination Converter BDV11 M8012 Bootstrap, Terminator, Diagnostic (CS Rev. E or later, ECO M8012-ML005 installed) DEQNA M7504 Ethernet Controller DLV11 M7940 Asynchronous Serial Line Interface Page 3 DLV11-E M8017 Asynchronous Serial Line Interface DLV11-F M8028 Asynchronous Serial Line Interface DLV11-J M8043 Four Asynchronous Serial Line Interfaces (CS Rev. E or later, ECO M8043-MR002 installed) DHV11 M3104 8-line Asynchronous EIA Multiplexer DMV11-AD M8053-MA Synchronous Communications Interface DMV11-AF M8064-MA Synchronous Communications Interface DPV11 M8020 Programmable Synchronous EIA Line DRV11 M7941 32 line Parallel Interface DRV11-J M8049 64 line Parallel Interface DRV11-W M7651 General Purpose DMA Interface (dual) DUV11 M7951 Programmable Synchronous EIA Line DZQ11 M3106 4-line Asynchronous EIA Multiplexer (dual) DZV11 M7957 4-line Asynchronous EIA Multiplexer (quad) FPF11 M8188 Floating Point Processor IBV11-A M7954 IEEE Instrument Bus Interface IEQ11 M8634 DMA IEEE Instrument Bus Interface KLESI-QA M7740 LESI Bus Adaptor (RC25 Interface) KPV11-A M8016 Power-fail and LTC Generator (KPV11-B and -C are not compatible) KWV11-C A4002 Programmable Real-time Clock LAV11 M7949 LA180 Line Printer Interface LPV11 M8027 LA180/LP05 Printer Interface RLV12 M8061 RL01/2 Controller RQDX1 M8639 Controller for 5.25" Floppy and Winchester RXV11 M7946 RX01 Floppy Disk Interface TQK25 M7605 Streaming Cartridge Tape Controller TSV05 M7196 Magnetic Tape Controller Page 4 E. Bus Cable-Cards M9404 Cable Connector M9404-YA Cable Connector with 240-Ohm Terminators M9405 Cable Connector M9405-YA Cable Connector with 120-Ohm Terminators II. Restricted Compatibility Options Options in this category do not meet one or both of the requirements for use in a 22-bit system. These options are incompatible with some or all 22-bit systems. A. Processors KDF11-A M8186 LSI-11/23 CPU (Prior to etch rev. C, 18-bit addressing only, and use of BC1,BD1,BE1,BF1 for purposes other than BDAL18-21) KD11-HA M7270 LSI-11/2 CPU (16-bit addressing only, and use of BC1,BD1, BE1,BF1 for purposes other than BDAL18-21) KD11-F M7264 LSI-11 CPU (16-bit addressing only, and use of DC1,DB1, DE1,DF1 for purposes other than BDAL18-21) KXT11-A M8063 SBC-11/21 CPU (16-bit addressing only) B. Backplanes/Boxes DDV11-B 6 X 9 Backplane (18-bit addressing only) BA11-M H9270 4 X 4 Backplane (18-bit addressing only) BA11-N H9273-A 4 X 9 Backplane (18-bit addressing only) BA11-VA H9281-A,B,C 2 X n Dual-height Backplane n = 4, 8, and 12 BA11-VA used the H9281-A (18-bit addressing only) VT103 4 X 4 Backplane (part number: 54-14008) (18-bit addressing only) Page 5 C. Memories MMV11-A G653 8 KB Core Memory (16-bit addressing only, Q-bus required on C/D backplane connectors) MRV11-AA M7942 ROM Module (16-bit addressing only) MRV11-BA M8021 UV PROM-RAM (16-bit addressing only) MRV11-C M8048 PROM/ROM Module (18-bit addressing only) MSV11-B M7944 8 KB bus refreshed RAM (16-bit addressing only) MSV11-C M7955 32 KB RAM (18-bit addressing only) MSV11-D,E M8044/M8045 8 KB, 16 KB, 32 KB, 64 KB RAM (18-bit addressing only) MXV11-A M8047 Multifunction Module (18-bit addressing only on memory, the memory can be disbales see uNte #106) D. Options AAV11 A6001 D/A Converter (Use of BC1 for purposes other than BDAL18) ADV11 A012 A/D Converter (Use of BC1 for purposes other than BDAL18) BDV11 M8012 Bootstrap/Terminator (CS Revision E or earlier 18 bits only) DLV11-J M8043 Serial Line Interface (CS Rev. E or earlier incompatible with KDF11-A and KDF11-B) DRV11-B M7950 General Purpose DMA Interface (quad) (18-bit DMA only) KPV11-B,C M8016-YB,YC Power-fail/line-time clock/terminator (Termination for 18-bits only) KUV11 M8018 Writable Control Store (For use with KD11-F processor only) KWV11-A M7952 Programmable real-time clock (Use of BC1 for purposes other than BDAL18) Page 6 REV11 M9400 Terminator, DMA refresh, bootstrap (Bootstrap for use with KD11-F and KD11-HA processors only. Termination for 18-bits only. DMA refresh may be used in any system.) RKV11-D M7269 RK05 Controller Interface (16-bit DMA only) RLV11 M8013 RL01,2 Controller M8014 (18-bit DMA only, use of BC1 and BD1 for purposes other than BDAL18 and BDAL19) RXV21 M8029 RX02 Floppy Disk Interface (18-bit DMA only) TEV11 M9400-YB 120-Ohm Bus Terminator (Termination for 18-bits only) VSV11 M7064 Graphics Display (18-bit DMA only) E. Bus Cable-Cards M9400-YD Cable Connector (18-bit bus only) M9400-YE Cable Connector with 240-Ohm Terminators (18-bit bus only) M9401 Cable Connector (18-bit bus only) ================================================================================ Note 6.0 LSI-11/23 & 11/73 Differences No replies JAWS::KAISER 413 lines 25-MAR-1985 09:15 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 006 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: Differences Between | Date: 23-APR-84 | | the LSI-11/73 and LSI-11/23 | | +----------------------------------------------------+-----------------+ | Originator: Mike Collins | Page 1 of 8 | +----------------------------------------------------+-----------------+ This MicroNote identifies and discusses the differences between the LSI-11/23 (KDF11-AA) and the LSI-11/73 (KDJ11-AA). The following table lists these differences. Following the table are individual discussions on these differences. Some of these differences are discussed from the point of view of an 11/23 to 11/73 upgrade. Table 1 LSI-11/73 versus LSI-11/23 +--------------------------+-----------------------+---------------------+ | FEATURE | 11/73 | 11/23 | +==========================+=======================+=====================+ | Odd Address Traps | Yes | No | +--------------------------+-----------------------+---------------------+ | Micro ODT | 22 Bit | 18 Bit | +--------------------------+-----------------------+---------------------+ | Illegal Halt | Traps to 4 | Traps to 10 | +--------------------------+-----------------------+---------------------+ | Processor Modes | 3 | 2 | +--------------------------+-----------------------+---------------------+ | I & D Space | Yes | No | +--------------------------+-----------------------+---------------------+ | General Purpose Reg Sets | 2 | 1 | +--------------------------+-----------------------+---------------------+ | Floating Point Inst. Set | Standard | Option | +--------------------------+-----------------------+---------------------+ | Line Time Clock Reg. | Yes | No | +--------------------------+-----------------------+---------------------+ | On-board Cache Memory | Yes | No | +--------------------------+-----------------------+---------------------+ | Pipelined Processing | Yes | No | +--------------------------+-----------------------+---------------------+ | UBMap Signal on the Q-bus| Not Available | Available | +--------------------------+-----------------------+---------------------+ | Additional Instructions | CSM, TSTSET, | Not | | Available | WRTLCK | Available | +--------------------------+-----------------------+---------------------+ cont'd Page 2 Table 1 cont'd LSI-11/73 versus LSI-11/23 +--------------------------+-----------------------+---------------------+ | FEATURE | 11/73 | 11/23 | +==========================+=======================+=====================+ | | | | | | CPU Error Register +----+ | | | Memory System Error Reg | | | Additional CPU Registers | Cache Control Reg | Not | | | Hit/Miss Reg | Available | | | Program Interrupt Req Reg | | | | Line Time Clock Reg | | | | Maintenance Reg +----+ | | | | | +--------------------------+-----------------------+---------------------+ | | A discussion of processor speed can | | Processor Speed | be found in the respective user guides | | | | | | | User Guide Part # | User Guide Part # | | | EK-KDJ1A-UG | EK-KDF11-UG | | | | | +--------------------------+-----------------------+---------------------+ ODD ADDRESS TRAPS The 11/73 processor will trap to 4 when it encounters an odd address reference. i.e. whenever an address begins on an odd byte boundary (least significant bit = 1). The 11/23 ignores odd address references and simply treats the LSB as a zero, effectively 'forcing' all addresses to begin on even byte boundaries. Odd address traps do not occur frequently, however it is possible for code to run on an 11/23 and NOT run on an 11/73 because of them. Fixes for these errors are straightforward. MICRO ODT (Octal Debugging Technique) Both the 11/23 and the 11/73 implement ODT in their microcode. The 11/23 can use ODT to examine main memory locations from 0 to 256 Kbytes, but no further. On the other hand, the 11/73 ODT can examine the full 4 Mbyte range of main memory. When accessing addresses in the I/O page with an 11/73, a full 22 bit address must be specified. Example: To look at the first instruction of the bootstrap code with an 11/73 it is necessary to type: @17773000/ or @7777777777773000/ NOT @773000/ This is NOT enough because only 18 bits have been specified. Page 3 ILLEGAL HALT The 11/23 and the 11/73 respond differently when detecting a halt instruction in user or supervisor mode. The 11/23 traps to address 10 whereas the 11/73 traps to address 4. The 11/73 also sets the Illegal Halt Bit in the CPU ERROR Register to indicate an Illegal Halt occurred. PROCESSOR MODES The 11/23 has two processor modes, KERNEL and USER. The 11/73 has three KERNEL, SUPERVISOR and USER. I and D SPACE The concept of I and D space is used in mapping information into separate physical memory segments, depending on whether the information is considered instructions (I) or data (D). The use of I and D space allows programs to exist in two virtual segments and effectively doubles the address available to the user from 64 Kbytes to 128 Kbytes. The 11/73 has the capability for I and D space whereas the 11/23 does not. To implement this feature, many more PAR/PDR pairs are necessary. The 11/73 has 48 PAR/PDR pairs, the 11/23 has only 16 PAR/PDR pairs. GENERAL PURPOSE REGISTER SETS The 11/23 and all previous LSI-11 processors have 1 set of general purpose registers, R0 thru R7. Some of these are used for special purposes. R7 is used as the program counter and R6 is used as the stack pointer. Internal to the 11/23 are 2 registers used for stack pointers, one for each processor mode). There are 5 additional registers R0 thru R5. The 11/73 has two sets of general purpose registers, listed in the table below. Only eight are visible to the user at any given time. There are two groups of six registers (R0 thru R5 and R0' thru R5'). The group currently being used is selected by bit 11 in the Processor Status Word (PSW). Only one stack pointer is visible to the user at any one time and is determined by bits 14 and 15 in the PSW. Register Number Designation 0 R0 R0' 1 R1 R1' 2 R2 R2' 3 R3 R3' 4 R4 R4' 5 R5 R5' *6 KSP SSP USP 7 PC * KSP = Kernel Stack Pointer SSP = Supervisor Stack Pointer USP = User Stack Pointer Page 4 FLOATING POINT INSTRUCTION SET Both the 11/23 and the 11/73 use the FP11 Floating Point Instruction Set. The FP11 Instruction Set is an option for the 11/23 (choice of either the KEF11 chip or the FPF11 floating point accelerator). The FP11 instruction set is part of the J11 microprocessor microcode and is therefore a standard feature of the 11/73. LINE TIME CLOCK REGISTER The original dual height 11/23 CPU does not have an LTC (Line Time Clock) register on the board. In 11/23 based systems the BDV11 boot module contains the LTC reg. In order to enable or disable LTC interrupts under software control, the 11/23 must write to this register over the Q-bus. +---------+ +---------+ | | | | | 11/23 | | LTC | | | | REG | | | | | | 1 | | | +--+ +--+ +--+ +--+ | 7 | | | | +----------------------------------------+ +------------- | 7 5 4 6 Q-bus +-------------------------------------------------------------- The 11/73 has an LTC register on the CPU board. This means that whenever the 11/73 wants to enable or disable LTC interrupts under software control it writes to this on-board register. The address of the LTC register (location 177546) is 'trapped' on the board and NEVER goes out onto the Q-bus. When the 11/73 is used in a system with a BDV11, it is recommended that software control over the LTC interrupts be disabled on the BDV11 (see uNOTE 114). +---------+ | | | 11/73 | | | | | | 177546 | +---------+ | | | +---------------------------------------------------------- | Q-bus +-------------------------------------------------------------- ON-BOARD CACHE MEMORY Cache memory systems are designed to increase CPU performance. The cache maintains copies of portions of main memory in very high-speed RAM and thus reduces access times significantly. Page 5 The 11/73 is the first Q-bus processor to implement a cache memory system. The cache is automatically enabled on power-up and its operation is transparent to software. However software can enable or disable the cache by writing to the Cache Control Register (CCR). When the cache is enabled, any information fetched from main memory will be 'cached' i.e. placed in the high-speed RAM. Information fetched from an I/O device will NOT be 'cached' (i.e. information fetched from an address in the I/O page). CAUTION : Digital Equipment Corporation does not support a system which uses shared or dual-ported memory on the Q-bus. However there are applications and non-DEC add-on hardware which do support such configurations. Consider the following: The system below uses an 11/73, has a certain amount of main memory as well as dual-ported memory. The cache is enabled and the following sequence of events occur: 1. The 11/73 reads a word from the dual-ported RAM at address A which contains the value X. The value is 'cached'. +---------+ +---------+ +---------+ | | | | | | | 11/73 | |_________| | EXTERNAL| | | +-----| A: X | <-+ | DEVICE | | | | |---------| | | | | A: X |<------+ | | | | | +---------+ | | | +---------+ | RAM | | | | Dual-Ported RAM | | +---------+ 2. The external device writes a new value, Y, into location A. +---------+ +---------+ +---------+ | | | | | | | 11/73 | |_________| | EXTERNAL| | | | A: Y | <---------- | DEVICE | | | |---------| | | | A: X | | | | | +---------+ | | +---------+ | RAM | | | | | +---------+ 3. The 11/73 references location A again, but finds that it is in the cache and therefore uses the 'old' value of X. But this is incorrect since the external device updated location A with the new value Y. This anomaly can be corrected in a number of ways. Page 6 A. Put the dual ported RAM somewhere in the I/O page since any I/O page reference always bypasses cache. If the amount of dual-ported RAM is large this may not be practical. B. The memory management unit contains several Page Descriptor Registers (PDRs). The PDRs contain information relative to page expansion, page length and access control. Bit 15 of each PDR is the Bypass Cache bit. If the PDR accessed during a relocation operation has this bit set the reference will go directly to main memory. Hits on reads or writes will result in invalidation of the accessed cache location. Enabling this bit in each PDR associated with the dual-ported memory will force these references to bypass cache. C. Whenever the processor reads from the dual-ported RAM, add extra code which will simply turn off the cache prior to the read and turn the cache back on after the read is complete. Turning the cache on and off can be done by setting the appropriate bits in the Cache Control Register. PIPELINED PROCESSING The 11/73 gets much of its performance by implementing a prefetch and predecode mechanism. The major benefit of this is that memory references are overlapped with internal operations which results in faster program execution. The 11/23 does not implement such a mechanism. CAUTION : This implementation is completely compatible with DEC hardware and software. However there are applications and non-DEC add-on hardware which may be confused. Such situations are easily corrected. The prefetch mechanism assumes sequential program flow; one instruction immediately follows the next. Whenever the program flow is not sequential (i.e. the PSW, CCR, PC or any memory management register is written) the pipeline is 'flushed'. If a non-DEC device does its own 'macro' memory management, the instruction flow may be confused. For example : A non-DEC device utilizes 2 ROM sets for boot code. Both ROM sets map over the same addresses but only 1 set is enabled at any instant in time. This is done via a ROM set enable CSR. Assume the boot code in ROM set X is executing. Instruction X + 1 is a MOV instruction to the ROM enable CSR to transfer program control to ROM set Y. The intent of the ROM code is for statement Y + 2 in ROM set 2 to be executed next. This will work OK with an 11/23. However because of the prefetch mechanism of the 11/73, the 11/73 will execute instruction X + 2 of ROM set 1, NOT ROM set 2. This particular boot method effectively does its own memory mapping and Page 7 since it is done at the 'macro' level and external to the J11 cpu, the pipeline is not 'flushed'. A simple solution is to include a NOP instruction after the instruction which updates the ROM enable CSR, or to use a branch instruction which effectively changes the PC and causes the pipeline to be 'flushed'. User Boot Device +---------+ +------------------------------------------+ | | | ROM X ROM Y | | 11/73 | | +-------+ +-------+ | | | | X | | Y | | | | | | X + 1 | | Y + 1 | | | | | | X + 2 | | Y + 2 | | | +---------+ | . | | . | | | | . | | . | | | Sequence of events : | . | | . | | | 1. ROM X is enabled. | X + n | | Y + n | | | | | | | | | 2. Instruction X + 1 enables | +-------+ +-------+ | ROM Y. | +----------------+ | | | ROM Enable CSR | | 3. Next instruction to be | +----------------+ | executed is Y + 2. +------------------------------------------+ MAP SIGNAL ON THE Q-BUS (UBMAP L) The 11/23 outputs the signal UBMAP onto the Q-bus. Some non-DEC add-on equipment may use this signal for special purposes. This signal is not defined by the Q-bus specification and for design reasons was not included on the 11/73. Therefore, the 11/73 may not work with non-DEC devices which expect to see this signal. ADDITIONAL INSTRUCTIONS AVAILABLE These 3 instructions are part of the 11/73 instruction set but are NOT found in the 11/23: CSM Call to Supervisor Mode TSTSET Test Destination and Set Low Bit WRTLCK Read/Lock Destination Write/Unlock R0 into Destination Page 8 ADDITIONAL CPU REGISTERS AVAILABLE The following CPU registers are part of the DCJ11 chip or implemented on the 11/73 module and are not found on the 11/23. CPU Error Register Memory System Error Register Cache Control Register Hit/Miss Register Additional PAR/PDR's necessary to implement I & D Space Program Interrupt Request Register Line Time Clock Register (previously discussed) Maintenance Register PROCESSOR SPEED The 11/73 executes instructions significantly faster than the 11/23. Software which bases delays on instruction loops may not work on the 11/73 because the instructions, and therefore the delay loop, are completed much faster than they were when executed on the 11/23. Software which uses this method of implementing delays produces code which is not processor independent. However instances do appear every so often and it is important to be aware of this possibility. ================================================================================ Note 7.0 Falcon(+) Memory Maps No replies JAWS::KAISER 691 lines 25-MAR-1985 09:16 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 007 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: User Defined Memory Maps for the FALCON | Date: 01-May-84 | | and the FALCON+ | | +----------------------------------------------------+-----------------+ | Originator: Jack Toto | Page 1 of 12 | +----------------------------------------------------+-----------------+ The memory maps on the Falcon, and Falcon Plus are defined by the FPLA (Field Programmable Logic Array) that is located on board in socket XE41. This micronote explains how to redefine the existing maps. The equipment needed to custom build the FPLA is as follows: 1. Signetics NS82S100N FPLA. 2. Signetics NS82S100N FPLA worksheet. 3. PROM programmer that supports Signetics NS82S100N FPLA. 4. User written routine to convert binary into hex form, needed for the PROM programmer. The Falcon or Falcon Plus can be configured to any one of four standard memory maps. When you custom build the memory map FPLA, you may keep this ability to select any one of four memory map schemes, however it is not nessecary to build in the four maps, you may build an FPLA with only one map for the Falcon. Further the addresses of the SLUs and Parallel I/O Port can be be changed to some other addresses on the module, or they can be relocated off the module to some other device such as an MXV11-A/B, DLV11-J, DRV11-J, etc. The memory map is defined by: 1. Selecting a range of addresses, for example addresses 077777 - 037777. This includes selecting the addresses of the boards SLUs and PIO. 2. Asserting or deasserting the bits which define that range. 3. Defining which one of four memory maps the selected range of addresses will respond. 4. Selecting an enable bit (A7 -A0), which tells the T-11 where to find that range of addresses: on the Q-bus, on board the Falcon Plus in one of the two sockets, or in the local RAM. When mapping an FPLA to be used with the KXT11-A2 or KXT11-A5 ODT ROMs, you must map addresses 177600 - 177777 to the local RAM that comes on board the Falcon or Falcon Plus. This space is used for a scratch pad area by Macro ODT. If Macro ODT is not going to be used than this address range can be left to be selected by the user. Beyond this all addresses and functions can be mapped off board. Below is an example of an FPLA worksheet that was completed specifying one map (map 0) which maps all of memory to the Q-bus, and changes the address of SLU2 from 176540 - 176547, to 176500 - 176507. This format Page 2 is simalar to the Signetics FPLA worksheet. For each address range shown, the combination of bits set (H), cleared (L), or in the don't care state (-) define that range. Further each address range has associated with it an output enable bit (A) that identifies the location of the memory containing that range. It is possible to define larger or smaller ranges then the ones shown here, if needed. More examples are provided in the Falcon Plus User's Guide Appendix H. THIS IS AN FPLA MAP FOR COMPANY: XYZ I I I I I I I I I I I I I I I I 0 0 0 0 0 1 0 1 0 1 0 1 0 1 0 1 7 8 6 9 5 0 4 1 3 2 2 3 1 5 0 4 F F F F F F F -------------------------------------------------------------------------- ADDRESS X 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 7 6 5 4 3 2 1 0 RANGE X 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 177600-177777 RAM - - - H H H H H H - - - - L L H A 00 177570-177577 QB - - - H H H H H L H H H H L L H A 01 177560-177567 DL0 - - - H H H H H L H H H L L L H A 02 177540-177557 QB - - - H H H H H L H H L - L L H A 03 177500-177537 QB - - - H H H H H L H L - - L L H A 04 177400-177477 QB - - - H H H H H L L - - - L L H A 05 177000-177377 QB - - - H H H H L - - - - - L L H A 06 176600-176777 QB - - - H H H L H H - - - - L L H A 07 176560-176577 QB - - - H H H L H L H H H - L L H A 08 176550-176557 QB - - - H H H L H L H H L H L L H A 09 176540-176547 QB - - - H H H L H L H H L L L L H A 10 176510-176537 QB - - - H H H L H L H L - H L L H A 11 176500-176507 DL1 - - - H H H L H L H L L L L L H A 12 176400-176477 QB - - - H H H L H L L - - - L L H A 13 176300-176377 QB - - - H H H L L H H - - - L L H A 14 176240-176277 QB - - - H H H L L H L H - - L L H A 15 176220-176237 QB - - - H H H L L H L L H - L L H A 16 176210-176217 QB - - - H H H L L H L L L H L L H A 17 176200-176207 PIO - - - H H H L L H L L L L L L H A 18 176000-176177 QB - - - H H H L L L - - - - L L H A 19 174000-175777 QB - - - H H L - - - - - - - L L H A 20 170000-173777 QB - - - H L - - - - - - - - L L H A 21 160000-167777 QB - - - L - - - - - - - - - L L H A 22 140000-157777 QB H H L - - - - - - - - - - L L L A 23 100000-137777 QB H L - - - - - - - - - - - L L L A 24 000000-077777 QB L - - - - - - - - - - - - L L L A 25 7 6 5 4 3 2 1 0 Page 3 Once the address ranges have been coded, they need to be converted into the formatted file shown directly below. This file will be used as the input file to a program (see end of Micronote) that will output the FPLA terms in a format that is usable by the PROM Programmer itself. When converting the above worksheet to FPLA terms, the following should be considered: 1. The area at the beginning of the file may be used as a comment area as long as the word "START" is not used in the comments. "START" is the key word to begin the formatting process while the word "END" is the key word used to signal the formatter that the processing must be terminated. Both words MUST appear in capital letters. 2. The layout of the map must be as follows: ----- I15 I14 I13 I12 I11 I10 I09 I08 I07 I06 I05 I04 I03 I02 I01 I00 | TERM1 O7 O6 O5 O4 O3 O2 O1 O0 | ----- ----- I15 I14 I13 I12 I11 I10 I09 I08 I07 I06 I05 I04 I03 I02 I01 I00 | TERM2 O7 O6 O5 O4 O3 O2 O1 O0 | ---- Where I15 is input 15 on the FPLA ,I14 is input 14 on the PLA etc. further O7 is output 7 on the FPLA and O6 is output 6 on the PLA. 3. "-" indicates a "DON'T CARE ON THAT INPUT" AND * indicates a "DON'T CARE ON THIS OUTPUT". The following is the formatted FPLA map for the worksheet shown above. Notice that bus address bit 00 is translated to FPLA bit I14, that bus address 01 is translated to FPLA bit I00, that is, the bus address bits are not directly translated to the FPLA bits, however the worksheet activity (output) bits F7 - F0 translate directly to FPLA bits A7 - A0. START LH--HHH---HHH--L A******* LHHHHHH---HHLHHL *****A** LHHHHHH---HHLHLL **A***** LHLHHHH---HHLH-L *****A** LH-HHHH---HHLL-L *****A** LH-LHHH---HHL--L *****A** LH--LHH---HH---L *****A** LH--HHH---HLH--L *****A** LHHHHHH---HLLH-L *****A** Page 4 LHLHHHH---HLLHHL *****A** LHLHHHH---HLLHLL *****A** LH-HHHH---HLLLHL *****A** LHLHHHH---HLLLLL ******A* LH-LHHH---HLL--L *****A** LH-HLHH---HLH--L *****A** LH-LLHH---HLHH-L *****A** LHHLLHH---HLHL-L *****A** LHLLLHH---HLHLHL *****A** LHLLLHH---HLHLLL ***A**** LH--LHH---HLL--L *****A** LH---LH---H----L *****A** LH----H---L----L *****A** LH----L--------L *****A** LL-----HHL-----L *****A** LL-----LH------L *****A** LL------L------L *****A** Translation: The following is a translation of FPLA terms and FPLA activity outputs, and the actual pin name on the FPAL chip. I15....D15 (02 on worksheet above) used for high order bit of map decode. I14....LBS7 (00 on worksheet above) asserted for all I/O page addresses. I13....AD04 I12....AD06 I11....AD08 I10....AD10 I09....AD12 I08....AD14 I07....AD15 I06....AD13 I05....AD11 I04....AD09 I03....AD07 I02....AD05 I01....AD03 Page 5 I00....DO (01 on worksheet above) used for the low order bit of map decode. A7.....F7 on worksheet above, used for local RAM enable. A6.....F6 on worksheet above, used for socket A enable. A5.....F5 on worksheet above, used for DL0 enable. A4.....F4 on worksheet above, used for PIO enable. A3.....F3 on worksheet above, not used. A2.....F2 on worksheet above, used for all Q-bus enables. A1.....F1 on worksheet above, used for DL1 enable. A0.....F0 on worksheet above, used for socket B enable. The output file shown below is an example of one that would be loadable into a PROM Programmer in order to blast the FPLA chip. An example of a program that will produce the formatted output file shown below can be found at the end of this micronote. START $A0000, ( ADDRESS ) FF ( FIRST 8 BITS ) $A100, ( ADDRESS ) FF 00 FD FB F1 EF 7E C1 80 7F 00 FF FF FF FF FF FF FF . . ( OTHER TERMS IN HEX BYTES ) . . $A200 ( NEXT ADDRESS BOUNDARY ) . . ( TERMS ) . $A300 ( ADDRESS ) . . ( TERMS ) . $A400 ( ADRESSS ) . . ( TERMS ) . ETC. Page 6 Once the FPLA is built, it is placed into socket XE41, the memory will be configured to whatever the FPLA terms look like. The Falcon Plus needs to be strapped for a start address, a memory map (1 of 4) that matches the one called out in the FPLA, and other user configurable options. FPLA FORMAT PROGRAM ********** ============================== 1 REM THIS PROGRAM IS FOR NORMAL PLA MAP INPUTS 2 PRINT "INPUT DEVICE AND FILE NAME";H1$ 4 INPUT H1$ 5 OPEN H1$ FOR INPUT AS FILE #1 7 PRINT "DO YOU WISH OUTPUT COMPARE FILE ON LINE PRINTER,DEVICE,BOTH OR NONE ? " 8 PRINT "DEFAULT IS NONE (LP,DEV,B,N) ";N1$ 10 INPUT N1$ 12 IF N1$="LP" THEN GO TO 30 16 IF N1$="DEV" THEN GO TO 36 20 IF N1$="B" THEN GO TO 42 22 LET N$="N" 23 LET K1$="N" 24 GO TO 50 30 OPEN "LP:" FOR OUTPUT AS FILE #2 33 LET N$="Y" 34 LET K1$="N" 35 GO TO 50 36 PRINT "WHAT IS DEVICE AND FILE NAME";U1$ \ INPUT U1$ 37 OPEN U1$ FOR OUTPUT AS FILE #3 38 LET N$="N" 39 LET K1$="Y" 40 GO TO 50 42 OPEN "LP:" FOR OUTPUT AS FILE #2 45 LET N$="Y" 46 PRINT "WHAT IS DEVICE AND FILE NAME";U1$ \ INPUT U1$ 47 OPEN U1$ FOR OUTPUT AS FILE #3 48 LET K1$="Y" 50 PRINT "WHAT DEVICE AND FILE NAME FOR OUTPUT PROM PROGRAMMER FILE";W$ 52 INPUT W$ 55 OPEN W$ FOR OUTPUT AS FILE #4 60 LET Y1=1 62 LET H1$=CHR$(2) 64 LET H2$=CHR$(3) 66 LET Z$=CHR$(10)+CHR$(13) 68 LET L1$=" " 70 INPUT #1,A$ 71 IF N$="N" THEN GO TO 73 72 PRINT #2,A$ 73 IF K1$="N" THEN GO TO 76 74 PRINT #3,A$ 75 PRINT #4,A$ 76 IF A$="START" THEN GO TO 80 78 GO TO 70 80 LET S1$="$A0000," 82 PRINT #4,H1$;S1$ 84 PRINT #4,"FF " Page 7 86 LET S1$="$A100," 88 PRINT #4,S1$ 90 GO TO 92 91 PRINT #4,S1$ 93 INPUT #1,I1$ 92 IF I1$="END" THEN GO TO 120 94 INPUT #1,O1$ 95 INPUT #1,I2$ 96 IF I2$="END" THEN GO TO 130 97 INPUT #1,O2$ 98 INPUT #1,I3$ 99 IF I3$="END" THEN GO TO 140 100 INPUT #1,O3$ 101 INPUT #1,I4$ 102 IF I4$="END" THEN GO TO 150 103 INPUT #1,O4$ 104 INPUT #1,I5$ 105 IF I5$="END" THEN GO TO 160 106 INPUT #1,O5$ 107 INPUT #1,I6$ 108 IF I6$="END" THEN GO TO 170 109 INPUT #1,O6$ 110 INPUT #1,I7$ 111 IF I7$="END" THEN GO TO 180 112 INPUT #1,O7$ 113 INPUT #1,I8$ 114 IF I8$="END" THEN GO TO 190 115 INPUT #1,O8$ 117 GO TO 200 120 LET I1$="0000000000000000" \ LET O1$="AAAAAAAA" 121 LET I2$="0000000000000000" \ LET O2$="AAAAAAAA" 122 LET I3$="0000000000000000" \ LET O3$="AAAAAAAA" 123 LET I4$="0000000000000000" \ LET O4$="AAAAAAAA" 124 LET I5$="0000000000000000" \ LET O5$="AAAAAAAA" 125 LET I6$="0000000000000000" \ LET O6$="AAAAAAAA" 126 LET I7$="0000000000000000" \ LET O7$="AAAAAAAA" 127 LET I8$="0000000000000000" \ LET O8$="AAAAAAAA" 128 LET E1=1 129 GO TO 200 130 LET I2$="0000000000000000" \ LET O2$="AAAAAAAA" 132 LET I3$="0000000000000000" \ LET O3$="AAAAAAAA" 133 LET I4$="0000000000000000" \ LET O4$="AAAAAAAA" 134 LET I5$="0000000000000000" \ LET O5$="AAAAAAAA" 135 LET I6$="0000000000000000" \ LET O6$="AAAAAAAA" 136 LET I7$="0000000000000000" \ LET O7$="AAAAAAAA" 137 LET I8$="0000000000000000" \ LET O8$="AAAAAAAA" 138 LET E1=1 139 GO TO 200 140 LET I3$="0000000000000000" \ LET O3$="AAAAAAAA" 143 LET I4$="0000000000000000" \ LET O4$="AAAAAAAA" 144 LET I5$="0000000000000000" \ LET O5$="AAAAAAAA" 145 LET I6$="0000000000000000" \ LET O6$="AAAAAAAA" 146 LET I7$="0000000000000000" \ LET O7$="AAAAAAAA" 147 LET I8$="0000000000000000" \ LET O8$="AAAAAAAA" 148 LET E1=1 Page 8 149 GO TO 200 150 LET I4$="0000000000000000" \ LET O4$="AAAAAAAA" 154 LET I5$="0000000000000000" \ LET O5$="AAAAAAAA" 155 LET I6$="0000000000000000" \ LET O6$="AAAAAAAA" 156 LET I7$="0000000000000000" \ LET O7$="AAAAAAAA" 157 LET I8$="0000000000000000" \ LET O8$="AAAAAAAA" 158 LET E1=1 159 GO TO 200 160 LET I5$="0000000000000000" \ LET O5$="AAAAAAAA" 165 LET I6$="0000000000000000" \ LET O6$="AAAAAAAA" 166 LET I7$="0000000000000000" \ LET O7$="AAAAAAAA" 167 LET I8$="0000000000000000" \ LET O8$="AAAAAAAA" 168 LET E1=1 169 GO TO 200 170 LET I6$="0000000000000000" \ LET O6$="AAAAAAAA" 176 LET I7$="0000000000000000" \ LET O7$="AAAAAAAA" 177 LET I8$="0000000000000000" \ LET O8$="AAAAAAAA" 178 LET E1=1 179 GO TO 200 180 LET I7$="0000000000000000" \ LET O7$="AAAAAAAA" 187 LET I8$="0000000000000000" \ LET O8$="AAAAAAAA" 188 LET E1=1 189 GO TO 200 190 LET I8$="0000000000000000" \ LET O8$="AAAAAAAA" 198 LET E1=1 200 PRINT I1$,O1$,Z$,I2$,O2$,Z$,I3$,O3$,Z$,I4$,O4$ 210 PRINT I5$,O5$,Z$,I6$,O6$,Z$,I7$,O7$,Z$,I8$,O8$ 215 IF N$="N" THEN GO TO 218 216 PRINT #2,I1$,O1$,Z$,I2$,O2$,Z$,I3$,O3$,Z$,I4$,O4$ 217 PRINT #2,I5$,O5$,Z$,I6$,O6$,Z$,I7$,O7$,Z$,I8$,O8$ 218 IF K1$="N" THEN GO TO 221 219 PRINT #3,I1$,O1$,Z$,I2$,O2$,Z$,I3$,O3$,Z$,I4$,O4$ 220 PRINT #3,I5$,O5$,Z$,I6$,O6$,Z$,I7$,O7$,Z$,I8$,O8$ 221 LET X=16 235 LET D1$=SEG$(I1$,X,X) 240 IF D1$="H" GO TO 260 245 IF D1$="L" GO TO 270 250 IF D1$="-" GO TO 280 252 IF D1$="0" GO TO 256 255 GO TO 1340 256 LET A(1,0)=1 \ LET A(1,1)=1 257 GO TO 285 260 LET A(1,0)=1 \ LET A(1,1)=0 265 GO TO 285 270 LET A(1,0)=0 \ LET A(1,1)=1 275 GO TO 285 280 LET A(1,0)=0 \ LET A(1,1)=0 285 LET D2$=SEG$(I2$,X,X) 290 IF D2$="H" GO TO 315 300 IF D2$="L" GO TO 325 305 IF D2$="-" GO TO 335 306 IF D2$="0" GO TO 309 307 GO TO 1340 309 LET A(1,2)=1 \ LET A(1,3)=1 310 GO TO 340 Page 9 315 LET A(1,2)=1 \ LET A(1,3)=0 320 GO TO 340 325 LET A(1,2)=0 \ LET A(1,3)=1 330 GO TO 340 335 LET A(1,2)=0 \ LET A(1,3)=0 340 LET D3$=SEG$(I3$,X,X) 345 IF D3$="H" GO TO 365 350 IF D3$="L" GO TO 375 355 IF D3$="-" GO TO 385 357 IF D3$="0" GO TO 359 358 GO TO 1340 359 LET A(1,4)=1 \ LET A(1,5)=1 360 GO TO 390 365 LET A(1,4)=1 \ LET A(1,5)=0 370 GO TO 390 375 LET A(1,4)=0 \ LET A(1,5)=1 380 GO TO 390 385 LET A(1,4)=0 \ LET A(1,5)=0 390 LET D4$=SEG$(I4$,X,X) 400 IF D4$="H" GO TO 420 405 IF D4$="L" GO TO 430 410 IF D4$="-" GO TO 440 412 IF D4$="0" GO TO 414 413 GO TO 1340 414 LET A(1,6)=1 \ LET A(1,7)=1 415 GO TO 445 420 LET A(1,6)=1 \ LET A(1,7)=0 425 GO TO 445 430 LET A(1,6)=0 \ LET A(1,7)=1 435 GO TO 445 440 LET A(1,6)=0 \ LET A(1,7)=0 445 LET A8=A(1,0)*1+A(1,2)*2+A(1,4)*4+A(1,6)*8 450 LET A9=A(1,1)*1+A(1,3)*2+A(1,5)*4+A(1,7)*8 455 LET A8=15-A8 \ LET A9=15-A9 460 LET D5$=SEG$(I5$,X,X) 465 IF D5$="H" GO TO 485 470 IF D5$="L" GO TO 495 475 IF D5$="-" GO TO 505 476 IF D5$="0" GO TO 479 477 GO TO 1340 479 LET B(1,0)=1 \ LET B(1,1)=1 480 GO TO 510 485 LET B(1,0)=1 \ LET B(1,1)=0 490 GO TO 510 495 LET B(1,0)=0 \ LET B(1,1)=1 500 GO TO 510 505 LET B(1,0)=0 \ LET B(1,1)=0 510 LET D6$=SEG$(I6$,X,X) 515 IF D6$="H" GO TO 535 520 IF D6$="L" GO TO 545 525 IF D6$="-" GO TO 555 526 IF D6$="0" GO TO 529 527 GO TO 1340 529 LET B(1,2)=1 \ LET B(1,3)=1 530 GO TO 560 Page 10 535 LET B(1,2)=1 \ LET B(1,3)=0 540 GO TO 560 545 LET B(1,2)=0 \ LET B(1,3)=1 550 GO TO 560 555 LET B(1,2)=0 \ LET B(1,3)=0 560 LET D7$=SEG$(I7$,X,X) 565 IF D7$="H" GO TO 585 570 IF D7$="L" GO TO 595 575 IF D7$="-" GO TO 605 576 IF D7$="0" GO TO 579 577 GO TO 1340 579 LET B(1,4)=1 \ LET B(1,5)=1 580 GO TO 610 585 LET B(1,4)=1 \ LET B(1,5)=0 590 GO TO 610 595 LET B(1,4)=0 \ LET B(1,5)=1 600 GO TO 610 605 LET B(1,4)=0 \ LET B(1,5)=0 610 LET D8$=SEG$(I8$,X,X) 615 IF D8$="H" GO TO 635 620 IF D8$="L" GO TO 645 625 IF D8$="-" GO TO 655 626 IF D8$="0" GO TO 629 627 GO TO 1340 629 LET B(1,6)=1 \ LET B(1,7)=1 630 GO TO 660 635 LET B(1,6)=1 \ LET B(1,7)=0 640 GO TO 660 645 LET B(1,6)=0 \ LET B(1,7)=1 650 GO TO 660 655 LET B(1,6)=0 \ LET B(1,7)=0 660 LET B8=B(1,0)*1+B(1,2)*2+B(1,4)*4+B(1,6)*8 665 LET B9=B(1,1)*1+B(1,3)*2+B(1,5)*4+B(1,7)*8 670 LET B8=15-B8 \ LET B9=15-B9 675 IF B8<10 THEN LET P1=0 680 IF B8<10 THEN GO TO 720 685 IF B8=10 THEN LET B8$="A" 690 IF B8=11 THEN LET B8$="B" 695 IF B8=12 THEN LET B8$="C" 700 IF B8=13 THEN LET B8$="D" 705 IF B8=14 THEN LET B8$="E" 710 IF B8=15 THEN LET B8$="F" 715 LET P1=1 720 IF A8<10 THEN LET P0=0 725 IF A8<10 THEN GO TO 765 730 IF A8=10 THEN LET A8$="A" 735 IF A8=11 THEN LET A8$="B" 740 IF A8=12 THEN LET A8$="C" 745 IF A8=13 THEN LET A8$="D" 750 IF A8=14 THEN LET A8$="E" 755 IF A8=15 THEN LET A8$="F" 760 LET P0=1 765 IF P1=0 THEN GO TO 780 770 IF P0=0 THEN GO TO 805 775 GO TO 795 Page 11 780 IF P0=1 THEN GO TO 815 785 PRINT #4,STR$(B8);STR$(A8);L1$ 790 GO TO 820 795 PRINT #4,B8$;A8$;L1$ 800 GO TO 820 805 PRINT #4,B8$;STR$(A8);L1$ 810 GO TO 820 815 PRINT #4,STR$(B8);A8$;L1$ 820 IF B9<10 THEN LET P3=0 825 IF B9<10 THEN GO TO 865 830 IF B9=10 THEN LET B9$="A" 835 IF B9=11 THEN LET B9$="B" 840 IF B9=12 THEN LET B9$="C" 845 IF B9=13 THEN LET B9$="D" 850 IF B9=14 THEN LET B9$="E" 855 IF B9=15 THEN LET B9$="F" 860 LET P3=1 865 IF A9<10 THEN LET P2=0 870 IF A9<10 THEN GO TO 910 875 IF A9=10 THEN LET A9$="A" 880 IF A9=11 THEN LET A9$="B" 885 IF A9=12 THEN LET A9$="C" 890 IF A9=13 THEN LET A9$="D" 895 IF A9=14 THEN LET A9$="E" 900 IF A9=15 THEN LET A9$="F" 905 LET P2=1 910 IF P3=0 THEN GO TO 925 915 IF P2=0 THEN GO TO 945 920 GO TO 937 925 IF P2=1 THEN GO TO 955 930 PRINT #4,STR$(B9);STR$(A9);L1$ 935 GO TO 960 937 PRINT #4,B9$;A9$;L1$ 940 GO TO 960 945 PRINT #4,B9$;STR$(A9);L1$ 950 GO TO 960 955 PRINT #4,STR$(B9);A9$;L1$ 960 LET X=X-1 965 IF X>0 THEN GO TO 235 970 LET Y=8 975 LET C1$=SEG$(O1$,Y,Y) 980 IF C1$="A" THEN LET A1=1 985 IF C1$="*" THEN LET A1=0 990 LET C2$=SEG$(O2$,Y,Y) 995 IF C2$="A" THEN LET A2=1 1000 IF C2$="*" THEN LET A2=0 1005 LET C3$=SEG$(O3$,Y,Y) 1010 IF C3$="A" THEN LET A3=1 1015 IF C3$="*" THEN LET A3=0 1020 LET C4$=SEG$(O4$,Y,Y) 1025 IF C4$="A" THEN LET A4=1 1030 IF C4$="*" THEN LET A4=0 1035 LET C5$=SEG$(O5$,Y,Y) 1040 IF C5$="A" THEN LET A5=1 1045 IF C5$="*" THEN LET A5=0 Page 12 1050 LET C6$=SEG$(O6$,Y,Y) 1055 IF C6$="A" THEN LET A6=1 1060 IF C6$="*" THEN LET A6=0 1065 LET C7$=SEG$(O7$,Y,Y) 1070 IF C7$="A" THEN LET A7=1 1075 IF C7$="*" THEN LET A7=0 1080 LET C8$=SEG$(O8$,Y,Y) 1085 IF C8$="A" THEN LET F8=1 1090 IF C8$="*" THEN LET F8=0 1095 LET O9=(A1*1)+(A2*2)+(A3*4)+(A4*8) 1100 LET P9=(A5*1)+(A6*2)+(A7*4)+(F8*8) 1105 LET O9=15-O9 \ LET P9=15-P9 1110 IF P9<10 THEN LET T1=0 1115 IF P9<10 THEN GO TO 1155 1120 IF P9=10 THEN LET P9$="A" 1125 IF P9=11 THEN LET P9$="B" 1130 IF P9=12 THEN LET P9$="C" 1135 IF P9=13 THEN LET P9$="D" 1140 IF P9=14 THEN LET P9$="E" 1145 IF P9=15 THEN LET P9$="F" 1150 LET T1=1 1155 IF O9<10 THEN LET T0=0 1160 IF O9<10 THEN GO TO 1200 1165 IF O9=10 THEN LET O9$="A" 1170 IF O9=11 THEN LET O9$="B" 1175 IF O9=12 THEN LET O9$="C" 1180 IF O9=13 THEN LET O9$="D" 1185 IF O9=14 THEN LET O9$="E" 1190 IF O9=15 THEN LET O9$="F" 1195 LET T0=1 1200 IF T1=0 THEN GO TO 1215 1205 IF T0=0 THEN GO TO 1240 1210 GO TO 1230 1215 IF T0=1 THEN GO TO 1255 1220 PRINT #4,STR$(P9);STR$(O9);L1$ 1225 GO TO 1260 1230 PRINT #4,P9$;O9$;L1$ 1235 GO TO 1260 1240 PRINT #4,P9$;STR$(O9);L1$ 1250 GO TO 1260 1255 PRINT #4,STR$(P9);O9$;L1$ 1260 LET Y=Y-1 1265 IF Y>0 THEN GO TO 975 1270 PRINT #4,Z$ 1275 LET Y1=Y1+1 1280 IF Y1=2 THEN LET S1$="$A200," 1285 IF Y1=3 THEN LET S1$="$A300," 1290 IF Y1=4 THEN LET S1$="$A400," 1295 IF Y1=5 THEN LET S1$="$A500," 1300 IF Y1=6 THEN LET S1$="$A600," 1305 PRINT #4,Z$ 1310 IF Y1=7 THEN GO TO 1320 1315 IF E1=0 THEN GO TO 91 1320 PRINT #4,H2$ 1330 CLOSE 1335 GO TO 1345 1340 PRINT "INPUT LINE IN ERROR" 1345 END ================================================================================ Note 8.0 LSI-11/73 Memory Managment No replies JAWS::KAISER 558 lines 25-MAR-1985 09:17 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 008 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: Memory Management and the LSI-11/73 | Date: 22-Jun-84 | +----------------------------------------------------+-----------------+ | Originator: Dave Smith | Page 1 of 10 | +----------------------------------------------------+-----------------+ This micronote explains memory management as it applies to the LSI-11/73. It includes descriptions of what memory management is, what it does, and how it works. Simply stated, memory management is a method of mapping virtual addresses to physical addresses. The virtual address space is the view of memory as seen by a process running. The physical address space is the actual physical memory as seen by the entire system. Since ALL memory references must be mapped, this translation is done in hardware by using a Memory Management Unit (MMU). Various schemes (dependent upon the architecture) have been developed to accomplish this, but most memory management systems provide the following services: 1) Protection 2) Relocation 3) Segmentation The first two are of great importance in a multiprogramming system since memory management provides the mechanism for assigning memory areas to user programs and for preventing users from accessing areas that have been assigned to other users. This protects the operating system executive as well as users from accidental or willful memory accesses outside of a user's assigned memory. Relocation is also important in a multiprogramming environment since the executive must be able to relocate the user's program to a free area in physical memory. The LSI-11/73 Memory Management Unit provides the hardware for complete memory management by providing all of the above services. It is software compatible with the larger UNIBUS PDP-11s and other Q-bus processors. Since the LSI-11/73 has the PDP-11 architecture and a 16-bit program counter, all 16-bit addresses access a 64Kb virtual address space. On the LSI-11/73 this addressing limitation can be eased by using separate sets of memory management registers for instructions (I-space) and for data (D-space). By utilizing separate I- and D- space, the address space can be segmented into two 64Kb segments, effectively doubling the virtual address space. The LSI-11/73 and the Q-bus allow 4 Mb of memory to be referenced. The MMU is necessary to provide the mapping from the 64Kb virtual address space to the 4 Mb physical address space. Page 2 When the MMU is activated, a 16-bit virtual address is mapped to an 18-bit or 22-bit physical address. The MMU uses registers known as Active Page Registers (APRs). An APR consists of two 16-bit registers which are called the Page Address Register (PAR) and the Page Descriptor Register (PDR). PARs are used in the actual address translation while PDRs contain access and other information. Since the LSI-11/73 is functionally equivalent to the PDP-11/70, it can operate in one of three modes: Kernel, Supervisor, or User and it can use I- and D- space. This means that the MMU must provide separate sets of registers for each mode and within each mode, sets of registers for I-space and for D-space. A set of registers consists of eight pairs of PDRs and PARs. Thus the LSI-11/73 MMU has a total of three sets of 32 16-bit registers. Mapping is always done in pages of 8Kb (4K words) in length or less. In order to map the largest possible virtual address space (64 Kb), the address space is divided into eight pages of 8Kb each. One APR is used for each of the eight pages, numbered 0 to 7. The uppermost page in physical memory is called the I/O page and is usually mapped by a Kernel Mode APR since it is a privileged area. PHYSICAL ADDRESS SPACE 4 Mb +----------+ | I/O page | <--+ +----------+ | | | | +----------+ | USER MODE +-----> | page 7 | | KERNEL MODE | +----------+ | APRs | | | | APRs | +----------+ | | . | | . | +----------+ | +----------+ | +----------+ | PAR7 |----+ | | +-------| PAR7 | +----------+ +----------+ +----------+ | PAR6 | | | | PAR6 | +----------+ +----------+ +----------+ | PAR5 | +---> | | | PAR5 | +----------+ | +----------+ +----------+ | PAR4 |----+ | | | +-------| PAR4 | +----------+ | | +----------+ | +----------+ | PAR3 | | | | | | | PAR3 | +----------+ | | +----------+ | +----------+ | PAR2 | | | | | <--+ | PAR2 | +----------+ | | +----------+ +----------+ | PAR1 | +-----> | | | PAR1 | +----------+ | +----------+ +----------+ | PAR0 |------+ | | <----------| PAR0 | +----------+ 0 +----------+ +----------+ The Page Address Register consists solely of the Page Address Field Page 3 (PAF). If 22-bit addressing is enabled, then all 16 bits of the PAR are used as the PAF. If only 18-bit addressing is desired then the 12 lower order bits are the PAF and the 4 higher order bits are unused. It may be thought of as a base register containing a base address or as a relocation register containing a relocation constant. PAGE ADDRESS REGISTER (PAR) 15 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PAGE ADDRESS FIELD (PAF) | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ The Page Descriptor Register contains information about access, page length, and expansion direction: PAGE DESCRIPTOR REGISTER (PDR) 15 14 08 07 06 05 04 03 02 01 00 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |BC| PAGE LENGTH FIELD | 0| W| 0| 0|ED| ACF | 0| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ PDR <15> BC (Bypass Cache) Set if memory accessing is wished to be without utilizing the cache. Useful with dual-ported memories. PDR <08:14> PLF (Page Length Field) Specifies the authorized length of the page in 32 word (or 64 byte) groups. 0 <--> 32 word page . . 177 (8) <--> 4096 word page PDR <06> W (Written Into) Useful in determining whether or not a page can simply be erased or must be saved to be brought back into memory. 0 <--> Page has NOT been written into 1 <--> Page has been written into PDR <03> ED (Expansion Direction) 0 <--> Expands to higher addresses Page 4 (Normally used) 1 <--> Expands to lower addresses (Can be used for stack segments) PDR <01:02> ACF (Access Control Field) 00 <--> Nonresident 01 <--> Resident - Read Only 10 <--> Not Used 11 <--> Resident - Read/Write The 16-bit virtual address is divided into three fields: VIRTUAL ADDRESS (VA) 15 13 12 6 5 0 +-------+------------------------+-------------+ | APF | BN | DIB | +-------+------------------------+-------------+ <--------DISPLACEMENT FIELD (DF)-------> o APF or Active Page Field These three bits determine which of the eight APRs are selected. o BN or Block Number The PAF determines an 8 Kb page in memory. The BN is that offset that is added to the base of the page determined by the PAF to obtain the block within the page to map. o DIB or Displacement In the Block Tells exactly which one of the 32 words is being mapped to. The low order 6 bits (DIB) are never relocated. The BN and DIB fields are collectively referred to as the Displacement Field (DF). If the MMU is not activated then 16-bit virtual addresses are also 16-bit physical addresses and linearly map the 64Kb address space. When the MMU is activated the 16-bit virtual address (VA) is no longer interpreted as a physical address Instead, the physical address (PA) is constructed using the VA and the PAF (Page Address Field) of the selected PAR. The translation of virtual addresses to 22-bit physical addresses is accomplished as follows: 1) A set of registers is selected. This is determined by the space being referenced (Instructions or Data) and by Page 5 the mode bits of the Processor Status Word (PSW <15:14>). 2) The APF field of the virtual address determines which of the eight pairs in the selected set will be used for the mapping. 3) The PAF of the selected register pair contains the starting address of the currently active page as a block number. 4) The block number from the virtual address and the block number from the PAF are added together. The block number from the PAF is shifted left by six bits in order to perform this addition. The result is the actual physical block number (bits <21:06> of the physical address). 5) The DIB of the virtual address is carried along unchanged as bits <05:00> of the translated address. VIRTUAL TO PHYSICAL ADDRESS TRANSLATION 16-BIT VIRTUAL ADDRESS 15 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | APF | BN | DIB | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | | | | | +---------+ | | | Selects | | | | APR | +---------------+ | +---------+ | | | | | | PAGE ADDRESS REGISTER | | 15 0 | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | | | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | | | | | +-----+ | | +------------>| ADD |<----------+ | +-----+ | | | +---------------+ | | | | | 21 | 6 5 | 0 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+ | BLOCK NUMBER IN PHYSICAL MEMORY | | DIB | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+ <--------------- 22-BIT PHYSICAL ADDRESS (PA) ----------------------> Page 6 There are four memory management registers that are used for memory fault recovery and abort and status information as well as control of the MMU. They are called MMR0, MMR1, MMR2, and MMR3. Memory Management Register 0 (MMR0) is the main control and status register. MEMORY MANAGEMENT REGISTER 0 (MMR0) 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | | | 0| 0| 0| 0| 0| 0| | | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ MMR0 <15> NONRESIDENT ABORT Set if an attempt is made to access a page with an ACF of 0 or 2 or if the PSW indicates mode 2. MMR0 <14> PAGE LENGTH ABORT Set if an attempt is made to access a location whose block number is outside the area authorized by the PLF of the PDR for that page. MMR0 <13> READ ONLY ABORT Set if an attempt is made to write to a page with an ACF of 1 (Read Only). MMR0 <06:05> PROCESSOR MODE Copy of the PSW <15:14> when abort occurred. MMR0 <04> PAGE SPACE 1 <--> D-space 0 <--> I-space MMR0 <03:01> PAGE NUMBER Page Number of page causing the abort. Copy of APF of virtual address. MMR0 <00> ENABLE RELOCATION Page 7 1 <--> ALL addresses are relocated (MMU activated) 0 <--> NO addresses are relocated (MMU disabled) Memory Management Register 1 (MMR1) is called the Instruction Backup Register. It records any autoincrement or autodecrement of any general purpose register. The lower byte is used for source operands and the destination operand may be in either byte, dependent upon the instruction. MEMORY MANAGEMENT REGISTER 1 (MMR1) 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ MMR1 <15:11> AMOUNT CHANGED (2's complement) MMR1 <10:08> REGISTER NUMBER MMR1 <07:03> AMOUNT CHANGED (2's complement) MMR1 <02:01> REGISTER NUMBER Memory Management Register 2 (MMR2) is known as the Last Virtual Program Counter. It is loaded with the value of the Program Counter at the beginning of each instruction fetch and is used in instruction fault recovery. Page 8 Memory Management Register 3 (MMR3) is used to select 18-bit or 22-bit address mapping and is used to enable/disable the data space for any of the processor modes. MEMORY MANAGEMENT REGISTER 3 (MMR3) 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| | | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ MMR3 <05> UNINTERPRETED May be set or cleared but is not interpreted. MMR3 <04> ENABLE 22-BIT MAPPING 1 <--> Mapping is to 22-bit space. 0 <--> Mapping is to 18-bit space. MMR3 <03> ENABLE CSM (Call Supervisor Mode) INSTRUCTION 1 <--> CSM is recognized. 0 <--> CSM is not recognized. MMR3 <02> KERNEL DATA SPACE 1 <--> Enable data space mapping in Kernel Mode 0 <--> Disable data space mapping in Kernel Mode MMR3 <01> SUPERVISOR DATA SPACE 1 <--> Enable data space mapping in Supervisor Mode 0 <--> Disable data space mapping in Supervisor Mode MMR3 <00> USER DATA SPACE 1 <--> Enable data space mapping in User Mode 0 <--> Disable data space mapping in User Mode Page 9 Summary: The LSI-11/73 Memory Management Unit provides a powerful, general purpose tool for memory management. It can be used to expand memory in a simple way and it can be used in a multiprogramming system to provide all the services necessary for an efficient and secure environment. The following is a simple MACRO-11 program which illustrates the method of setting up the registers and performing some mappings. It writes a known value to an unmapped location and sets up the MMU registers and turns on the unit. It then writes another known value to the same virtual address which is now mapped. Then it turns the MMU off. At this point the two known values are in different memory locations. .TITLE MMU ; ; Program to demonstrate setting up MMU registers ; and to illustrate the mapping that takes place ; PSW = 177776 ; Processor Status Word MMR0 = 177572 ; Memory Management Register 0 PDR0 = 172300 ; Page Descriptor Register 0 PAR0 = 172340 ; Page Address Register 0 PAR1 = 172342 ; Page Address Register 1 PAR7 = 172356 ; Page Address Register 7 ; INSURE THAT MMU IS NOT ACTIVATED START:: CLR @#MMR0 ; CLEAR MMR0 ; STORE A KNOWN VALUE (152152) IN UNMAPPED LOCATION 20000 MOV #152152,@#20000 ; SET PSW TO KERNEL MODE BIC #140000,@#PSW ; SET THE PARS SO THAT EACH PAGE MAPS TO ITSELF MOV #PAR0,R5 ; SET UP PAR POINTER MOV #10,R4 ; SET UP PAR COUNTER CLR R3 ; SET UP PAR OFFSET VALUE LOOP1: MOV R3,(R5)+ ; SET EACH RELOCATION CONSTANT TO ; MAP TO ITSELF Page 10 ADD #200,R3 ; UPDATE OFFSET SOB R4,LOOP1 ; DO ALL OF THEM ; SET PAR1 TO MAP PAGE 1 TO PAGE 2 MOV #400,@#PAR1 ; SET PAR7 TO MAP THE I/O PAGE TO THE TOP OF MEMORY MOV #7600,@#PAR7 ; 172356 POINTS TO 760000 ; ; SET UP THE PDRS ; ; 77406 (8) = 0 111 111 100 000 110 (2) ; ; RESIDENT - READ/WRITE ; UPWARD EXPANDING ; NOT WRITTEN INTO ; 8KB PAGE SIZE ; DON'T BYPASS CACHE ; MOV #PDR0,R5 ; SET UP PDR POINTER MOV #10,R4 ; SET UP PDR COUNTER LOOP2: MOV #77406,(R5)+ ; SET EACH PDR SOB R4,LOOP2 ; DO THEM ALL ; ENABLE THE MMU INC @#MMR0 ; SET BIT 0 OF MMR0 ; WRITE A VALUE TO LOCATION 20000. THIS SHOULD BE MAPPED. MOV #107010,@#20000 ; WRITE 107010 TO MAPPED 2000 ; DISABLE THE MMU DEC @#MMR0 ; CLEAR BIT 0 OF MMR0 ; AT THIS POINT IN THE PROGRAM, EXAMINING PHYSICAL ; ADDRESS 20000 SHOWS THE VALUE OF 152152 WHICH WAS PLACED THERE ; ADDRESS 40000 (WHICH 20000 MAPPED TO) HOLDS THE VALUE 107010 HALT .END START ================================================================================ Note 9.0 LSI-11/73 Cache Concepts No replies JAWS::KAISER 307 lines 25-MAR-1985 09:18 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 009 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: Cache Concepts and the LSI-11/73 | Date: 02-JUL-84 | +----------------------------------------------------+-----------------+ | Originator: Charlie Giorgetti | Page 1 of 6 | +----------------------------------------------------+-----------------+ The goal is to introduce the concept of cache and its particular implementation on the LSI-11/73 (KDJ11-A). This is not a detailed discussion of the different cache organizations and their impact on system performance. What Is A Cache ? ----------------- The purpose of having a cache is to simulate a system having a large amount of moderately fast memory. To do this the cache system relies on a small amount of very fast, easily accessed memory (the cache), a larger amount of slower, less expensive memory (the backing store), and the statistics of program behavior. The goal is to store some of the data and its associated addresses in the cache and all of the data at its usual addresses (including the currently cached data) in the backing store. If it can be arranged that most of the time when the processor needs data it is located in fast memory, then the program will execute more quickly, slowing down only occasionally for main memory operations. The placement of data in the cache should not be a concern to the programmer but is a consequence of how the cache functions. Figure 1 is an example of a memory organization showing a cache with backing store. If the data needed by the microprocessor (uP) can be found in the cache then it is accessed much faster due to the local data path and faster cache memory than by having to access the backing store on the slower system bus. +-----------+ System Bus +------+ CPU Internal Buses | System | For Memory and I/O Options | |<-----------------+->| Bus |<--------------------------> | uP | | | Interface | | | |<----------+ | +-----------+ | +------+ Fast Path | | +-------+---------+ to Cache | | | | +-+------+--+ | System Memory | | | | (Backing Store) | | Cache | | | | | +-----------------+ +-----------+ Figure 1 - An Example Memory System with Cache Page 2 A cache memory system can only work if it can successfully predict most of the time what memory locations the program will require. If a program accessed data from memory in a completely random fashion, it would be impossible to predict what data would be needed next. If this was the case a cache would operate no better then a conventional memory system. Programs rarely generate random addresses. In many cases the subsequent memory address referenced is often very near the current address accessed. This is the principle of program locality. The next address generated is in the neighborhood of the current address. This behavior helps makes cache systems feasible. The concept of program locality is not always adhered to, but is a statement of how many programs behave. Many programs execute code in a linear fashion or in loops with predictable results in next address generation. Jumps and context switching give the appearance of random address generation. The ability to determine what word a program will reference next is never completely successful and therefore the correct "guesses" are a statistical measure of the size and organization of the cache, and the behavior of the program being executed. The measure of a cache performance is a statistical evaluation of the number of memory references found versus not found in cache. When memory is referenced and the address is found in the cache this is known as a hit. When it is not it is termed a miss. Cache performance is usually stated in terms of the hit ratio or the miss ratio where these are defined as: Number of Cache Hits Hit Ratio = --------------------------------- Total Number of Memory References Miss Ratio = 1 - Hit Ratio The LSI-11/73 Cache Implementation ---------------------------------- The cache organization chosen must be one that can be implemented within the physical and cost constraints of the design. The LSI-11/73 implements a direct map cache. A direct map organization has a single unique cache location for a given address and this is where the associated data from backing store are maintained. This means an access to cache requires one address comparison to determine if there is a hit. The significance of this is that a small amount of circuitry is required to perform the comparison operation. The LSI-11/73 has an 8 KByte cache. This means that there are 4096 unique address locations each of which stores two bytes of information. Page 3 The cache not only maintains the data from backing store but it also includes other information that is needed to determine if its content is valid. These are parity detection and valid entry checking. The following diagram shows the logical layout of the cache and what each field and its associated address in the cache is used for. Binary Cache Entry Address P V TAG P1 B1 P0 B0 +---+---+-------------+---+----------+---+----------+ 000000000000 | | | | | | | | +---+---+-------------+---+----------+---+----------+ 000000000001 | | | | | | | | +---+---+-------------+---+----------+---+----------+ 000000000010 | | | | | | | | +---+---+-------------+---+----------+---+----------+ . . . . . . +---+---+-------------+---+----------+---+----------+ 111111111101 | | | | | | | | +---+---+-------------+---+----------+---+----------+ 111111111110 | | | | | | | | +---+---+-------------+---+----------+---+----------+ 111111111111 | | | | | | | | +---+---+-------------+---+----------+---+----------+ Figure 2 - LSI-11/73 Cache Layout The Cache Entry Address is the address of one of 4096 entries within the cache. This value has a one-to-one relationship with a field in each address that is generated by the processor (described in the next section on how the physical address accesses cache). Each field has the following meaning: Tag (TAG) - This nine bit field contains information that is compared to the address label, described in the next section on how the physical address accesses cache. When the physical address is generated, the address label is compared to the tag field. If there is a match it can be considered a hit provided that there is entry validation and no parity errors. Cache Data (B0 and B1) - These two bytes are the actual data stored in cache. Valid Bit (V) - The valid bit indicates whether the information in B0 and B1 is usable as data if a cache hit occurs. The valid bit is set when the entry is allocated during a cache update which occurs as a result of a miss. Tag Parity Bit - (P) - Even parity calculated for the value stored in the tag field. Page 4 Parity Bits (P0 and P1) - P0 is even parity calculated for the data byte B0 and P1 is odd parity calculated for the data byte B1. When the processor generates a physical address, the on-board cache control logic must determine if there is a hit by looking at the unique location in cache. To determine what location to check, the cache control logic considers each address generated as being made up of three unique parts. The following are the three fields of a 22-bit address (in an unmapped or 18-bit environment the label field is six or four bits less respectfully): 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 +--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+ +--+ | | | | | | | | | | | | | | | | | | | | | | | | | +--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+ +--+ |<-------- LABEL --------->| |<-------------- INDEX ------------>| BYTE SELECT Figure 2 - Components of a 22-bit Address For Cache Address Selection Each field has the following meaning: Index - This twelve bit field determines which one of the 4096 cache data entries to compare with for a cache hit. The index field is the displacement into the cache and corresponds to the Cache Entry Address. Label - Once the location in the cache is selected, the nine bit label field is compared to the tag field stored in the cache entry under consideration. If the address label and the tag field match, the valid bit is set, and there is no parity error, then a hit has occurred. Byte Select Bit - This bit determines if the reference is on an odd or even byte boundary. All Q-bus reads are word only so this bit has no effect on a cache read. Q-bus writes can access either words or bytes. If there is a word write the cache will be updated if there is a hit. If there is a miss a new cache entry will be made. If there is a byte write, the cache will only be updated if there is a hit. A miss will not create a new entry on a byte write. The LSI-11/73 direct map cache must update the backing store on a memory write. The LSI-11/73 uses the write through method. With this technique, writes to backing store occurs concurrently with cache writes. The result is that the backing store always contains the same data as the cache. Page 5 Features Of The LSI-11/73 Cache ------------------------------- The LSI-11/73 direct map cache has a number of features that assist in the performance of the overall system in addition to the speed enhancement as a result of faster memory access. These features consist of the following: o Q-bus DMA monitoring o I/O page reference monitoring o Memory management control of cache access o Program control of cache parameters o Statistical monitoring of cache performance The LSI-11/73 cache control logic monitors the Q-bus during DMA transactions. When an address that has its data stored in cache is accessed during DMA, the cache and backing store contents might no longer be the same. This is an unacceptable situation. The cache control logic invalidates a cache entry if the address is used during DMA. This also includes addresses used during Q-bus Block Mode DMA transfers. Memory references to the I/O page are not cached since that data is volatile, meaning its contents can change without a Q-bus access. Since the cache could end up with stale data, I/O references are not cached. There are situations for which using the cache to store information for faster access is not desirable. An example is a device that resides in the I/O page, and is true in other instances as well. One situation is a device that does not reside in the I/O page but can change its contents without a bus reference, such as dual ported memory. Another situation is partitioning and tuning an application for instruction code execution versus data being manipulated. In this case the instruction stream may execute many times over for different data values. Speed enhancement can be obtained if the instructions are cached while the data is not cached. By forcing the data never to be cached it cannot replace instructions in the cache. The memory management unit (MMU) of the LSI-11/73 can assist in this situation. Pages of memory allocated for data can be marked to bypass the cache and therefore not effect instructions that loop many times. The cache and the MMU work together to achieve the goal of increased system performance. The dynamics of cache operation are under program control through use of the Cache Control Register (CCR), an LSI-11/73 on-board register. This register can "turn" the cache on or off, force cache parity errors for diagnostic testing, and invalidate all cache entries. The details of the CCR are described in the KDJ11-A CPU Module User's Guide (part number EK-KDJ1A-UG-001). During system design or at run-time the performance enhancements provided by the cache system can be monitored under program control. This is accomplished by using another LSI-11/73 on-board register the Page 6 Hit/Miss Register (HMR). This register tracks the last six memory references and indicates if a hit or miss took place. The details of the HMR are also described in the KDJ11-A CPU Module User's Guide. Summary ------- Caches are a mechanism that can help improve overall system performance. The dynamics of a given cache are dictated by the organization and the behavior of the programs running on the machine. The LSI-11/73 cache is designed to be flexible in its use, simple in implementation, and enhance application performance. More detailed discussions on how caches work and other cache organizations can be found in computer architecture texts that have a discussion of memory hierarchy. ================================================================================ Note 10.0 MicroVAX I I/O Programming No replies JAWS::KAISER 229 lines 25-MAR-1985 09:18 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 010 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: MicroVAX I/O Programming | Date: 27-JUL-84 | +----------------------------------------------------+-----------------+ | Originator: Peter Jonhson | Page 1 of 5 | +----------------------------------------------------+-----------------+ The Qbus MicroVax implements the full Vax memory management, so virtual addresses are translated to physical addresses - just as they are for the Vax minicomputers. When memory management is enabled, system and process space virtual addresses are translated into physical addresses and sent onto the Qbus. Normally, the programmmer need not concern himself with this translation as this is completely handled by the operating system; however, when accessing locations in the I/O space directly the programmer must concern himself with the mapping since specific information must be supplied by the programmer to MicroVMS in order for it to successfully map the user's virtual addresses into the I/O space. The process of mapping a virtual address to a physical address must start by determining the physical address that you wish to access. In our case this means that we must calculate a Qbus MicroVax physical address given that we know the address that the Qbus board is configured to. In order to do this we must know a few key facts about the Qbus MicroVax architecture. 1) The Qbus MicroVax I/O space begins at physical 20000000 (hex) 2) The I/O space of a Qbus MicroVax is largely empty containing only Q22 bus I/O space which is 8K bytes long Given these two pieces of information we now know that the I/O space for the Qbus MicroVax starts at physical 20000000 (hex) and extends to 20001FFF (hex). This I/O space directly corresponds to the configurable addresses on Qbus option boards 160000-177777 (oct). In order to convert any Qbus option address to a Qbus MicroVax address one simply subtracts 160000 from the boards configured address to get its offset into the I/O space and then add this value to the base of the Qbus MicroVax I/O space. For example, let us consider a board which has been configured to 166540. In order to calculate its equivalent Qbus MicroVax address we would do the following: Page 2 1) Subtract off the I/O base address for this board (160000) 166540 (oct) - 160000 (oct) --------- 6540 (oct) --> D60 (hex) 2) Add the board's address offset to the Qbus MicroVax I/O space base address 20000000 (hex) + D60 (hex) ---------- 20000D60 (hex) This addition results in the physical address on the Qbus MicroVax system that this board would answer to. Now we have calculated the physical address for the board in the Qbus MicroVax environment. This value, however, is in the raw state and is still not usable by the uVMS software to perform virtual to physical address translation. In order for this address to be useful to the software it must now be converted from a physical address to a page frame number. The page is the basic unit of memory mapping and protection. A page is 512 contiguous byte locations. A page frame number (PFN) is the address of the first byte of a page in physical memory. This means that the lsb of a PFN has the resolution of 1 page or 512 bytes. It is a simple matter now to convert a physical address to a PFN. Since the lsb of a PFN is 1 page to convert a physical address to PFN just shift right the physical address 9 bits, i.e. shift off the 9 least significant bits. physcial 20000D60 (hex) shift right 9 --> PFN 100006 (hex) The PFN value which we have calculated is sufficient to allow the system to map a physcial page of addresses into your virtual address space. The address of the Qbus option resides somewhere in the page which we have mapped. It is the responsibility of the programmer to correctly offset from the beginning of the page in order to access the board i.e. the programmer must displace from the base of the mapped page with the correct virtual address offset. To determine the offset from the beginning of the mapped page look to bits 0-9 of the configured address of the Qbus option board - this is the offset. In our example the offset would be: Page 3 166540 (oct) | | \ / | -------- 540 bits 9-0 are the offset This offset would be used by the programmer to access the device registers on the board. Failure to use the offset will usually result in an attempt to access non-esxistent locations (analagous to memory time-outs) which will result in an access violation error being returned to the user. A sample program follows which illustrates the principles which have been discussed. It uses the same board address discussed earlier so that one can see the code needed to acutally implement the previous example. The following program illustrates, in a raw fashion, how one might actually access the I/O space with software. It is not meant to illustrate good or recommended programming practice but rather to show the mechanics of accessing the I/O space of a Qbus on MicroVax I. Page 4 .title map_io_space ;This program will allow a user with suitable privilege to access ;device registers in the I/O space of a uVax. This example shows ;code which is used to extract data from a DRV11 - a general purpose ;parallel interface which resides in I/O space. It is sufficiently ;general to allow the concept to be used in other situations where ;access to the I/O space from a user process is desireable. ;This portion of the program is responsible for creating the ;virtual to physical mapping required to access registers in ;the I/O space. For this example the device registers are assumed to ;start at 166540. In order for virtual to physical mapping to occur ;the user must calculate the physcial page frame that the device ;registers overlap into. (See accompanying text for how to do this) ;Create and map section directive does the actual work of mapping. ;In order for this system service to work correctly the ;use must have PFNMAP privilege .entry start,^m<> $crmpsc_s - inadr = maprange, - ;Input virtual address range retadr = actadr, - ;Virtual address range acutally ;mapped pagcnt = #1, - ;Non zero required for page frame ;section flags =#, - vbn = pfn_number ;Actual page frame of I/O space ;page which contains device registers blbs r0,continue ;check the return status of create ;and map - if successful branch pushl r0 ;put status onto stack calls #1,g^lib$stop ;tell him what happened and ;stop program Page 5 ;At this point one page of virtual addresses in the user's process ;space is now mapped into one page of the I/O space. Now the user ;can access device registers by using move instructions. ;...... ** Please note that only certain instructions are allowed when ;doing physical I/O to the bus. For example a MOVL instruction is ;NOT legal to the I/O space. continue: movl actadr, r6 ;Get starting virtual address from ;system service and put into R6 addl #^x160, r6 ;Add the displacement into this page ;to access the device registers ;Access data from the parallel interface tstb (r6) ;Test for data transfer request bgew 10$ ;If no data exit movw 4(r6), data_in_buffer ;Data is present - store it 10$: $exit_s - ;exit gracefully code = #1 ;data for program ...... maprange: .long ^x400 .long ^x800 control_status .word 0 data_in_buffer .word 0 actadr: .blkl 2 ;holds returned virtual ; address range pfn_number: .long ^x100006 ;actual pfn of I/O page to ;be mapped .end start ================================================================================ Note 11.0 LSI-11/73 Advanced Memory Mgmt No replies JAWS::KAISER 557 lines 25-MAR-1985 09:19 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 011 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: LSI-11/73 ADVANCED MEMORY MANAGEMENT | Date: 04-Sep-84 | +----------------------------------------------------+-----------------+ | Originator: Art Bigler | Page 1 of 11 | +----------------------------------------------------+-----------------+ This micronote examines the advanced memory management features available on the DCJ11 based LSI-11/73 series processors (KDJ11-A, KDJ11-B). These features include the standard virtual address relocation within the physical address space and the kernel and user execution modes, all of which are currently available as options on the mid-range LSI-11/23 (KDF11-A, KDF11-B) processors. In addition to these features, the DCJ11 based processors also provide instruction and data space (I/D space) memory management and the supervisor execution mode. The following discussion is intended to further clarify these features. For information pertaining to address relocation the reader is referred to micronote 008, MEMORY MANAGEMENT AND THE LSI-11/73. 1.0 INSTRUCTION/DATA SPACE MEMORY MANAGEMENT I/D space memory management is utilized in the DCJ11 based processors IN ADDITION TO the relocation of virtual addresses within the physical address space. This provides the ability to place multiple program images in physical memory while at the same time providing an increased virtual address space of 128 kb or 64 kw by mapping instructions and data to separate areas of physical memory. The means by which I/D space memory management is attained involves both hardware and software as described in the following paragraphs. 1.1 I/D SPACE HARDWARE The hardware required to implement I/D space addressing is integrated into the memory management unit and is standard on all DCJ11 based processors. This includes the following: 1. Eight (8) additional active page registers (APR's) per execution mode (more about execution modes later). These APR's are used to map to the data space when I/D space memory management is enabled. 1. Additional control and status bits in memory management registers 0 and 3 (MMR0, MMR3) which are used to control the enabling and disabling of data space addressing. INSTRUCTION SPACE ADDRESSING IS ALWAYS ENABLED. 1.1.1 ACTIVE PAGE REGISTERS Page 2 The hardware provides a total of sixteen (16) APR's per execution mode, eight (8) instruction space registers and eight (8) data space registers. THE APR's are further divided into page descriptor registers (PDR's) and page address registers (PAR's) as described in micronote 008. The physical addresses for these registers are contained in the I/O page and are as follows: +-------+---------------+---------------+-------+ | MODE | PAR's | PDR's | PAGE | +-------+---------------+---------------+-------+ | | 17772340 | 17772300 | 0 | + +---------------+---------------+-------+ | | 17772342 | 17772302 | 1 | + +---------------+---------------+-------+ | | 17772344 | 17772304 | 2 | + +---------------+---------------+-------+ | KERNEL| 17772346 | 17772306 | 3 | + I +---------------+---------------+-------+ | SPACE | 17772350 | 17772310 | 4 | + +---------------+---------------+-------+ | | 17772352 | 17772312 | 5 | + +---------------+---------------+-------+ | | 17772354 | 17772314 | 6 | + +---------------+---------------+-------+ | | 17772356 | 17772316 | 7 | +-------+---------------+---------------+-------+ | | 17772360 | 17772320 | 0 | + +---------------+---------------+-------+ | | 17772362 | 17772322 | 1 | + +---------------+---------------+-------+ | | 17772364 | 17772324 | 2 | + +---------------+---------------+-------+ | KERNEL| 17772366 | 17772326 | 3 | + D +---------------+---------------+-------+ | SPACE | 17772370 | 17772330 | 4 | + +---------------+---------------+-------+ | | 17772372 | 17772332 | 5 | + +---------------+---------------+-------+ | | 17772374 | 17772334 | 6 | + +---------------+---------------+-------+ | | 17772376 | 17772336 | 7 | +-------+---------------+---------------+-------+ TABLE 1a KERNEL MODE APR'S Page 3 +-------+---------------+---------------+-------+ | MODE | PAR's | PDR's | PAGE | +-------+---------------+---------------+-------+ | | 17772240 | 17772200 | 0 | + +---------------+---------------+-------+ | | 17772242 | 17772202 | 1 | + +---------------+---------------+-------+ | | 17772244 | 17772204 | 2 | + +---------------+---------------+-------+ | SPVSR | 17772246 | 17772206 | 3 | + I +---------------+---------------+-------+ | SPACE | 17772250 | 17772210 | 4 | + +---------------+---------------+-------+ | | 17772252 | 17772212 | 5 | + +---------------+---------------+-------+ | | 17772254 | 17772214 | 6 | + +---------------+---------------+-------+ | | 17772256 | 17772216 | 7 | +-------+---------------+---------------+-------+ | | 17772260 | 17772220 | 0 | + +---------------+---------------+-------+ | | 17772262 | 17772222 | 1 | + +---------------+---------------+-------+ | | 17772264 | 17772224 | 2 | + +---------------+---------------+-------+ | SPVSR | 17772266 | 17772226 | 3 | + D +---------------+---------------+-------+ | SPACE | 17772270 | 17772230 | 4 | + +---------------+---------------+-------+ | | 17772272 | 17772232 | 5 | + +---------------+---------------+-------+ | | 17772274 | 17772234 | 6 | + +---------------+---------------+-------+ | | 17772276 | 17772236 | 7 | +-------+---------------+---------------+-------+ TABLE 1b SUPERVISOR MODE APR'S Page 4 +-------+---------------+---------------+-------+ | MODE | PAR's | PDR's | PAGE | +-------+---------------+---------------+-------+ | | 17777640 | 17777600 | 0 | + +---------------+---------------+-------+ | | 17777642 | 17777602 | 1 | + +---------------+---------------+-------+ | | 17777644 | 17777604 | 2 | + +---------------+---------------+-------+ | USER | 17777646 | 17777606 | 3 | + I +---------------+---------------+-------+ | SPACE | 17777650 | 17777610 | 4 | + +---------------+---------------+-------+ | | 17777652 | 17777612 | 5 | + +---------------+---------------+-------+ | | 17777654 | 17777614 | 6 | + +---------------+---------------+-------+ | | 17777656 | 17777616 | 7 | +-------+---------------+---------------+-------+ | | 17777660 | 17777620 | 0 | + +---------------+---------------+-------+ | | 17777662 | 17777622 | 1 | + +---------------+---------------+-------+ | | 17777664 | 17777624 | 2 | + +---------------+---------------+-------+ | USER | 17777666 | 17777626 | 3 | + D +---------------+---------------+-------+ | SPACE | 17777670 | 17777630 | 4 | + +---------------+---------------+-------+ | | 17777672 | 17777632 | 5 | + +---------------+---------------+-------+ | | 17777674 | 17777634 | 6 | + +---------------+---------------+-------+ | | 17777676 | 17777636 | 7 | +-------+---------------+---------------+-------+ TABLE 1c USER MODE APR'S 1.1.2 MEMORY MANAGEMENT REGISTER 0 Memory management register 0 (MMR0) contains control and status information for the memory management unit (MMU). This register is discussed completely in micronote 008, to which the reader is again refferred for information on those functions which are not directly applicable to I/D space and supervisor mode. MMR0 contains three (3) status bits which are used in the implementation of I/D space memory addressing. These bits, 04 through 06, yield MMU status information whenever a MMU abort occurs and are used in conjunction with MMR0 bits 01 through 03 and 13 through 15 to provide complete execution mode and I/D space status for the page causing the abort. See figure 1. Page 5 Bit 04, the page address space status bit, indicates the address space associated with the aborted page and is equal to a zero (0) for an instruction space page and a one (1) for a data space page whenever I/D space addressing is enabled. If I/D space addressing is not enabled this bit always reflects a zero (0). Bits 05 and 06, the processor mode status bits, indicate the processor execution mode associated with the page causing the abort. These bits are coded as follows: BIT 06 05 EXECUTION MODE ----- -------------- 0 0 KERNEL 0 1 SUPERVISOR 1 0 ILLEGAL (causes an abort with bit 15 set) 1 1 USER For more information on MMU aborts see micronote 008. Page 6 MMR0 ADDRESS: 17777572 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 +===+---+---+---+===+===+===+---+---+---+===+===+===+---+---+---+ | | | | 0 | 0 | 0 | 0 | 0 | 0 | | | | | +===+---+---+---+===+===+===+---+---+---+===+===+===+---+---+---+ |_| |_| |_| |_____| |_| |_________| |_| | | | | | | | | | |____ABORT READ-ONLY PAGE | PAGE | | | ACCESS VIOLATION MODE | NUMBER | | | | | | |________ABORT PAGE LENGTH ERROR PAGE ENABLE | ADDRESS RELOCATION |____________ABORT NON-RESIDENT SPACE (I/D) BIT # DESCRIPTION ----- ----------- <15> - ABORT READ-ONLY ACCESS VIOLATION (R ONLY) <14> - ABORT PAGE LENGTH ERROR (R ONLY) <13> - ABORT NON-RESIDENT (R ONLY) <12:07> - NOT USED (R ONLY) <06:05> - PAGE MODE (R ONLY) <04> - PAGE ADDRESS SPACE (I/D) (R ONLY) <03:01> - PAGE NUMBER (R ONLY) <00> - ENABLE RELOCATION (R/W) FIGURE 1 MEMORY MANAGEMENT REGISTER 0 (MMR0) 1.1.3 MEMORY MANAGEMENT REGISTER 3 Memory management register 3 (MMR3) contains control and status information for data space addressing, 22 bit mapping, and the call to supervisor mode (CSM) instruction. This register, once again, is discussed in detail in micronote 008. MMR3 contains three (3) control bits which are used in the implementation of I/D space addressing. These bits, 00 through 02, individually enable data space addressing for each of the execution modes. Bit 00 enables data space addressing for the USER mode, bit 01 enables it for SUPERVISOR mode, and bit 02 enables it for KERNEL mode. The desired bits are set to a one (1) whenever data space addressing is desired. MMR3 is cleared during power-up, console restart, and the execution of the RESET instruction. See figure 2. Page 7 MMR3 REGISTER ADDRESS: 17772516 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 +===+---+---+---+===+===+===+---+---+---+===+===+===+---+---+---+ | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | | | | MODE | +===+---+---+---+===+===+===+---+---+---+===+===+===+---+---+---+ |_| |_| |_| |_| |_| |_| | | | | | | UNINTERPRETED_____________| | | | | | | | | | | ENABLE 22 BIT MAPPING_________| | | | | | | | | ENABLE CSM INSTRUCTION____________| | | | | | | KERNEL________________________________| | | | | SUPERVISOR________________________________| | | USER__________________________________________| BIT # DESCRIPTION ----- ----------- <15:06> - NOT USED (R ONLY) <05> - UNINTERPRETED (R/W) <04> - ENABLE 22 BIT MAPPING (R/W) <03> - ENABLE CSM INSTRUCTION (R/W) <02> - KERNEL DATA SPACE (R/W) <01> - SUPERVISOR DATA SPACE (R/W) <00> - USER DATA SPACE (R/W) FIGURE 2 MEMORY MANAGEMENT REGISTER 3 1.1.4 I/D SPACE ADDRESS MAPPING When I/D space addressing has been enabled the MMU hardware performs the address mapping (IN ADDITION TO ADDRESS RELOCATION WHICH IS PERFORMED USING THE APPROPRIATE SET OF APR'S) as follows: 1. The current instruction is ALWAYS fetched from the instruction space. 2. The operands are mapped according to table 2. Page 8 +---------------+---------------+---------------+-------+ | OPERAND | REGISTER | TYPE | I OR D| | ADDRESSING | USED | OF | SPACE | | MODE | | ADDRESSING | USED | +---------------+---------------+---------------+-------+ | 000 | ANY | REGISTER | I | +---------------+---------------+---------------+-------+ | 001 | ANY | REGISTER | D | | | | DEFERRED | | +---------------+---------------+---------------+-------+ | 010 | 0 THROUGH 6 | AUTOINCREMENT | D | | | | | | | | 7 | IMMEDIATE | I | +---------------+---------------+---------------+-------+ | 011 | 0 THROUGH 6 | AUTOINCREMENT | D (A) | | | | DEFERRED | D (D) | | | | | | | | 7 | ABSOLUTE | I (A) | | | | | D (D) | +---------------+---------------+---------------+-------+ | 100 | 0 THROUGH 6 | AUTODECREMENT | D | | | | | | | | 7 | DO NOT USE !! | | +---------------+---------------+---------------+-------+ | 101 | 0 THROUGH 6 | AUTODECREMENT | D (A) | | | | DEFERRED | D (D) | | | | | | | | 7 | DO NOT USE !! | | +---------------+---------------+---------------+-------+ | 110 | ANY | INDEX | I (A) | | | | | D (D) | +---------------+---------------+---------------+-------+ | 111 | ANY | INDEX | I (A) | | | | DEFERRED | D (A) | | | | | D (D) | +---------------+---------------+---------------+-------+ (A) = INDIRECT OR INDEX ADDRESS (D) = DATA TABLE 2 OPERAND ADDRESSING WITH DATA SPACE ENABLED All address mapping is performed using the I space APR's when data space addressing is not enabled. The most difficult example showing data space addressing is the index deferred type of addressing. CLR @1000(R3) 1. The instruction is fetched from the instruction space at Page 9 location PC. 2. The base address 1000 is fetched from the instruction space at location PC+2. The index in R3 is added to the base address forming the address of the indirect address. 3. The indirect address is fetched from the data space using the address calculated in step 2. 4. The data is fetched from the data space using the address calculated in step 3. 1.2 I/D SPACE SOFTWARE At the present time I/D space addressing is supported by two (2) Digital supplied operating systems, RSX-11M-PLUS and ULTRIX-11. RSX-11M-PLUS provides linking of tasks which utilize I/D space addressing via the task builder (TKB) utility. Those programs which include the data PSECTs in their object files may be task built using the /ID switch. It should be noted that the task may not make use of the entire 32kw data space because RSX-11M-PLUS requires that the stack and the task header be placed in data space. Other restrictions may apply, consult the task builder manual for further information. When using I/D space with other operating systems or in standalone programs, the user must do all the mapping within the program. This implies that the mapping of the operating system must be attended to by the user program if operating system features are to be utilized. To make use of data space addressing the program must: 1. Separate the instruction space from the data space. (ie. create different regions in memory for instructions and data) 2. Load the instruction space and data space APR's with the appropriate relocation information. 3. Enable I/D space mapping by setting the MMR3 bit associated with the execution mode under which the program will run. The following restrictions apply to I/D space programs: 1. The instruction space can only contain instructions, immediate operands, absolute addresses, and index words. This is reflected in table 2. 2. The stack page must be mapped into both instruction and data space if the MARK instruction is used because it is executed off the stack. 3. Instruction space-only pages cannot contain subroutine parameters which are data. This precludes the mapping of any pages containing standard PDP-11 calling sequences entirely Page 10 into an instruction space page. 4. The trap catcher technique of putting .+2 in the trap vector followed by a halt must be mapped into both instruction and data space. For further information on I/D space addressing under RSX-11M-PLUS and ULTRIX-11 consult the appropriate documentation set. 2.0 SUPERVISOR MODE The DCJ11 based processors provide three (3) execution modes: KERNEL, SUPERVISOR, and USER. They provide for various forms of memory and processor protection and permit additional features to be implemented in multiprogramming environments. Each mode has its own set of mapping registers. KERNEL mode is the most privileged of the modes, allowing the execution of any instruction and the modification of any area in memory including the I/O page. USER mode prohibits the execution of privileged instructions such as HALT and RESET and the modification of areas in memory that the KERNEL program does not provide access to. SUPERVISOR mode has the same privileges as USER mode with its own set of mapping registers, thus providing another level of protection. SUPERVISOR mode is intended for use in the mapping and execution of programs to be shared by users while still providing protection from them. Examples of this are command line processors which are required for use by all users on a system, while necessitating write protection from them. The execution mode is controlled by the state of bits 14 and 15 in the processor status word (PSW). These bits are changed by the execution of traps and interrupts, pushing and popping of old PSW's to and from the stack, and, when in KERNEL mode, the direct manipulation by the program. Bits 12 and 13 reflect the execution mode which existed prior to the event which placed the processor in the current mode. See figure 3. The current and previous mode PSW bits are coded as follows: BIT 15 14 13 12 EXECUTION MODE ----- -------------- 0 0 KERNEL 0 1 SUPERVISOR 1 0 ILLEGAL 1 1 USER Page 11 PROCESSOR STATUS WORD (PSW) ADDRESS: 17777776 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 +===+---+---+---+===+===+===+---+---+---+===+===+===+---+---+---+ | | | | 0 | 0 | | | T | N | Z | V | C | +===+---+---+---+===+===+===+---+---+---+===+===+===+---+---+---+ |_____| |_____| |_| |_| |_________| |_| |_____________| | | | | | | | CURRENT PREVIOUS | | PRIORITY | CONDITION MODE MODE | | LEVEL | CODES | | | | | | GPR SUSPENDED TRACE GROUP INFORMATION BIT BIT # DESCRIPTION ----- ----------- <15:14> - CURRENT MODE (R/W) <13:12> - PREVIOUS MODE (R/W) <11> - GENERAL PURPOSE REGISTER SET (R/W) <10:09> - NOT USED (R ONLY) <08> - SUSPENDED INFORMATION (R/W) <07:05> - PROCESSOR PRIORITY LEVEL (R/W) <04> - TRACE BIT (R/W) <03> - NEGATIVE CONDITION CODE (R/W) <02> - ZERO CONDITION CODE (R/W) <01> - OVERFLOW CONDITION CODE (R/W) <00> - CARRY CONDITION CODE (R/W) FIGURE 3 PROCESSOR STATUS WORD ================================================================================ Note 12.0 DMA on the Q-bus No replies JAWS::KAISER 174 lines 25-MAR-1985 09:20 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 012 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: DMA on The Q-bus | Date: 06-SEP-84 | +----------------------------------------------------+-----------------+ | Originator: Jack Toto | Page 1 of 4 | +----------------------------------------------------+-----------------+ This Micronote explains the various types of DMA on the Q-bus; Single Cycle Mode, Burst Mode and Block Mode. SINGLE CYCLE MODE: ------------------ Single cycle mode DMA like all DMA on the Q-bus requires that the DMA device gain control of the bus through an arbitration cycle. During the arbitration cycle the DMA device becomes bus master by first asserting a DMA request (BDMR). When the arbiter acknowledges this request it issues a DMA grant (BDMGO). In the event that there is more than one DMA device in the backplane the grant signal is daisy chained from device to device. Eventually the device that issued the DMA request will latch the grant signal and take control of the bus, and proceed with the DMA transfer. Once becoming bus master the device asserts BSACK and is allowed to do one word tranfer to or from memory, during which time the CPU is idle. Certain processors such as the KDJ11-B have a cache memory with dual tag store which allows it to process data while DMA transfers are occurring. Regardless of which processor type is used only one transfer is allowed in single cycle mode. If the device must perform additional transfers, it must go through the bus arbitration cycle again. _______________ _______________ SACK ___________/ \____________/ \_____ BDAL __________/ ADRS/DATA \___________/ ADRS/DATA \_____ 1 2 In single cycle mode, the theoretical transfer rate across the Q-bus is 1.66 Mbytes/sec (833Kw/sec) A device such as the DRV11-B or the newer 22-bit compatible DRV11-W can transfer data at a rate of 250KW/sec while in single cycle mode. Page 2 BURST MODE: ----------- Burst mode DMA can be performed by certain devices such as the DRV11-B. Once the DMA controller becomes bus master (through the arbitration routine described in the single cycle section and it has asserted BSACK, the DMA tranfers can begin. Each data word that is transfered is accompanied by an address that the data word is targeted for. In burst mode loading an octal value into the 16 bit word count register (WCR) allows for that number of words (64Kb max) to be transfered under one sack. This differs from single mode, in that the word count register can be loaded with the same value, but each single word transfer will require a new arbitraion cycle, i.e in order to transfer 64Kb of data it would require 65,536 arbitration cycles. ________________________________________________ SACK ____/ \____ BDAL ____/ADRS/DATA ADRS/DATA ADRS/DATA................(N)\____ N := word count; The theoretical transfer rate across the Q-bus in burst mode remains at 1.66 Mbytes/sec, however a device such as the DRV11-B operating in burst mode can transfer data at a rate twice that of a DRV11-B operating in single mode, or 500Kw/sec. In burst mode the DMA bus master maintains control of the bus until it has transferred all of the required data. Burst mode has the advantage of moving large blocks of memory across the bus with no delay. The caution here is that no other device (including the CPU) has access to the bus during that time. This can have severe impact on system performance. DMA COMPROMISE: -------------- Since Single Cycle Mode requires a rearbitration for every data transfer and Burst Mode can adverseley impact system performance in some cases DIGITAL EQUIPMENT CORP. has made some compromises with certain DMA controllers. Most DIGITAL devices will do a limited Burst Mode operation. These controllers (for example the RXV21 and RLV12) are allowed up to do four words of data tranfer. Each word of transfer is preceeded on the bus by an address that the data word is targeted for. This allows data to move across the bus with a minimum of rearbitraton. However, when a group of four transfers is finished, the DMA devices must again go through the arbitration cycle in order to allow other Page 3 devices the opportunity to use the bus. If no other bus requests are pending at a higher priority, then bus mastership will be returned to the device for the next set of data transfers. ______________________________________ SACK ___________/ \_______ BDAL ___________/ADRS/DATA ADRS/DATA ARDS/DATA ADRS/DATA\_______ 1 2 3 4 BLOCK MODE: ---------- For increased throughput, Block Mode DMA may be implemented on a device for use with memories that support this type of transfer. Block Mode DMA devices are only block mode when operating. They may not operate as a Single or Burst Mode device. They may, however, appear to operate like a single mode device if they are only doing a single word transfer, and they will always look like a Single Cycle Mode DMA device when used with non-Block Mode memory. Once a Block Mode device has arbitrated for the bus, the starting memory address is asserted, then data for that address, followed by data for consecuetive addresses. By eliminating the assertion of the address for each data word, the transfer rate is almost doubled. The DMA device should monitor the BDMR line. If the line is not asserted after the seventh transfer than the device can continue. This allows a maximum of 16 data transfers for one abitration cylce. If the BDMR line is not monitored by the DMA device than a maximum data tranfer of 8 words is allowed after completing one bus arbitration cycle. Block Mode DMA transactions can be described as two types, a DATBI (block mode data in) and DATBO (block mode data out). Both of these cycles are explained in depth in the Micronote's. When reading the appropriate micronote special attention should be paid to the use of BREF and BBS7 signals when performing a DATBO. ___________________________________________ SACK___/ \___ BDAL___/ADRS/DATA/.........DEPENDS ON STATE OF BDMR\___ (1) * (7) (16) | ___ | BDMR \____________________*_______________________/\/\/ Block Mode devices such as the DEQNA, RQDX1 and the MSV11-P memories can Page 4 transfer data across the bus at rates that approach twice that of DMA devices in Burst Mode. The actual rate is dependent upon the device itself. The technical manuals for each of these devices should be checked for actual performance figures. ================================================================================ Note 13.0 MicroPower Run-time Perform. No replies JAWS::KAISER 254 lines 25-MAR-1985 09:20 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 013 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: Run-time System Performance Evaluation | Date: 09-Oct-84 | | Using MicroPower/Pascal V 1.5 | | +----------------------------------------------------+-----------------+ | Originator: Herbert Maehner | Page 1 of 5 | +----------------------------------------------------+-----------------+ In real-time programming, the performance of the run-time system and the compiler together govern the overall power of the application. The performance of the MicroPower/Pascal compiler has been extensively discussed by R.Billig/R.Cronk [1]. The performance of the run-time executive of MicroPower/Pascal is measured in this MicroNote using different LSI-11 CPU-boards and the KXT11-CA I/O processor. Data was obtained using MicroPower/Pascal version 1.5. Test Conditions --------------- Results obtained through a lab experiment are only as precise as the test environment and may only be referenced giving the exact test conditions. The goal was to measure the elapsed time of a given primitive execution on the Pascal process level, i.e. how long it takes to call/execute a kernel primitive from a Pascal program. Generally, the following procedure was used to obtain the elapsed time, where in some cases more than one output bit has been used to obtain the desired pulse-width. WHILE Condition = TRUE DO BEGIN Out_port.bit0 := TRUE; { here call/execute given primitive } Out_port.bit0 := FALSE; END; The whole test was done in a loop as long as the condition was true. Here, Condition is a boolean variable, which is set FALSE by a high priorty process waiting on a terminal input (READLN). The Outport.bit0 is bit0 of a parallel device. The parallel device was either a DRV11 (using LSI 11/23 and LSI 11/73) or the on-board parallel device (using the FALCON plus SBC 11/21 and KXT11-CA). Page 2 The bit0 pulse is used as the input to an oscilloscope which has the capabilities to measure and display time differences and frequencies. The elapsed time required to execute the various primitives was obtained. In addition to the primitive requests some math-functions times were obtained. The results are shown in Table 1 at the of this MicroNote. Interrupt-Test Conditions ------------------------- A Pascal-program with an embedded interrupt service routine needs DRIVER privileges in a mapped environment. The test program either connects to a "normal" ISR or to a prio7 ISR. The program executed a simple loop like: WHILE TRUE DO BEGIN Out_port.Bit1 := TRUE; Out_port.Bit1 := FALSE; END; The Outport is the parallel device of the type mentioned above. This is used to monitor process execution behavior. Testing the interrupt response time, we used a square wave generator which triggered an interrupt on that parallel device. The ISR was coded as .ENABL GBL ; Enable global symbols .MCALL MACDF$,PURE$ ; Set-up pure/impure area .MCALL IMPUR$ .GLOBL INPORT,OUTPRT ; port A,B of PPI MACDF$ ; MACDF$ must be called before the PURE$ ; two assembly directives .DSABL AMA PPIINT:: BISB #1,@#OUTPRT ; set bit 0 output port ------- MOVB @#INPORT,@#Temp ; dummy read | ISR time MOVB @#INPORT,@#Temp ; dummy read | measured BICB #1,@#OUTPRT ; set bit 0 output port ------- RTS PC ; normal ISR return RTS R4 ; prio 7 ISR return IMPUR$ TEMP: .WORD 0 ; reserve one word .END Depending upon the ISR-type either the RTS PC or the RTS R4 must be used to exit the ISR. The first MACRO-statement within the ISR signaled bit0 of the parallel port. The resulting interrupt dispatch time was defined as the pulse width given by the square wave generator Page 3 edge and the signaled output port. This includes the hardware ISR dispatch time as well. The ISR execution time was given by the pulse width indicated within ISR source above. Again, all pulses were measured using an oscilloscope. The maximum interrupt rate was determined by increasing the square frequency (which in turn increases the outpt square wave of the ISR) until the system lost interrupts. Using CONNECT SEMAPHORE the interrupt performance was similarly measured. In this case only a dynamic process was waiting on the semaphore to be signaled. The results are shown in table 2. References 1. Rich Billig and Randy Cronk, A System/Architecture Approach to Microcomputer Benchmarking, DIGITAL Equipment Corporation, Sept. 1982, EZ-12053-03/82 2. MicroPower/Pascal Newsletter, Volume 1, No. 1, March 1984, p. 23, DIGITAL Equipment Corporation, Order Number AV-B067A-TK Page 4 +---------------+-----------+-----------+-----------+------+------+ | | LSI-11/23 | LSI-11/23 | | | | | Operation | w/o FPU | w/ FPU | LSI-11/73 | SBC | KXT11| | | u m | u m | u m |11/21+| -CA | +---------------+-----------+-----------+-----------+------+------+ |Process | | | | | | | creation | 3.1 5.48 | 3.56 5.93 | 1.84 2.64 | 3.96 | 2.71 | | deletion | 2.4 4.19 | 2.55 4.35 | 1.14 1.92 | 2.96 | 2.06 | +---------------+-----------+-----------+-----------+------+------+ |Schedule + | | | | | | | Context Switch| 0.56 0.97 | 0.82 1.27 | 0.38 0.57 | 0.69 | 0.49 | +---------------+-----------+-----------+-----------+------+------+ | Ring_buffer | | | | | | | 1 character | | | | | | | get | 0.55 0.96 | 0.55 0.99 | 0.27 0.42 | 0.67 | 0.47 | | put | 0.50 0.93 | 0.51 0.95 | 0.25 0.39 | 0.63 | 0.43 | | 2 characters | | | | | | | get | 0.61 1.05 | 0.61 1.05 | 0.29 0.43 | 0.72 | 0.51 | | put | 0.58 1.01 | 0.58 1.02 | 0.28 0.42 | 0.70 | 0.49 | | 4 characters | | | | | | | get | 0.73 1.20 | 0.73 1.18 | 0.36 0.50 | 0.88 | 0.62 | | put | 0.71 1.17 | 0.71 1.15 | 0.35 0.49 | 0.86 | 0.60 | | Signal Semaphr| | | | | | | by descriptor| 0.35 0.64 | 0.35 0.65 | 0.16 0.25 | 0.44 | 0.30 | | by name | 0.61 0.93 | 0.61 0.94 | 0.27 0.37 | 0.75 | 0.52 | | fast named | 0.36 0.65 | 0.36 0.66 | 0.17 0.29 | 0.44 | 0.30 | +---------------+-----------+-----------+-----------+------+------+ | Get_status | 0.42 0.84 | 0.42 0.85 | 0.20 0.33 | 0.50 | 0.35 | +---------------+-----------+-----------+-----------+------+------+ | Send + Receive| | | | | | | (by value) | | | | | | | - 1 Byte | 1.17 2.18 | 1.18 2.20 | 0.59 0.89 | 1.45 | 1.01 | | - 34 Bytes| 1.46 2.50 | 1.46 2.51 | 0.73 1.11 | 1.79 | 1.24 | | Send + Receive| | | | | | | (by reference)| | | | | | | - 10 Bytes| 1.26 2.28 | 1.26 2.31 | 0.67 0.96 | 1.54 | 1.08 | | - 100 Bytes| 1.59 2.64 | 1.59 2.67 | 0.84 1.14 | 1.94 | 1.35 | | - 500 Bytes| 3.09 4.32 | 3.09 4.35 | 1.74 2.11 | 3.78 | 2.63 | +---------------+-----------+-----------+-----------+------+------+ | TAN | 6.84 7.74 | 1.64 1.68 | 0.35 0.36 | 9.00 | 6.24 | +---------------+-----------+-----------+-----------+------+------+ | SIN | 5.13 5.82 | 1.75 1.78 | 0.33 0.34 | 6.80 | 4.69 | +---------------+-----------+-----------+-----------+------+------+ | COS | 6.19 7.00 | 1.94 1.98 | 0.39 0.39 | 8.15 | 5.64 | +---------------+-----------+-----------+-----------+------+------+ | EXP | 5.04 5.69 | 1.45 1.48 | 0.32 0.33 | 6.55 | 4.59 | +---------------+-----------+-----------+-----------+------+------+ | LN | 5.34 6.01 | 1.27 1.31 | 0.28 0.29 | 6.95 | 4.86 | +---------------+-----------+-----------+-----------+------+------+ Table 1: MicroPower/Pascal V1.5 Runtime System (millisec) Page 5 Notes for Table 1 ----------------- o u = without MMU and m = with MMU o FPU = with floating point unit (KEF11) o Send/Receive without context-switch o SBC-11/21+ using on-board memory only +------------------------+-----------+-----------+-------+-------+ | Operation | LSI-11/23 | LSI-11/73 | SBC | KXT11 | | | u m | u m | 11/21+| -CA | +------------------------+-----------+-----------+-------+-------+ | ISR: | | | | | | | | | | | | Interrupt dispatch- | | | | | | time (usec) | 62 91 | 42 54 | 81 | 61 | | | | | | | | ISR execution | | | | | | time (usec) | 20 23 | 13.4 | 21 | 16 | | | | | | | | Maximal interrupt- | | | | | | frequency (kHz) | 7.0 5.1 | 12.9 10.9 | 4.8 | 7.5 | +------------------------+-----------+-----------+-------+-------+ | PRIO7 ISR: | | | | | | | | | | | | Interrupt dispatch- | | | | | | time (usec) | 28.5 60 | 22 38 | 32 | 28 | | | | | | | | ISR execution | | | | | | time (usec) | 20 24 | 13.4 | 21 | 16 | | | | | | | | Maximal interrupt- | | | | | | frequency (kHz) | 17.8 9.3 | 26 16 | 12.8 | 16.5 | +------------------------+-----------+-----------+-------+-------+ | CONNECT_SEMAPHORE: (one process waiting on that semaphore) | | | | Interrupt dispatch + | | | | | | context-switch time | | | | | | (msec) | 0.88 1.36 | 0.49 0.63 | 1.15 | 0.82 | | | | | | | | Maximal interrupt- | | | | | | frequency (kHz) | 0.67 0.39 | 1.20 0.83 | 0.41 | 0.75 | +------------------------+-----------+-----------+-------+-------+ Table 2: Interrupt Performance Note for Table 2 ---------------- Additionally, the system had to service the clock interrupt at a rate of 50 Hz without the clock driver implemented, i.e. the interrupt dispatcher discarded the interrupt. The clock interrupt was enabled because realistically most systems have the clock enabled. ================================================================================ Note 14.0 Fortran Routines from VAXELN No replies JAWS::KAISER 203 lines 25-MAR-1985 09:20 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 014 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: Using Fortran Routines In A | Date: 16-Oct-84 | | VAXELN-Pascal Environment | | +----------------------------------------------------+-----------------+ | Originator: Herbert F. Maehner | Page 1 of 4 | +----------------------------------------------------+-----------------+ This Micronote discusses the VAXELN interface to VAX-11 Fortran. The following topics are covered are discussed: 1. The VAX-11 Procedure Calling Standard 2. Establishing a COMMON-data area between a VAXELN program and Fortran routines VAXELN Procedure Calling Standard --------------------------------- VAXELN Pascal (EPascal) does conform to the VAX Procedure Calling Standard. The standard allows for three methods of parameter passing : value, reference, and descriptor, and requires that values be no longer than a longword. EPascal does not explicitly support descriptors as parameters, and other languages may not treat conformant parameters as EPascal does, but EPascal does nothing to violate the calling standard. All routines can be described according to the conventions described in the summary of run-time library entry points [1]. There are principle differences in passing parameters in Pascal and Fortran: In Pascal, you may pass parameters as - values, e.g PROCEDURE Pass_it (What: INTEGER); i.e. the value of the parameter will be copied into the procedure's stack frame with no implications for the source variable. This is termed pass by value. or as - variable, e.g. PROCEDURE Pass_it (VAR What: INTEGER); i.e. the parameter will be referenced through its address. An assignment to the parameter within the procedure will directly affect the source variable. This is termed pass by reference. Page 2 In Fortran, you pass parameters as - values, e.g. SUBROUTINE Passit( What) INTEGER*4 What i.e. with no implications for the source. It uses a common data area to pass variables to the main program. The main difference to Pascal is, that Fortran uses pass by reference, although it is actually a value. Calling a Fortran routine with parameter passing from a Pascal environment, you have to declare the parameters as VAR parameters in Pascal ( Figure 1 and Figure 2). COMMON Data Area ---------------- As mentioned before, Fortran uses a COMMON data area to pass variables from procedures to the main part of the program. In VAX-11 Pascal the [COMMON] attribute enables the linker to establish the common data section. VAXELN- Pascal has no such attribute and wouldn't overlay data sections for common areas. To overcome this restriction you must use the [EXTERNAL] attribute in VAXELN-Pascal to declare the prospective data as externally declared and use a MACRO-32 declaration to assign the Fortran common part to the "global" data area (Figure 3). References: 1. VMS RUN TIME LIBRARY USER'S GUIDE (Summary of Run Time Library Entry Points) 2. VAXELN Encyclopedia, Procedures and Functions, 3. VMS MACRO Language Reference Manual Page 3 +--------------------------------------------------------------------+ | MODULE Fortran_TO_Pascal; | | | | { This module is a simple example on, how to use Fortran | | routines in VAXELN. } | | | | CONST | | Max = 50; | | | | TYPE | | Array_type = ARRAY[1..Max] OF INTEGER; | | | | VAR | | AA: [EXTERNAL] Array_type; | | | | PROCEDURE Valaccess (VAR What:INTEGER); EXTERNAL; | | | | FUNCTION Double_it (VAR What: INTEGER):INTEGER; EXTERNAL; | | | | PROGRAM FORTEST(INPUT,OUTPUT); | | | | VAR | | What,I,J,K: INTEGER; | | Twenty: [READONLY] INTEGER:=20; | | | | BEGIN | | WRITELN('Program start '); | | FOR I:=1 TO Max DO AA[I] := 0; { initialize array } | | Valaccess(Twenty); { call Fortran routine Valaccess } | | FOR I:=21 TO Max DO | | BEGIN | | What := I; | | AA[I] := Double_it(What); { use Fortran Function to | | END; double array value } | | | | { formated output to screen } | | | | K := 1; | | FOR I:=1 TO 10 DO | | BEGIN | | FOR J:=1 TO 5 DO | | BEGIN | | WRITE(AA[K]:4,' '); | | K := K+1 | | END; | | WRITELN; | | END; | | END; | | END; { end of module Fortran_to_Pascal } | | | +--------------------------------------------------------------------+ Figure 1 : VAXELN main program module Page 4 +--------------------------------------------------------------------+ | C | | C Fortran SUBROUTINE TO SET THE INDEXED ARRAY VALUE | | C THE MAXIMAL INDEX IS PASSED AS A PARAMETER | | C | | SUBROUTINE VALACCESS(WHAT) | | IMPLICIT INTEGER*4 (A-Z) | | C | | COMMON /XX$AA/ AA(50) | | C | | C | | DO 10 I=1,What | | AA(I) = What-I | | 10 CONTINUE | | C | | RETURN | | C | | END | | C | | C | | C | | C INTEGER FUNCTION TO DOUBLE THE VALUE PASSED AS A PARAMETER | | C | | INTEGER FUNCTION DOUBLE_IT(WHAT) | | IMPLICIT INTEGER*4 (A-Z) | | DOUBLE_IT = WHAT + WHAT | | RETURN | | C | | END | | | +--------------------------------------------------------------------+ Figure 2: External Fortran routines used +--------------------------------------------------------------------+ | ; | | ; definition file for common array AA to be accessed by Fortran | | ; subroutine VALACCESS | | ; the P-section name XX$AA must be the same as the one used in the | | ; Fortran routine | | ; | | .TITLE COMDAT | | .PSECT XX$AA,LONG,PIC,USR,OVR,REL,GBL,SHR,NOEXE,RD,WRT,NOVEC | | AA:: .LONG 50 | | .END | | | +--------------------------------------------------------------------+ Figure 3: MACRO definition module to define the common array ================================================================================ Note 15.0 Q-bus Hardware Bootstraps No replies JAWS::KAISER 194 lines 25-MAR-1985 09:21 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 015 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: Q-Bus Hardware Bootstraps | Date: 16-Oct-84 | +----------------------------------------------------+-----------------+ | Originator: Dave Smith | Page 1 of 4 | +----------------------------------------------------+-----------------+ The purpose of this micronote is to provide a comprehensive list of Q-Bus hardware bootstraps and the devices they support. The tables on the next two pages are organized as follows. There is a row for each of the currently supported bootable devices. There is a column for each hardware bootstrap. The columns span both pages. In the heading for each bootstrap will be found any ordering information and/or references to notes which follow the tables. When two order numbers are given, both must be ordered since the boot code is divided into high byte and low byte ROMs. The bootstrap devices listed are: +============+======================================================+ | | | | BOOT | DESCRIPTION | | DEVICE | | | | | +============+======================================================+ | BDV11 | Bus Terminator, Bootstrap & Diagnostic ROM | | | used primarily with older LSI-11 configurations | +------------+------------------------------------------------------+ | MXV11-A2 | Bootstrap ROM set designed for MXV11-A board | +------------+------------------------------------------------------+ | MXV11-B2 | Bootstrap ROM set designed for MXV11-BF & MRV11-D | +------------+------------------------------------------------------+ | KDF11-BA | Bootstrap ROM on board PDP-11/23+ systems | +------------+------------------------------------------------------+ | KDF11-BE | Bootstrap ROM on board MicroPDP-11/23 systems | +------------+------------------------------------------------------+ | KDF11-BF | New Bootstrap ROM for PDP-11/23+ and MicroPDP-11/23 | +------------+------------------------------------------------------+ | KXT11-A2 | Bootstrap ROM on board Falcon | +------------+------------------------------------------------------+ | KXT11-A5 | Bootstrap ROM on board Falcon-Plus | +------------+------------------------------------------------------+ | KDJ11-B | Bootstrap ROM on board MicroPDP-11/73 CPU | +------------+------------------------------------------------------+ | uVAX I | Bootstrap ROM on board MicroVAX I CPU | +============+======================================================+ Page 2 BOOTSTRAP DEVICE SUPPORT +==========+==========+==========+==========+==========+==========+ | DEVICE | BDV11 | MXV11-A2 | MXV11-B2 | KDF11-BA | KDF11-BE | | | | | | | | | | Rev A | |see Note 2| part no | part no. | | | | | | 23-339E2| 23-157E4| | |see Note 1| | | 23-340E2| 23-158E4| +==========+==========+==========+==========+==========+==========+ | RX01 | X | X | X | X | X | +----------+----------+----------+----------+----------+----------+ | RX02 | X | X | X | X | X | +----------+----------+----------+----------+----------+----------+ | TU58 |see Note 1| X | X | X | X | +----------+----------+----------+----------+----------+----------+ | RL01/2 | X | X | X | X | X | +----------+----------+----------+----------+----------+----------+ | MRV11-C | | X | | X | | +----------+----------+----------+----------+----------+----------+ | MRV11-D | | | | | | +----------+----------+----------+----------+----------+----------+ | RK05 | X | X | | | | +----------+----------+----------+----------+----------+----------+ | RX50 | | | X | | X | +----------+----------+----------+----------+----------+----------+ | RD51 | | | X | | X | +----------+----------+----------+----------+----------+----------+ | RD52 | | | | | | +----------+----------+----------+----------+----------+----------+ | TSV05 | | | X | | | +----------+----------+----------+----------+----------+----------+ | TK25 | | | | | | +----------+----------+----------+----------+----------+----------+ | RC25 | | | | | | +----------+----------+----------+----------+----------+----------+ | DEQNA | | | | | | +----------+----------+----------+----------+----------+----------+ | DLV11-E | X | | X | X | | +----------+----------+----------+----------+----------+----------+ | DLV11-F | X | | X | X | | +----------+----------+----------+----------+----------+----------+ | DUV11 | X | | X | X | | +----------+----------+----------+----------+----------+----------+ | DPV11 | | | X | | | +==========+==========+==========+==========+==========+==========+ Page 3 BOOTSTRAP DEVICE SUPPORT +==========+==========+==========+==========+==========+==========+ | DEVICE | KDF11-BF | KXT11-A2 | KXT11-A5 | KDJ11-B | uVAX I | | | | | | | | | | part no | | |available |available | | | 23-183E4| | | on CPU | on CPU | | | 23-184E4| | |board only|board only| +==========+==========+==========+==========+==========+==========+ | RX01 | X | X | X | X | | +----------+----------+----------+----------+----------+----------+ | RX02 | X | X | X | X | | +----------+----------+----------+----------+----------+----------+ | TU58 | X | X | X | X | | +----------+----------+----------+----------+----------+----------+ | RL01/2 | X | | X | X | | +----------+----------+----------+----------+----------+----------+ | MRV11-C | | | | | | +----------+----------+----------+----------+----------+----------+ | MRV11-D | | | | | X | +----------+----------+----------+----------+----------+----------+ | RK05 | | | | X | | +----------+----------+----------+----------+----------+----------+ | RX50 | X | | X | X | X | +----------+----------+----------+----------+----------+----------+ | RD51 | X | | X | X | X | +----------+----------+----------+----------+----------+----------+ | RD52 | X | | | X | X | +----------+----------+----------+----------+----------+----------+ | TSV05 | X | | | | | +----------+----------+----------+----------+----------+----------+ | TK25 | X | | | X | | +----------+----------+----------+----------+----------+----------+ | RC25 | X | | |See note 3|See note 3| +----------+----------+----------+----------+----------+----------+ | DEQNA | X | | | X | X | +----------+----------+----------+----------+----------+----------+ | DLV11-E | | | | X | | +----------+----------+----------+----------+----------+----------+ | DLV11-F | | | | X | | +----------+----------+----------+----------+----------+----------+ | DUV11 | | | | X | | +----------+----------+----------+----------+----------+----------+ | DPV11 | | | | | | +==========+==========+==========+==========+==========+==========+ Page 4 NOTES: ------ (1) The information in the BDV11 column refers to the Rev A chips. There were also Rev O chips and an additional TU58 chip that can be added to the board: Rev O: Part numbers 23-010E2, 23-011E2 Does NOT support: DLV11-F, RX02 as bootable devices TU58 ROM: Part number 23-126F3 Inserted into socket XE40. Other ROM must be Rev A. Allows use of the TU58 DECtape II as a bootable device. (2) The MXV11-B2 Bootstrap ROMs can be used with the MXV11-BF multifunction module as well as the MRV11-D ROM module. It will not work with the MXV11-A module. (3) The RC25 adapter board must be configured at the the DEC standard base address for the first MSCP controller (772150). Other MSCP controllers may also reside but may not be booted. ================================================================================ Note 16.0 KXT11-CA Development Tools No replies JAWS::KAISER 388 lines 25-MAR-1985 09:21 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 016 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: KXT11-CA Software Development Tools | Date: 16-OCT-84 | +----------------------------------------------------+-----------------+ | Originator: Scott Tincher | Page 1 of 7 | +----------------------------------------------------+-----------------+ The KXT11-CA is a single board computer (SBC) which executes the PDP-11 instruction set. It may be utilized as a stand-alone SBC or interfaced to the Q-bus as a peripheral processor or as an intelligent I/O processor (IOP). This article will describe the software tools available to develop applications in either the stand-alone mode or the IOP mode. The KXT11-CA features: o T11 Microprocessor which implements the PDP-11 instruction set o 32K bytes of on-board static RAM o Two 28-pin sockets for up to 16K bytes of additional RAM or 32K bytes of ROM o Three serial line units: o One asynchronous DL compatible line (RS232) o One synch/asynch line with modem control (RS449) o One synch/asynch with data and timing only (RS449) o 20 programmable parallel I/O lines o Three 16-bit programmable interval timers o 2-channel DMA controller o Q-bus interface o Four diagnostic LEDs The Q-bus interface of the KXT11-CA allows up to 14 KXT11-CAs to be added to a traditional Q-bus system. As a slave device the KXT11-CA offloads the arbiter CPU's processing activities by providing real-time I/O data buffering, preprocessing, and high speed communications. The KXT11-CA is especially suited for applications with critical interrupt latency requirements or applications that must service a high frequency of interrupts. The KXT11-CA may also be used as a computational engine in applications where it is possible to partition the application to run in parallel. Page 2 The software development environment for systems which utilize KXT11-CAs is slightly different from that of the traditional Q-bus system. The system programmer must develop application programs for each KXT11-CA in the system in addition to the application code which runs on the arbiter CPU. Different software application tools are available for the arbiter and "onboard" environments. (When used in stand-alone mode only the onboard environment need be considered.) THE ARBITER ENVIRONMENT The arbiter system may run under any of the following operating systems: o MicroPower/Pascal o RT-11 o RSX-11M o RSX-11M-PLUS Each of these operating systems offers a device handler for the two-port RAM of the KXT11-CA as well as a utility for loading application programs across the Q-bus into the KXT11-CA. A MicroPower/Pascal application may be coded in Pascal and MACRO-11. RT-11 and RSX-11 applications will be coded in MACRO-11 or a high level language, such as FORTRAN, which is capable of issuing programmed requests (RT-11) or QIO directives (RSX-11). USING A MICROPOWER/PASCAL ARBITER SYSTEM If the arbiter system controlling the application is running in a MicroPower/Pascal environment there are KXT11-CA specific functions available to aid in program development. The first component is the KX device handler. This handler provides the arbiter-side interface to the two-port RAM of the KXT11-CA. The KX handler supports up to 14 KXT11-CAs on the Q-bus. Two functions are supplied which simplify the interface between the application program and the KX handler. These functions are: o KX_write_data: Transfer data from an arbiter buffer to a KXT11-CA process and return a completion-status value. o KX_read_data: Transfer data from a KXT11-CA process to an arbiter buffer and return a completion-status value. MicroPower/Pascal also provides a function which transfers a MicroPower/Pascal .MIM file from the arbiter to a KXT11-CA. This function, KXT_LOAD, reads a .MIM file from the arbiter and initiates a DMA transfer using the DTC of the KXT11-CA to transfer the file to the KXT11-CA's local memory. This procedure may be called at any time by the arbiter's application program - not necessarily at system startup time. Page 3 MicroPower/Pascal also supplies the symbolic debugger PASDBG. PASDBG supplies the following features: o A set of debugger commands and qualifiers that allow for control of an executing program. o Access to the symbol table generated by the Pascal compiler, providing symbolic (Pascal language) referencing and variable access. o Access to process control variables and structures. o Control of an application system not configured for terminal I/O. o A method for user control after an execution error. o A method for loading a program on the application system while PASDBG is running on a host computer. USING AN RT-11 OR RSX-11 ARBITER SYSTEM If the arbiter system controlling the application is running in a RT-11 or RSX-11 environment there are tool kits available to aid in program development. They are the KXT11-C/RT-11 Peripheral Processor Tool Kit (QJV51) and the KXT11-C/RSX-11 Peripheral Processor Tool Kit (QJV52). There are two major components in each of these tool kits. They are the KX device handler and the KUI utility program. The KX device handler manipulates the two-port RAM of the KXT11-CA so that it appears to be a standard Q-bus I/O device. The KUI utility program allows programs to be loaded into a peripheral processor from the arbiter, performs debugging operations, starts execution of KXT11-C programs, and initiates KXT11-CA selftests. The KX handler supplied with the RT-11 tool kit supports up to four KXT11-CAs where each KXT11-CA appears as two logical units. More than four KXT11-CAs may be supported by editing, renaming, and rebuilding the KX handler. The following RT-11 programmed requests are supported by the KX handler: o .OPEN - associates a user-specified channel number with a logical unit number of the KXT11-CA. o .CLOSE - frees a previously opened channel for use with another device or file. Page 4 o .READ - transfers data from a peripheral processor to an arbiter buffer. (.READ, .READW, .READC) o .WRITE - transfers data from an arbiter buffer to a peripheral processor. (.WRITE, .WRITEW, .WRITEC). The KX handler supplied with the RSX-11 tool kit supports up to 14 KXT11-CAs. The KX handler assigns a unit number for each data channel in each KXT11-CA two-port RAM. This handler supplies the following RSX-11 I/O requests: o IO.RVB - Read a virtual block of data from the device unit unit specified in the macro call. o IO.WVB - Write a virtual block of data to a physical device unit. o IO.ATT - Attach a physical device to the control of the task which issued the request. o IO.DET - Detach a physical device from the control of the task which issued the request. Included in the RT-11 and RSX-11 tool kits is the KUI (KXT11-CA User Interface) utility program. The KUI program has several commands which supply the following functions: o @ - Process commands from the specified indirect command file. o CLOSE - Close the file specified in the LOG command. o EXECUTE - Start a program on the specified KXT11-CA. o EXIT - Exit the KUI utility and return to the operating system. o LOAD - Load a program from the arbiter's mass storage to arbiter memory. Then perform a DMA operation to transfer the image to the specified peripheral processor's memory. KUI under RT-11 supports the transfer of .SAV, .LDA, and .MIM files. KUI under RSX-11 supports the transfer of .TSK and .MIM files. o LOG - Record all commands, status information, and messages during this terminal session in the specified file. The CLOSE command terminates the logging session. Page 5 o ODT - Executes the octal debugging tool (ODT). This tool allows the arbiter system to examine and modify the contents of registers and memory local to a KXT11-CA. ODT may also be used to start or halt a program. o REINIT - Reinitialize the specified peripheral processor and reboot it's application. o RESUME - Causes a SUSPENDed command file to continue execution. o SELFTEST - Causes one or more of several diagnostic programs to execute. o SET - Specifies a peripheral processor as the target for subsequent commands. o SHOW - Displays information about the state of the peripheral processor. o SUSPEND - Used in an indirect command file to halt execution of the file. The RESUME command can return control to the command file. o TRAP - performs a trap emulation so that a trap handling routine can be tested. THE ONBOARD PROGRAMMING ENVIRONMENT The KXT11-CA may be programmed in either MACRO-11 or MicroPower/Pascal. MicroPower/Pascal provides the ability to program the onboard devices in a high-level language, Pascal. In particular MicroPower/Pascal provides the following device handlers: o DD: This handler supports the TU58 tape drive. It allows the TU58 to be interfaced to any of the asynchronous I/O channels. o KK: This handler manipulates the two-port RAM from the KXT11-CA side in the KX/KK protocol. This protocol allows the KK handler to pass variable length messages to the arbiter system by emulating a traditional Q-bus slave device. Two functions are supplied which simplify the interface between the user's application code and the KK handler. These functions are: o KK_read_data: transfer data from the arbiter to a KXT11-CA buffer and return a completion-status value. o KK_write_data: transfer data from a KXT11-CA buffer to the arbiter and return a completion-status value. Page 6 o QD: This handler supports the two-channel DMA transfer controller (DTC). The QD handler enables the DTC to move data from source to destination without the aid of the CPU. One location, source or destination, must be local to the KXT11-CA. The QD handler may be used for the following functions: o Transfer data to and from Q-bus memory. o Transfer data to and from local memory. o Search for data. o Transfer to and from local I/O devices. o Access the Q-bus I/O page. o Assure access to a DMA Channel. o XL: Supports asynchronous communications on the three serial ports of the KXT11-CA. The first port is a standard DL device. The second port is channel A of the multiprotocol chip. This channel is supported with full modem controls. The third port is channel B of the multiprotocol chip. This channel is supported as though it were a standard DL device. All three channels may be operated simultaneously. o XS: Supports synchronous operation of channel A of the multiprotocol chip. The handler provides the following bit-oriented communication procedures: o Synchronization (Flag detection) o Transparency (Bit stuffing) o Invalid frame detection o Frame abortion detection o Frame check sequence (FCS) checking/calculation The handler can be used by user-written software as a component in performing bit-oriented protocols such as X.25, HDLC, SDLC, and others. o YK: Supports the parallel I/O port and the three counter-timers. The handler provides the functions of read, write, pattern recognition, DMA read, DMA write, counter-timer set, counter-timer read, and counter-timer clear. Typical parallel port operations are: Page 7 o Transferring a series of bytes or words through a port with handshake protocol. o Setting or reading the bits of external state lines. o Generating a time base to software. o Generating a waveform for external output. o Counting pulses from an external input. These MicroPower/Pascal device handlers do not support all of the functions of the onboard devices of the KXT11-CA. For this reason, or because of preference, the application code for the KXT11-CA may also be written in MACRO-11. RELATED DOCUMENTS For further information pertaining to the KXT11-CA and it's software development tools please reference the following materials: KXT11-CA Single-Board Computer User's Guide EK-KXTCA-UG KXT11-C Peripheral Processor Software User's Guide AA-Y615A-TK ================================================================================ Note 17.0 LSI-11/23 ECO History 1 reply JAWS::KAISER 365 lines 25-MAR-1985 09:22 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 017 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: LSI 11/23 ECO History | Date: 19-NOV-84 | +----------------------------------------------------+-----------------+ | Originator: Bob Hessinger | Page 1 of 8 | +----------------------------------------------------+-----------------+ This micronote documents the ECO and etch revision history of the KDF11-A (LSI 11/23) module. A quick verify has been included so that the status of a module may be determined by a visual check. For the M8186, the revision identifier is a two field alphanumeric designation stamped on the reverse side of the module handle. The first field indicates the etch revision. The second field indicates the modifications to this etch. Hardware revision notation : A 0 Identifies etch level Identifies modifications The M8186 began as hardware revision "A0", as shown above. That is, etch revision "A" with no modifications or rework. As ECO's were released calling for rework, the hardware revision level was updated to "A1", then "A2", etc. Periodically new etch revisions were released, incorporating previous modifications. When these occurred the etch revision field was updated from "A" to "C", and later from "C" to "D". For the M8186, no etch revision "B" was released. Page 2 The hardware revision history of the M8186 is shown below: Release A0 | Rework A1 ECO #1 | | Rework A2 ECO #2 | | NOTE: All modules Rework A3 shipped are at ECO #3 | rev A3 or greater | | NOTE : New etch Relayout +---- C0 rev C created. No ECO #4 | | rev B boards were | | built | | Rework A4 C0 NOTE: Rev C etch incorporates ECO #5 | | changes for ECO #5 | | Rework A5 C1 ECO #6 | | | | Rework A6 C2 ECO #7 | | | | Rework A6 C2 NOTE: This was a documen- ECO #8 | | tation change only | | Rework A7 C3 ECO #9 | | | | Rework and A8 C4 --- D0 Relayout | | | ECO #10 | | | | | | Rework A8 C4 D0 NOTE: This was a ECO #11 documentation change only Page 3 Jumper Functions on Etch Revision "A", "C" and "D" Modules +----------+------------------------------------------------------------+ | Jumper | Function | Description | Shipped | +----------+---------------+-------------------------------+------------+ | W1 | Master Clock | In = Enabled, do not remove | In | +----------+---------------+-------------------------------+------------+ | W2,W3 | DEC Reserved | Factory configured, do not | W2=Out | | | | change (see note 1) | W3=In | +----------+---------------+-------------------------------+------------+ | W4 | BEVENT | Out = Enabled | In | +----------+---------------+-------------------------------+------------+ | W5,W6 | Power-up Mode | Mode W5 W6 | Mode 1 | | | | 0 - PC=24,PS=26 Out Out | W5=In | | | | 1 - Console ODT In Out | W6=Out | | | | 2 - Bootstrap Out In | | | | | 3 - Reserved In In | | +----------+---------------+-------------------------------+------------+ | W7 | Halt/Trap | In = Trap to 10 on Halt | Out | | | Option | Out = Enter Console ODT | | | | | on Halt | | +----------+---------------+-------------------------------+------------+ | W8 | Bootstrap | In = Boot to 17773000 | In | | | Address | Out = Bootstrap address | | | | | specified by jumpers W9-W15 | | +----------+---------------+-------------------------------+------------+ | W9-W15 | User Bootstrap| W9-W15 correspond to address | In | | | Address | bits 9-15 respectively. | | | | | In = logic 1, Out = logic 0 | | +----------+---------------+-------------------------------+------------+ | W16,W17 | DEC Reserved | Factory configured, do not | In | | | | change | | +----------+---------------+-------------------------------+------------+ | Etch A only | +----------+---------------+-------------------------------+------------+ | W18 | DEC Reserved | Factory configured, do not | In | | | | change | | +----------+---------------+-------------------------------+------------+ | W19 |Wake-up Circuit| Out = enabled | In | | | | This jumper is a red wire | | | | | across diode D1 | | +----------+---------------+-------------------------------+------------+ | Etch C and D only | +----------+---------------+-------------------------------+------------+ | W18 |Wake-up Circuit| Out = enabled | In | | | | This jumper is a red wire | | | | | across diode D1 | | +----------+---------------+-------------------------------+------------+ note 1 : W3 on etch A modules consists of a jumper from E2 pin 5 to E2 pin 15. Page 4 +-------------------------------------------------------+ | | | | | | | W18 --- | | | | | | D1 --- | | (W19 - see text) | | | | | | | | | | W17 --- | | +----+ +----+ +----+ +----+ | | | | | | | | | | | | | | | | | | | | W1 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | W16 | | | | | | | | | | | | | | +----+ +----+ +----+ +----+ | | | | W15 --- W2 --- | | W14 --- | | W13 --- | | W12 --- | | W11 --- | | W10 --- | | W9 --- | | W8 --- | | W6 --- | | W7 --- | | W6 --- | | W5 --- W4 --- | | | | | | | | | | | | | | +-+ | ++ +---+ | ++ | | | | +-----------------------+ +-----------------------+ KDF11-A REV A Jumper Layout Page 5 +-------------------------------------------------------+ | | | | | | | | | | | | | | | D1 --- | | (W18 - see text) | | | | | | | | | | +----+ +----+ +----+ +----+ | | | | | | | | | | | | | | | | | | | | W1 --- | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +----+ +----+ +----+ +----+ | | | | W15 --- | | W14 --- | | W13 --- | | W12 --- | | W11 --- | | W10 --- | | W9 --- | | W8 --- | | W6 --- | | W7 --- W4 --- W3 --- | | W6 --- | | W5 --- W2 --- | | | | | | | | | | W16 --- | | W17 --- | | | | +-+ | ++ +---+ | ++ | | | | +-----------------------+ +-----------------------+ KDF11-A REV C Jumper Layout Page 6 +-------------------------------------------------------+ | | | | | | | | | | | | | | | | | W18 | | | | | | | | | | | | | | +----+ +----+ +----+ +----+ | | | | | | | | | | | | | | | | | | | | W1 --- | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +----+ +----+ +----+ +----+ | | | | W15 --- | | W14 --- | | W13 --- | | W12 --- | | W11 --- | | W10 --- | | W9 --- | | W8 --- | | W6 --- | | W7 --- W4 --- W3 --- | | W6 --- | | W5 --- W2 --- | | | | | | | | | | | | W16 --- | | W17 --- | | +-+ | ++ +---+ | ++ | | | | +-----------------------+ +-----------------------+ KDF11-A REV D Jumper Layout Page 7 The following table details the ECO's issued since the M8186 began to ship to the field. These ECO's are coded "M8186-ML0XX", where "XX" is the ECO number shown below : ECO # Problem Quick Verify -------------------------------------------------------------------------- 04 Too many wires and etch cuts, new etch Module handle will be needed. Note that the jumper locations stamped "Cn" where change for etch Revision C. "n" indicates Note also that etch A boards bring only modifications 18 bits of addressing from the MMU to the Q-BUS, while etch C boards bring all 22 bits of addressing from the MMU to the Q-BUS. 05 I/O page addressing scheme differs from Check for etch cut LSI-11/2 processor. to pins 16 and 18 (rev A boards only) 06 The internal wake-up circuit defeats the Red jumper wire is power sequencing provided by standard installed in parallel DEC power supplies. with D1. 07 CTL/DAT hybrid (57-00000-00) and MMU IC CTL/DAT should be (21-15542-00) were not compatible with 57-00000-01 or higher KEF11-AA floating point option. The FP and MMU should be registers in the MMU were inaccessible, 21-15542-01 or higher and the CTL/DAT data path caused for floating point intermittent errors in floating point compatibility. instructions. Coordinate with EC0 M8186-ML009 08 MMU (21-15542-01) was included as part of Some modules may or the M8186 module. This documentation not have MMUs, change removes the MMU and makes it an depending on the option which is ordered separately. options ordered. Page 8 ECO # Problem Quick Verify ------------------------------------------------------------------------- 09 1) No jumper table in print set (doc only) 1) Table added 2) Crystal oscillator may short to adjacent 2) Manufacturing components includes nylon spacer 3) Possibility of worst case MMU timing 3) Module will have violations. Change configuration W2 removed and W3 of W2 and W3 to adjust timing. This in. On rev A ECO must be installed : modules W3 is a A) When ECO m8186-ML007 is installed wire from E2 pin B) When the KEF11 or FPF11 is installed 5 to E2 pin 15. C) When one of the F-11 chips is replaced D) Whenever unexplained system crashes occur 10 1) Heavily loaded systems lock up during 1) Rev A and Rev C worst case timing between DMA and modules will have interrupt arbitration. Symptoms wires on E2 pins usually occur with DMA options not 2 and 4. Rework manufactured by DEC. included in Rev D. 2) Too many wires and etch cuts, new etch 2) Module handle will needed. Note W18 now uses jumper posts. be stamped "Dn" where n indicates modifications. 11 Documentation updated. Documentation only. ================================================================================ Note 17.1 LSI-11/23 ECO History 1 of 1 BRS01::BRUSCHE 5 lines 9-MAY-1985 02:24 -------------------------------------------------------------------------------- Please note that in all tree jumper layout drawings there is a redundant "W6". The top ones are those that should be disregarded. Johan. ================================================================================ Note 18.0 KXT11-CA DMA Programming No replies JAWS::KAISER 1117 lines 25-MAR-1985 09:22 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 018 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: Programming the KXT11-CA DMA controller | Date: 28-DEC-84 | +----------------------------------------------------+-----------------+ | Originator: Scott Tincher | Page 1 of 22 | +----------------------------------------------------+-----------------+ The KXT11-CA intelligent I/O processor contains several user programmable devices. One of these devices is a DMA transfer controller (DTC). This article will describe the features of the DTC and provide some programming examples. This article is intended for use by individuals interested in programming the DTC using MACRO-11. DIGITAL supplies a DTC device driver for those programmers using MicroPower/Pascal. A working knowledge of MACRO-11 and of the KXT11-CA is assumed. FEATURES/CAPABILITIES The DTC is addressable by the local T-11 microprocessor as an I/O device. It is capable of performing DMA transfers between any of the following addresses: 1) A 16-bit local address to a 16-bit local address 2) A 16-bit local address to a 22-bit global address 3) A 22-bit global address to a 16-bit local address 4) A 22-bit global address to a 22-bit global address 5) To/From channel A of the multiprotocol SLU 6) To/From the PIO chip Word, high byte, and low byte transfers are supported locally. Only word transfers are supported across the Q-bus. The operations of the DTC are controlled by several internal registers. It was designed with the capabilty of loading these registers directly from memory thereby minimizing the amount of processor intervention necessary to perform a DMA transaction. The area of memory where the parameters for the DTC are stored is referred to as the chain table. The local microprocessor need only load the address of the chain table into the DTC and give a "start" command to initiate a DMA transfer. DMA transactions may be initiated locally by the T11 or by the arbiter CPU. If the transfer is initiated by the arbiter the command words and transfer parameters are placed in the command registers of the two-port RAM file. The local CPU will then initiate the DMA transaction using the parameters supplied by the arbiter. Page 2 The DTC consists of two identical channels. DMA transfers may be interleaved between these two channels or interleaved between the DTC and the T-11. It is also possible to select a "hog mode" that allows the DMA transfer to run to completion without interruption. The DTC supports three types of operations: Transfer, Search, and Transfer-and-Search. As the name implies, Transfer operations move data from a source to a destination. Search operations read data from a source and compare the data to the pattern register. A mask register allows the user to declare "don't care" bits. The Transfer-and-Search operation combines the features of the Transfer and Search functions. In this type of operation data is transferred between a source and destination until the data transferred meets the match condition specified in the Channel Mode register. The DTC is capable of performing multiple DMA transactions without processor intervention. This can be accomplished in two ways: base-to-current reloading or chaining. Base-to-current reloading allows the DTC to reload a portion of its registers before initiating a DMA transfer. The reload operation occurs between internal registers so there are no memory access related delays. This type of operation is only practical in applications where data is continuously transferred between the same addresses. Chaining allows all of the applicable registers of the DTC to be reloaded from a new chain table. Therefore this is a slower but more flexible alternative. Upon completion of a DMA transfer the DTC may perform any combination of the following options: Interrupt the local processor, perform base-to-current reloading, or perform a chain reload. It may also choose to take no action. DTC REGISTERS Among the internal registers of the DTC are two chip-level registers, the Master Mode register and the Command register. These registers control both channels of the DTC. In addition, each channel of the DTC is controlled by several channel-level registers. For the sake of completeness a brief description of these registers will be included here. For a detailed description refer to the KXT11-CA Single Board Computer User's Guide (EK-KXTCA-UG-001). CHIP-LEVEL REGISTERS Master Mode Register The Master Mode register controls the chip-level interfaces. It is used to: - Enable/disable the DTC - Select DTC/CPU interleaving - Enable/disable asynch operation - Enable/disable counter/timer interrupt request - Enable/disable interrupt save vector Page 3 Command Register The command register is used to issue commands to the DTC channels such as: Reset, Start Chain, etc. CHANNEL-LEVEL REGISTERS (Each of the following registers is present in each channel of the DTC) Current Address Registers A and B (CARA, CARB) CARA and CARB consist of two words, the segment/tag and the offset. The segment/tag is used to indicate: - Address bits <21:16> of the source (or destination) - If the source (or destination) resides on the Q-bus - Whether the source (or destination) address should be incremented, decremented, or held constant - Whether wait states should be included The offset is used to indicate: - Address bits <15:00> Base Address Registers A and B (BARA, BARB) BARA and BARB are identical to CARA and CARB. They are used to reload CARA and CARB if base-to-current reloading is selected after a DMA operation has terminated. Current Operation Count Register (COPC) This 16-bit register is used to specify the number of words (or bytes) to be transferred during a DMA operation. The maximum word count is obtained by programming this register with a zero. Base Operation Count Register (BOPC) This register is identical to the COPC register. It is used to reload the COPC register when base-to-current reloading is selected. Pattern and Mask Registers The Pattern and Mask registers are used during Search and Transfer-and-Search operations. The contents of the Pattern register are compared to the read data to generate a "match" condition. The Mask register is used to generate "don't care" bits. Setting a bit to '1' in the Mask register specifies that the bit always matches. Page 4 Status Register The status register is a 16-bit read-only register which returns the status of the following fields: Interrupts status, DTC status, Hardware interface status, and Completion status. Interrupt Vector and Interrupt Save Registers The Interrupt Vector register contains the vector that is output during an interrupt acknowledge cycle. When an interrupt occurs the contents of the Interrupt Vector register and a part of the Status register are stored in the Interrupt Save register. This allows a new vector to be loaded during chaining so that a new DMA operation can be performed before an interrupt acknowledge cycle occurs. Channel Mode Register The Channel Mode register consists of two words, channel mode high and channel mode low. Channel mode low is used to indicate: - The operation type (transfer, search, transfer-and-search,bytes,words) - Whether CARA (or CARB) defines the source (or destination) - Transfer type (single, hog mode, interleaved) - Completion options (interrupt CPU, base-to-current reload, chain reload) Channel mode high is used to: - indicate match conditions - mask the hardware requests for DMA operations - cause the channel to request the bus for a DMA operation Chain Address Register The chain address register consists of two words, the segment/tag and the offset. This register is used to point to the reload word, the first word in a chain table. The segment/tag is used to indicate: - Whether the reload word resides in Q-bus memory - Whether the reload word resides in the Q-bus I/O page - Address bits <21:16> The offset is used to indicate: - Address bits <15:00> Page 5 PROGRAMMING THE DTC Programming the DTC consists of three phases: Chip Initialization, Data Transfer (or Search), and Termination. This section will provide a general description of these phases. CHIP INITIALIZATION The Reset instruction is used to place the DTC in a known state. A reset will clear the CIE, IP, SIP and WFB bits and set the CA and NAC bits in the Channel Status registers. The Master Mode register will also be cleared. Before a DMA operation is initiated the local CPU loads the Master Mode register and the Chain Address register of the appropriate channel of the DTC. The DTC fetchs any other parameters that are necessary from a table located in system memory referred to as the chain table. This minimizes the amount of CPU intervention necessary to perform a DMA operation. The relationship of the Chain Address register to the chain table is shown in Figure 1. System +---------------+ | Memory | | | | | | | |-------------------| | DTC | +---------->| Reload Word | | Channel 0/1 | | |-------------------| | | | | | | | | | DTC | | | | | Register | | +---------+ | | | Data | | | Chain | | | | | | | Address |--|----------+ |- - - - - - - - - -| | | Reg. | | +----| New Chain Address | | +---------+ | | |-------------------| +---------------+ | | | | | | | | | | | | | |-------------------| +--->| Reload Word | |-------------------| | | | DTC | | Register | | Data | | | |-------------------| | | - Figure 1 - Page 6 The first word in the chain table is the reload word. The reload word is used to specify which registers are to be loaded for the pending DMA operation. Bits <9:0> of the reload word correspond to the registers of the DTC as shown in figure 2. Bits <15:10> are not used. Reload Word +---------------------------------------------------------------+ | x | x | x | x | x | x | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +---------------------------------------------------------------+ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | Current ARA -----------------+ | | | | | | | | | Current ARB ---------------------+ | | | | | | | | Current Op-Count --------------------+ | | | | | | | Base ARA --------------------------------+ | | | | | | Base ARB ------------------------------------+ | | | | | Base Op-Count -----------------------------------+ | | | | Pattern and Mask ------------------------------------+ | | | Interrupt Vector ----------------------------------------+ | | Channel Mode ------------------------------------------------+ | Chain Address ---------------------------------------------------+ - Figure 2 - Therefore if a bit in the reload word is set then the corresponding register is to be reloaded from the chain table. Since all of the registers are not applicable to each DMA operation the chain table may be of variable length. ( i.e. The pattern and mask registers would not be used in DMA operations that do not search the data.) It is NOT correct to select a register in the reload word and subsequently load that register with a dummy argument such as zero. The following are examples of the relationship between the reload word and the chain table. | 9 8 7 6 5 4 3 2 1 0 | |---------------------------------------------------------------| | x | x | x | x | x | x | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | |---------------------------------------------------------------| | Current ARA Segment/Tag | |---------------------------------------------------------------| | Current ARA Offset | |---------------------------------------------------------------| | Current ARB Segment/Tag | |---------------------------------------------------------------| | Current ARB Offset | |---------------------------------------------------------------| | Current Op-Count | |---------------------------------------------------------------| | Channel Mode High | |---------------------------------------------------------------| | Channel Mode Low | |---------------------------------------------------------------| | | Page 7 | 9 8 7 6 5 4 3 2 1 0 | |---------------------------------------------------------------| | x | x | x | x | x | x | 1 | 0 | 1 | 0 | 0 | 0 | 1 | 0 | 1 | 1 | |---------------------------------------------------------------| | Current ARA Segment/Tag | |---------------------------------------------------------------| | Current ARA Offset | |---------------------------------------------------------------| | Current Op-Count | |---------------------------------------------------------------| | Pattern Register | |---------------------------------------------------------------| | Mask Register | |---------------------------------------------------------------| | Channel Mode High | |---------------------------------------------------------------| | Channel Mode Low | |---------------------------------------------------------------| | Chain Address Segment/Tag | |---------------------------------------------------------------| | Chain Address Offset | |---------------------------------------------------------------| | | The DTC has been properly initialized once the chain table(s) have been created and the Master Mode register and Chain Address Register for the selected channel have been loaded. DATA TRANSFER The DTC may perform a DMA operation once it has been properly initialized. A DMA operation may be initiated in one of four ways: by software request, by hardware request, by loading a set software request bit in the Channel Mode register during chaining, or as the result of a command from the arbiter. Software Request: The local CPU may initiate a DMA operation by writing a 'software request' command followed by a 'start chain' command to the Command register. The 'software request' command sets the software request bit in the channel's Mode register. If either the SIP (second interrupt pending) bit or the NAC (no auto-reload or chain) bit is set in the channel's status register the DMA operation will not begin. The SIP bit will be cleared when the channel receives an interrupt acknowledge. The NAC bit will be cleared when the channel receives a 'start chain' command. The 'start chain' command initiates the DMA operation after the registers of the selected channel are loaded from the chain table. The 'start chain' command is ignored if the SIP bit or the CA (Chain Abort) bit are set in the channel's status register. The SIP bit was described above. The CA bit is cleared when the channel's chain address register is reloaded. Hardware Request: DMA operations may be started by applying a 'low' on the channel's DREQ input. No details about this type of request will be provided since they fall beyond the scope of this note. Page 8 Starting After Chaining: If the software request bit of the channel's Mode register is loaded during chaining the channel will perform the DMA operation at the end of chaining. Arbiter Request: The arbiter may interrupt the local CPU to request a DMA operation. This is accomplished by passing parameters to load the chain address register of channel 0 via the two-port RAM. The arbiter loads register 2 of the TPR with the offset of the chain address register and register 3 of the TPR with the segment/tag of the chain address register. The DMA operation is then initiated by setting the DMA Load bit (bit 1) in the TPR command register (register 0). Error conditions will be returned in TPR register 1. Information in the channel's Mode register determines what type of DMA operation will be performed. The Channel Mode register consists of two words, Channel Mode High and Channel Mode Low. Bits <3:0> of the Channel Mode Low register select the type of DMA operation. These bits determine whether the data should be transferred, searched, or transferred-and-searched. Bit 4 is the flip bit. It is used to determine which set of current address registers (CARA, CARB) points to the source. Bits <6:5> determine the transfer type. The types of DTC transfers are: single transfer, demand dedicated with bus hold, demand dedicated with bus release, and channel-to-channel demand interleave. Single transfer is used with devices which transfer data at irregular intervals. A single DMA transaction will occur each time a 'software request' command is issued or the DREQ input is asserted. Demand dedicated with bus hold is a software hog mode. This mode allows the DMA transaction to run to completion as long as there is a valid op count and the DREQ input is asserted. If the DREQ input is not asserted no DMA operations will occur but the channel will retain bus control. Demand dedicated with bus release is similar to demand dedicated with bus hold in that a DMA transaction is allowed to run to completion if DREQ is asserted. If DREQ is not asserted the DTC must release the bus thus allowing other devices to obtain the bus. The operation performed by a channel-to-channel demand interleave request depends on the state of bit 2 in the Master Mode register. If MM bit 2 is clear then control may be passed between each channel of the DTC without the need to release the bus. If MM bit 2 is set then the DTC must share the bus with the local processor. The DTC will release the bus and then re-request it after every DMA iteration. Bits <1:0> of the Channel Mode High register are used to determine the type of match control in Search and Transfer-and-Search operations. The DTC is capable of generating a termination condition based on 'No Match', 'Word Match', and 'Byte Match'. Bit <4> of the Channel Mode High register causes the channel to request the bus and perform transfers when it is set by a 'Software Request Command' or a chain reload. Page 9 TERMINATION OPTIONS Bits <15:7> of the Channel Mode Low register control the termination options. A DTC operation may be terminated in a number of ways. If the Current Operation Count Register goes to zero then a Terminal Count (TC) termination is generated. External logic may assert the End Of Process (EOP) input of the DTC to generate an EOP termination at any time. In addition, during a Search or Transfer-and-Search operation a match condition may occur which generates a MC termination. Bits <15:7> allow the DTC to perform a chain reload, a base-to-current reload, or to interrupt the local processor if a TC, EOP, or MC termination condition is encountered. If bits <15:7> are cleared then no special action is initiated when a TC, EOP, or MC condition is encountered. EXAMPLES The following example programs were developed on a PDP-11/23+ system with 256KB of memory using the RT-11 (version 5.1) operating system with the KXT11-C Peripheral Processor Software Toolkit. These examples assume the programmer is familiar with MACRO-11 and the KXT11-C Peripheral Processor Toolkit. Page 10 .TITLE EXAM1.MAC ; This program transfers data from local KXT11-C addresses to other ; local KXT11-C addresses. This program should be compiled and linked ; on the development system and then downloaded into the KXT11-C using ; the KXT11-C Software Toolkit. Once the program has been compiled ; and linked use the following KUI commands to execute it and verify ; its successfullness. ; ; .KUI ; KUI>SET n ! Where n is the appropriate KXT11-C ; KUI>LOAD EXAM1 ; KUI>ODT ! Use KUI ODT to verify that the destination ; . addresses are cleared ; . ; ODT>^C ; KUI>EXECUTE ! Execute EXAM1 ; KUI>ODT ! Use KUI ODT to verify that the transfer was ; . successful ; . ; ODT>^C ; KUI>EXIT ; ; SET UP REGISTER ASSIGNMENTS MMREG = 174470 ; MASTER MODE REGISTER CMDREG = 174454 ; COMMAND REGISTER CASTF0 = 174446 ; CHANNEL 0 CHAIN ADDRESS SEGMENT/TAG FIELD CAOF0 = 174442 ; CHANNEL 0 CHAIN ADDRESS OFFSET FIELD START: MOVB #130,MMREG ; LOAD MASTER MODE REG TO DISABLE DTC CLRB CMDREG ; RESET THE DTC MOV #0,CASTF0 ; LOAD THE CHAIN ADDRESS REGISTER SEG/TAG MOV #RELOAD,CAOF0 ; LOAD THE CHAIN ADDRESS REGISTER OFFSET MOVB #131,MMREG ; LOAD MASTER MODE REG TO ENABLE DTC MOVB #102,CMDREG ; SET SOFTWARE REQUEST CHANNEL 0 MOVB #240,CMDREG ; START CHAIN CHANNEL 0 BR . ; STAY HERE WHILE THE USER VERIFIES ; THAT THE PROGRAM WAS SUCCESSFUL ; CHAIN LOAD REGION RELOAD: .WORD 001602 ; RELOAD WORD .WORD 000000 ; CURRENT ADDRESS REGISTER A SEG/TAG .WORD SOURCE ; CURRENT ADDRESS REGISTER A OFFSET ; .WORD 101400 ; CURRENT ADDRESS REGISTER B SEG/TAG .WORD 00000 ; CURRENT ADDRESS REGISTER B OFFSET ; ; ; .WORD 000013. ; CURRENT OPERATION COUNT .WORD 000000 ; CHANNEL MODE REGISTER HIGH .WORD 000040 ; CHANNEL MODE REGISTER LOW ; SOURCE: .WORD 1,2,3,4,5,6,7,6,5,4,3,2,1 .END START Page 14 .TITLE EXAM3.MAC ; This program transfers data from global Q-bus addresses to local ; KXT11-C addresses. This program should be compiled and linked on ; the development system and then downloaded into the KXT11-C using ; the KXT11-C Software Toolkit. Once the program has been compiled ; and linked use the following commands to execute it and verify its ; successfullness. ; ; 600030(8). ; These values will be the source for this operation> ; ; @600000/000001 ! Deposit source values ; . ; . ; @600030/000001 ; @P ! Use the 'P' command to return to the system prompt ; ; .KUI ; KUI>SET n ! Where n is the appropriate KXT11-C ; KUI>LOAD EXAM3 ; KUI>EXECUTE ; KUI>ODT ! Use KUI ODT to examine the destination locations ; to verify the transfer was successful ; ODT> . ; . ; . ; ODT>^C ; KUI>EXIT ; ; SET UP REGISTER ASSIGNMENTS MMREG = 174470 ; MASTER MODE REGISTER CMDREG = 174454 ; COMMAND REGISTER CASTF0 = 174446 ; CHANNEL 0 CHAIN ADDRESS SEGMENT/TAG FIELD CAOF0 = 174442 ; CHANNEL 0 CHAIN ADDRESS OFFSET FIELD START: MOVB #130,MMREG ; LOAD MASTER MODE REG TO DISABLE DTC CLRB CMDREG ; RESET THE DTC MOV #0,CASTF0 ; LOAD THE CHAIN ADDRESS REGISTER SEG/TAG MOV #RELOAD,CAOF0 ; LOAD THE CHAIN ADDRESS REGISTER OFFSET MOVB #131,MMREG ; LOAD MASTER MODE REG TO ENABLE DTC MOVB #102,CMDREG ; SET SOFTWARE REQUEST CHANNEL 0 MOVB #240,CMDREG ; START CHAIN CHANNEL 0 BR . ; STAY HERE WHILE THE USER VERIFIES THAT ; THE PROGRAM WAS SUCCESSFUL Page 15 ; CHAIN LOAD REGION RELOAD: .WORD 001602 ; RELOAD WORD .WORD 101400 ; CURRENT ADDRESS REGISTER A SEG/TAG .WORD 000000 ; CURRENT ADDRESS REGISTER A OFFSET ; ; .WORD 101400 ; CURRENT ADDRESS REGISTER B SEG/TAG .WORD 010000 ; CURRENT ADDRESS REGISTER B OFFSET ; ; .WORD 000013. ; CURRENT OPERATION COUNT .WORD 000000 ; CHANNEL MODE REGISTER HIGH .WORD 000040 ; CHANNEL MODE REGISTER LOW ; .END START Page 18 .TITLE EXAM5.MAC ; This program demonstrates how chaining is implemented using the ; DTC. A local to local transfer will be initiated under program ; control. Then, using the chaining feature of the DTC, a local to ; global transfer will be performed followed by a global to global ; transfer and finally a global to local transfer. The following ; diagram illustrates these transfers. ; ; ; KXT11-C Memory Q-bus Memory ; ; -------------- ------------ ; +---| | | | ; | | | | | ; | | | | | ; | |------------| Transfer #2 |----------| ; +-->| | ---------------> | |---+ ; |------------| |----------| | ; | | | | | Transfer #3 ; |------------| Transfer #4 |----------| | ; | | <--------------- | |<--+ ; |------------| |----------| ; ; This program should be compiled and linked on the development system ; and then downloaded into the KXT11-C using the KXT11-C Software ; Toolkit. Once the program has been compiled and linked use the ; following commands to execute it and verify its successfullness. ; ; 600030(8) ; and 6100000(8) --> 610030(8) before executing the program> ; ; .KUI ; KUI>SET n ! Where n is the appropriate KXT11-C ; KUI>LOAD EXAM5 ; KUI>EXECUTE ; KUI>ODT ! Use KUI ODT to verify that the destination ; ODT> . contents are accurate ; ODT> . ; ODT>^C ; KUI>EXIT ; ; ; SET UP REGISTER ASSIGNMENTS MMREG = 174470 ; MASTER MODE REGISTER CMDREG = 174454 ; COMMAND REGISTER CASTF0 = 174446 ; CHANNEL 0 CHAIN ADDRESS SEGMENT/TAG FIELD CAOF0 = 174442 ; CHANNEL 0 CHAIN ADDRESS OFFSET FIELD START: MOVB #130,MMREG ; LOAD MASTER MODE REG TO DISABLE DTC CLRB CMDREG ; RESET THE DTC Page 19 MOV #0,CASTF0 ; LOAD THE CHAIN ADDRESS REGISTER SEG/TAG MOV #LOAD1,CAOF0 ; LOAD THE CHAIN ADDRESS REGISTER OFFSET MOVB #131,MMREG ; LOAD MASTER MODE REG TO ENABLE DTC MOVB #102,CMDREG ; SET SOFTWARE REQUEST CHANNEL 0 MOVB #240,CMDREG ; START CHAIN CHANNEL 0 BR . ; STAY HERE WHILE THE USER VERIFIES THAT ; THE PROGRAM WAS SUCCESSFUL ; CHAIN LOAD REGION LOAD1: .WORD 001603 ; RELOAD WORD .WORD 000000 ; CURRENT ADDRESS REGISTER A SEG/TAG .WORD AREA2 ; CURRENT ADDRESS REGISTER A OFFSET ; .WORD 101400 ; CURRENT ADDRESS REGISTER B SEG/TAG .WORD 000000 ; CURRENT ADDRESS REGISTER B OFFSET ; .WORD 000013. ; CURRENT OPERATION COUNT .WORD 000000 ; CHANNEL MODE REGISTER HIGH .WORD 100040 ; CHANNEL MODE REGISTER LOW ; Page 20 .WORD 000000 ; CHAIN ADDRESS REGISTER SEG/TAG .WORD LOAD3 ; CHAIN ADDRESS REGISTER OFFSET ; LOAD3 : .WORD 001603 ; RELOAD WORD .WORD 101400 ; CURRENT ADDRESS REGISTER A SEG/TAG .WORD 010000 ; CURRENT ADDRESS REGISTER A OFFSET ; ; <610000(8)> .WORD 000000 ; CURRENT ADDRESS REGISTER B SEG/TAG .WORD AREA3 ; CURRENT ADDRESS REGISTER B OFFSET ; .WORD 000013. ; CURRENT OPERATION COUNT .WORD 000000 ; CHANNEL MODE REGISTER HIGH .WORD 000040 ; CHANNEL MODE REGISTER LOW ; AREA1 : .WORD 1,2,3,4,5,6,7,6,5,4,3,2,1 AREA2 : .BLKW 13. AREA3 : .BLKW 13. .END START Page 21 .TITLE EXAM6.MAC ; This program demonstrates how to initiate a DTC operation from the ; arbiter CPU. This program will tranfer a block of data from Q-bus ; memory to KXT11-C memory. All of the information necessary for the ; transfer will reside in Q-bus memory (chain table, source data) ; This program should be compiled, linked, and run on the arbiter ; development system. After the program executes use the following ; KUI commands to verify the transfer ; ; .KUI ; KUI>SET n ! Where n is the appropriate KXT11-C ; KUI>ODT ; ODT>5000/xxxxxx ! Examine locations 5000 --> 5030 to verify that ; . the data was transfered correctly ; . ; ODT>5030/xxxxxx ; ODT>^C ; KUI>EXIT ; ; Two-port RAM register definitions TPR0=160100 TPR2=160104 TPR3=160106 .MCALL .EXIT START: MOV #100000,TPR3 ; Place Chain Address Reg Seg/Tag in TPR3 MOV #LOAD,TPR2 ; Place Chain Address Reg Offset in TPR2 ; * NOTE!! * ; ; The KXT11-C User's Guide contains an error which instructs the ; programmer to place the CA register Seg/Tag in TPR2 and the CA ; register Offset in TPR3. This information is reversed and is ; correct as stated above. BIS #2,TPR0 ; Issue DMA Load command to the command register .EXIT LOAD : .WORD 001602 ; RELOAD WORD .WORD SOURCE ; CARA OFFSET .WORD 000000 ;CARB SEG/TAG Page 22 SOURCE: .WORD 1,2,3,4,5,6,7,6,5,4,3,2,1 .END START RELATED DOCUMENTS For further information concerning the KXT11-CA and the DTC please consult the following sources: KXT11-CA Single-Board Computer User's Guide EK-KXTCA-UG-001 AmZ8016 DMA Transfer Controller User's Guide 01924C For further information concerning the KXT11-CA Peripheral Processor Software Toolkit please consult: KXT11-C Peripheral Processor Software User's Guide AA-Y615A-TK KXT11-CA Software Toolkit/RT Reference Manual AA-AU63A-TC KXT11-CA Software Toolkit/RSX Reference Manual AA-AU64A-TC ================================================================================ Note 19.0 Disabling RAM on the MXV11-BF No replies JAWS::KAISER 132 lines 25-MAR-1985 09:24 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 019 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: Disabling RAM on the MXV11-BF | Date: 10-JAN-85 | +----------------------------------------------------+-----------------+ | Originator: Mike Collins | Page 1 of 3 | +----------------------------------------------------+-----------------+ This uNOTE describes how to disable the on-board memory of the MXV11-BF multifunction module. There is also a comparison of features between the MXV11-BF (with RAM disabled) and the combination of the MRV11-D and DLV11-J modules. DISABLING RAM ON THE MXV11-BF MODULE WARNING! The procedure outlined below for disabling the RAM requires physical changes to the circuit board. Implementing this change will void the warranty of the MXV11-BF as well as voiding any field service contract for the board. The procedure requires cutting one etch and adding one wire. PROCEDURE (see figure below) 1. The etch cut can be achieved two ways. Cut and bend up pin 13 of chip E17. OR On side 2 of module (the non-component side), cut etch which connects E17 pin 13 to E26 pin 2. 2. Add wire between E17 pin 13 and E17 pin 14 (+5 Volts). 3. The on-board RAM is now disabled. Page 2 MXV11-BF (M7195) | | | | | | | Pin 1 | | | | | | Pin 14 | | | | | | | | | | | | | | +-+ V V +-+ | | Pin 1 ---> +-+ | | +-+ +-+ | | +-+ +-+ | | | | | | | | | | | | | | | | | | E26 -----> | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +-+ | | +-+ +-+ | | | | | | | | +-+ ^ +-+ | | | | | | | +-+ +-+ | +-+ +-+ | | | +---+ | | +-+ | | | E17 | | | | | +--------------------+ +--------------------+ COMPARISON OF THE MXV11-BF VERSUS THE COMBINATION OF MRV11-D AND DLV11-J The following table lists several features common to both the MXV11-BF with the RAM disabled and the MRV11-D / DLV11-J combination. FEATURE MXV11-BF w/o RAM MRV11-D and DLV11-J RAM None None Boot ROMs MXV11-B2 MXV11-B2 SLU's 2 DLARTs 4 UARTs 4 baud rates 9 baud rates No format options Many format options (Start, stop bits, parity, # of bits, etc.) Miscellaneous 4 Red LED's 14 unused ROM/RAM sockets features 1 Green LED Cabinet kit Currently N/A Available +5 V 3.4A 2.6A Heat diss. 16.65W 16W Page 3 FEATURE MXV11-BF w/o RAM MRV11-D and DLV11-J Slots 1 dual 2 duals AC loads 2.3 4.0 DC loads 0.5 1.5 +12 V 0.1A 0.25A When comparing the features on page 2, the MRV11-D/DLV11-J combination works out better than the MXV11-BF. All of the features on page 3 show the advantages of the MXV11-BF. The MXV11-BF is the best choice in situations where backplane space and loading is a primary concern. In terms of backplane space, if the number of slots available is limited, the MXV11-BF is preferable since it takes up one dual slot whereas the MRV11-D/DLV11-J combination requires two dual slots. In a large system where AC loading may be a concern, the MXV11-BF also has an advantage over the MRV11-D/DLV11-J combination. The number of AC loads the MXV11-BF presents to the bus is fewer than the two board combination. The most attractive use for the MXV11-BF is in a minimal yet powerful two-board system i.e. KDJ11-A and the MXV11-BF. The advantages of such a system are the size or form factor (only two dual height modules) 128Kb of RAM, 2 serial lines, bootstrap capability and the high performance 11/73 CPU. ================================================================================ Note 20.0 MXV11-A, -B Differences No replies JAWS::KAISER 84 lines 25-MAR-1985 09:24 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 020 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: Differences between the MXV11-A and MXV11-B | Date: 10-JAN-85 | +----------------------------------------------------+-----------------+ | Originator: Dave Smith | Page 1 of 2 | +----------------------------------------------------+-----------------+ This MicroNote illustrates the features to consider when upgrading from MXV11-AA/-AC to MXV11-BF multifunction boards or when choosing one in a new configuration. +-----------------------------------+----------------------------------+ | | | | MXV11-A | MXV11-BF | | | | +-----------------------------------+----------------------------------+ | | | | o Dual height form factor | o Dual height form factor | | | | | o 18-bit compatible only | o 18 or 22-bit compatible | | | | | o 2 SLU's (DLV11-J type) | o 2 SLU's (DLARTs) | | | | | o RAM: | o RAM: | | 8 KB non-parity (MXV11-AA) | 128 KB non-parity | | 32 KB non-parity (MXV11-AC) | | | | | | o ROM: 2 sockets (24-pin) | o ROM: 2 sockets (28-pin) | | (for MXV11-A2 boot ROMS | (for MXV11-B2 boot ROMS | | - cannot use MXV11-B2 ROMS) | - cannot use MXV11-A2 ROMS) | | | | +-----------------------------------+----------------------------------+ Notes: The MXV11-B2 Boot ROMs are required for an LSI-11/73 based system to be maintained under a DEC Field Service contract because these ROMs contain cache diagnostics. For a comprehensive list of Bootstraps and device support, refer to MicroNote 15, entitled "Q-bus Hardware Bootstraps" Since the ROM sockets on these boards may be used for user-written application code as well as boot code, it is important to note what is different on the two boards. Besides the sockets being of different size, the ROM on the two boards has another difference. The ROM on the MXV11-BF is window mapped and may be used under application control to address up to 8 KB. The MXV11-A ROM is direct mapped and can only address 256 bytes. Thus, an upgrade would require new ROMs and possible Page 2 application recoding. For more detailed information concerning MXV11-BF issues, refer to MicroNote 19. For more detailed information concerning MXV11-A issues, refer to the archived MicroNotes listed in appendix A. Summary: When upgrading from the MXV11-A to the MXV11-BF or choosing the MXV11-BF over the MXV11-A, three important features are obtained: 1) 22-bit compatibility - allows use in large memory systems (The MXV11-BF memory can only be configured to start in the lower 512 KB. It does, however, decode all 22 lines of address which makes it usable in systems with up to 4 MB.) 2) More memory (although its non-parity feature creates some software support issues if used with RSX or RSTS) 3) Support for boot ROMs that will boot MSCP devices such as the RX50 and RD51 and will provide cache diagnostics for the LSI-11/73. ================================================================================ Note 21.0 MicroVAX I Floating Point No replies JAWS::KAISER 106 lines 25-MAR-1985 09:24 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 021 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: Floating Point Considerations on MicroVAX I | Date: 10-Jan-85 | +----------------------------------------------------+-----------------+ | Originator: Christopher DeMers | Page 1 of 2 | +----------------------------------------------------+-----------------+ The MicroVAX architecture implements a subset of VAX data types. Four that are part of the VAX architecture but not part of the MicroVAX architecture are the D_floating, F_floating, G_floating and H_floating data types. Floating point instructions that use these data types are likewise not part of the architecture. The MicroVAX I system implements a proper superset of the MicroVAX architecture; that is, MicroVAX I uses the MicroVAX architecture, but implements a few items that are not defined as part of the MicroVAX architecture. Even though the architecture specifies emulation support for floating point, the following data types and instructions are supported in the MicroVAX I microcode: - F_float - D_float - G_float The F_float data type and instructions are standard on the MicroVAX I. In addition, the user may specify EITHER D_float or G_float as the double precision instruction set. The decision to use D_float or G_float depends on the application. Both D_float and G_float are double precision floating point data types/instructions. D_float is compatible with the PDP-11 format and is the double precision floating point default for many of Digital's compilers including FORTRAN, PL/I, BASIC and Pascal. Therefore, if the application has been compiled, say, on a VAX-11/780, with the default (D_float) and is not to be re-compiled before being run on the MicroVAX I, then choose the D_float option. The compilers mentioned above have a switch that allows the generation of G_float instructions. If you wish to choose the G_float option for your MicroVAX I, the program needs to be re-compiled with the G_float switch set. If Macro programs use a specific data type such as G_float, then the MicroVAX I will need to have the G_float option unless the program is modified so that the floating point instructions match the option chosen for the MicroVAX I. Page 2 Note that even though a program uses one type of double precision floating point and the MicroVAX I has the other as an option, the program will run. A feature of the MicroVAX architecture is that all instructions are executed. The floating point instructions not chosen as a microcode option are emulated in software. An instruction/data type mismatch could result in severe performance degradation. Another reason for choosing one double precision format over another is the size and accuracy of the data. Both formats are 64 bits long. The D_float range is 2.9E-37 to 1.7E38. This type gives approximately sixteen decimal digits precision. G_float "steals" three bits from the fraction to give the exponent a larger range. The G_float range is .56E-308 to .9E308 and gives approximately fifteen decimal digits precision. The range of the number is increased significantly while only reducing the precision by one decimal digit. H_float, the only other floating data type in the VAX architecture, is 128 bits long with a range of close to 10E5000 and a precision of thirty-three decimal digits. H_float is not implemented as part of the MicroVAX architecture. It is, however, emulated in software. Data Type Representations F_Floating 15 7 6 0 +------------+----------+ |S| Exponent | Fraction | +------------+----------+ | Fraction | +-----------------------+ 31 16 D_Floating G_Floating 15 7 6 0 15 4 3 0 +------------+----------+ +------------+----------+ |S| Exponent | Fraction | |S| Exponent | Fraction | +------------+----------+ +------------+----------+ | Fraction | | Fraction | +-----------------------+ +-----------------------+ | Fraction | | Fraction | +-----------------------+ +-----------------------+ | Fraction | | Fraction | +-----------------------+ +-----------------------+ 63 48 63 48 ================================================================================ Note 22.0 MicroVAX I and II differences No replies FURILO::JACKSON 626 lines 19-AUG-1985 11:29 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 022 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: Differences between the MicroVAX I and the | Date: 28-APR-85 | | MicroVAX II CPUs | | +----------------------------------------------------+-----------------+ | Originator: Mike Collins | Page 1 of 11 | +----------------------------------------------------+-----------------+ This MicroNote identifies the differences between the MicroVAX I processor and the MicroVAX II processor. The term 'MicroVAX 630' is sometimes used in this and other documentation when referring to the CPU module of the MicroVAX II system. Table 1 below contains a summary of these differences and following the table are detailed discussions of each. Table 1 - MicroVAX II versus the MicroVAX I +-----------------------------+--------------------+-------------------+ | FEATURE | MicroVAX II | MicroVAX I | +-----------------------------+--------------------+-------------------+ | CPU Technology | MicroVAX 78032 | Custom VLSI | +-----------------------------+--------------------+-------------------+ | Memory System | Local Memory | Uses Q-bus Memory | | | System | | +-----------------------------+--------------------+-------------------+ | Floating Point | MicroVAX 78132 | Microcode | +-----------------------------+--------------------+-------------------+ | Q-bus I/O Map | YES | NO | +-----------------------------+--------------------+-------------------+ | Addressable Physical Memory | 16 MBytes | 4 MBytes | +-----------------------------+--------------------+-------------------+ | On-Board Memory | 256KB or 1MB | None | +-----------------------------+--------------------+-------------------+ | Performance | See Performance Section | +-----------------------------+--------------------+-------------------+ | Console Serial Line | YES | YES | +-----------------------------+--------------------+-------------------+ | Boot & Diagnostic ROMs | YES | YES | +-----------------------------+--------------------+-------------------+ | Form Factor | 1 Quad | 2 Quads | +-----------------------------+--------------------+-------------------+ | Configuration Set via | Cabinet Kit | Cabinet Kit & | | | | On-board Switches | +-----------------------------+--------------------+-------------------+ | RQDX Controller Type | RQDX2 | RQDX1 or RQDX2 | +-----------------------------+--------------------+-------------------+ Page 2 Table 1 - MicroVAX II versus the MicroVAX I (cont'd) +-----------------------------+--------------------+-------------------+ | TOY Clock w/ Battery Backup | YES | NO | +-----------------------------+--------------------+-------------------+ | Multicomputing Hooks | YES | NO | +-----------------------------+--------------------+-------------------+ | Instruction Set Differences | See MicroNote #24 | +-----------------------------+--------------------+-------------------+ | Power Requirements | +5V - 6.2 Amps | +5V - 14 Amps | | | +12V - 0.14 Amps | +12V - 0.5 Amps | +-----------------------------+--------------------+-------------------+ | AC Loads | 2.7 | 2 | +-----------------------------+--------------------+-------------------+ | DC Loads | 1 | 1 | +-----------------------------+--------------------+-------------------+ | Termination | 240 Ohms | 240 Ohms | +----------------------------------------------------------------------+ The MicroVAX II is both faster and smaller than the MicroVAX I. Two major features of the MicroVAX II are responsible for these enhancements: the MicroVAX 78032 microprocessor and the memory system. CPU TECHNOLOGY -------------- The technologies used to design the two processors are different. This is why the MicroVAX II CPU is half the size and three times the speed of the MicroVAX I. The MicroVAX I CPU was designed using a custom VLSI chip, several ROMs and off-the-shelf parts to implement the ALU, memory management unit and the microcode. In contrast, these same features are implemented in the MicroVAX 78032 microprocessor. The MicroVAX 78032 is the first VAX on a chip. Two custom gate arrays were also designed to reduce the size of the MicroVAX II CPU to one quad module: the Q-bus interface gate array and the MicroVAX 78032 interface gate array. MEMORY SYSTEM ------------- The significant difference in performance is due in part to the different memory systems used by the two processors. The MicroVAX II memory system uses a high speed interconnect between the MicroVAX 78032 microprocessor and RAM. The MicroVAX I uses standard Q-bus memories which are not as fast but are also less expensive and usable by both the MicroVAX I and other 16-bit processors (such as the MicroPDP-11). The MicroVAX I also uses a cache memory scheme. The MicroVAX II CPU communicates to memory over a local memory interconnect. This was done to increase the performance of the system in two ways. First, the local memory system provides a fast connection between the processor and memory (400 nsec read and write cycles). Second, since memory fetches occur over the local memory system, the Page 3 Q-bus is now a dedicated I/O bus. The diagrams below contrast previous Q-bus processors and the MicroVAX II. The local memory system allows for 2 expansion memory boards. (See next section on Addressable Physical Memory) Configuration Used by Previous Q-bus Processors: This approach is used by most Q-bus processors such as the 11/23, LSI-11/73 and the MicroVAX I. In this design, the Q-bus bandwidth is shared by the processor and I/O devices when accessing memory. +---------+ +---------+ +---------+ | | | | | | |Processor| | Memory | | I/O | | | | | | Device | | | | | | | | | | | | | +---------+ +---------+ +---------+ | | | | | | --------------------------------------------------------- Q-bus --------------------------------------------------------- Figure 1 - Memory Design Used by Previous Q-bus Processors MicroVAX II Design: The MicroVAX II uses a local memory system for all memory references, allowing the Q-bus to be a dedicated I/O bus. The local memory system is implemented using the C-D interconnect of the backplane and an over-the-top cable. The memory system has a bandwidth of 10 MBytes/sec which will support the MicroVAX 78032 microprocessor running at full speed (approx. 6 MB/sec) with simultaneous Q-bus DMA transfers (3.3 MB/sec). 10 MBytes/sec +---------------------------+ <-- Over-the-Top Cable | +---------------+ | | | | <---|---- C-D Interconnect in Backplane +---------+ +---------+ +---------+ | | | | | | |Processor| |Expansion| | I/O | | | | Memory | | Device | | 6 MB/sec| |(max. of | | | | | | 2) | | | +---------+ +---------+ +---------+ | | | | --------------------------------------------------------- Q-bus (3.3 MBytes/sec) --------------------------------------------------------- Q-bus is a dedicated I/O bus Figure 2 - MicroVAX II Memory Design Page 4 FLOATING POINT -------------- The MicroVAX architecture specifies that the floating point instruction set need not be implemented in the hardware of a MicroVAX processor. For those processors that fall into this category, there is an emulator in the software which guarantees that the instructions are still executable. However the MicroVAX architecture does not restrict a MicroVAX design from having floating point instructions implemented in hardware. This is what was done on the MicroVAX I. The MicroVAX I does have the F_floating and D_floating or the F_floating and G_floating instructions in microcode. (see MicroNote 21 "Floating Point Considerations on MicroVAX I") The MicroVAX II uses the MicroVAX 78132 floating point unit to implement floating point instructions. It is a high performance coprocessor for the MicroVAX 78032 and eliminates the need to emulate floating-point instructions in software. The MicroVAX 78132 handles the F_floating (single precision), D_floating (double-precision) and the G_floating (extended range double-precision) floating point data types and instructions. The FPU also accelerates the execution of integer multiply and divide operations. The H_floating instructions are emulated in both the MicroVAX I and the MicroVAX II. Q-bus I/O MAP (SCATTER/GATHER MAP) ---------------------------------- The concept of a scatter/gather map has been used on the large UNIBUS VAXes since the VAX 11/780. The same concept is used on the MicroVAX II. Simply stated, the scatter/gather mechanism maps addresses from one bus to another bus. This mapping is necessary because the address length is not the same for the two buses. The term 'scatter/gather' is a description of what operations are performed through the scatter/gather map. A VAX with mapping enabled is a virtual machine and manages data in 512-byte pages which may be discontiguous in physical memory. When a DMA write operation occurs, pages of data may be 'scattered' into physical memory. During a DMA read operation from memory to an I/O device, such as a disk, these pages of data must be 'gathered' from throughout memory and transferred to the device. The MicroVAX I does not require a Q-bus I/O map. Since all I/O devices and memory share the same bus, the Q-bus, there is no mismatch in address lengths and no I/O map is necessary. Reading and writing data to and from memory in 512 byte pages becomes the responsibility of the I/O device or the system software. In the case of the MicroVAX II CPU, the scatter/gather map provides the mapping mechanism to allow DMA devices on the Q-bus, with a 4 MByte physical address range, to gain access to all of main memory on the Page 5 local memory system, a 16 MByte physical address range. Figure 3 below illustrates the mapping process. The high order 13 bits of the Q-bus address select one of 8192 mapping registers. Each register translates an address for a range covering one page of 512 bytes; thus the mapping registers cover the entire Q-bus address space of 4MB. The lower 15 bits of the mapping register will have been previously loaded with the correct information, which when appended to the lower 9 bits of the Q-bus address selects the appropriate byte in main memory. The high order 15 bits of the physical address select which page in main memory has the correct address and the low order 9 bits select the byte within a page. 9 8 0 +----------------------+ Q-bus I/O Map Q-bus Address | 13 bits | | 8K Mapping Registers +----------------------+ +---------------+ | | | | | +--------------------------> |---------------| | | +----- | | | |---------------| | | | | | Selected Mapping Register | | | | | | | | 31 15 14 0 | | | +-----------------------------+ | | +---------------+ |V| | 15 bits | <-------------+ +-----------------------------+ | | | | | | Local Memory | | | +---------------+ Physical Addr. +-------------------------+ | | in local | 24 bits | | | memory +-------------------------+ | | | | | | |---------------| +----------------------> | | |---------------| | | | | | | | | +---------------+ Figure 3 - Q-bus to Private Memory Mapping Process Page 6 ADDRESSABLE PHYSICAL MEMORY --------------------------- The total amount of addressable physical memory for each CPU is different because of the memory system designs. The MicroVAX I uses standard Q-bus memories for main memory and therefore has a lower physical addressing limit than the MicroVAX II. This limit is constrained by the number of address lines on the Q-bus. There are 22 address lines on the Q-bus, limiting maximum memory to 4 MB. The MicroVAX II uses a 24 bit address when accessing the local memory system. Therefore the maximum amount of addressable memory is 16 MBytes. When the system is first available, 9 Mbytes will be the maximum because the 16 MByte total depends on the availability of 1 Mbit RAM parts. The 9 MByte total includes a MicroVAX II CPU (KA630-AA) which includes 1 MByte on-board plus two 4 MByte expansion modules. The memory module capacities are listed in the table 3 below. Table 3 - Expansion Memory Options +----------+---------------+---------------+ | MEMORY | MEMORY SIZE | FORM FACTOR | +----------+---------------+---------------+ | MS630-AA | 1 Mbyte | Dual | +----------+---------------+---------------+ | MS630-BA | 2 Mbytes | Quad | +----------+---------------+---------------+ | MS630-BB | 4 Mbytes | Quad | +----------+---------------+---------------+ PERFORMANCE ----------- The relative performance between the processors is of course application dependent. However, as a general rule of thumb, the MicroVAX II CPU will be approximately 3 times faster than the MicroVAX I. The results of standard, compute bound floating point benchmarks indicate that the MicroVAX II (with the MicroVAX 78132 FPU) will run 4 to 6.6 times faster than the MicroVAX I. CONSOLE SERIAL LINE ------------------- The MicroVAX II and the MicroVAX I processors both have one dedicated serial line for the console terminal. There are two differences between the two serial line units. First, the number of selectable baud rates is different. The possible baud rates are listed in table 4. Page 7 Table 4 - Baud Rate Selections +--------------+------------+ | MicroVAX II | MicroVAX I | +--------------+------------+ | 300 | 300 | | 600 | 1200 | | 1200 | 9600 | | 2400 | 19200 | | 4800 | | | 9600 | | | 19200 | | | 38400 | | +--------------+------------+ Second, the console device connector on the patch panel for the MicroVAX I is an RS232 25-pin D-subminiature connector. The connector on the MicroVAX II patch panel is a 9-pin D-subminiature connector. Because the connectors are different, different cables will be used to connect to the console terminal. FORM FACTOR ----------- All of the features and functions of the MicroVAX II processor are contained on one quad module. The MicroVAX I processor is made up of two quad modules, a data path module ('DAP'), and a memory controller ('MCT'). The two modules of the MicroVAX I communicate over the C-D backplane interconnect and an over-the-top ribbon cable. BOOT AND DIAGNOSTIC ROMs ------------------------ Both processors have boot/diagnostic ROMs. The ROMs on the MicroVAX I are NOT the same as those on the MicroVAX II CPU, therefore there are differences in their operation. Both ROMs perform the following functions : Initialize the machine into a known state. Perform diagnostic tests. Allow for the automatic restart or bootstrap of the system following a processor halt or initial power-up. Provide bootstrap capability from a variety of devices. Provide the VAX console command language. Perform diagnostic tests. When either machine is powered on, their respective diagnostic tests are executed. Microverify is the name given to the diagnostics executed by the MicroVAX I system. There are three LEDs on the DAP module and a seven segment display on the patch panel which will isolate the problem to one of the two CPU modules. Error codes are defined in table 10-1 on page 10-4 of the MicroVAX I Owner's Manual. A similar function is performed by the MicroVAX II CPU diagnostics. As each test is run, a code is displayed on the processor LEDs, the patch Page 8 panel and the console terminal. These codes count down in hexadecimal from F to 0. There are potentially 16 steps which may be executed, therefore the MicroVAX 630 has 4 LEDs. The definitions for these codes may be found in the MicroVAX 630 CPU Module User's Guide (P/N CK-KA630-UG). Power-up modes. A major difference between the two processors is what occurs at power-up. The MicroVAX I will either attempt to do a restart, bootstrap or halt and enter console mode (the appropriate option is selected via two switches on the DAP module). The MicroVAX II can also be configured to try a restart, perform a bootstrap or halt. Before it attempts these options however, it does a language inquiry. All console messages may be output in one of eleven different languages; one must be selected. There are options such as defaulting to English or defaulting to the language which was selected previously for unassisted bootstrap or always prompting for the language at power-up. These options are described in the MicroVAX 630 CPU Module User's Guide. Bootstrap Devices. The list of devices which each processor can boot from is slightly different. Table 5 lists the supported boot devices for each processor. The devices are listed in the order by which they are searched by the processor. Table 5 - Bootstrap Devices +----------------+------------+ | MicroVAX II | MicroVAX I | +----------------+------------+ | RQDX, KDA50 or | RQDX | | RC25 | | | | | | TK50 | | | | | | MRV11-D | MRV11-D | | | | | DEQNA | DEQNA | +----------------+------------+ VAX Console Command Language. Both processors implement the VAX console command language in their boot ROMs. Most of the frequently used commands are implemented by both machines. However, there are a few commands which are only implemented by one or the other. Table 6 lists the commands and indicates which are available on each processor. Page 9 Table 6 - VAX Console Commands +-------------+--------------+------------+ | COMMAND | MicroVAX II | MicroVAX I | +-------------+--------------+------------+ | BREAK | X | X | | INITIALIZE | X | X | | START | X | X | | CONTINUE | X | X | | HALT | X | X | | BOOT | X | X | | UNJAM | X | X | | EXAMINE | X | X | | DEPOSIT | X | X | | X | X | X | | FIND | X | | | REPEAT | X | | | TEST | X | X | | ! (Comment) | X | | | N (Next) | | X | | CTRL/U | X | X | | CTRL/S | X | | | CTRL/Q | X | | | CTRL/O | X | | | CTRL/R | X | | | CTRL/C | X | | +-------------+--------------+------------+ CONFIGURATION ------------- Both CPUs have a cabinet kit through which certain features are configured. However the cabinet kits are different. The cabinet kit for the MicroVAX I will not work with the MicroVAX II CPU and vice versa. In addition to the cabinet kit are eight switches on one of the MicroVAX I CPU boards used for setting such functions as the recovery action, break detect enable and the baud rate selection. The cabinet kit for the MicroVAX I is a set of two cables and a patch panel insert for FCC system integration. It performs three functions: 1. Console terminal connector 2. Baud rate rotary switch 3. Two digit LED display The MicroVAX II CPU has no switches or jumpers on the module itself. All options are set via the patch panel insert of the cabinet kit or an optional configuration card used in place of the cabinet kit. The patch panel insert has the following functions : 1. Halt enable switch 2. Power-Up mode rotary switch 3. Baud rate rotary switch 4. Hexadecimal display Page 10 5. Console terminal connector 6. Batteries for battery backup For MicroVAX II applications which do not need the cabinet kit, Digital designed a special configuration card. This card allows the user to configure the same functions as the cabinet kit but it is much smaller and requires no cables. The configuration card is 1.5" x 2.5" and plugs into two connectors on the CPU module. Simple DIP switches are used to select the appropriate functions. TIME-OF-YEAR CLOCK WITH BATTERY BACKUP -------------------------------------- The MicroVAX I does not have the capability for keeping time after a system power-down or power failure. Each time the system is brought back up the time must be reentered manually (This limitation can be bypassed under MicroVMS for example, but the system time will be incorrect until set at a later time). The MicroVAX II has the capability for a battery backed up time-of-year (TOY) clock. A low-power TOY clock chip was designed onto the CPU module. After a system power-down the chip keeps track of the correct time and the system can reboot without needing an operator to enter the time and date. During normal operation the system keeps track of time using a 10 msec interval timer internal to the MicroVAX 78032. When power is lost this interval timer will stop but the TOY clock chip will continue to operate. The TOY clock chip has a resolution of 1 second. The batteries for the time-of-year clock chip are located on the patch panel insert of the cabinet kit. The battery backup capability is not present if a system is using the configuration card instead of the cabinet kit in order to configure the system. However there are pins on the configuration card which can be used to connect external batteries to provide the same capability. It is the user's responsibility to provide the batteries and cabling for battery backup when using the configuration card. RQDX CONTROLLER TYPE -------------------- Initial MicroVAX I systems use the RQDX1 disk controller for the RX50 floppy disks and the RD51 / RD52 winchester disks. This controller is required to be the last module in a system because it does not pass interrupt acknowledge (IACK) nor the DMA grant (BDMG) signals to options which come after it in the backplane. The RQDX2 disk controller was designed to work with and is shipped with initial MicroVAX II systems. The RQDX2 will also work with other Q-bus processors such as the MicroVAX I and MicroPDP-11/73. IMPORTANT! The RQDX1 is incompatible with the MicroVAX II CPU therefore the two should never be configured into the same system. Page 11 MULTICOMPUTING HOOKS -------------------- The MicroVAX II CPU has been designed to allow a maximum of four processors to coexist in the same system. There will always be an arbiter and up to 3 auxiliaries. This feature is NOT supported by any Digital operating system and is not an off-the-shelf multiprocessing solution. For more information on the specifics of the multicomputing feature, reference MicroNote #26 and the MicroVAX 630 CPU Module User's Guide. INSTRUCTION SET DIFFERENCES --------------------------- The MicroVAX architecture specifies which instructions must be implemented in the hardware/microcode, all other instructions will then be emulated in software. Depending on the particular instruction, the emulation is either entirely in software or in software with a hardware assist. Any specific MicroVAX implementation will meet this minimum requirement but may choose to include in its microcode some instructions which would otherwise be emulated. MicroNote #24 contains a table which lists all of the instructions in the VAX architecture and indicates for each MicroVAX processor whether or not the instruction is in the hardware or emulated. POWER REQUIREMENTS, AC LOADS, DC LOADS AND TERMINATION ------------------------------------------------------ Table 7 below summarizes the pertinent information necessary to configure one of these processors into a system. Since the MicroVAX II CPU is only one quad module it is not surprising that the amount of current drawn from the +5 volt supply is substantially less than that required by the MicroVAX I CPU. Table 7 - Specifications +---------------------+-------------+------------+ | SPECIFICATION | MicroVAX II | MicroVAX I | +---------------------+-------------+------------+ | Power Requirements | | | | +5 Volt (amps) | 6.2 | 14.0 | | +12 Volt (amps) | 0.14 | 0.5 | +---------------------+-------------+------------+ | AC loads | 2.7 | 2 | +---------------------+-------------+------------+ | DC loads | 1.0 | 1 | +---------------------+-------------+------------+ | Termination (ohms) | 240 | 240 | +---------------------+-------------+------------+ ================================================================================ Note 23.0 MicroVAX I->II upgrades No replies FURILO::JACKSON 248 lines 19-AUG-1985 11:31 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 023 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: MicroVAX I to MicroVAX II Upgrade Issues | Date: 28-APR-85 | +----------------------------------------------------+-----------------+ | Originator: Mike Collins | Page 1 of 5 | +----------------------------------------------------+-----------------+ This MicroNote describes the hardware issues in upgrading from a MicroVAX I to a MicroVAX II. The Add-On and Upgrades group within Digital Equipment Corporation announced a formal upgrade kit at the time of the MicroVAX II announcement. For more information about this program contact a local DEC sales representative. This MicroNote is intended for those users who wish understand the issues in an upgrade. Reference MicroNote #22 for a detailed description of the differences between the processors of the MicroVAX I and MicroVAX II systems. Upgrading a MicroVAX I to a MicroVAX II is straightforward because the two systems share many common components. First of all the BA23 enclosure is used by both systems, this includes the backplane, power supply, control panel, and I/O patch panel. The 5 1/4" disk devices used on a MicroVAX I are also compatible with the MicroVAX II. Since I/O devices for both machines are Q-bus devices they are directly compatible with the new processor. The upgrade process does however involve replacing the processor, the memory, the 5 1/4" disk controller and the processor cabinet kit. Each of these upgrade issues is addressed in detail. An upgrade example is shown at the end of this MicroNote. THE PROCESSOR UPGRADE: The MicroVAX I CPU is made up of two quad modules, the memory controller ('MCT') and the data path ('DAP'). These two modules occupy slots 1 and 2 in the backplane. Both of these modules are replaced with a single quad module, the MicroVAX II CPU which must be placed in slot 1. The MicroVAX II CPU module includes 1 MB of memory and the MicroVAX 78132 floating point unit. Slot 2 previously used by the MicroVAX I is now available for expansion memory or other options. THE MEMORY UPGRADE: The memory system designed for the MicroVAX II is unique to that processor, therefore the Q-bus memories used in the MicroVAX I must be removed and replaced by the new type. Page 2 If the MicroVAX I being upgraded has only 1 MB of main memory then the processor and memory can both be replaced with the MicroVAX II CPU module. Additional memory may be added to a MicroVAX II CPU if necessary. Besides the 1 MB of on-board memory, the MicroVAX II CPU will support a maximum of 2 memory expansion boards. These additional boards must be placed immediately after the processor in slots 2 and 3 of the backplane. The memory modules communicate with the CPU over the C-D interconnect of the backplane and an over-the-top cable. A cable is shipped with each memory module. Figure 1 is an example of how the processor and memory boards are configured into a system. If the dual height memory expansion module is used (MS630-AA) it must be placed in the C-D side of the backplane. The memory modules may be placed in any order in slots 2 and 3. Table 2 lists the memory expansion options. WARNING Both the MicroVAX II CPU and MS630 memory expansion modules must be placed in backplane slots with the C-D interconnect. Damage may result if these modules are placed in backplanes with Q-bus signals on both the A/B and C/D sides. Table 2 - MS630 Memory Expansion Modules +----------+---------------+---------------+ | MEMORY | MEMORY SIZE | FORM FACTOR | +----------+---------------+---------------+ | MS630-AA | 1 Mbyte | Dual | +----------+---------------+---------------+ | MS630-BA | 2 Mbytes | Quad | +----------+---------------+---------------+ | MS630-BB | 4 Mbytes | Quad | +----------+---------------+---------------+ Figure 1 - Processor and Memory Configuration +-------------------------------------+ | +---------------------------------+ | 1 | | MicroVAX II CPU ========== | | | +---------------------| |----+ | +-----------------------| |------+ | +---------------------| |----+ | 2 | | MS630-B ========== | | | +---------------------| |----+ | +-----------------------| |<--------Memory Expansion | +-----| |----+ | Cable 3 | MS630-AA---->| ========== | | | +-----------------+ | +-------------------------------------+ 4 | | . | Additional slots | . | | 8 | | +-------------------------------------+ Page 3 THE RQDX DISK CONTROLLER UPGRADE: The RQDX1 5 1/4" disk controller used in MicroVAX I systems must be removed and replaced with the RQDX2 controller. This upgrade is necessary because the RQDX2 provides features not available on the RQDX1 and because the RQDX1 is incompatible with the MicroVAX II. The RQDX1 does not pass the interrupt acknowledge (IACK) or DMA grant signal (DMGO) to other modules which may be located after it in the backplane. Therefore it must always be the last module in a system. This restriction has been removed with the RQDX2, which does pass both of those signals. Both RQDX modules are capable of controlling 4 logical units. However the RQDX1 can only control a maximum of 2 fixed winchesters (RD5n type drives). Therefore the largest amount of storage that can be connected to an RQDX1 would be a combination of 2 RD5n type drives and an RX50, which counts as two logical units because it actually handles two 400KB floppies. The RQDX2 also controls 4 logical units but it knows how to control any combination of RDs and RX50s. Therefore the maximum amount of storage that can be connected to an RQDX2 would be four RD5n type drives. The RQDX1 is compatible with RX50 floppies (800KB), RD51 (11MB) and RD52 (31MB) disk drives. The RQDX2 is compatible with those drives but is also capable of controlling RD53 (71MB) drives. THE CABINET KIT UPGRADE: The MicroVAX I cabinet kit is incompatible with the MicroVAX II, therefore the cabinet kit used in the MicroVAX II, BA23 based system must be used. The part number is CK-KA630-AB. Both cabinet kits have one serial line connector in order to communicate with the VAX console device. The MicroVAX I cabinet kit uses the standard 25-pin, D-subminiature RS232 connector. The MicroVAX II cabinet kit uses a different type of connector. It is a 9-pin D-subminiature connector and will therefore require a different cable from the patch panel to the console device. The appropriate cable is part number BCC08. OPERATING SYSTEM UPGRADE: Once the hardware has been upgraded it is also necessary to have the appropriate system software which will support the MicroVAX II. Table 3 lists the initial versions of MicroVMS, ULTRIX-32m and VAXELN which support the MicroVAX II. Table 3 - System Software Support +-----------------+----------------------------------+ | System Software | Version with MicroVAX II Support | +-----------------+----------------------------------+ | MicroVMS | V4.1m or later | | ULTRIX-32m | V1.1 or later | | VAXELN | V2.0 or later | +-----------------+----------------------------------+ Page 4 Many software layered products support the MicroVAX II. Consult the appropriate Software Product Description (SPD) to verify if the current version of the layered product is supported. UPGRADE EXAMPLE: The following example illustrates the changes made to a MicroVAX I system to upgrade it to a MicroVAX II system. The diagrams represent the modules placed in the BA23 backplane. Both systems have a CPU, 2MB of memory, a DHV11 8-line asynchronous multiplexer, a DEQNA Ethernet controller and an RQDX 5 1/4" disk controller. MicroVAX I System MicroVAX II System +---------------------+ +---------------------+ 1 | KD32 CPU - MCT | 1 | KA630-AA | +---------------------+ +----------+----------+ 2 | KD32 CPU - DAP | 2 | DEQNA | MS630-AA | +---------------------+ +----------+----------+ 3 | MSV11-QA (1MB) | 3 | RQDX2 | +---------------------+ +---------------------+ 4 | MSV11-QA (1MB) | 4 | DHV11 | +---------------------+ +---------------------+ 5 | DHV11 | 5 | | +----------+----------+ +---------------------+ 6 | DEQNA | G7272 | 6 | | +----------+----------+ +---------------------+ 7 | RQDX1 | 7 | | +---------------------+ +---------------------+ 8 | | 8 | | +---------------------+ +---------------------+ Comments: The 2 modules of the MicroVAX I CPU and the two quad memory boards (MSV11-QAs) were replaced by the KA630-AA and one MS630-AA. The DHV11 and DEQNA are compatible with both processors, therefore they were not replaced and remained in the system. The RQDX1 controller is incompatible with the MicroVAX II, therefore it is replaced with the RQDX2. Any 5 1/4" disk (RX50, RD51 and RD52) used on the MicroVAX I is compatible with the RQDX2 on the MicroVAX II. The RQDX1 controller must occupy the last slot in a system. The RQDX2 controller is located before the DHV11 in the upgraded system to emphasize the point that it is not required to be the last module in the system. The MicroVAX I system required a G7272 grant continuity card in slot 6 in order to make the system work properly. This was not necessary in the upgraded MicroVAX II system because there was an empty dual-height slot next to the MS630-AA memory module. This illustrates the point Page 5 that the dual height slot next to an MS630-AA is a valid Q-bus slot and can be occupied by any compatible, dual-height option. The cabinet kits for the two systems are not shown in the diagrams, but the one used for the MicroVAX I must be replaced by the cabinet kit for the MicroVAX II, part number CK-KA630-AB. The serial line cable from the patch panel to the terminal must also change. The cable of the MicroVAX I system must be replaced by a BCC08 cable. ================================================================================ Note 24.0 MicroVAX instr set difference No replies FURILO::JACKSON 578 lines 19-AUG-1985 11:32 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 024 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: MicroVAX Instruction Set Differences | Date: 28-APR-85 | +----------------------------------------------------+-----------------+ | Originator: Mike Collins | Page 1 of 10 | +----------------------------------------------------+-----------------+ The MicroVAX architecture specifies that the full VAX instruction set need not be implemented in the hardware of a MicroVAX processor. For those processors that fall into this category, there is a software emulator which guarantees that the instructions are still executable. This MicroNote lists all of the instructions of the VAX architecture and for each MicroVAX processor indicates which instructions are implemented in hardware/microcode, those that are emulated and those that are present in a floating point unit. The instructions are listed in alphabetical order by instruction mnemonic. The following designations are used to indicate where an instruction will be executed. CPU - Instructions marked with 'CPU' are implemented in the hardware of the particular MicroVAX processor. EMA - Instructions marked with 'EMA' are emulated with microcode assist. E - Instructions marked with an 'E' are emulated entirely in software. Processor specific designations: MicroVAX II FPU - Instructions marked with 'FPU' are implemented in the hardware only if an external floating point unit is present, otherwise they are emulated. MicroVAX I Hx - Instructions marked with 'H', 'HF', 'HD' or 'HG' are implemented in hardware even though the MicroVAX architecture specifies that these instructions are emulated. There are two versions of the MicroVAX I, one with F_ and D_floating and the other with F_ and G_floating instructions in microcode. There are no MicroVAX I processors with all 3 of these floating point instruction types in the hardware. The F_floating instructions are identified by 'HF', the D_floating by 'HD' and the G_floating by 'HG'. Page 2 Reference MicroNote #21, 'Floating Point Considerations on MicroVAX I'. The following table lists statistics about the distribution of instructions based on where they are executed. There are 304 instructions in the VAX instruction set. Table 1 - MicroVAX Instruction Distribution +-------------------------+--------------+------------+-------------+ | Description | MicroVAX | MicroVAX I | MicroVAX II | | | Architecture | | | +-------------------------+--------------+------------+-------------+ | Percentage executed | 57.6 | 74.3 | 57.6 | | in CPU | | | | +-------------------------+--------------+------------+-------------+ | Percentage executed | N/A | N/A | 23.0 | | in FPU | | | | +-------------------------+--------------+------------+-------------+ | Percentage emulated | 8.9 | 7.3 | 8.9 | | with microcode assist | | | | +-------------------------+--------------+------------+-------------+ | Percentage emulated | 33.5 | 18.4 | 10.5 | | entirely in software | | | | +-------------------------+--------------+------------+-------------+ Table 2 - Instruction Set Differences Mnemonic Description MicroVAX MicroVAXI MicroVAXII Architecture ACBB Add compare and branch byte CPU CPU CPU ACBD Add compare and branch E HD FPU D_floating ACBF Add compare and branch E HF FPU F_floating ACBG Add compare and branch E HG FPU G_floating ACBH Add compare and branch E E E H_floating ACBL Add compare and branch CPU CPU CPU longword ACBW Add compare and branch word CPU CPU CPU ADAWI Add aligned word interlocked CPU CPU CPU ADDB2 Add byte 2-operand CPU CPU CPU ADDB3 Add byte 3-operand CPU CPU CPU ADDD2 Add D_floating 2-operand E HD FPU ADDD3 Add D_floating 3_operand E HD FPU ADDF2 Add F_floating 2_operand E HF FPU ADDF3 Add F_floating 3_operand E HF FPU ADDG2 Add G_floating 2_operand E HG FPU Page 3 Mnemonic Description MicroVAX MicroVAXI MicroVAXII Architecture ADDG3 Add G_floating 3_operand E HG FPU ADDH2 Add H_floating 2_operand E E E ADDH3 Add H_floating 3-operand E E E ADDL2 Add longword 2-operand CPU CPU CPU ADDL3 Add longword 3-operand CPU CPU CPU ADDP4 Add packed 4-operand E EMA EMA ADDP6 Add packed 6-operand E EMA EMA ADDW2 Add word 2-operand CPU CPU CPU ADDW3 Add word 3-operand CPU CPU CPU ADWC Add with carry CPU CPU CPU AOBLEQ Add one and branch on CPU CPU CPU less or equal AOBLSS Add one and branch on less CPU CPU CPU ASHL Arithmetic shift longword CPU CPU CPU ASHP Arithmetic shift and E EMA EMA round packed ASHQ Arithmetic shift quad CPU CPU CPU BBC Branch on bit clear CPU CPU CPU BBCC Branch on bit clear and clear CPU CPU CPU BBCCI Branch on bit clear and clear CPU CPU CPU interlocked BBCS Branch on bit clear and set CPU CPU CPU BBS Branch on bit set CPU CPU CPU BBSC Branch on bit set and clear CPU CPU CPU BBSS Branch on bit set and set CPU CPU CPU BBSSI Branch on bit set and set CPU CPU CPU interlocked BCC Branch on carry clear CPU CPU CPU BCS Branch on carry set CPU CPU CPU BEQL Branch on equal CPU CPU CPU BEQLU (=BEQL) Branch on equal unsigned CPU CPU CPU BGEQ Branch on greater or equal CPU CPU CPU BGEQU (=BCC) Branch on greater or equal CPU CPU CPU unsigned BGTR Branch on greater CPU CPU CPU BGTRU Branch on greater unsigned CPU CPU CPU BICB2 Bit clear byte 2-operand CPU CPU CPU BICB3 Bit clear byte 3-operand CPU CPU CPU BICL2 Bit clear longword 2-operand CPU CPU CPU BICL3 Bit clear longword 3-operand CPU CPU CPU BICPSW Bit clear processor status CPU CPU CPU word BICW2 Bit clear word 2-operand CPU CPU CPU BICW3 Bit clear word 3-operand CPU CPU CPU BISB2 Bit set byte 2-operand CPU CPU CPU BISB3 Bit set byte 3-operand CPU CPU CPU Page 4 Mnemonic Description MicroVAX MicroVAXI MicroVAXII Architecture BISL2 Bit set longword 2-operand CPU CPU CPU BISL3 Bit set longword 3-operand CPU CPU CPU BISPSW Bit set processor status CPU CPU CPU word BISW2 Bit set word 2-operand CPU CPU CPU BISW3 Bit set word 3-operand CPU CPU CPU BITB Bit test byte CPU CPU CPU BITL Bit test longword CPU CPU CPU BITW Bit test word CPU CPU CPU BLBC Branch on low bit clear CPU CPU CPU BLBS Branch on low bit set CPU CPU CPU BLEQ Branch on less or equal CPU CPU CPU BLEQU Branch on less or equal CPU CPU CPU unsigned BLSS Branch on less CPU CPU CPU BLSSU (=BCS) Branch on less unsigned CPU CPU CPU BNEQ Branch on not equal CPU CPU CPU BNEQU (=BNEQ) Branch on not equal unsigned CPU CPU CPU BPT Break point fault CPU CPU CPU BRB Branch with byte displacement CPU CPU CPU BRW Branch with word displacement CPU CPU CPU BSBB Branch to subroutine with CPU CPU CPU byte displacement BSBW Branch to subroutine with CPU CPU CPU word displacement BVC Branch on overflow clear CPU CPU CPU BVS Branch on overflow set CPU CPU CPU CALLG Call with general argument CPU CPU CPU list CALLS Call with argument list on CPU CPU CPU stack CASEB Case byte CPU CPU CPU CASEL Case longword CPU CPU CPU CASEW Case word CPU CPU CPU CHME Change mode to executive CPU CPU CPU CHMK Change mode to kernel CPU CPU CPU CHMS Change mode to supervisor CPU CPU CPU CHMU Change mode to user CPU CPU CPU CLRB Clear byte CPU CPU CPU CLRD (=CLRQ) Clear D_floating CPU CPU CPU CLRF (=CLRL) Clear F_floating CPU CPU CPU CLRG (=CLRQ) Clear G_floating CPU CPU CPU CLRH (=CLRO) Clear H_floating CPU CPU CPU CLRL Clear longword CPU CPU CPU CLRO Clear ocatword E E E CLRQ Clear quadword CPU CPU CPU Page 5 Mnemonic Description MicroVAX MicroVAXI MicroVAXII Architecture CLRW Clear word CPU CPU CPU CMPB Compare byte CPU CPU CPU CMPC3 Compare character 3-operand E H EMA CMPC5 Compare character 5-operand E EMA EMA CMPD Compare D_floating E HD FPU CMPF Compare F_floating E HF FPU CMPG Compare G_floating E HG FPU CMPH Compare H_floating E E E CMPL Compare longword CPU CPU CPU CMPP3 Compare packed 3-operand E EMA EMA CMPP4 Compare packed 4-operand E EMA EMA CMPV Compare field CPU CPU CPU CMPW Compare word CPU CPU CPU CMPZV Compare zero-extended field CPU CPU CPU CRC Calculate cyclic redundancy E EMA EMA check CVTBD Convert byte to D_floating E HD FPU CVTBF Convert byte to F_floating E HF FPU CVTBG Convert byte to G_floating E HG FPU CVTBH Convert byte to H_floating E E E CVTBL Convert byte to longword CPU CPU CPU CVTBW Convert byte to word CPU CPU CPU CVTDB Convert D_floating to byte E HD FPU CVTDF Convert D_floating to E HD FPU F_floating CVTDH Convert D_floating to E E E H_floating CVTDL Convert D_floating to E HD FPU longword CVTDW Convert D_floating to word E HD FPU CVTFB Convert F_floating to byte E HF FPU CVTFD Convert F_floating to E HF FPU D_floating CVTFG Convert F_floating to E HG FPU G_floating CVTFH Convert F_floating to E E E H_floating CVTFL Convert F_floating to E HF FPU longword CVTFW Convert F_floating to word E HF FPU CVTGB Convert G_floating to byte E HG FPU CVTGF Convert G_floating to E HG FPU F_floating CVTGH Convert G_floating to E E E H_floating Page 6 Mnemonic Description MicroVAX MicroVAXI MicroVAXII Architecture CVTGL Convert G_floating to E HG FPU longword CVTGW Convert G_floating to word E HG FPU CVTHB Convert H_floating to byte E E E CVTHD Convert H_floating to E E E D_floating CVTHF Convert H_floating to E E E F_floating CVTHG Convert H_floating to E E E G_floating CVTHL Convert H_floating to E E E longword CVTHW Convert H_floating to word E E E CVTLB Convert longword to byte CPU CPU CPU CVTLD Convert longword to D_floating E HD FPU CVTLF Convert longword to F_floating E HF FPU CVTLG Convert longword to G_floating E HG FPU CVTLH Convert longword to H_floating E E E CVTLP Convert longword to packed E EMA EMA CVTLW Convert longword to word CPU CPU CPU CVTPL Convert packed to longword E EMA EMA CVTPS Convert packed to leading E EMA EMA separate CVTPT Convert packed to trailing E EMA EMA CVTRDL Convert rounded D_floating E HD FPU to longword CVTRFL Convert rounded F_floating E HF FPU to longword CVTRGL Convert rounded G_floating E HG FPU to longword CVTRHL Convert rounded H_floating E E E to longword CVTSP Convert leading separate E EMA EMA to packed CVTTP Convert trailing to packed E EMA EMA CVTWB Convert word to byte CPU CPU CPU CVTWD Convert word to D_floating E HD FPU CVTWF Convert word to F_floating E HF FPU CVTWG Convert word to G_floating E HG FPU CVTWH Convert word to H_floating E E E CVTWL Convert word to longword CPU CPU CPU DECB Decrement byte CPU CPU CPU DECL Decrement longword CPU CPU CPU DECW Decrement word CPU CPU CPU DIVB2 Divide byte 2-operand CPU CPU CPU DIVB3 Divide byte 3-operand CPU CPU CPU Page 7 Mnemonic Description MicroVAX MicroVAXI MicroVAXII Architecture DIVD2 Divide D_floating 2-operand E HD FPU DIVD3 Divide D_floating 3-operand E HD FPU DIVF2 Divide F_floating 2-operand E HF FPU DIVF3 Divide F_floating 3-operand E HF FPU DIVG2 Divide G_floating 2-operand E HG FPU DIVG3 Divide G_floating 3-operand E HG FPU DIVH2 Divide H-floating 2-operand E E E DIVH3 Divide H-floating 3-operand E E E DIVL2 Divide longword 2-operand CPU CPU CPU DIVL3 Divide longword 3-operand CPU CPU CPU DIVP Divide packed E EMA EMA DIVW2 Divide word 2-operand CPU CPU CPU DIVW3 Divide word 3-operand CPU CPU CPU EDITPC Edit packed to character E EMA EMA string EDIV Extended divide CPU CPU CPU EMODD Extended modulus D_floating E HD FPU EMODF Extended modulus F_floating E HF FPU EMODG Extended modulus G_floating E HG FPU EMODH Extended modulus H_floating E E E EMUL Extended multiply CPU CPU CPU EXTV Extract field CPU CPU CPU EXTZV Extract zero_extended field CPU CPU CPU FFC Find first clear bit CPU CPU CPU FFS Find first set bit CPU CPU CPU HALT Halt (kernel mode only) CPU CPU CPU INCB Increment byte CPU CPU CPU INCL Increment longword CPU CPU CPU INCW Increment word CPU CPU CPU INDEX Index calculation CPU CPU CPU INSQHI Insert at head of queue, CPU CPU CPU interlocked INSQTI Insert at tail of queue, CPU CPU CPU interlocked INSQUE Insert into queue CPU CPU CPU INSV Insert field CPU CPU CPU JMP Jump CPU CPU CPU JSB Jump to subroutine CPU CPU CPU LDPCTX Load process context (only CPU CPU CPU legal on interrupt stack) LOCC Locate character E H EMA MATCHC Match characters E EMA EMA MCOMB Move complemented byte CPU CPU CPU MCOML Move complemented longword CPU CPU CPU Page 8 Mnemonic Description MicroVAX MicroVAXI MicroVAXII Architecture MCOMW Move complemented word CPU CPU CPU MFPR Move from processor register CPU CPU CPU (kernel mode only) MNEGB Move negated byte CPU CPU CPU MNEGD Move negated D_floating E HD FPU MNEGF Move negated F_floating E HF FPU MNEGG Move negated G_floating E HG FPU MNEGH Move negated H_floating E E E MNEGL Move negated longword CPU CPU CPU MNEGW Move negated word CPU CPU CPU MOVAB Move address of byte CPU CPU CPU MOVAD (=MOVAQ) Move address of D_floating CPU CPU CPU MOVAF (=MOVAL) Move address of F_floating CPU CPU CPU MOVAG (=MOVAQ) Move address of G_floating CPU CPU CPU MOVAH (=MOVAO) Move address of H_floating CPU CPU CPU MOVAL Move address of longword CPU CPU CPU MOVAO Move address of ocatword E E E MOVAQ Move address of quadword CPU CPU CPU MOVAW Move address of word CPU CPU CPU MOVB Move byte CPU CPU CPU MOVC3 Move character 3-operand CPU CPU CPU MOVC5 Move character 5-operand CPU CPU CPU MOVD Move D_floating E HD FPU MOVF Move F_floating E HF FPU MOVG Move G_floating E HG FPU MOVH Move H_floating E E E MOVL Move longword CPU CPU CPU MOVO Move octaword E E E MOVP Move packed E EMA EMA MOVPSL Move processor status CPU CPU CPU longword MOVQ Move quadword CPU CPU CPU MOVTC Move translated characters E EMA EMA MOVTUC Move translated until E EMA EMA character MOVW Move word CPU CPU CPU MOVZBL Move zero-extended byte to CPU CPU CPU longword MOVZBW Move zero-extended byte to CPU CPU CPU word Page 9 Mnemonic Description MicroVAX MicroVAXI MicroVAXII Architecture MOVZWL Move zero-extended word to CPU CPU CPU longword MTPR Move to processor register CPU CPU CPU (kernel mode only) MULB2 Multiply byte 2-operand CPU CPU CPU MULB3 Multiply byte 3-operand CPU CPU CPU MULD2 Multiply D_floating 2-operand E HD FPU MULD3 Multiply D_floating 3-operand E HD FPU MULF2 Multiply F_floating 2-operand E HF FPU MULF3 Multiply F_floating 3-operand E HF FPU MULG2 Multiply G_floating 2-operand E HG FPU MULG3 Multiply G_floating 3-operand E HG FPU MULH2 Multiply H_floating 2-operand E E E MULH3 Multiply H_floating 3-operand E E E MULL2 Multiply longword 2-operand CPU CPU CPU MULL3 Multiply longword 3-operand CPU CPU CPU MULP Multiply packed E EMA EMA MULW2 Multiply word 2-operand CPU CPU CPU MULW3 Multiply word 3-operand CPU CPU CPU NOP No operation CPU CPU CPU POLYD Evaluate polynomial D_floating E HD FPU POLYF Evaluate polynomial F_floating E HF FPU POLYG Evaluate polynomial G_floating E HG FPU POLYH Evaluate polynomial H_floating E E E POPR Pop registers CPU CPU CPU PROBER Probe read access CPU CPU CPU PROBEW Probe write access CPU CPU CPU PUSHAB Push address of byte CPU CPU CPU PUSHAD (=PUSHAQ) Push address of D_floating CPU CPU CPU PUSHAF (=PUSHAL) Push address of F_floating CPU CPU CPU PUSHAG (=PUSHAQ) Push address of G_floating CPU CPU CPU PUSHAH (=PUSHAO) Push address of H_floating CPU CPU CPU PUSHAL Push address of longword CPU CPU CPU PUSHAO Push address of ocatword E E E PUSHAQ Push address of quadword CPU CPU CPU PUSHAW Push address of word CPU CPU CPU PUSHL Push longword CPU CPU CPU PUSHR Push registers CPU CPU CPU REI Return from exception or CPU CPU CPU interrupt REMQHI Remove from head of queue, CPU CPU CPU interlocked REMQTI Remove from tail of queue, CPU CPU CPU interlocked REMQUE Remove from queue CPU CPU CPU Page 10 Mnemonic Description MicroVAX MicroVAXI MicroVAXII Architecture RET Return from procedure CPU CPU CPU ROTL Rotate longword CPU CPU CPU RSB Return from subroutine CPU CPU CPU SBWC Subtract with carry CPU CPU CPU SCANC Scan for character E H EMA SKPC Skip character E H EMA SOBGEQ Subtract one and branch CPU CPU CPU on greater or equal SOBGTR Subtract one and branch CPU CPU CPU on greater SPANC Span characters E H EMA SUBB2 Subtract byte 2-operand CPU CPU CPU SUBB3 Subtract byte 3-operand CPU CPU CPU SUBD2 Subtract D_floating 2-operand E HD FPU SUBD3 Subtract D_floating 3-operand E HD FPU SUBF2 Subtract F_floating 2-operand E HF FPU SUBF3 Subtract F_floating 3-operand E HF FPU SUBG2 Subtract G_floating 2-operand E HG FPU SUBG3 Subtract G_floating 3-operand E HG FPU SUBH2 Subtract H_floating 2-operand E E E SUBH3 Subtract H_floating 3-operand E E E SUBL2 Subtract longword 2-operand CPU CPU CPU SUBL3 Subtract longword 3-operand CPU CPU CPU SUBP4 Subtract packed 4-operand E EMA EMA SUBP6 Subtract packed 6-operand E EMA EMA SUBW2 Subtract word 2-operand CPU CPU CPU SUBW3 Subtract word 3-operand CPU CPU CPU SVPCTX Save process context (kernel CPU CPU CPU mode only) TSTB Test byte CPU CPU CPU TSTD Test D_floating E HD FPU TSTF Test F_floating E HF FPU TSTG Test G_floating E HG FPU TSTH Test H_floating E E E TSTL Test longword CPU CPU CPU TSTW Test word CPU CPU CPU XFC Extended function call CPU CPU CPU XORB2 Exclusive OR byte 2-operand CPU CPU CPU XORB3 Exclusive OR byte 3-operand CPU CPU CPU XORL2 Exclusive OR longword 2-operand CPU CPU CPU XORL3 Exclusive OR longword 3-operand CPU CPU CPU XORW2 Exclusive OR word 2-operand CPU CPU CPU XORW3 Exclusive OR word 3-operand CPU CPU CPU ================================================================================ Note 25.0 FPJ11,KDJ11-A compatibility No replies FURILO::JACKSON 85 lines 19-AUG-1985 11:35 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 025 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: FPJ11-AA Compatibility with the | Date: 28-APR-85 | | LSI-11/73 (KDJ11-A) | | +----------------------------------------------------+-----------------+ | Originator: Mike Collins | Page 1 of 2 | +----------------------------------------------------+-----------------+ Early LSI-11/73 (KDJ11-A) modules are incompatible with the FPJ11-AA floating point accelerator. This MicroNote describes how to identify those modules which are compatible and those which are not compatible with the FPJ11-AA. The following information refers to two identifying numbers. They are the module variation and the module revision. The module variation number is stamped onto the end of the plastic handles. It will be 'M8192', 'M8192-YB' or 'M8192-YC'. The module revision number can be found on side two of the module (noncomponent side) stamped into the plastic handle, or written with indelible ink. This number is updated as the board is ECO'd. The designation is a number followed by the module revision. e.g. 441 C1, indicates module revision C1. The first LSI-11/73 module is called a KDJ11-AA and is incompatible with the FPJ11-AA. The module variation for the KDJ11-AA is M8192, and the module revision number is C1. The KDJ11-AA can be upgraded to be FPJ11-AA compatible. Contact the local DEC office for more information concerning the upgrade procedure. Two new options have been created. The KDJ11-AB is a module which is fully compatible with the FPJ11-AA. The module variation for the KDJ11-AB is M8192-YB, and the module revision number is A1 or A2. The third option is called a KDJ11-AC and is used for fully compatible modules which have FPJ11-AAs installed onto the board by Digital. It has a module variation of M8192-YC and the module revision number is A1 or A2. Therefore a KDJ11-AB becomes a KDJ11-AC by simply installing an FPJ11-AA. Page 2 The following table summarizes the above information and should be used as a 'quick check' for FPJ11-AA compatibility. +----------+------------+------------+--------------------------+ | OPTION | MODULE | MODULE | FPJ11 COMPATIBLE? | | | VARIATION | REVISION | | +----------+------------+------------+--------------------------+ | KDJ11-AA | M8192 | C1 | NO (But Upgradeable) | +----------+------------+------------+--------------------------+ | KDJ11-AB | M8192-YB | A1 or A2 | YES | +----------+------------+------------+--------------------------+ | KDJ11-AC | M8192-YC | A1 or A2 | YES (FPJ11-AA Installed) | +----------+------------+------------+--------------------------+ CAUTION An FPJ11-AA installed on a KDJ11-AA may APPEAR to work but cache errors and parity errors may occur. An MXV11-BF must be REV C to be compatible with a KDJ11-A with an FPJ11-AA (KDJ11-AC). Earlier versions of the MXV11-BF are incompatible with KDJ11-ACs. KDJ11-As without FPJ11-AAs are compatible with all versions of the MXV11-BF. The MCV11-D is incompatible with KDJ11-ACs. KDJ11-As without FPJ11-AAs are compatible with all versions of the MCV11-D. ================================================================================ Note 26.0 MicroVAX II multicomputing No replies FURILO::JACKSON 700 lines 19-AUG-1985 11:36 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 026 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: The MicroVAX II CPU Multicomputing | Date: 28-JUN-85 | | Capability | | +----------------------------------------------------+-----------------+ | Originator: Mike Collins | Page 1 of 12 | +----------------------------------------------------+-----------------+ The MicroVAX II CPU may be configured as an arbiter CPU or as one of three auxiliary CPU's. Therefore it is possible to configure a Q-bus system with multiple MicroVAX II CPUs. This 'multicomputing' capability is the topic of this MicroNote. Multicomputing Introduction The multicomputing capability is a hardware design feature of the MicroVAX II. It allows a maximum of four MicroVAX II CPUs to reside on the same Q-bus. Figure 1 below is a block diagram which shows how 2 of a possible 4 CPUs may be configured on the bus. One of the processors will be the arbiter and the others will be auxiliaries. NOTE There is no shared memory between processors, therefore this system should not be considered as symmetrical multiprocessing. Each processor may use expansion memory modules provided that there are sufficient Q/CD slots in the backplane. See the configuration section for more detail on the configuration rules. +---------------------+ +---------------------+ | +---------+ | | +---------+ | | | | | | | | | +---------+ +---------+ +---------+ +---------+ | Arbiter | | | |Auxiliary| | | |Processor| | Memory | |Processor| | Memory | | | | | | | | | | | | | | #1 | | | | | | | | | | | +---------+ +---------+ +---------+ +---------+ | | | | ----------------------------------------------------------- Q-bus ----------------------------------------------------------- Page 2 Figure 1 - Multicomputing Configuration CAUTION Digital's 32-bit operating systems DO NOT support the multicomputing feature. Users who wish to customize their systems to take advantage of the multicomputing capability may do so but are responsible for designing the software system. The following topics which are pertinent to the multicomputing design will be described in detail: 1. MicroVAX II Memory System 2. Interprocessor Communications Register 3. Arbiter/auxiliary Processor Differences 4. Bootstrapping an Auxiliary Processor 5. Configuration Rules REFERENCES The MicroVAX 630 CPU Module User's Guide (P/N EK-KA630-UG) and MicroNote #22 have more detailed information on all aspects of the MicroVAX II CPU and memory system. MicroVAX II Memory System -------------------------- Before describing the details of the multicomputing feature it is necessary to understand the memory system of a MicroVAX II. The memory system of the MicroVAX II is unique. Unlike previous Q-bus processors, the memory modules do not communicate to the CPU over the Q-bus. Instead, the communication and transfers occur over a dedicated, closely coupled interconnect. This design allows for very fast reads and writes to memory (400 nsec). Not only are the transfers very fast, but none of this CPU-memory activity appears on the Q-bus. Therefore the Q-bus is strictly for I/O. Since memory is not directly on the Q-bus it is necessary to allow DMA devices on the Q-bus to access memory. This feature is called the Q-bus I/O map. It is a mechanism which maps Q-bus addresses (22-bit physical address) to the local memory system of a MicroVAX II (24-bit physical address). This same concept is used on larger UNIBUS based VAXes. When one or more auxiliary processors are added to a system, remember that each has its own local memory system. Therefore it is intended that they will each operate out of their own memory. This design is Page 3 well suited for applications which can be easily partitioned between multiple processors such that only messages are passed between them. It would be possible for a processor to operate out of memory on the Q-bus but this would be unconventional from a systems standpoint and would decrease system performance significantly. Digital's operating systems do not support the use of standard Q-bus memories in a MicroVAX II. With only one processor on the Q-bus, the system software has complete control over DMA transfers. The software controls the contents of the Q-bus map registers. First, it determines whether the register is enabled and second, if it is enabled, where the DMA transfers are directed in the local memory system. In a multiple processor configuration (since each has its own set of Q-bus I/O map registers) it is now possible for multiple map registers to respond to a single Q-bus address. It is the responsibility of the system software running on each processor to cooperate and assure that one and only one map register will respond to any Q-bus address. Otherwise multiple memory locations may respond and the results are indeterminate (i.e. multiple BRPLYs on the Q-bus for a single address). A similar situation occurs if standard Q-bus memories are added to a MicroVAX II system. The system software is again responsible for assuring that for any address on the Q-bus which is 'shared' by a Q-bus memory board and a Q-bus I/O map register, the map register is disabled to allow only a Q-bus memory reply. Q-bus memories would not be added to 'typical' systems. However there are some special applications which may require this capability. For example, a graphics system where the Q-bus memory is the bit map of a graphics display. On power-up, the MicroVAX II boot ROM will check for the presence of Q-bus memory and clear the valid bits of the corresponding mapping registers. This will prevent the above situation from occurring as long as the system software does not alter the state of these valid bits at a later time. Interprocessor Communications Register -------------------------------------- The interprocessor communications register (ICR) is the primary mechanism of the MicroVAX II CPU which enables multiple processors to cooperate and reside on the same Q-bus. Figure 3 describes the ICR and the bit definitions. The ICR provides the following four functions: 1. Any processor on the bus may interrupt another without using the Q-bus interrupt lines. This is done by setting the appropriate bit in the ICR of the second processor. The CPU will then interrupt at IPL 14 (HEX) with an interrupt vector of 204 (HEX). Page 4 2. The ICR also has a bit which controls external access to local memory via the Q-bus map. When set this bit allows external devices to access the local memory system. When reset, this bit prevents the local memory system from responding to any Q-bus address references. 3. If a processor is an auxiliary then the ICR provides a mechanism which allows it to be halted by other CPUs. This feature is used at power-up to coordinate the bootstrap process. 4. Parity errors are identified when one occurs during accesses to the MicroVAX II's local memory. The address for the ICR is located in the Q-bus I/O page address space and may be accessed by any device which can become Q-bus master. The ICR is byte-addressable. Since it is possible to put a maximum of 4 MicroVAX II CPUs on one Q-bus they each have their own unique ICR. Table 1 lists each processor and the associated ICR address. Table 1 - Interprocessor Communication Register Address Assignments +--------------+----------------------+----------------------------+ | Processor | 22-bit Octal Address | 32-bit Hexadecimal Address | +--------------+----------------------+----------------------------+ | Arbiter | 17 777 500 | 2000 1F40 | +--------------+----------------------+----------------------------+ | Auxiliary #1 | 17 777 502 | 2000 1F42 | +--------------+----------------------+----------------------------+ | Auxiliary #2 | 17 777 504 | 2000 1F44 | +--------------+----------------------+----------------------------+ | Auxiliary #3 | 17 777 506 | 2000 1F46 | +--------------+----------------------+----------------------------+ 1 1 1 1 1 1 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +--+-----------------+--+--+--+--+-----------+--+ | | 0 0 0 0 0 0 | | | | | 0 0 0 0 | | +--+-----------------+--+--+--+--+-----------+--+ | | | | | DMA QPE ----+ | | | | | | | | AUX HLT -------------------------+ | | | | | | DBI IE -------------------------------+ | | LM EAE ----------------------------------+ | | DBI RQ -------------------------------------------------+ Figure 3 - Interprocessor Communications Register Page 5 Bit(s) Mnemonic Meaning <15> DMA QPE DMA Q22-Bus Address Space Parity Error. This read-only bit is set if Memory System Error Register bit <04> (DMA QPE) is set. The DMA QPE bit indicates that a parity error occurred when an external device (or CPU) was accessing the MicroVAX II CPU local memory. <14:09> - Unused. Read as zeros. <08> AUX HLT Auxiliary Halt. On an auxiliary MicroVAX, AUX HLT is a read-write bit. When set, typically by the arbiter CPU, it causes the on-board CPU to transfer program control to the Halt Mode ROM Code. On an arbiter MicroVAX II, AUX HLT is a read-only bit which always reads as zero. It has no effect on arbiter CPU operation. <07> - Unused. Read as zero. <06> DBI IE Doorbell Interrupt Enable. This bit, when set, enables interprocessor doorbell interrupt requests via ICR <00>. When the on-board CPU is Q22-Bus master, DBI IE is a read-write bit. When an external device (or CPU) is bus master, DBI IE is a read-only bit. DBI IE is cleared by power up, by the negation of DCOK and by writes to the Bus Initialize Register. <05> LM EAE Local Memory External Access Enable. This bit, when set, enables external access to local memory (via the Q22-Bus map). When the on-board CPU is Q22-Bus master, LM EAE is a read-write bit. When an external device (or CPU) is bus master, LM EAE is a read-only bit. LM EAE is cleared by power up, by the negation of DCOK and by writes to the Bus Initialize Register. <04:01> - Unused. Read as zeros. <00> DBI RQ Doorbell Interrupt Request. If ICR <06> (DBI IE) is set, writing a "1" to DBI RQ sets DBI RQ, thus requesting a doorbell interrupt. If ICR <06> is clear, writing a "1" to DBI RQ has no effect. Writing a "0" to DBI RQ has no effect. DBI RQ is cleared when the CPU grants the doorbell interrupt request. DBI RQ is held clear whenever DBI IE is clear. Page 6 When a processor is interrupted via its ICR the interrupt vector is 204 (Hex). This vector is used when the interrupting device is the arbiter, auxiliary 1, auxiliary 2, auxiliary 3, or any device which may become Q-bus master. Therefore it is the responsibility of the interrupt service routine to determine which device caused the interrupt since the same vector is used no matter what device set the DBI RQ bit. This interrupt occurs at the same interrupt priority level (IPL) as IRQ4 on the Q-bus. NOTE Following such an interrupt, the MicroVAX II sets the IPL to 14 (Hex). This is different from what happens after a standard Q-bus interrupt. When a Q-bus interrupt occurs on IRQ4, the processor raises the IPL to 17 (Hex) and it is the responsibility of the interrupt service routine to lower the IPL later on. Arbiter/Auxiliary Processor Differences --------------------------------------- There are several differences between arbiter and auxiliary processors. It is important to understand these differences when configuring multiple processors into a system. 1. The arbiter MicroVAX II arbitrates bus mastership in accordance with the Q22-Bus DMA protocol. The arbitration logic is disabled on an auxiliary MicroVAX II. 2. Both the arbiter and auxiliary MicroVAX II request bus mastership via the Q22-Bus DMA Request protocol. a. They both assert BDMR on the Q22-Bus. b. The arbiter MicroVAX II receives DMGI from its arbitration logic. But an auxiliary receives DMGI from its Q22-Bus BDMGI pin. c. Only the auxiliary MicroVAX II actually asserts BSACK on the Q22-Bus. 3. The arbiter MicroVAX II asserts the Q22-Bus BINIT signal when DCOK is negated and when its CPU software writes to its Bus Initialize Register. An auxiliary MicroVAX II never asserts Q22-Bus BINIT, but receives BINIT and uses it to initialize the MicroVAX chip and to clear all internal registers which are cleared by the negation of DCOK. 4. The physical address of the Interprocessor Communication Register is different for each of the four MicroVAX II arbiter/auxiliary configurations. Page 7 5. An auxiliary MicroVAX II can be halted by setting bit <08> (AUX HLT) of its Interprocessor Communication Register. On an arbiter MicroVAX II this feature is disabled and AUX HLT is a read-only bit which always reads as zero. 6. The CPU halts are controlled by the external connector HLT ENB input. However, the external halts which are affected differ somewhat for the arbiter and auxiliary MicroVAX II modules. If the HLT ENB signal is asserted (low) the a MicroVAX II CPU will halt and enter the console program if: a. The program executes a halt instruction in kernel mode. b. The console detects a break character. c. Arbiter CPU only - the Q-bus halt line is asserted. d. Auxiliary CPU only - the Interprocessor Communication Register AUX HLT bit is set. If the HLT ENB signal is negated then: a. The halt line and break character are ignored and the ROM program responds to a halt instruction by restarting or rebooting the system. b. If the MicroVAX CPU is an auxiliary, the ROM program responds to the assertion of the ICR AUX HLT bit by rebooting. The state of the HLT ENB bit can be read by software via the Boot and Diagnostic Register. 7. Each arbiter or auxiliary MicroVAX II module can field interrupt requests from its interval timer, from its console device, and from its interprocessor doorbell. Only the arbiter MicroVAX II can field interrupts from Q22-Bus interrupt request lines IRQ7-4. 8. The arbiter asserts BIAKO on the Q22-Bus when it responds to a Q22-Bus interrupt request. An auxiliary asserts BIAKO on the Q22-Bus when it receives the assertion of BIAKI in order to pass it through to devices after it. 9. Although both the arbiter and auxiliary MicroVAX II modules contain the same time-of-year clock and battery back-up circuitry, it is assumed that the auxiliary will be configured without batteries and that its clock will never actually be enabled. This configuration will ensure a single time base for the system. If an auxiliary needs to set its time-of-year clock it can do so by referencing the arbiter's clock. 10. An arbiter processor can bootstrap from a variety of devices but an auxiliary will always boot using the ROM bootstrap protocol. See the following section for a detailed description Page 8 of the bootstrap process. Bootstrapping an Auxiliary Processor ------------------------------------ Since there are distinct differences between the operation and capabilities of arbiter and auxiliary processors, it is necessary to bootstrap them differently. An arbiter processor bootstraps in the conventional manner from one of several devices but an auxiliary boots using only one method. On power-up both processors initialize themselves and perform some self tests. At this point the primary bootstrap (VMB) begins to execute. An arbiter processor may bootstrap from any one of the following devices: 1. DU type device (RX50, RDxx, RC25 or RAxx) 2. TK50 tape 3. ROM bootstrap protocol 4. Ethernet (DEQNA) An auxiliary processor will not attempt to boot from disk, tape or ethernet. It will always boot via the ROM bootstrap protocol, which is described below. In order to synchronize the bootstrap process, after power-up and initialization an auxiliary processor will not boot until it is allowed to do so by the arbiter. The controlling device is not required to be the arbiter, it could be another auxiliary or DMA device which is bus master, but it is the most logical point of control. The following steps summarize the bootstrap procedure for a system with an arbiter and one (or more) auxiliaries: 1. Both types of processors initialize themselves after power-up. 2. Self-diagnostics execute to check out major sections of the CPU. 3. The arbiter boots from one of the four device types listed above. a. While the arbiter is booting the auxiliary completes its diagnostics and waits to start its bootstrap process. b. The auxiliary clears the valid bit in each of its Q-bus map registers to prevent accidental transfers to or from its local memory. Page 9 c. The auxiliary loops doing nothing until the AUX HLT bit in its ICR is cleared. When this bit is finally cleared, the auxiliary boots via the ROM bootstrap protocol. 4. Somewhere in the system the appropriate data structure has been created to allow the auxiliary to boot via the ROM bootstrap protocol. This can be done several ways: a. The bootstrap code is actually in ROM on an MRV11-D module. b. The bootstrap code is loaded into non-volatile RAM. c. The arbiter CPU loads the bootstrap code into its own local memory then sets up some Q-bus map registers so that this data can be seen by the auxiliary CPU over the Q-bus. This method is the most flexible since the bootstrap code can be changed easily. 5. When the arbiter is ready and knows auxiliary boot code is available, it allows the auxiliary CPU to bootstrap by clearing the AUX HLT bit in its ICR. ROM Bootstrap Protocol. To locate a PROM bootstrap, VMB searches the Q22-bus address range from high to low addresses by page (512 bytes per page) looking for readable memory. If the first six longwords of any such page contains a valid PROM "signature block" (see figure 4), VMB passes control directly to the bootstrap code in the PROM, it does not copy the PROM code to local memory for execution as it does for all other secondary bootstraps. Note that while defined as an MRV11 PROM or equivalent bootstrap, VMB does not actually require that the signature block or the bootstrap code be in PROM. It could be in ROM, nonvolatile RAM or it could be loaded into another MicroVAX II's RAM and mapped to the Q22-bus thus enabling an auxiliary to see it. RB: +---------------+---------------+---------------+---------------+ + 0: | check byte | any value | 0 | 18 (hex) | +---------------+---------------+---------------+---------------+ + 4: | any value | 1 | 0 | +-------------------------------+---------------+---------------+ + 8: | size of PROM in pages | +---------------------------------------------------------------+ + 12: | must be zero | +---------------------------------------------------------------+ + 16: | offset into PROM to start execution | +---------------------------------------------------------------+ + 20: | sum of previous three longwords | +---------------------------------------------------------------+ Figure 4: PROM Bootstrap Memory Format Page 10 RB + 0: This byte must be 18 (hex). RB + 1: This byte must be 0. RB + 2: This byte may be any value. RB + 3: This byte must be the ones complement of the sum of the previous three bytes. RB + 4: This byte must be zero. RB + 5: This byte must be 1. RB + 6: These two bytes may be any value. RB + 8: This longword contains the size in pages of the PROM. RB + 12: This longword must be zero. RB + 16: This longword contains the byte offset into the PROM where execution is to begin. RB + 20: This entry is a longword containing the sum of the previous three longwords. Configuration Rules ------------------- In order to configure multiple MicroVAX II CPUs onto one bus, 4 issues must be addressed: 1. Q-bus slot requirements for the CPU and MS630 memory boards. 2. Compatible enclosures or boxes. 3. Bus termination. 4. Using a PDP-11 CPU as the Arbiter. 1. Q-bus slot requirements. To operate properly both the MicroVAX II CPU and all versions of the MS630 memory modules MUST be inserted in Q-bus slots which feature Q-bus signals on the A/B side and the CD interconnect on the C/D side. The MicroVAX II CPU and any expansion memory modules must all be adjacent in the backplane. WARNING The MicroVAX II CPU WILL be damaged if inserted into a slot which has Q-bus signals on the C/D side. Page 11 2. Compatible enclosures or boxes. Since Q/CD slots are required, there are only 4 enclosures which are compatible with these modules. They are: a. BA23 (8 slots total, first 3 are Q/CD) b. BA123 (12 slots total, first 4 are Q/CD) c. BA11-S (9 slots total, all 9 are Q/CD) d. BA11-N (9 slots total, all 9 are Q/CD) This enclosure is electrically compatible but since it is older it is only 18-bit compatible and has not been tested for FCC compliance in a system package. Since the BA11-S is the 22-bit, updated version, the BA11-N enclosure is not recommended. 3. Bus termination. Each MicroVAX II processor has 240 ohm termination. When multiple CPUs are placed into one system, take care to abide by the Q-bus specification regarding termination and configuring multiple box systems. REFERENCE Reference MicroNote #29, entitled 'Q-bus Expansion Concepts' and appendix A of the Microsystems Handbook (P/N EB-26085-41) for more information concerning Q-bus configuration rules. The BA11-S enclosures are best suited for multiple CPUs because they have backplanes with the Q22/CD configuration in all slots. Therefore multiple CPUs and expansion memory can be accommodated most easily. The other potential boxes, the BA23 and BA123, are not as flexible because they only have 3 and 4 Q22/CD slots respectively. When using multiple MicroVAX II CPUs in one system the goal should be to configure each backplane with 120 ohm termination if the number of backplanes used is one or two. In the three backplane case, only the first and third backplanes should have 120 ohm termination. This implies that no MicroVAX II CPUs should be configured into the middle backplane of a three backplane system (three backplanes is the maximum number allowed for the Q-bus). The following configurations assume the BA11-S enclosures will be used. Two CPU System: A two CPU system is the easiest case to configure. As mentioned earlier, each CPU has 240 ohm termination. With two CPUs in the same backplane, the proper overall termination of 120 ohms is achieved. The first CPU has 240 ohms in parallel with 240 ohms on the second CPU which is 120 ohms, assuming there is no termination on the backplane (which is Page 12 true for the BA11-S enclosure). Three CPU System: A three CPU system should be configured in 2 backplanes to maintain 120 ohm termination in each. The first 2 CPUs should be configured in the first box which terminates that backplane properly as in the case above. The third CPU should be placed in the second backplane. The modules of the expansion cable set must be terminated differently. The module of the expansion cable set in the first backplane should add no additional termination to the system while the module in the second backplane should be terminated with 240 ohms. Therefore the second backplane is also terminated in 120 ohm (240 on the processor in parallel with 240 on the expansion module). Four CPU System: A four CPU system should also be configured in 2 backplanes. The first backplane will have 2 CPUs for 120 ohm termination and the second backplane will also have 2 CPUs for 120 ohm termination. But the expansion cable set connecting the two backplanes will not be the same as in the three CPU system. In this case there should be no termination on either of the expansion modules. These same basic rules should be followed if the BA23 enclosure is used. However the configurations become more constrained because of the relatively few number of Q/CD slots. The configuration also becomes more complicated because the BA23 has built in termination on the backplane (termination resistors are socketed and therefore removable). 4. Using a PDP-11 CPU as the Arbiter. The arbiter can be a Q-bus PDP-11 CPU as well as a MicroVAX II CPU. In this configuration only the 3 auxiliary MicroVAXes could be added to the system. Although there are tremendous architectural differences between a PDP-11 and MicroVAX CPU, they both perform the arbiter function on the Q-bus and therefore such a configuration is possible. Two issues arise from this 'mixed' configuration. 1. All Q-bus PDP-11s to-date have their main memory on the Q-bus. In order to talk to an auxiliary MicroVAX CPU's local memory, part of the Q-bus physical address space must be reserved for mapping to that local memory. 2. The PDP-11 processor will not have an interprocessor communication register because that feature is unique to the MicroVAX II CPU. Therefore, if it is necessary to have the capability for an auxiliary CPU to interrupt the arbiter, an additional device must be added to the system. This device will look like the interprocessor communication register for an arbiter and will convert and ICR interrupt into a conventional Q-bus interrupt (there is no capability which allows an auxiliary to interrupt the arbiter via the standard Q-bus interrupt protocol). ================================================================================ Note 27.0 Using Messages with VAXELN No replies FURILO::GIORGETTI 292 lines 21-AUG-1985 23:04 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 027 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: USING MESSAGES WITH VAXELN | Date: 19-JUN-85 | +----------------------------------------------------+-----------------+ | Originator: Christopher DeMers | Page 1 of 5 | +----------------------------------------------------+-----------------+ This Micronote discusses how VAXELN uses messages for inter-job communication. Included is an overview of the message architecture, benchmark data from MicroVAX II configurations and a sample program illustrating the message handling technique. In a VAXELN application, every job(Pascal,C or Macro-32 program) has a unique and protected virtual address space. Within a single processor, the kernel separates each job's virtual address space using the VAX memory management hardware. Within a network, each job's virtual address space is separated by virtue of the fact that the jobs may exist in the memories of different computer systems. One of the principal reasons for dividing an application into separate jobs is to aid the migration and distribution of the jobs within the network. In order for the jobs to work together on the same application, they must be able to share data, but the only way of moving data from the memory of one processor to another in a network is by packaging the data in a message and directing the network hardware to move the message to the destination memory. To make the network movement of data between jobs the same as in the non-network case, message passing is the principal means of inter-job communication. The kernel provides a number of facilities to make an efficient and transparent means of communication. The VAXELN MESSAGE object describes a block of memory that can be moved from one job's virtual address space to another's. The block of memory is called 'message data' and is allocated dynamically by the kernel from physically contiguous, page-aligned blocks of memory. A MESSAGE object and its associated message data are both created by calling the CREATE_MESSAGE kernel service. Message data is mapped into a job's P0 virtual address space, so it is potentially accessible to all the processes in the job. If a message is sent to a job on the sending job's local node, the kernel unmaps the 211 uNOTE # 027 Page 2 of 5 message data from the sending job's virtual address space and remaps it into the receiver's space. Instead of moving the data, Page Table Entries are remapped, resulting in very fast message transmission time. If a message is sent to a remote node, the kernel again unmaps the message data, but it remaps it into the appropriate network device driver job to send the message to the remote system. The reverse operations then cause the message data to be remapped in the receiver's space. The code necessary to send a message local to a machine or over the network is identical in both cases. A port name table parameter (NAME$LOCAL or NAME$UNIVERSAL) allows the programmer to define local or remote ports. The kernel maintains the local name list, while the name table for network-wide names is maintained by the name server. Names known throughout the network are guaranteed to be unique. Thus, jobs can initially be executed on one processor and later be segmented to run on multiple processors without modification of the program. Datagrams and Circuits ---------------------- Messages can be used two ways to transmit data: - One process can obtain the value of a port anywhere in the system (including other jobs) or in a different system running on a different Ethernet node. The process can send the port a message with the SEND datagram procedure. This is called the datagram method. - Any two ports (usually in different jobs) can be bound together to circuit form a circuit. In this case, having established the circuit, the sending process has one port of its own bound to another port, which usually is in a different job or on a different network node. The sender sends the message to its own port, and it is routed automatically to the other port in the circuit. Processes can both send to and receive from a circuit port. In the datagram method, as well as in the circuit method, a process can use the WAIT procedures to wait for the receipt of a message on the specified port. The datagram method requires no connection sequence as in circuits, but cannot guarantee that a message is actually received at the destination. However, it does guarantee that received messages are correct. At the cost of setting up and handling a circuit connection, circuits offer several advantages over the basic datagram method: Guaranteed delivery - Guaranteed delivery. The circuit method guarantees that either the message arrives at the destination port regardless of its location, or that the sender is notified that the message could not be delivered. 212 uNOTE # 027 Page 3 of 5 Flow control - Flow control. You can prevent a sending process from sending too many messages to a slower receiving process. If a port is connected in a circuit and is full, the sender is put into the waiting state until the port is no longer full (you can override this default). The implicit waiting performed by the SEND procedure evens the flow of messages between the transmitting process and the receiving process without having to explicitly program for the condition. Furthermore, circuits guarantee the sequence of message delivery as no other unconnected port can send a message to a connected port. Segmentation - Segmentation. Message can have any length (datagrams are limited to approx. 1500 bytes), and, if the transmission is across the network, the network services will divide the message into segments of the proper length, transmit the segments and reassemble them at the destination node. User interface - User interface via Pascal I/O routines. The OPEN procedure permits you to 'open' a circuit as if it were a file and to use the I/O routines such as READ and WRITE to transmit messages. There is no performance penalty with circuits for messages transmitted over the same network node and very little over the network. For full generality, programs should assume that the sending and receiving jobs may be distributed on different nodes in a network. Circuits are the preferred means of sending message in almost every practical case. Expedited Messages ------------------ An expedited message bypasses the normal flow-control mechanism and can be sent even if the receiving port already has its maximum number of messages. The message is received by the port before any normal data messages. The size of an expedited message is limited to a maximum of 16 bytes. Monitoring Network Integrity ---------------------------- Circuits can be used as a method for monitoring the status of a network connection. In addition to the circuit used to send data, another process could establish a secondary circuit with a process in a remote node. Neither process sends data, they only WAIT on their respective ports. When a node fails, the circuit is broken and the WAIT is satisfied. At this point exception handling routines could be invoked to handle this condition. This allows the programmer to separate the error handling code from the message transmission code. 213 uNOTE # 027 Page 4 of 5 Connecting with VAX/VMS nodes ----------------------------- The VAXELN procedure CONNECT_CIRCUIT can be used to request a connection with a VAX/VMS program on the same DECnet network. Instead of using a port as the destination for the connection, a VMS node and an object name (program name on the VMS node) is used. The program on the VMS node completes the connection by opening the "file" SYS$NET. A VAX/VMS node may also request a connection by specifying a node name and port name in the file portion of an OPEN statement. The VAXELN node complete the connection by issuing an ACCEPT_CIRCUIT statement. Performance Data ---------------- MicroVAX II, 5MB memory, connection via circuit All times in microseconds (us). Throughput in thousand bytes/second(KB/s). Delivery Message Size|Create|Delete| One Machine | Two Machines (bytes) | Time | Time |Time|Throughput| Time|Throughput ------------+------+------+----+----------+-----+---------- 0 | 131 | 144 |1094| N/A | 4479| N/A 512 | 361 | 255 |1611| 318 | 5271| 97 2048 | 450 | 274 |1885| 1087 | 8675| 236 8192 | 481 | 394 |2139| 3830 |27538| 298 214 uNOTE # 027 Page 5 of 5 PROGRAM msgsend(INPUT,OUTPUT); {++ { This program connects a circuit to the global name 'msgrecv', { sends a message to the receiver and waits for a reply. {--} VAR send_port,reply_port: PORT; msg,reply: MESSAGE; msg_data_ptr: ^VARYING_STRING(20); reply_data_ptr: ^VARYING_STRING(10); BEGIN CREATE_PORT(send_port); CONNECT_CIRCUIT(send_port, destination_name := 'msgrecv'); CREATE_MESSAGE(msg,msg_data_ptr); msg_data_ptr^ := 'message from msgsend'; SEND(msg,send_port); WAIT_ANY(send_port); RECEIVE(reply,reply_data_ptr,send_port); DELETE(reply); DISCONNECT_CIRCUIT(send_port); END; { program msgsend } PROGRAM msgrecv (INPUT,OUTPUT); {++ { This module runs a receive program that accepts a circuit,receives { a message and sends back a reply. {--} VAR reply_port: PORT; nam: NAME; msg,reply: MESSAGE; msg_data_ptr: ^VARYING_STRING(20); reply_data_ptr: ^VARYING_STRING(20); BEGIN CREATE_PORT(reply_port); CREATE_NAME(nam,'msgrecv',reply_port,table := name$universal); INITIALIZATION_DONE; ACCEPT_CIRCUIT(reply_port); WAIT_ANY(reply_port); RECEIVE(msg,msg_data_ptr,reply_port); DELETE(msg); CREATE_MESSAGE(reply,reply_data_ptr); reply_data_ptr^ := 'reply'; SEND(reply,reply_port); END; { program msgrecv } 215 ================================================================================ Note 28.0 MSV11-Q/M/J Memory Comparisons No replies FURILO::GIORGETTI 175 lines 21-AUG-1985 23:07 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 028 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: MSV11-Q/M/J MEMORY COMPARISONS | Date: 28-JUN-85 | +----------------------------------------------------+-----------------+ | Originator: JACK TOTO | Page 1 of 3 | +----------------------------------------------------+-----------------+ This MicroNote will compare three of Digital Equipment Corporation's newest memory modules. Following the description of each memory module, is a chart which, list the differences between these memories. MSV11-Q ------- The MSV11-Q has three versions, the MSV11-QA, the MSV11-QB and the MSV11-QC. The MSV11-QA (M7551-A) is a quad size Q-bus memory module and contains 1MB of MOS RAM using 64K bit parts. The MSV11-QA has two etch revisions which must be checked when configuring the module into a system. The two revisions are the C rev and the A rev, both of these revisions are discussed in the Users Guide (EK-MSV1Q-UG) and in Micronote # 030. The second version of the MSV11-Q is the MSV11-QB (M7551-B) which is a half populated quad size Q-bus memory module containing 2MB of MOS RAM using 256K bit parts. The last version of the MSV11-Q is the MSV11-QC which is a fully populated MSV11-QB quad size Q-bus memory module containing 4MB of MOS RAM using 256K bit parts. Both the MSV11-QB and the MSV11-QC use the MSV11-QA printed circuit board, however that board is ECOed to etch level C. MSV11-J ------- The MSV11-J has four versions, the MSV11-JB and MSV11-JC which are used in the PDP-11/84 UNIBUS systems and the MSV11-JD and MSV11-JE are used in either the MicroPDP-11/83 Q-bus systems, or the PDP-11/84 UNIBUS systems. All four modules use ECC memory for error correction, as well as using 256K bit MOS RAM parts on either a half or fully populated quad size module. NOTE: ----- NONE OF THE FOUR MSV11-J MODULES CAN BE PLACED IN A Q/Q BACKPLANE SLOT. IF THIS IS ATTEMPTED PERMANENT DAMAGE WILL BE DONE TO THE BOARDS AND TO THE SYSTEM. The MSV11-JB (M8637-BA) is a half populated quad size PMI memory module containing 1MB of memory. The second version of the MSV11-J is the MSV11-JC (M8639-CA), this is a fully populated MSV11-JB quad size PMI memory module containing 2MB of memory. These two modules can not be used in a Q-bus system due to gate array incompatibilities, and can only 217 uNOTE # 028 Page 2 of 3 be used in PDP-11/84 systems which use the UNIBUS/PMI bus interface (KTJ11-A). The third version of the MSV11-J is the MSV11-JD (M8639-DA) which is a half populated quad size PMI memory module containing 1MB of memory. The last version of the MSV11-J is the MSV11-JE, (M8639-EA) which is a fully populated MSV11-JD quad size PMI memory module containing 2MB of memory. These last two modules can be used with either the MicroPDP-11/83 system which uses the Q-bus/PMI bus interface or the PDP-11/84 system which was mentioned above. For details reference the PMI protocol Micronote # xxx. Although the MSV11-JD and MSV11-JE are PMI memories they can be used in two other Q-bus configurations. 1. If either of these two memories are used in slots 1 and/or 2 of a Q/CD backplane such as the H9276 (BA11-S box) or in the MicroPDP-11 BA23 backplane, and with the standard 15MHZ KDJ11-B cpu (non-fpj compatible) in slot 3, the system will perform PMI memory cycles. In the case of BA23 backplanes, a maximum of two memory modules may be used in slots ahead of the processor, with a minimum of one memory module in front of the processor still functioning as PMI memory. In the case of the H9276 backplane a number of MSV11-JD/JE memory modules may be used ahead of the processor bringing the system to a full 4MB of PMI memory. 2. If in a Q/CD or BA23 backplane the memories reside in slots 2&3 with either of the KDF11 or KDJ11 processors in the slot 1 the MSV11-J memories will respond as standard Q-bus memories, performing normal Q-bus and block mode memory cycles. This use of the MSV11-J memories is also true for the MicroVAX cpu. However the fact that the MicroVAX I cpu is a two board set requires a slightly different configuration. Slots 1&2 will be used for the MicroVAX I cpu boards with only one memory card used, that being located in slot 3 for the BA23 backplane and one or more memory cards being used for other Q/CD backplanes. The only constraint with either of the second configurations is that in the BA23 or other Q/CD backplanes no module may be placed adjacent to the MSV11-J that uses pins in the CD connector. Instead leave an empty slot between the MSV11-J and this option. An option which does not use the CD interconnect may be placed adjacent to the MSV11-J. MSV11-M ------- The MSV11-M has two versions; the MSV11-MA and the MSV11-MB. The MSV11-MA (M7506-AA) is a half populated dual sized Q-bus memory module which contains 0.5MB of MOS RAM using 256K parts. The second version the MSV11-MB (M7506-BA) is a fully populated dual size Q-bus memory module containing 1MB of MOS RAM using 256K parts. 218 uNOTE # 028 Page 3 of 3 MEMORY COMPARISON TABLE ----------------------- +-----------------------------------------------------------------------+ |ATTRIBUTE | MSV11-QA/QB/QC | MSV11-MA/MB | MSV11-JB/JC/JD/JE| +--------------+--------------------+----------------+------------------+ |MEMORY SIZE | 1MB, 2MB, 4MB | 0.5MB, 1MB | 1MB, 2MB | +--------------+--------------------+----------------+------------------+ |FORM FACTOR | QUAD | DUAL | QUAD | +--------------+--------------------+----------------+------------------+ |SYSTEM SIZE | Q18/Q22 | Q18/Q22 | PMI/CD ONLY | +--------------+--------------------+----------------+------------------+ |BLOCK MODE | YES | YES | YES (JD/JE ONLY)| +--------------+--------------------+----------------+------------------+ |BLOCK MODE | YES FOR REV-A | NO | NO | |CONFIGURABLE | NO FOR REV-C |(DEFAULT OPTION)| (DEFAULT OPTION) | +--------------+--------------------+----------------+------------------+ |AC BUS LOADS | 2.4 | 2.0 | 2.5 | +--------------+--------------------+----------------+------------------+ |DC BUS LOADS | 1.0 | 1.0 | 0.5 | +--------------+--------------------+----------------+------------------+ |AMPS @ +5 VDC | TYP MAX | TYP MAX | TYP MAX | | | QA 2.4 3.99 | MA 2.19 3.11 | JB/JD 1.5 3.94 | |(ACTIVE ONLY) | QB 2.3 3.59 | MB 2.22 3.34 | JC/JE 1.7 4.29 | | | QC 2.5 4.30 | | | +--------------+--------------------+----------------+------------------+ |AMPS @ +12VDC | NO +12V SUPPLY NEEDED | +--------------+--------------------+----------------+------------------+ |WATTS | TYP MAX | TYP MAX | TYP MAX | | | QA 12.0 20.95 | MA 11.0 16.3 | JB/JD 7.5 19.7 | |(ACTIVE ONLY) | QB 11.5 18.85 | MB 11.1 17.5 | JC/JE 8.5 21.5 | | | QC 12.5 22.58 | | +--------------+--------------------+----------------+------------------+ |MEMORY ERROR | PARITY | PARITY | ECC | |CORERECTION | | | | +--------------+--------------------+----------------+------------------+ |BATTERY BACKUP| YES FOR REV-C | YES | YES | |SUPPORT | NO FOR REV-A | | | +--------------+--------------------+----------------+------------------+ |DIAGNOSTICS |CVMSAA FOR PDP11s | SAME | CVMJA0 | | |EHXMS FOR MICROVAX | SAME | | +--------------+--------------------+----------------+------------------+ |MAINTENANCE | MP01931 | MP02053 | MP02056 | |PRINTSET | | | | +--------------+--------------------+----------------+------------------+ |USER GUIDE | EK-MSV1Q-UG | EK-MSV1M-UG | EK-MSV1J-UG | +--------------+--------------------+----------------+------------------+ 219 ================================================================================ Note 29.0 Q-bus Expansion Concepts No replies FURILO::GIORGETTI 292 lines 21-AUG-1985 23:09 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 029 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: Q-bus Expansion Concepts | Date: 24-Jun-85 | +----------------------------------------------------+-----------------+ | Originator: Charlie Giorgetti | Page 1 of 5 | +----------------------------------------------------+-----------------+ This MicroNote discusses the expansion (multiple backplanes) characteristics of a Q-bus system. Understanding this topic is critical when configuring a system. The loading, impedance, and single backplane characteristics of the Q-bus and some assumptions and definitions are discussed prior to defining the expansion rules. The specific products used in expansion are not discussed here. Viewing the Q-bus for Electrical Analysis Viewing the Q-bus for Electrical Analysis ----------------------------------------- When analyzing the Q-bus from a configuration rule standpoint the bus is treated as a transmission line. The reasons for this: o The Q-bus has voltage sources at both ends of a conductor. o When one of these voltage sources (typically a processor) changes state (a control/data signal transitioning) its effect is not seen instantaneously at the other end, but after some propagation delay. The propagation delay could result in signal reflections on the bus if it is not properly terminated or expanded. Loading Definitions Loading Definitions ------------------- The Q-bus specification defines two loading parameters used when configuring a system. These parameters, AC and DC loading, indicate the load presented to the system by individual elements on the Q-bus. A system element is either a Q-bus module or a backplane. The definition of AC and DC loads are: o AC loading is the capacitive loading added to a Q-bus system by a Q-bus module or by the backplane itself. Capacitive loading will cause bus reflections and impact signal rise and fall times. This is measured at the time the module or backplane is being designed. An AC load is 9.35 pf/signal line. o DC loading is the amount of leakage current presented to the Q-bus by an undriven signal line on a Q-bus module. This information is obtained from the specification data for Q-bus drivers and 221 uNOTE # 029 Page 2 of 5 receivers. A DC load is defined as 210 uA. The number of AC and DC loads allowed in a configuration is dictated by the number of backplanes and the termination used. This will be discussed in later sections of this MicroNote. The AC and DC values for Q-bus modules and backplanes can be found in either the Microcomputer Products Handbook (#EB-26078-41) or the Microcomponents Configuration Guide (#EB-27318-68). Backplane Configurations Backplane Configurations ------------------------ The rules that govern Q-bus system implementation must be viewed in light of the backplane arrangement used. The two supported Q-bus configurations are: single backplane or multiple backplanes. How the Q-bus is treated as a transmission line varies for these two configurations and is the foundation for the implementation rules. Impedance and Termination Characteristics Impedance and Termination Characteristics ----------------------------------------- The characteristic impedance of the Q-bus is approximately 120 Ohms. Therefore, when implementing a system (single or multiple backplane) the basic configuration is: Transmission Line Impedance = 120 Ohms +-----------------------------+ Source Backplane | | +---------+ | +----+----+ | | | | | | | +---+ | | | +-+-+ | | | S | | | | | Z | | | +-+-+ | | | +-+-+ | | | | | | | | | +-+-+ | | | +-+-+ | | | Z | | | | | S | | | +-+-+ | | | +---+ | | | | | | | +----+----+ | +---------+ | | Destination Backplane +----------+ Source (usually the processor) Far-end termination Z - Bus Termination with 120 Ohms Characteristic Impedance S - Voltage Source The transmission line in this diagram could be a single backplane or multiple backplanes connected with expansion cables. Figure 1 - General Q-bus Configuration 222 uNOTE # 029 Page 3 of 5 Q-bus Configuration - Single Backplane Q-bus Configuration - Single Backplane --------------------------------------- For the single backplane case the transmission line is the length of the etch runs on the Q-bus connector blocks and the backplane printed circuit board. This orientation has a signal generator at one end (the processor) and potentially a terminator at the far end of the bus. The length of the etch runs cannot exceed 14 inches (35.56 cm). In figure 1 the transmission line is the backplane itself. A single backplane system does not require termination if there are less than 20 AC loads. In this case the signals do not lose their integrity because the reflections, caused by the mismatched impedances, are not significant enough to disrupt bus activity. However, in a high ambient electrical noise environment, system integrity may be further insured by proper termination. The single backplane configuration requires termination if the number of AC loads is 20 or greater. The number of allowable AC loads in this case is dictated by the termination on the processor. A 120 Ohm processor can have up to 45 AC loads. A 240 Ohm processor can have up to 35 AC loads. Q-bus Configuration - Multiple Backplanes Q-bus Configuration - Multiple Backplanes ----------------------------------------- For the multiple backplane case (where the multiples are two or three backplanes) the transmission line is the cables used to interconnect the multiple backplanes. The expansion cable set consists of: o A module in the source backplane o A module in the destination backplane o Cables to connect the two modules The maximum length of the cables is 16.0 feet (4.88 meters). The length of these cables is by comparison significantly longer then the length of the Q-bus connector blocks and the backplane etch used in the single backplane case. Therefore, only the interconnect cables are considered for configuration purposes. This arrangement has a signal generator at one end and requires termination at the far end. The far end termination must reside in the last backplane of the configuration. The location of the far end termination can be any place in the last backplane, since the backplane etch runs do not enter into transmission line considerations. The lump sum termination must be 120 Ohms. The termination in the source box must also be 120 Ohms. If the processor is 240 Ohms then the expansion cable set module or the backplane printed circuit board must have 240 Ohm termination to achieve 223 uNOTE # 029 Page 4 of 5 the 120 Ohms for the lump sum load. Lump sum implies that the 120 Ohms can be achieved by one or more expansion module or backplane printed circuit board mounted terminators and its location is position independent in a given backplane. Figure 2 shows an example of how such a lump sum load can be accomplished. | | <--------------------- Expansion Cable from Backplane | | Source Backplane Slot # | | +------+ +---------------+ | +---+ +------------+ | 1 | | --+--+-- <-------|--|------- Expansion Module | +-------------------+ | with Termination (Z1) 2 | | | | | +-------------------+ | 3 | | | |<------ Printed Circuit Board . | +-------------------+ | . | | | | . | | |<-|------- Backplane . | +-------------------+ | n | | | | | +-------------------+ | Z1 * Z2 | +-+ +-+ | Lump Sum Termination = ------- | | | <---> | | | Z1 + Z2 | +-+ | +-+ | +------------+------------+ | +-------------------- Printed Circuit Board Mounted Termination (Z2) Figure 2 - Example of Lump Sum Termination in an Expanded Backplane Figure 1 shows the double backplane configuration where the expansion cable set is considered the transmission line. The far end termination is required. Figure 3 shows the three backplane configuration. Backplane #2 in figure 3 for all practical purposes is part of the expansion cable set when looking at it from an expansion point of view. The lengths of the expansion cables in multiple box configurations are strictly specified. As mentioned the maximum length of the overall cable is 16.0 feet. The minimum length is 2.0 feet (0.61 meters). Therefore, in a two backplane configuration the expansion cable must be between 2.0 and 16.0 feet. In the three backplane configuration the maximum cable length is still 16.0 feet. One of the two interconnect cables must be between 2.0 feet and 6.0 feet (1.83 meters) in length. The other interconnect cable must be at least 4.0 feet (1.22 meters) but not longer than 10 feet (3.05 224 uNOTE # 029 Page 5 of 5 meters). The difference in the two cable lengths must be 4.0 feet. The cable lengths are specified to insure that any reflections occur in the expansion cables and not in the backplane (if they happen). The etch runs on the backplane printed circuit board used in a multiple backplane configuration must be no longer than 10 inches (25.4 cm). Not all backplanes used in single configurations can be used in multiple backplane configurations. Expansion Cable Expansion Cable #1 to #2 #2 to #3 +---------+ +---------+ | | | | +---------+ | +----+----+ | +----+----+ | | | | | | | | | | +---+ | | | | | | +-+-+ | | | S | | | | | | | | Z | | | +-+-+ | | | | | | +-+-+ | | | | | | | | | | | | +-+-+ | | | | | | +-+-+ | | | Z | | | | | | | | S | | | +-+-+ | | | | | | +---+ | | | | | | | | | | +----+----+ | +----+----+ | +---------+ | | | | +---------+ +---------+ Backplane #1 Backplane #2 Backplane #3 Z - Bus Termination with a Characteristic Impedance S - Voltage Source Figure 3 - Three Backplane Q-bus Configuration Multiple backplane configurations allow 22 AC loads/backplane. Therefore, it is 44 AC loads in a two or 66 AC loads in a three backplane configuration. To avoid lumping too many AC loads together the total number of AC loads should be distributed as evenly as possible over the two or three backplanes. The entire configuration cannot exceed 20 DC loads. In summary, following the expansion rules insures proper system operation. The set of rules to be followed are dictated by the single or multiple configuration chosen and the arrangement of the termination in the system. 225 ================================================================================ Note 30.0 PMI on KDJ11-B and MSV11-J No replies FURILO::GIORGETTI 587 lines 21-AUG-1985 23:13 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 030 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: The Private Memory Interconnect | Date: 28-Jun-85 | | between the KDJ11-B and the MSV11-J | | +----------------------------------------------------+-----------------+ | Originator: Peter Kent | Page 1 of 10 | +----------------------------------------------------+-----------------+ Purpose ------- This MicroNote describes the Private Memory Interconnect on the MicroPDP-11/83 system. It is not intended to be a design guide for PMI, since no devices other than the CPU and memory will make use of it. General Description ------------------- A MicroPDP-11/83 system consists of the KDJ11-B CPU and one or more MSV11-J memories in a Q-bus backplane. The slots used for the CPU and memory use the CD interconnect. In a MicroPDP-11/83 configuration, the first 1 or 2 slots in a BA23 backplane (an 8 slot backplane with the first 3 slots Q/CD) are reserved for MSV11-J memory. The CPU is put in the third slot. The mechanical design of the signal pathways between the CPU and memory were designed to prevent accidental interference between the PMI and other devices that might be placed adjacent to the CPU and memory. It is possible to have a single 2 Mb board in slot 1 followed by the CPU in slot 2. Putting the CPU after the memory ends the PMI because the PMI signals from the CD side of the CPU board are only on the component side of the CPU board. "Private Memory Interconnect" is the addition of 14 unique signals to the Q-bus. These new signals use the CD part of the backplane in a Q-bus system for communications between the KDJ11-B CPU and one or two MSV11-J memories. Only the CPU and memory may communicate over this bus (hence PRIVATE). The Q-bus Data/Address lines are used for passsing data and addresses between the CPU and memory. All other Q-bus transactions proceed as before. The PDP-11/84 Unibus system uses the KTJ11-B Unibus Adaptor, KDJ11-B CPU, and one or two MSV11-J memories. No Q-bus devices may be configured with the PDP-11/84 system. Five of the PMI signals are used only with Unibus systems. All communications between Unibus devices and the KTJ11-B occur according to the Unibus protocol. The KTJ11-B provides the interface between PMI and Unibus protocols. This MicroNote does not explain the details of the Unibus and PMI interaction. 227 uNOTE # 030 Page 2 of 10 What is PMI? ------------ To understand PMI it is necessary to describe some of the bus cycles used by PMI and compare them with ordinary Q-bus cycles. There are 4 PMI cycles used in the MicroPDP-11/83 system: DATI - Data word input. This cycle is used to read one or more 16 bit words from memory by the CPU. DATIP - Data word input pause. This cycle is used to read one or more 16 bit words from memory by the CPU. It is often used to perform a read/modify/write cycle. DATO - Data word ouput. This cycle is used to write a 16 bit word to memory by the CPU. DATOB - Data byte output. This cycle is used to write a byte to memory by the CPU. The KDJ11-B does not perform Block Mode reads or writes with memory. Certain other Q-bus devices (such as the RDRX1 and RQDX2 controllers and RQC25) perform Block Mode DMA with MSV11-P,MSV11-Q,AND MSV11-M memories. The CPU monitors Block Mode transactions to keep its cache in order, but it has no control over such transfers once it has relinquished control of the bus to those devices. REFERENCES PMI signal definitions are listed at the end of this MicroNote. All other signal definitions are as given in the Microcomputer Products Handbook (EB 26078-41) or Microsystems Handbook (EB 26085-41). TWTBT, a Q-bus signal, is used somewhat differently during a PMI transaction than during a normal Q-bus transaction. See the definitions section for an explanation of this signal. 228 uNOTE # 030 Page 3 of 10 NOTE Few timing relationships are given here because it is not necessary for a basic understanding of PMI. The relationships that are given are a comparison to Q-bus only. The prefix "T" refers to bus driver input and "R" refers to bus receiver output. This helps to distinguish between the device which issues a particular signal and that of the receiver of the signal. If the prefix "B" is used, it denotes a general term for the signal on the bus without regard for its timing relation with respect to sender or receiver (i.e. BSYNCH). Address part of cycle --------------------- The address portion of the MicroPDP-11/83 PMI cycles is the same for all 4 PMI cycles. It is listed here first and the description of the other cycles follow. 1. For the first part of the cycle, the CPU gates ADDR, BBS7 (if the I/O page is referenced), TWTBT, and TPBYT onto the Q-bus. The combination of TWTBT and TPBYT (PMI signal) determine what type of PMI transaction will take place - see Table 1 below. These signals are asserted for a brief period after the assertion of TPBCYC. Table 1 ------- BWTBT L PBYT L Description H H DATI or DATBI Cycle H L DATIP Cycle L H DATO Cycle L L DATOB Cycle As noted above, Q-bus signals such as TWTBT are used differently during a PMI cycle. TWTBT is not normally used during a DATI cycle, for example. 2. Next, memory issues TPSSEL after receiving RADDR and RBS7. The CPU receives RPSSEL. This part of the cycle indicates that the memory is responding. 229 uNOTE # 030 Page 4 of 10 3. If the CPU was the previous bus master and the previous cycle was a Q-bus cycle, then the CPU must not assert TPBCYC or TSYNC until after the negation of TSYNC and after the negation of RRPLY. If the cycle was an interrupt service cycle, then the CPU must wait until after the negation of RRPLY. This stipulation allows for other Q-bus devices equal access to the bus. Also, if another Q-bus device was previously bus master, then the CPU must not asssert TPBCYC or TSYNC until after the negation of RSYNC - this is to make sure RRPLY is negated long enough as per Q-bus protocol. 4. Now, if RPSSEL is asserted and if RPUBMEM is negated, the PMI master proceeds with a PMI cycle. The negation of RPUBMEM indicates no that no Unibus memory is responding - in other words a Q-bus PMI cycle. Here is where the diffe- rence between Q-bus cycles and PMI cycles becomes visible. 5. The CPU asserts TPBCYC after gating TADDR, TBS7, TPBYT, and TWTBT onto the bus. The PMI master continues to gate TADDR, TBS7, and TWTBT after the assertion of TPBCYC. 6. If at this point RPSSEL is negated, the system will revert to a normal Q-bus cycle. This describes the address portion of the PMI cycle for Q-bus only systems. DATI ---- When the CPU (KDJ11-B) is accessing memory for a PMI Data In Cycle, it transfers 2 words. This takes advantage of the KDJ11-B restart overhead to load a second 16-bit word into the cache on the CPU module. Listed below equivalent Q-bus cycles are compared with PMI cycles under "Timimg Comparisons". For the read cycle, 2 data words (one after another) are latched into the MSV11-J data gate array and both words are placed on the bus. Interestingly enough, either word may be selected to be placed on the bus first. If the odd word is placed on the bus first, it is followed by the preceding even word. For example, if a word at address 17362 is selected to be placed on the bus first, the next word transferred will be from address 17360. If the even word is selected to be placed on the bus first, the next odd word is then transferred second. For example, if a word at address 17360 is selected to be placed on the bus first, the next odd word is then transferred second. For example, if a word at address 17360 is selected to be placed on the bus, the next word transferred will be at address 17362. 230 uNOTE # 030 Page 5 of 10 Using the MSV11-J memory as a normal Q-bus memory (disabling the PMI by putting it after the CPU in the bus) and performing a read cycle, 2 words will be latched into the data gate array. However, only one word is placed on the Q-bus. 1. At this point the address portion of the cycle is over. The memory gates TDATA onto the bus after the assertion of RPBCYC. 2. Immediately after RPBCYC the memory enables the parity signals TPHBPAR and TPLBPAR. 3. Memory asserts TPRDSTB immediately after the reception of RPBCYC. 4. The strobe signal TPRDSTB is negated by memory after the reception of RPBCYC. 5. The memory gates the second data word onto the bus after TPRDSTB is negated. Shortly after the parity in- formation is sent. Another advantage is realized here: the second data word is transmitted without the need of any further signals between the CPU and memory. 6. If the CPU has read 2 words, it negates TPBCYC after latching the second data word. 7. After the negation of RPBCYC memory removes TDAT from the bus. It becomes evident that there is an essential difference between normal Q-bus transactions and PMI transactions. Q-bus transactions are all based on handshaking. During a DATI Q-bus transaction, the memory responds with BRPLY after BDIN from the processor. There must be the signal between each device that the transaction has taken place. During a PMI DATI transaction, there is only a strobe signal from the memory saying that it is ready for the data. The only further communication between the memory and CPU is the actual data transfer. Only upon the transmission of the second possible data word is parity information sent along with the second data word. No other memory-CPU signalling occurs. 231 uNOTE # 030 Page 6 of 10 KDJ11-B MSV11-J ------- ------- Address Memory -------------- o Gate Address onto Address Lines ---------+ o Combination of | TPBYT and TWTBT | result in DATI Cycle +------> Decode Address o Assert BBS7 if Address -------------- is in I/O Page +------- o TPSSEL asserted shows | Memory is Selected PMI Cycle Assertion <---------+ ------------------- o TPBCYC Indicates PMI Cycle deasserts Address, BBS7 ------+ TPBYT,TWTBT Signals | Address part of +-------> Data cycle is finished ---- o TDATA, TPHBPAR, TPLBPAR (Data and Parity) is asserted onto Data Lines o Memory strobes CPU by Asserting TPRDSTB to tell CPU Data is on the Bus o The strobe signal TPRDSTB is deasserted +------- o The second data word and | parity info are put on PMI Cycle End <----------------+ the Data Lines ------------- o CPU deasserts TPBCYC to end PMI Cycle -------------+ Data | ---- +------> o Memory removes data from Bus Timing Comparisons ------------------ At this point it would be interesting to make some timing comparisons between Q-bus and PMI DATI transactions. Considering a Q-bus DATI transaction, the cycle time (timing from BSYNCH to TRPLY ignoring addressing time) is 510 ns for MSV11-M. The MSV11-M was chosen because its cycle time does not include the ECC overhead of the MSV11-J. Add to this 320 ns access time and this totals 830 ns to transfer 1 word from memory to CPU. Now, if 2 words are to be transferred in this manner, add another 300 ns due to delay between RRPLY and TSYNCH in order for other Q-bus devices access to the bus. This results in 1130 ns total 232 uNOTE # 030 Page 7 of 10 for a 2 word transfer using MSV11-M parity memory. The MSV11-J memory access time is 417 ns. This is the time from RPBCYC to PRDSTB. Fifty eight ns later, at the trailing edge of PRDSTB, the CPU receives the second data word. This means that PMI is approx. 2.5 times faster than Q-bus on 2 word reads from memory to CPU. Remember, this also accounts for the time the ECC requires to do its modified Hamming code versus the MSV11-M parity check. For each 18 bits of MSV11-J memory there are 6 bits used for ECC. This accounts for the space needed on the MSV11-J for 2 Mb of memory whereas 4 Mb is possible on the MSV11-Q on the same size board. DATO (DATOB) ------------ The CPU uses DATO to transfer a single word (or byte for a DATOB cycle) to memory. The address portion of the cycle is the same as for the DATI and is described above. 1. The CPU determines what type of cycle (DATO or DATOB) by logically combining TWTBT and TPBYT. During the address portion of the cycle, these signals were used to indicate which type of PMI cycle was selected. 2. Memory asserts TRPLY after RPBCYC. 3. After the assertion of TPBCYC, data is gated onto the bus by the CPU. 4. The CPU asserts TPWTSTB after data is gated onto the bus. 5. Memory asserts TPSBFUL after RPWTSTB. 6. The CPU deasserts TPBCYC after negating TWTSTB. 7. The memory waits before it can accept another PMI cycle (or Q-bus cycle) - then it deasserts TRPLY. 8. Memory negates TPSBFUL before it can accept another PMI (or Q-bus cycle). 233 uNOTE # 030 Page 8 of 10 KDJ11-B MSV11-J ------- ------- Address Memory -------------- o Gate Addresses onto Address Lines o Combination of TPBYT and TWTBT Result in DATO Cycle o Assert BBS7 if Address ------+ is in the I/O Page | +-------> Decode Address -------------- PMI Cycle Assertion +-------- o TPSSEL Shows ------------------- | Memory is address o Assertion of TPBCYC <-------+ selected indicates PMI Cycle o CPU deasserts Address, BBS7, TPBYT, TWTBT Signals - Address Portion of Cycle ---+ Memory Responding is finished | ----------------- +-------> o After reception of RPBCYC, memory sends Data TRPLY to CPU ---- o TDATA, TPHBPAR, TPLBPAR (Data and Parity) is put onto the Data Lines o CPU then strobes the Reception of Data Memory by asserting TPWTSTB --+ ----------------- +-------> o Memory asserts TPSBFUL after reception of +-------- RPWTSTB | PMI Cycle End <-------------+ ------------- o CPU deasserts TPBCYC to indicate current Memory Cycle End PMI Cycle is finished -------+ ---------------- +-------> o Memory waits for other devices to claim Bus before it can accept another PMI Cycle - then deasserts TRPLY o Memory must negate TPSBFUL before another PMI Cycle can begin 234 uNOTE # 030 Page 9 of 10 Timing Comparisons ------------------ Here is a comparison of a Q-bus DATO cycle with a PMI DATO cycle. Looking at a Q-bus DATO transaction, the cycle time (timing from RSYNCH to TRPLY) for MSV11-M is 550 ns. Comparing this to the MSV11-J DATO cycle, the result of 223 ns is obtained. This figure is arrived at as follows: 38 ns access time for the memory + 80 ns TPBCYC to TDATA + 75 ns TPWTSTB after data is on the bus + 30 ns to hold TPWTSB. Again the speed advantage of PMI transactions over normal Q-bus transactions is about 2.5 to 1. DATIP ----- The PMI Data In Pause cycle is identical to the DATI cycle except that TPBYT is asserted with TADDR to indicate that the next cycle (immediately following the current cycle) will be a data out cycle to the same address. PMI and Q-bus signal definitions -------------------------------- Eight of the PMI signals are used in an MicroPDP-11/83 system, therefore only those will be defined here. One Q-bus signal, BWTBT, is defined here because it is used differently than during normal Q-bus transactions. PBYT L PMI Byte. When the CPU gates address onto the bus, it asserts this signal with BWTBT to indicate the type of bus cycle (see Table 1 above). PBCYC L PMI bus cycle. The CPU asserts this signal at the start of a PMI cycle and negates it at the end of that cycle. PRDSTB L PMI read strobe. Memory asserts and negates this signal to control data transfers during DATI cycles. The CPU latches the received first word data on the negating edge of this signal. The second word is latched after that without further signalling. PWTSTB L PMI Write Strobe. The CPU asserts this signal after gating data onto the bus. The memory latches the data into its write buffer after the leading edge of this pulse. PSSEL L PMI slave selected. Memory asserts this signal whenever it decodes its address on the Q-bus. 235 uNOTE # 030 Page 10 of 10 PHBPAR L PMI high byte data parity. This signal is generated by PMI memory during DATI cycles and provides odd parity for the high byte data on the Q-bus. PLBPAR L PMI low byte data parity. This signal is generated by PMI memory during DATI cycles and provides even parity for the low byte data. PSBFUL L PMI memory buffer full. Memory asserts this signal during a write cycle indicating that its write buffer is full and that it cannot respond to another cycle request. Q-bus signal ------------ BWTBT L Write byte (PMI write indication). In Q-bus systems, this signal is used for Q-bus write cycles. For PMI transactions, the CPU gates this signal with PBYT to indicate the type of PMI cycle. See Table 1 above. References ---------- Microcomputer Products Handbook EB-26078-41 Microsystems Handbook EB-26085-41 MSV11-M User Guide EK-MSV1M-UG-001 MSV11-Q User Guide EK-MSV1Q-UG-002 MSV11-J User Guide EK-MSV1J-UG-001 236 ================================================================================ Note 31.0 MSV11-QA Revision Differences No replies FURILO::GIORGETTI 528 lines 21-AUG-1985 23:16 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 031 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: MSV11-QA Revision Differences | Date: 28-JUN-85 | +----------------------------------------------------+-----------------+ | Originator: Jack Toto | Page 1 of 9 | +----------------------------------------------------+-----------------+ Digital Equipment Corporation recently announce the addition of three memories for the Q-bus space; the MSV11-QA quad module at 1MB, the MSV11-QB quad module at 2MB, and the MSV11-QC quad module at 4MB. Earlier versions of the MSV11-QA were shipped using a revision A etch and the documentation correctly showed the jumper configurations. However early in 1985 the MSV11-QA/QB/QC started shipping with revision C etch. The documentation at that point did not show how to properly configure the C etch. It is the intent of this MicroNote to point out the differences between the two modules and to explain the configuration of both the etch revisions. The two modules can be identified in any one of the three ways listed in the table below; 1. The location and value of the modules serial number. 2. The location of CSR and address jumpers and switches. 3. The module's designation number, stamped on the insertion handles will be different. 3A. Revision A modules will be labeled M7551-AA. 3B. Revision C modules will be labeled M7551-AA. SERIAL NUMBER LOCATION ---------------------- The two modules can be identified by the location of its serial number. The revision A module will have its serial number located in the upper right hand corner of the module as you hold it with the fingers pointing down or at you and the component side facing you or up as it would lay on a work bench. This serial number will be 5017547A1. The location of the serial number for revision C module will be on the component side also, but in the upper left hand corner. This serial number will be 5017547-01-C1. The attached diagrams of the revision A and revision C modules show the location of these numbers. 237 uNOTE # 031 Pag 2 of 9 JUMPER LOCATION --------------- The MSV11-QA revision A module allows for the selection of Block Mode DMA transfers, parity detection, and extended address parity error detection as well as CSR and address selection. The address selection includes two switches, one for the modules starting address and one for the modules ending address. The ending address switch is used to control the decode logic on the module as the same etch is used for 2MB and 4MB boards as well, each with different value memory chips to reach there designed capacity. The location and function of these switches and jumpers if detailed in the diagrams and configuration tables attached to the end of this MicroNote. The MSV11-QA revision C module does not allow for the selection of Block Mode DMA or for the selection of parity detection, these features are built into the module itself and can be used or not used through hardware/software compatibility. When used in a system that supports Block Mode the MSV11-QA will perform as a Block Mode device, when used in a non Block Mode system it will perform as a normal memory module without any decrease in that system's performance. When used with software such as RSX11 and using mixed parity/non-parity memories parity detection can be disabled through sysgen. The only functions that a user is required to configure to use the MSV11-QA revision C is CSR selection and starting and ending address. It should be pointed out that the two switches for starting and ending addresses have been flip flopped from the positions in which they were located on the revision A module. Once again refer to the diagrams and configuration tables attached to this MicroNote for location and function of these switches and jumpers. The following pages contain diagrams and tables for configuring the two versions of the MSV11-QA 238 uNOTE # 031 Page 3 of 9 MSV11-QA revision A Module Identification ----------------------------------------- +-----+ +-+ +-+ +-----+ | +____________|_|___________|_|____________+ | +-----------------------------------------------------+ | | | 5017547A1 <---------+- PRINTED CIRCUIT | | BOARD NO. | | | | | | | | | (COMPONENT SIDE) | | | | | | | | | | | | | | | | | | +-+ +-+ +-+ | ++ +---+ | +-+ | +---+ | ++ | | | | | | | | +--------+ +--------+ +--------+ +--------+ (A) MSV11-QA (ETCH revision A ONLY) MSV11-QA revision A CSR SELECTION --------------------------------- NUMBER OF JUMPER POSITION CSR REGISTER MEMORY MODULE R P N M ADDRESS --------------------------------------------------------------- 1ST IN IN IN IN 17772100 2ND OUT IN IN IN 17772102 3RD IN OUT IN IN 17772104 4TH OUT OUT IN IN 17772106 5TH IN IN OUT IN 17772110 6TH OUT IN OUT IN 17772112 7TH IN OUT OUT IN 17772114 8TH OUT OUT OUT IN 17772116 9TH IN IN IN OUT 17772120 10TH OUT IN IN OUT 17772122 11TH IN OUT IN OUT 17772124 12TH OUT OUT IN OUT 17772126 13TH IN IN OUT OUT 17772130 14TH OUT IN OUT OUT 17772132 15TH IN OUT OUT OUT 17772134 16TH OUT OUT OUT OUT 17772136 239 uNOTE # 031 Page 4 of 9 MSV11-QA revision A STARTING AND ENDING ADDRESS ----------------------------------------------- DESIRED SW1 SW2 STARTING ENDING STARTING SWITCH SWITCH ENDING SWITCH ADDRESS POSITION POSITION ADDRESS POSITION ----------------------------------------------------------------------- IN KBYTE 12345 6 IN KBYTE 12345 ----------------------------------------------------------------------- 0 00000 0 128 11111 128 11111 1 256 01111 256 01111 1 384 10111 384 10111 1 512 00111 512 00111 1 640 11011 640 11011 1 768 01011 768 01011 1 896 10011 896 10011 1 1024 (1MB) 00011 1024 (1MB) 00011 1 1152 11101 1152 11101 1 1280 01101 1280 01101 1 1408 10101 1408 10101 1 1536 00101 1536 00101 1 1664 11001 1664 11001 1 1792 01001 1792 01001 1 1920 10001 1920 10001 1 2048 (2MB) 00001 2048 (2MB) 00001 1 2176 11110 2176 11110 1 2304 01110 2304 01110 1 2432 10110 2432 10110 1 2560 00110 2560 00110 1 2688 11010 2688 11010 1 2816 01010 2816 01010 1 2944 10010 2944 10010 1 3072 (3MB) 00010 3072 (3MB) 00010 1 3200 11100 3200 11100 1 3328 01100 3328 01100 1 3456 10100 3456 10100 1 3584 00100 3584 00100 1 3712 11000 3712 11000 1 3840 01000 3840 00010 1 3968 10000 3968 10000 1 4096 (4MB) 00000 1 = off position (open) 0 = on position (closed) NOTE: Switch S6 of SW1 is not used. For a memory starting address of 0, switch S6 of SW2 should be set to 0 (on). For all other starting addresses S6 of SW2 should be off (1). 240 uNOTE # 031 Page 5 of 9 MSV11-QA revision A ------------------- +-----+ +-+ +-+ +-----+ | +____________|_|___________|_|____________+ | +-----------------------------------------------------+ | 5017547A1 | | ++ +++ | | PARITY -----> ++ A+++ <-----------+- CSR REGISTER | LED ++ P+++ | SELECTION | N+++ | | M+++ | | ++ | | ++A <-------------+- ENABLE/DISABLE | ++B | CSR SELECTION | ++ | | SW1 | | ++++ | | ++++1 <------------+- STARTING ADDRESS | |++|2 | SWITCHES | |++|3 ++ | (S6 NOT USED) | |++|4 ++W1 <-----+- ENABLE/DISABLE | (COMPONENT SIDE) |++|5 ++W2 | BLOCK MODE | ++++6 ++ ++ | | OFF ON ++K <--+- ENABLE/DISABLE | ++L | EXTENDED | SW2 ++ | ERROR ADDRESS | ++++ | | ++++1 <-----+- ENDING ADDRESS | ++++2 | SWITCHES | |++|3 | | |++|4 | | |++|5 | | |++|6 | | OFF ON | | ++++ <-+- ENABLE PARITY | +5V ++++ | ERROR DETECTION | ++ JH | | ++ <------+- NOT USED, MODULE | ++ | DOES NOT SUPPORT | +5VB | BATTERY BACKUP | +-+ +-+ +-+ | ++ +---+ | +-+ | +---+ | ++ | D | | C | | B | | A | +--------+ +--------+ +--------+ +--------+ Jumper and Switch Locations (Drawing not to scale) 241 uNOTE # 031 Page 6 of 9 MSV11-QA revision C Module Identification ----------------------------------------- +-----+ +-+ +-+ +-----+ | +____________|_|___________|_|____________+ | +-----------------------------------------------------+ | | PRINTED CIRCUIT -+---------> 5017547-01-C1 | BOARD NO. | | | | | | | | | | | (COMPONENT SIDE) | | | | | | | | | | | | | | | | | | +-+ +-+ +-+ | ++ +---+ | +-+ | +---+ | ++ | | | | | | | | +--------+ +--------+ +--------+ +--------+ (B) MSV11-QA (ETCH revision C OR LATER) MSV11-QB AND MSV11-QC (Drawings not to scale) MSV11-QA revision C CSR SELECTION --------------------------------- NUMBER OF JUMPER POSITION CSR REGISTER MEMORY MODULE J5 J7 J9 J11 ADDRESS ------------------------------------------------------------------------ 1ST IN IN IN IN 17772100 2ND OUT IN IN IN 17772102 3RD IN OUT IN IN 17772104 4TH OUT OUT IN IN 17772106 5TH IN IN OUT IN 17772110 6TH OUT IN OUT IN 17772112 7TH IN OUT OUT IN 17772114 8TH OUT OUT OUT IN 17772116 9TH IN IN IN OUT 17772120 10TH OUT IN IN OUT 17772122 11TH IN OUT IN OUT 17772124 12TH OUT OUT IN OUT 17772126 13TH IN IN OUT OUT 17772130 14TH OUT IN OUT OUT 17772132 15TH IN OUT OUT OUT 17772134 16TH OUT OUT OUT OUT 17772136 242 uNOTE # 031 Page 7 of 9 MSV11-QA revision C STARTING AND ENDING ADDRESS ------------------------------------------ DESIRED SW2 SW1 STARTING ENDING STARTING SWITCH SWITCH ENDING SWITCH ADDRESS POSITION POSITION ADDRESS POSITION ----------------------------------------------------------------------- IN KBYTE 12345 6 IN KBYTE 12345 ----------------------------------------------------------------------- 0 00000 0 128 11111 128 11111 1 256 01111 256 01111 1 384 10111 384 10111 1 512 00111 512 00111 1 640 11011 640 11011 1 768 01011 768 01011 1 896 10011 896 10011 1 1024 (1MB) 00011 1024 (1MB) 00011 1 1152 11101 1152 11101 1 1280 01101 1280 01101 1 1408 10101 1408 10101 1 1536 00101 1536 00101 1 1664 11001 1664 11001 1 1792 01001 1792 01001 1 1920 10001 1920 10001 1 2048 (2MB) 00001 2048 (2MB) 00001 1 2176 11110 2176 11110 1 2304 01110 2304 01110 1 2432 10110 2432 10110 1 2560 00110 2560 00110 1 2688 11010 2688 11010 1 2816 01010 2816 01010 1 2944 10010 2944 10010 1 3072 (3MB) 00010 3072 (3MB) 00010 1 3200 11100 3200 11100 1 3328 01100 3328 01100 1 3456 10100 3456 10100 1 3584 00100 3584 00100 1 3712 11000 3712 11000 1 3840 01000 3840 00010 1 3968 10000 3968 10000 1 4096 (4MB) 00000 1 = off position (open) 0 = on position (closed) NOTE: Switch S6 of SW2 is not used. For a memory starting address of 0, switch S6 of SW1 should be set to 0 (on). For all other starting addresses S6 of SW1 should be off (1). 243 uNOTE # 031 Page 8 of 9 MSV11-QA revision C ------------------- +-----+ +-+ +-+ +-----+ | +____________|_|___________|_|____________+ | +-----------------------------------------------------+ | | | 5017547-01-C1 +++++ <--------------+-- CSR REGISTER | +++++ | SELECTION | +++++ | | | | | | | | | | SW2 | | ++++ | | ++++1 <---+- STARTING ADDRESS | ++++2 | SWITCHES | ++++3 | (S6 NOT USED) | ++++4 | | ++++5 | | ++++6 | | (COMPONENT SIDE) | | | | | | SW1 | | ++++ | | ++++1 <--------+- ENDING ADDRESS | ++++2 | SWITCHES | ++++3 | | ++++4 | | ++++5 | | ++++6 | | | | | | o o <-----+- BATTERY BACKUP | o o | JUMPERS | W2 o o W1 | | o o | | | | +-+ +-+ +-+ | ++ +---+ | +-+ | +---+ | ++ | | | | | | | | +--------+ +--------+ +--------+ +--------+ Jumpers and Switches (Drawing not to scale) 244 uNOTE # 031 Page 9 of 9 COMPARISON OF SIMILAR FUNCTION JUMPERS -------------------------------------- JUMPER SELECTABILITY ENABLED DISABLED FUNCTION REV-A REV-A CONFIGURATION CONFIGURATION ---------------------------------------------------------------------- DISABLE YES NO W1 IN (J11 TO J12) W2 IN (J11 TO J10) BLOCK MODE W2 OUT W1 OUT ----------------------------------------------------------------------- DISABLE YES NO JUMPER B IN JUMPER A IN PARITY (J14 TO 13) (J14 TO J5) MEMORY JUMPER A OUT JUMPER B OUT ----------------------------------------------------------------------- DISABLE YES NO JUMPER H IN JUMPER G IN PARITY (J2 TO J3) (J1 TO J2) DETECTION JUMPER G OUT JUMPER H OUT ----------------------------------------------------------------------- DISABLE YES NO JUMPER L IN JUMPER K IN 22-BIT (J8 TO J7) (J8 TO J9) ADDRESSING JUMPER K OUT JUMPER L OUT ----------------------------------------------------------------------- BATTERY NO YES W3 AND W1 IN W4 AND W1 IN BACKUP WITH WITH SUPPORT W4 AND W1 OUT W3 AND W1 OUT (revision C ONLY) (revision C ONLY) ---------------------------------------------------------------------- BATTERY BACKUP CONFIGURATION NOTE: JUMPERS W4 AND W2 ARE LOCATED BETWEEN E21 AND E13 IN THE LOWER RIGHT HAND CORNER OF THE COMPONENT SIDE OF THE MODULE. FOR THE ACTUAL LOCATION OF THESE AND ALL OTHER JUMPERS PLEASE REFER TO THE USERS GUIDE. 245 ================================================================================ Note 32.0 KXT11-C Parallel I/O Prog No replies FURILO::GIORGETTI 2476 lines 21-AUG-1985 23:19 -------------------------------------------------------------------------------- +---------------+ +-----------------+ | d i g i t a l | | uNOTE # 032 | +---------------+ +-----------------+ +----------------------------------------------------+-----------------+ | Title: KXT11-C Parallel I/O Programming | Date: 28-JUN-85 | +----------------------------------------------------+-----------------+ | Originator: Scott Tincher | Page 1 of 42 | +----------------------------------------------------+-----------------+ The KXT11-CA is a single board computer that provides the user with flexible I/O programming options. One of the onboard programmable devices is a 20 line parallel I/O port (PIO). This note will describe the operation of the PIO and will provide some programming examples. Since the DIGITAL operating system MicroPower/Pascal provides a device handler for the PIO, the programming examples included in this note will be written in MACRO-11 for the user who wishes to program the PIO in MACRO-11. The example programs assume the user is familiar with the KXT11-C Software Toolkit for RT-11 or RSX. FEATURES/CAPABILITIES The PIO of the KXT11-C supplies the following features: o Two 8-bit, double buffered, bidirectional I/O ports o A 4-bit special purpose I/O port o Four handshake modes o REQUEST signal for utilizing the DMA controller o Pattern recognition logic o Three independent 16-bit counter/timers The two 8-bit ports (A and B) are identical except that Port B can provide external access to Counter/Timers 1 and 2. Each port may be configured under program control as a single or double buffered port with handshake logic or as a bit port for control applications. Pattern recognition logic is also included in each port. This logic allows interrupt generation whenever a specific pattern is recognized. Ports A and B may be linked to form a 16-bit port with handshake. When Port A or B is used as a port with handshake the control lines are supplied by a special 4-bit port (Port C). If no handshake lines are required then Port C may be used as a bit port. Port C also provides external access to Counter/Timer 3 and a REQUEST line that allows the 247 uNOTE # 032 Page 2 of 42 PIO to utilize the DMA controller when transfering data. The PIO supplies three identical 16-bit Counter/Timers. These Counter/Timers operate at a frequency of 2 MHz which provides a resolution of 500 ns. Each Counter/Timer may operate with one of three output duty cycles: pulse, one-shot, or square-wave. In addition, each unit may operate as retriggerable or non-retriggerable. REGISTER DESCRIPTION The following section provides a brief description of the registers of the PIO. MASTER CONTROL REGISTERS There are two registers that control the overall function of the PIO, the Master Interrupt Control Register and the Master Configuration Control Register. Master Interrupt Control Register +-------------------------------+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------+ Address = 177000 Bit 7: Master Interrupt Enable (MIE) 0 - Inhibits this device from requesting an interrupt or responding to an interrupt acknowledge. 1 - Allows interrupt logic to operate normally. Bits 6,5,4,3,2,1: These bits must be programmed to zero. Bit 0: Reset 0 - Clears the reset bit and allows the other registers to function properly. 1 - Resets the device. While this bit is 1 reads of other registers will be 0 and writes to other registers will be ignored. This bit is cleared only by writing a 0 to the RESET bit. 248 uNOTE # 032 Page 3 of 42 Master Configuration Control Register +-------------------------------+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------+ Address = 177002 Bit 7: Port B Enable (PBE) 0 - Inhibits Port B from issuing an interrupt request and forces tth Port B I/O lines into a high impedance state. 1 - Allows Port B to operate normally. Bit 6: Counter/Timer 1 Enable (CT1E) 0 - Inhibits Counter/Timer 1 from issuing an interrupt request and clears the Count In Progress (CIP) flag. All trigger inputs are ignored. 1 - Allows Counter/Timer 1 to operate normally. Bit 5: Counter/Timer 2 Enable (CT2E) Provides the same functions for Counter/Timer 2 that CT1E does for Counter/Timer 1. Bit 4: Port C and Counter/Timer 3 Enable (PCE) and (CT3E) Provides the same functions for Port C that PBE does for Port B and the same functions for Counter/Timer 3 that CT1E does for Counter/Timer 1. Bit 3: Port Link Control (PLC) 0 - Allows Ports A and B to operate independently. 1 - Links Ports A and B to form a 16-bit port. In this mode Port A's handshake and command and status registers are used. Port B is specified as a bit port. This bit must be set before the ports are enabled. Bit 2: Port A Enable (PAE) Provides the same functions for Port A that PBE provides for Port B. Bits 1,0: Counter/Timer Link Controls These two bits specify how Counter/Timers 1 and 2 are linked according to the following table: 249 uNOTE # 032 Page 4 of 42 Bit 1 Bit 0 0 0 Counter/Timers are independent 0 1 C/T 1's output (inverted) gates C/T 2 1 0 C/T 1's output (inverted) triggers C/T 2 1 1 C/T 1's output (inverted) is C/T 2's count input The Counter/Timers must be linked before they are enabled. PORT SPECIFICATION REGISTERS Ports A and B both utilize the following port specification registers: Port Mode Specification Register +-------------------------------+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------+ Port A = 177100 Port B = 177120 A RESET forces all of these bits to 0. All bits are read/write. Bits 7,6: Port Type Select These two bits specify the port type as defined by the following table: Bit 7 Bit 6 0 0 Bit port (No handshake) 0 1 Input port with handshake 1 0 Output port with handshake 1 1 Bidirectional port with handshake Bit 5: Interrupt on Two Bytes (ITB) 0 - Indicates that Interrupt Pending (IP) should be set when one byte of data is available for transfer. For an input port IP is set when the Input Data Register is full. For an output port IP is set when the Output Data Register is empty. 1 - Indicates that IP should be set when two bytes of data are available for transfer. For an input port IP is set when both the Input Data Register and the Input Buffer Register are full. For an output port IP is set when both the Output Data Register and the Output Data Buffer are empty. This bit must be set to zero for ports specified as bit ports, single-buffered ports, or bidirectional ports. 250 uNOTE # 032 Page 5 of 42 Bit 4: Single Buffered (SB) 0 - Indicates that the port is double-buffered. 1 - Indicates the the port is single-buffered. This bit is always 0 for bit ports. Bit 3: Interrupt on Match Only (IMO) 0 - Port operates normally. 1 - An interrupt is generated when the data moved into the Input Data Register or out of the Output Data Register matches the pattern specification. Bits 2,1: Pattern Mode Specification Bits These bits define the operation of the pattern recognition logic as shown by the following table: Bit 2 Bit 1 0 0 Disable Pattern Match 0 1 AND Mode 1 0 OR Mode 1 1 OR-Priority Encoded Vector Mode Bit 0: Latch on Pattern Match (LPM) or Deskew Timer Enable (DTE) When a port is used as a bit port the LPM function is used. When a port with handshake is used the DTE function is used. LPM: 0 - Pattern matches are detected but the data read from the port follows the port pins. 1 - When a pattern match is detected the input data at the port is latched. DTE: 0 - The deskew timer is not activated. 1 - The deskew timer is activated to perform delay functions as set in the Port Handshake Specification Register. Port Handshake Specification Register +-------------------------------+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------+ Port A = 177102 Port B = 177122 251 uNOTE # 032 Page 6 of 42 These bits are ignored if the port is a bit port. A RESET forces all bits to 0. All bits are read/write. Bits 7,6: Handshake Type Specification Bits These bits define the type of handshake a port will use as shown by the following table: Bit 7 Bit 6 0 0 Interlocked Handshake 0 1 Strobed Handshake 1 0 Pulsed Handshake 1 1 3-Wire Handshake The Pulsed and 3-Wire Handshakes must not be specified for bidirectional ports. Only one port at a time may use the Pulsed Handshake. If one port uses the 3-Wire Handshake the other port must be specified as a bit port. Bits 5,4,3: REQUEST/WAIT Specification Bits (RWS) The WAIT function is not implemented on the KXT11-C. These bits define the utilization of the REQUEST line as shown by the following table: Bit 5 Bit 4 Bit 3 0 0 0 REQUEST disabled 0 0 1 Not supported 0 1 1 Not supported 1 0 0 Special REQUEST 1 0 1 Output REQUEST 1 1 1 Input REQUEST Only Port A may use the REQUEST capability - Port B must be programmed as a bit port. Bits 2,1,0: Deskew Time Specification Bits These bits specify the amount of deskew time to be provided for output data. They define the minimum number of Peripheral Clock (PCLK) cycles of delay between the output of a new byte of data and the handshake logic indicating that new data is available. PCLK = 250 ns. 0 PCLK cycles are chosen by setting DTE=0 in the Port Mode Specification Register. 252 uNOTE # 032 Page 7 of 42 Bit 2 Bit 1 Bit 0 PCLK cycles 0 0 0 2 0 0 1 4 0 1 0 6 0 1 1 8 1 0 0 10 1 0 1 12 1 1 0 14 1 1 1 16 Port Command and Status Register +-------------------------------+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------+ Port A = 177020 Port B = 177022 A RESET forces ORE to 1 and all other bits to 0. All bits are readable and four are writeable. Bit 7: Interrupt Under Service (IUS) 0 - Cleared to indicate that the port is not servicing an interrupt. 1 - Indicates that that the port has been recognized by an interrupt acknowledge sequence. Bit 6: Interrupt Enable (IE) 0 - Interrupt logic disabled. The port is unable to request an interrupt or to respond to an interrupt acknowledge. 1 - Interrupt logic operates normally. Bit 5: Interrupt Pending (IP) 0 - Cleared to indicate that the port does not require service. 1 - Set to indicate the port needs service because of a pattern match, a handshake, or an error. Bits 7, 6, and 5 are written using the following codes: 253 uNOTE # 032 Page 8 of 42 Bit 7 Bit 6 Bit 5 0 0 0 Null code 0 0 1 Clear IP and IUS 0 1 0 Set IUS 0 1 1 Clear IUS 1 0 0 Set IP 1 0 1 Clear IP 1 1 0 Set IE 1 1 1 Clear IE Bit 4: Interrupt Error (ERR) This bit is set to 1 when using a a bit port with pattern match enabled if a second match occurs before the previous match is acknowledged. This is a read-only bit. Bit 3: Output Data Register Empty (ORE) A status bit that indicates when an output port's Output Data Register is empty. This bit can only be cleared by writing to the data register. This is a read-only bit. Bit 2: Input Data Register Full (IRF) A status bit that indicates if an input port's Input Data Register is full. This bit can only be cleared by reading the Input Data Register. This is a read-only bit. Bit 1: Pattern Match Flag (PMF) If the port pattern match logic is enabled this bit will indicate when a match is detected. This bit is read-only. Bit 0: Interrupt on Error (IOE) 0 - Disables the generation of an interrupt if an error occurs within the pattern match logic. 1 - Enables the generation of an interrupt if an error occurs within the pattern match logic. This bit is valid only for bit ports with pattern match logic enabled. It is ignored by ports with handshake and should be programmed to 0. BIT PATH DEFINITION REGISTERS Each port has a set of these registers. Only the four least significant bits are valid in the port C registers. 254 uNOTE # 032 Page 9 of 42 Data Path Polarity Registers These registers define whether the bits in a port are inverting or non-inverting. These bits are cleared by a RESET and are read/write. +-------------------------------+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------+ Port A = 177104 Port B = 177124 Port C = 177012 0 = Non-inverting 1 = Inverting Date Direction Registers These registers are ignored by ports with handshake. For bit ports they define the data direction for each bit. These bits are cleared by a RESET and are read/write. +-------------------------------+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------+ Port A = 177106 Port B = 177126 Port C = 177014 0 = Output bit 1 = Input bit Special I/O Control Registers These registers supply special characteristics to the port's data paths. A RESET clears all bits to 0. All bits are read/write. +-------------------------------+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------+ Port A = 177110 Port B = 177130 Port C = 177016 0 = Normal Input or Output 1 = Input with 1's catcher 255 uNOTE # 032 Page 10 of 42 PATTERN DEFINITION REGISTERS These registers are used collectively to specify the match pattern for a port. A RESET clears all bits to 0. All bits are read/write. Pattern Polarity Registers (PPR) +-------------------------------+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------+ Port A = 177112 Port B = 177132 Pattern Transition Registers (PTR) +-------------------------------+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------+ Port A = 177114 Port B = 177134 Pattern Mask Registers (PMR) +-------------------------------+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------+ Port A = 177116 Port B = 177136 The pattern specification for each bit is shown in the following table: PPR PTR PMR 0 0 0 Bit masked off 0 1 0 Any transition 1 0 0 Zero 1 0 1 One 1 1 0 One to zero transition 1 1 1 Zero to one transition PORT DATA REGISTERS Ports A and B have a data path that consists of three registers: an Input Data Register, and Output Data Register, and a Buffer Register. The Buffer Register is used to buffer the input or output data of a port with handshake. It is also used by bit ports to latch data when pattern matching is enabled. 256 uNOTE # 032 Page 11 of 42 Port A and B Data Registers +-------------------------------+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------+ Port A = 177114 Port B = 177134 The Port C data register consists of two registers: an Input Data register and an Output Data register. Because Port C is only 4 bits wide the least significant four bits of the data register are used for the data path. The four most significant bits are used as a write- protect mask for the four least significant bits. Port C Data Register +-------------------------------+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------+ | | | | ^ ^ ^ ^ | | | | | | | | | | | +---|---|---|---+ | | +-------|---|---+ | +-----------|---+ +---------------+ Bits 7,6,5,4: 0 = Writing of corresponding LSB enabled 1 = Writing of corresponding LSB inhibited Port C = 177036 COUNTER/TIMER CONTROL REGISTERS Each counter/timer has a set of Counter/Timer Control registers to specify the operation of the counter/timers. Counter/Timer Mode Specification Registers These registers define the mode of operation for the counter/timers and specify the external control and status lines to provide for it. A RESET clears all bits to 0. All bits are read/write. +-------------------------------+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------+ Counter/Timer 1 = 177070 Counter/Timer 2 = 177072 Counter/Timer 3 = 177074 257 uNOTE # 032 Page 12 of 42 Bit 7: Continuous/Single Cycle 0 - When the counter reaches 0 the countdown sequence is terminated. 1 - When the counter reaches 0 the time constant value is reloaded and the countdown sequence is repeated. Bit 6: External Output Enable (EOE) 0 - No external access. 1 - The output of the counter/timer is available on the I/O pin associated with that counter/timer. (See table 2 for pin assignments.) Bit 5: External Count Enable (ECE) 0 - No external access. 1 - The I/O line of the port associated with the counter/timer is used as an external counter input. (See table 2 for pin assignments.) Bit 4: External Trigger Enable (ETE) 0 - No external access 1 - The I/O line of the port associated with the counter/timer is used as a trigger input to the counter/timer. (See table 2 for pin assignments.) Bit 3: External Gate Enable (EGE) 0 - No external access 1 - The I/O line of the port associated with the counter/timer is used as an external gate input to the counter/timer. This allows the external line to suspend/continue the countdown in progress by toggling the line. (See table 2 for pin assignments.) Bit 2: Retrigger Enable Bit (REB) 0 - Triggers (external or internal) that occur during a countdown sequence are ignored. 1 - Triggers that occur during a countdown sequence cause a new countdown to begin. Bits 1,0: Output Duty Cycle Selects These two bits select the output duty cycle as shown in the following table: 258 uNOTE # 032 Page 13 of 42 Bit 1 Bit 0 0 0 Pulse Output 0 1 One-Shot Output 1 0 Square Wave Output 1 1 Do not use See figure 2 for a description of each output duty cycle. Counter/Timer Command and Status Registers Each counter/timer contains a command and status register for controlling the operation of the counter/timer. A RESET clears all bits to 0. +-------------------------------+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------+ Counter/Timer 1 = 177024 Counter/Timer 2 = 177026 Counter/Timer 3 = 177030 Bit 7: Interrupt Under Service (IUS) The operation of the this bit is the same as the IUS bit described on page *. Bit 6: Interrupt Enable (IE) The operation of the this bit is the same as the IE bit described on page *. Bit 5: Interrupt Pending (IP) This bit is set to 1 to indicate that the counter/timer needs to be serviced. It is automatically set to 1 each time the counter/timer reaches its terminal count. The IUS, IE, IP bits are written by using the codes shown in the following table: Bit 7 Bit 6 Bit 5 0 0 0 Null code 0 0 1 Clear IP and IUS 0 1 0 Set IUS 0 1 1 Clear IUS 1 0 0 Set IP 1 0 1 Clear IP 1 1 0 Set IE 1 1 1 Clear IE 259 uNOTE # 032 Page 14 of 42 Bit 4: Interrupt Error (ERR) This bit is set to indicate that the counter/timer has reached a terminal count before the previous terminal count has been serviced. Bit 3: Read Counter Control (RCC) Writing this bit to a 1 causes the contents of the Counter/Timer Current Count Register (CCR), which normally follows the down- counter, to be frozen until the least-significant byte of the CCR is read. Bit 2: Gate Command Bit (GCB) 0 - Halts the countdown sequence. 1 - Starts or resumes the countdown sequence. Bit 1: Trigger Command Bit (TCB) When written with a 1, this bit causes the down-counter to be loaded with the time constant value and a countdown sequence to be initiated. Bit 0: Count in Progress (CIP) This status bit is set to 1 to indicate that a countdown sequence is in progress. It is automatically set to 0 when the down-counter reaches 0. Counter/Timer Time Constant Registers These registers contain the time constant value that is loaded into the down-counter when a trigger is detected. These registers are 16 bits wide and are accessed as two 8-bit registers. (Bit 7 of the most-significant byte is bit 15 of the Time Constant register). A RESET does not effect these registers. Bit 15 Bit 0 <------------- MSB -------------> <------------- LSB -------------> +-------------------------------+ +-------------------------------+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------+ +-------------------------------+ Counter/Timer 1 MSB = 177054 Counter/Timer 1 LSB = 177056 Counter/Timer 2 MSB = 177060 Counter/Timer 2 LSB = 177062 Counter/Timer 3 MSB = 177064 Counter/Timer 3 LSB = 177066 260 uNOTE # 032 Page 15 of 42 Counter/Timer Current Count Registers These 16-bit registers follow the contents of the appropriate down- counter until a 1 is written into the RCC register. At that time the contents of the CCR are frozen until the least-significant byte of the CCR is read. A RESET forces the CCR to follow the down-counter again. Bit 15 Bit 0 <------------- MSB -------------> <------------- LSB -------------> +-------------------------------+ +-------------------------------+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------+ +-------------------------------+ Counter/Timer 1 MSB = 177040 Counter/Timer 1 LSB = 177042 Counter/Timer 2 MSB = 177044 Counter/Timer 2 LSB = 177046 Counter/Timer 3 MSB = 177050 Counter/Timer 3 LSB = 177052 INTERRUPT RELATED REGISTERS These registers contain the interrupt vectors output during an interrupt acknowledge sequence. Registers are provided for Port A, Port B, one to be shared by the Counter/Timers. Another register is provided to indicate which devices need service in a polled environment. Interrupt Vector Registers These vectors contain the vector output when the source of an interrupt is acknowledged. If Master Interrupt Enable = 1 then the vector register returns status when read according to the following table: Port Vector Status OR-Priority Encoded Vector Mode: Bit 3 Bit 2 Bit 1 x x x Encodes the number of the highest-priority bit with a match All other modes: Bit 3 Bit 2 Bit 1 ORE IRF PMF Normal 0 0 0 Error Counter/Timer Status Bit 2 Bit 1 0 0 Counter/Timer 3 0 1 Counter/Timer 2 1 0 Counter/Timer 1 1 1 Error 261 uNOTE # 032 Page 16 of 42 +-------------------------------+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------+ Port A = 177004 Port B = 177006 Counter/Timers = 177010 The native firmware of the KXT11-C initializes these interrupt vectors to the following values: Port A = 200 Port B = 204 Counter/Timers = 210 Current Vector Register When read, this register returns the interrupt vector that would have been output by the device during an interrupt acknowledge cycle if its IEI input had been high. The vector returned corresponds to the highest priority IP independent of IUS. The order of priority is: Counter/Timer 3, Port A, Counter/Timer 2, Port B, Counter/Timer 1. If no enabled interrupts are pending, a pattern of ones is returned. This is useful in a polled environment. +-------------------------------+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +-------------------------------+ Address = 177076 I/O BUFFER CONTROL REGISTER The PIO chip is protected from the connector by a set of buffers. These buffers comply with the IEEE 488 electrical standards. The buffers allow the ports to configured as inputs or outputs. They also allow the ports to be configured as open collectors or active pull-ups. +---------------------------------------------------------------------+ | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +---------------------------------------------------------------------+ Address = 177140 Bit 15: PCTT (Cleared on RESET) 0 - Configures the Port C drivers for open collector 1 - Configures the Port C drivers for active pull-up 262 uNOTE # 032 Page 17 of 42 Bit 14: PABTT (Cleared on RESET) 0 - Configures the Port A and B drivers for open collector 1 - Configures the Port A and B drivers for active pull-up Bits 13:10: PC DIR (Cleared on RESET) 0 - Port C bit is a receiver 1 - Port C bit is a driver Bit 9: PAHN DIR (Cleared on RESET) 0 - Port A high nibble bits (4:7) are receivers 1 - Port A high nibble bits are drivers Bit 8: PALN DIR (Cleared on RESET) 0 - Port A low nibble bits (0:3) are receivers 1 - Port A low nibble bits are drivers Bits 7:0: PB DIR (Cleared on RESET) 0 - Port B bit is a receiver 1 - Port B bit is a driver PROGRAMMING THE I/O PORTS This section will describe how to program the I/O ports and provide example programs. In particular this section will describe how to use the I/O ports in the following modes: as bit ports, as ports with handshake, in 16-bit linked mode, and with the DMA controller. The use of the pattern recognition logic will also be discussed. Programming the I/O Ports as Bit Ports Using the I/O ports as bit ports provides up to 20 lines for control and status. Each bit in ports B and C may be independently configured to be an input or an output. Port A must be configured on a nibble (4-bit) basis. Programming the PIO as a bit port is straight-forward. First, the Port Mode Specification Register is used to select the port as a bit port with/without pattern matching. Then the Bit Path Definition Registers are used to determine the polarity, direction, and special characteristics of the bits of the port. If pattern recognition is enabled the Pattern Definition Registers must also be initialized. It is then a simple matter to write to the output data buffer to provide the correct control signals and to read the input data buffer to monitor status. 263 uNOTE # 032 Page 18 of 42 The following program provides an example for using the PIO in the bit mode: .TITLE PIO1.MAC ;+ ; This program provides an example of how to program the PIO's ; I/O ports as bit ports. This program utilizes the PIO ; loopback connector (Part #H3021 or 54-16227) which makes the ; following connections: ; ; A0 -- B0 ; A1 -- B1 ; . ; . ; A7 -- B7 ; C0 -- C3 ; C1 -- C2 ; ; After this program has been assembled and linked on the ; development machine use the KUI utility of the KXT11-C Software ; Toolkit to load the program into the KXT11-C to execute as ; shown in this example: ; ; SET 2 ; LOAD PIO1.SAV ; EXECUTE ; !ODT ; ! ; !001152 ; !R2/000000 ; !1154/04