INTRODUCTION The rtVAX 300 is a realtime target processor that is adaptable to running applications that benefit from a fully supported network connection. Designed to be embedded in a robust computing network, the rtVAX 300 processor is a 117 mm x 79 mm (4.61 in. x 3.11 in.) module encapsulated in a black painted metallic cover. The rtVAX 300 processor is intended to work in the following situations: • Distributed applications that are part of a Digital computing network • Customized, embedded, standalone hardware • Remote data acquisition and computing platform that can be linked to use Digital data communication message protocol (DDCMP) serial lines • Applications that use proprietary I/O buses and industry-standard buses, such as the VME bus or the IBM PC/AT • Applications that interface with industry-standard LSI/VLSI peripherals chips The rtVAX 300 processor is the basic hardware element that you extend to handle your application, adding only the memory and I/O devices that you need. Many facets of the final system, from memory and I/O to power and packaging, are under your control. When a Signetics 2681 dual universal asynchronous receiver/transmitter (SCN 2681 DUART) serial-line chip is added to its configuration, the rtVAX 300 processor can support a console terminal. OVERVIEW Central Processor The central processor is implemented by using Digital’s CVAX chip. This chip contains about 180,000 transistors and supports full VAX memory management and a 4G-byte virtual address space. The CVAX chip contains all VAX visible general-purpose registers (GPRs), a 1K-byte instruction/data cache, all memory management hardware, including a 28-entry translation buffer, and several system registers - such as the cache disable register (CADR), memory system error register (MSER), and system control block base register (SCBB). Floating-Point Accelerator The floating-point accelerator is implemented by the CVAX floating-point accelerator (CFPA) chip. The CFPA chip contains about 60,000 transistors and execute 70 floating-point instructions. The CFPA chip receives operations code information from the CVAX chip and receives operands directly from memory or from the CVAX chip. The floating-point result is always returned to the CVAX chip. Ethernet Coprocessor The rtVAX 300 processor contains the second-generation Ethernet coprocessor (SGEC) chip and can pass data and instructions to and from other stations on a network without processor intervention. The Ethernet coprocessor has the following attributes: • Supports ThinWire and thickwire Ethernet interfaces to the rtVAX 300 processor1 • Contains 16 control and status registers (CSRs) that control its operations • Resets hardware and software and handles interrupts • Supports the full IEEE 802.3 frame encapsulation and media access control • Supports three levels of testing and diagnostics System Support Functions System support functions provided by the rtVAX 300 processor include: • Halt/boot-request arbitration logic • Interval timer with 10 ms interrupts • Flexible interface to the rtVAX 300 processor’s DAL bus • Ethernet thickwire connections • Control logic to attach a console terminal Resident Firmware Resident firmware consists of 256K bytes of ROM. Firmware gains control when the processor halts; it contains programs that provide the following services: • Board initialization • Power-up self-testing of the rtVAX 300 processor and its attached memory system • Emulation of a subset of the VAX standard console (automatic/manual bootstrap and a simple command language for examining/altering the state of the processor) • Booting from ROM, network, or DECnet DDCMP The rtVAX 300’s firmware interface is extensible: you can use it to add your own power-up initialization and self-test diagnostics. TECHNICAL SPECIFICATIONS Architecture Summary Based on Digital’s CVAX microprocessor chip, the rtVAX 300 processor contains an Ethernet coprocessor, a floating-point accelerator, an interval timer, control logic, and a diagnostic and boot ROM. Figure 2-1 shows a block diagram of the rtVAX 300 processor. 1 Ethernet is synonymous with IEEE 802.3; ThinWire, with IEEE 802.3 10BASE2; thickwire, with IEEE 802.3 10BASE 5 The rtVAX 300 processor provides a common interface to the user logic as close to the CVAX microprocessor bus interface as possible. The rtVAX 300 processor can access up to 510M bytes of physical memory; 256M bytes are read/write memory, and 254M bytes are read/only memory. All memory is directly accessible by its Ethernet coprocessor and is cacheable by the CVAX. The rtVAX 300 also provides access to 512M bytes for I/O space. Accesses in I/O space are not cached. Figure 2-1 rtVAX 300 Block Diagram CLKA CLKB CLKIN CLK20 Interrupt Arb. Logic BM and CSDP Buffers CVAX Ethernet Coprocessor SIA DAL Bufers DMA Arb. Logic Buff System and NI ROMs Boot Reg. Decode Logic Buff CFPA CPU and CFPA The processor on the rtVAX 300 is Digital’s CVAX chip with its associated CVAX floatingpoint accelerator (CFPA). The rtVAX 300 runs VAXELN software based on the VAX instruction set. The VMS and ULTRIX operating systems are not supported on the rtVAX 300 ROM and Reserved Memory Locations The upper 2M bytes of memory space are reserved for Digital. The lowest 2M bytes of I/O space are the rtVAX 300 local register I/O space intended for the user. The rtVAX 300 processor stores in I/O space its self-diagnostic routines, console emulation program, other routines that it needs to boot bootstrap-console serial-line unit (SLU), and board-level initialization and diagnostic ROMs can also use a portion of this I/O space. Network Interface The Ethernet controller, or Network Interface (NI),connects the rtVAX 300 processor to the Ethernet. It consists of the Ethernet coprocessor, which interfaces to the CVAX chip data and address line (DAL) bus and he serial interface adapter (SIA), to allow users to connect to Ethernet. Details of the connection to thickwire and ThinWire Ethernet are in Chapter 7. The Ethernet coprocessor can perform direct memory access (DMA) to any location in memory space. This controller is programmed by reading from, and writing to, a set of registers in the Ethernet coprocessor, SGEC. Minimum Hardware Configuration The rtVAX 300 processor is a platform that requires additional hardware to be usable. The following two sections list the minimum hardware requirements needed for the rtVAX 300 processor. System RAM The rtVAX 300 processor contains no RAM; however, in order for the rtVAX 300 processor to run its power-on self-test diagnostics successfully and issue the console program prompt, the processor needs at least 64K bytes of RAM. Under DECnet Phase IV, at least 512K bytes are needed to boot a VAXELN system image with the Ethernet driver, local and remote debuggers, and a 200K-byte user application. Console The rtVAX 300 processor needs no console; however, a console port is required in order for the processor to use the console emulation program, report errors and warnings, and display system crashes. HARDWARE ARCHITECTURE Central Processor The central processor of the rtVAX 300 supports the CVAX chip subset (plus six additional string instructions) of the VAX instruction set and data types and full VAX memory management. It is implemented by a single VLSI chip called the CVAX. Floating-Point Accelerator The floating-point accelerator is implemented in a single VLSI chip. Cache Memory To maximize CVAX processor performance, the rtVAX 300 incorporates a 1K-byte cache implemented with the CVAX chip. FIRMWARE System Firmware ROM Format The base rtVAX 300 firmware is contained in four 8-bit-wide ROMs; this provides a full 32-bit memory data path. System firmware ROMs require two types of information: some information is required on a per-byte basis for ease of manufacture and development; the bulk of the information (software and tables) is supplied by the set of ROM parts. System Firmware Entry The firmware checks for a power-on entry to see if it should execute the power-on self-test. The firmware then passes control to the dispatch code, which examines, and dispatches according to, the halt code set by the hardware at entry, the halt action fields stored internally, and the restart in progress and bootstrap in progress bits. Console Program The console program operates an optional user-supplied terminal through the Signetics 2681 Serial-Line Unit chip or its equivalent. Entity-Based Module and Ethernet Listener The Ethernet maintenance operations protocol (MOP) module supports MOP Version 3 and Version 4 functions. The Ethernet listener polls the Ethernet subsystem for receipt of packets. Once a packet has been received, the listener code inspects the packet protocol in order to determine the actions to take. Important protocols are as follows: • MOP loopback packet for Ethernet connectivity testing. The listener forwards or loops back a MOP loopback packet. • DECnet SYSID request packet for sizing the network. The listener generates a DECnet SYSID. • Ethernet counters request packet for checking the performance of the system on the Ethernet. The listener generates an Ethernet counters packet. • DECnet bootstrap trigger packet for forcing the rtVAX 300 system to enter its bootstrap sequence. Remote trigger must be enabled, in order to initiate the bootstrap process. The listener processes a down-line loaded system image. • DECnet assistance volunteer packet for the case where the console program has failed an attempt at booting over the Ethernet. Startup Messages The console displays messages and menus, some during power-up and others when the operator issues commands at the console terminal. The latter depend on entries in the console memory. Diagnostic Test List Tests are listed in the order they are executed upon restart. Each test has the following features: • When called from the console, it supports loop-on-test, loop-on-error, halt-on-error, and continue-on-error. • It has two levels of subtests: - the functional unit of the device under test - the particular function of the subunit being tested System Scratch RAM The rtVAX 300 system firmware acquires a number of pages of RAM memory at power-on initialization. These pages are marked "bad" in the memory bitmap to prevent higher-level software from modifying their data indiscriminately. User-Defined board-Level Boot and Diagnostic ROMs An optional, user-defined initialization routine and up to seven user-defined self-test routines can be located in user ROM. This 32-bit-wide user ROM is optional and is not necessary for the normal operation of the firmware initialization and self-test routines. On power-up, the firmware runs preliminary self-tests and then checks to see if a ROM exists. If a ROM responds to that address, the console program checks for a user-supplied ROM initialization routine in user ROM before executing the full self-tests. If the routine is found, the ROM initialization routine is called. Once the rtVAX 300 firmware regains control from the user ROM initialization routine, the rtVAX 300 completes it self-test. Creation and Down-Line Loading of Test Programs You can write simple test routines, down-line load their executable files to the rtVAX 300, and run them. ROM Bootstrap Operations The ROM bootstrap allows an rtVAX 300 system to execute either out of ROM or out of RAM, after the system image has been copied from ROM to RAM. You can specify which RAM bootstrap to use in any of the following ways: • By selecting a boot action in the boot register at power up • By using the BOOT command and explicitly specifying any of the ROM boot devices • By overriding the default boot action in the BOOTDEV register through software MEMORY The system performance of the rtVAX 300 system is linked to the performance of the memory system. Most bus cycles are used to access memory, because memory contains both the application instructions and data that the rtVAX 300 is processing. In turn, the rtVAX 300 memory system performance depends on the speed or access time of the RAM memory devices used. In general. the cost of memory devices is directly proportional to their speed and size. Static RAMs generally provide the fastest access time; however, they are more costly and less dense than dynamic RAMs (DRAMs). The memory system speed must be weighed against the cost of the memory elements to determine the type of memory devices which are used. To improve its performance, the rtVAX 300 processor contains a 1K-byte cache. This cache has a very high hit rate (greater than 70% for some applications) and allows the rtVAX 300 to read a longword in one microcycle. This cache helps to provide very high performance with relatively slow external memory, by satisfying many of the required processor read operations in one microcycle. The best processor performance is still realized with the fastest memory system, so the memory system should be designed to be as fast as practicable. Static and Dynamic RAMs The memory system can be constructed from either static or dynamic RAMs. Dynamic RAMs provide more storage at a lower cost per bit than static RAMs, and they also require less PC board space for the same density. Static RAMs store data more reliably than dynamic RAMs, because the data is stored in a latch and not as a charge on a capacitor. Static RAMs have faster access time than dynamic RAMs. Dynamic RAMs require refresh cycles to retain the stored data and also required address multiplexing and precise strobe timing. These requirements complicate the design of a memory controller for DRAMs. Once the size of the external memory system has been determined, the type and speed of the memory elements must be defined after weighing all of the factors mentioned above. If performance is the only issue and cost and size are less important, fast static RAMs are the better choice. If cost, size and power consumption are big concerns, dynamic RAMs are the better choice. For most applications, the slower, less expensive DRAMs are a good choice, because the rtVAX 300 performance is greatly enhanced by its internal cache. Basic Memory Interface The rtVAX 300 can access up to 256M bytes of physical memory and up to 510M bytes of memory-mapped I/O. The device address is first multiplexed onto the DAL bus, and the data is then transferred through that same bus. This reduces the number of external pins on the rtVAX 300 processor module; however, it requires the addition of external latches to store the device address for the duration of the bus cycle. CONSOLE AND BOOT ROM INTERFACE Console System Interface The rtVAX 300 processor module does not contain an internal console serial-line unit (SLU); however, 16 console registers are reserved in the rtVAX 300 processor reserved space to select and program an external Signetic 2681 console dual universal asynchronous receiver/transmitter. Booting From External ROM The default booting device for the rtVAX 300 is the network. When the rtVAX 300 initializes after a power-on reset, it sends the maintenance operation protocol (MOP) message over the network. The host system responsible for booting the rtVAX 300 receives these MOP requests and begins to down-line load the ELN system file to the rtVAX 300. Once this file is loaded into the rtVAX 300’s memory, the rtVAX 300 begins executing the application software from its RAM. Many applications require the rtVAX 300 to boot internally, independently of the state of the network or host. This is accomplished by connecting a ROM in the rtVAX 300’s I/O space or memory space and fixing the VAXELN system image in this ROM. The rtVAX 300 can not boot the intended application if the host node is not available or the network segment fails This feature is important if controller down time is unacceptable. NETWORK INTERCONNECT INTERFACE DECnet Communications The rtVAX 300 processor allows the transfer of information and programs among Digital’s systems, and among Digital’s and other manufacturer’s systems. Network communications between Digital’s systems is facilitated by DECnet hardware and software. VAXELN programs developed on a host VAX processor can be loaded into the target rtVAX 300 based application through the network. The rtVAX 300 communicates with other VAX processors through the Ethernet local area network. Systems and devices can easily be connected to the network; network expansion is possible without interrupting network operations. Programs and data can be transferred between realtime applications and VAX processors in the network. Ethernet provides the following features: • Simplified network design allows installation of new devices without interrupting communication • Cable segments can be added to expand networks • Remote locations have fast access to data • High-speed communication can take place between nodes. Ethernet Interface The Ethernet coprocessor and serial-interface adapter (SIA) built into the rtVAX 300 provide the basis of an interface to an Ethernet network. The coprocessor has three features: • It supports virtual DMA and buffer management • It contains one 120-byte FIDO queue for data reception, and another for data transmission, with loopback capability • It complies with IEEE Standard 802.3 • It provides collision handling, transmission deferral and retransmission, and automatic jam and backoff • It has a continuous packet rate of up to 14,000 frames per second. The Ethernet interface can perform DMA transfers directly to the 256M bytes of system RAM. The coprocessor is programmed by reading from and writing to a set of registers on the rtVAX 300. Proper operation of an Ethernet/IEEE 802.3 interface requires precise and specific physical design of the power and ground arrangements. Briefly, components connected to the trunk network cable must be cd and low frequency-isolated from system ground. This isolation is provided by the isolation transformer and dc-to-dc converter. Thickwire Network Interconnect Thickwire Ethernet interconnect requires addition of an external isolation transformer and a 15-pid D-su connector to the rtVAX 300. ThinWire Support The rtVAX 300 connects to a ThinWire Ethernet network through the DP8392 transceiver and a few other components. An isolated -9V owner source is needed to support the ThinWire connection. I/O DEVICE INTERFACING I/O Device Mapping The rtVAX 300 processor supports 8-bit, 16-bit, and 32-bit I/O devices that are located in the rtVAX 300 processor’s 510M bytes of I/O space. This space is accessed with the same read and write cycles used for memory access; however, address bit 29 is set for I/O access and cleared for memory access. General Bus Interfacing Techniques In some applications, the rtVAX 300 interfaces with a general-purpose I/O bus, such as the VME bus or the IBM PC/AT bus. The design of this interface can vary. The rtVAX 300 applications module can function either as a bus master or a slave processor. Communication between the rtVAX 300 application module and other modules on the bus is carried out through either shared memory or dual-ported data registers. rtVAX 300 TEST BOX Features of the rtVAX 300 test box include: • Self contained test box for rtVAX 300 • Double digit HEX display for test code/pass/fail indicators • Console ports • Self - test bootstrap extensions • 4 Mbytes of dynamic RAM • Power supply • Can be used for: - functional verification - timing verification - incoming inspection • Will load and run VAXELN programs, can be used for debugging You can order an rtVAX 300 test box and users’ guide from Design Analysis Associates. The Design Analysis Associates part number for the test box is DAA-20RTVX-01. The address for Design Analysis Associates is: Design Analysis Associates, Inc. 75 West 100 South Logan, Ut. 84321 U.S.A. Phone: (801) 753-2212 FAX: (801) 753-7669 For additional technical and physical specifications of the rtVAX 300 processor, please reference the rtVAX 300 Hardware User’s Guide (Order Number: EK-382AB-UG-002). This manual contains information necessary for configuring the rtVAX 300 into host and target configurations.