
\chapter{PAM and DECPeRLe-1}
\label{CHEN-Chapter04}

There are two ways to implement a specific digital processing task: software
approach and hardware approach.

In software approach, a general purpose computer is programmed to perform a
processing task. The structure of any general purpose computer has been 
highly optimized to process arbitrary codes. In many cases, however, it is 
poorly suited to the specific algorithm, so the performance does not meet
the requirement. 

In the hardware approach, a specific circuitry/machine for the specific 
processing task is designed. The machine's structure, processors, storage
and interconnect, are tailored to the application. The result is more 
efficient, with less actual circuitry than what general purpose computers 
would require.

The drawback of the hardware approach is that a specific architecture is
usually limited to processing a small number of algorithms, often a single
one. Attaching special purpose hardware to a general purpose computer, 
say for video compression, speeds up the system when the system is 
actually compressing video. It contributes nothing when the system is 
required to perform some different task, say machine learning.

An alternative way is a reconfigurable hardware, which combines software
versatility and hardware performance. DEC PRL's Programmable Active 
Memory (PAM) was one of the earliest pioneers in this so-called 
{\it reconfigurable computing} field. PAM is a novel form of universal 
reconfigurable hardware co-processor based on SRAM-based FPGA technology.

This chapter presents the concept of PAM and the detail of one realization
of PAM --- PeRLe-1 board which is available in the Department of Electrical
Engineering at Portland State University. For more complete description
about PAM and DEC-PERLE-1 board, please see references \cite{pamweb1,pamweb2,
pam89,pam93,pam96,p1inst,p1hard,p1soft,p1tut,p1lib}.

\section{PAM}
\label{CHEN-section4.1}

A PAM concept is a uniform array of identical cells all connected in the same
repetitive fashion. Each cell, called a PAM for Programmable Active Bit, 
must be general enough so that the following holds true: Any synchronous
digital circuit can be realized, through suitable programming, on a large
enough PAM, for a slow enough clock. 

\begin{figure}[H]
\centerline{\hbox{\psfig{figure=fig/pam1.ps,width=4.5in}}}
\caption{A simple PAM}
\label{fig:pam1}
\end{figure}

Figure \ref{fig:pam1} shows a simple PAM implementation as a regular
matrix of Manhattan connected identical PABs. Each PAB has:
\begin{itemize}
\item 4 inputs $<n,s,e,w>$
\item 4 outputs $<N,S,E,W>$
\item 1 register (flip-flop) with input $R$ and output $r$, synchronous with
      the PAM's global clock $clk$
\item 1 combinatorial gate $F$ (5 inputs, 5 outputs) connected so that:\\ 
      $g(n,s,e,w,r)=<N,S,E,W,R>$
\item $160 = 5 \times 2^5$ control bits which specify the truth table of 
  function $F$.
\end{itemize}

A {\it program} for such a PAM with $m$ active bits is a sequence of
$160m$ control bits ({\it bitstream}) representing the truth tables 
for each PAM. This program can be {\it download}ed into the 
{\it configuration memory} of the PAM. From this instant, and until 
the program is changed again, the PAM behaves as the particular finite 
state machine specified by the bitstream.

\begin{figure}[H]
\centerline{\hbox{\psfig{figure=fig/pam2.ps,width=4in}}}
\caption{PAMs as virtual machines}
\label{fig:pam2}
\end{figure}

