INTRODUCTION The rtVAX 300 is a realtime target processor that is

INTRODUCTION The rtVAX 300 is a realtime target processor that is
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
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.
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
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
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.
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
Arb. Logic
BM and
Arb. Logic
and NI
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.
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
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.
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
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
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
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 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.
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
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
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 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.
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.
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF