constant msbFirst: ....................................0
constant drop: .............................uuuuuu..
constant take: .......................uuuuuu........
+
out: out
in: outOp
constant lsbFirst: ....................................1
Its capacity is guaranteed to be at least two full machine words or
more.
-Bits are enqueued by providing a word at the {\tt in} port and a count
-at the {\tt inOp} port (ports are named this way to take advantage of
-the switch fabric opcode mechanism). The {\tt inOp} count may be
-positive, negative, or zero.
-
-If the {\tt inOp} count is positive, a word will be taken from the
-{\tt in} port and its {\tt count} least significant bits will be
-enqueued most-significant-bit first.
-
-If the {\tt inOp} count is zero, a word will be {\it discarded} from
-the {\tt in} port and a duplicate copy of the bit at the {\it tail} of
-the fifo is enqueued. If the fifo is empty, an undefined bit will be
-enqueued. This mechanism is used for sign-extending words.
-
-If the {\tt inOp} count is negative, a word will be taken from the
-{\tt in} port and its {\tt |count|} most significant bits will be
-enqueued least-significant-bit first.
-
-Whenever a full word is present in the fifo, it will be made available
-for dequeueing at the {\tt out} port.
-
-\begin{verbatim}
-FIXMEs
-- previously I noted that it would be nice to be able to dequeue bits
- without consuming them (ie copy-out). What was this needed for?
-\end{verbatim}
+\subsection*{Enqueueing}
+
+Bits are enqueued by providing a word at the {\tt in} port and a code
+word at the {\tt inOp} port (ports are named this way to take
+advantage of the switch fabric opcode mechanism \cite{am25}). As
+shown in the constant diagram, this code word has fields {\tt
+lsbFirst}, {\tt msbFirst}, {\tt drop}, and {\tt take}.
+
+When a word is consumed from {\tt in}, it is ``oriented'' in either
+Most Significant Bit First ({\tt msbFirst}) or Least Significant Bit
+First ({\tt lsbFirst}) depending on whether or not these flags are
+set. Based on this orientation, the first {\tt drop} bits are
+discarded. Then the next {\tt take} bits are enqueued into the fifo.
+Any remaining bits are discarded. Attempting to drop or take beyond
+the end of a word produces undefined results.
+
+\subsection*{Dequeueing}
+
+Bits are dequeued by providing a code word at the {\tt outOp} port
+(despite its name, this is actually an {\it input port}). As shown in
+the constant diagram, this code word has fields {\tt lsbFirst}, {\tt
+msbFirst}, {\tt signExtend}, {\tt drop}, {\tt take}, and {\tt copy}
+fields.
+
+Before additional processing, {\tt drop} bits are discarded from the
+head of the fifo. Next, bits are dequeued into an empty word-width
+register. If the {\tt msbFirst} flag is set, bits will be deposited
+into this register starting with the most significant bit of the
+register and working towards the least significant bit. If the {\tt
+lsbFirst} flag is set, bits will be deposited into this register
+starting with the {\it least} significant bit of the register and
+working towards the {\it most} significant bit. The number of bits
+dequeued is specified by the {\tt take} field. If the {\tt copy}
+field is specified instead, the bits will be {\it copied} out of the
+fifo rather than being removed.
+
+Finally, if the {\tt signExtend} bit is set, all bits in the register
+which were not filled by bits dequeued from the fifo will be filled
+with a copy of {\it the last bit dequeued from the fifo}.
+
+As a final addendum to the above, whenever a request arrives at {\tt
+outOp} which requires more bits than are available in the fifo, the
+operation will wait until enough bits are present.
+
+\subsection*{To Do}
+
+The text above regarding sign extending and dequeueing
+msbFirst/lsbFirst is wrong.
== Fleeterpreter ====================================================
projects / fleet.git / blobdiff