The PAM is used to implement a {\it virtual machine} which can be dynamically
configured as a large number of specific hardware devices. As shown in 
Figure \ref{fig:pam2}, the PAM is connected to a host computer through
the {\it in} and {\it out} links. The host can download configuration
bitstreams into the PAM. After configuration, the PAM behaves, 
electrically and logically, like the ASIC (Application Specific Integrated
circuit) defined by the specific bitstream. The PAM may operate in 
stand-alone mode, hooked to some external system through the {\it in'} 
and {\it out'} links. It may operate as a co-processor under host control,
this co-processor is specialized to speed-up some crucial computations. 
It may operate in both modes simultaneously, connecting the host to some 
external system, like an audio or video device, or some other PAM.

The PAM as presented above is only a theoretical concept and has been
not realized in practice. Digital's Paris Research Laboratory developed 
several boards based on the PAM concept, but realized with the existing FPGA
chips, thus the actual cell structure and connections are different from
the cell and connection model shown in Figure \ref{fig:pam1}. 
DECPeRLe-1 is the third generation PAM board,
and it was built at Digital's Paris Research Laboratory in 1992. 

\section{PERLE-1 Board}
\label{CHEN-section4.2}

The overall structure of DEC-PERLE-1 is shown in Figure \ref{fig:pam3}. The 
DEC-PERLE-1 board is organized around a central computational matrix made up of
16 Xilinx XC3090 LCAs\footnote{LCA stands for Logic Cell Arrays}
(M00 to M15 in the figure), surrounded by a 4 1MB RAM 
bank, and 7 other LCAs to implement switching and controlling functions. 
The data buses and their width are also shown in the figure (everything
shown in the figure will be explained later in this section). All control 
wires are shown in Figure \ref{fig:cntrbus} and will be discussed in 

\begin{figure}[H]
\centerline{\hbox{\psfig{figure=fig/pam3.eps,width=5.85in}}}
\caption{ DEC-PERLE-1 architecture}
\label{fig:pam3}
\end{figure}

\begin{figure}[H]
\centerline{\hbox{\psfig{figure=fig/matrix.ps,width=5.85in}}}
\centering{
DCN, DCE, DCS and DCW: North/East/South/West matrix side to connectors\\
MDN, MDE, MDS and MDW: Matrix North/East/South/West direct connections\\
MBN, MBE, MBS and MBW: North/East/South/West matrix buses
}
\caption{DEC-PERLE-1 matrix}
\label{fig:matrix}
\end{figure}

related sections. This section describes all programmable resources
and the way they are interconnected with each other.


\subsection{Computational matrix}
\label{CHEN-section4.2.1}

The central computational matrix is a $ 4 \times 4$ matrix of
Xilinx 3090 LCAs. These LCAs are interconnected with each other.
The internal structure of the matrix is shown in Figure \ref{fig:matrix}.
The LCAs are named LCA\_M00 to LCA\_M15 (M00 to M15 in the figure). 
This matrix can be used to develop any kind of digital circuitry: data 
path, control unit and others. But it is typically used to develop the
data path of the application. The interconnection resource between them 
can be classified into the following three categories.

% \tinytitle{Direct Connections}
\subsubsection{Direct Connections}

As shown in Figure \ref{fig:pam6}, these wires connect the adjacent 
sides of adjacent LCAs. The main purpose of direct connections is to 
extent the internal regularity of the LCA to the matrix level.
The matrix can be seen as a large FPGA with $64 \times 80$ PABs

\begin{figure}[H]
\centerline{\hbox{\psfig{figure=fig/pam6b.eps,height=3in}}}
\caption{DEC-PERLE-1 Direct connection}
\label{fig:pam6}
\end{figure}
(one XC3090 FPGA has $16 \times 20$ PABs).
Each LCA has 16 such wires on each side.


As shown in Figure \ref{fig:matrix}, the horizontal and vertical direct
connections are named DCmm\_nnH and DCmm\_nnV, respectively, where mm and
nn are the numbers of the connected LCAs. For instance, DC00\_04V 
represents vertical direct connections between LCA\_M00 and LCA\_M04.

The direct connections at the edges of the FPGA matrix are called
DCN, DCE, DCS and DCW as shown in Figure \ref{fig:pam6}. These four
64-bit-wide connections are connected to external connectors, which
can be used to connect other devices, for example, another DEC-PERLE-1 board.

% \tinytitle{Buses}
\subsubsection{Buses}

As shown in Figure \ref{fig:pam7}, 
the horizontal or vertical wires connect the corresponding
side of all 4 LCAs in the same row or column. They can thus 
efficiently distribute global data in one direction, and
are comparable to the {\it longline} interconnections

\begin{figure}[H]
\centerline{\hbox{\psfig{figure=fig/pam7.eps,height=3.5in}}}
\caption{DEC-PERLE-1 Matrix data buses}
\label{fig:pam7}
\end{figure}

resources in Xilinx internal architecture. Each LCA has
16 such wires on each side. According to their directions, these 
buses are named {\it matrix North, East, South and West bus}, 
respectively, and represented by MBusN, MBusE, MBusS and MBusW 
for short. Each bus has 64 wires which are connected to switches
on the corresponding side of matrix FPGAs.

% \tinytitle{Rings}
\subsubsection{Rings}

As shown in Figure \ref{fig:pam8}, 
the wires connect all the matrix LCAs and two control LCAs. These 
connections are very useful for global control signals distribution 
since they connect to all the matrix LCAs. There are
10 such wires. Note that because of their electrical loading (they 
are used to connect 18 LCAs, 16 matrix LCAs and two control LCAs),
these wires are slower than the buses and should be used with care
in high performance designs.

\begin{figure}[H]
\centerline{\hbox{\psfig{figure=fig/pam8.eps,height=2.85in}}}
\caption{DEC-PERLE-1 Matrix rings}
\label{fig:pam8}
\end{figure}


\subsection{Switches and I/O buses}
\label{CHEN-section4.2.2}

Figure \ref{fig:pam3} shows the way that FIFOs, RAM banks and the central
matrix are connected through two 32-bit data buses and five programmable
switches (FPGAs).

As shown in Figure \ref{fig:pam3}, there is one matrix switch on each 
side of the matrix,  respectively called {\it North Switch} (SWN), 
{\it East Switch} (SWE), {\it South Switch} (SWW) and {\it West Switch}
(SWW), which connect the corresponding matrix data buses and 
corresponding RAM banks. These 4 switches (SWN, SWE, SWS, SWW) 
also connect to two 32 bits I/O buses, called {\it North-East Bus}
(DBusNE) and {\it South-West Bus} (DBusSW) after the names of the 
switches they respectively connect. 

Two I/O buses (DBusNE, DBusSW) connect to the input and output FIFOs 
through the fifth switch called {\it Fifo Switch} (FSW), and also connect
to corresponding controllers, called {\it North-East Controller} (CNE) and
{\it South-West Controller} (CSW). 

As their names imply, the FPGAs CNE and CSW are typically used to 
develop the controller of the application because they connect to
all other parts of the DEC-PERLE-1, FIFOs, Memory banks and other FPGAs.

\subsection{Control resource}
\label{CHEN-section4.2.3}

\begin{figure}[H]
\centerline{\hbox{\psfig{figure=fig/cntrbus.ps,width=5.85in}}}
\centerline{(see section sections~\ref{CHEN-section4.2.3},~\ref{CHEN-section4.2.4}
 and~\ref{CHEN-section4.2.6} for more detail)}
\caption{DEC-PERLE-1 control wires}
\label{fig:cntrbus}
\end{figure}

The control resource is the programmable resource that can be used to
develop the control part of the application other than data path part.
As shown in Figure \ref{fig:cntrbus}, the data path resource (matrix, 
RAM banks, FIFOs and switches) need the following set of control wires:
\begin{description}
\item MATRIX RINGS: There are 10 matrix global wires (see section~\ref{CHEN-section4.2.1}).
      These wires are not used in our CCM design.
\item RAM ADDRESS: Each RAM bank has a 18-bit-wide address, that 
      specify the word address of the current read or write operation.
      Since our CCM design uses two of four memory banks, two addresses
      are used in our CCM design.
\item RAM CONTROLS: Each RAM bank has 4 control signals (see section~\ref{CHEN-section4.2.4}).
      Since our CCM design uses two memory banks, the corresponding controls
      are used in our CCM design, 
\item SWITCH CONTROLS: Each pair of matrix switches ({\it North}
      and {\it East} / {\it South} and {\it West}) has 10 control
      wires that are the equivalent of the matrix rings, and are
      called {\it switch ring}. The {\it Fifo Switch} has 6 control
      wires. In addition, each of the matrix switches has
      2 dedicated control wires (see Figure \ref{fig:cntrbus}).
      These wries are used in our CCM design.
\item FIFO CONTROLS: Each of the two FIFOs has one status wire:
      empty flag for input FIFO / full flag for output FIFO;
      and one control wire: write for output FIFO / read for input
      FIFO (see Figure \ref{fig:cntrbus}). These wires are used in
      our CCM design.
\item TAGS: Four ``tag" wires along the input data wires on the
      input FIFO (see section~\ref{CHEN-section4.2.6}). These wires are not used in
      our CCM design.
\item CLOCK CONTROL: The clock generator has two control wires that
      can be driven by the application design (see section~\ref{CHEN-section4.2.5}).
      These wires are not used in our CCM design.
\item LCBus: There is a 24-bit-wide communication path between the
      board and the host, called {\it LCBus} (see section~\ref{CHEN-section4.2.6}).
      These wires are not used in our CCM design.
\end{description}

As shown in Figure \ref{fig:cntrbus}, all these control wires are
connected to one of two controller LCAs (CNE, CSW) or both of them.
These two controllers are identical except that each of them controls 
two of the four switches and memory banks.
These two controllers also connect to corresponding I/O bus in order 
for it to be able to communicate with the main datapath.

\subsection{Memory subsystem}
\label{CHEN-section4.2.4}

DEC-PERLE-1contains 4MB of high-speed static RAM organized in 4 banks of
256K 32-bit words (4 bytes a word). These banks are named {\it North,
South, East} and {\it West} after the matrix switch to which they 
are connected. Each bank is completely independent of the others and 
has its own data, address and control signals:
\begin{description}
\item DATA BUS: 32 data wires connect to the corresponding matrix switch.
      They are represented by $RamdataX$, where X is one of
      {\it N,S,E,W} to respectively specify the North, South, East or 
      West RAM bank.
\item ADDRESS BUS: 18 address wires ($1MB = 2^{20} = 2^{18} \times 2^{2}$)
      connect to the corresponding controller.
      They are represented by $RamAddrX$. 
\item CONTROL BUS: 4 active-low control signals to specify the read/write
      operation, connect to the corresponding controller.
  \begin{itemize}
  \item $\overline{RamReadX}$: read command.
  \item $\overline{RamWriteX}$: write command.
  \item $\overline{RamDisLowX}$: disable lower half-word (bits 0 to 15).
  \item $\overline{RamDisHighX}$: disable upper half-word (bits 16 to 31).
  \end{itemize}
  In our CCM design, we always read/write memory by a 32-bit word a time. 
  Therefore, the signal $\overline{RamDisLowX}$ and $\overline{RamDisHighX}$
  are always set to 1 (not actived).

\end{description}

The basic read and write transactions both last one clock cycle, and 
either may be performed at every cycle. 

% \tinytitle{Read memory}
\subsubsection{Read memory}

To read a particular word of memory, the word address ($RamAddrX$)
must be presented and the read command ($\overline{RamReadX})$ must be 
asserted at the beginning of a cycle; the data word read from memory will
be available on the data wires at the end of the same cycle and may be 
latched on the next clock tick.  A RAM bank can be seen as a combinational
device when read.

% \tinytitle{Write memory}
\subsubsection{Write memory}

To write a particular word of memory, the word address ($RamAddrX$),
the data ($RamDataX$) and the write command ($\overline{RamWriteX})$ 
must be asserted during the same cycle; the word will have been written 
by the end of the same cycle, and the address and the data may be removed
after the next clock tick.

\vspace{0.2in}
The reading or writing of either half of the data word may be independently
disabled by asserting the corresponding disabled command
($\overline{RamDisLowX}$ or $\overline{RamDisHighX}$) during the
transaction cycle. The memory system is clocked by {\it clock1} signal
(see section~\ref{CHEN-section4.2.5}).

\subsection{Clock subsystem}
\label{CHEN-section4.2.5}

Two global synchronous clock signals, {\it clock0} and {\it clock1}, are 
available to all \\ DEC-PERLE-1 LCAs for proper synchronous operation.
These clock signals are generated by a phase-locked-loop oscillator 
synchronized to the host bus master clock. When DEC-PERLE-1 is connected to a 
DEC 5000/24 workstation (25MHz TURBOchannel), its frequency can be 
programmed under software control to be any value from 360 KHz to 120 
MHz, with an average resolution of 0.01\%.

\subsubsection{4.2.5.1 Clock modes}
\label{CHEN-section4.2.5.1}

Under software (the program running on the host) control, the clock 
generator may be put in the following operation modes:
\begin{description}
\item STOP MODE: No clock is generated in this mode.
\item FREE-RUN MODE: This is the normal operating mode, where the clock
      continuously runs at the prescribed frequency.
      Our CCM design will run in this mode.
\item BURST MODE: This is a mode where, under software control, the
      clock generator will generate a burst of 1 to 31 clock ticks
      at the prescribed frequency, then stop. This is useful to
      implement step and double-step debugging modes. 
      We will use this clock mode to debug our CCM design.
\item AUTOSTOP MODE: There are two autostop modes: {\it FifoIn-Autostop}
      and {\it FifoOut-Autostop}. In the {\it FifoIn-Autostop} mode,
      {\it clock0} will automatically stop whenever the design attempts to
      read an empty input FIFO. Similarly, in the {\it FifoOut-Autostop} mode,
      {\it clock0} will automatically stop whenever the design attempts to
      write a full output FIFO. These two modes can be enabled at the same time.
      Our CCM design will always run in this mode.
\item CLOCK1-DIV2: This mode is useful for very high performance designs.
      {\it clock1} runs at half the speed of {\it clcok0}. This allows the 
      RAM and FIFOs to be operated on half the speed of the matrix.
      This clock mode is not used in our CCM design.
\end{description}

% \pagebreak
% \vspace{- \baselineskip}
% \tinytitle{{\it clock0} stop}
\subsubsection{4.2.5.2 {\it clock0} stop}
\label{CHEN-section4.2.5.2}

The {\it clock0} may stop under control of the application on the board. 
This is usually
used to implement {\it flow-control}, where the entire datapath is stopped
waiting for input data (when the input FIFO is empty) or output space (when
the output FIFO is full). It is much more efficiently and easily implemented
this way than through the global distribution of a clock enable signal.
%
In effect, when application runs entirely on {\it clock0} and both autostop
modes are enabled, the application can be seen as a perfect synchronous
system without flow-control concern.

The {\it clock0} signal will stop under one or more of the following 
conditions:
\begin{itemize}
\item The active-low $\overline{ClkStop}$ signal is asserted from one of
      the controllers.
\item In the {\it FifoIn-autostop} mode, the input FIFO is empty and
      the active-low \\ $\overline{FifoInRead}$ signal is asserted from 
      one of the controllers.
\item In the {\it FifoOut-autostop} mode, the output FIFO is full and
      the active-low \\ $\overline{FifoOutWrite}$ signal is asserted from
      one of the controllers.
\end{itemize}

The memory subsystem and the FIFOs are clocked by {\it clock1}. This means
that it is still possible to perform memory and/or FIFO operations even when 
{\it clock0} is stopped.
This feature is not used in our CCM design.

\subsubsection{4.2.5.3 Slow mode}
\label{CHEN-section4.2.5.3}

Under control of an application on the board, it is possible to slow down
the clock (divide its frequency by 4) by asserting the active-low 
$\overline{ClkSlow}$ signal from one of the controllers. This is useful 
when an application can run at a very high speed, but must infrequently
perform an operation that is impossible to be performed at the high speed
(like stopping the clock, or accessing the FIFOs). The $\overline{ClkSlow}$
can be asserted at any speed, but its operation is asynchronous, that is,
it will take an unpredictable number of cycles for it to be effective. 
If the operation frequency is less than 80 MHz, this number of cycles 
is however guaranteed to be less than or equal to 6.
This feature is not used in our CCM design.

\subsection{Host interface}
\label{CHEN-section4.2.6}

The DEC-PERLE-1 application is running under the control of the software program
executed on the host computer. The communication between DEC-PERLE-1 application
and its driving software program can be done through FIFOs or LCBus.

\subsubsection{FIFOs}
\label{CHEN-section4.2.6.1}

There is a 32-bit-wide, 512-word-deep FIFO in each direction
(see Figure \ref{fig:des7}). These FIFOs are called {\it input FIFO} for
the Host-to-PAM direction and {\it output FIFO} for the PAM-to-Host 
direction, respectively. On the application side, their data 
wires are connected to the {\it Fifo Switch} LCA and their control
wires to the two Controller LCAs. Both FIFOs are purely synchronous
devices when operated from the application side. They appear to be 
always available for reading or writing in {\it autostop} mode.

The input FIFO and output FIFO are synchronous devices that offer two
active-low status signals $\overline{FifoInEmpty}$ and 
$\overline{FifoOutFull}$ and two active-low command signals
$\overline{FifoInRead}$ and $\overline{FifoOutWrite}$. These four
signals are connected to the two Controller LCAs CNE and CSW (see Figure 
\ref{fig:cntrbus}). The Input FIFO is operated as follows:

\begin{figure}[H]
\centerline{\hbox{\psfig{figure=fig/fifoin1.ps,width=5.85in}}}
\centerline{(a) the input FIFO read operation (no autostop)}
\vspace{0.1in}
\centerline{\hbox{\psfig{figure=fig/fifoin2.ps,width=5.85in}}}
\centerline{(b) the input FIFO read operation (autostop)}
\caption{The input FIFO operation}
\label{fig:fifoin}
\end{figure}

\begin{itemize}
\item When the design is in {\it FifoIn-autostop} mode, 
      if on one cycle $\overline{FifoInRead}$ is asserted and 
      $\overline{FifoInEmpty}$ is inactive, the FIFO is read and the
      data word shows on the {\it FifoInData} wires in the next 
      cycle (see Figure \ref{fig:fifoin} (a)).
\item In any other situation except in the {\it FifoIn-autostop} mode, 
      no operation is performed in this cycle and the current value of 
      {\it FifoInData} is held to the next cycle.
\item When the design is in {\it FifoIn-autostop} mode and
      the design is entirely clocked by {\it clock0}, 
      if $\overline{FifoInRead}$ is asserted, the data
      word is available on the next cycle (see Figure \ref{fig:fifoin} (b)).
\end{itemize}

The output FIFO is operated as follows:
\begin{itemize}
\item When the design is not {\it FifoOut-autostop} mode, 
      if on one cycle $\overline{FifoOutWrite}$ is asserted and 
      $\overline{FifoOutFull}$ is inactive, the FIFO is written and the
      data word present on the {\it FifoOutData} wires in this cycle
      is pushed into the output FIFO (see Figure \ref{fig:fifoout} (a)).
\item In any other situation except in {\it FifoOut-autostop} mode, 
      no operation is performed in this cycle and the data present on 
      the {\it FifoOutData} is ignored.
\item When the design is put in {\it FifoIn-autostop} mode and
      the design is entirely clocked off {\it clock0}, 
      if $\overline{FifoOutWrite}$ is asserted, the data present on
      the {\it FifoOutData} is pushed into the output FIFO
      (see Figure \ref{fig:fifoout} (b)).
\end{itemize}

\begin{figure}[H]
\centerline{\hbox{\psfig{figure=fig/fifoout1.ps,width=5.85in}}}
\centerline{(a) the output FIFO write operation (no autostop)}
\vspace{0.1in}
\centerline{\hbox{\psfig{figure=fig/fifoout2.ps,width=5.85in}}}
\centerline{(b) the output FIFO write operation (autostop)}
\caption{The output FIFO operation}
\label{fig:fifoout}
\end{figure}

As shown in Figure \ref{fig:fifoin} and \ref{fig:fifoout}, all operations
of the input and output FIFOs occur at the raising edge of the 
{\it clock1} signal.

The input FIFO can be written and the output FIFO can be read by the 
driving software through the runtime library. The program running on 
the host computer can access the input and output FIFOs through the 
following FIFO operations: 

\begin{description}
\item WriteFifo: this operation pushes 32-bit data word into the input
      FIFO. The corresponding runtime library is {\it P1WriteFifo()}.
\item WriteFifoTagged: this operation pushes one 32-bit data word into
      the input FIFO and sets the tag bits. The corresponding 
      runtime library {\it P1WriteFifoTagged()}.
\item ReadFifo: this operation reads one 32-bit data word from output
      FIFO. The corresponding runtime library is {\it P1ReadFifo()}.
\item WritePAM: this operation successively pushes a 19-bit address 
      word and a 32-bit data word in the input FIFO; the address word
      is present on bits 5 to 23. The corresponding runtime library 
      is {\it P1WritePAM()}.
\item ReadPAM: this operation successively pushes a 19-bit address 
      word in the input FIFO and reads a 32-bit data word form the 
      output FIFO; the address word is present on bits 5 to 23. 
      The corresponding runtime library is {\it P1ReadPAM()}.
\end{description}

\subsubsection{LCBus}
\label{CHEN-section4.2.6.2}

The LCBus is a 24-bit-wide general purpose register that can be
read and written by both the software and the application design. 
The LCBus can be used for asynchronous communication between the 
Controller LCAs and the software program.  Under the software 
control, the direction of each bit can be set independently of 
the others. Initially (after download), all bits are set for 
PAM-to-Host communication.  
This feature is not used in our CCM design.

\subsubsection{Tags}
\label{CHEN-section4.2.6.3}

Every word that the software (the program running on the host) pushes
into the input FIFO is ``tagged"
with 4-bit value. These tag bits are read from the input FIFO at the
same time as the data word, and are available on both Controller
LCAs and on the {\it Fifo Switch}. The meaning of these bits is as follows:
\begin{description}
\item TagDataSource (TDS): When set, the word was pushed by a DMA\footnote
{ DMA stands for {\it Direct Memory Access}. The DMA is a fast way of
  transferring data between memory and other devices (not CPU) in a 
  computer system. For example, the DMA operation can be used to transfer
  data between memory and hard disk in a PC system. 
} 
      transfer operation.
\item TagDataType (TDT): This bit is only valid when {\it TagDataSource}
      is 0 (not set) . When valid and set, the word is a 19-bit address 
      pushed by a {\it WritePAM} or {\it ReadPAM} transaction.
\item TagAddr0, TagAddr1 (TA0, TA1): these two bits can be defined by the
      user.
\end{description}
These tags are not used in our CCM design.

\subsection{Performance}
\label{CHEN-section4.2.7}

The main timing characteristics of the DEC-PERLE-1 is shown in table
\ref{tbl:p1perf}. For a given design, the worst-case propagation 
delay can be determined by combining these timing characteristics
and Xilinx chip time characteristics.

\begin{table}[h]
\caption{DEC-PERLE-1 Timing Characteristics}
\begin{center}
\begin{tabular}{|l|l|c|} \hline
% title
Connection & Name & Delay \\ \hline
% content
Matrix direct connection & DCnn-mmX & 24 ns \\ \hline
Matrix bus    & MBusX & 28 ns \\ 
I/O bus       & DBusXX & \\ 
Switch ring   & RingSwXX & \\ 
Switch control &SwCntrX & \\ 
Fifo switch control & FswCntr & \\ \hline
Matrix ring  & RingMat & 43ns\\ \hline
% Matrix ring two sources
% \footnote{For inproving performance, it is
% possible to drive the rings from both controllers at once.}
% & RingMat & 35ns \\ \hline
Memory read, address to data & RamAddrX to RamDataX & 46ns \\ \hline
Memory read, control to data & RamReadX to RamDataX & 35ns \\ \hline
Memory write, from any source & & 33ns \\ \hline
Fifo data & FifoInData & 23 ns \\
          & FifoOutData & \\
Tags      & TagAddr &     \\
          & TagDataType & \\
          & TagDataSource & \\ \hline
Fifo Status & FifoInEmpty & 27 ns \\
            & FifoOutFull& \\ \hline
Fifo Command & FifoInRead & 30 ns \\
             & FifoOutWrite & \\ \hline
\end{tabular}
\end{center}
\label{tbl:p1perf}
\end{table}

The goal of this table is to provide the further designers with data
allowing the understanding of delays of different kinds of connections,
so that they can make reasonable trade-off decisions for their designs. 
For instance, as shown in the table, the delay of matrix
rings is 43ns, and the delay of matrix direct connection is 24ns. For a 
given signal, if we can use either matrix rings or matrix direct connection, 
the matrix direct connection should be a better choice.

\subsection{The runtime library}
\label{CHEN-section4.2.8}

The runtime library of DEC-PERLE-1 is essential to the developer who develops
the {\it driving program} which runs on the host computer and controls
the DEC-PERLE-1 hardware for the application. The runtime library is the only
way to access DEC-PERLE-1 hardware for the driving program. The runtime library
developed by Digital Paris Research Laboratory provided a few essential
controls to the application driving program:
\begin{itemize}
\item A UNIX I/O interface, with open, close, read and write.
\item Download the configuration bitstreams from host to DEC-PERLE-1,
      and/or read back the values of all the flip-flops of all the 
      LCAs.
\item Read/write static RAM on DEC-PERLE-1 by the software program.
\item Control the mode and speed of DEC-PERLE-1 clock by the software program.
\end{itemize}

\section{Programming}
\label{CHEN-section4.3}

For using DEC-PERLE-1 board, we must run an application-specific program on
the host computer which connects to the DEC-PERLE-1 board. On the other hand,
the 23 FPGA chips of the DEC-PERLE-1 must be programmed to realize an
application-specific hardware. Therefore, A DEC-PERLE-1 program consists of 
two parts:
\begin{itemize}
\item the {\it driving program} which runs on the host and controls the
      DEC-PERLE-1 hardware.
\item A 1.5 MB bitstream which programs the 23 XC3090 FPGAs of the DEC-PERLE-1
      to realize an application-specific hardware.
\end{itemize}

The driving program is written in C or C++ and is linked to the runtime 
library encapsulating a device driver. The requirement for developing
the driving program is the C or C++ programming environment and the DEC-PERLE-1
runtime library.

For generating 1.5MB bitstream that programs the XC3090 FPGAs to realize
application-specific hardware, the following steps are involved:
\begin{enumerate}
\item Design Partition

      In this step, you map your design onto 23 FPGA chips according
      to your design and the constraint of DEC-PERLE-1 board. Some of FPGA 
      chips may be not used in your design. For example, our CCM design uses
      only 17 FGPA chips of all 23 chips. The steps 2 and 3 should be carried
      out separately for each FPGA chip that is used in your design.

\item Design Entry

      In this step, you create your design using a Xilinx-supported 
      schematic editor or hardware description language (like VHDL)
      for each FPGA used  in your design separately. This step produces
      a Xilinx netlist file (XNF file) for the next step. There are 
      three kinds of design entry methods:

 \begin{enumerate}
 \item Schematic editor: you can use schematic editor to create your
       design, then your schematic editor should be able to generate
       the XNF file.

%      Mentor's Design Architect for FPGA (pld\_da tool) is such
%      a schematic editor that is supported by Xilinx.
      
 \item Hardware description language: you can use VHDL or other
       hardware description language to create your design, then you
       need a synthesis software to synthesize and optimize your design 
       and produce the XNF file.

 \item Another possible way is to use a C++ program and the PerleDC
       library to describe your design. Individual configuration of
       each FPGAs involved in your design are described by this C++
       program. Compiling and running this C++ program generates the
       XNF file of your design \cite{pam96,p1tut,p1lib}.
 \end{enumerate}
  There are two sets of tools available at EE of PSU as of this writing:
  {\it Xilinx Foundation Series} and {\it OrCAD Express 7.0}. Both
  of them support schematic editor and hardware description language.
  Due to the lack of license, the {\it Xilinx Foundation Series} only
  supports schematic editor. {\it Xilinx Foundation Series} was used 
  to capture our CCM design. For more information about this software,
  please see \cite{xilinx97d} and online reference. I do not have 
  experience with {\it OrCAD Express 7.0}. For more information about 
  this software, please see the documentation shipped with the software 
  and online reference.

\item Design Implementation
 
      Map, place and route your design, and finally generate the
      bitstream file by using Xilinx development tools.

      Since all FPGAs used on DEC DEC-PERLE-1 board are XC3090 FPGAs,
      we need a Xilinx development tools that support XC3090
      FPGA. As of this writing, the latest Xilinx development
      tool, {\it Xilinx's Alliance Series Release Version 1.4} (also
      known as {\it M1 software}), is available at EE of PSU. 
      Unfortunately, M1 software does not support XC3090 FPGA 
      anymore since XC3090 FPGA is obsolete. M1 software does support
      two families of Xilinx 3000 series FPGA, XC3000A and XC3000L. 
      XC3090 belongs to  XC3000 family. Therefore, our CCM design
      are mapped to XC3090A chips. For more information about 
      M1 software, please see \cite{xilinx97a,xilinx97b} and online
      reference.

\item Design Verification

      At this step, the bitstream generated at previous step is 
      downloaded into the DEC-PERLE-1 board and the design is tested. 
      If something goes wrong, you may need to modify your design 
      at design entry step, then regenerate the bitstream file, download
      it to DEC-PERLE-1 board and test your design again.
\end{enumerate}

