N
A Video Controller and Distributed Frame Buffer
for the J-Machine
by
Eric Lawrence McDonald
S.B., M.I.T.
(1990)
Submitted to the Department of Electrical Engineering and Computer Science
In Partial Fulfillment of the Requirements for the Degree of
MASTER OF SCIENCE
IN ELECTRICAL ENGINEERING AND COMPUTER SCIENCE
at the
Massachusetts Institute of Technology
January 1995
(@1995Massachusetts Institute of Technology. All rights reserved.
-
t"
Signature of Author
on- ,
,
n
__
n
-
-
-
-
-
-
Department of Electrical Engineering and Computer Science
January, 1995
,zl)
/-)
Certified by
7.
Prof. William J. Dally
Associate Professor of Electrical Engineering and Computer Science
Thesis Supervisor
A
Accepted by
--
n){.
Prof. Frederic Morgenthaler
Chair an, Departmental Committee on Graduate Students
Eng,
MASSACHIJSErSINSTITUTE
.r
!. -
-
-
APR 13 1995
LIBRARIE
A Video Controller and Distributed Frame Buffer
for the J-Machine
by
Eric Lawrence McDonald
Submitted to the
Department of Electrical Engineering and Computer Science
on January 20, 1995, in partial fulfillment of
the requirements for the Degree of Master of Science in
Electrical Engineering and Computer Science
Abstract
A high-bandwidth video system for the J-Machine concurrent computer has been developed.
The system integrates a physically distributed frame buffer with a commercial video controller chip to provide a unique research tool in the field of computer graphics. Combined
with the fine-grain programming mechanisms of the J-Machine, the flexibility of the system
allows research into a number of distributed graphics algorithms without the dampening
effects of low video memory bandwidth. The video system is scalable to provides a range of
price/performance tradeoffs. Applications for the J-Machine video system include scientific
visualization, animation, and high-speed photorealistic rendering.
Thesis Supervisor: Prof. William J. Dally
Title: Associate Professor of Electrical Engineering and Computer Science
Keywords:
Video, Distributed, Graphics, J-Machine.
Acknowledgments
Many people have given me invaluable help and guidance throughout my years here at
M.I.T, and I'd like to offer them my whole-hearted thanks.
I would first like to thank my thesis advisor, Prof. Bill Dally, for giving me such a challenging
research project. His wealth of knowledge and expertise helped me though some critical
design decisions, and yet he kept enough distance to let me find solutions to the exciting
problems on my own.
Several members of the CVA group offered their wisdom as well. My first few months with
the group were spent under the tutelage of Mike Noakes, who was more than generous with
his time when I was trying to learn as much as possible about the J-Machine hardware.
Toward the end of the project, the debugging advice offered by Andrew Chang helped me
untangle some crucial puzzles. And the advice, opinions, and humor of Stuart Fiske and
Rich Lethin have helped me put some perspective on where I've been and where I'm going.
The faculty at M.I.T. is tremendous, and I would like to extend my particular thanks to
Profs. Don Troxel and Al Drake. As a TA in their courses, I experienced some of my most
worthwhile and rewarding moments here at the institute.
Many, many thanks go out to my family. The love and support from my parents have given
me all the confidence I need to make a difference in life. My brother and sister have already
demonstrated the successful lives that a loving family can foster. The warmth of my family,
and Jellybean (my cat, not the Machine), have always been able to keep my spirits aloft.
My deepest gratitude goes out to my best friend Dave. His friendship, tolerance, insight,
and humor have helped me to appreciate the better parts of life. The experiences we've
shared since high school have instilled in me the sense of optimism and hope that I possess
today. It is with excitement and wonder that I wait for the future to unfold.
To Mom and Dad
Contents
1 Introduction
. . . . . . . . . . . . . . . . . . . . . .
1.1 Overview . .......
1.2 Background . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 The J [-Machine ..............................
. . .
1.2.2 The )emands of High-speed Rendering
1.3 Video Systen n Hardware Overview . . . . . . . . . .
1.4 Prior Work
1.5 Results...
1.6
Thesis Outlit
. . . . . . . . . . . . .
. . . . . . . . . . . . .
13
......
14
14
15
16
19
Module Descriptions ...............................
2.2.1 MDP Module ...............................
2.2.2 DRAM Module ..............................
2.2.3 FIFO Module ...............................
2.2.4 MREAD Module .............................
2.2.5 MUX Module ...............................
2.2.6 VRAM Module ..............................
2.3 Fabrication ....................................
3 Video Controller
3.1 Purpose ......................................
3.2
. . . . . . . . . . . . .
. . . . . . . . . . . . .
.. 17
17
............
....................................
............
....................................
ae...................................... .... 18
2 Pixel Storage Node
2.1 Purpose ......................................
2.2
13
19
20
21
22
23
26
28
30
35
37
Module Descriptions ...............................
3.2.1 MDP Module ...............................
3.2.2 DRAM Module ..............................
3.2.3 FIFO Module ...............................
3.2.4 ERM Module ...............................
3.2.5 XLM Module ...............................
3.2.6 SCM Module ...............................
3.2.7 TIM Module ...............................
3.2.8 MPU Module ...............................
3.2.9 Bt463 ...................................
3.3 Fabrication ....................................
9
37
37
38
39
39
42
44
47
54
56
58
58
59
4 Configuring the Video System
4.1
4.2
4.3
4.4
4.5
4.6
Number of Pixel Storage Nodes . . .
Display Resolution ..........
Starting an Application ......
Initializing the XLM .........
4.4.1 Single-line frame buffer . . .
4.4.2 Single-screen frame buffer . .
4.4.3 Multiple-screen frame buffer.
Initializing the SCM .........
Classes of Pixel Messages ......
. . . . . . . .
. . . . . . . .
4.6.1 Address/Pixel List .....
4.6.2
4.7
4.8
4.9
5
Raster Operations ......
. . . . . . . .
4.6.3 Proxy Messages .......
Increasing Effective Storage
Hardware Scrolling and Stretching
Stereo Monitors ............
..............
..............
..............
59
60
60
62
63
63
65
65
65
66
66
67
68
68
69
71
Conclusion
Summary ..............
Further Work ............
71
72
A PSN Schematics and PAL Files
73
5.1
5.2
108
B VC Schematics and PAL Files
10
List of Figures
1.1
Small Video System for the J-Machine . .
16
2.1
Pixel Storage Node Hardware Modules ...................
2.2
2.3
2.4
PSN FIFO Block Diagram ..........................
20
24
25
27
29
30
31
32
32
33
34
34
3.1
3.2
Video Controller Hardware Modules
VC FIFO Block Diagram ..........
Logic Analyzer Plot of EMI Write Cycle ..................
MREAD Block Diagram ...........................
2.5 MUX Block Diagram .............................
2.6 Single-bit VRAM Layer ...........................
2.7 VRAM Block Diagram ............................
2.8 Flow Chart for VRAM Controller ......................
2.9 Timing Diagram- VRAM Refresh Cycle ..................
2.10 Timing Diagram - VRAM Row Transfer ..................
2.11 Timing Diagram - VRAM Write ......................
2.12 Timing Diagram- VRAM Read .......................
....
3.3 Data transfer between FIFO and MPU . . .
.................
.................
.................
.................
3.4
3.5
3.6
3.7
3.8
3.9
3.10
ERM Block Diagram .............
XLM Block Diagram .............
. . . . . . . . . . .
. . . . . . . . . . .
Shift Clock Timing for a One-Of-Four PSN
Shift Clock Timing for a One-Of-Eight PSN . . . . . . . . . . .
. . . .
General Structure of SCM module .....
Preventing LdClk Timing Violations with a Delay Line.
. . . .
MPU Block Diagram ....................
4.1
4.2
4.3
4.4
4.5
Displaying the Same Color Using True-Color and Pseudo-color Modes
Single-buffer VRAM Usage with Four PSNs per Scan Line ........
Multi-buffer VRAM Usage with Eight PSNs per Scan Line .......
Increasing Effective Storage through Pixel Compaction ..........
Using the XLM to Scroll an Image Vertically ...............
11
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
40
41
42
.
.
.
.
.
45
..
..
..
..
..
62
64
64
69
69
49
49
51
54
57
List of Tables
2.1
2.2
2.3
2.4
Effects of Increasing the Number of PSNs ..................
EMI Address Multiplexing Scheme . .................
MREAD Memory Map .
MUX Selection .................................
3.1
3.2
3.3
3.4
3.5
FIFO Interpretation of EMI Address Bits 17 & 16
ERM Memory Map .................
XLM Usage of Data and Address Bits From FIFO
SCM Usage of Data and Address Bits From FIFO
MPU Usage of Data Bits From FIFO ........
12
.
.
............
..............
..............
..............
..............
..............
22
24
26
29
40
43
46
51
56
Chapter 1
Introduction
My goal is simple. It is complete understanding of
the universe, why it as it is and why it exists as all.
-STEPHEN
HAWKING
There is a theory which states that if ever anyone discovers
exactly what the Universe is for and why it is here, it will
instantly disappear and be replacedby something even more
bizarre and inexplicable. There is another which states
that this has already happened.
- DOUGLAS
ADAMSin The Restaurant at the End of the Universe
1.1
Overview
This thesis describes a video system that has been developed for the J-Machine concurrent
computer. The video system, also called the Distributed Frame Buffer (DFB), allows the
J-Machine to be used as a research tool in the field of distributed graphics processing.
The DFB provides the J-Machine with high-bandwidth, multiple-buffer, high-resolution
video capability required for applications such as scientific visualization, animation, and
photorealistic graphics rendering.
The J-Machine itself is a fine-grain, concurrent computer that provides efficient mechanisms to support several proposed models of concurrent computation. While it has always
been possible to use the J-Machine for the calculations involved in graphics applications,
the results previously had to be fetched with significantlylow-bandwidth bit-serial retrieval.
The DFB allows the rapid display of information-rich video generated by the J-Machine processor array.
The DFB is both distributed and scalable. Distributing the physical location of the
pixel frame buffers eliminates the bottleneck created by a single video bus and thus pro-
vides greater bandwidth into the video system. The scalable nature of the DFB allows
J-Machine owners to balance cost against performance in accordance with their particular
graphics requirements. The DFB is extremely flexible, with many configuration options
under software control.
13
CHAPTER 1. INTRODUCTION
14
Before discussing the video system in detail, some background information is needed on
both the J-Machine architecture and modern-day graphics requirements.
1.2
Background
1.2.1 The J-Machine
The DFB has been targeted for use with the J-Machine, a fine-grain concurrent computer
built by MIT's Concurrent VLSI Architecture Group [9]. A 1024-node version of the JMachine has been operating since mid-1993.
The J-Machine Philosophy
The J-Machine is a concurrent computer; rather than optimizing execution on a single
node, the emphasis is on dividing a job efficiently across many nodes. Moreover, it is a
fine-grain concurrent computer, allowing programs to be efficiently partitioned into tasks
(with an average size of a few dozen instructions) and data objects (with an average size
of a few dozen words). The J-Machine provides hardware mechanisms that support several
distinct concurrent programming models. For example, the hardware provides efficient
synchronization and object translation across multiple nodes.
The processing elements in the J-Machine, called Message Driven Processors (MDPs),
are connected through a very low latency, synchronous, three-dimensional mesh network.
Since inter-node communication in a fine-grain concurrent computer occurs as frequently as
procedure-calling in sequential programs, low overhead for message sends is desirable. To
this end, MDP message sends are user-level instructions and do not require bulky systemlevel calls. Furthermore, the delivery mechanism and message buffering is performed by
dedicated logic on the MDP chip, freeing up the main processor for program execution.
Although parallel graphics processing is becoming commonplace, very little research in
the field has been done with the fine granularity provided by the J-Machine. The J-Machine
and its video system now provide fertile ground for the study of this model.
The J-Machine Hardware
The J-Machine contains up to 65,536 computing nodes, each with an MDP and 256 KWords
of external DRAM memory. An MDP chip consists of an ALU, register files, 4K 36-bit
words of internal memory, a network interface, and control logic for the external DRAM.
The network that links the MDP nodes is provably deadlock-free.
An MDP also contains a diagnostic port used for initializing the chip, halting and
examining its state, and reading and writing to its memory. Although any MDP in the
J-Machine array can be individually accessed through its diagnostic port, such access is bitserial and thus slow. It is through this serial port that images from a previous ray-tracing
experiment [4] were retrieved.
A single J-Machine processor board can accommodate 64 MDP nodes. Within a board,
routing of the x and y network channels is accomplished with copper traces. Between
boards, network routing takes place over ribbon cables (x and y dimensions) and elastomeric
1.2. BACKGROUND
connectors (z dimension).
15
The J-Machine chassis can accommodate up to 16 processor
boards with an additional 32 peripheral boards.
1.2.2
The Demands of High-speed Rendering
Modern graphics applications such as 3-dimensional rendering, photorealistic animation,
and scientific visualization demand far higher performance than non-specialized computing
environments can suitably provide. Graphics users must often accept either a slow response
time or lower resolution to accomplish work at a tolerable rate. Two obstacles need to
be overcome to meet the demands of today's high-performance graphics: pixel processing
power and frame buffer memory bandwidth [5].
Pixel processing requirements
The rendering of three-dimensional scenes relies heavily on two fundamental types of data
processing: geometry processingis used to transform the objects in a scene according to
the observer's viewpoint, and rasterization is needed to scan-convert the transformed objects into pixel representations. The amount of such computation needed in a real-time
high-quality animation sequence can be staggering. For example, rendering a high-quality
Gouraud-shaded scene of 100,000 polygons updated at 30 Hz requires about 350 million
floating-point operations per second and 750 millioninteger operations per second [7]. Standard uniprocessor designs simply cannot satisfy such computational requirements.
An obvious way to overcome the processing barrier is to distribute the computational
problem among multiple processors. This can be accomplished with parallel processing,
hardware pipelining, or a combination of both techniques.
A video system that used a purely parallel approach was proposed as early as 1979
at UNC [6]. In this system, all polygons were broadcast to a set of processing elements,
but each processing element only computed those pixels for which it was responsible. This
parallel processing was used for both geometry processing and rasterization.
More often, specialized hardware pipelines are used in conjunction with parallel processing. In the Pixel Machine [10], a pipeline of nodes was employed to perform the intrinsicallysequential rendering operations that would otherwise reduce the efficiency of its parallel
array of processors. Both the pipeline unit and parallel array were connected to each other
and a host computer through a single bus, which posed a potential bottleneck. A system
developed at SGI [1] used a more tightly integrated sequence of hardware pipeline and parallel processing stages. However, as is typical with designs containing hardware pipelines,
this system was somewhat constrained to a particular rendering algorithm.
The J-Machine video system uses a more flexible approach to satisfy the pixel processing
requirements. The entire J-Machine processor array is used to perform pixel processing
calculations. The nodes are grouped into functional units which can then be linked in a
pipeline or parallel array. The allocation of nodes to the stages of the rendering algorithm
is arbitrary, as is the rendering algorithm itself. No specialized rendering hardware is used
to perform the data processing. Processing can be done at either the pixel level or object
level. However, this flexibility brings with it the non-trivial challenges of synchronization
and load balancing.
CHAPTER 1. INTRODUCTION
16
TwoindependentPixel
StorageNodesper board
Scalable
PSN
array
Figure 1.1: Small Video System for the J-Machine
Frame buffer bandwidth
The second potential bottleneck in rendering architectures is the bandwidth of the video
memory used to store the computed image. To meet this high demand, all of the rendering
architectures mentioned thus far have used memory interleaving in one form or another.
The distributed nature of the J-Machine's frame buffer provides a similar mechanism to
meet these bandwidth requirements. The maximum configuration of the video system can
support 140 million 32-bit writes to the frame buffer per second.
The frame buffer is scalable, so the exact size of the video system can be tailored to the
performance requirements of individual installations. Although fewer frame buffer boards
reduces total memory bandwidth, the dollar cost of the system is reduced.
1.3
Video System Hardware Overview
The J-Machine video system consists of two types of printed circuit boards. The first type
contains two independent and identical nodes called Pixel Storage Nodes (PSNs); multiple
PSNs comprise the distributed frame buffer storage. The second type is called the Video
Controller (VC) board. There is only a single VC per system; its function is to coordinate
the real-time transfer of pixel data and to display images on an RGB monitor.
Each type of board connects to an edge of the J-Machine processor array. Figure 1.1
shows one possible configuration of the video system, consisting of an array of eight Pixel
Storage Nodes and a single Video Controller Board.
The VC must repeatedly retrieve pixel data for every line of each screen refresh cycle;
no buffering is performed on the VC itself. The video specification provides for up to
a 1280 x 1024 pixel screen with 24-bit deep pixels. The RGB video adheres to RS-343
synchronization standards [3], making it compatible with most high-performance monitors.
Although there is only one VC per video system, synchronization between multiple VCs
1.4. PRIOR WORK
17
is possible if multiple video systems are installed in a single J-Machine. This permits the
generation of high-resolution three-dimensional images on a stereo monitor.
As shown in the figure, the aggregate PSN array is ultimately responsible for supplying
four pixel streams to the VC. Although the resulting data bus is four times the size of the
pixels (the video controller IC has a massive 128-bit input port), the buses need operate
only at one-quarter the 120 MHz pixel rate. So instead of retrieving a single pixel every
120 MHz clock cycle, four pixels are retrieved every 30 MHz clock cycle. Because of this
arrangement, the video system requires at least four PSNs and a single VC. If more than
four PSNs are used, each pixel stream bus is shared in a time-multiplexed fashion, with the
VC providing bus arbitration.
A typical screen update proceeds as follows: an application is distributed throughout
MDPs in the J-Machine cube. Each MDP is responsible for computing pixels for a certain
region of the display. The MDPs have halted at a barrier synchronization because they
are waiting for the recently-computed frame to be displayed. When they receive word from
the VC that the end-of-frame has arrived, they can send their pixel updates to the frame
buffer1 . These pixel messages are sent to one or more of the PSNs over the J-Machine interprocessor network. Before every scan line in the new frame, the VC instructs the PSNs to
download a row of pixel data into shift registers. The VC sequences through this data for
the duration of the scan line. It fetches pixels from four PSNs at a time and spreads them
across the next four display columns. When the end of a horizontal scan line is reached, the
PSNs are instructed to download another row of pixel data. All communication between
the PSNs and the VC takes place over a dedicated set of ribbon cables. When every scan
line has been displayed, the process repeats.
1.4
Prior Work
This research builds upon initial work performed by S. Zamani [12]. In his Bachelor's thesis,
Zamani proposed a design to deal with some of the fundamental architectural requirements
of a video system for the J-Machine. The J-Machine video system includes some of those
early design ideas, specifically with respect to the Pixel Storage Node.
In addition, other peripheral boards have been developed for the J-Machine. A SCSI
interface was implemented to provide scalable non-volatile disk storage [11]. An SBus
interface was built to allow a Sparc workstation to function as the front end to the JMachine [8]. Since all of the peripheral boards must integrate into the J-Machine, they
share a set of common logic.
1.5
Results
The J-Machine video system achieves the high-bandwidth required by modern graphics
applications, but it has some weaknesses. Most notably, the various levels of interleaving
required to achievethis bandwidth (discussed in Chapter 3) presents a convoluted mapping
between position in memory and location on the display. Although a software library
lIf all updates can be computed and delivered to the frame buffer in time, only a single buffer is needed.
Otherwise, at least two buffers are needed and the VC is instructed which buffer to use for the current frame.
CHAPTER 1. INTRODUCTION
18
can abstract away any confusion, it will also incur a performance penalty. A truly high-
performance application therefore needs to understand the hardware at a fundamental level.
For less demanding applications, the J-Machine video system can be quite useful.
1.6
Thesis Outline
Chapter 2 discusses the architecture of the Pixel Storage Node and some of the tradeoffs
that were made in the interest of design simplicity. Chapter 3 describes the Video Con-
troller board and the flexiblegraphical environment it provides. Chapter 4 presents a range
of system configurations, each with its own performance and cost. Chapter 5 closes by
discussing potential future research issues and summarizing the results of this thesis.
Chapter 2
Pixel Storage Node
Do, or do not. There is no try.
-YODA
Even if you are on the right track,
you'll get run over if you just sit there.
-UNKNOWN
2.1
Purpose
Each Pixel Storage Node (PSN) provides a portion of the physical storage for the pixels in
the video frame buffers. The relation between a storage location on a PSN and a position
on the screen is not fixed by the hardware. Instead, it is configurable by the user via the
Video Controller board. This mapping cannot be completely arbitrary, however, and will
be discussed in Chapter 3.
The pixels of an image are typically generated by computations in the J-Machine processor array, transferred to one or more of the PSNs, and then fetched repeatedly by the VC.
The native J-Machine inter-processor network provides the data path from the J-Machine
to the PSN; this path is used when pixel values need to be modified. The second data path
- from the PSNs to the VC - uses a separate set of ribbon cables. This path is used very
frequently, since the Video Controller must refresh the CRT display.
There are two distinct methods for generating pixel data. One method requires that the
precise pixel address and pixel value be computed by the J-Machine, and then transferred
pixel-for-pixel to the PSNs. Such a message might say "put pixel value 0x3bf in VRAM
location 0x0201." The second method requires only that general raster operations (ROPs)
be generated by the main J-Machine array; the PSNs then interpret the ROPs locally to
generate and store the exact pixel values. Such a message might say "draw a blue line from
display coordinates (0,0) to (50,100)." The list of supported ROPs appears in section 4.6,
along with a discussion of the tradeoffs associated with these two methods.
19
CHAPTER 2. PIXEL STORAGE NODE
20
Address
Row Transfer
Address
(from VCB)
Shift
Pixel
Clock
Figure 2.1: Pixel Storage Node Hardware Modules
2.2
Module Descriptions
Figure 2.1 shows the modules that comprise a Pixel Storage Node. Various control signals
between the modules have been omitted for clarity. Pixel messages flow in from the JMachine through the network connection on the upper left. The MDP decodes each message
and writes address/pixel pairs out to its external memory interface (EMI), where they are
placed into either standard external DRAM or into a FIFO directed toward the video RAM
(VRAM). If the MDP tries to read from its EMI, the request will be serviced either by
DRAM or by the MREAD module (which can read directly from the VRAM), depending
on the address. A MUX is needed to select the address lines for the VRAM, since an address
can come from the FIFO module (pixel write), the MREAD module (pixel read), or the
Video Controller Board (in the form of a row-transfer request, discussed in section 2.2.6).
The dual-ported VRAM has a serial output port which is constantly supplying pixel data
to the video controller. The video controller uses a "shift clock" to sequence through this
data as it retraces the display.
The remaining sections of this chapter discuss each of the modules in more detail. PAL
program listings and full schematics for all modules appear in the appendices.
2.2. MODULE DESCRIPTIONS
2.2.1
21
MDP Module
The MDP provides a data link between the J-Machine processor array and the rest of the
PSN. Its 20 MByte/sec 1 port is connected via ribbon cable to an MDP along one of the JMachine processor board edges. It is over this path that incoming pixel messages, generated
somewherewithin the J-Machine array, arrive at the MDP. The PSN must somehowretrieve
this pixel data from the MDP to complete the pixel data path.
The MDP's external memory interface (EMI) is used to accomplish this task. Normally,
the EMI allows the MDP to manage up to 1 Mword (36-bit words) of external DRAM
storage. However,if the MDP copies data from network messages to its EMI interface, the
data can instead be grabbed off the EMI bus and used by the rest of the PSN.
The network protocol used by the MDP to communicate with neighboring MDPs is
obviously well-defined, so the question arises: why dedicate an expensive MDP to carry
out this rather trivial task of copying data, instead of using some dedicated programmable
logic? The two primary reasons are:
* The handshaking and token-passing network protocol was deemed too complicated to
attempt to implement with programmable logic. It is also not clear that PALs or other
PLDs could achieve the goal with the given timing constraints. For these reasons, the
PSN and two other peripheral boards - the Video Controller board discussed later and
the SCSI Interface Board used for the disk array - use an MDP for this data-bridging
function. The single J-Machine peripheral board that obviates the use of an MDP is
the SBus interface board; the tradeoff there, however, is that two-way communication
is achieved by requiring connections to two MDPs in the processor array (one for each
direction).
* Without an MDP available to process the incoming network messages, the format
of incoming pixel messages needs to be rather tightly specified when the PLDs are
programmed. An MDP, on the other hand, allows both pixel messages and raster
operations to be sent to the PSNs (as discussed in section 2.1). This flexibility would
not be possible without a processing engine - one more complicated than a finite state
machine implemented in PLDs, for example.
A key disadvantage to using an MDP in this fashion is that its EMI interface has a paltry
bandwidth of 8.75 MBytes/sec. The primary reason for this low bandwidth was a lack of
I/O pins on the 168-pin PGA package used for the MDP. Because of the pin limitation,
two MDP cycles are required to specify an external DRAM address, and three cycles are
required to fetch 36 bits of data over 12 data lines (although the first data cycle is coincident
with the second address cycle). Additional delay is caused by the need to copy each pixel
out of the MDP's network buffer, into a register, and out to its EMI.
Thus, the pixel bandwidth into a single node is limited not by the J-Machine's network
bandwidth but by the MDP's EMI bandwidth. It is important to note, however, that one
can compensate for this lower bandwidth by scaling up the number of PSNs in the video
'Numerical figures in this thesis assume a J-Machine operating frequency of 20 MHz. As such, the
network clock is 20 MHz while the MDP processor clock is one-half this rate. In theory, the operating
frequency can be increased to 32 MHz.
CHAPTER 2. PIXEL STORAGE NODE
22
PSN Nodes
Refresh rate Storage Cap.
Aggregate
(32-bit pix)
EMI Bandwidth (32-bit pix)
4
35 MB/s
8.75 fps
2 frames
8
70 MB/s
17.5 fps
4 frames
16
32
140 MB/s
280 MB/s
35.0 fps
70.0 fps
8 frames
16 frames
Table 2.1: Effects of Increasing the Number of PSNs
system. Table 2.1 shows the effect scaling has on the pixel bandwidth into the video system.
Also shown is the maximum frame storage and refresh rate assuming 32-bit pixels and a
1024x 1024 display.
Realistic animation demands at least 15 frames per second to provide the illusion of
continuous motion. Thus table 2.1 indicates that the video system requires at least 8 PSNs
to meet the lower threshold for full-screen, 32-bit animation. However, if the rendering
algorithm can pack multiple pixel values into a single 32-bit word (as discussed in Chapter
4), animation is still possible in a system with 4 PSNs. In essence, speed can be achieved
at the expense of simultaneous color range.
The MDP module also requires a host of support components to integrate it into the
J-Machine diagnostic and routing network. The schematics and PAL files that provide this
support appear in the appendices; a more detailed description can be found in [8], [9], and
[11].
2.2.2 DRAM Module
The external DRAM connected to the MDP module could potentially be used in two ways:
* As normal MDP external memory, available for program and data storage. Data
intended for the VRAM would be addressed beyond the address range of the DRAM.
No installed J-Machine node has more than 256 KWords of external DRAM, so it
makes little sense to install more than that on the peripheral boards. This leaves 768
KWords of unused address space that can be memory mapped into VRAM space.
* As shadow video memory, to be used for duplicate pixel storage only. All EMI writes
would be directed into both the DRAM and the VRAM, but EMI reads would be
serviced by the DRAM. This would allow the MDP to use rendering algorithms that
require the current value of a pixel before updating it. (Even though the MREAD
module provides a read path between the MDP and VRAM, it is much slower than
the DRAM path for reasons revealed in section 2.2.4.) Obviously, this scheme requires
at least as much DRAM memory as VRAM memory per node; since 512 KWords of
VRAM are installed per PSN, this would also be the minimum DRAM storage.
The first method was chosen over the second. A high-performance application uses
many more J-Machine nodes than there are PSN nodes. To minimize the effects of low
EMI bandwidth, a read-modify-write algorithm should be distributed across this larger set
2.2. MODULE DESCRIPTIONS
23
of nodes; the shadow memory model therefore loses its appeal. Note that a PSN can still
use its DRAM to locally implement a read-modify-write algorithm, but it must write to
DRAM and VRAM with separate instructions.
2.2.3
FIFO Module
Design Considerations
The FIFO module serves to decouple the timing constraints of the MDP (which supplies
the pixel data) from those of the VRAM (which consumes the data).
Since the EMI was designed solely as a memory interface, it has none of the provisions of
a more general-purpose peripheral interface such as request, acknowledge, and ready lines.
Thus, it is useful only for devices capable of consuming or producing data when the MDP
demands it.
This requirement makes it impossible to directly connect the VRAM to the EMI bus.
The VRAM may be in the midst of a refresh cycle, or may be servicing a row-transfer
request for the video controller. Disruption of either of these activities would produce
undesirable results, but the EMI interface has no provisions for detecting this not-ready
condition. Without some kind of queue, any writes during this period need to be ignored
by the VRAM module.
Since external DRAM memory should still be available to the MDP, the FIFO allows
both DRAM and VRAM accesses by using a memory-mapping scheme: addresses less
than x80000 correspond to the DRAM and addresses greater than or equal to x80000
correspond to the VRAM. To implement this scheme, the FIFO controller must understand
the multiplexing mentioned in section 2.2.1. During an EMI access, the eleven address
lines are time-multiplexed to provide a 20-bit wide address with two bits of phase, and the
twelve data lines are time-multiplexed to produce 36-bit wide data. The two-cycle addressmultiplexing scheme is shown in table 2.2. The three-cycle data-multiplexing scheme is
simply the three 12-bit portions of the data word from lowest to highest significance. Since
the VRAM's data port is 32 bits wide, the FIFO must assemblethe three 12-bit data chunks
appropriately. Note that the FIFO drops the four most significant bits, which are normally
used as a tag for the data word; the video controller neither requires nor recognizes more
than 32 bits of pixel data.
The FIFO module must take care to disable the external DRAM when an EMI access is
intended for the VRAM. It therefore suppresses the write signal when the EMI address is
greater than Ox7ffff.It should also disable the DRAM when a read is made from this upper
address range, since the MREAD module is then responsible for driving the bus.
Implementation
As shown in figure 2.2, the FIFO module consists of separate address and data FIFOs, all
coordinated by a 22v10B PAL. When the PAL detects an EMI write access to an address
greater than Ox7ffff,it sequentially strobes the shift-in control lines of the FIFOs (SIAddr,
SIWordO, SIWordl, SIWord2) to capture both the address and data. An FSM in the
VRAM module can detect the subsequent data ready signal produced by the FIFOs and
will eventually shift out the address/data pair.
CHAPTER 2. PIXEL STORAGE NODE
24
from EMI
from EMI
from EMI
MCLK
/RAS
/CAS
/WR
EA[10: 8]
CSB[1 :0]
LIX
to VRAM
/OE /WR
to DRAM
Figure 2.2: PSN FIFO Block Diagram
EMI line
1st cycle 2nd cycle
EA10
EA9
EA8
EA7
A19
A17
A15
A13
A18
A16
A14
A12
EA6
All
A10
EAS
EA4
EA3
EA2
EAl
A9
A7
A5
A3
A1
A8
A6
A4
A2
CSB1
EAO
AO
CSBO
Table 2.2: EMI Address Multiplexing Scheme
ly
to VRAM
2.2. MODULE DESCRIPTIONS
25
MCLK
/WRITE
/RAS
!
I
SIWordO
,
/CAS
CSBO
CSB1
._Il
SIAddr
,
,
,
,
SIWordl
,
,
SIWord2
~~~~~~~~~~~~I
I
20 ns grid
I
I
,
II,
l_
I
I
I
1,I!
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
Figure 2.3: Logic Analyzer Plot of EMI Write Cycle
Figure 2.3 is the logic analyzer output produced by an EMI write to an address greater
than Ox7ffff. MCLKis the MDP's processor clock. The A19 bit appears on the EA10 line
(not shown) when RASfirst falls. If it is high and WRITEis low, the PAL will proceed to
monitor the gAS and CSBlines. When CASfirst drops, the PAL shifts in the EMI address
(SIAddr) and the first twelve bits of the data (SIWordO).As the CSBcycle counter increases
during subsequent CAS cycles, the second and third twelve-bit words will be shifted into
their respective FIFOs.
The FIFO shift signals must be registered because they are derived from the combinational CSBlines. However, MCLKdoesn't provide a suitable clock for these registers; as seen
in the plot above, the rising edge of MCLKoccurs before the falling edge of CAS,
which is the
time the data is valid. And the falling edge of MCLKoccurs too late into the CAS cycle to
satisfy the FIFO hold time requirements. Thus, an external JK flip-flop, clocked by A-S,is
needed to align SIWordl and SIWord2 with the falling edges of CAS.
The address and data FIFOs are 64 words deep, which is more than enough space to
queue the pixel data. In the worst-case scenario, the VRAM would require 13 clock cycles
to perform an entire row-transfer (and subsequent memory refresh) before even recognizing
the FIFO data. It would then take 13 cycles to process the data and shift it out of the
FIFO. However, any further data would only require 13 cycles between shift outs, since
row-transfers occur infrequently. These cycles are based on a 40 MHz clock, quadruple the
speed of the MDP processor clock. And since the MDP needs at least six of its cycles
between successive writes, the VRAM will quickly drain the FIFO should it begin to fill
up. 2
Although the EMI's RASand CAScontrol lines pass unimpeded to the DRAM chips, the
WRR
signal is routed through the PAL so that it can be squished when the address is greater
than Ox7ffff. And while most J-Machine nodes permanently enable their DRAM outputs,
2
The FIFO depth was selected before optimizing the time required by a row-transfer and before the 40
MHz clock was chosen.
CHAPTER 2. PIXEL STORAGE NODE
26
Address
0x80000 - Oxbffff
OxcOO0 - Oxcffff
- Oxdffff
OxdOOOO
Interpretation
Request VRAM data from Address minus 0x80000
Poll DataREQline and view data returned from last request.
Also selects bank for next read to Bank A.
Same as above, but selects bank for next read to Bank B.
Table 2.3: MREAD Memory Map
here the OE signal is generated by the FIFO PAL so as to avoid bus contention during
MREAD cycles.
2.2.4
MREAD Module
Design Considerations
The MREAD module allows the MDP to read pixel data directly out of VRAM. In theory
this is unnecessary because the MDPs themselves (both in the PSN and in the J-Machine)
are responsible for setting the VRAM contents in the first place - they presumably can
maintain a copy of what they send into the VRAM. But for debugging purposes this module
provides an essential feedback mechanism. During testing it is always a good idea to be
able to read back what one has written.
It is impossible to satisfy the MDP's request for VRAM data during the same memory
cycle it is issued. The VRAM module may be busy accepting data from the FIFO or
performing a row-transfer for the video controller. But even if the VRAM were idle, the
EMI address lines could not be decoded fast enough to initiate a VRAM read cycle that
could complete in time. The MREAD module must therefore use a multi-phase approach:
the MDP first issues an EMI read to a memory-mapped address range. It then monitors
a flag in a separate memory-mapped location to determine when the pixel data is ready.
The data is then retrieved in a final read cycle. This reduces the read bandwidth from
the VRAM to the MDP, but is acceptable because the MREAD interface was implemented
primarily for testing purposes.
Implementation
Figure 2.4 is a block diagram of the MREAD module. Much like the FIFO module, a
controlling PAL monitors the EMI lines of the MDP. When the PAL detects an EMI read
to an address greater than Ox7ffff, the PAL latches the multiplexed address with LdRAS
and LdAddr, and then raises its DataREQline to the VRAM module. Since it will take the
VRAM module some time to supply the pixel, the value driven onto the EMI bus for that
initial read will be the last pixel fetched, not the one just requested. Eventually the VRAM
registers with PixLd and then assert
module will place the newly-read pixel into the DATA
DataACKto indicate completion. The MREAD PAL releases DataREQwhen it sees this, so
after first initiating a read the MDP should poll DataREQand wait for it to drop before
going back to read the returned pixel.
2.2. MODULE DESCRIPTIONS
27
from EMI
from EMI
MCLI
/RA.
/CA.
/W
EA[10 :81
CSB [1:01
DataACI
(from
VRA
to
VRAM
Figure 2.4: MREAD Block Diagram
Data
CHAPTER 2. PIXEL STORAGE NODE
28
Since the MDP will typically be polling the MREAD module after issuing a request, the
MREAD module must not interpret every MREAD access as a VRAM data request. To
do so would cause the PAL to re-assert DataREQ each time the MDP polled DataREQ, and
this could create a race condition with the DataACK signal being returned by the VRAM
module. The MREAD PAL therefore maps the address space as shown in table 2.3. Only
MDP reads in the 0x80000 to 0xbffff address range will fetch the VRAM contents of that
address (minus 0x80000). This allows an 18-bit address range for each VRAM bank (the
two VRAM banks are discussed in section 2.2.6). To decide which VRAM bank to read,
the MREAD PAL looks back to the last read made from an address greater than 0xbffff. If
it was in the 0xc0000 page, VRAM bank A will be used on the next read cycle. If it was
the 0xdO000 page, VRAM bank B will be used instead. A read from either of these pages
will also return the DataREQstatus in bit 35 of the data, without initiating another VRAM
read cycle.
When the MREAD PAL drives data onto the bus with its DrvW[2:0] signals, it relies
on the PAL in the FIFO module to disable the external DRAM to avoid bus contention.
Thus, the FIFO PAL must monitor for both FIFO and MREAD accesses to control the
DRAMs appropriately.
2.2.5
MUX Module
Design Considerations
The MUX module selects one of three sources for the address lines of the VRAMs. An
address may come from the FIFO as a place to store a given pixel, from the MREAD
module as an address to read, or from the VC as a row-transfer address. To conform to
the VRAM address interface, the 18-bit address supplied by each of these sources must be
broken up into a nine-bit column and a nine-bit row.
Implementation
The VRAM module provides the three MUX control signals shown in figure 2.5. When Pix
is high the address will come from the ADDRFIFOs. When it is low the address will come
from either the VC or the MREAD module, depending on the state of Line. The VRAM
expects its address to be multiplexed into a row and column, so when CASis high the lower
9 bits of the address will be selected; otherwise the upper 9 bits will be selected. Table 2.4
summarizes this behavior.
Although straightforward in function, the MUX module requires eight chips as implemented with simple discrete multiplexors. The upper mux in the figure requires five quad
2-to-1 chips, and the lower one requires three quad 4-to-1 chips. The chip count could have
been reduced with more elaborate components, but at a higher dollar cost. If the area on
the circuit board had been smaller, this module would have been the first to get streamlined.
2.2. MODULE DESCRIPTIONS
29
LineAddr
MreadAddr PixAddr
Line/Mread
CAS/R
Pix/Xf
to VRAM
Figure 2.5: MUX Block Diagram
CAS/RAS Pix/Xfer
Line/Mread
Output
0
1
X
X
X
X
Upper nine bits (row)
Lower nine bits (column)
X
0
0
Mread address
X
X
0
1
1
X
Row transfer address
Pixel write address
Table 2.4: MUX Selection
CHAPTER 2. PIXEL STORAGE NODE
30
AM
NM
hat
SCMk
Figure 2.6: Single-bit VRAM Layer
2.2.6
VRAM Module
Design Considerations
The video memory is the primary resource of a PSN, and the complexity of the VRAM
module reflects this importance. The VRAM controller must communicate with three other
modules - the FIFO, MREAD and XFER modules - to arbitrate their access to the video
storage. FIFO and MREAD accesses have already been discussed; XFER accesses are
generated once per scan line and will be described in section 2.2.4.
Contention for the video memory would have been exacerbated had we needed to worry
about the video controller's requirement to refresh the display. Fortunately, today's dualported Video RAM (VRAM) architecture eliminates this potential bottleneck. Figure 2.6
is a simplified diagram of a single-bit 3 layer of VRAM storage. A standard array of RAM
is supplemented by the Serial Access Memory (SAM) shown on the right. A "read transfer
cycle" copies an entire row from the RAM array into the SAM4 , after which time the SAM
can be accessed completely independently (and faster) than the RAM array. The TAP is a
9-bit counter that indexes one of the 512 copied values and sends it to the output port. The
TAP increments on the rising edge of SClk (shift clock), eliminating the need for separate
address lines. This sequential access approach is not as flexible as the general random access
used on the RAM side, but it is targeted at video applications where most accesses are in
fact sequential.
Implementation
Figure 2.7 is a block diagram of the VRAM module. The first thing to notice is that
the memory is segmented into two 256K banks. This is necessary to satisfy the video
controller's read cycle time in a minimum video system. In a system with only 4 PSNs,
3
The single layer shown is replicated four times in the VRAM chips used in this project. The chips are
organized in groups of eight to provide 32-bit wide pixels.
4
A "write transfer cycle" transfers data in the other direction, but this capability isn't used.
2.2. MODULE DESCRIPTIONS
31
from FIFO
ADDR
DATA
I gu
DataRBQ--PixBankMR-
DataACK
PixLd
to
READ
(fromMREAD)
LineXfer(fromVCS)
FifoOR---
PixBank(fromFIFO)
Line
Pix MuxCAS_
to MUX
FifoOE
_
FifoSO
to FIFO
RAS,CAS,
-- l to Bank A
WE,OE
FClk-
__
-.> WE,OE
to Bank B
Figure 2.7: VRAM Block Diagram
the time between successive reads from a given PSN is only 23 ns, whereas the VRAM
serial port requires at least 30 ns between reads. Thus, subsequent reads from a given PSN
are alternately satisfied by banks A and B. Although the timing can be more relaxed in a
system with more PSNs, the PSN is hardwired to always deliver pixels to the VC in this
alternating fashion.
This mode of operation is nearly transparent to the user. The FSM determines the bank
in which to store a given pixel by looking at the PixBank bit, which is actually the least
significant bit of the pixel's address. Thus, pixels written to even addresses are placed in
bank A, and those written to odd addresses are placed in bank B.
However, when using the MREAD module to read data back from the VRAM, the bank
to read must be set explicitly as described earlier in section 2.2.4 and table 2.3. Since the
MREAD module is principally used only during testing, this inconvenience is not important.
Pixels fetched from the SAM ports of the VRAMs are put into registers before being
enabled onto the common PixChan bus. Notice that the SClk signal that provides the shift
clock for the SAM is also used as the output enable for the register. Thus, the low-to-
high transition of SC1ktransfers data from the VRAM to the register and increments the
VRAM's TAP, but the pixel isn't driven onto the pixel bus until the next time SClk goes
low. This design eliminates the need for a separate output-enable going to each register, but
causes the SClk signal to assume two roles. The implications of this design are discussed in
the next chapter.
FClk is a 40 Mhz clock signal supplied by the VC. It is asynchronous to the J-Machine
clocking network, and allows the VRAM controller to run at a higher speed. More important, it is not selectable by the J-Machine user (who can choose between three system
clocks). If the FSM frequency were not fixed, it would be difficult to arrange those portions
of the state diagram that must meet certain VRAM timing constraints.
CHAPTER 2. PIXEL STORAGE NODE
32
Figure 2.8: Flow Chart for VRAM Controller
The flow chart in figure 2.8 reveals that the most frequent operation of the FSM is the
VRAM refresh cycle, which is required to maintain the integrity of the volatile memory.
An internal refresh function provided by the VRAM chips reduces this task to the simple
CAS-before-RASoperation shown in figure 2.9. An internal address counter eliminates the
need to supply a row address for each refresh cycle.
In the last three refresh states, the controller sequentially checks for requests coming
from the XFER, FIFO, and MREAD modules respectively. The XFER module gets first
priority because the row of data must be transfered to the serial port before the beginning
of the next scan line. There is no danger of permanently blocking requests from FIFO and
MREAD because XFER requests are generated only once every 16 s.
Figure 2.10 is a timing diagram for the row-transfer operation. The VRAM recognizes a
row-transfer request when DTOEdrops before RASdoes. The FSM drives Line high to select
I
State
. ed I E(Ref5
\
(fO
RAS
i
I
CAS
L
25ns
l
-
50ns
IfnS
-I
)
l
n__
lUUns
W
s
e__
12lns
15 0ins
1'75ns
Figure 2.9: Timing Diagram - VRAM Refresh Cycle
2.2. MODULE DESCRIPTIONS
33
StateE
fer2lKer]3
XfrlX
F_
Line
MuxRAS ---
l
Addr
\Xfer4
_i RefO
=~1
R(
F
Tap
cii
DTOE
i
RAS
i
I
I
---- I
F_
F_
-rn-i
--- I L_ 7_
CAS
-rn-i
i
i
I
i
25ns
50ns
75ns
lOOns
C_
-J 7125ns
150ns
Figure 2.10: Timing Diagram- VRAM Row Transfer
the transfer address from the MUX. The row to be transferred is specified by the nine bits
latched on the falling edge of RAS. The TAP counter is initialized to the nine bits latched
on the falling edge of CAS.
Without an outstanding row-transfer request, the FSM next looks for the FifoOR condition. This indicates that one or more pixels is waiting to be transferred from the FIFO
to VRAM. Although there may be a continuous flood of FIFO data, the controller always
performs a VRAM refresh and possibly a XFER cycle between successive writes. The write
operation is depicted in figure 2.11. The DATAFIFO outputs are directly connected to the
VRAM, so the pixel data will be valid by the time FifoOR is raised. The address must be
selected in the normal multiplexed fashion. At the end of the write, the VRAM uses FifoSO
to shift the data and address out of the FIFOs.
Lowest in priority is the MREAD module, which may be attempting to read a value out
of VRAM. Requests from MREAD will be deferred if there are any outstanding XFER or
FIFO requests, but this is acceptable given the debugging purpose of MREAD. As shown
in figure 2.12, the VRAM distinguishes a VRAM read from a row-transfer based on the
state of DTOEwhen RASfalls. The FSM releases FifoOE to disable the outputs of the DATA
FIFO, allowing the VRAM to use the common bus to drive data into MREAD. This data
is latched by the PixLd signal.
Following the read, the FSM maintains DataACKand awaits the fall of DataREQ,indicating that MREAD has recognized the completion of the read cycle5 . This REQ/ACK
handshaking is necessitated by the the different operating frequencies of the MREAD and
VRAM modules. In operation, the loop only lasts for about two MREAD cycles. Note that
a hardware- or software-level failure in one of the PALs engaging in the handshaking could
'This acknowledgment is presumably being polled by the MDP as discussed in section 2.2.4
CHAPTER 2. PIXEL STORAGE NODE
34
State
MuxRAS
Addr
RAS
CAS
Data
WBWE
Fi f oSO
Figure 2.11: Timing Diagram - VRAM Write
State Edo
MuxRAS
L
wi
1Rd4
~ Rd5 (Rd5
Rd2
!mmmmmmm~l
mmmmmmmmmI
-
Addrl
r% .
|
-£-.-
MiQW
iO
A,
( ,olumr
I
~mmmmmmm
I-
RAS
l
u
1m
DTOE
lI
FifoOE
Data
PixLD
1-
q
-
CAS
hi
|
|
]I
InFro
-
-
|l
l-
PixelOut
mmmmmmmmq
-
.
I
25ns
50ns
II Dns
q f
.LU U
IS
i
1-ir
125ns
Figure 2.12: Timing Diagram - VRAM Read
150ns
2.3. FABRICATION
35
cause MREAD to loop infinitely, allowing the VRAM contents to decay and producing
garbage on the display.
2.3
Fabrication
The form factor used for J-Machine peripheral circuit boards is rather large (11 inches wide
by 15 inches long), so two PSNs fit onto a single circuit board dubbed the Pixel Storage
Board (PSB). Thus, as discussed in section 1.3, the minimum video system configuration
requires two PSBs (four PSN nodes) and a Video Controller board. The PSB has a ground
plane, power plane, and six signal layers.
The PSB has gone through two fabrication runs. The first version of the board differed
from the second in two significant ways: each node had only a single bank of VRAM, and
the two nodes were laid out vertically along the length of the board. Several other changes
were made, most of them bug fixes or format changes.
The effect of the first difference was that twice as many nodes were needed in the
minimum configuration in order to meet the video controller timing requirements. A type
of "pixel funneling" was experimented with along the lines proposed by [12], but this was
changed in favor of the dual-bank/common-pixel-bus approach now in use.
The nodes were rearranged for the second version to keep the two MDPs fairly close to
the ribbon-cable connector that couples them to the J-Machine. In the first version, one
of the MDPs was about 12 inches away from the connector. It is uncertain whether this
layout posed a potential reliability problem, but it was decided to keep the distance between
MDPs as small as possible.
The clock signals were hand-routed to minimize signal reflection. The MDP clock trace
was made as identical as possible to the MDP clock trace on the J-Machine processor boards
in terms of length, signal layer usage, and number of buffers used.
Aside from the MDP and an assortment of registers, latches, and PALs, the PSB required
four specialized types of ICs:
* High speed FIFOs. To easily interface with the EMI bus, these were needed in 9-bit
wide versions for ADDRand in 12-bit wide versions for DATA.The DATAFIFOs also had
to have an output enable for reasons discussed in section 2.2.4. Fortunately, Cypress
Semiconductor manufactures FIFOs that meet almost all of these requirements (an
8-bit and 4-bit FIFO were coupled for DATA).
* VRAM. The Toshiba TC524256BZ-80 chip provided all of the functionality described
in section 2.2.6. Due to their sheer number, the combined cost of the VRAM was
higher than any other portion of the PSN except the MDP. At approximately $12 per
megabit, each 16-megabit PSN requires about $200 worth of VRAM.
* Pixel bus drivers. The registers/drivers needed between the VRAM and the pixel
bus had to combine high speed with high output drive. The Signetics ABT series
74ABT646 provided the solution. The outputs of these tri-state registers can sink 64
mA and source 32 mA, with an average enable/disable time of 5 ns. Although these
chips are only used to drive the bus, they are actually bidirectional. Jumpers were
36
CHAPTER 2. PIXEL STORAGE NODE
added to the PSN so that a future research project could use this input capability to
implement a frame grabber or similar input device.
* Clock receivers. The FCLKand -Esignals used by the VRAM module are supplied by
the VC. To protect these signals from EMI interference, differential signal pairs are
used on the ribbon cables. AT&T manufactures a series of drivers/receivers that use
balanced pseudo-ECL levels - ECL levels shifted by 5V to run on a single +5V power
supply. The PSB uses a 41LR quad receiver to convert the pseudo-ECL signals to
TTL levels. On the other end, the VC uses a 41LP driver to convert and drive the
signals. These chips are also used to transport the MDP clock.
Chapter 3
Video Controller
Where a calculator on the ENIAC is equippedwith 18,000
vacuum tubes and weighs 30 tons, computers in the future
may have only 1,000 vacuum tubes and perhaps weigh 1.5 tons.
-POPULAR
MECHANICS,
March 1949
My primary and cerebralfunctions are now operating almost
entirely from within the computer. They have expanded to such
a degreethat it would be impossible to return to the confines of
my human brain. Any attempt to do so would mean my death.
-LT.
3.1
BARCLAY
in Star Trek: The Next Generation Episode #93
Purpose
The Video Controller (VC) coordinates the flow of pixels in the system and produces an
image on the display. While the Pixel Storage Nodes are busy delivering new pixels to the
VRAM buffers, the VC determines which pixels to fetch, how to interpret them, and where
to place them on the screen. All of the VC modules are configurable - some directly by
software- providing multiple graphical environments.
At the heart of the VC is a Brooktree Bt463 high-performance RAMDAC. When supplied with digital-level pixels and timing signals, this chip generates the analog RS-343 video
signals accepted by many monitors. Every VC module supports the Bt463 in one way or
another. The Timing Module and MPU module directly interface to the Bt463 to provide
clocking and control. The XferAddr Lookup Module and Shift Clock Module provide indi-
rect support by controlling the flow of pixel data. The MDP and FIFO modules direct the
progress of the other modules. And the EMI Readback Module allows the system status to
be monitored.
3.2
Module Descriptions
Figure 3.1 is a block diagram of the VC. An MDP acts as a link between the J-Machine
and the VC. A FIFO provides a data path from the MDP to the other modules without
37
CHAPTER 3. VIDEO CONTROLLER
38
Pixel
Streams
-
a...to display
XferAddr
to PSN bus
32 SClk pairs
to individual
PSNs
Figure 3.1: Video Controller Hardware Modules
constraining their timing requirements. The ERM allows the MDP to check on the status
of the modules. The MPU interfaces to the Bt463 and provides dynamic control over
numerous display options. The XLM dictates which portion of VRAM storage should be
displayed for each scan line, and the SCM selects those VRAMs that should take part in
this process. Finally, the TIM module generates the system clock, pixel clock, and monitor
synchronization signals.
3.2.1
MDP Module
The VC employs the same method to communicate with the J-Machine as the Pixel Storage
Node: an MDP translates certain incoming network messages into EMI accesses, which are
acted upon by VC modules that spy on the EMI bus. Much of the discussion in section 2.2.1
applies, but the traffic seen by the VC's MDP and the PSN's MDP differs in two respects:
* The rate of incoming messages is much smaller on the VC. For many applications,
the only communication with the VC will be to perform one-time initialization of
the display options. Even those applications which modify these options between
successive video frames send only a handful of messages per frame.
3.2. MODULE DESCRIPTIONS
39
* Messages are sent in both directions. In contrast to the one-way flow of pixels into a
PSN, the VC may be asked to reply with messages indicating the beginning of video
blanking periods or the current status.
With these differences in mind, there is little incentive to use anything other than an
MDP as a link to the J-Machine.
Despite its low bandwidth, the EMI interface does
not introduce a bottleneck during the execution of practical graphic applications. One
might take issue with the cost of an MDP versus any alternatives, but the ease with which
messages can be injected into the network by the MDP overwhelms this objection. Still,
some operations performed by the VC MDP are less than elegant: for instance, the MDP
must perform polling to obtain status updates since it lacks a general-purpose interrupt
mechanism.
3.2.2
DRAM Module
The MDP is equipped with the standard ration of 256 KWords of external DRAM memory.
This can be used for program or data storage, but is unused in the current VC software
driver, which was written in assembly and fits within the MDP's internal RAM.
3.2.3
FIFO Module
Design Considerations
The VC's FIFO has the same task as the PSN's FIFO: monitor the EMI bus for transactions
with addresses greater than 0x7ffff,and push the assembled address and data into FIFOs
for use by the rest of. the VC. However, there are now multiple consumers of FIFO data;
the MPU, XLM, and SCM modules are all possible destinations. The FIFO module must
be split into two parts:
* A controller that inserts data into the FIFOs. This controller operates with the same
clock as the MDP so as to decode the EMI signals properly.
* A controller that detects data ready on the other end of the FIFO and directs it to
the appropriate module. This controller must perform handshaking with each module
since the receiver may not be ready to accept new data. The receiver modules all
operate at a higher clock rate than the MDP, so for efficiency this controller is also
operated at the higher rate.
As discussed in later sections, the XLM and SCM modules both make use of to pri-
vate tables during their operation. The "active table" number can be set to increment
automatically at the bottom of every video frame. However, since the modules operate independently, they require a common "reset" signal to align their active table numbers. The
MDP initiates this TabSyncsynchronization by strobing a certain EMI address. Since the
table counters increment together, this is only necessary at start-up or when the number of
tables is changed. The most convenient place to recognize the request to generate TabSync
is in the FIFO module.
CHAPTER 3. VIDEO CONTROLLER
40
EXIFSIK & F1708
MCk-b
FCk-
I
I
rs
/RAS-b 4
/VBlk
L~~~~~~~~~~~~~~~~~~~~~~~~~~~
_
2,
A16,A17
1
sotlL
/CAS--J
MODFSM
26v12
I
/WR-1
OR
ModSel
D
SO
TSynoFF
rahfvne
Q
F74
j
to
ERM
EMIAddr'-EMIDatal-
I
I
I
I Addr
. I
I
from
modules
MpuAck
-'I-
XlmAck
ScmAck
-ba-
(i
fro
Data
Formpu
Foru3M
-- Forscm
to modules
modules
to
Figure 3.2: VC FIFO Block Diagram
Targeted
Module
.II ~
First
Last
Addr Data
ModSel
Valid
Valid
Bits
Bits
A[17:161
Address
Address
Used
Used
0x80000
MPU
00
0x80000
XLM
SCM
TabSync .
01
10
11
0x90000
Ox91fff
OxaOOOO Oxa0fff
OxbOOOO OxbOOOO
0
32
13
12
0
23
13
0
Table 3.1: FIFO Interpretation of EMI Address Bits 17 & 16
3.2. MODULE DESCRIPTIONS
State
(
)
41
HndO
tlewD)
OR
E
-3
I
I
-7
--- d1I
-E
SO
F_
ForMpu
-
F---
=i
MpuAck
25ns
5Ons
75ns
lOOns
125ns
l5Ons
Figure 3.3: Data transfer between FIFO and MPU
Implementation
A block diagram for the FIFO appears in figure 3.2. The dashed block on the left
contains a PAL and set of FIFO chips identical to the PSN's FIFO block shown earlier on
page 24.
MODFSM
is a finite state machine implemented with a 26V12 PAL. Whenever it detects
an output ready condition from the FIFOs, it examines bits 16 and 17 of the captured EMI
write address1 . Using these bits, it hands the data and the lower 13 address bits to one of
the modules according to the memory map shown in table 3.1. Note that not all modules
use all of the address and data bits.
A special "module" that uses neither the address nor data bits is actually the TabSync
signal, which is memory-mapped to address OxbOO0O. TabSync must be delayed by an
external flip-flop to prevent race conditions that can occur if it is asserted too close to
the end-of-frame; because the XLM and SCM modules are running independent FSMs, we
must prevent the possibility that one module sees TabSyncin time to reset its table counter
but the other does not. So although MODFSM
presents the TabSync request to the flip-flop
immediately after receiving it, the flip-flop will pass it through only when the TIM module
asserts and then releases VBlk,indicating the end of vertical blanking. Positioning TabSync
at the beginning-of-frameensures that both modules have enough time to recognize it.
The MPU, XLM, and SCM modules all share the ADDRand DATAbus outputs of the
FIFOs. MODFSM
notifies the module that should accept new input with ForMPU,ForXlm,
or ForSCM.An example of the data transfer routine executed by the FSM is shown in
figure 3.3; upon noticing an output ready condition R, the FSM decodes the MODSEL
bits
in state "NewData" and signals the appropriate module in state "HandoffO."It remains in
this state until it sees an ACKsignal from the module, and then enters "Handoffl" where
it waits for the ACKto go away. The FIFO entries are shifted out by the falling edge of SO
when the FSM returns to the "Idle" state.
1
EMI bit 19 must also be set for the FIFO to have accepted the data in the first place.
CHAPTER 3. VIDEO CONTROLLER
42
MCLK-
ERawsm
22v10B
-- /XLM2ERM
-a- /FIFO2ERM
,>
RAS -CAS -+
WR-
EMIAddr4
-
to XLM
to ERM
/MPU2ZER1
_ /XPU2E1 to MPU
EA10,9,1,0
-0-/MPU2ERM2
-_- ErmAck
ERMBUF
F827
MpuRdy-
/BUFEN
from MPU
MPUSTAT
P. C En
D.
9
_9
to
EMIDATA
8
from modules
from modules
Figure 3.4: ERM Block Diagram
The module selected to receive the new input will not necessary accept it immediately.
The module may have previously received data flagged with a request to delay further
processing until the end of the current scan line (HHOLD
flag) or the end of the current frame
(VHOLD
flag). In such an event, MODFSM
is forced to remain in "HandoffO" until the module
has processed the previous data. Because the new data can't be shifted out, the FIFOs can
subsequently begin to fill up.
The FIFOs have a depth of 64 words, which is enough storage to queue as many EMI
writes as the MDP can produce in a single 16 Us scan line. But if multiple FIFO entries have
their HHOLD
flag set, or if a single entry has its VHOLD
flag set, the FIFOs can potentially fill
up. To allow the MDP to check for the FIFO-full condition, the Input Ready (IR) status of
the FIFO chips is provided to the ERM. Also provided to the ERM, primarily for debugging
purposes, are ForMPU,ForXLM,ForSCM,ORfrom the FIFO chips, and TabSync. The EMI
address from which these status bits can be fetched is revealed in the next section.
A feedback path that allows stalled FIFO data to be pushed out of the way from the
head back to the tail of the queue was considered but ultimately dismissed for three reasons.
First, out-of-order processing might not be acceptable to the application. Second, the
coordination that would be required between MODFSM and EMIFSM(which shifts data into
the FIFOs) added too much overhead. Finally, such transfers could get preempted by new
EMI writes, creating the risk of data loss.
3.2.4
ERM Module
The MDP, acting on behalf of the application, needs the ability to monitor various status
signals within the VC. The EMI Readback Module (ERM) provides this ability, assuming
a role similar to the MREAD module in the PSN. But whereas MREAD was designed to
assist during debugging, the ERM provides information more useful to an application. For
example, it would be difficult for animation programs to know when to update the frame
3.2. MODULE DESCRIPTIONS
43
Data
FIFO
XLM
MPU
Address
Bits
Meaning
0xd0000
0
1
Fifo OR
Fifo IR
OxcOO0
0x80000
or
0x90000
2
TabSync
3
ForMpu
4
ForXlm
5
ForScm
0-3
0-7
12-19
24-31
8
TabCtr
Word 0 from Bt463
Word 1 from Bt463
Word 2 from Bt463
MpuStat
Table 3.2: ERM Memory Map
buffer without being notified when the end-of-frame occurs. And as noted in the previous
section, the MDP must be able to verify the readiness of the FIFO to accept new data
before sending it.
The ERM consists of a single 22v10B PAL and a tri-state buffer, shown in figure 3.4.
ERMBUF
provides isolation between the ErmBus and the EMI bus. ERMFSM,
an FSM running
on the MDP clock, monitors the EMI for read attempts from addresses greater than Ox7ffff.
The FSM interprets these addresses according to the memory map listed in table 3.2. When
a read request is detected, the FSM enables two tri-state buffers - ERMBUF
and a tri-state
buffer in the appropriate module - to drive the EMI bus during its three data cycles2 .
ERMFSM
relies on the FIFO module to prevent bus contention by disabling the external
DRAMs during these cycles.
The status signals provided by the FIFO and XLM modules are asynchronous with
respect to the MDP clock. It therefore behooves the MDP to read the status from these
modules several times in succession to verify signal stability.
Special care is put into reading values back from the MPU module - which provides
not status information, but data fetched from the Bt463. As explained in section 3.2.8,
the actual request for Bt463 data is initiated by an EMI write access through the FIFO
module. When the MPU module finally receivesthe request, it fetches the data and returns
it through the ERM.
Due to the delay that followsan MPU request, the MDP must poll the ERM's MpuStat
flag to determine when the Bt463 data has been fetched. ERMFSM
asserts MpuStat once it
has received an MpuRdysignal from the MPU. The MDP should poll MpuStat using address
0x80000. But the MPU module itself needs to be notified when the data it is providing
has been read by the MDP, so that it can re-use its output buffers for any further data
requests. So once the MDP has detected MpuStat using address x80000, it should make
2
The VC MDP must disable ECC error correction for proper operation.
CHAPTER 3. VIDEO CONTROLLER
44
a final read from address 0x90000. Although the MDP will have already fetched the new
to send an ErmAck back
value along with MpuStat, only an access to 0x90000 causes ERMFSM
to the MPU, freeing it for further processing. The separate addresses are needed to prevent
confusion in the handshaking protocol between MREAD and MPU.
3.2.5
XLM Module
Before a horizontal scan line can be displayed on the screen, each VRAM must be instructed
to perform a "row-transfer" to copy a row of pixels from its primary memory array to its
serial SAM port. This allows rapid, sequential access to the pixels via the SClk shift
clock signal. The particular row to transfer and the starting column within that row are
jointly called a XferAddr transfer address. It is the responsibility of the XferAddr Lookup
Module (XLM) to broadcast the row-transfer request and the 18-bit XferAddr to all VRAMs
during horizontal blanking periods.
Instead of fixing the relation between a row number and its XferAddrin hardware, a
RAM table allows arbitrary mapping. A single table contains 1024 18-bit entries, one entry
for every row of the highest supported resolution. Up to eight tables may be defined in
advance to provide eight logical frame buffers. An XLM write operation can change the
active table (frame buffer) at any time, but to ease the task of animation the tables can
be set to sequence automatically when the end-of-frame occurs. Alternatively, it is possible
to use a single table and simply overwrite its contents when necessary. There is more than
enough time between video frames to modify all 1024 entries in an XLM table.
Figure 3.5 is a block diagram of the XLM. The registers that accept data from the ADDR
and DATAFIFOs are shown on the left. From top to bottom in the middle of the figure
are the scan line counter, the active table counter, the valid table registers, and the XLM
controller. The SRAM is the large block on the right. In the upper right are shown two
flip-flops that are triggered by the horizontal and vertical blanking periods, respectively.
They ensure that the XLM controller notices these events, even though it may be busy at
the time they occur.
The XLM can execute three operations: an XLM write places a new XferAddr entry
into SRAM; an end-of-line update increments the scan line counter and broadcasts a new
XferAddrto the VRAMs; and an end-of-frame update increments the active table pointer.
XLM write
which simultaneously ACKs
asserts XlmACK,
When the FIFO's ForXlmline is raised, XLMFSM
the FIFO module and latches in 22 bits from the DATAFIFO and 13 bits from the ADDR
until ForXm drops, and then decodes the data and
FIFO. XLMFSM maintains XlmACK
address words according to table 3.3.
doesn't immediately perform the write.
If either the HHoldor VHold flag is set, XLMFSM
It instead sets an internal "blocked" flag, which instructs it to process only Eol (end-ofline) and Eof (end-of-frame) events. Once the blocked flag has been cleared by one of these
operations, the new data will be written. Thus, HHold and VHold prevent XLM changes
from taking place mid-line or mid-screen. If neither HHold nor VHOLDis high, the XLM
write commences immediately according to the TYPE of data being received.
3.2. MODULE DESCRIPTIONS
45
J
F112a
XlmAC
From
ADDR
of
Kc
FIFO
9:0
I
I
I
I
i
I
I
I
IRN
I
I
I
I
I
I
I
I
From
ADDR
FIFO
12:10
A[9:0]
2:10]
Line
ble
From
DATA
FIFO
2 x CY7C182
9:0
(8K x 9 SRAM)
1/0[17:0]
II
From
DATA
FIFO
17:10
1
XLMBUFF
2 x ABT823
1
,-18
'I
0 all
-o all
PSNs
From
DATA
FIFO
31:28
For_X
Tabsy
11 PSNs
Figure 3.5: XLM Block Diagram
/OESram
CHAPTER 3. VIDEO CONTROLLER
46
31
30
VH
HH
29
28
|
TYPE I unused]
l
17
0
DATA
-- - -
--
-
-
-
-~~~~~~~~~~~~~~~
I DATA word
VH
VHold - If set, don't perform write until next vertical blanking period
HH
HHold - If set, don't perform write until next horizontal blanking period
DATA
The TYPE-specific data to be used
TYPE
The type of data being specified:
Write DATA into SRAM location specified by ADDR bus
Set LVT register = DATA[2:0], FVT register = DATA[5:3]
Set FLAGS register = DATA[2:0] (for future use)
00 Xfer Address
01 Valid Tables
Flags
11
12
10
9
0
&
I TABADDR
I
LINEADDR
1 ADDR
word
3 upper bits specify one of eight tables. The active
s cycled
between the FVT and the LVT register values.
10 bits specify one of 1024 scan lines. The active
unter is incremented at the end of each scan line.
Table 3.3: XLM Usage of Data and Address Bits From FIFO
* If the TYPE is 00, the 18 bits of DATA specify a XferAddr,and the 13 bits of ADDR
specify the scan line (lower 10 bits) and table number (upper 3 bits) that should
contain this XferAddr. The SRAM store is performed with the DrvAddr, DryData,
and WRSram
control lines.
* If the TYPE is 01, the Last Valid Table (LVT) register is loaded from DATA[2:0]
and the First Valid Table (FVT) register is loaded from the DATA[5:3] by asserting
DrvData and LdVT. The registers are maintained in TABPAL,which also contains a
comparator that checksthe active table counter against LVT.
* If the TYPE is 11, the lower 2 bits of DATA are stored in a 2-bit register in TABPAL
by asserting DryData and LdFlags. These flags are for "future use" and are currently
ignored by the XLM.
Once the FSM has processed the data according to its type, it loops back to wait for
another ForXlm,Eol, or Eof signal.
End-of-line update
fetches an 18-bit XferAddr from SRAM and
If Eol goes high but Eof remains low, XLMFSM
array
to
use
it to perform a row-transfer. If Eof is also
instructs every VRAM in the PSN
will perform an end-of-frame update before the end-of-line update.
high, the XLMFSM
3.2. MODULE DESCRIPTIONS
47
The XferAddrvalue at the SRAM location pointed to by TABCTR
and LINECTR
is latched
into the XLMBUFF
buffers by asserting DrvCtrs and OESram.
Transfer is raised to advertise
a valid address on the broadcast bus and to request each of the PSN nodes to perform the
row-transfer. LineInc is then asserted to increment the LINECTRin preparation for the
next end-of-line update.
Next, if XLMFSM's
internal "blocked" flag has been set, an XLM write is awaiting execution. Either HHold or VHold will be set; if HHoldis set, XLM write is always performed
and the "blocked" flag is cleared; if VHold is set, XLM write is not performed unless Eof is
also high; if VHold is set but Eof isn't, XLMFSM
re-enters the tight loop that checks only for
Eof or Eol.
If "blocked" hasn't been set, XLMFSM loops back to wait for another ForXlm, Eol, or
Eof. In all cases, ERes is asserted to clear the Eol (and possibly Eof) condition.
End-of-frame update
If Eof is detected, LINECTRand TABCTRare updated before performing the end-of-line
update (Eol will always be true when Eof is true). LINECTR
is reset to zero by asserting
LineRes. If Tabsync is high, TABCTR
is reset to the value in the FVT register by asserting
TabLd. Otherwise, TABCTR
is compared against the value in the LVT register by checking
Eot. If Eot is high, TABCTR
has reached the last valid table and is loaded with FVT.
Otherwise, TabInc is asserted to increment TABCTRby one.
An end-of-line update is then performed.
3.2.6
SCM Module
Design Considerations
The Shift Clock Module (SCM) generates the SClk signals used to sequence through the
pixels in VRAM. With two VRAM banks per PSN and a maximum of 16 PSNs per video
system, the SCM needs to generate and distribute up to 32 separate SClk signals.
The SClk signals do more than shift pixels out of the VRAMs; they determine the very
access patterns made into the PSN array and implicitly provide pixel bus arbitration. The
figure below shows that between every VRAM and its pixel bus is register/driver chip. SClk
is not only fed into the VRAM - it also latches the register and is used as the output enable
for the driver. So while the low-to-high transition of SClk transfers data from the VRAM
to the register, the data is not driven onto the pixel bus until SC1knext goes low (which
would only be in preparation for the next data transfer). In effect, a pipeline stage has been
formed.
e
8C~k-
VRAM
'BANK
;32
SI~~~Cl~~~~k~
> REGISTER
-_-_ -_
-_ -_
DRIVER
32b
32
Pixel Bus
SCk8
Idle;anotherVRAMbank
must drivepixelbus
Pixel N
t ransferred
from
VRAM to Register
N
J
Pixel N
driven onto
pixel bus
PixelN+l
transferredfrom
VRAM
toRegister
CHAPTER 3. VIDEO CONTROLLER
48
The SCM does not support completely arbitrary access patterns made into the set of
all VRAM banks. Since each PSN has two VRAM banks driving the same pixel channel, it
is pointless to enable both of them onto the channel simultaneously. The two SClks sent to
an active PSN are therefore asserted alternately, pulling data from the even VRAM bank
one cycle and the odd VRAM bank the next. Indeed, as discussed earlier in section 2.2.6,
the VRAM banks were created with this alternating access in mind.
At least four PSNs must contribute pixels to a scan line because precisely four pixels are
needed every LdClk cycle (LdClk is a clock running at one-quarter the true pixel rate; four
pixels are loaded into the video controller every LdClk cycle, and the video controller spreads
the pixels across the next four display columns using the true pixel clock). Therefore, in a
minimum configuration with four PSNs, every PSN must contribute to every scan line. But
when more PSNs are installed, the update rate of the display can be increased by allowing
more nodes to contribute to a single scan line. So the SCM is designed to use either four
or eight PSNs per scan line. If eight PSNs are used, four of them deliver pixels during
even-numbered LdClk cycles and the other four deliver pixels during odd-numbered LdClk
cycles.
It is important to distinguish the three levels of interleaving:
1. Interleaving between VRAM banks. Consecutive pixels from a given PSN are fetched
from alternating VRAM banks by interleaving its two SClk signals.
2. Interleaving between PSN nodes. Four pixels are driven simultaneously by four separate PSNs during every LdClk cycle. The video controller ingests these pixels all at
once but then distributes them across the next four display columns; this is column
interleaving.
3. Interleaving betweengroups of PSN nodes. If eight PSNs are contributing to a scan
line, four of them provide pixels during even-numbered LdClk cycles and the other
four provide pixels during odd-numbered LdClk cycles.
If just four PSNs are contributing to a scan line, only the first two types of interleaving
occur. Figure 3.6 illustrates the SClk timing in this case. Shown are the separate SClk
signals that drive the two VRAM banks of a single PSN. These two banks alternately drive
the connected pixel channel every LdClk cycle. Because of the second form of interleaving
in the above list, the pixels fetched from the PSN as a whole supply columns 0, 4, 8, 12,
etc. Because of the first form of interleaving, bank A supplies columns 0, 8, 16, etc. and
bank B supplies columns 4, 12, 20, etc. All remaining columns are supplied by the other
three participating PSNs.
Since the two SClks shown are complements of each other, one might be tempted to use
the true and inverted versions of a single SClk supplied by the VC. Although inversion can
be accomplished by flipping the SClk ECL lines before sending them through the ECL-to-
TTL converter, this wouldn't reduce the VC logic needed to generate the SClks: the VC
must still support the one-of-eight PSN scan line mode.
Figure 3.7 shows the timing for scan lines with eight contributing PSNs. Now, the third
form of interleaving means that this PSN as a whole supplies columns 0, 8, 16, 24, etc. Of
these columns, bank A supplies 0, 16, 32, etc. and bank B supplies 8, 24, 40, etc. The other
seven contributing PSNs supply the remaining columns.
3.2. MODULE DESCRIPTIONS
49
FSM Cycle 0 -F----SM
Cycle 1 I
SClkO
Bank A
SClkO
Bank B
I
Pixel n|
Chane
.. 1
P ix
N /ix
VidVid
| Cycle 0
Video
Cycle 1I
IColuCol
C
L
Oa
la
Video
Cycle 2
Video
Cycle 3
4olumnColumn
DisplayrT
y-yyy
-T
Rows
)/PixBN+l/\PixAN+2/h.
N /\PixAN+l
f*t5!
I2a 3a
Colun Col
12
yyyy
Ob
lb
Display
Columns
Video
Cycle 4
2-
3b
Oa
umn 1
y-
Ob
\
/
Node
Bank
Figure 3.6: Shift Clock Timing for a One-Of-Four PSN
------- FSM
Cycle
0----I ~~
~
~
-'
~
I
SClkO
Bank B
I~~
Pixel
Pixel
Channel
A
~/Drivanby\
ano
Pix N / \noe
Video
Cycle O0
Video
Cycle
tB
Pix N
I
I Column OJ-Column 4
Displayr~7
Rows
7
Display N B
Columns
{
1
h/'rivenbY\A
eanother
node
I
Video
Cycle 2
Column 8
7
Video
Cycle 3
Pix N+1
I
Video
Cycle 4
I
Column 12 Column 16
7 7 7
.0a1a.a3a6.
n
Node
Bank
Figure 3.7: Shift Clock Timing for a One-Of-Eight PSN
CHAPTER 3. VIDEO CONTROLLER
50
Although the same four or eight nodes are used for the entire scan line, other scan lines
need not use the same nodes. Like the XLM, the SCM uses an SRAM table to fetch the
configuration for the current scan line. Unlike the XLM, the SCM does not need to allow
up to 1024 unique configurations, one for every scan line; there aren't 1024 ways to access
(at most) 16 PSNs. So the SCM allows up to sixteen different configurations to be defined
during a single frame, and will sequence through each of them on consecutive scan lines.
The SCM wraps around to the first configuration when the last valid (LVL) configuration
has been reached, and will continue to cycle through the list for the entire video frame.
This list is allowed to have just a single entry if every scan line uses, the same PSNs.
In this context, the list of all valid configurations to be sequenced is called a "table." An
application may find it desirable to use different tables for different video frames. Separate
tables can be used to create logical frame buffers, using certain PSNs for one buffer and
other PSNs for the next 3 . So the SCM provides space for up to eight tables (each with up to
sixteen configuration entries). The active table pointer can be incremented automatically
at the end-of-frame. "First Valid Table" and "Last Valid Table" registers specify the range
of tables to use; an identical protocol was discussed in the XLM section.
Figure 3.8 depicts the general structure of the SCM. The SRAM in the middle is shared
between two blocks clocked at different frequencies. ScmCtrl on the left, clocked by the
same 40 MHz FClk used by most of the VC modules, communicates with the FIFO. One of
its responsibilities is to await new SClk table data and write it into SRAM.
ScmCtrl is also the caretaker of the Go flag. Bad table entries can cause damaging bus
contention by driving more than one VRAM bank onto the same pixel bus at once. The
SCM cannot detect this conflict, but a special measure is taken to prevent contention due
to garbage in the SRAM following a power cycle: the SCM will only operate when the Go
flag has been set. Go gets cleared by a system reset or power-cycle, and must be explicitly
set by the J-Machine application (after it has initialized the SRAM with valid data).
When ScmCtrl sets Go at the request of an application, the SClkGen block on the
right proceeds to fetch data from SRAM to generate up to 32 SClk signals. To keep the
SClks synchronous with the Bt463 video controller, SClkGen needs to be clocked by LdClk.
To determine which SClksto assert, SClkGen uses that configuration indexed by the line
and table counters, which are updated during horizontal and vertical blanking periods
respectively. The TTL clocks generated by SClkGen are converted to pseudo-ECL logic
levels before being transmitted over twisted pairs to the individual VRAM banks.
ScmCtrl Implementation
The overall structure of ScmCtrl is similar to the XLM, and includes:
* Registers that accept data from the FIFO;
* An FSM that decodes the FIFO data. Table 3.4 describes how the DATAand ADDR
words are interpreted;
* Flip-flops triggered by the horizontal and vertical blanking periods;
3
in contrast, separate tables in the XLM allow certain portions of VRAM to be used for one logical buffer
and other portions for the next.
3.2. MODULE DESCRIPTIONS
51
.le
---
from F.
-
to
r
ECL
L--i
to E
~
.
to
VRAK
banks
I
LdClk ---
I
Figure 3.8: General Structure of SCM module
VH
HH
31
30
29
28
I VH
HH
TYPE
3
unused
0
DATA
I DATA word
VHold - If set, don't perform write until next vertical blanking period
HHold - If set, don't perform write until next horizontal blanking period
DATA
The TYPE-specific data to be used
TYPE
The type of data being specified:
00
01
10
11
NUT Entry
Valid Tables
Last Valid Line
Go Flag
11
9
Write DATA[3:0] into SRAM location ADDR
Set registers LVT = DATA[2:0], FVT = DATA[5:3]
Set LVL register = DATA[3:0]
Set the Go flag equal to DATA bit 0.
8
5
4
0
l TABADDR I LINEADDR I NUTADDR I ADDR word
TABADDR
These 3 upper bits specify one of eight tables. The active
LINEADDR
These 4 bits specify one of 16 scan lines. The active
line counter is cycled between 0 and the LVL register.
An index into the Node Usage Table for the given table and
line. The Node Usage Table contains 9 entries.
table is cycled between the FVT and the LVT register values.
NUTADDR
Table 3.4: SCM Usage of Data and Address Bits From FIFO
CHAPTER 3. VIDEO CONTROLLER
52
* PALs which implement the FVT and LVT registers and the Go flag. The PALs also
perform line and table counting similar to the way it is accomplished by the XLM.
One important difference is that the output enables of these counters are controlled
by the SClkGen FSM, not the ScmCtrl FSM. Handshaking takes place between the
two FSMs to arbitrate access to the SRAM and counters.
The complete schematics and PAL file listings for the ScmCtrl block appear in the
appendix; since it is very similar to the XLM logic, attention shall instead be turned to the
SClkGen block.
SClkGen Implementation
The individual SClk signals are best thought in terms of pairs, since each PSN requires two
of them for its two VRAM banks. Each of the SClk pairs is implemented as the lower two
state bits of a finite state machine that simply loops throughout the entire scan line. Before
the scan line begins, the FSMs (one for every PSN) are told how to behave for that line.
This "behavior" is determined by three flags:
1. An active flag. Unless this flag is set, the FSM remains idle for the entire scan line
and the following two flags are ignored.
2. An odd flag. Only applicable in 8PSN mode (below). If set, the initial state for the
FSM will be such that the associated PSN supplies pixels during odd-numbered LdClk
cycles. Otherwise, the PSN supplies pixels during even-numbered LdClk cycles.
3. An 8PSNflag. If set, the FSM will loop through the following state transition table:
Q2
0
Q1
0
Q0
(Initial state if odd is false)
1
0o
o
0
0
i
0
1
0
0
(Initial state if odd is true)
If the 8PSN flag is clear, the FSM will loop through the shorter transition table:
Q2
Q1
QO
0
0
1
0
1
0
(Initial state)
Note that the last two state bits of an "active" FSM create the SClk patterns shown
earlier in figures 3.7 and 3.6.
A "Node Usage Table" in SRAM contains the above three flags for every PSN in the
system. The table consists of sixteen 2-bit entries and a 1-bit flag using the following format:
3
2
ConfigN01
ConfigN02
1
0
Co figN00
ConfigN03
+- bit
ConfigN14
I18PSN
Word 7
Word 8
......
ConfigN15
Word 0
Word
1
53
3.2. MODULE DESCRIPTIONS
Each ConfigNxx field in the table corresponds to a different PSN. The high and low bits
of the field specify the active and odd flags, respectively. The global 8PSN flag at the end
of the table is used by all of the FSMs.
In 8PSNmode, exactly eight of the 16 entries should have their active flag set. Of those
eight, four should also have their odd flag set. If the 8PSN flag is not set, then exactly four
of the 16 entries should have their active flag set, and the odd flags are ignored.
Before concluding this section, some examples may help to clarify SClk generation:
1. In a system with four PSNs, there is only one valid SCM table because all four PSNs
are needed every LdClk cycle of each scan line:
1
0
Nodes 1 and O will be active
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Nodes 3 and 2 will be active
All other nodes are inactive...
0
0
WO:
1
Wi:
W2:
1
0
0
0
0
0
0
0
W3:
W4:
W5:
W6:
0
W7:
W8: 0
We're not in8PSNmode
This table produces the following access patterns into the VRAM banks:
Oa la 2a 3a Ob lb 2b 3b Oa la 2a 3a..
LdClk 0
LdClk 1
LdClk 2
which uses PSN interleaving within a LdClk cycle and VRAM bank interleaving between LdClk cycles.
2. In a full video system with 16 PSNs, numerous SCM tables can be defined. The
following table retrieves pixels from eight of the 16 PSNs:
WO: 1
WI1: 1
0
0
1
1
0
0
Nodes 1 and 0 active during even LdClks
Nodes 3 and 2 active during even LdClks
1
1
1
1
Nodes 5 and 4 active during odd LdClks
W3: 1
W4: 0
1
0
1
0
1
0
Nodes 7 and 6 active during odd LdClks
All other nodes are inactive...
W5:
W6:
W7:
W8:
0
0
0
0
0
0
0
0
0
0
0
1
We are in 8PSN mode
W2:
0
0
0
0
This table produces the following access patterns into the VRAM banks:
pa la 2a 3a 4a 5a 6a 7a Ob lb 2b 3b 4b 5b 6b 7b Oa la 2a 3a.
LdClk 0
LdClk 1
LdClk 2
LdClk 3
LdClk 4
which interleaves at three levels: the PSNs within a LdClk cycle; groups of PSNs
between LdClk cycles; and VRAM banks between every other LdClk cycle.
CHAPTER 3. VIDEO CONTROLLER
54
I
I
I
I
I
I
I
I
SCM State
with delayed
LdClk
SClkA
BufOutA
Bt463
ZdClk
Figure 3.9: Preventing LdClk Timing Violations with a Delay Line
3.2.7 TIM Module
The various timing signals used throughout the video system are supplied by the timing
module (TIM). As described in this section, the logic required to generate these signals
varies from a simple, self-contained support chip to a more complex FSM with counters and
a PROM table.
VidClk and LdClk
The VidClk video clock runs at the pixel rate of 111.5 MHz. The only component that
requires the full pixel rate is the Bt463 video controller. However, the ECL-level VidClk
passes through a Brooktree Bt438 support chip on its way to the Bt463.
The Bt438 divides the VidClk frequency by four to produce a TTL-level LdClk signal
that instructs the Bt463 when to accept four new pixel values. The Bt463 requires both
VidClk and LdClk to perform 4:1 pixel multiplexing.
LdClk as delivered to SCM
The LdClk signal delivered to the SCM module is used to generate the SClk signals sent
to the VRAM banks. It is almost identical to the LdClk delivered to the Bt463; the only
difference is that it is disabled during blanking periods to give the VRAM an opportunity to
3.2. MODULE DESCRIPTIONS
55
perform row-transfers; the VRAM specifications do not allow an active SClk during these
operations.
The Bt438 actually produces two versions of LdClk. A version that is always active is
sent to the Bt463. Another version that can be disabled is sent to the SCM. The Blank
signal described below is used to disable this version of LdClk.
The upper part of the figure 3.9 shows a timing violation that would occur if we were
to allow LdClk to directly clock the SClk FSMs. The edges of LdClk and SClk would
nearly align, which would be unacceptable since SClk is also used as an output enable onto
the pixel bus. The hold-time following a rising Bt463 LdClk would not be met. Thus,
LdClk is passed through a tapped-delay line before being used by the SClk FSMs. This
programmable delay, with a nominal delay of one-half the LdClk period, pushes the outputenable periods further into the next LdClk cycle. As shown in the bottom part of the figure,
this allows the hold-time to be met.
Blanking and Sync signals
The Bt463 requires composite Blank and Sync TTL inputs so that it can generate the
analog video synchronization signals needed by the monitor. In addition, various modules
in the VC need to be alerted when horizontal blanking (HB-k) and vertical blanking (VB-k)
periods begin.
The TIM module generates these four signals with a 13-state FSM, two 16-bit counters,
and a small table in PROM. At various stages in the FSM, the table entries are transferred
from the PROM to the counters, which then count either LdClkcycles or HBlk cycles (where
HBlk itself is generated by the FSM). Those entries in the following table with units of LdClk
cycles are based on a 27.875 MHz LdClk (derived from a 111.5 MHz VidClk).
Parameter
HFrontPorch
Cycles
Value Counted
12
LdClk
Time
(Us)
0.466
HSync
HBackPorch
38
54
LdClk
LdClk
1.40
1.97
HActive
HLinesActive
HLinesInVFP
339
897
6
LdClk
HBlk
HBlk
12.20
-
HLinesInVBP
31
HBlk
-
HActiveInVBlk
411
LdClk
14.78
68
LdClk
2.48
Description
Blanking time between end of scan
line and beginning of horiz sync
Duration of horizontal sync pulse
Blanking time between end of horiz
sync and active scan line
Duration of active scan line
Number of active horizontal scan lines
Number of off-screen scan lines at
bottom of display
Number of off-screen scan lines at
top of display
Time between horiz sync serrations
during vertical blanking
HBPaVBP
Length of horiz sync serrations
during vertical blanking
HLinesInVS
4
HBlk
-
Number of horiz sync serrations
during vertical sync
CHAPTER 3. VIDEO CONTROLLER
56
31
VH
30
HH
29 28
unused
27
RW
26
WC
16 15
25 24 23
IWordl
Cl,Co I Word2
8
0
7
WordO
I
VHold - If set, don't perform access until next vertical blanking
VH
HH
HHold - If set, don't perform access until next horiz blanking
Selects either read access (1) or write access (0)
RW
WC
Word Count - Access is a long (1) or short (0)
C1,C0 Control lines fed directly to Bt463; help determine MPU address
WordO First byte to write in a "long" access
(Only byte to write in a "short" access)
Wordi Second byte to write in a "long" access
Word2 Last byte to write in a "long" access
Table 3.5: MPU Usage of Data Bits From FIFO
3.2.8
MPU Module
The MPU module allows the application to read from or write to the MPU interface of the
Bt463 video controller. This provides access to things such as the Bt463 control registers
and color palettes. Some of these locations are read-only, but most of them are read/write
and require initialization to properly set up the Bt463.
A potential source of confusion is the manner in which MPU reads are performed by
the MDP. The only way to get information (including a request for return data) from the
MDP to the MPU is through the FIFO, but the FIFO only accepts data when the MDP
writes to its EMI. So both MPU reads and writes require the MDP to write a value to some
memory-mapped address. A flag within the data word itself indicates whether the MPU
access should be handled as a read or write.
Figure 3.10 shows the organization of the MPU module. As with most VC modules, some
registers (on the left) accept data from the FIFO under the control of an FSM (bottom).
Another set of registers (right) provide configuration data read out of the Bt463 to the
ERM. The MPU interface of the Bt463 is shown in the middle.
The complete Bt463 MPU interface is detailed in the Brooktree data sheets. Its data
bus is only eight bits wide, but some of the configuration entries are 24 bits wide. Thus,
depending on the specific location, reads and writes require either one cycle or three cycles.
how many cycles
A Word Count (WC) flag in the data sent by the MDP informs the MPUFSM
the access requires, and should be consistent with what the Bt463 expects. The R/Winput
selects either a read or write, and is fed directly from the data word coming from the FIFO.
interprets the FIFO data. Note that unlike other modules,
Table 3.5 details how MPUFSM
none of the ADDRFIFO bits are used. The Bt463 has some internal counters which, along
with the C1 and COlines, specify the address. These counters automatically increment after
each access, and can be set to specific values through the data lines.
If the MPU access is a read, the appropriate data will be loaded by this module into
registers in the ERM module. After the read is complete, the MPU module signals the ERM
3.2. MODULE DESCRIPTIONS
57
DATAO
K"UYU
MpuA
Frox
DATJ
FIF(
7:0
From
DATA
to
FIFO
15:8
ERM
From
DATA
FIFO
23:16
to FIFO
buffers
From
DATA
FIFO
31:24
to output
buffers
to Bt463
ForMpu
to ERM
Figure 3.10: MPU Block Diagram
>MX_'>EYUm.
CHAPTER 3. VIDEO CONTROLLER
58
module so that it can in turn provide the data to the MDP. This protocol was described
earlier in section 2.2.4.
Bt463
3.2.9
All of the modules described in this chapter have a single unified purpose: to provide control,
timing, and pixels for the Bt463 video controller. The Brooktree part was selected because
it met two criteria:
* It is configurable. Many RAMDACs have rigid behavior and rely on copious support
logic to provide such features as variable colormaps and plane depth. The Bt463, on
the other hand, provides internal colormaps and pixel depth that can vary by pixel.
These two features can be combined to compress multiple pixels into a single 32-bit
word; as shown in the next chapter, this compression can be used to increase frame
buffer storage and bandwidth.
* It provides 4:1 multiplexing. This scheme requires four pixels to be presented at the
same time, but quadruples the period length between fetches. This allows most of
the PSN and VC modules to operate at one-quarter the pixel rate, a reasonable speed
for TTL logic. If the modules had been required to work at the full 111.5 MHz, the
system would require a faster logic family and delicate timing analysis.
The examples in the next chapter demonstrate the flexibility provided by the Bt463
video controller, and the J-Machine video system as a whole.
3.3
Fabrication
Only a single fabrication run of the VC board could be made, but few bug fixes were
required. The most visible modification is the addition of a fourth BNC connector next to
the red, green, and blue outputs of the Bt463. This connector makes the composite Sync
signal (generated by the TIM module) available to the display. The initial design did not
include this connector because the Bt463 has the ability to superimpose the Sync signal
on top of the green output. Many newer monitors support the "sync on green" standard,
but the funds for such a monitor became unavailable. As a result, the system uses an older
monitor that requires a separate Sync signal.
Some very specific Bt463 layout recommendations from Brooktree were implemented.
For instance, the board fabricator was asked to control the impedance between each of
the six signal layers and the power planes to an optimal 75Q. In addition, two "fingers"
delineate the area between the Bt463 and the video output connectors; these fingers do not
have any copper in their signal and power layers. They prevent current loops on the board
from affecting the video outputs.
Finally, the usual precautions were taken with the clock signals, hand-routing them and
providing termination at the end of long runs. The complementary outputs of the various
ECL clocks were run parallel to each other to improve their immunity to EMI interference.
Chapter 4
Configuring the Video System
One machine can do the work of fifty ordinary men.
No machine can do the work of one extraordinary man.
-ELBERT
GREEN HUBBARD
It is the quality rather than the quantity that matters.
- Lucius
ANNAEUSSENECA(4 BC - AD 65)
The J-Machine video system supports a variety of configurations. Some of the parameters that establish these configurations need to be changed only when more PSNs are added
or a different monitor is used, so they are determined by jumpers and PROMs. Others
affect how the application interacts with the system and need to be changed frequently.
These are set with software routines that modify various registers and RAM tables.
This chapter presents some sample configurations of the video system. It describes
the parameters that can be changed and the effects they produce. It also examines some
methods useful in a minimum-sized system to compensate for its smaller bandwidth and
storage capacity. This chapter makes liberal use of the terms and concepts discussed in
Chapters
4.1
2 and 3.
Number of Pixel Storage Nodes
Up to sixteen PSNs may be installed to increase the aggregate network bandwidth between the J-Machine and video system. Sufficiently parallel applications can use this larger
bandwidth to achieve faster updates and smoother animation. The effects of scaling were
illustrated earlier in table 2.1. It is not necessary to connect the same number of PSNs to
each pixel channel. The VC requires only that at least one PSN connect to each of the four
channels.
Two issues should be addressed before installing more than the minimum requirement
of four PSNs:
1. Bandwidth. Although the maximum frame buffer bandwidth increases with PSN
count, it will go unused unless the rendering application has a sufficient degree of
parallelism. If only a handful of J-Machine nodes are producing pixel data for a full
screen animation, the refresh rate is dominated by computation time, not bandwidth.
59
CHAPTER 4. CONFIGURING THE VIDEO SYSTEM
60
2. Storage capacity. Improvements in bandwidth cannot be made without an increase
in VRAM storage capacity, regardless of the application's desire or ability to use this
expensive extra storage.
The second point assumes that one doesn't build socket adapters that allow the 256Kby-4-bit VRAMs to be replaced with less costly VRAMs with a smaller address range. Alternatively, if one is willing to dispense with the flexibility provided by 32-bit words, certain
VRAM sockets may be left empty. The value of maintaining 32-bit words is demonstrated
later in this chapter.
4.2
Display Resolution
The display resolution of the video system is fixed by the frequency of the pixel clock. This
frequencyis related to the horizontal resolution (RH), vertical resolution (Rv), and monitor
refresh rate (Nfps) by
f=f
RH
Nfp..Rv -
(7 x 10-6)
where N 1 .Rv is the time allowed per scan line if Rv scan lines must fit within a single
screen refresh period (N-) Of this time, the RS-343 synchronization signals consume 7#s,
with the remaining time available to display RH columns.
If the pixel clock is changed, so must the TIM module's PROM table entries 1 listed
earlier in section 3.2.7. Although the Bt463 is compatible with any pixel clock below
135MHz, an arbitrarily slow pixel clock cannot be used because TIM generates its signals by
counting cycles of LdClk, whose period is one-quarter that of the pixel clock. If a very slow
pixel clock is used, the granularity of the counting process erodes and the synchronization
signals fall out of tolerance.
Some monitors look for synchronization signals superimposed on the green video output,
while others require a separate sync signal. Although the J-Machine video system was
intended for use with the first type of monitor, a SYNCconnector was added to support the
second type. The Bt463 supports both types, selectable with a control register.
The resolution of the monitor currently used by the video system is 1280 columns by
900 rows.
4.3
Starting an Application
This section lists some start-up activities required by a simple J-Machine video application.
An interface for each of these activities is provided by a C library call.
'The TIM PROM table is large enough to hold 32 separate tables; the active table is specified by jumper
pins.
4.3. STARTING AN APPLICATION
61
1. Initializing the Bt463. These Bt463 registers, accessible through the MPU module,
must always be set when an application starts up:
CommandReg0
CommandReg1
CommandReg2
MaskRegisters
0x40 Select 4:1 multiplexing
OxOO0 Use upper 4 pixel bits as overlay planes
OxO0O No sync on green, no IRE blanking pedestal
OxFF Enable all bits of pixel word
2. Initializing the window types. The Bt463 requires that each pixel word be tagged with
a 4-bit value called a "window type" (WT). A set of sixteen registers in the Bt463
specify how the word possessing each WT should be interpreted. The WT determines
the followingattributes of the pixel:
* Display mode. The display mode can either be true-color (where the R,G, and
B values are contained in the pixel itself) or pseudo-color (where the entire pixel
is treated as a colormap index from which to retrieve the R,G, and B values).
* Number of planes. In true-color mode, this corresponds to the number of bits in
each R,G, and B field (from 0 to 8). In pseudo-color mode, it corresponds to the
number of bits in the colormap index number (from 0 to 9).
* Starting position within the data word.
* Starting address of colormap. The colormaps, discussed below, are contained in
the Bt463.
It should be emphasized that the WT tag allows these characteristics to be specified
on a pixel-by-pixel basis.
A simple application using 24-bit true-color pixels might write (ode=TrueColor,
NumbPlanes=8, Start=O, Colormap=O)into WT register zero and then ensure that
all pixels ae tagged with WT=0.
3. Initializing the colormaps. Both true-color and pseudo-color display modes use col-
ormaps to translate pixels into values that drive the R, G, and B digital-to-analog
converters:
* In true-color mode, three independent colormaps are indexed by the three pixel
fields. A simple application might simply load each 256-entry colormap with
values from 0 to 255. An advantage gained by using true-color mode is that all
224 available colors may be specified by a single 24-bit word.
* In pseudo-color mode, a single colormap is indexed to determine the values for
all three DACs. When an application needs to display a pixel with a new color, it
allocates a colormap entry and uses its index as the pixel's value. An advantage
gained by using pseudo-color mode is that fewer bits are necessary to specify a
color.
Figure 4.1 illustrates the use of colormaps in true-color and pseudo-color modes to
produce the same color. The same set of colors is accessible to both modes, but
CHAPTER 4. CONFIGURING THE VIDEO SYSTEM
62
Red
Colonnap
/.
True-colo r mode:
/
I
' iI/
--
-
-
_-I..
FRW
m
Green
Colormap DE
DAC
DO
G
//
II
I
I
II
I
I
DE
86
.
Pixel
I
/
a
19
F-Red
Pseudo-color mode:
{
07
PIxel
07
DO
I
|
se
s0
>I
R
aoc
o
Single
Colo~ap
SingleClr a
Figure 4.1: Displaying the Same Color Using True-Color and Pseudo-color Modes
in pseudo-color mode only 512 of these colors may be used at once. Note that the
true-color example adjusts the values of the R, G, and B fields before sending them
to the DACs. The application has set the colormap to implement a technique called
"gamma correction," which compensates for non-linearities in the color response of
the monitor, as well as non-linearities in intensity as perceived by the human eye.
Multiple colormaps can exist at once within the Bt463, which is why the WT must
specify the starting address of the pixel's colormap.
The next two sections describe the steps that are taken after the initialization in this
section has been performed.
4.4
Initializing the XLM
At least one XLM table must be initialized to specify the segment of VRAM to display.
The table contains a XferAddr entry for every scan line of the display. These examples all
assume a display resolution of 1280x900, so the last table index used by the XLM is 899.
4.4. INITIALIZING THE XLM
4.4.1
63
Single-line frame buffer
A very simple XLM table has all of its entries set to the same XferAddr, for example:
000: $0
001: $0
002: $0
898: $0
899: $0
Here, row zero of VRAM is used to produce every single scan line. Though not not very
practical except for screen fills, this type of table proved useful during testing. One of the
first images produced by the video system was a color test pattern; since the pattern simply
contained vertical bands of color, there was no need to make any line look different from
the others.
4.4.2
Single-screen frame buffer
Most of the time, an application would like to allow each scan line to look different from
the rest, so the XferAddr entries will differ. Assuming that four PSNs are used per scan
line, a useful XLM table is:
000:
001:
002:
003:
$0
$200
$400
$600
898: $70400
899: $70600
Notice that XferAddr increases by 0x200 (512 decimal) on successive scan lines. With 1280
columns, the four PSNs are each responsible for providing 320 pixels per scan line, so why
increment XferAddr by 512? The answer to this question lies in the VRAM architecture.
The VRAM segments XferAddr into two parts: the upper nine bits specify which of the
VRAM's 512 rows to transfer, and the lower nine bits specify the starting column of the
shift register's SAM pointer. Once the SAM pointer reaches the end of the row, it wraps
around to the first column of the same row, not the next row. Suppose the second entry
in the table above were instead set to 0x140 (320 decimal), which is actually located in
the first row of VRAM. Then, only the first (512- 320) x 4 =768 columns of the second
line would differ from the first. The remaining portion of the second line would begin to
duplicate the first line.
Figure 4.2 illustrates the wasted VRAM in this simple configuration. The last 192 words
of each VRAM bank become unusable for the first 900 rows. The remaining 1024 - 900 =124
rows supply a small amount of off-screen storage, but not enough to fill a screen. Methods
to reduce the wasted VRAM are explored later in this chapter.
CHAPTER 4. CONFIGURING THE VIDEO SYSTEM
64
320 active
320 active
320 active
320 active
$0
900
active
lines
$200
$400
$600
$70600 |Z
70800
124
off-screen
lines
worda
words
word
word
320 ative words
52t p; ntially
ativ
$70AO
320 potentiallyactive
$70DO
320 potentially
ad
ord
active word
!
Figure 4.2: Single-buffer VRAM Usage with Four PSNs per Scan Line
FrameBuffer
I
.
$0
900
active
lines
tiv
word.
FrameBuffer
2_
160 active
FrameBuffer
I
_
160 active
wor.
d
160 active words.
160 active word.
160 active
$400
160 active words
160 active words
160 active wrds
$600
160 active word
160
160
160
$70800
$70A00
$70D00o
aotive
wod.
potentially
activ
160potetially
active word
160 potetially
ative word.
160
tive word.
activ
ward
160potetially
active Wrds
160potentially
activ wordl
160 potentially
active wod
I
I
I
$200
$70600
124
off-screen
lines
160
I
o
160 active word.
I
160
active
wordi
160 potetially
tv words
160potentially
active ords
160 pottially
active r
Figure 4.3: Multi-buffer VRAM Usage with Eight PSNs per Scan Line
4.5. INITIALIZING THE SCM
4.4.3
65
Multiple-screen frame buffer
Unless the type of pixel compaction described later is used, a system with four PSNs
has only enough storage for the single buffer just described. However, if eight PSNs are
installed, the followingtables can be used to specify three separate frame buffers:
000: $0
000: $AO
001: $200
001: $2A0
000: $140
001: $340
002: $400
003: $600
002: $4A0
003: $6A0
002: $540
003: $740
898:$70400
898: $70400
899: $70600
898: $704A
898: $704A0
899: $706A0
898: $70540
898: $70540
899: $70740
Figure 4.3 shows only 32 words per VRAM row are unusable in 8PSN mode, as compared
with the 192 words in 4PSNmode. Note that the amount of wasted VRAM depends on both
the horizontal screen resolution RH and the number of PSNs per scan line. The fraction of
wasted VRAM in 8PSN mode is:
512 mod
z
8
512
4.5
Initializing the SCM
With only four PSNs, the installed video system must configure the SCM table as shown
on page 53; all PSNs will drive during all LdClk cycles, and the pixels will be pulled from
alternating VRAM banks.
If multiple frame buffers are desired in a video system with more than four PSNs, several
models can be used:
1. Each PSN contains a portion of all buffers. This is accomplished with appropriate
XLM tables as described in the last section.
2. Each PSN is dedicatedto a subset of the buffers. Multiple SCM tables are needed for
this approach, which holds the most benefit for full 16-PSN systems.
3. A combination of 1 and 2.
The first approach is best suited to applications that have even load distribution throughout the J-Machine processor array; the network traffic to the video system would then be
evenly distributed as well. The second approach can be used by applications that divide
the processor array into upper and lower portions. The two sub-arrays would then send
their messages exclusively to the upper and lower groups of PSN boards, respectively.
4.6
Classes of Pixel Messages
Once the necessary registers and tables have been initialized, the application can begin to
write pixels to the frame buffer. The J-Machine messages that encapsulate these pixels
are handled by drivers that are loaded into the PSN MDPs. The messages fall into three
classes, each with different costs and benefits.
CHAPTER 4. CONFIGURING THE VIDEO SYSTEM
66
4.6.1
Address/Pixel List
An Address/Pixel List (APL) contains a list of pixel values and the explicit VRAM addresses
to which those pixels should be written. For example, the following APL sent to one of the
PSNs would produce a 4-pixel long vertical line in the upper left region of the display:
Ox000: $de
0x200: $de
0x400: $de
0x600: $de
The precise column of the line depends on which PSN receives the message and how the
XLM was initialized. The precise color of the line depends on the colormap tables and
on the display mode of the pixel. When the PSN receives this message, it simply uses
each address as an offset from 0x80000 (the memory-mapped address for the beginning of
VRAM) and copies each pixel until the list is exhausted. The addresses of this vertical line
increment in steps of 0x200 for reasons discussed earlier in section 4.4.2.
Due to the column-wise interleaving of PSNs, a continuous horizontal line requires that
APL messages be sent to all four (or eight) contributing PSNs. If messages were sent to
only one PSN, only every fourth (or eighth) column would be drawn. Assuming that the
SCM is in 4PSN mode, the following APL sent to all four PSNs produces a 12-pixel wide
horizontal line:
OxOOO: $de
0x00I: $de
0x002: $de
0x003: $de
Here the addresses only increment in steps of one, but the corresponding columns are
implicitly incrementing in steps of four.
4.6.2 Raster Operations
A raster operation (ROP) is a primitive graphic operation performed on the frame buffer
data. The supported operations and the contents of their corresponding ROP messages are:
ROP
I
Message contents
DrawPoints (x1 ,yl,pixl), ( 2, y2,pix 2 ), ...
DrawHPoints x,y,pixl, pix 2, pix 3, ...
Draw VPoints
Increments x between pixels
Same as above, but increments y between pixels
2 ,Y2 ,piX2 ,/en 2),
Draw HLines
(x 1 , Yl,pi 1, lenl), (
Draw VLines
Increments x by one for len iterations
Same as above, but increments y
These operations were selected to form the basis of a rudimentary graphics library. They
serve as templates for more elaborate routines that can handle objects such as arbitrary
lines, triangles, and other polygons.
4.6. CLASSES OF PIXEL MESSAGES
67
Just as with APL messages, continuous horizontal lines can only be drawn by sending
the same ROP to all four (or eight) PSNs contributing to a scan line. Presently, the line
"length" specified in Draw Hlines is treated as an iteration count, so the corresponding line
is four times as long.
ROPs do not contain actual VRAM addresses; vertices are instead specified using the
display (x, y) coordinate system. To perform coordinate-to-address translation, the PSNs
need to know the contents of the XLM and SCM tables. In principle, the driver can
accommodate any XLM and SCM table, but for testing purposes the driver assumes the
tables have been initialized to particular values2 . The driver also assumes 24-bit pixels are
being used; as described later in this chapter, this need not be the case.
The key advantages to using ROPs instead of APLs are:
1. Simpler interface. The library provides an abstraction that hides the coordinate-toaddress translation from the application.
2. Smaller messages. The messages sent to the PSNs are generally much smaller than
APLs, causing less congestion of the network and buffers.
On the other hand, several important drawbacks of ROPs are:
1. Slower pixel updates. The MDPs on the PSNs must now do more than simply copy
data; they must supply varying degrees of computation. Although the routines listed
above are not very compute-intensive, every cycle "wasted" on computation cuts into
the pixel update rate.
2. Fixed format. As noted earlier, the present driver assumes a fixed format for the XLM,
SCM, and WT tables. Although a driver can be written to accommodate dynamic
changes to these tables, this implies that additional parameters would need to be
fetched for every ROP (to determine the current configuration). This would exacerbate the effects of item (1). A compromise solution would have different drivers compiled for different table configurations; the appropriate driver would then be loaded
into the PSNs during application set-up.
A very robust application will assume all responsibility for coordinate-to-address translation itself; it will distribute the computation load for ROP processing across its own nodes
and use the PSN MDPs simply to copy APL messages into VRAM. This load distribution
would help combat a major weakness of the MDP: its lack of native floating-point support.
Less demanding applications can capitalize on the abstraction offered by PSN ROP
processing, but at the expense of the pixel update rate.
4.6.3
Proxy Messages
The dimension-ordered J-Machine network routes messages first in the x dimension, then
in y, and finally in z. If the PSNs boards were part of the J-Machine cube, this routing
algorithm would be sufficient. However, the boards actually jut out from the cube along
2
Specifically, it assumes the XLM entries are OxO0000,
4PSN mode.
x00200,
x00400, etc. and that the SCM is in
CHAPTER 4. CONFIGURING THE VIDEO SYSTEM
68
the y dimension, and they do not form z-dimension connections with their neighboring
peripheral boards. As a result, J-Machine messages can only reach a PSN if they originate
from MDPs on the same z-plane as that PSN. Messages generated on any other plane will
reach the appropriate x and y coordinates, but never reach the z destination.
As a workaround, one or more "proxy" J-Machine nodes are allocated on each z plane
with a PSN board attached. A node on another plane can send its message directly to the
proxy node, which then re-sends the message to the PSN. A proxy message is not a distinct
class of pixel message; rather, it is an encapsulation of an APL, or ROP message.
Proxy nodes add a small latency to the time required for pixel message delivery. But
as long as there are at least as many proxies as there are PSNs, they do not significantly
reduce the bandwidth to the peripheral boards. Care must be taken, however, to evenly
distribute the load of proxy messages among the proxy nodes.
A proxy node is also needed to deliver messages to the Video Controller board. However,
this proxy is also needed by the VC MDP to return messages to the application.
4.7
Increasing Effective Storage
A video system with four PSNs has only enough VRAM storage for 1.12 frame buffers using
24-bit pixels. This section describes a way to gain effective storage at the expense of color
range.
Section 4.3 introduced the concept of window types. A 4-bit WT attached to each 24-bit
data word determines how that data word is interpreted, including the size (NPlanes) and
offset (Start) of the pixel value. Normally a true-color application 3 would specify 24-bit
pixels so as to access all 16 million colors available. But if it doesn't actually require such a
large color range, the size of the pixels can be reduced and multiple pixels can be stored in
the same data word. Each pixel would belong to a different frame buffer, and the application
would select the active frame buffer by modifying the Start field of the WT register.
Figure 4.4 demonstrates how a four-PSN system can use this method to achieve two
12-bit deep frame buffers. As indicated in the table below, this method can be used to
achieve as many as 48 frame buffers in a four-PSN system; only two colors are allowed in
this extreme case.
4.8
Pixel
Max number
Effective
Size
of colors
storage
24
12
1
16 million
4 thousand
2
2 MPixels
4 MPixels
48 MPixels
Hardware Scrolling and Stretching
The XLM provides a convenient method to perform scrolling of an image without the need
to shuffle pixels in and out of VRAM. Vertical scrolling is easily accomplished by rotating
3The methods in this section also apply to pseudo-color applications.
4.9. STEREO MONITORS
WT
69
Red
II
4
Green
Blue
I
Frame Buffer
0
4
|
8
8
Red [Green
Blue
4
4
4
I
Frame
Bufffer
1
Red
4
47
Gr
' I
Blue
4
Figure 4.4: Increasing Effective Storage through Pixel Compaction
Zfer
Addr
Frame1
Xfor
Addr
$200
$400
$600
$000
$200
$400
Xfer
Addr
Frame2
l
Frame3
$400
$600
$800
!
a
- -_ -
Figure 4.5: Using the XLM to Scroll an Image Vertically
the entries in the XLM table. Figure 4.5 depicts three successive video frames and the XLM
tables used to scroll the image upward one row per frame.
Limited horizontal scrolling is also available. Here, the "wasted" VRAM discussed
earlier provides a buffer between the left and right edges of the pixel row. The width of
this buffer determines the degree of horizontal scrolling available before the image begins
to spill across multiple scan lines.
The XLM can also be used to stretch the image vertically. Here, two or more successive
table entries would contain the same XferAddr. However, due to the fixed nature of SC1k
generation, horizontal stretching is not available.
4.9
Stereo Monitors
Two independent video systems, each with their own VC and array of PSNs, can be com-
bined within the J-Machine to generate three-dimensional images on stereo monitors. To
couple the video systems, their VC boards must be synchronized so that one provides images during even frames and the other provides images during odd frames. An observer
wears glasses which alternately block the left and right eyes.
Existing jumpers and external connectors can be used accommodate this behavior. In
stereo mode, the two VC boards are configured differently:
* One VC is the master; as usual, its Bt438 derives the quarter-rate LdClk from the
CHAPTER 4. CONFIGURING THE VIDEO SYSTEM
70
PixClk oscillator and sends it to the Bt463 and TIM module. But it also passes the
signal through a TTL-to-ECL converter, out onto a ribbon cable, and over to the
other VC. It sends its local Reset signal to the other VC as well.
* The other VC is the slave; although it still requires a local PixClk oscillator, it uses
the master's LdClk as its own LdClk. It also feeds the master's Reset line to its TIM
FSM.
The goal of sharing a single LdClk and TIM Reset signal is to align the HBLK,VBLK,
and SYNCsignals produced by TIM. This insures that the scan lines and frames are in sync.
Note that because the slave's LdClk is not directly derived from its PixClk, the edges of
the two will not necessarily be aligned. This could potentially wreak havoc with a video
controller, which uses both signals. However, the Bt463 has an internal phase-locked loop
that resolves any delay between their edges; as long as the periods of PixClk and LdClk do
not vary, the PLL will align the signal edges.
Chapter 5
Conclusion
What lies behind us and what lies before us are tiny matters
comparedto what lies within us.
-RALPH
WALDO EMERSON
We shall not ceasefrom exploration; and the end
of all our exploring will be to arrive where we started
and to know the place for the first time.
- T.S. ELLIOT in Little Gidding
5.1
Summary
This thesis described the Distributed Frame Buffer, a video system built for the J-Machine
concurrent computer. The DFB provides a high-bandwidth data path from the J-Machine
to video memory. The combination of this data path and the aggregate processing power of
the J-Machine provides a valuable research tool into high-performancerendering algorithms.
Modern graphics applications such as virtual reality require tremendous processing
power to transform scenes according to some observer's viewpoint. After the objects have
been transformed, additional processing is needed to scan-convert the objects into pixels.
Many existing systems try to satisfy the demands of these two processing stages with a
mixture of parallel architecture and hardware pipelines. Unfortunately, such systems must
make assumptions about the specific rendering algorithm being used. They are optimized
to perform very well if these assumptions are correct, but suffer significantly if they are not.
The J-Machine and its DFB provide a more flexible approach. Rather than fixing the
rendering algorithm in hardware, the J-Machine computing nodes can implement the algorithm in software. A unique trait of the J-Machine is its built-in support for fine-grain tasks
and data objects. This support distinguishes the J-Machine from other massively-parallel
computers and makes it much more suited to graphics-oriented distributed algorithms. Since
many algorithms also contain operations that must be serialized, the J-Machine nodes can
be organized into a pipeline. The number of nodes allocated to each stage of the pipeline
can be modified dynamically to meet varying demands. The DFB is distributed to avoid
the bottleneck of a single video bus. It is also scalable, allowing a tradeoff between price
71
CHAPTER 5. CONCLUSION
72
and performance.
The cost of all this flexibility is that careful attention must be paid to load distribution.
A distributed graphics algorithm can slow down to a crawl if its computation isn't balanced
across the nodes; even though the nodes can often compute their pixels locally, the video
frame will not normally be able to advance until it has been completely updated.
The DFB consists of two types of nodes. An array of Pixel Storage Nodes accepts
incoming pixel messages from the J-Machine, and a Video Controller node repeatedly fetches
frame buffer data from the PSNs to display the pixels on a monitor. For every PSN added to
the array, an additional 8.75 MBytes/sec of bandwidth and 2 MBytes of storage is gained.
The PSNs can be configured to understand different classes of pixel messages. Simple
address/pixel lists require little processing by the PSN and must be used to achieve maxi-
mum bandwidth into the system. More abstract raster operations can be specified instead,
but these reduce the frame buffer bandwidth and should be used only by less-demanding
applications.
The VC has many configuration options: it can work with monitor resolutions up to
1280x1024; the format of pixel data is flexible, and allows true-color, pseudo-color, and
plane depth to be specified on a pixel-by-pixel basis; the portion of VRAM corresponding
to an area of the screen can be changed dynamically by the application, allowing the VRAM
to be segmented into multiple logical buffers; the VC can accommodate from four to sixteen
PSNs; and it can be coupled with another VC to drive stereo monitors.
5.2
Further Work
Now that the hardware foundation exists, much software remains to be developed to validate the performance of the video system under realistic demands. Although a simple
graphics library has been developed, a true test of the system requires a full-fledged rendering algorithm executing in the J-Machine cube. A rigorous application would also test
the fine-grain mechanisms provided by the J-Machine, a challenge that has not been fully
met to date.
Such an application would also demonstrate how well a heavily-distributed algorithm
can compensate for the lack of floating-point hardware in the J-Machine nodes. The first
stage of rendering - object transformation - is very floating-point intensive and would
require many costly software calls. Would this cripple a demanding J-Machine graphics
application, or can the task be sufficiently partitioned and executed in parallel to reduce its
overall cost?
Recent research suggests that the use of multiple frame buffers hampers virtual reality
applications by requiring full-frame updates before the next frame can begin [2]. This often
introduces enough visual lag during head movement to frustrate the observer; for a given
frame buffer bandwidth, it may be more important to update the observer's viewpoint
immediately (with partial images) than to supply full (but jerky) updates. The DFB has
enough flexibility to investigate this claim more thoroughly.
The fine-grain mechanisms provided by the J-Machine lend themselves naturally to
many inherently distributed graphics algorithms. The combination of the J-Machine and
the Distributed Frame Buffer can supply a fertile and flexible testing ground for these and
future algorithms.
Appendix A
PSN Schematics and PAL Files
73
74
APPENDIX A. PSN SCHEMATICS AND PAL FILES
I
i.
It.
I
I
I'
I
ii iI
ii, II
a)
07
I
It
T 1,
I
Fiji
I9.1
I
APPENDIX A. PSN SCHEMATICS AND PAL FILES
75
I
i
IH
I
A
j
I
I
76
APPENDIX A. PSN SCHEMATICS AND PAL FILES
M.
I it
t~;I&
II' I
.18
y
JslI
Js
,.
4~
1
APPENDIX A. PSN SCHEMATICS AND PAL FILES
ae i2 1119
ARt1
ttt 4
77
78
APPENDIX A. PSN SCHEMATICS AND PAL FILES
APPENDIX A. PSN SCHEMATICS AND PAL FILES
79
.
a I 8 I
APPENDIX A. PSN SCHEMATICS AND PAL FILES
80
ndpmode. abl
module mdpmode
title 'MDP Diag Interface - MDPModePal
Eric McDonald
January 15, 1994'
device 'P22V10';
mdpmode
"*** Inputs
Mclk
Mmode0, Mmodel
Pin
Pin
Pin
Pin
X0, xi
SoutO, Soutl
1;
2, 3;
4, 5;
6, 7;
"*** Outputs
Pin 23;
Pin 22;
!Phl
BSout
ModeO_O, Model_0
ModeO_l, Model_l
!FifoReset
Pin 21, 20 istype 'reg,buffer';
Pin 19, 18 istype 'reg,buffer';
Pin 17;
"*** Buses
Mmode
Mode0
Model
= [Mmodel , Mmode0];
= [Model_ , ModeO_O];
= [Model_l , ModeO_l];
"*** Aliases
NOP
EX
SH
RESET
0 ,
0 ,
];
];
0
1
1,
0 ];
1 ,
1
];
H, L, X = 1, 0, .X.;
"*** Equations
equations
"The
registers are clocked by MCLK
[Mode0,
"Phl
Phl
Model,
Phl].clk
= Mclk;
held hi by reset (stops during Phl hi).
(Mmode == RESET);
:= (Phl == L)
The new Mode arives during phl.
"Normally, pass it on ph2. Hold until next phl when reset goes away
"
" Note:
(Phi == L) means that PH1 is about
Mode0 := (XO == H) & (
((Mmode == RESET) & Mmode)
((Mmode
!= RESET)
& (Mode0.fb
to go hi
== RESET)
&
(Phl == H) & Mode0.fb)
)
#
)
((Mmode != RESET) & (Mode0.fb != RESET) & (Phl == H) & Mmode
((Mmode != RESET) & (Mode0.fb != RESET) & (Phl == L) & Mode0.fb)
#
((Mmode != RESET) & (Mode0.fb == RESET) & (Phl == L) & Mmode
APPENDIX A. PSN SCHEMATICS AND PAL FILES
81
mdpmode.abl
);i
Model
:= (Xl == H) &
(
#
((Mmode == RESET) & Mmode)
((Mmode
!= RESET)
&
(Model.fb
== RESET)
&
(Phl == H) & Model.fb)
((Mmode != RESET) & (Model.fb == RESET) & (Phl == L) & Mmode
#
((Mmode != RESET) & (Model.fb != RESET) & (Phl == H) & Mmode
)
((Mmode != RESET) & (Model.fb != RESET) & (Phl == L) & Model.fb)
#
);
BSout
=
FifoReset
end mdpmode
#
)
(SoutO & XO)
# (Soutl
& Xl);
= ((XO == H) # (Xl == H)) &
(Mmode == RESET)
& Phl;
APPENDIX A. PSN SCHEMATICS AND PAL FILES
82
mdpsel.abl
module mdpsel
title 'MDP Diag Interface - MDPSelectPal
Eric McDonald
January 15, 1994'
mdpsel device 'P22V10';
"*** Inputs
"These 5 signals are asserted LOW
BS, AS, DS, RW
MATCH
Pin 2, 3, 4, 5;
Pin 10;
DO, D,
Pin 6, 7, 8, 9;
D2, D3
"'*** Outputs
" BSel is asserted LOW
BSel
Pin
Pin
Pin
Pin
X0, Xl
A0, A1
Xen
22;
21, 20;
19, 18;
17;
"*** Bus definitions
ADDR
ADDRB
DATA
XR
=
=
=
=
[D1,
[A1,
[D1,
[Xl,
DO];
A];
D];
=
=
=
=
[0, 0];
[0, 1];
[1, 0];
1, 0, .X.;
XO];
"*** Alias equates
XEREG
YE_REG
ATO_D_REG
H, L, X
"*** Output equations
equations
!BSel = (!BS & !MATCH) # (BS &
BSel);
"Store the register address selection.
ADDRB = (!BSel & AS & ADDR)
( !(!BSel &
AS) & ADDRB);
"Latch the X register with the appropriate value.
"Note that this value is not encoded base 2...instead, each 1/0 bit
"corresponds to one MDP node.
Xen = !BSel & DS & RW & (ADDRB == XEREG);
XR = (DATA & Xen) # (XR & Xen);
end mdpsel
APPENDIX A. PSN SCHEMATICS AND PAL FILES
83
mdpfan.abl
module mdpfan
title 'MDP Diag Interface - MDPFanoutPal
Eric McDonald
January
mdpfan device 'P16V8';
"*** Inputs
Mclk
MmodeO, Mmodel
Sin
ModeInOO, ModeInlO
ModeInOl,
ModeInl_l
Pin
Pin
Pin
Pin
Pin
1;
2, 3;
4;
5, 6;
7, 8;
Pin
Pin
Pin
Pin
19,
17,
15,
13,
"*** Outputs
Sin0_O, Sin_l
Phl_0, Phl_l
ModeO_O, Model_0
ModeO_l, Model_l
"*** Buses
Mmode
= [Mmodel , MmodeO];
"*** Aliases
NOP
EX
SH
RESET
H, L, X
=
=
=
=
=
[
[
[
[
1,
0,
0,
1,
1,
0,
0
1 ];
I;
0
I;
1 I];
.X.;
"*** Equations
equations
[Phl_0,
Phll].clk
= Mclk;
"Just buffer and distribute Sin:
Sin_0
Sin_l
= Sin;
= Sin;
"Just buffer and distribute Mode:
ModeOO
:= ModeInO_0;
Model_0 := ModeInl_0;
Mode0_l := ModeInO_l;
Model_l := ModeInl_l;
"Calculate and distribute phl
Phl_0
Phl_l
:= (PhlO
:= (Phll
end mdpfan
== L) # (Mmode == RESET);
== L) # (Mmode == RESET);
18;
16 istype
14 istype
12 istype
'reg';
'reg';
'reg';
15, 1994'
84
APPENDIX A. PSN SCHEMATICS AND PAL FILES
--i,
Al3
ahit
-I---
RAI
-- --
-IFHE 3
IL
APPENDIX A. PSN SCHEMATICS AND PAL FILES
85
v
.
F .'
i
9 I
I
86
APPENDIX A. PSN SCHEMATICS AND PAL FILES
E-Fi
>aj
I; I
1
II
7
X
In
APPENDIX A. PSN SCHEMATICS AND PAL FILES
87
i
88
APPENDIX A. PSN SCHEMATICS AND PAL FILES
h
b
Ol
tlo
I
I
I
&.b
i =
2 1 .
I 5
& ni
;; - I A
ii&Il
r
Al
APPENDIX A. PSN SCHEMATICS AND PAL FILES
89
fifopal.abl
module FifoPal
title 'FIFO Controller Pal
Eric McDonald
Last revised:
"
n
"
February 15, 1994
February
15, 1994'
DESCRIPTION:
------------
This PAL watches all emem accesses made by the MDP.
If the access is to an address < $80000, the PAL does nothing but
pass along the /WE and /OE signals to the DRAMs.
However, accesses to >= $80000 disable the DRAM /WE and /OE lines.
For WRITEs, the specified data and some bits of the address
are shifted into the appropriate FIFOs.
For READs, nothing is done besides disabling /WE and /OE (to allow
the MREAD PAL to respond to the read request).
FifoPal
device 'P22V10';
"*** Inputs
PH1
WR,CAS,RAS
CSB0, CSB1
EA10
Pin
Pin
Pin
Pin
1;
2, 3, 4;
5, 6;
9;
"EMI control signals
"Indicate which word is on bus.
"*** Outputs
"FIFO control lines...
LdAddr
SIaddr
Pin 23;
Pin 22;
SIwordO
SIwordlset
SIword2set
SIwordReset
Pin
Pin
Pin
Pin
"EMI DRAM control lines...
WE
OE
Pin 21;
Pin 20;
"For internal use
RASDelayed
A19
19;
18;
17;
16;
"Latch 10 bits of address
"Shift in all 20 bits of address
"(current 10 + latched 10)
"Shift in first 12 data bits
"...next 12 data bits
(to JK FF)
"...and last 12 data bits (to JK FF)
"Clear SIword{1,2} from JK FF
"/WE line for DRAMs
"/OE line for DRAMs
Pin 15 istype 'reg';
Pin 14;
"*** Aliases
DRAM_ACCESS
=
!A19;
FIFO_ACCESS =
A19;
H, L, C, X = 1, 0, .C., .X.;
ZERO = [0, 0];
ONE
= [0, 1];
TWO
= [1, 0];
CSB = [CSB1, CSB0];
WordO
=
(CSB == ZERO);
"DRAM takes the lower half of address space
"..and the Video RAM takes the upper half
APPENDIX A. PSN SCHEMATICS AND PAL FILES
90
fifopal.abl
Wordl
Word2
=
=
(CSB == ONE);
(CSB == TWO);
RASGoingLow = !RAS & RASDelayed;
*** Equations
equations
RASDelayed.clk
= PH1;
RASDelayed
:= RAS;
"A19 (provided on EA10 when /RAS drops) will be high for address >= $80000
A19 = (!PH1 & RASGoingLow & EA10) # (!RAS & A19);
.. ***
"DRAM control lines...
.. ****
"DRAM /OE and /WE lines are disabled during A19 accesses
OE = A19 # !WR;
WE = A19 # WR;
..
***
"FIFO control lines...
.. **
"The high-to-low transition of /LdAddr latches the row of the external
" memory address. Keep it low for the entire emem access cycle.
!LdAddr = (EA10 & !WR & !RAS & CAS) # (!RAS & !LdAddr);
"The low-to-high transition of SIaddr shifts the latched addr row and the
" current addr column into the FIFOs. The subsequent high-to-low return
" of SIaddr propagates the address through the FIFO.
SIaddr = (Al9 & !WR & !CAS & WordO) # (SIaddr & !RAS);
WARNING: Watch out for a race condition here. The 'output ready' from
the FIFO's comes only from a DATA FIFO, so it is assumed that the
ADDR FIFO is in sync with it. However, SIaddr goes low at 'about'
the same time as the Sword's do, so the ADDR FIFO may not have
propagated the address all the way through yet.
"SIwordO goes right to its FIFO. SIword{1,2} go to the J inputs of a
"JK Flip Flop whic is clocked off the falling edge of /CAS.
SIwordO = (A19 & !WR & !CAS & WordO) # (SIwordO & !RAS);
SIwordlset = (SIwordO & Wordl);
SIword2set = (SIwordO & Word2);
!SIwordReset
end FifoPal
= RAS;
APPENDIX A. PSN SCHEMATICS AND PAL FILES
91
92
APPENDIX A. PSN SCHEMATICS AND PAL FILES
mread. abl
module MRead
title 'MDP Readback PAL
Eric McDonald
Last revised:
July 14, 1992
April 28, 1994'
DESCRIPTION:
When the MDP makes a READ access to address >= $80000 (A19=1), we
initiate a request to the VRAM PAL to supply us with the pixel
value for the given address in VRAM.
The request is made with DataREQ and is acknowledged with DataACK once
the VRAM module has clocked the data into our registers with /PixLd.
The two valid address ranges for this module are:
I!
$80000 - $bffff
Request pixel data for selected bank from
(address & $3ffff) (strip 2 MSBs)
$c0000
Poll DataREQ status flag and view data returned
~~"
~
from last read request. Also selects bank for
~~~"
~
next read to Bank A.
$dOOOO
Same as above, but selects bank for
"N~~~
~
next read to Bank B.
A summary of the bit usage is:
A19 A18 A17 A16
1
0
X
X
Request data
1
1
X
0
Poll and select bank A (PixBankMR = 0)
" 1
1
X
1
Poll and select bank B (PixBankMR = 1)
~~"
~
After requesting the data by addressing the $80000 range,
the MDP should keep reading from $cOOOO or $eOOOO. It should
ignore the data it sees until the DataREQ line goes low again, at
which point the data is valid.
MRead device 'P22V10';
"*** Inputs
PH1
Pin 1;
RAS, CAS, WR
Pin 2, 3, 4;
VRAMDataACK
Pin 5;
CSBO, CSB1
EA9, EA10
Pin 6, 7;
Pin 9, 10;
"*** Outputs
VRAMDataREQ
DriveWordO, DriveWordl, DriveWord2
LoadRAS, LoadMDPAddr
PixBankMR
Pin
Pin
Pin
Pin
23 istype 'reg';
22, 21, 20;
18, 19;
17 istype 'reg';
"*** Outputs used internally
A19
RASDelayed, CASDelayed
Pin 16;
Pin 15, 14 istype
'reg';
APPENDIX A. PSN SCIIEMATICS AND PAL FILES
mread. abl
"*** Aliases
H, L, C, X = 1, 0,
ZERO = [0, 0];
ONE
= [0, 1];
TWO
= [1, 0];
CSB = [CSB1, CSB0];
RASGoingLow = !RAS &
RASGoingHigh = RAS &
CASGoingLow = !CAS &
A19Read = !RAS & A19
C.,
.X.
RASDelayed;
!RASDelayed;
CASDelayed;
& WR;
"*** Equations
equations
[VRAMDataREQ,RASDelayed,CASDelayed].clk
RASDelayed
CASDelayed
= PH1;
:= RAS;
:= CAS;
" A19 appears on EA10 during the initial memory cycle...
A19 = (!PH1 & RASGoingLow & EA10) # (!RAS & A19);
"LoadRAS is asserted during *every* read with A19 == 1
LoadRAS = (WR & EA10 & RASGoingLow)
# (LoadRAS & !RAS);
LoadMDPAddr is asserted only during reads with A19 == 1 and A18 == 0
(A18 appears on EA10 when CAS drops and CSB==0)
" (A16 appears on EA9 when CAS drops and CSB==0)
VRAMDataREQ depends on this signal.
LoadMDPAddr = (A19Read & !EA10 & CASGoingLow & (CSB == ZERO))
# (LoadMDPAddr & !VRAMDataREQ);
PixBankMR := (A19Read & EA10 & CASGoingLow & (CSB == ZERO) & EA9)
# (!(A19Read & EA10 & CASGoingLow & (CSB == ZERO)) & PixBankMR);
This signals to the VRAM PAL that we have a complete address and would
like to read data from the VRAM.
It also clears the LoadMDPAddr signal.
VRAMDataREQ := (LoadMDPAddr & RAS)
# (VRAMDataREQ & !VRAMDataACK);
!DriveWordO
!DriveWordl
= A19Read
= A19Read
&
&
CAS &
!CAS &
(CSB == ZERO);
(CSB == ONE);
!DriveWord2 = A19Read & !CAS & (CSB == TWO);
end MRead
93
APPENDIX A. PSN SCHEMATICS AND PAL FILES
94
I
I
,
i
I
_
a
11
k
II i
J
11
tS1S
All1t~~~t
t 21 .,,X1
1. I
I
i
I
I
I
a
a
a
k k k k k k k
I
I
i
a
11 k k k k k k t k
t l
.1t
I
I
II
k k
1.
APPENDIX A. PSN SCHEMATICS AND PAL FILES
95
APPENDIX A. PSN SCHEMATICS AND PAL FILES
96
xfer. abl
module Xfer
title 'Xfer Pal for VRAM FSMs
Eric McDonald
Last revised:
May 12, 1994
May
12, 1994'
" DESCRIPTION:
Xfer device 'P22V10';
"*** Inputs
FClk
Transfer
AckO,Ackl
FFTransfer
Pin
Pin
Pin
Pin
1;
2;
3,4;
5;
"Async. transfer signal from VC
"VRAM FSMs saw the transfer signal
"Transfer signal from Flip Flop
"*** Outputs
Pin 23,22 istype 'reg,buffer'; " Sent to VRAM FSMs
Pin 21 istype 'invert';
Complement of Transfer
Pin 20 istype 'reg,invert';
"Reset FF
Xfer0,Xferl
TransferNot
FFReset
"*** Bits used internally
XferSync
Pin 19 istype 'reg,buffer';
XferSyncDel
Pin 18 istype 'reg,buffer';
OKToReset
Pin 17 istype 'reg,buffer';
Sync up the Transfer sig
"*** Aliases
H, L, C, X = 1, 0, .C., .X.;
"*** Equations
equations
[XferSync,XferSyncDel,OKToReset,Xfer0O,Xferl].clk
TransferNot
=
Transfer;
XferSync := FFTransfer;
XferSyncDel := XferSync;
"Async
= FClk;
sets the FF
Sync the FF output to our clock
Xfer0 := (XferSync & !XferSyncDel)
# (Xfer & !AckO);
Xferl := (XferSync & !XferSyncDel)
# (Xferl & !Ackl);
OKToReset := XferSync
" OK to reset after we've seen the signal
# (OKToReset & XferSync);
!FFReset := OKToReset & TransferNot.pin; "Must be sure not to assert
" /FFReset and /TransferNot simult.
APPENDIX A. PSN SCHEMATICS AND PAL FILES
97
vcO. abl
module VC0
title 'VRAM Control PAL #0
Eric McDonald
Last revised:
July 14, 1992
April 28, 1994'
"DESCRIPTION:
I!I.
II
II
I!
Most of the
However, it
Broadcast
FifoOR
DataREQ
time this FSM is simply providing refresh strobes to the VRAMs.
also services three kinds of requests:
- VC has asked us to transfer a row in VRAM to the serial ports
- FIFO has data to be written into VRAM
- The MDP (via the MREAD module) would like us to read a
piece of data out of VRAM
VC0 device 'P22V10';
"*** Inputs
FClk
FifoOR
PixBank
DataREQ
Transfer
PixBankMR_0
PixBankMR_1
"***
Pin
Pin
Pin
Pin
Pin
Pin
Pin
1;
2;
4;
3;
5;
6;
7;
Pin
Pin
Pin
Pin
Pin
Pin
23 istype 'reg,buffer'; "ACK back to MDPRead PAL
22 istype 'reg,buffer'; "Latch data into MDPRead buffers
21 istype 'reg,buffer'; " When high, disables FIFO data
20 istype 'reg,buffer'; " Select Brdcst or MDPRead addr
19 istype 'reg,buffer'; " Pixel or Brdcst/MDP address
14,15,16,17,18 istype 'reg,buffer'; " State bits
" FIFO has data ready
" The FIFO data should go into this bank
" MDP wants to read data back from the VRAM
" VC wants us to transfer a row of data
" The MDP0 readback data should come from this bank
The MDP1 readback data should come from this bank
Outputs
DataACK
PixLoad
FifoDisable
Broadcast
Pixel
Q0,Q1,Q2,Q3,Q4
"*** State declarations
Ginclude
'vc.sta'
"*** Equations
equations
[current_state,DataACK,PixLoad,FifoDisable,Broadcast,Pixel].clk = FClk;
statediagram
current_state;
State Init:
goto RefreshO;
"
State RefreshO:
!CASa := 1; !CASb := 1;
goto Refreshl;
State Refreshl:
"
I"
!CASa := 1;
!RASa := 1;
!CASb
!RASb
:= 1;
:= 1;
APPENDIX A. PSN SCHEMATICS AND PAL FILES
98
vcO. abl
goto Refresh2;
State Refresh2:
!CASa
!RASa
:= 1;
:= 1;
!CASb :=
!RASb :=
1;
1;
goto Refresh3;
State Refresh3:
!CASa
!RASa
:= 1;
:= 1;
!CASb :=
!RASb :=
1;
1;
goto Refresh4;
State Refresh4:
!CASa
!RASa
:= 1;
:= 1;
!CASb :=
!RASb :=
1;
1;
goto Refresh5;
State Refresh5:
if (Transfer) then XferO;
else Refresh6;
State Refresh6:
if (FifoOR) then WriteO;
else Refresh7;
State Refresh7:
if (DataREQ) then ReadO;
else RefreshO;
State XferO:
"
Broadcast
:= 1;
!OEa := 1;
OEb
MuxRAS := 1;
:= 1;
First bring /DT low
goto Xferl;
State Xferl:
"
"
Broadcast
:= 1;
!OEa := 1;
OEb := 1;
!RASa := 1; !RASb := 1;
MuxRAS := 1;
Then bring /RAS low
with valid row
goto Xfer2;
State Xfer2:
"
"
Broadcast
:= 1;
!OEa := 1;
OEb := 1;
!RASa := 1; !RASb := 1;
Relase MuxRAS and let settle
goto Xfer3;
State Xfer3:
"
"
"
Broadcast
:= 1;
!OEa := 1;
OEb := 1;
!RASa := 1; !RASb := 1;
!CASa := 1; !CASb := 1;
And finally bring /CAS low with SAM
goto Xfer4;
State Xfer4:
"
"
"
Broadcast
:= 1;
!OEa := 1;
OEb := 1;
!RASa := 1; !RASb := 1;
!CASa := 1;
CASb := 1;
goto Init;
State WriteO:
Pixel := 1;
MuxRAS :=.1;
goto Writel;
State Writel:
Drive row address and let settle
APPENDIX A. PSN SCHEMATICS AND PAL FILES
99
vcO.abl
Pixel
:= 1;
!RASa := !PixBank; !RASb := PixBank;
"
MuxRAS
Bring /RAS low with valid row
:= 1;
goto Write2;
State Write2:
Pixel
:= 1;
!RASa := !PixBank; !RASb := PixBank;
goto Write3;
State Write3:
Pixel
IRASa
:= 1;
:= !PixBank;
!RASb
:= PixBank;
!CASa := !PixBank; !CASb := PixBank;
goto Write4;
State Write4:
Pixel
Bring /CAS low with valid column
:= 1;
!RASa := !PixBank; !RASb
!CASa := !PixBank; !CASb
"
!WEa := !PixBank; !WEb
goto Write5;
State Write5:
"
!RASa := !PixBank; !RASb
"
!CASa := !PixBank; !CASb
FifoSO
Drive col address and let settle
:= PixBank;
:= PixBank;
:= PixBank;
:= PixBank;
:= PixBank;
:= 1;
goto Init;
State ReadO:
MuxRAS
Drive row addr & let settle
:= 1;
goto Readl;
State Readl:
MuxRAS
:= 1;
!RASa := !PixBankMR;
FifoDisable
:= 1;
!RASb := PixBankMR;
Bring /RAS low w/valid row
!RASb := PixBankMR;
Drive col addr & let settle
goto Read2;
State Read2:
"
!RASa := !PixBankMR;
!OEa
:= !PixBankMR;
:= 1;
FifoDisable
lOEb
:= PixBankMR;
goto Read3;
State Read3:
!RASa := !PixBankMR; !RASb := PixBankMR;
"
!CASa := !PixBankMR; iCASb := PixBankMR;
"
State
"
"
"
!OEa
:= !PixBankMR;
:= 1;
FifoDisable
lOEb
:= PixBankMR;
goto Read4;
Read4:
!RASa := !PixBankMR; !RASb := PixBankMR;
!CASa := !PixBankMR; iCASb := PixBankMR;
!OEa := !PixBankMR; lOEb
:= PixBankMR;
:= 1;
FifoDisable
PixLoad := 1;
goto Read5;
State Read5:
DataACK
:= 1;
if (DataREQ) then Read5;
else Init;
' Eliminate trap states...
Bring /CAS low w/valid col
Drive the VRAM data out
APPENDIX A. PSN SCHEMATICS AND PAL FILES
100
vcO. abl
State
State
State
State
State
State
end VCO
TrapO: goto Init;
Trapl: goto Init;
Trap2: goto Init;
XferTrap: goto Init;
ReadTrap: goto Init;
WriteTrap: goto Init;
APPENDIX A. PSN SCHEMATICS AND PAL FILES
101
vcl_O.abl
module VC1_0
@const MDP = 0;
title 'VRAM Control PAL #1
Eric McDonald
Last revised:
July 14, 1992
April 28, 1994'
VCl_0 device 'P22V10';
"*** Inputs
FClk
Q0,Q1,Q2,Q3,Q4
FifoOR
PixBank
DataREQ
Transfer
PixBankMR_0
PixBankMR_l
Pin 1;
Pin
Pin
Pin
Pin
Pin
Pin
Pin
2,3,4,5,6; " State bits generated by VCtrlO
" FIFO has data ready
7;
" The FIFO data should go into this bank
9;
8;
" MDP wants to read data back from VRAM
10;
" VC wants us to transfer a row of data
11; " The MDP0 readback data should come from this bank
13; " The MDP1 readback data should come from this bank
"*** Outputs
Pin
Pin
Pin
Pin
Pin
Pin
MuxRAS
FifoSO
RASa,RASb
CASa,CASb
WEa,WEb
OEa,OEb
23 istype 'reg,buffer'; "Mux RAS or CAS select
22 istype 'reg,buffer'; "Shift FIFO one word
21,17 istype 'reg,invert'; "VRAM /RAS signals
20,16 istype 'reg,invert'; "VRAM /CAS signals
19,15 istype 'reg,invert'; "VRAM /WBWE signals
18,14 istype 'reg,invert'; "VRAM /DTOE signal
"*** Aliases
@if (MDP == 0) { PixBankMR
@if (MDP != 0) { PixBankMR
= PixBankMR_0;
= PixBankMRl;
}
"*** State declarations
@include 'vc.sta'
"*** Equations
equations
[MuxRAS,FifoSO,RASa,RASb,CASa,CASb,WEa,WEb,OEa,OEb].clk
FifoSO := InState(Write5);
MuxRAS := InState(Xfer0)
#
#
#
#
#
!RASa
InState(Xferl)
InState(Write0)
InState(Writel)
InState(Read0)
InState(Readl);
:= InState(Refreshl)
#
#
#
#
#
In_State(Refresh2)
In_State(Refresh3)
In_State(Refresh4)
In_State(Xferl)
In_State(Xfer2)
= FClk;
APPENDIX A. PSN SCHEMATICS AND PAL FILES
102
vcl_O. abl
# In_State(Xfer3)
# In_State(Xfer4)
(InState(Writel)& !PixBank)
(InState(Write2)& !PixBank)
(InState(Write3)& !PixBank)
(InState(Write4)& !PixBank)
(InState(Write5)& !PixBank)
(InState(Readl) & !PixBankMR)
(InState(Read2) & !PixBankMR)
# (InState(Read3) & !PixBankMR)
# (InState(Read4) & !PixBankMR);
#
#
#
#
#
#
#
!RASb
:= In_State(Refreshl)
# InState(Refresh2)
# InState(Refresh3)
# In_State(Refresh4)
# In_State(Xferl)
# In_State(Xfer2)
# InState(Xfer3)
# In_State(Xfer4)
# (InState(Writel)& PixBank)
# (InState(Write2)& PixBank)
# (InState(Write3)& PixBank)
# (InState(Write4)& PixBank)
# (InState(Write5)& PixBank)
# (InState(Readl) & PixBankMR)
# (InState(Read2) & PixBankMR)
# (InState(Read3) & PixBankMR)
# (InState(Read4) & PixBankMR);
!CASa
:= In_State(RefreshO)
#
#
#
#
In_State(Refreshl)
In_State(Refresh2)
In_State(Refresh3)
In_State(Refresh4)
# InState(Xfer3)
# In_State(Xfer4)
# (InState(Write3)& !PixBank)
# (InState(Write4)& !PixBank)
# (InState(Write5)& !PixBank)
# (InState(Read3)& PixBankMR)
# (InState(Read4)& !PixBankMR);
!CASb := In_State(RefreshO)
# In_State(Refreshl)
# In_State(Refresh2)
# InState(Refresh3)
# In_State(Refresh4)
# InState(Xfer3)
# In_State(Xfer4)
#
#
#
#
#
(InState(Write3)& PixBank)
(InState(Write4)& PixBank)
(InState(Write5)& PixBank)
(InState(Read3)& PixBankMR)
(InState(Read4)& PixBankMR);
!WEa := (In_State(Write4)
& !PixBank);
APPENDIX A. PSN SCHEMATICS AND PAL FILES
vcl._O. abl
!WEb := (InState(Write4)
!OEa
&
PixBank);
:= In_State(XferO)
#
#
#
#
In_State(Xferl)
In_State(Xfer2)
In_State(Xfer3)
In_State(Xfer4)
# (InState(Read2) & PixBankMR)
# (InState(Read3) & !PixBankMR)
# (InState(Read4) & !PixBankMR);
!OEb := InState(XferO)
# In_State(Xferl)
# InState(Xfer2)
# In_State(Xfer3)
#
#
#
#
InState(Xfer4)
(InState(Read2) & PixBankMR)
(InState(Read3) & PixBankMR)
(InState(Read4) & PixBankMR);
end VC1_0
103
APPENDIX A. PSN SCHEMATICS AND PAL FILES
104
-- --
~itt
- R- R9- R
I v! 2
NI;
-- --
- -- -
I !2 it ! I
R~
N~t
I 2
1.
M
- - - -
RR
W:2TZV*ril
I
44Vi
. . . .
9
ss
101.
mbi
!AR .
7K
. .
. . . .
I
I
I-
m
4
F
. . . .
9 9 2
HU
I
~i2
wvzv * %I RN
T
.
.
9
R9
.
I.
.
.
.
.
s
llfd~zvz
IN
F
9. 9. R. .
. I. . .
R
Qvl
i
!A
101,16
!A R
IQ
JjJ
II
6!
M
LJ
II
i
I
1.
105
APPENDIX A. PSN SCHEMATICS AND PAL FILES
-7-
I !
&! II
Ii ~I
11
APPENDIX A. PSN SCHEMATICS AND PAL FILES
106
1
Ii IIqEI
9 i
A: N
E
,
RR
q
-
-
-
-- -
1
'I 1
-
Ii
i-
-
V
IE
&7-
!
i
1 1
Ii
J I
i I
m
I P
I
1 -
-
-
. . .
:- -
-
-
L~
-
-
-
I
-
Ri.Iiii-
I
I
11
ILJ J
-
-
e
11
1 s||
SIf
-|P
|||
i
i
U|
J I
i El
9
I
1 1;
1
1 11
;4.
I
..... r,, . TS................
'1: tl I
C!.
A9
6A S "A
tl [I
pi
4E
E
-
-
-
-
N.
h
I
-
-
-
I
L-f
1
I
A
I
1
s
N
LI
- - - - - -
I . . .
Iq
I e'9
L
q
i
I
.1
I-I
- -I
I
hL
R9
9 2 ei 12Bs
A
L
-
-
-
9
c
I]
-
-
-
-
.
.
.
.
.
., I{WM1
P.
J I
Nil
P.
1
11
§E~
] J
-J
.
.
.
.
. .
I I
-
el
!I ,I
I
-
el
K
I
I1
i9A
.~
~
.
9I
I'~l
i
I
I
E.,
I
I
i
9
.
-
II I:Ii]
R . i
i
I -1
f ;
-
IK-I
1
L
94
-
%tM Wi'
I
I--
-.--...-
.
I I
-
I-
t
!n,
I I
11
rlI
I
-
.
4. I
3
I
I !
At
NJ
P
N
iX
-
N
.
NJ
~
'P:i
i
I
IW
I
,,,..
I
;4
I j .!I I11
AM
I
A
I
R
41
I
I
1T
11~
iN
K
L
I
II2
6 13
'ill."AsAr.
IIi .Ie
I
9
w
-
Z
-
-
w
w
2.
1,I
R
I
_
.__._7
w
I
APPENDIX A. PSN SCHEMATICS AND PAL FILES
107
i.
JI
.
jIk i!~;Ia. .,
I
By-
-----
-
-
-
-
I
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
f
i
I4 q a i r x l t t ( }q t q q IRE
u~~~~~~~~~~
_
gt
t - - ''tot~t't
tttt t t t't t t' t .Lttt
..
_T
__
_
T
_
_1T
__
____
.
.,,
Appendix B
VC Schematics and PAL Files
108
APPENDIX B. VC SCHEMATICS AND PAL FILES
109
I
.
..
i ;1 #g
]LVL
t-
a0
Zr
APPENDIX B. VC SCHEMATICS AND PAL FILES
110
I'I
I
mn M{
~m
r
Lj
T
ii
12
I
I
I
i
T
T
T
T
i
I
i
i
I
lT
4
m
,I
t
T
+,.4
H
II
T
I
t
1
T
_v 81_
UI I
fT?
I
I
T
L
T
~~~~~I 4~
I I Iis I~
c
0
I
I.
I
I
z
t t t t
LLLL
iI
~,
!
;
I
4.)
I
I~
0.
if
r
f|
mb8111111
f
I Ia I
9a'I
46[44N4
a 1s8!A
N 68+
* |ditlisJ~lJ
AtSgnfgQ
5
1,.
I
i
III
T 1
It
^5il
Y
d
I t !Im
4a
I,
II
T
II
1=.
APPENDIX B. VC SCHEMATICS AND PAL FILES
111
11
11
I
APPENDIX B. VC SCHEMATICS AND PAL FILES
112
mdplsel.abl
module mdpsel
title 'MDP Diag Interface - MDPSelectPal
Eric McDonald
January 15, 1994'
mdpsel device 'P22V10';
"*** Inputs
"These 5 signals are asserted LOW
BS, AS, DS, RW
MATCH
Pin 2, 3, 4, 5
Pin 10;
DO, D,
Pin 6, 7, 8, 9
D2, D3
"*** Outputs
"BSel is asserted LOW
BSel
X0, Xl
A0, Al
Xen
***
Pin
Pin
Pin
Pin
22;
21, 20;
19, 18;
17;
Bus definitions
ADDR
ADDRB
DATA
XR
=
=
=
=
[D1,
[Al,
[D1,
[Xl,
DO];
A];
D];
X];
=
=
=
=
[0, 0];
[0, 1];
[1, 0];
1, 0, .X.;
"*** Alias equates
XEREG
YEREG
ATO_DREG
H, L, X
"*** Output equations
equations
!BSel =
(!BS &
MATCH)
#
(BS &
BSel);
"Store the register address selection.
ADDRB = (!BSel & !AS & ADDR) # ( !(!BSel & !AS) & ADDRB);
"Latch the X register with the appropriate value.
"Note that this value is not encoded base 2...instead, each 1/0 bit
"corresponds to one MDP node.
Xen = IBSel & !DS & RW & (ADDRB == XE_REG);
XR = (DATA & Xen) # (XR & !Xen);
end mdpsel
APPENDIX B. VC SCHEMATICS AND PAL FILES
113
mdpfan. abl
module mdpfan
Eric McDonald
title 'MDP Diag Interface - MDPFanoutPal
January 15, 1994'
mdpfan device 'P16V8';
"*** Inputs
Mclk
MmodeO, Mmodel
Sin
ModeInO0O, ModeInl_0
Pin
Pin
Pin
Pin
Pin
ModeInOl, ModeInl_l
1;
2, 3;
4;
5, 6;
7, 8;
"*** Outputs
Sin.0_O,Sinl
Phl_0, Phl1_l
Pin 19, 18;
ModeOO, Model_0
ModeOl, Model_l
Pin 15, 14 istype
Pin 13, 12 istype
Pin 17, 16 istype 'reg,invert';
"*** Buses
=
Mmode
[Mmodel
, Mmode0];
"*** Aliases
NOP
EX
=
[
0,
0,
1,
SH
=
[1,
=
1,
RESET
= [[
H, L, X = 1, 0,
0
];
1
1;
0 ];
1
I;
.X.;
"*** Equations
equations
[Phl_O,
Phl_l].clk
= Mclk;
"Just buffer and distribute Sin:
Sin_0
Sin_l
= Sin;
= Sin;
"Just buffer and distribute Mode:
Mode0_0 := ModeInO_0;
Model_0 := ModeInl_0;
Mode0_l := ModeInO_l;
Model_l := ModeInl_l;
"Calculate and distribute phl
Phl_0.d
Phl_l.d
end mdpfan
:= (PhlO.q
:= (Phl_l.q
== L)
== L)
(Mmode == RESET);
(Mmode == RESET);
'reg';
'reg';
114
APPENDIX B. VC SCHEMATICS AND PAL FILES
-I,
4.R
ma
i-
md
md
115
APPENDIX B. VC SCHEMATICS AND PAL FILES
I
9
-
I
I
116
APPENDIX B. VC SCHEMATICS AND PAL FILES
L
h.
I I
1I
I
I
I Ii
APPENDIX B. VC SCHEMATICS AND PAL FILES
117
!il
~
h~inlugolq~fl45gg4L~t~ll~i~l~l484;l~Ip
I.l
§152isQ;24Q;i-22i;;4@;;1
J$I.)Xls~lffl~lawlillis~ttiiiitt~t~iita~teRvii
91
APPENDIX B. VC SCHEMATICS AND PAL FILES
118
i
APPENDIX B. VC SCHEMATICS AND PAL FILES
119
erm. abl
module Erm
title 'EMI Readback Module PAL
Eric McDonald
Last revised:
January
5, 1994
February 15, 1994'
-" DESCRIPTION:
-----------"Decodes EMI reads from address >= $80000 according to this table:
Output signal
Sample address
" A[19:16]
_____________
"
l0Xl
$90000
/MPU2ERMO (cycle
/MPU2ERM1 (cycle
/MPU2ERM2 (cycle
(access here will
same as above w/o
/XLM2ERM
/FIFO2ERM
I!
..
10X0
$80000
11
11X0
$coooo0000
1.
lixi
$dOOOO
0)
1)
2)
also set ErmAck)
setting ErmAck
Erm device 'P22V10';
"*** Inputs
Pin
Pin
Pin
Pin
Pin
1;
2, 3, 4;
5, 6, 7, 8;
9;
10;
Xlm2Erm
Fifo2Erm
Mpu2ErmO, Mpu2Erml, Mpu2Erm2
ErmAck
BufEn
MpuReady
Extra
Pin
Pin
Pin
Pin
Pin
Pin
Pin
23 istype 'invert';
22 istype 'invert';
"*** For internal use
DoAck
Pin 14 istype 'reg,buffer';
PH1
RAS, CAS, WR
EA10, EA9, CSB1, CSBO
MpuStat
RESET
"*** Outputs
"*** Aliases
H, L, C, X = 1, 0, .C.,
ZERO = [0, 0];
ONE
= [0, 1];
TWO
= [1, 0];
CSB = [CSB1, CSBO];
.X.;
"*** Equations
equations
[DoAck,ErmAck,MpuReady].clk
= PH1;
21, 20, 19 istype
'invert';
18 istype 'reg,buffer';
17;
16 istype 'reg,buffer';
15;
120
APPENDIX B. VC SCHEMATICS AND PAL FILES
erm.abl
Extra
= 0;
A19 appears on EA10 during the zeroth cycle (when RAS first drops), and
A18,A16 appear on EA10,EA9 during the next memory cycle (when CAS 1st drops).
!BufEn = (WR & EA10 & !RAS & CAS) # (!BufEn & !RAS);
!Fifo2Erm = (!BufEn & !CAS & EA10 & EA9 & (CSB == ZERO))
# (!Fifo2Erm & iRAS);
lXlm2Erm
= (!BufEn
&
CAS & EA10
& !EA9 & (CSB == ZERO))
# (!Xlm2Erm & !RAS);
!Mpu2ErmO = (!BufEn & !CAS &
!Mpu2Erml = (!BufEn &
EA10 & (CSB == ZERO));
CAS & !EA10 & (CSB == ONE));
!Mpu2Erm2 = (!BufEn & !CAS &
EA10 & (CSB == TWO));
DoAck
:= (!BufEn & CAS & EA10 & EA9 & (CSB == ZERO))
# (DoAck & ErmAck);
ErmAck
:= (MpuReady & !Mpu2Erm2 & DoAck)
# (ErmAck & MpuReady);
MpuReady := MpuStat;
end Erm
APPENDIX B. VC SCHEMATICS AND PAL FILES
121
I
APPENDIX B. VC SCHEMATICS AND PAL FILES
122
1-
9: rm,e
!_ =
b
?
A
l?
I
4
45
I Iw I*II
.bi11i
.:-.
11
1 1 1 I I I
--
0 0 0 0
.1-
I
0 0
g gi8 II 8 1 Rh
1
APPENDIX B. VC SCHEMATICS AND PAL FILES
123
fifopal.abl
module FifoPal
title 'FIFO Controller Pal
Eric McDonald
Last revised:
February 15, 1994
March 1, 1994
DESCRIPTION:
Determines whether an MDP emem access is meant for the DRAM (< $80000)
or the FIFO (>= $80000). It provides appropriate signals to DRAMs and PALs.'
FifoPal
device 'P26V12';
"*** Inputs
PH1
WR,CAS,RAS
CSB0, CSB1
EA9,EA10
RESET
Pin
Pin
Pin
Pin
Pin
1;
2, 3, 4;
5, 6;
9, 10;
11;
UEMI control signals
"Indicate which word is on bus.
"*** Outputs
"FIFO control lines...
LdAddr
SIaddr
Pin 27;
Pin 26;
SIwordO
SIwordlset
SIword2set
SIwordReset
Pin
Pin
Pin
Pin
"EMI DRAM control lines...
WE
OE
Pin 25;
Pin 24;
"FIFO reset line
FifoMR
Pin 17;
"Internal register bits
A19
A19Read
Pin 18;
Pin 16;
23;
22;
20;
19;
"Latch 10 bits of address
"Shift in all 20 bits of address
"(current10 + latched 10)
"Shift in first 12 data bits
"...next 12 data bits
(to JK FF)
"...and last 12 data bits (to JK FF)
"Clear SIword{1,2} from JK FF
"/WE line for DRAMs
"/OE line for DRAMs
"*** Aliases
H, L, C, X = 1, 0, .C.,
ZERO = [0, 0];
ONE
= [0, 1];
TWO
= [1, 0];
CSB = [CSB1, CSB0];
DRAM_ACCESS
FIFO_ACCESS
WordO
Wordl
Word2
=
=
!A19;
A19;
= (CSB == ZERO);
= (CSB == ONE);
= (CSB == TWO);
.X.;
"DRAM takes the lower half of address space
"..and the Video RAM takes the upper half
APPENDIX B. VC SCHEMATICS AND PAL FILES
124
fifopal.abl
"*** Equations
equations
"All MDP external WRITES to locations >= $80000 should go to the FIFO.
"Therefore, if EA10 is 1 when RAS first goes low (i.e. A19 = 1) during
" a write access, we are writing into the FIFO.
A19 = (!WR & RAS & EA10) # (!RAS & A19);
(!RAS & A19Read);
A19Read = (RAS & WR & EA10)
..
***
"DRAM control lines...
..
***
"We should de-assert the DRAMs /OE and /WE inputs for the duration of
" FIFO or MDPReadBack access cycles.
OE = A19Read
# !WR;
WE = FIFO_ACCESS
..
WR;
***
"FIFO control lines...
..
***
"The high-to-low transition of /LdAddr latches the row of the external
" memory address. Keep it low for the entire emem access cycle.
!LdAddr = (EA10 & !WR & RAS & CAS) # (!RAS & !LdAddr);
"The low-to-high transition of Saddr shifts the latched addr row and the
" current addr column into the FIFOs. The subsequent high-to-low return
" of SIaddr propagates the address through the FIFO.
(SIaddr & !RAS);
SIaddr = (!WR & !RAS & FIFO_ACCESS & CAS & WordO)
WARNING: Watch out for a race condition here. The 'output ready' from
the FIFO's comes only from a DATA FIFO, so it is assumed that the
ADDR FIFO is in sync with it. However, SIaddr goes low at 'about'
the same time as the SIword's do, so the ADDR FIFO may not have
propagated the address all the way through yet.
"SIwordO goes right to its FIFO. SIwordf1,2} go to the J inputs of a
"JK Flip Flop whic is clocked off the falling edge of /CAS.
(SIwordO & !RAS);
SIwordO = (!WR & RAS & FIFO_ACCESS & !CAS & WordO)
SIwordlset = (!WR & !RAS & FIFO_ACCESS & Wordl);
SIword2set = (!WR & !RAS & FIFO_ACCESS & Word2);
!SIwordReset
FifoMR
= RAS;
= RESET;
end FifoPal
APPENDIX B. VC SCHEMATICS AND PAL FILES
125
-!
-
r
fli
E
A
I
! i 21 I
HI
I
I; I
i,;; 9
-z
z
3j
i
a
!.
X Ifl
A
ffi
SI ti
i
i
.
0000
.ne
51|
:1494 "b
I1 I
.
.
0x3A
APPENDIX B. VC SCHEMATICS AND PAL FILES
126
mod.abl
module Mod
title 'FIFO Mod FSM
Eric McDonald
Last revised:
January
5, 1994
February 15, 1994'
" DESCRIPTION:
" Awaits OR condition from FIFOs and tries to deliver data to
" appropriate module, as determined by the table:
Module
Beg. MDP Addr.
Modsel
"1
000
"
001
$80000
$90000
"1
100
$coooo
"
101
$dOOOO
MPU
XLM
SCM
Tabsync
Mod device 'P26V12';
"*** Inputs
FClk
OR
ModSelO, ModSell, ModSel2
MpuAck, XlmAck, ScmAck
TabSync
RESET
Pin
Pin
Pin
Pin
Pin
Pin
1;
2;
3, 4, 5;
6, 8, 9;
10;
11;
"FIFO Output Ready
"Addr[18:16]
"ACKs from modules
"*** Outputs
SO
ForMpu, ForXlm, ForScm
QO, Q,
Q2, Q3
Pin 27 istype 'reg,buffer';
"FIFO Shift Out
Pin 26, 25, 24 istype 'reg,buffer';
" RDYs to mods
Pin 23, 22, 20, 19 istype
TSyncSet
'reg,buffer';
Pin 17;
"*** Bits used internally
TSet
Pin 16 istype 'reg,buffer';
'***
Aliases
X.;
H, L, C, X = 1, 0, C.,
ModSel = [ModSel2..ModSelO];
MPUSEL =
[0, 0, 0];
XLMSEL =
[0, 0, 1];
SCMSEL =
[1, 0, 0];
TSYNCSEL = [1, 0, 1];
"*** State declarations
current_state
=
[Q2..QO];
" Requires single-bit-only differences between:
"
Init0,Idle
(coming from Initl)
"
state
bits
APPENDIX B. VC SCHEMATICS AND PAL FILES
127
mod.abl
"
Idle,NewData (coming from Idle)
=
=
=
=
=
=
=
=
InitO
Initl
Idle
NewData
BadData
HandoffO
Handoffl1
TabSyncO
[ 0, 0, 0 ];
[ O, O, 1 ];
[ 0, 1, 0 ];
1,
, 0 ];
[1
[ 1, 1, 1
[ O, 1, 1
];
];
0 ];
[ 1,
0,
[ 1,
O, 1
];
' Q= 0
Q= 1
2
IQ= 6
7
"Q=
3
I'Q=
.IQ= 4
1.Q-5
II
IQ=
"*** Equations
equations
[current_state,TSet].clk = FClk;
[current_state,TSet].ar
= !RESET;
[SO,ForMpu,ForXlm,ForScm].clk = FClk;
TSyncSet = TSet
(TSyncSet & !TabSync);
State_Diagram current_state
state InitO:
SO := 1;
goto Initl;
state Initl:
if
"Upon
RESET, flush FIFO
(OR) then InitO;
else Idle;
Wait here for OR from FIFO
state Idle:
if
(OR) then NewData
else Idle;
state NewData:
if (ModSel == MPUSEL) then HandoffO
with ForMpu := 1 endwith;
else
if
(ModSel
== XLMSEL)
then HandoffO0
with ForXlm := 1 endwith;
else if (ModSel == SCMSEL) then HandoffO0
with ForScm := 1 endwith;
else if (ModSel == TSYNCSEL) then TabSyncO
with
SO
:
1; TSet
:= 1 endwith;
else BadData
with SO := 1 endwith; "Ignore unrecognized MODSEL
state BadData:
goto Idle;
" This state allows SO to be asserted after bad data
" Tell module valid data is waiting
state HandoffO0:
ForMpu := ForMpu; ForScm := ForScm; ForXlm := ForXlm;
(ForXlm & XlmAck) # (ForScm & ScmAck))
if ((ForMpu & MpuAck)
then Handoffl;
else HandoffO;
" Drop our DR signal and wait
state Handoffl:
" for module to drop its ACK...
SO := 1;
if (MpuAck # XlmAck
ScmAck)
I Note that ALL ACKs must be clear
then Handoffl;
APPENDIX B. VC SCHEMATICS AND PAL FILES
128
mod.abl
else Idle;
state TabSyncO:
goto Idle; "This
end Mod
" (can fix this with more states)
state allows TSet and SO to be asserted
APPENDIX B. VC SCHEMATICS AND PAL FILES
129
I
VI
130
APPENDIX B. VC SCHEMATICS AND PAL FILES
hA
i
I
jir I I
.4,
A
APPENDIX B. VC SCHEMATICS AND PAL FILES
131
mpuO.abl
module Mpu0
title 'Bt463 Mpu FSM PAL#0
Eric McDonald
Last revised:
January
5, 1994
February
15, 1994'
"DESCRIPTION:
Mpu0 device 'P22V10';
"*** Inputs
FClk
Eol, Eof
Sp0, Spl
ForMpu
Read
Wcnt
HHold, VHold
ErmAck
RESET
Pin
Pin
Pin
Pin
Pin
Pin
Pin
Pin
Pin
1;
2, 3;
4, 5;
6;
7;
8;
9, 10;
11;
13;
Pin
Pin
Pin
Pin
23 istype 'reg,invert';
Reset Eol, Eof
22 istype 'reg,buffer'; "Latch & ACK data
21 istype 'reg,invert'; " Bt463 /CE line
20,19,18,17,16,15,14 istype 'reg,buffer';
"Horiz and Vert syncs
"Spare inputs (unused)
H
FIFO has data for us
" Is access read or /write?
" # of 8-bit wrds? 0->1 1->3
"Should we sync up?
ERM rcvd our data
Global /RESET line
"*** Outputs
ERES
Mpu_Ack
CE
Q0,Q1,Q2,Q3,Q4,Q5,Q6
"***
Bits used internally
"*** Aliases
H, L, C, X = 1, 0, .C., .X.;
LongWord
= (Wcnt == 1);
ShortWord = (Wcnt == 0);
Write = !Read;
current_state
=
[Q6..Q0];
@include 'mpu.sta'
"*** Equations
equations
[current_state, ERES, MpuAck,
[current_state].ar
CE].clk = FClk;
= !RESET;
State_Diagram current_state
state Idle:
if (ForMpu)
then NewData
with MpuAck
else Idle;
" Loop here...
" If new incoming data, grab it
:= 1;
ERES
:= 1; endwith;
APPENDIX B. VC SCHEMATICS AND PAL FILES
132
mpuO.abl
Loop until we know FIFO has seen our ACK
state NewDataO:
if (For_Mpu) then NewDataO with MpuAck := 1 endwith;
else NewDatal;
state NewDatal:
if (VHold # HHold) then LoopTilEnd;
else case Read : ReadData0a;
Write : WriteDataOa;
endcase;
state LoopTilEnd:
if ((VHold & Eof) # (HHold &
else Dispatch;
state Dispatch:
!ERES := 1;
case Read : ReadDataOa;
Write : WriteDataOa;
endcase;
state WriteDataOa:
!DriveWO = 1;
!CE : 1;
goto WriteDataOb;
state WriteDataOb:
!DriveWO = 1;
!CE := 1;
goto WriteDataOc;
state WriteDataOc:
!DriveWO = 1;
if
(ShortWord)
then Idle;
else WriteDatala;
state WriteDatala:
!DriveWl = 1;
!CE := 1;
goto WriteDatalb;
state WriteDatalb:
!DriveWl = 1;
!CE := 1;
goto WriteDatalc;
state WriteDatalc:
!DriveWl = 1;
goto WriteData2a;
state WriteData2a:
!DriveW2 = 1;
!CE := 1;
goto WriteData2b;
state WriteData2b:
iDriveW2 = 1;
iCE := 1;
goto WriteData2c;
state WriteData2c:
!DriveWl = 1;
goto Idle;
state ReadData0a:
iCE := 1;
Eol)) then LoopTilEnd;
APPENDIX B. VC SCHEMATICS AND PAL FILES
mpuO.abl
goto ReadDataOb;
state ReadDataOb:
!CE :=
1;
! LdMRO := 1;
goto ReadDataOc;
state ReadData0c:
!CE
:= 1;
if (ShortWord) then SendToErmO;
else ReadDataOd;
state ReadDataOd:
goto ReadDatala;
"Meets minimum
CE high requirement
state ReadDatala:
!CE
:= 1;
goto ReadDatalb;
state ReadDatalb:
ICE := 1;
!LdMR1 := 1;
goto ReadDatalc;
state ReadDatalc:
!CE := 1;
goto ReadDatald;
state ReadDatald:
goto ReadData2a;
"Meets minimum !CE high requirement
state ReadData2a:
!CE := 1;
goto ReadData2b;
state ReadData2b:
!CE := 1;
!LdMR2 := 1;
goto ReadData2c;
state ReadData2c:
!CE := 1;
goto ReadData2d;
state ReadData2d:
goto SendToErmO;
1 Meets minimum
CE high requirement
state SendToErmO:
MpuRdy
:= 1;
goto SendToErml;
state SendToErml:
MpuRdy
:= 1;
if (ErmAck) then SendToErm3;
else SendToErm2;
state SendToErm2:
MpuRdy
:= 1;
if (For_Mpu) then NewDataO" If new incoming data, grab it
with Mpu_Ack := 1 endwith;
else SendToErml;
state SendToErm3:
"Wait for ErmAck to drop
if (ErmAck) then SendToErm3;
else SendToErm4;
state SendToErm4:
goto Idle;
end MpuO
133
APPENDIX B. VC SCHEMATICS AND PAL FILES
134
mpul.abl
module Mpul
title 'Bt463 Mpu FSM PAL#1
Eric McDonald
Last revised:
January
February
5, 1994
15, 1994'
"DESCRIPTION:
Mpul device 'P22V10';
"*** Inputs
FClk
Q0,Q1,Q2,Q3,Q4
Read
Wcnt
HHold, VHold
ErmAck
RESET
Pin 1;
Pin 2,3,4,5,6;
Pin
Pin
Pin
Pin
Pin
"Is access read or /write?
" # of 8-bit wrds? 0->1 1->3
"Should we sync up?
"ERM rcvd our data
"Global /RESET line
7;
8;
9, 10;
11;
13;
"*** Outputs
Pin 23,22,21 istype 'reg,invert'; " /OE
Pin 20,19,18 istype 'reg,invert'; "/Latch
Pin 17 istype 'reg,buffer'; "To ERM module
DriveW0,DriveWl,DriveW2
LdMR0,LdMRl,LdMR2
MpuRdy
"*** Aliases
H, L, C, X = 1, 0,
C.,
X.;
current_state
Idle
NewData0
NewDatal
LoopTilEnd
Dispatch
= [Q4..Q0];
= [0, 0, 0, 0,
= [0, 0, 0, 1,
= [0, 0, 0, 1,
= [0, 0, 0, 0,
= [0, 0, 0, 0,
WriteData0
WriteDatal
WriteData2
=
=
=
ReadData0b
ReadDatalb
ReadData2b
=
=
=
[ 0, 1, 0, 0, 1 ];
[ 0, 1, 0, 1, 1 ];
SendToErm0
SendToErml
SendToErm2
SendToErm3
SendToErm4
=
=
=
=
=
[ 1, 0, 0, 0, 0 ];
[ 1, 0, 0, 0, 1 ];
[ 1, 0, 0, 1, 1 ];
0
0
1
1
1
];
];
];
];
];
0, 0, 1, 0, 0 ];
[ o, 0, 1, o, 1 ];
0, 0, 1, 1, 1 ];
[ 0, 1,
[ 1,
[ 1,
1,
0, 1,
0, 1,
1,
1,
1,
1 ];
1 ];
1 ];
In_State MACRO (st) { (currentstate
"*** Equations
== ?st)
};
APPENDIX B. VC SCHEMATICS AND PAL FILES
mpul.abl
equations
IDriveWO
!DriveWl
!DriveW2
;= In_Stat6(Writ6DataO);
:= In_State(WriteDatal);
:= In_State(WriteData2);
!LdMRO := InState(ReadData0b);
!LdM4Rl := InState(ReadDatalb);
!LdMR2 := InState(ReadData2b);
MpuRdy := InState(SendToErmO)
# InState(SendToErml)
# InState(SendToErm2);
end Mpul
135
APPENDIX B. VC SCHEMATICS AND PAL FILES
136
mpu.sta
"*** State declarations
"These pairs require one-bit state bit differences:
"
Idle->NewData0
NewData0
"
"
-> NewDatal
LoopTilEnd -> Dispatch
SendErm2, SendErm3 (from SendErml)
SendErm3 -> SendErm4
0, 0 ]; "00-0 (00)
Idle
NewData0
NewDatal
LoopTilEnd
Dispatch
=
=
=
=
=
[
[
[
[
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
.0,
0, 0,
0,
0,
0,
0,
1,
1,
0,
0,
0,
1,
1,
1,
0, 0 ];
WriteDataOa
WriteData0b
WriteData0c
=
=
=
[ 0,
[ 0,
[ 0,
0,
0,
0,
1,
1,
1,
0,
0,
0,
0,
0,
0,
0, 0 ]; "04-0 (10)
0, 1 ]; "04-1 (11)
WriteDatala
WriteDatalb
WriteDatalc
=
=
=
[ 0,
0,
1,
0,
1,
[ 0,
0,
1,
0,
1,
[ 0,
0,
1,
0,
1,
0, 0 ]; "05-0
0, 1 ]; "05-1
1, 1 ]; "05-3
(14)
(15)
(17)
WriteData2a
WriteData2b
WriteData2c
=
=
=
[ 0, 0, 1, 1,
[ 0, 0, 1, 1,
[ 0. 0, 1,1
,
1,
1,
1,
0, 0 ];
0, 1 ];
1, 1 ];
(lc)
ReadDataOa
ReadData0b
ReadData0c
ReadData0d
=
=
=
=
[
[
[
[
0,
0,
0,
0,
1,
1,
1,
1,
0, 0,
0, 0,
0, 0,
0, 0,
0,
1,
0,
0,
0, 0 ]; "08-0 (20)
1, 1 ];
"08-3
ReadDatala
ReadDatalb
ReadDatalc
ReadDatald
= [ 0,
= [ 0,
= [ 0,
= [ 0,
1,
0,
"Oa-0
"Ob-0
"Oa-1
"Oa-3
ReadData2a
ReadData2b
ReadData2c
ReadData2d
=
=
=
=
[
[
[
[
SendToErm0
SendToErml
SendToErm2
SendToErm3
SendToErm4
=
=
=
=
=
[
[
[
[
[
1,
O,
1 ];
0 ];
0,
0,
0 ];
O,
0
1,
1,
0,
0,
1,
1,
0,
0,
0, 1 ];
1, 1 ];
0,
0,
0,
0,
1,
1,
1,
1,
1,
1,
1,
1,
1,
1,
0,
1,
0,
1, 1, 0,
0,
0,
0,
1,
0
0
1
1
1,
1,
1,
1,
1,
0,
0,
0,
0,
O,
0 ];
0,
0,
0,
0,
0,
0,
1,
0, 0 ];
0, 0 ];
0, 0 ];
0, 1, 1,
1,
1,
1,
1,
1,
1,
"04-3
"07-0
"07-1
"07-3
(08)
];
(13)
(ld)
(if)
"09-0 (24)
0, 1 ]; "08-1
1, 0, 1, 1,
1,
"02-0
0, 0 ]; "03-0 (Oc)
0, 0 ]; "01-0 (04)
0, 1 ]; "01-1 (05)
]; "Oe-O
]; "0 f-0
]; "Oe-1
]; "Oe-3
(21)
(23)
(28)
(2c)
(29)
(2b)
(38)
(3c)
(39)
(3b)
"10-0 '(40)
"11-0 (44)
"13-0 (4c)
"17-0
0, 1 ]; "17-1
(5c)
(5d)
APPENDIX B. VC SCHEMATICS AND PAL FILES
137
5-I
A
2
e
Ae
2I
lb
I
i
I
I
APPENDIX B. VC SCHEMATICS AND PAL FILES
138
.
.-
uLI
EI a
alI~~~,
x.
if
19 I
.
. _
I
111111111
11111-1111
c
c
a
_ _
ofqqqq
a
I
el A
1,1!I I
Lo!I
I
I I
.1
11
J
R
Ii I I Q IIit 9
L'...... L'.id
_
_
R
e
_
_
e
R
.
_
_
IggoXIRRIMi
l
_
_
_
7
_
_
_
_
_
_
Il1
_
- - .-Ilsx-xxr. . . . .
_
.
I I
_
-~~~~
:,
I
_
_
_
I
; I
vL i A A YL
IP
IPIPI.
P_
' . . ..
X
P |_llII
.1
.
I
.
.
lii
9
1
_
:lil,
_|_1_l
llmlu
b
11111I11
I I AIllI ,I
Mv
.
I
II 'l
l
1
-.
Pid
PPP P
. .. .. .. .. .. .. .
iti
ii ,, ,ll
fttttthfft
'tttttittt
!RllBB"p',
MWi
I-~
III
, h hh A.h
wm.1
11 I
11i1
-----B1111d
, h -h-hh-A---A
I
__
11-1 1111
rr
I
~B
A
11,
I
tftt tttt
Y
Y Y
-
.133 .2 t tfftt
- - - -
-
-
I
_ _______
11~~III..I11111
I
Bmmmmmmllmll----
a
A
:
0:b"A
:
ae
11 BILKAA
. 5g
9 Aa
u
19
D.
a ~ h11
IE 19A~~~~~~
II
I
Esg
:J!d J'a
1
'.1 1411,11111,111
11,11,r
N'Tit.iiiWil.1 111iittlilit
,
_____________
...................................
___________
M~
j,
mm l,
mh
it
i
APPENDIX B. VC SCHEMATICS AND PAL FILES
139
M.
jJi
i!
4-R
I I
I
'iV1
=
I
2
1 1
A A
I I I
1i
III II I
J . . IJ
-M YYy
kilsilill
t
Ca
U) t
3 1
t
- -I - - - l I
,XtUAI
'i ,
0
1)
no
II -,;DI
.
A
Id
......
4. ..4
F I' EI I' I I' I' I' I' I' I
t | W,.
I_ql1''
I
I
- |
4
x
. 1. 1. 1. 1. 1. 1. 1. 1. 1. I
I.
...
_
-.....
·
,
Iil
,
!
I
I III
t ht
1
- - *i .I IBL
I I
e
I
&&
11N
1.W . 1. 1. 1. 1. 1. 1. 1. 1. I
I!
...
x<
....
I--
APPENDIX B. VC SCHEMATICS AND PAL FILES
140
xlmO. abl
module XlmO
title 'XLM FSM PAL#O
Eric McDonald
Last revised:
January
5, 1994
February
15, 1994'
"DESCRIPTION:
XlmO device 'P26V12';
"*** Inputs
Pin
Pin
Pin
Pin
Pin
Pin
Pin
Pin
Pin
Pin
1;
Eol,Eof,ForXlm
Pin
Pin
Pin
Pin
Pin
27 istype 'reg,invert'; " Reset Eol, Eof
26 istype 'reg,buffer'; " Latch & ACK data
25 istype 'reg,buffer'; " XLM addr valid
22,20,19,18,17 istype 'reg,buffer'; "State
24,16,15 istype 'reg,buffer'; "Sync up
"*** Bits used internally
Blocked
Pin 23 istype 'reg,buffer';
FClk
Eol_Async, EofAsync
HHold, VHold
For_XlmAsync
Type0, Typel
TabSync
Eot
SpO
HBlk, VBlk
RESET
2, 3;
4, 5;
6;
8, 9;
10;
11;
12;
13, 14;
28;
"Horiz and Vert syncs
"Should we sync up?
FIFO has data for us
"Type of data
l!
11
II
II
1!
Reached end of tables?
Unused spare
Blanking signals
Global /RESET line
"*** Outputs
ERES
Xlm_Ack
TRANSFER
Q0, Q,
Q2, Q3, Q4
"*** Aliases
H,
L, C, X = 1, 0,
Type
=
C.,
X.;
[Typel, TypeO];
WRITE_XFERADDR
LOAD_TABLES
LOAD_FLAGS
UNDEFINED
= [0,
= [0,
= [1,
= [1,
0];
1];
1];
0];
"*** State declarations
include 'xlm.sta'
"*** Equations
equations
current_state.clk
= FClk;
[TRANSFER,ERES,XlmAck,Blocked,Eof,Eol,For_Xlm].clk
current_state.ar
= !RESET;
= FClk;
"
Waiting for blk?
APPENDIX B. VC SCHEMATICS AND PAL FILES
141
xlmO.abl
Eol := Eol_Async;
Eof := Eof_Async;
For_Xlm := For_Xlm_Async;
StateDiagram current_state
state Idle:
"End of frame, update counters
if (Eof&ERES) then UpdateCtrs;
else if (Eol&ERES) then BroadcastO; "End of line, send address
"New table data, record it
else if (ForXlm) then NewDataO
else
Idle;
" Loop until we know FIFO has seen our ACK
state NewDataO:
if (ForXlm) then NewDataO
with Xlm_Ack := 1 endwith;
else NewDatal;
state NewDatal:
if (HHold # VHold) then LoopTilEnd
else goto Dispatch;
state Dispatch:
if
(Type == WRITE_XFERADDR)
then WriteDataO;
else if (Type == LOAD_TABLES) then LoadTables;
else if (Type == LOAD_FLAGS) then LoadFlags;
Discard unknown data type
else goto Idle;
state LoopTilEnd:
Blocked
:= 1;
if (Eof # Eol)
then BroadcastO;
else LoopTilEnd;
state WriteDataO:
!DRADDR
!DRDATA
: 1;
:= 1;
Enable address and data lines coming
from FIFO registers...
goto WriteDatal;
state WriteDatal:
.1
11
.1
!DRADDR
!DRDATA
!WRSRAM
: 1;
: 1;
:= 1;
Write into SRAM one cycle later
goto WriteData2;
state WriteData2:
1.
11
!DRADDR := 1;
!DRDATA : 1;
goto Idle;
And keep address/data valid for 1 more cycle
state LoadTables:
.1
11
!DRDATA : 1;
LDVT := 1;
goto Idle;
Drive FIFO data lines and ask TABPAL to
latch in new tables
state LoadFlags:
!DRDATA :
LDFLAGS
:
goto Idle;
1;
1;
Drive FIFO data lines and ask TABPAL to
latch in new flags
state UpdateCtrs:
!LINERES
:= 1;
Reset low SRAM address bits to zero
APPENDIX B. VC SCHEMATICS AND PAL FILES
142
xlmO.abl
if (TabSync # Eot) then ResetTabCtr; "Reset high addr bits if
last table or TabSync
else IncTabCtr;
"Otherwise, just increment them
state ResetTabCtr:
!TABLD
:= 1;
goto BroadcastO;
state IncTabCtr:
!TABINC
:= 1;
goto BroadcastO;
state BroadcastO:
Blocked := Blocked;
It
!DRCTRS
!OESRAM
:= 1;
:= 1;
goto Broadcastl;
state Broadcastl:
Blocked := Blocked;
All
!DRCTRS
!OESRAM
:= 1;
:= 1;
"Remember if blocked
Drive address lines to SRAM...
and drive SRAM into output latches
"Remember if blocked
Drive address lines to SRAM...
and drive SRAM into output latches
goto WaitO;
state WaitO:
Blocked := Blocked;
goto Waitl;
state Waitl:
Blocked := Blocked;
goto Wait2;
state Wait2:
Blocked := Blocked;
goto Wait3;
state Wait3:
Blocked := Blocked;
if
(!VBlk)
then BrdcstWithoutInc;
else
BrdcstAndInc;
state BrdcstAndInc:
Blocked := Blocked;
TRANSFER
Remember if blocked
:= 1;
!LINEINC := VBlk;
if (!Blocked) then Idle
with
else if (HHold
ERES
:= 1 endwith;
(VHold & Eof)) then Dispatch
with
!ERES
:= 1 endwith;
else LoopTilEnd
with
Blocked
:= 1;
state BrdcstWithoutInc:
Blocked := Blocked;
"Remember
TRANSFER
!ERES
:= 1 endwith;
if blocked
:= 1;
if (!Blocked) then Idle
with ERES := 1 endwith;
else if (HHold
(VHold & Eof)) then Dispatch
with ERES := 1 endwith;
APPENDIX B. VC SCHEMATICS AND PAL FILES
143
xlmO.abl
else LoopTilEnd
with
end XlmO
Blocked
:= 1; !ERES
:= 1 endwith;
APPENDIX B. VC SCHEMATICS AND PAL FILES
144
xlml.abl
module Xlml
title 'XLM FSM PAL#1
Eric McDonald
Last revised:
January
February
5, 1994
15, 1994'
DESCRIPTION:
Xlml device 'P22V10';
"*** Inputs
Pin
Pin
Pin
Pin
Pin
Pin
FClk
Q0, Q1, Q2, Q3, Q4
Sp0, Spl
TabSync
Type0, Typel
RESET
1;
2,3,4,5,6;
.,
7, 8;
9;
10, 11;
13;
II
State
Unused spares
I!
II
Type of data
Global /RESET line
"*** Outputs
DRADDR
DRDATA
DRCTRS
Pin 23 istype 'reg,invert';
Pin 22 istype 'reg,invert';
Pin 21 istype 'reg,invert';
LINEINC
LINERES
TABINC
TABRES
TABLD
Pin
Pin
Pin
Pin
Pin
LDFLAGS
LDVT
Pin 15 istype 'reg,buffer';
Pin 14 istype 'reg,buffer';
20
19
18
17
16
istype
istype
istype
istype
istype
"*** Aliases
H, L, C, X = 1, 0,
Type
=
WRITE_XFERADDR
LOAD_TABLES
LOAD_FLAGS
UNDEFINED
C.,
X.;
[Typel, Type0];
= [0, 0];
= [0, 1];
= [1,
=
1];
[1, 0];
"*** State declarations
@include 'xlm.sta'
"*** Equations
equations
[DRADDR,DRDATA,DRCTRS].clk
= FClk;
!DRADDR := In_State(WriteData0) #
'reg,invert';
'reg,invert';
'reg,invert';
'reg,invert';
'reg,invert';
"Ctrl
"Ctrl
"Ctrl
sgnl to ADDR0,1
sgnl to DATA0,1
sgnl to LINE/TAB
" Ctrl
"Ctrl
"Ctrl
" Ctrl
" Ctrl
sgnl
sgnl
sgnl
sgnl
sgnl
"Ctrl
"Ctrl
sgnl to TABPAL
sgnl to TABPAL
to LINEPAL
to LINEPAL
to TABPAL
to TABPAL
to TABPAL
APPENDIX B. VC SCHEMATICS AND PAL FILES
xlml. abl
InState(WriteDatal)#
InState(WriteData2);
!DRDATA := InState(WriteDataO)
#
InState(WriteDatal)#
InState(WriteData2)#
InState(LoadTables)#
InState(LoadFlags);
!DRCTRS := InState(BroadcastO) #
InState(Broadcastl);
!LINEINC := InState(BrdcstAndInc);
!LINERES := InState(UpdateCtrs);
!TABINC
:= InState(IncTabCtr);
!TABLD
:= InState(ResetTabCtr);
!TABRES
:= 0;
LDFLAGS
:= InState(LoadFlags);
LDVT
:= InState(LoadTables);
end Xlml
145
146
APPENDIX B. VC SCHEMATICS AND PAL FILES
xlm2 .abl
module Xlm2
title 'XLM FSM PAL#2
Eric McDonald
Last revised:
January
February
5, 1994
15, 1994'
"DESCRIPTION:
Xlm2 device 'P22V10';
"*** Inputs
FClk
Q0, Q,
Pin
Pin
Pin
Pin
Pin
Pin
Q2, Q3, Q4
Eol, Eof
HBlk,VBlk
SpO
RESET
1;
2,3,4,5,6;
7, 8;
9, 10;
11;
13;
" State
"Horiz and Vert syncs
"Blanking signals
" Unused spare
"Global /RESET line
"*** Outputs
OESRAM
WRSRAM
HReset,VReset
Auxl,Aux2,Aux3,Aux4
Pin
Pin
Pin
Pin
23 istype 'reg,invert';
22 istype 'reg,invert';
21,20;
19,18,17,16;
"*** Aliases
H, L, C, X = 1, 0,
C.,
X.;
"*** State declarations
@include 'xlm.sta'
"*** Equations
equations
[OESRAM,WRSRAM,Auxl,Aux2,Aux3,Aux4].clk = FClk;
!OESRAM := In_State(Broadcast0) #
In_State(Broadcastl);
!WRSRAM := In_State(WriteDatal);
HReset
= Eol;
VReset
= Eof;
Auxl
=
!HBlk;
Aux2
= !VBlk;
end Xlm2
"Ctrl
"Ctrl
sgnl to SRAM
sgnl to SRAM
APPENDIX B. VC SCHEMATICS AND PAL FILES
xlm. sta
"*** State declarations
current_state
= [Q4, Q3, Q2, Q1, QO];
[
, 0, 0
00
Idle
=
NewData0
NewDatal
Dispatch
= [ 0, 0, 0, 0, 1 ;
=
0, 0, 0, 1, 0
;
= [ 1, 0, 0, 1, 1 ];
"Q= 01
"Q= 02
"Q= 13
LoopTilEnd
=
[ 0,
];
"Q= 03
WriteData0
WriteDatal
WriteData2
=
=
=
[ 0, 1, 0, 0, 0 ];
[ 0, 1, 0, O, 1 ];
[ 0, 1, 0, 1, 0 ];
"Q= 08
"Q= 09
"Q= Oa
LoadTables
LoadFlags
=
BroadcastO
Broadcastl
=
=
WaitO0
Waitl
Wait2
Wait3
=
=
=
=
UpdateCtrs
ResetTabCtr
IncTabCtr
= [ 1, 1, 0, 0, 0
= [ 1, 1, 1, 0, 0
= [ 1, 1, 1, 1, 0
,
,
0,
0,
1,
1
];
"Q=
[ 0, 1, 1, 0, 0 ];
= [ 0, 1, 1, 1, 0 ];
"Q= Oc
"Q= Oe
"Q= 10
[ 1, 0, 0, 0, 0 ];
[ 1, 0, O, O, 1 ];
"Q= 11
BrdcstAndlnc
= [ 1, 0, 0, 1, 0 ;
"Q= 12
BrdcstWithoutInc
= [ 1, 0, 1, 1, 0 ;
Q=16
In_State
MACRO
0, 0, 1, 0, 0
];
I 0, 0, 1, 0, 1 ];
[ 0, 0, 1, 1, 1 ];
[ 0, 0, 1, 1, 0 ];
];
];
];
(st) { (current_state
"Q=04
"Q=05
"Q=07
"Q=06
"Q= 18
"Q= lc
"Q= le
== ?st)
};
147
APPENDIX B. VC SCHEMATICS AND PAL FILES
148
xlmline.abl
module XlmLine
title 'XLM Line Counter FSM
Eric McDonald
Last revised:
January
February
5, 1994
15, 1994'
DESCRIPTION:
"This
PAL is basically just a 10-bit counter with /INC, /RES, and /OE lines
XlmLine device 'P22V10';
"*** Inputs
FClk
LineInc
LineRes
OE
GRESET
Pin
Pin
Pin
Pin
Pin
1;
2;
3;
4;
5;
" Increment counter
"Reset counter to zero
"Output enable
"Global /RESET line
"*** Outputs
A9,A8,A7,A6,A5,A4,A3,A2,A1,A0
Pin 14,15,16,17,18,19,20,21,22,23 istype 'reg,buffer';
"*** Equations
HOLD = LineInc & LineRes;
INC
= !LineInc;
RESET = LineInc & !LineRes;
equations
[A9..A0].clk = FClk;
[A9..A0].oe = !OE;
[A9..A0].ar = !GRESET;
!A0 := RESET
# (HOLD & !A0.fb)
# (INC & A0.fb);
!A1 := RESET
# (HOLD & !Al.fb)
# (INC & !A0.fb & !Al.fb)
# (INC & A0.fb & Al.fb);
!A2 := RESET
#
#
#
#
(HOLD
(INC
(INC
(INC
& !A2.fb)
& !A0.fb& !A2.fb)
& !Al.fb& !A2.fb)
& A0.fb & Al.fb & A2.fb);
!A3 := RESET
# (HOLD & !A3.fb)
# (INC & IA0.fb &
# (INC & !Al.fb &
!A3.fb)
lA3.fb)
APPENDIX B. VC SCHEMATICS AND PAL FILES
xlmline.abl
# (INC
& !A2.fb & !A3.fb)
# (INC & A.fb & Al.fb& A2.fb& A3.fb);
!A4
:= RESET
$
#
#
#
#
#
!A5
!A4.fb)
!A0.fb & A4. fb)
!Al.fb & !A4.fb)
!A2.fb & !A4.fb)
!A3.fb & !A4.fb)
A0.fb & Al. fb & A2.fb & A3.fb & A4.fb);
:= RESET
#
#
#
#
#
#
#
!A6
(HOLD &
(INC &
(INC &
(INC &
(INC &
(INC &
(HOLD &
(INC &
(INC &
(INC &
(INC &
(INC &
(INC &
!A5.fb)
!A0.fb &
!Al.fb &
1A2.fb &
!A3.fb &
!A4.fb &
!A5.fb)
!A5.fb)
!A5. fb)
!A5.fb)
!A5.fb)
A0.fb & Al. fb & A2.fb & A3.fb & A4.fb & A5.fb);
:= RESET
*
#
#
#
#
#
#
#
(HOLD&
(INC &
(INC &
(INC &
(INC &
(INC &
(INC &
(INC &
!A6.fb)
!A0.fb &
!Al.fb &
!A2.fb &
!A3.fb &
!A4.fb &
!A5.fb &
!A6.fb)
!A6.fb)
!A6.fb)
!A6. fb)
!A6. fb)
!A6.fb)
A0.fb & Al. fb
& A2.fb & A3.fb & A4.fb & A5.fb & A6.fb);
!A7 := RESET
# (HOLD & !A7.fb)
#
#
#
#
#
#
#
#
(INC
(INC
(INC
(INC
(INC
(INC
(INC
(INC
&
&
&
&
&
&
&
&
!A0.fb& !A7. fb)
!Al.fb& !A7. fb)
!A2.fb& !A7. fb)
!A3.fb & !A7. fb)
!A4.fb & ! A7. fb)
!A5.fb & !A7. fb)
!A6.fb& !A7. fb)
A0.fb & Al. fb & A2.fb & A3.fb & A4.fb & A5.fb & A6.fb
& A7.fb);
!A8
:= RESET
# (HOLD & !A8.fb)
# (INC & !A0.fb & !A8.fb)
# (INC & !Al.fb & !A8.fb)
# (INC & iA2.fb & !A8.fb)
#
#
#
#
#
(INC
(INC
(INC
(INC
(INC
&
&
&
&
&
!A3.fb
!A4.fb
!A5.fb
!A6.fb
!A7.fb
&
&
&
&
&
!A8.fb)
!A8.fb)
!A8.fb)
!A8.fb)
!A8.fb)
# (INC & A0.fb & Al.fb & A2.fb & A3.fb & A4.fb & A5.fb & A6.fb
& A7.fb & A8.fb);
"A9.fb
is programmed differently because it was stuck on a pin without
149
150
APPENDIX B. VC SCHEMATICS AND PAL FILES
xlmline.abl
enough product terms (we need 11 but have only 8).
It doesn't toggle back to 0 once it's been set.
But we shouldn't be trying to write beyond the 10-bit address space anyway.
A9
:=
(HOLD &
# (INC
&
A9.fb)
A9.fb)
# (INC & A.fb & Al.fb & A2.fb& A3.fb& A4.fb& A5.fb& A6.fb
& A7.fb & A8.fb & !A9.fb);
end XlmLine
APPENDIX B. VC SCHEMATICS AND PAL FILES
151
xlmtab. abl
module XlmTab
title 'XLM Table Counter FSM
Eric McDonald
Last revised:
January
February
5, 1994
15, 1994'
"DESCRIPTION:
XlmTab device 'P26V12';
"*** Inputs
FClk
TabInc
TabLd
TabRes
LdFlags
LdVT
RESET
LvtD0,LvtDl,LvtD2
FvtD0,FvtDl,FvtD2
Pin
Pin
Pin
Pin
Pin
Pin
Pin
Pin
Pin
1;
2;
3;
4;
5;
6;
8;
Pin
Pin
Pin
Pin
Pin
27,26,25 istype 'reg,buffer'; "Last Valid Table
24,23,18 istype 'reg,buffer'; "First Valid Table
22,20,19 istype 'reg,buffer'; "Current table
"Spare flags
17,16 istype 'reg,buffer';
15;
"Current table == Last Valid Table
10,11,12;
13,14,28;
"Increment table counter
"Load FVT into table counter
" Reset table counter to 0
"Load into FLAGS register
Load FVT and LVT registers
"Global /RESET line
"Inputs for LVT
"Inputs for FVT
"*** Outputs
LVT0,LVT1,LVT2
FVT0,FVT1,FVT2
Tab0,Tabl,Tab2
SpO,Spl
Eot
"*** Bits used internally
"*** Aliases
H, L, C, X = 1, 0,
LVT
= [LVT2, LVT1,
C.,
X.;
LVT0];
FVT = [FVT2, FVT1, FVT0];
Tab
=
[Tab2, Tabl,
TabO];
LvtData = [LvtD2, LvtD1, LvtD0];
FvtData = [FvtD2, FvtD1, FvtD0];
HOLD =
INC
=
LOAD =
TabInc & TabLd;
!TabInc;
TabInc & !TabLd;
"*** Equations
equations
LVT.clk = FClk;
FVT.clk
[Spl,Sp0].clk
= FClk;
= FClk;
Tab.clk
= FClk;
"Reload FVT and LVT registers upon receipt of LdVT signal from XLM0 Pal
FVT0 := (!LdVT & FVT0) # (LdVT & FvtD0);
152
APPENDIX B. VC SCHEMATICS AND PAL FILES
xlmtab.abl
FVT1 := (!LdVT & FVT1) # (LdVT & FvtDl);
FVT2
:= (!LdVT & FVT2)
#
(LdVT & FvtD2);
LVT0 := (!LdVT & LVT0) # (LdVT & LvtD0);
LVT1 := (!LdVT & LVT1) # (LdVT & LvtDl);
LVT2 := (!LdVT & LVT2) # (LdVT & LvtD2);
"Reload
Sp0
Spl
FLAGS register upon receipt of LdFlags signal from XLM0 Pal
& Sp0) # (LdFlags & LvtD0);
& Spl) # (LdFlags & LvtDl);
:= (!LdFlags
:= (!LdFlags
"The
table counter can either hold, reload, or increment by one
Tab.ar
!TabO
=
!RESET;
:= (HOLD & !TabO)
# (LOAD & !FVT0)
# (INC & TabO);
!Tabl
:= (HOLD & !Tabl)
# (LOAD &
FVT1)
# (INC & !TabO &
# (INC & TabO &
!Tab2
:= (HOLD &
!Tabl)
Tabl);
!Tab2)
# (LOAD & !FVT2)
# (INC & TabO & !Tab2)
# (INC & !Tabl & !Tab2)
# (INC & TabO & Tabl & Tab2);
"Raise
Eot output when table counter == LVT
Eot = Tab == LVT;
end XlmTab
APPENDIX B. VC SCHEMATICS AND PAL FILES
153
ii
N~~
jh I
Aunt
°Lrneh
fllS^iSLLLI~sLE
I
I
154
APPENDIX B. VC SCHEMATICS AND PAL FILES
I II, 0
v
v
I
v
v
I
Ii
.1
Wid
'17r-L7
I
17- -I1
0
IV
h
v
1.
APPENDIX B. VC SCHEMATICS AND PAL FILES
155
APPENDIX B. VC SCHEMATICS AND PAL FILES
156
scmline. abl
module ScmLine
-
title 'SCM Line Counter FSM
Eric McDonald
Last revised:
January
5, 1994
February 15, 1994'
" DESCRIPTION:
I
-
-
-
-
"This PAL implements a 4-bit counter, a 4-bit register, and a comparator
"between the pair.
ScmLine device 'P22V10';
"*** Inputs
FClk
LineInc
LineRes
OE
LdLVL
GRESET
SpO
LvlD0,LvlD1,LvlD2,LvlD3
"***
Pin
Pin
Pin
Pin
Pin
Pin
Pin
Pin
1;
2;
3;
4;
5;
6;
7;
" Increment counter
" Reset counter to zero
"Output enable
" Load LVL register
"Global /RESET line
" Spare; unused
9,10,11,13; "Data
inputs for LVL register
Outputs
L0,L1,L2,L3
LVL0,LVL1,LVL2,LVL3
NotAtEot
Pin 23,22,21,20 istype 'reg,buffer';
Pin 19,18,17,16 istype 'reg,buffer'; "Last Valid Line
Pin 15 istype 'invert';
" Current cntr != LVL
"*** Aliases
H, L, C, X = 1, 0, .C., .X.;
Line = L3..L0];
LVL = LVL3..LVL0];
HOLD = !LineInc
INC =
LineInc
RESET = !LineInc
IGNORE = LineInc
"***
&
&
&
&
LineRes;
LineRes;
LineRes;
LineRes;
Equations
equations
[Line,LVL].clk
= FClk;
Line.oe
= !OE & !LineInc & !LineRes;
Line.ar
=
"Reload
LVL0 :=
LVL1 :=
LVL2 :=
LVL3 :=
!GRESET;
LVL registers upon receipt of LdLVL signal from SCM0 Pal
(!LdLVL & LVL0) # (LdLVL & LvlD0);
(!LdLVL & LVL1) # (LdLVL & LvlD1);
(!LdLVL & LVL2) # (LdLVL & LvlD2);
(!LdLVL & LVL3) # (LdLVL & LvlD3);
APPENDIX B. VC SCHEMATICS AND PAL FILES
scmline abl
!L0
:= RESET
# (HOLD & !L0.fb)
# (IGNORE & !L0.fb)
#(INC & L0.fb);
!L1:= RESET
# (HOLD & !Ll.fb)
# (IGNORE & Ll.fb)
# (INC & !L0.fb & !Ll.fb)
# (INC & L.fb & Ll.fb);
!L2
:= RESET
#
#
#
#
(HOLD &
(IGNORE
(INC &
(INC &
!L2.fb)
& !L2.fb)
!L0.fb & !L2.fb)
!Ll.fb & !L2.fb)
# (INC & L.fb & Ll.fb& L2.fb);
!L3
:= RESET
# (HOLD &
#(IGNORE
# (INC &
# (INC &
# (INC &
!L3.fb)
& !L3.fb)
!L0.fb & !L3.fb)
!Ll.fb & !L3.fb)
!L2.fb & !L3.fb)
(INC & L.fb & Ll.fb& L2.fb& L3.fb);
Raise Eot output when line counter == LVL
!NotAtEot
=
end ScmLine
(Line.fb
!= LVL);
157
APPENDIX B. VC SCHEMATICS AND PAL FILES
158
scmtab.abl
module ScmTab
title 'SCM Table Counter FSM
Eric McDonald
Last revised:
January
February
5, 1994
15, 1994'
"DESCRIPTION:
i
-
-
-
-
ScmTab device 'P26V12';
"*** Inputs
FClk
TabInc
TabLd
OE
LdFlags
LdVT
RESET
LvtD0,LvtDl,LvtD2
FvtD0,FvtDl,FvtD2
Pin
Pin
Pin
Pin
Pin
Pin
Pin
Pin
Pin
1;
2;
3;
4;
5;
6;
8;
Pin
Pin
Pin
Pin
Pin
Pin
27,26,25 istype 'reg,buffer';
24,23,22 istype 'reg,buffer';
20,19,18 istype 'reg,buffer';
17 istype 'reg,buffer';
16 istype 'reg,buffer';
10,11,12;
13,14,28;
"Increment table counter
"Load FVT into table counter
"Output enable for Tab[2:0]
"Load into FLAGS register
"Load FVT and LVT registers
"Global /RESET line
"Inputs for LVT
"Inputs for FVT
"*** Outputs
Tab0,Tabl,Tab2
FVT0,FVT1,FVT2
LVT0,LVT1,LVT2
Go
SpO
NotAtEot
15 istype
"Current table
"First Valid Table
"Last Valid Table
"ScmGo signal
"Spare flags
'invert';
"*** Bits used internally
"*** Aliases
H, L, C, X = 1, 0,
C.,
X.;
LVT = [LVT2, LVT1, LVT0];
FVT = [FVT2, FVT1, FVT0];
Tab = [Tab2, Tabl, TabO];
LvtData = [LvtD2, LvtDl, LvtD0];
FvtData = [FvtD2, FvtDl, FvtD0];
HOLD =
INC =
LOAD =
!TabInc
&
TabLd;
TabInc & !TabLd;
!TabInc & TabLd;
IGNORE = TabInc & TabLd;
"*** Equations
equations
[LVT,FVT,Tab,Go,SpO].clk
"Reload
= FClk;
FVT and LVT registers upon receipt of LdVT signal from SCM0 Pal
APPENDIX B. VC SCHEMATICS AND PAL FILES
scmtab.abl
FVT0 := (!LdVT & FVT0) # (LdVT & FvtD0);
FVT1 := (!LdVT & FVT1) # (LdVT & FvtDl);
FVT2 := (!LdVT & FVT2) # (LdVT & FvtD2);
LVT0 := (!LdVT & LVT0) # (LdVT & LvtD0);
LVT1 := (!LdVT & LVT1) # (LdVT & LvtDl);
LVT2 := (!LdVT & LVT2) # (LdVT & LvtD2);
"Reload
Go.ar
FLAGS register upon receipt of LdFlags signal from SCM0 Pal
=
!RESET;
Go := (!LdFlags & Go) # (LdFlags & LvtD0);
Sp0 := (!LdFlags & Sp0) # (LdFlags & LvtDl);
"The
table counter can either hold, reload, or increment by one
Tab.ar
= !RESET;
Tab.oe = !OE & !TabInc & !TabLd;
!TabO :=
#
#
#
(HOLD & !TabO.fb)
(IGNORE & !TabO.fb)
(LOAD & !FVT0)
(INC & TabO.fb);
!Tabl := (HOLD & !Tabl.fb)
# (IGNORE & !Tabl.fb)
# (LOAD & !FVT1)
# (INC & !TabO.fb& !Tabl.fb)
# (INC & TabO.fb & Tabl.fb);
!Tab2 :=
#
#
#
#
(HOLD & !Tab2.fb)
(IGNORE & !Tab2.fb)
(LOAD & !FVT2)
(INC & !TabO.fb & !Tab2.fb)
(INC & !Tabl.fb & !Tab2.fb)
# (INC &
"Raise
TabO.fb & Tabl.fb & Tab2.fb);
Eot output when table counter == LVT
!NotAtEot = (Tab.fb != LVT);
end ScmTab
159
APPENDIX B. VC SCHEMATICS AND PAL FILES
160
scmO. abl
module Scm0
title 'Scm FSM PAL#O
Eric McDonald
Last revised:
January
February
5, 1994
15, 1994'
" DESCRIPTION:
Scm0 device 'P26V12';
"*** Inputs
FClk
Eol, Eof
HHold, VHold
For_Scm
Type0, Typel
TabSync
LVT,LVL
RamCEAck
ReloadAck
poRESET
SpO
Pin
Pin
Pin
Pin
Pin
Pin
Pin
Pin
Pin
Pin
Pin
1;
2, 3;
4, 5;
6;
8, 9;
10;
11, 12;
13;
14;
28;
15;
Pin
Pin
Pin
Pin
Pin
" Reset Eol, Eof
27 istype 'reg,invert';
25,24,23,22,20 istype 'reg,buffer'; "State bits
19 istype reg,buffer'; " Reload SCBlocks request
18 istype 'reg,buffer'; " Assert /RAMCE request
17 istype 'reg,buffer'; " Latch & ACK FIFO data
II
II
II
II
Horiz and Vert syncs
Should we sync up?
FIFO has data for us
Type of data
II
II
I'
II
II
II
Reached end of tables?
ACK from SCCtl for RamCE request
ACK from SCCtl for Reload request
Power-on/global RESET line
Unused spare
"*** Outputs
ERES
Q0,Q1,Q2,Q3,Q4
Reload
RamCE
Scm_Ack
"*** Bits used internally
Pin 26 istype 'reg,buffer'; "Data
Blocked
ready to be written?
"*** Aliases
H, L, C, X = 1, 0,
Type =
WRITE_DATA
LOAD_TABLES
LOAD_LVL
LOAD_FLAGS
.C.,
X.;
[Typel,Type0];
=
=
=
=
[0,
[0,
[1,
[1,
0];
1];
0];
1];
"*** State declarations
@include 'scm.sta'
"*** Equations
equations
[current_state,ERES,Reload,RamCE,ScmAck,Blocked].clk
current_state.ar
= poRESET;
= FClk;
APPENDIX B. VC SCHEMATICS AND PAL FILES
161
cmO. bl
State_Diagram current_state
state IdleO: " If end of line, reload SCBlocks
if (Eol) then DoReload;
else Idlel;
state Idlel: " If new data from FIFO, ack and process it
if (ForScm) then NewDataO with Scm_Ack := 1 endwith;
else IdleO;
state NewDataO:
" Loop until we know FIFO has seen our ACK
if (ForScm) then NewDataO with Scm_Ack := 1 endwith;
else NewData1;
state NewDatal:
if (HHold # VHold # (Type == LOAD_FLAGS)) then LoopTilEol;
We require an implicit HHold on LOAD_FLAGS to avoid race conditions
with the Go flag-in ScmCt0l
else Dispatch;
state LoopTilEol:
Blocked
:= 1;
if (Eol) then DoReload;
else LoopTilEol;
state DoReload:
Blocked := Blocked;
"Remember
if blocked
Reload := 1;
Ask SCCtl to do a reload
if (!ReloadAck) then DoReload;
"Loop here until we get ReloadAck
else if (Eof) then UpdateTab; " TAB and LINE get updated at Eof
else UpdateLine;
" Just LINE gets updated at Eol
state UpdateTab:
Blocked := Blocked;
TabOp
=
(LVT & LOAD)
#
(!LVT & INC);
LineOp = LOAD;
goto UpdateDone;
state UpdateLine:
Blocked := Blocked;
LineOp
=
(LVL & LOAD)
# (!LVL & INC);
goto UpdateDone;
state UpdateDone:
!ERES := 1;
if (!Blocked)
then
IdleO;
else if (!VHold # Eof) then Dispatch;
else LoopTilEol;
state Dispatch:
if (Type == WRITE_DATA) then WriteDataO;
else if (Type == LOAD_TABLES) then LoadTables;
else if (Type == LOAD_LVL) then LoadLvl;
else LoadFlags;
state LoadTables:
!DRDATA := 1;
LDVT := 1;
goto IdleO;
state LoadFlags:
!DRDATA := 1;
LDFLAGS := 1;
Drive FIFO data lines and ask TABPAL to
latch in new tables
Drive FIFO data lines and ask TABPAL to
latch in new flags
APPENDIX B. VC SCHEMATICS AND PAL FILES
162
scmO.abl
goto IdleO;
1.
state LoadLvl:
!DRDATA := 1;
LDLVL :=1;
goto IdleO;
state WriteDataO:
RamCE
TabOp
:= 1;
= IGNORE;
Drive FIFO data lines and ask LINEPAL to
latch in new LVL
Wait here til SCCtl has seen our RamCE request
LineOp
= IGNORE;
if (!RamCEAck) then WriteDataO;
else WriteDatal;
state WriteDatal:
11
11
11
1.
RamCE
TabOp
:= 1;
= IGNORE;
LineOp
RamCE
TabOp
:= 1;
= IGNORE;
11
!DRADDR := 1;
1.
!DRDATA
!WRSRAM
= IGNORE;
Enable address and data lines coming
from FIFO registers...
!DRADDR : 1;
!DRDATA := 1;
goto WriteData2;
state WriteData2:
LineOp
= IGNORE;
Write into SRAM one cycle later
:= 1;
:= 1;
goto WriteData3;
state WriteData3:
1.
11
1.
RamCE
TabOp
:= 1;
= IGNORE;
LineOp
!DRDATA
= IGNORE;
And keep address/data valid for 1 more cycle
IDRADDR := 1;
:= 1;
goto WriteData4;
state WriteData4:
TabOp
= IGNORE;
LineOp
= IGNORE;
if (RamCEAck) then WriteData4;
else
end ScmO
IdleO;
Wait for SCCtl to drop RamCEAck
APPENDIX B. VC SCHEMATICS AND PAL FILES
163
scml.ab
module Scml
title 'Scm FSM PAL#1
Eric McDonald
Last revised:
5, 1994
January
February 15, 1994'
"DESCRIPTION:
Scml device 'P22V10';
n*** Inputs
Pin 1;
FClk
Q0,Q1,Q2,Q3,Q4
TabSync
LVT, LVL
poRESET
Pin 2,3,4,5,6;
SpO
State bits
Pin
Pin
Pin
Pin
7;
8, 9;
10;
11;
Pin
Pin
Pin
Pin
Pin
23,22 istype 'reg,invert'; "Drive registers
" LINEPAL signals
21,20;
19,18;
" TABPAL signals
17,16,15 istype 'reg,buffer';" More PAL load sigs
" Ctrl signal to SRAM
14 istype 'reg,invert';
I.
Reached end of tables?
Power-on/global RESET line
Unused spare
"*** Outputs
DRADDR,DRDATA
LINEINC,LINERES
TABINC,TABLD
LDFLAGS,LDVT,LDLVL
WRSRAM
"*** Aliases
H, L, C, X = 1, 0,
.C.,
.X.;
[TABINC, TABLD];
[LINEINC, LINERES];
TabOp =
LineOp =
INC =
=
LOAD
IGNORE =
[
[
[
1,
0,
1,
0
1
1
];
];
];
"*** State declarations
@include 'scm.sta'
"*** Equations
equations
[DRDATA,DRADDR,LDFLAGS,LDVT,LDLVL,WRSRAM].clk
InState(WriteDatal)
InState(WriteData2)
InState(WriteData3);
!DRADDR
:=
!DRDATA
:= In_State(LoadTables)
#
#
#
#
In_State(LoadFlags)
In_State(LoadLvl)
InState(WriteDatal)
InState(WriteData2)
= FClk;
APPENDIX B. VC SCHEMATICS AND PAL FILES
164
scml.abl
# InState(WriteData3);
LineOp = (InState(UpdateTab)
#
#
#
#
#
#
#
TabOp = ((InState(UpdateTab)
#
#
#
#
#
#
& LOAD)
((InState(UpdateLine)& LVL) & LOAD)
((InState(UpdateLine)& !LVL) & INC)
(InState(WriteDataO)& IGNORE)
(InState(WriteDatal)& IGNORE)
(InState(WriteData2)& IGNORE)
(InState(WriteData3)& IGNORE)
(InState(WriteData4)& IGNORE);
& LVT) & LOAD)
((InState(UpdateTab)&
(InState(WriteDataO)&
(InState(WriteDatal)&
(InState(WriteData2)&
(InState(WriteData3)&
(InState(WriteData4)&
!LVT) & INC)
IGNORE)
IGNORE)
IGNORE)
IGNORE)
IGNORE);
LDFLAGS := In_State(LoadFlags);
LDVT
:= In_State(LoadTables);
LDLVL
:= In_State(LoadLvl);
!WRSRAM := InState(WriteData2);
end Scml
APPENDIX B. VC SCHEMATICS AND PAL FILES
165
scm. sta
"*** State declarations
"These pairs require one-bit state bit differences:
"
Idle->NewData0
NewData0 -> NewDatal
LoopTilEnd -> Dispatch
"
SendErm2, SendErm3 (from SendErml)
"
SendErm3 -> SendErm4
Idle
NewData0
NewDatal
LoopTilEnd
Dispatch
= [
0,0, 0,
= [ 0, 01 0
= [0, 0, 0,
= [0,
= [0,
0,
0,
0, 0 ];
"00-0
(00)
(08)
1, 0,
1, 1,
0, 0 1; "02-0
0, 0 ]; "03-0
0, 0,
0, 0,
0,
0,
1,
1,
0, 0 ; "01-0
0, 1 ]; "01-1
(04)
(05)
(0c)
WriteData0a = [0,
WriteData0b = [0,
0,
0,
1,
1,
0,
0,
0,
0,
0,
0,
0 ]; "04-0
1 ; "04-1
(10)
(11)
WriteData0c
=
0, 1,
0,
0,
1,
1 ];
(13)
WriteDatala
WriteDatalb
WriteDatalc
= [ 0, 1, 1, 0, 0,
= [ 0, 1, 1, 0, 0,
= [ 0,-1, 1, 0, 0,
0, 0 ]; "06-0
0, 1 ]; "06-1
1, 1 ]; "06-3
(30)
(31)
(32)
WriteData2a
WriteData2b
WriteData2c
0
=
= [ 0,
= [ 0,
0,
(20)
ReadData0a
ReadData0b
ReadData0c
ReadData0d
= [ 1
ReadDatala
ReadDatalb
ReadDatalc
ReadDatald
=
=
=
=
[
[
[
[
ReadData2a
ReadData2b
ReadData2c
ReadData2d
SendToErm0
SendToErml
SendToErm2
SendToErm3
SendToErm4
[0,
= [ 1,
= [ 1,
1,
1,
1,
0,
0,
0,
0
0
0
0,
0,
0,
0 , 0,
,
0
0,
;
];
1, 1
0,
"04-3
"08-0
08-1 (21)
; "08-3
(23)
]; "10-0
(40)
(45)
(41)
(43)
0,
0,
0,
0,
0,
0,
= [ 1, 0,
0,
0, 0,
0,
0,
0,
0,
1,
1,
1,
1,
0,
1,
0,
0,
0,
0,
0,
1,
1
1
1
1
]; "12-0
];
13-1
];
12-1
]; "12-3
(48)
(4d)
(49)
(4b)
=
=
=
=
[ 1, 0, 1, 1,
[
0 1, 1 ,
[ 1, 0, 1, 1,
[ 1, 0, 1, 1,
0,
1
0,
0,
0,
0
0,
1,
0
1
1
1
];
];
];
];
"16-0
"17-1
"16-1
"16-3
(58)
(5d)
(59)
(5b)
=
[ 1, 1, 0,
0,
0,
0,
0 ]; "18-0
0,
1,
0,
0 ];
(60)
(64)
(6b)
(7b)
(7d)
1, 0,
1 0,
10,
1, 0,
= [ 1,
1,
0,
1,
0,
= [ 1, 1, 0, 1, 1,
= [ 1, 1, 1, 1, 1,
= [ 1, 1, 1, 1, 1,
0, 1 ];
0, 1 ];
11-1
"10-1
1, 1 ]; "10-3
"19-0
0, 0 ]; "lb-0
0,0
]; "lf-0
0, 1 ]; "lf-1
166
APPENDIX B. VC SCHEMATICS AND PAL FILES
APPENDIX B. VC SCHEMATICS AND PAL FILES
167
scmct10.abl
module ScmCtlO
title 'SCCtrl FSM PAL#0
Eric McDonald
Last revised:
January
5, 1994
February
15, 1994'
"DESCRIPTION:
ScmCtlO device 'P26V12';
"*** Inputs
Clk
HBlk,VBlk
Reload
RamCE
Go
DRCTRS
GReset
Pin
Pin
Pin
Pin
Pin
Pin
Pin
1;
2, 3;
4;
5;
6;
8;
28;
Pin
Pin
Pin
Pin
27 istype 'reg,buffer'; " ACK for Reload request
26 istype 'reg,buffer'; " ACK for RamCE request
25,24,23,22,20 istype 'reg,buffer'; " RAM address
19,18,17,16,15 istype 'reg,buffer'; " State bits
"Horiz and Vert blanking
"Scm request to Reload
"Scm request to enable /DRCTRS
"Sync'd Go signal
" Drive ADDR bits only when !DRCTRS
"Reset signal
"*** Outputs
ReloadAck
RamCEAck
AO,A,A2,A3,A4
Q0,Q1,Q2,Q3,Q4
"*** Aliases
H, L, C, X = 1, 0,
C.,
X.;
"*** State declarations
@include 'scmctl.sta'
"*** RAM Addresses
[A3,A2,A1,A0];
Addr =
Setup_NOl0_N00
Setup_N03_N02
Setup_N05_N04
Setup_N07_N06
Setup_N09_N08
=
=
=
=
=
Setup_NllN10
=
[
[
[
[
[
0, 0,
0, 0,
0, 0
0,0,
0, 1,
[ 0, 1,
[ 0, 1
0,
0,
1
1,
0,
0,
1,
0 ];
1 ];
0];
1 ];
0 ];
1];
0 ];
Setup_N13_N12 =
Setup_N15_N14
DFB8_Flag
= [ 1, 0, 0, 0 ];
"*** Equations
equations
[current_state,ReloadAck,RamCEAck,Addr].clk
= Clk;
[current_state,ReloadAck,RamCEAck].ar = GReset;
A4 = 0;
Addr.oe = !DRCTRS & !RamCEAck;
APPENDIX B. VC SCHEMATICS AND PAL FILES
168
scmctlO .abl
State_Diagram current_state
NOTE: Reload, RamCE, and Go are guaranteed (by ScmO) not to go high
close to each other. In addition, none of them will occur close
to VBlk or HBlk going high.
If we're not in Go condition, loop in Idle looking
for Reload and RamCE requests or a Go condition
"
state Idle:
op = ((GReset == 1) & CLEAR_REG);
if (Reload) then RelO;
else if (RamCE) then CEO;
else if (Go) then AwaitVBlanking;
else Idle;
state CEO:
!DRCTRS : 1;
RamCEAck
:= 1;
if (RamCE) then CEO;
else CE1;
state CE1:
goto HBlankingO;
If we actually came here from Idle, we'll
get back to Idle after a hop through
HBlankingO and HBlankingl
When we first see a Go condition, we wait until Eof before doing
anything
state AwaitVBlanking:
if
(VBlk) then AwaitVBlanking;
else HBlankingO;
We wait here during HBlanking periods, servicing any Reload or RamCE
requests while we wait for the next Active period
state HBlankingO:
if (!Go # Reload # RamCE) then HBlankingl;
else if (HBlk & VBlk) then ActiveO;
else HBlankingO;
ONLY enter this state if we know Go, Reload or RamCE is true
state HBlankingl:
if
(Reload) then RelO;
else if (RamCE) then CEO;
else Idle;
state ActiveO:
Op = GO_INITSTATE;
goto Activel;
state Activel:
Op = NEXT;
if (!HBlk)
then HBlankingO;
else Activel;
state RelO:
!DRCTRS
" Enable /DRCTRS
:= 1;
goto RelOa;
"Copy RAM [0] -> SCRegO
state RelOa:
Addr = Setup_NOlNOO;
[DRCTRS
:= 1;
APPENDIX B. VC SCHEMATICS AND PAL FILES
scmctlO. abl
SelO = 1;
Op = LOAD_SETUP;
goto RelOb;
state RelOb:
Copy RAM [1] -> SCRegO
Addr = SetupN03_N02;
11
1.
!DRCTRS := 1;
SelO = 1;
Op = LOAD_SETUP;
goto Rella;
state Rella:
Copy RAM [2] -> SCRegl
Addr = SetupNO5_NO4;
.1
11
11
!DRCTRS := 1;
Sell = 1;
Op = LOAD_SETUP;
goto Rellb;
Copy RAM [3] -> SCRegl
state Rellb:
Addr = Setup_N07_N06;
11
!DRCTRS := 1;
Sell = 1;
Op = LOAD_SETUP;
goto Rel2a;
state Rel2a:
Copy RAM [4] -> SCReg2
Addr = Setup_N09_N08;
11
!DRCTRS := 1;
Se12 = 1;
Op = LOAD_SETUP;
goto Rel2b;
state Rel2b:
Copy RAM [5] -> SCReg2
Addr = Setup_NlN10;
!DRCTRS := 1;
Se12 = 1;
Op = LOAD_SETUP;
goto Rel3a;
state Rel3a:
Copy RAM [6] -> SCReg3
Addr = Setup_N13_N12;
11
!DRCTRS := 1;
Sel3 = 1;
Op = LOAD_SETUP;
goto Rel3b;
state Rel3b:
Copy RAM [7] -> SCReg3
Addr = Setup_N15_N14;
11
!DRCTRS := 1;
Se13 = 1;
Op = LOAD_SETUP;
goto Rel4;
Copy RAM [8] -> SCReg[0:3]
state Rel4:
Addr = DFB8_Flag;
11
SelO = 1;
Sell = 1; Se12
Op = LOAD_DFB8;
= 1; Sel3 = 1;
goto Re15 with ReloadAck := 1; endwith;
state Rel5:
:= 1;
ReloadAck
if (Reload) then Rel5;
else HBlankingO;
end ScmCtlO
169
APPENDIX B. VC SCHEMATICS AND PAL FILES
170
scmtll.abl
module ScmCtll
title 'SCCtrl FSM PAL#1
Eric McDonald
Last revised:
January
5, 1994
February 15, 1994'
"DESCRIPTION:
ScmCtll device 'P22V10';
"*** Inputs
Clk
Q0,Q1,Q2,Q3,Q4
HBlk,VBlk
ASyncGo
GReset
Pin 1;
Pin 2,3,4,5,6;
Pin 7, 8;
Pin 9;
Pin 13;
"State bits
"Horiz and Vert blanking
"Asynchronous Go signal
"Reset signal
"*** Outputs
Op0,Opl,Op2
Pin
Pin
Pin
Pin
SeSell,Sel12,Se13
DRCTRS
Go
23,22,21;
"Op command
20,19,18,17; "Select SCBlock control lines
16 istype 'reg,invert';
14 istype 'reg,buffer';
"*** Aliases
H, L, C, X = 1, 0, .C., .X.;
In_State MACRO (st) { (currentstate
== ?st)
};
"*** State declarations
@include 'scmctl.sta'
"***Op command definitions (consistent with scmreg.abl and scmdrv.abl)
@include 'scmctl.ops'
"*** Equations
equations
[DRCTRS,Go].clk
= Clk;
Go.ar
= GReset;
Go := ASyncGo;
Op = (InState(Idle)
& (GReset == 1) & CLEAR_REG)
# (InState(Active0)
& GOINITSTATE)
# (InState(Activel)& NEXT)
# (InState(RelOa) & LOAD_SETUP)# (InState(RelOb) & LOAD_SETUP)
# (InState(Rella)
& LOAD_SETUP)
# (InState(Rellb)
& LOADSETUP)
# (InState(Rel2a) & LOAD_SETUP) (InState(Rel2b) & LOADSETUP)
# (InState(Rel3a) & LOAD_SETUP)# (InState(Rel3b) & LOAD_SETUP)
# (InState(Rel4) & LOAD_DFB8);
APPENDIX B. VC SCHEMATICS AND PAL FILES
scmctll. abl
SelO = (InState(RelOa))
# In_State(Rel4);
# (InState(RelOb))
Sell = (InState(Rella))
# (InState(Rellb))
# InState(Rel4);
Sel2
= (InState(Rel2a))
# (InState(Rel2b))
# In_State(Rel4);
Sel3 = (InState(Rel3a))
# (In State(Rel3b))
# InState(Rel4);
!DRCTRS := InState(CEO)
# InState(RelO)
# InState(RelO1 a) #
# InState(Rellzi) #
# InState(Rel2ea) #
# InState(Rel3za) #
end ScmCtll
InState(RelOb)
InState(Rellb)
InState(Rel2b)
InState(Rel3b);
171
172
APPENDIX B. VC SCHEMATICS AND PAL FILES
samctl. ata
"*** State declarations
States transitions that demand single-bit changes only:
Idle -> AwaitVBlanking, CEO, RelO
CEO -> CE1
AwaitVBlanking.-> HBlankingO
HBlankingO -> ActiveO, HBlankingl
Activel
-> HBlanking0;
current_state
Idle =
AwaitVBlanking
CEO
CE1
=
=
HBlanking
HBlankingl
Active
Activel
RelO =
RelOa =
RelOb =
Rella =
Rellb =
Rel2a =
Rel2b =
Rel3a =
Rel3b =
Rel4 =
Re15 =
=
=
=
=
= [Q4,Q3,Q2,Q1,QO];
0, 0, 0, 0, 0 ];
"00
=[ 0, 0, 0, 1, 0 ];
"02
[0, 0, 1, 0, 0 ];
[
0,0, 1, 0, 1 ];
"04
"05
0, 0,0, 1, 1 ];
0,
0, 0, 1 1];
"03
"01
[0, 0, 1, 1, 1 ];
[ 0, 1, 0, 1, 1 ];
"07
"Ob
[
[
[
[
[
[
[
[
[
[
[
[
[
1, 0,
1, 1,
1, 1,
1, 1,
1, 1,
1., 1,
1, 1,
1, 1,
1, 1,
1, 0,
1, 0,
0,
0,
0,
0,
0,
1,
1,
1,
1,
0,
0,
0,
0,
0,
1,
1,
0,
0,
1,
1,
0,
1,
0
0
1
0
1
0
1
0
1
1
0
];
];
];
];
];
];
];
];
];
];
];
"10
"18
"19
"la
"lb
"lc
"ld
"le
"if
"11
"12
173
APPENDIX B. VC SCHEMATICS AND PAL FILES
It.
A
A
I
Ii
jb hiT
6
Irl.
APPENDIX B. VC SCHEMATICS AND PAL FILES
174
scmreg. abl
module ScmReg
title 'ScmReg PAL
Eric McDonald
Last revised:
January
February
5, 1994
15, 1994'
DESCRIPTION:
ScmReg device 'P26CV12';
"*** Inputs
Clk
Data0, Datal,Data2,Data3
Op0,Opl,Op2
Pin 1;
Sel
Pin 10;
Pin 2,3,4,5;
Pin 6,8,9;
"*** Outputs
DFB8
OddO,Act0O,Oddl,Actl,
Odd2,Act2,Odd3,Act3
"Select
line
Pin 27 istype 'reg,buffer';
Pin 23,22,20,19,18,17,16,15 istype 'reg,buffer';
"*** For internal use
do_loadsetup
do_load_dfb8
Pin 26;
Pin 25;
clearreg
Pin 24 istype 'reg,buffer';
"*** Aliases
H, L, C, X = 1, 0, .C.,
.X.;
"*** Op command definitions
(include 'scmctl.ops'
"*** Equations
equations
[OddO..Odd3,ActO..Act3,DFB8,clear_reg].clk
= Clk;
[OddO..Odd3,ActO..Act3,DFB8].ar = clear_reg;
do_loadsetup
do_load_dfb8
clearreg
= Sel &
= Sel &
:=
(Op == LOAD_SETUP);
(Op == LOAD_DFB8);
(Op == CLEARREG);
OddO := (do_loadsetup
ActO := (do_loadsetup
Oddl := (do_loadsetup
Actl := (do_loadsetup
&
&
&
&
DataO)
Datal)
Data2)
Data3)
Odd2 := (do_loadsetup
Act2 := (do_loadsetup
Odd3 := (do_loadsetup
Act3 := (do_load_setup
&
&
&
&
OddO)
ActO)
Oddl)
Actl)
#
#
#
#
#
#
#
#
(!do_load_setup
(!do_load_setup
(!do_load_setup
(!do_load_setup
&
&
&
&
(!do_loadsetup &
(!do_loadsetup &
(!do_loadsetup &
(!do_loadsetup &
OddO);
ActO);
Oddl);
Actl);
Odd2);
Act2);
Odd3);
Act3);
APPENDIX B. VC SCHEMATICS AND PAL FILES
scmreg.abl
DFB8 := (do_load_dfb8 & DataO) # (!do_load_dfb8 & DFB8);
end ScmReg
175
176
APPENDIX B. VC SCHEMATICS AND PAL FILES
scmdrv.abl
module ScmDrv
title 'ScmDrv PAL
Eric McDonald
Last revised:
January
5, 1994
February 15, 1994'
DESCRIPTION:
ScmDrv device 'P26CV12';
"*** Inputs
Clk
OddO,ActO,Oddl,Actl,
Odd2,Act2,Odd3,Act3
Pin 1;
Pin 2,3,4,5,11,12,13,14;
OpO, Opl, Op2
Pin 6,8,9;
Sel
DFB8
Pin 10;
Pin 28;
Select line
8DFB flag
"*** Outputs
SCaO,SCbO,SCal,SCbl,SCa2,SCb2,SCa3,SCb3 Pin 23,22,20,19,18,17,16,15
istype 'reg,buffer';
SClk signals
SCqO,SCql,SCq2,SCq3
Pin 27,26,25,24 istype 'reg,invert';
"*** Aliases
H, L, C, X = 1, 0,
.C., .X.;
"*** Op command definitions
@include 'scmctl.ops'
SClk
SClkl
SClk2
SClk3
= [SCqO,SCbO,SCaO];
= [SCql,SCbl,SCal];
= SCq2,SCb2,SCa2];
= [SCq3,SCb3,SCa3];
"*** State declarations
EnabA
IdleO
EnabB
Idlel
Trap4
Trap5
Trap6
Trap7
=
=
=
=
=
=
=
=
[0,
[ 0,
[ 0,
[ 1,
[ 0,
[ 1,
[ 1,
[ 1,
0,
0,
1,
0,
1,
0,
1,
1,
1
0
0
0
1
1
0
1
];
];
];
];
];
];
];
];
do_state_diag macro (SVar,Act,Odd) {
state_diagram ?SVar
state EnabA:
if
(?Act & (Op == NEXT))
case !DFB8 : EnabB;
DFB8 : IdleO;
then
endcase;
else if (?Act & (Op == GO_INIT_STATE)) then
APPENDIX B. VC SCHEMATICS AND PAL FILES
scmdrv.abl
case
(!DFB8) : EnabA;
(DFB8 & !?Odd) : EnabA;
(DFB8 & ?Odd) : IdleO;
endcase;
else IdleO;
state IdleO:
if
(?Act &
(Op == NEXT))
then
case !DFB8 : EnabA;
Should never reach here
DFB8 : EnabB;
endcase;
else if (?Act & (Op == GO_INITSTATE)) then
case
(!DFB8) : EnabA;
(DFB8 & !?Odd) : EnabA;
(DFB8 & ?Odd) : IdleO;
endcase;
else IdleO;
state EnabB:
if
(?Act & (Op == NEXT))
case !DFB8 : EnabA;
DFB8 : Idlel;
then
endcase;
else if (?Act & (Op == GO_INIT_STATE)) then
case
(!DFB8) : EnabA;
(DFB8 & !?Odd) : EnabA;
(DFB8 & ?Odd) : Idle0;
endcase;
else IdleO;
state Idlel:
if
(?Act & (Op == NEXT))
then
case !DFB8 : EnabA;
"Should never reach here
DFB8 : EnabA;
endcase;
else if (?Act & (Op == GO_INIT_STATE)) then
case
state
state
state
state
else
Trap4:
goto
Trap5:
goto
Trap6:
goto
Trap7:
goto
(!DFB8) : EnabA;
(DFB8 & !?Odd) : EnabA;
(DFB8 & ?Odd) : IdleO;
endcase;
IdleO;
Idle0;
IdleO;
IdleO;
IdleO;
}
"*** Equations
equations
[SClkO,SClkl,SClk2,SClk3].clk
= Clk;
do_state_diag(SClkO,ActO,OddO);
do_state_diag(SClkl,Actl,Oddl);
177
178
APPENDIX B. VC SCHEMATICS AND PAL FILES
scmdrv.abl
do_state_diag(SClk2,Act2,Odd2);
do_statediag(SClk3,Act3,Odd3);
end ScmDrv
APPENDIX B. VC SCHEMATICS AND PAL FILES
179
APPENDIX B. VC SCHEMATICS AND PAL FILES
180
--
-
J
I
I
li
II
B
a
I
_
-
Ii'
'4
9 2.6
i
_
m7
I
III
I
l
g.6 LII I
I i
i,
j
II
IF -- fl
-1
I1- I
iI
pf
I-
J
ul
n-
1
!
II
I
_
I
.
.
.
11
.
-
- -
I
I
m
_-
- -
]
/
I
1
I
I,
i
I
3
I
',:!L
aAM11
Ii I I Im I I mI I I I
.
,%-Y'
I1
.
III
1I
r
W11111,
-
I' FF1s§ss9 I I
:
I
.
I
i
I!
I
VLNYXSX
NMy
.."A~bAAAb
WI
'r'V
"I II
'
.
.
.
.
I
.
.
, id
I I I
.
.
.
.
I.
I
I
D.
A
A;I
I
E
U)
It-I
I
I
T T T T
iI- -
11
-----
h- %'L 'LI
.I
J
TTT
-
I
I
TTT
TT
E~~
9A
-r
1A
i A
I h!
A A
-I- -I-
I
IAi
Ui
e
I
i! 1
II
n
·
I
Ak
{'
-
'J
I
A
'I' 1'
APPENDIX B. VC SCHEMATICS AND PAL FILES
181
timotrO.abl
module TimCtrO
title 'TIM module HCtrO/VCtrO counter FSM
Eric McDonald
Last revised:
January
5, 1994
February
15, 1994'
"DESCRIPTION:
"This PAL compares an 8-bit input value with an internal down counter.
" Asserts CO when counter == 0 and CI == 0,
" asserts Zero when counter == 0 regardless of CI.
"The counter can be decremented with Dec or loaded with Load.
TimCtr0 device 'P22V10';
"*** Inputs
Clock
Dec
Load
@Ifdef HIGH_ORDER
Pin 1;
Pin 2;
Pin 3;
{CI
Pin 4;
" Decrement counter
"Load counter with D inputs
Carry bit input}
@Ifndef HIGH_ORDER
"No
{CI = 1;
carry bit input on low order ctr}
D0,D1,D2,D3,D4,D5,D6,D7 Pin 5,6,7,8,9,10,11,13; " Data inputs
"*** Outputs
Q0,Q1,Q2,Q3,Q4,Q5,Q6,Q7 Pin 22,15,21,16,20,17,19,18 istype 'reg,buffer';
Pin 23 istype 'reg,buffer';
CO
Zero
Pin 14;
"*** Equations
HOLD
=
DEC
=
!Dec &
Dec & !Load;
Load;
LOAD
=
Load;
equations
[CO,Q7..Q0].clk = Clock;
!Q0 := (HOLD & !Q0)
# (LOAD & !DO)
# (DEC & !CI & !Q0)
# (DEC & CI & QO);
!Q1 := (HOLD & !Q1)
# (LOAD & !D1)
# (DEC & !CI & !Q1)
# (DEC &
# (DEC &
Q0 & !Q1)
CI & !Q & Q1);
!Q2 := (HOLD & !Q2)
APPENDIX B. VC SCHEMATICS AND PAL FILES
182
timctrO .abl
# (LOAD & !D2)
# (DEC & !CI & !Q2)
#
(DEC
& Q & !Q2)
Q & !Q2)
CI & !Q0 & !Q1 & Q2);
# (DEC &
# (DEC &
!Q3 := (HOLD & !Q3)
# (LOAD & !D3)
#
#
#
#
#
!Q4
(DEC
(DEC
(DEC
(DEC
(DEC
!CI & !Q3)
Q & !Q3)
Q1 & !Q3)
Q2 & !Q3)
CI & !Q0 & !Q1 &
Q2 & Q3);
:= (HOLD & !Q4)
#(LOAD
# (DEC
#(DEC
#(DEC
#(DEC
#(DEC
# (DEC
!Q5
&
&
&
&
&
& !D4)
& !CI & Q4)
& Q0 & !Q4)
& Q1 & !Q4)
& Q2 & Q4)
& Q3 & IQ4)
& CI & !Q0 & !Q1 & !Q2 & !Q3 & Q4);
:= (HOLD &
!Q5)
# (LOAD & !D5)
# (DEC
#(DEC
# (DEC
#(DEC
#(DEC
# (DEC
# (DEC
!Q6
& !CI & !Q5)
& Q0 & !Q5)
& Q1 & !Q5)
& Q2 & !Q5)
& Q3 & !Q5)
& Q4 & !Q5)
& CI & !Q0 & !Q1 & !Q2 & !Q3 & !Q4 & Q5);
:= (HOLD & !Q6)
# (LOAD & !D6)
# (DEC
#(DEC
# (DEC
#(DEC
#(DEC
#(DEC
# (DEC
# (DEC
& !CI & !Q6)
& Q0 & !Q6)
& Q1 & !Q6)
& Q2 & !Q6)
& Q3 & !Q6)
& Q4 & !Q6)
& Q5 & !Q6)
& CI & !Q0 &
!Q
&
!Q2 & !Q3 & !Q4 &
Q5 & Q6);
!Q7 := (HOLD & !Q7)
# (LOAD & !D7)
CO
#
#
#
#
#
#
#
#
#
(DEC
(DEC
(DEC
(DEC
(DEC
(DEC
(DEC
(DEC
(DEC
:=
CI &
& !CI & !Q7)
& Q0 & !Q7)
& Q1 & !Q7)
& Q2 & !Q7)
& Q3 & !Q7)
& Q4 & !Q7)
& Q5 & *Q7)
& Q6 & *Q7)
& CI & !Q0 & !Q1 & !Q2 & !Q3 & !Q4 & !Q5 & !Q6 & Q7);
Q0 &
Q1 &
Q2 & !Q3 &
Q4 & !Q5 &
!Q6 &
Q7;
APPENDIX B. VC SCHEMATICS AND PAL FILES
timctrO.abl
Zero =
end TimCtrO
!QO & !Q1 & !Q2 & !Q3 & !Q4 & !Q5 & !Q6 & !Q7;
183
APPENDIX B. VC SCHEMATICS AND PAL FILES
184
timctrl.abl
module TimCtrl
@const HIGH_ORDER
= 1;
title 'TIM module HCtrl/VCtrl counter FSM
Eric McDonald
Last revised:
January
February
5, 1994
15, 1994'
DESCRIPTION:
------------
This PAL compares an 8-bit input value with an internal down counter.
Asserts CO when counter == 0 and CI == 0,
asserts Zero when counter == 0 regardless of CI.
"The counter can be decremented with Dec or loaded with Load.
TimCtrl device 'P22V10';
*** Inputs
Clock
Dec
Load
@Ifdef HIGH_ORDER
Pin 1;
Pin 2;
Pin 3;
" Decrement counter
"Load counter with D inputs
{CI
Pin 4;
"Carry bit input}
cIfndef HIGH_ORDER
"No carry bit input on low order ctr}
{CI = 1;
D0,D1,D2,D3,D4,D5,D6,D7 Pin 5,6,7,8,9,10,11,13; "Data
"***
inputs
Outputs
Q0,Q1,Q2,Q3,Q4,Q5,Q6,Q7 Pin 22,15,21,16,20,17,19,18 istype 'reg,buffer';
Pin 23 istype reg,buffer';
CO
Pin 14;
Zero
"*** Equations
HOLD
= !Dec & !Load;
DEC
=
Dec & !Load;
LOAD
=
Load;
equations
[CO,Q7..Q0].clk = Clock;
!Q0 := (HOLD & !Q0)
# (LOAD & !D0)
# (DEC & !CI &
# (DEC & CI &
!Q1 := (HOLD &
!Q))
Q0);
!Q1)
# (LOAD & !D1)
# (DEC & !CI & !Q1)
# (DEC & Q & !Q1)
# (DEC & CI & !Q0 & Q);
APPENDIX B. VC SCHEMATICS AND PAL FILES
185
timctrl. abl
!Q2 := (HOLD & !Q2)
# (LOAD & !D2)
!Q3
# (DEC
# (DEC
# (DEC
& !CI &
& Q &
& Q &
# (DEC
&
:= (HOLD
!Q2)
!Q2)
!Q2)
CI & !Q
& !Q1 & Q2);
& !Q3)
# (LOAD & !D3)
# (DEC & !CI & !Q3)
# (DEC & Q0 & !Q3)
# (DEC & Q1 & !Q3)
# (DEC & Q2 & !Q3)
# (DEC & CI & !Q0 & !Q1 & !Q2 & Q3);
!Q4
:= (HOLD & !Q4)
# (LOAD & !D4)
# (DEC & !CI &
# (DEC & Q0 &
# (DEC & Q1 &
# (DEC & Q2 &
# (DEC
# (DEC
&
&
!Q4)
!Q4)
!Q4)
!Q4)
Q3 & !Q4)
CI & !Q0 &
!Q5 := (HOLD & !Q5)
# (LOAD & !D5)
# (DEC & !CI &
# (DEC & Q0 &
# (DEC & Q1 &
# (DEC & Q2 &
# (DEC & Q3 &
# (DEC & Q4 &
# (DEC & CI &
!Q6 := (HOLD & !Q6)
# (LOAD & !D6)
# (DEC & !CI &
# (DEC & Q0 &
# (DEC & Q1 &
# (DEC & Q2 &
# (DEC & Q3 &
# (DEC & Q4 &
# (DEC & Q5 &
# (DEC & CI &
!Q1 &
!Q2 & !Q3 & Q4);
!Q5)
!Q5)
!Q5)
!Q5)
!Q5)
!Q5)
!Q & !Q1 &
!Q2 & !Q3 & !Q4 & Q5);
!Q6)
!Q6)
!Q6)
!Q6)
!Q6)
!Q6)
!Q6)
!Q0 &
Q1 &
!Q2 & !Q3 & !Q4 &
!Q5 & Q6);
!Q7 := (HOLD & !Q7)
# (LOAD & !D7)
# (DEC & !CI & !Q7)
# (DEC & Q0 & !Q7)
# (DEC & Q1 & !Q7)
# (DEC
#
#
#
#
#
(DEC
(DEC
(DEC
(DEC
(DEC
&
&
&
&
&
&
Q2 & !Q7)
Q3 & !Q7)
Q4 & !Q7)
Q5 & !Q7)
Q6 & !Q7)
CI & !Q0 & !Q1 & !Q2 & !Q3 &
Q4 &
Q5 & !Q6 & Q7);
186
APPENDIX B. VC SCHEMATICS AND PAL FILES
timctrl.abl
CO
:=
Zero =
CI &
end TimCtrl
!QO &
Q1 &
!QO & !Q1 &
!Q2 & !Q3 &
!Q2 & !Q3 &
!Q4 & !Q5 &
!Q4 & !Q5 &
!Q6 & !Q7;
!Q6 & !Q7;
187
APPENDIX B. VC SCHEMATICS AND PAL FILES
A
I;
1.
11
k
jII
-1t
APPENDIX B. VC SCHEMATICS AND PAL FILES
188
tim40.abl
module Tim40
title 'TIM Module FSM #0
Eric McDonald
Last revised:
January
5, 1994
June 6, 1994'
" DESCRIPTION:
Tim40 device 'P22V10';
"*** Inputs
FClk
HZero
VZero
RESET
Pin
Pin
Pin
Pin
1;
3;
5;
13;
from Bt440
"LdClk
"HCtr
"VCtr
is 0
is 0
"Global
/RESET line
"*** Outputs
Pin 23 istype reg,buffer';
BLANK
Pin 22 istype 'reg,buffer';
SYNC
Pin 21,20 istype 'reg,buffer';
HBLK,VBLK
All of the above outputs are inverted outside of this PAL, so we
are writing for the complements
Pin 19 istype 'reg,invert';
CSYNC4
Pin 18,17,16,15,14 istype 'reg,buffer'; "State
Q0,Q1,Q2,Q3,Q4
"*** State declarations
$include 'tim4.sta'
"*** Aliases
H, L, C, X = 1, 0,
.C., .X.;
"*** Equations
equations
current_state.clk
current_state.ar
SYNC
= FClk;
= !RESET;
:= L;
StateDiagram current_state
state Init:
~"
~ PAddr := HLinesInVFP;
goto VertFrontPorch0;
with VLoad = H;
HLinesInVFP -> VCtr
state HorizActive:
PAddr := HFrontPorch;
HDec
= H;
if (HZero) then HorizFrontPorch;
HFrontPorch -> HCtr
with HLoad = H;
VDec
= H;
APPENDIX B. VC SCHEMATICS AND PAL FILES
189
t im40o.abl
else HorizActive;
state HorizFrontPorch:
BLANK := H;
HDec = H;
HBLK
:= H;
PAddr := HSync;
if (HZero) then HorizSync;
with
HLoad
HSync -> HCtr
= H;
else HorizFrontPorch;
state HorizSync:
BLANK := H; HBLK
HDec = H;
if (HZero) then
.1
:= H;
!CSYNC4
:= H;
if (VZero) then VertFrontPorchO;
with VLoad = H;
HLinesInVFP -> VCtr
PAddr := HActiveInVBlk;
else HorizBackPorch;
with HLoad = H;
HBackPorch -> HCtr
else HorizSync;
with PAddr := (VZero & HLinesInVFP) # (!VZero & HBackPorch);
state HorizBackPorch:
BLANK := H;
HDec = H;
HBLK
:= H;
PAddr := HActive;
if (HZero) then HorizActive;
with HLoad
= H;
HActive -> HCtr
else HorizBackPorch;
state VertFrontPorchO:
[wait state for registered PROM with registered addr inputs]
BLANK
:= H;
VBLK
:= H;
goto VertFrontPorchl;
state VertFrontPorchl:
BLANK
:= H;
VBLK
:= H;
goto VertFrontPorch2;
with HLoad = H;
state VertFrontPorch2:
BLANK := H;
HDec = H;
.1
VBLK
HActiveInVBlk -> HCtr
:= H;
PAddr := HSync;
if (HZero) then HorizSyncInVFP;
with
HLoad = H;
VDec = H;
HSync -> HCtr
else VertFrontPorch2;
state HorizSynclnVFP:
BLANK := H; !CSYNC4
HDec = H;
if (HZero) then
:= H; HBLK
:= H; VBLK
:= H;
if (VZero) then VertSyncO;
with HLoad = H;
HActiveInVBlk -> HCtr
PAddr := HLinesInVS;
else VertFrontPorch2;
with HLoad = H;
HActiveInVBlk -> HCtr
APPENDIX B. VC SCHEMATICS AND PAL FILES
190
tim4O .abl
else HorizSyncInVFP;
with PAddr := HActiveInVBlk;
state VertSyncO:
[wait state for registered PROM with registered addr inputs]
BLANK
!CSYNC4
:= H;
:= H; VBLK
:= H;
:= H; VBLK
:= H;
goto VertSyncl;
state VertSyncl:
BLANK
:= H;
!CSYNC4
goto VertSync2;
with VLoad
HLinesInVS -> VCtr
= H;
state VertSync2:
11
BLANK := H;
CSYNC4 := H; VBLK
PAddr := HSync;
HDec = H;
if (HZero) then HorizSyncInVS;
with HLoad = H;
VDec = H;
:= H;
HSync -> HCtr
else VertSync2;
state HorizSyncInVS:
HBLK := H;
BLANK := H; VBLK := H;
HDec = H;
if (HZero) then
if (VZero) then VertBackPorchO;
with VLoad = H;
PAddr
HLinesInVBP -> VCtr
:= HSync;
else VertSync2;
HActiveInVBlk -> HCtr
with HLoad = H;
else HorizSyncInVS;
with PAddr:=(VZero & HLinesInVBP) # (!VZero & HActiveInVBlk);
state VertBackPorchO:
[wait state for registered PROM with registered addr inputs]
BLANK
:= H;
:= H;
VBLK
goto VertBackPorchl;
state VertBackPorchl:
BLANK
:= H;
VBLK
:= H;
goto HorizSyncInVBPO;
with HLoad = H;
HSync -> HCtr
state VertBackPorch2:
BLANK
1.
:= H; VBLK
:= H;
PAddr := HSync;
HDec = H;
if (HZero)
then HorizSyncInVBPO;
with HLoad = H;
VDec
HSync -> HCtr
= H;
else VertBackPorch2;
state HorizSyncInVBPO:
BLANK := H;
!CSYNC4 := H; VBLK := H; HBLK
HDec = H;
if (HZero) then
if (VZero) then HorizSyncInVBPl;
.,
:= H;
HLinesActive -> VCtr
with VLoad = H;
PAddr := HBPaVBP;
APPENDIX B. VC SCHEMATICS AND PAL FILES
191
tim4 0. abl
else VertBackPorch2;
with HLoad = H;
HActiveInVBlk -> HCtr
else HorizSyncInVBP0;
with PAddr:=(VZero & HLinesActive)#(!VZero & HActiveInVBlk);
state HorizSyncInVBPl:
[wait state for registered PROM with registered addr inputs]
BLANK
:= H;
!CSYNC4
:= H; VBLK
:= H; HBLK
:= H;
:= H; VBLK
:= H; HBLK
:= H;
goto HorizSyncInVBP2;
state HorizSyncInVBP2:
BLANK
:= H;
!CSYNC4
goto HBPAfterVBP;
with HLoad
= H;
HB3PaVBP -> HCtr
state HBPAfterVBP:
BLANK := H;
HDec = H;
VBLK
:= H; HBLK
:= H;
PAddr := HActive;
if (HZero) then HorizActive;
with
HLoad
else HBPAfterVBP;
end Tim40
= H;
HA .ctive-> HCtr
APPENDIX B. VC SCHEMATICS AND PAL FILES
192
tim41.abl
module Tim41
title 'TIM Module FSM #1
Eric McDonald
Last revised:
January
5, 1994
February 15, 1994'
"DESCRIPTION:
Tim41 device 'P22V10';
"*** Inputs
" LdClk from Bt440
Pin 1;
Pin 2,3,4,5,6; " Current state
FClk
Q0,Q1,Q2,Q3,Q4
HZero
VZero
RESET
is 0
is 0
Pin 8;
Pin 10;
"HCtr
" VCtr
Pin 11;
"Global
/RESET line
"*** Outputs
Pin
Pin
Pin
Pin
HDec,HLoad
VDec,VLoad
PromClk, PClr
PA0,PA1,PA2,PA3
23,22; "Dec and Load signals to HCtr
21,20; "Dec and Load signals to VCtr
Ctrl sigs to PROM
19,18 istype 'reg,invert';
17,16,15,14; " Address inputs to PROM
"*** State declarations
@include 'tim4.sta'
"*** Aliases
H, L, C, X = 1, 0, .C., .X.;
In_State MACRO (st) { (current_state
PAddr
== ?st)
};
= [PA3..PA0];
"PROM addresses of parameters used by timing FSM
HFrontPorch
HSync
HBackPorch
HActive
=
=
=
=
HLinesActive
HLinesInVFP
HLinesInVBP
= [0, 1, 0, 0];
= [0, 1, 0, 1];
= [0, 1, 1, 0];
[0,
[0,
[0,
[0,
0,
0,
0,
0,
0,
0,
1,
1,
0];
1];
0];
1];
HActiveInVBlk = [0, 1, 1, 1];
HBPaVBP
= [1, 0, 0, 01];
HLinesInVS
= [1, 0, 0, 1];
"***
Equations
equations
PromClk
= FClk;
APPENDIX B. VC SCHEMATICS AND PAL FILES
tim4 1.abl
In_State(HorizActive)
HDec
#
#
#
#
#
InState(HorizFrontPorch)
InState(HorizSync)
InState(HorizBackPorch)
InState(VertFrontPorch2)
InState(HorizSyncInVFP)
# In_State(VertSync2)
#
#
#
#
HLoad
InState(HorizSyncInVS)
InState(VertBackPorch2)
InState(HorizSyncInVBPO)
InState(HBPAfterVBP);
= (InState(HorizActive)
#
#
#
#
#
#
#
#
#
#
#
#
#
& HZero)
(InState(HorizFrontPorch)& HZero)
(InState(HorizSync)& HZero & !VZero)
(InState(HorizBackPorch)& HZero)
InState(VertFrontPorchl)
(InState(VertFrontPorch2)& HZero)
(InState(HorizSyncInVFP)& HZero)
(InState(VertSync2)& HZero)
(InState(HorizSyncInVS)& HZero & !VZero)
InState(VertBackPorchl)
(InState(VertBackPorch2)& HZero)
(InState(HorizSyncInVBPO)& HZero & !VZero)
InState(HorizSyncInVBP2)
(InState(HBPAfterVBP)& HZero);
VDec = (InState(HorizActive)
& HZero)
# (InState(VertFrontPorch2)& HZero)
# (InState(VertSync2)& HZero)
# (InState(VertBackPorch2)& HZero);
VLoad = In_State(Init)
# (InState(HorizSync)& HZero & VZero)
# In_State(VertSyncl)
# (InState(HorizSyncInVS)& HZero & VZero)
# (InState(HorizSyncInVBPO)& HZero & VZero);
!PClr
:= 0;
PAddr := (InState(Init)
#
#
#
#
#
#
#
#
#
#
#
#
#
#
& HLinesInVFP)
(InState(HorizActive)& HFrontPorch)
& HSync)
(In-State(HorizFrontporch)
(InState(HorizSync)& HZero & HActiveInVBlk)
(InState(HorizSync)& !HZero & VZero & HLinesInVFP)
(InState(HorizSync)& !HZero& !VZero& HBackPorch)
(InState(HorizBackPorch)& HActive)
(InState(VertFrontPorch2)& HSync)
(InState(HorizSyncInVFP)& HZero & HLinesInVS)
(InState(HorizSyncInVFP)& !HZero & HActiveInVBlk)
(InState(VertSync2)& HSync)
(InState(HorizSyncInVS)& HZero & HSync)
(InState(HorizSyncInVS)& !HZero& VZero & HLinesInVBP)
(InState(HorizSyncInVS)& !HZero & !VZero& HActiveInVBlk)
(InState(VertBackPorch2)& HSync)
193
APPENDIX B. VC SCHEMATICS AND PAL FILES
194
tim41. abl
#
#
#
#
end Tim41
(InState(HorizSyncInVBPO)& HZero & HBPaVBP)
(InState(HorizSyncInVBPO)& !HZero& VZero & HLinesActive)
(InState(HorizSyncInVBPO)& !HZero & !VZero& HActiveInVBlk)
(InState(HBPAfterVBP)& HActive);
APPENDIX B. VC SCHEMATICS AND PAL FILES
tim4. sta
current_state
= [Q4..QO];
Init
HorizActive
HorizFrontPorch
HorizSync
HorizBackPorch
=
=
=
=
=
VertFrontPorchO
VertFrontPorchl
VertFrontPorch2
HorizSyncInVFP
=
VertSyncO
VertSyncl
VertSync2
HorizSyncInVS
=
=
1,
1
1,
1,
1,
1,
0,
0,
0, 0 ];
VertBackPorchO
VertBackPorchl
VertBackPorch2
HorizSyncInVBPO
HorizSyncInVBPl
HorizSyncInVBP2
HBPAfterVBP
= [ 1, 0
0,
= [0
0,0,
= [
[
0,o,
=
= [ 1, 0,
= [ 1, 0,
= [ 1, 0
1,
1,
1,
1,
1,
1,
1,
0, 0 ];
[ 0, 0, 0,
[
0, 0,
[
0, 0,0,
[
0, 0,0,
[
0,0, 1,
[
=[
= [
= [
];
];
];
];
];
"0
"1
"3
"2
"6
0, 1, 0, 1, 0 ];
"a
"8
"9
"d
0,
0
1,
1,
1,
0
1
1
0
0
0, 1, 0, 0, 0 ];
0, 1, 0, 0, 1 ];
0, 1, 1, 0, 1 ];
[ 0,
[
=[ 1,
=[1
0, 0 ];
0, 0 ];
0, 1 ];
0, 0
0, 1
1, 1
1, 1
0, 1
1, 0
];
];
];
];
];
];
"c
"lc
"18
"19
"14
"4
"5
"7
"17
"15
"16
195
196
APPENDIX B. VC SCHEMATICS AND PAL FILES
APPENDIX B. VC SCHEMATICS AND PAL FILES
197
I
I
jSi
I
IX
C
I
c,
C
cC
0-
tt
IL
a.
I
C
c1
0~
0_
o.xl
I
!
198
APPENDIX B. VC SCHEMATICS AND PAL FILES
. I M.
A
5 i
jI I I
d
APPENDIX B. VC SCHEMATICS AND PAL FILES
rffff;f-
_..rrr';_ , *'
199
?
I
£
I~~~~~~~~~~~~~~~~~~~~I
I******** *********
200
APPENDIX B. VC SCHEMATICS AND PAL FILES
Bibliography
[1] K. Akeley and T. Jermoluk. High-Performance Polygon Rendering. Computer Graphics, 22(4):239-246, August 1988.
[2] Gary Bishop, Henry Fuchs, Leonard McMillan, and Ellen Scher Zagier. Frameless
Rendering: Double Buffering Considered Harmful. Proceedings of SIGGRAPH '94. In
Computer Graphics Proceedings, 1994, ACM SIGGRAPH. pages 175-176.
[3] Electronic Industries Association Engineering Dept. Electrical Performance Standards
for High Resolution Monochrome Closed Circuit Television Camera. Technical Report
EIA-343-A, Electronic Industries Association, September 1969.
[4] Jerko Fatovic. A Ray Tracer for the J-Machine. MS Thesis, Massachusetts Institute
of Technology Department of Electrical Engineering, May 1992.
[5] J.D. Foley, A. van Dam, S.K. Feiner, and J.F. Hughes. Computer Graphics: Principles
and Practice. Addison-Wesley, Reading, MA, 1990.
[6] H. Fuchs and B. Johnson.
prepublication draft of "An Expandable Multiprocessor
Architecture for Video Graphics". Proceedingsof the 6th ACM-IEEE Symposium on
Computer Architecture, pages 58-67, April 1979.
[7] S. Molnar, J. Eyles, and J. Poulton. PixelFlow: High-Speed Rendering Using Image
Composition. Computer Graphics,26(2):231-240, July 1992.
[8] Michael Noakes and John Cha. J-Machine Host Interface Specification.
Memo, Dec 1993.
MIT VLSI
[9] Michael Noakes and William J. Dally. System Design of the J-Machine. In William J.
Dally, editor, Sixth MIT Conference of Advanced Research in VLSI, pages 179-194,
Cambridge, MA 02139, 1990. The MIT Press.
[10] M. Potmesil and E. Hoffert. The Pixel Machine: A Parallel Image Computer. Computer
Graphics, 23(3):69-78, July 1989.
[11] Thucydides Xanthopoulos. A Disk Array for the J-Machine. BS Thesis, Massachusetts
Institute of Technology, Department of Electrical Engineering and Computer Science,
May 1992.
201
202
BIBLIOGRAPHY
[12] Sasan Zamani. A Scalable Distributed Frame Buffer for the J-Machine. BS Thesis, Massachusetts Institute of Technology, Department of Electrical Engineering and
Computer Science, May 1991.
-
), '?.1-_.!C_