aboutsummaryrefslogtreecommitdiffstats
path: root/manual/CHAPTER_CellLib.tex
blob: 0106059b6a37443d9237350cb0009d021c08e6c7 (plain)
1
2
3
4
5
6
7
pre { line-height: 125%; margin: 0; }
td.linenos pre { color: #000000; background-color: #f0f0f0; padding: 0 5px 0 5px; }
span.linenos { color: #000000; background-color: #f0f0f0; padding: 0 5px 0 5px; }
td.linenos pre.special { color: #000000; background-color: #ffffc0; padding: 0 5px 0 5px; }
span.linenos.special { color: #000000; background-color: #ffffc0; padding: 0 5px 0 5px; }
.highlight .hll { background-color: #ffffcc }
.highlight { background: #ffffff; }
.highlight .c { color: #888888 } /* Comment */
.highlight .err { color: #a61717; background-color: #e3d2d2 } /* Error */
.highlight .k { color: #008800; font-weight: bold } /* Keyword */
.highlight .ch { color: #888888 } /* Comment.Hashbang */
.highlight .cm { color: #888888 } /* Comment.Multiline */
.highlight .cp { color: #cc0000; font-weight: bold } /* Comment.Preproc */
.highlight .cpf { color: #888888 } /* Comment.PreprocFile */
.highlight .c1 { color: #888888 } /* Comment.Single */
.highlight .cs { color: #cc0000; font-weight: bold; background-color: #fff0f0 } /* Comment.Special */
.highlight .gd { color: #000000; background-color: #ffdddd } /* Generic.Deleted */
.highlight .ge { font-style: italic } /* Generic.Emph */
.highlight .gr { color: #aa0000 } /* Generic.Error */
.highlight .gh { color: #333333 } /* Generic.Heading */
.highlight .gi { color: #000000; background-color: #ddffdd } /* Generic.Inserted */
.highlight .go { color: #888888 } /* Generic.Output */
.highlight .gp { color: #555555 } /* Generic.Prompt */
.highlight .gs { font-weight: bold } /* Generic.Strong */
.highlight .gu { color: #666666 } /* Generic.Subheading */
.highlight .gt { color: #aa0000 } /* Generic.Traceback */
.highlight .kc { color: #008800; font-weight: bold } /* Keyword.Constant */
.highlight .kd { color: #008800; font-weight: bold } /* Keyword.Declaration */
.highlight .kn { color: #008800; font-weight: bold } /* Keyword.Namespace */
.highlight .kp { color: #008800 } /* Keyword.Pseudo */
.highlight .kr { color: #008800; font-weight: bold } /* Keyword.Reserved */
.highlight .kt { color: #888888; font-weight: bold } /* Keyword.Type */
.highlight .m { color: #0000DD; font-weight: bold } /* Literal.Number */
.highlight .s { color: #dd2200; background-color: #fff0f0 } /* Literal.String */
.highlight .na { color: #336699 } /* Name.Attribute */
.highlight .nb { color: #003388 } /* Name.Builtin */
.highlight .nc { color: #bb0066; font-weight: bold } /* Name.Class */
.highlight .no { color: #003366; font-weight: bold } /* Name.Constant */
.highlight .nd { color: #555555 } /* Name.Decorator */
.highlight .ne { color: #bb0066; font-weight: bold } /* Name.Exception */
.highlight .nf { color: #0066bb; font-weight: bold } /* Name.Function */
.highlight .nl { color: #336699; font-style: italic } /* Name.Label */
.highlight .nn { color: #bb0066; font-weight: bold } /* Name.Namespace */
.highlight .py { color: #336699; font-weight: bold } /* Name.Property */
.highlight .nt { color: #bb0066; font-weight: bold } /* Name.Tag */
.highlight .nv { color: #336699 } /* Name.Variable */
.highlight .ow { color: #008800 } /* Operator.Word */
.highlight .w { color: #bbbbbb } /* Text.Whitespace */
.highlight .mb { color: #0000DD; font-weight: bold } /* Literal.Number.Bin */
.highlight .mf { color: #0000DD; font-weight: bold } /* Literal.Number.Float */
.highlight .mh { color: #0000DD; font-weight: bold } /* Literal.Number.Hex */
.highlight .mi { color: #0000DD; font-weight: bold } /* Literal.Number.Integer */
.highlight .mo { color: #0000DD; font-weight: bold } /* Literal.Number.Oct */
.highlight .sa { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Affix */
.highlight .sb { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Backtick */
.highlight .sc { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Char */
.highlight .dl { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Delimiter */
.highlight .sd { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Doc */
.highlight .s2 { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Double */
.highlight .se { color: #0044dd; background-color: #fff0f0 } /* Literal.String.Escape */
.highlight .sh { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Heredoc */
.highlight .si { color: #3333bb; background-color: #fff0f0 } /* Literal.String.Interpol */
.highlight .sx { color: #22bb22; background-color: #f0fff0 } /* Literal.String.Other */
.highlight .sr { color: #008800; background-color: #fff0ff } /* Literal.String.Regex */
.highlight .s1 { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Single */
.highlight .ss { color: #aa6600; background-color: #fff0f0 } /* Literal.String.Symbol */
.highlight .bp { color: #003388 } /* Name.Builtin.Pseudo */
.highlight .fm { color: #0066bb; font-weight: bold } /* Name.Function.Magic */
.highlight .vc { color: #336699 } /* Name.Variable.Class */
.highlight .vg { color: #dd7700 } /* Name.Variable.Global */
.highlight .vi { color: #3333bb } /* Name.Variable.Instance */
.highlight .vm { color: #336699 } /* Name.Variable.Magic */
.highlight .il { color: #0000DD; font-weight: bold } /* Literal.Number.Integer.Long */
// ---------------------------------------

module \$__ABC_DPR16X4_COMB (input [3:0] A, S, output [3:0] Y);
    assign Y = A;
endmodule
'#n202'>202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499
\chapter{Internal Cell Library}
\label{chapter:celllib}

Most of the passes in Yosys operate on netlists, i.e.~they only care about the RTLIL::Wire and RTLIL::Cell
objects in an RTLIL::Module. This chapter discusses the cell types used by Yosys to represent a behavioural
design internally.

This chapter is split in two parts. In the first part the internal RTL cells are covered. These cells
are used to represent the design on a coarse grain level. Like in the original HDL code on this level the
cells operate on vectors of signals and complex cells like adders exist. In the second part the internal
gate cells are covered. These cells are used to represent the design on a fine-grain gate-level. All cells
from this category operate on single bit signals.

\section{RTL Cells}

Most of the RTL cells closely resemble the operators available in HDLs such as
Verilog or VHDL. Therefore Verilog operators are used in the following sections
to define the behaviour of the RTL cells.

Note that all RTL cells have parameters indicating the size of inputs and outputs. When
passes modify RTL cells they must always keep the values of these parameters in sync with
the size of the signals connected to the inputs and outputs.

Simulation models for the RTL cells can be found in the file {\tt techlibs/common/simlib.v} in the Yosys
source tree.

\subsection{Unary Operators}

All unary RTL cells have one input port \B{A} and one output port \B{Y}. They also
have the following parameters:

\begin{itemize}
\item \B{A\_SIGNED} \\
Set to a non-zero value if the input \B{A} is signed and therefore should be sign-extended
when needed.

\item \B{A\_WIDTH} \\
The width of the input port \B{A}.

\item \B{Y\_WIDTH} \\
The width of the output port \B{Y}.
\end{itemize}

Table~\ref{tab:CellLib_unary} lists all cells for unary RTL operators.

\begin{table}[t!]
\hfil
\begin{tabular}{ll}
Verilog & Cell Type \\
\hline
\lstinline[language=Verilog]; Y =  ~A ; & {\tt \$not} \\
\lstinline[language=Verilog]; Y =  +A ; & {\tt \$pos} \\
\lstinline[language=Verilog]; Y =  -A ; & {\tt \$neg} \\
\hline
\lstinline[language=Verilog]; Y =  &A ; & {\tt \$reduce\_and} \\
\lstinline[language=Verilog]; Y =  |A ; & {\tt \$reduce\_or} \\
\lstinline[language=Verilog]; Y =  ^A ; & {\tt \$reduce\_xor} \\
\lstinline[language=Verilog]; Y = ~^A ; & {\tt \$reduce\_xnor} \\
\hline
\lstinline[language=Verilog]; Y =  |A ; & {\tt \$reduce\_bool} \\
\lstinline[language=Verilog]; Y =  !A ; & {\tt \$logic\_not}
\end{tabular}
\caption{Cell types for unary operators with their corresponding Verilog expressions.}
\label{tab:CellLib_unary}
\end{table}

Note that {\tt \$reduce\_or} and {\tt \$reduce\_bool} actually represent the same
logic function. But the HDL frontends generate them in different situations. A
{\tt \$reduce\_or} cell is generated when the prefix {\tt |} operator is being used. A
{\tt \$reduce\_bool} cell is generated when a bit vector is used as a condition in
an {\tt if}-statement or {\tt ?:}-expression.

\subsection{Binary Operators}

All binary RTL cells have two input ports \B{A} and \B{B} and one output port \B{Y}. They
also have the following parameters:

\begin{itemize}
\item \B{A\_SIGNED} \\
Set to a non-zero value if the input \B{A} is signed and therefore should be sign-extended
when needed.

\item \B{A\_WIDTH} \\
The width of the input port \B{A}.

\item \B{B\_SIGNED} \\
Set to a non-zero value if the input \B{B} is signed and therefore should be sign-extended
when needed.

\item \B{B\_WIDTH} \\
The width of the input port \B{B}.

\item \B{Y\_WIDTH} \\
The width of the output port \B{Y}.
\end{itemize}

Table~\ref{tab:CellLib_binary} lists all cells for binary RTL operators.

\subsection{Multiplexers}

Multiplexers are generated by the Verilog HDL frontend for {\tt
?:}-expressions. Multiplexers are also generated by the {\tt proc} pass to map the decision trees
from RTLIL::Process objects to logic.

The simplest multiplexer cell type is {\tt \$mux}. Cells of this type have a \B{WIDTH} parameter
and data inputs \B{A} and \B{B} and a data output \B{Y}, all of the specified width. This cell also
has a single bit control input \B{S}. If \B{S} is 0 the value from the \B{A} input is sent to
the output, if it is 1 the value from the \B{B} input is sent to the output. So the {\tt \$mux}
cell implements the function \lstinline[language=Verilog]; Y = S ? B : A;.

The {\tt \$pmux} cell is used to multiplex between many inputs using a one-hot select signal. Cells
of this type have a \B{WIDTH} and a \B{S\_WIDTH} parameter and inputs \B{A}, \B{B}, and \B{S} and
an output \B{Y}. The \B{S} input is \B{S\_WIDTH} bits wide. The \B{A} input and the output are both
\B{WIDTH} bits wide and the \B{B} input is \B{WIDTH}*\B{S\_WIDTH} bits wide. When all bits of
\B{S} are zero, the value from \B{A} input is sent to the output. If the $n$'th bit from \B{S} is
set, the value $n$'th \B{WIDTH} bits wide slice of the \B{B} input is sent to the output. When more
than one bit from \B{S} is set the output is undefined. Cells of this type are used to model
``parallel cases'' (defined by using the {\tt parallel\_case} attribute or detected by
an optimization).

The {\tt \$tribuf} cell is used to implement tristate logic. Cells of this type have a \B{WIDTH}
parameter and inputs \B{A} and \B{EN} and an output \B{Y}. The \B{A} input and \B{Y} output are
\B{WIDTH} bits wide, and the \B{EN} input is one bit wide. When \B{EN} is 0, the output \B{Y}
is not driven. When \B{EN} is 1, the value from \B{A} input is sent to the \B{Y} output. Therefore,
the {\tt \$tribuf} cell implements the function \lstinline[language=Verilog]; Y = EN ? A : 'bz;.

Behavioural code with cascaded {\tt if-then-else}- and {\tt case}-statements
usually results in trees of multiplexer cells. Many passes (from various
optimizations to FSM extraction) heavily depend on these multiplexer trees to
understand dependencies between signals. Therefore optimizations should not
break these multiplexer trees (e.g.~by replacing a multiplexer between a
calculated signal and a constant zero with an {\tt \$and} gate).

\begin{table}[t!]
\hfil
\begin{tabular}[t]{ll}
Verilog & Cell Type \\
\hline
\lstinline[language=Verilog]; Y = A  & B; & {\tt \$and} \\
\lstinline[language=Verilog]; Y = A  | B; & {\tt \$or} \\
\lstinline[language=Verilog]; Y = A  ^ B; & {\tt \$xor} \\
\lstinline[language=Verilog]; Y = A ~^ B; & {\tt \$xnor} \\
\hline
\lstinline[language=Verilog]; Y = A << B; & {\tt \$shl} \\
\lstinline[language=Verilog]; Y = A >> B; & {\tt \$shr} \\
\lstinline[language=Verilog]; Y = A <<< B; & {\tt \$sshl} \\
\lstinline[language=Verilog]; Y = A >>> B; & {\tt \$sshr} \\
\hline
\lstinline[language=Verilog]; Y = A && B; & {\tt \$logic\_and} \\
\lstinline[language=Verilog]; Y = A || B; & {\tt \$logic\_or} \\
\hline
\lstinline[language=Verilog]; Y = A === B; & {\tt \$eqx} \\
\lstinline[language=Verilog]; Y = A !== B; & {\tt \$nex} \\
\end{tabular}
\hfil
\begin{tabular}[t]{ll}
Verilog & Cell Type \\
\hline
\lstinline[language=Verilog]; Y = A <  B; & {\tt \$lt} \\
\lstinline[language=Verilog]; Y = A <= B; & {\tt \$le} \\
\lstinline[language=Verilog]; Y = A == B; & {\tt \$eq} \\
\lstinline[language=Verilog]; Y = A != B; & {\tt \$ne} \\
\lstinline[language=Verilog]; Y = A >= B; & {\tt \$ge} \\
\lstinline[language=Verilog]; Y = A >  B; & {\tt \$gt} \\
\hline
\lstinline[language=Verilog]; Y = A  + B; & {\tt \$add} \\
\lstinline[language=Verilog]; Y = A  - B; & {\tt \$sub} \\
\lstinline[language=Verilog]; Y = A  * B; & {\tt \$mul} \\
\lstinline[language=Verilog]; Y = A  / B; & {\tt \$div} \\
\lstinline[language=Verilog]; Y = A  % B; & {\tt \$mod} \\
\lstinline[language=Verilog]; Y = A ** B; & {\tt \$pow} \\
\end{tabular}
\caption{Cell types for binary operators with their corresponding Verilog expressions.}
\label{tab:CellLib_binary}
\end{table}

\subsection{Registers}

D-Type Flip-Flops are represented by {\tt \$dff} cells. These cells have a clock port \B{CLK},
an input port \B{D} and an output port \B{Q}. The following parameters are available for \$dff
cells:

\begin{itemize}
\item \B{WIDTH} \\
The width of input \B{D} and output \B{Q}.

\item \B{CLK\_POLARITY} \\
Clock is active on the positive edge if this parameter has the value {\tt 1'b1} and on the negative
edge if this parameter is {\tt 1'b0}.
\end{itemize}

D-Type Flip-Flops with asynchronous resets are represented by {\tt \$adff} cells. As the {\tt \$dff}
cells they have \B{CLK}, \B{D} and \B{Q} ports. In addition they also have a single-bit \B{ARST}
input port for the reset pin and the following additional two parameters:

\begin{itemize}
\item \B{ARST\_POLARITY} \\
The asynchronous reset is high-active if this parameter has the value {\tt 1'b1} and low-active
if this parameter is {\tt 1'b0}.

\item \B{ARST\_VALUE} \\
The state of \B{Q} will be set to this value when the reset is active.
\end{itemize}

Note that the {\tt \$adff} cell can only be used when the reset value is constant.

\begin{sloppypar}
Usually these cells are generated by the {\tt proc} pass using the information
in the designs RTLIL::Process objects.
\end{sloppypar}

\begin{fixme}
Add information about {\tt \$sr} cells (set-reset flip-flops) and d-type latches.
\end{fixme}

\subsection{Memories}
\label{sec:memcells}

Memories are either represented using RTLIL::Memory objects, {\tt \$memrd}, {\tt \$memwr}, and {\tt \$meminit}
cells, or by {\tt \$mem} cells alone.

In the first alternative the RTLIL::Memory objects hold the general metadata for the memory (bit width,
size in number of words, etc.) and for each port a {\tt \$memrd} (read port) or {\tt \$memwr} (write port)
cell is created. Having individual cells for read and write ports has the advantage that they can be
consolidated using resource sharing passes. In some cases this drastically reduces the number of required
ports on the memory cell. In this alternative, memory initialization data is represented by {\tt \$meminit} cells,
which allow delaying constant folding for initialization addresses and data until after the frontend finishes.

The {\tt \$memrd} cells have a clock input \B{CLK}, an enable input \B{EN}, an
address input \B{ADDR}, and a data output \B{DATA}. They also have the
following parameters:

\begin{itemize}
\item \B{MEMID} \\
The name of the RTLIL::Memory object that is associated with this read port.

\item \B{ABITS} \\
The number of address bits (width of the \B{ADDR} input port).

\item \B{WIDTH} \\
The number of data bits (width of the \B{DATA} output port).

\item \B{CLK\_ENABLE} \\
When this parameter is non-zero, the clock is used. Otherwise this read port is asynchronous and
the \B{CLK} input is not used.

\item \B{CLK\_POLARITY} \\
Clock is active on the positive edge if this parameter has the value {\tt 1'b1} and on the negative
edge if this parameter is {\tt 1'b0}.

\item \B{TRANSPARENT} \\
If this parameter is set to {\tt 1'b1}, a read and write to the same address in the same cycle will
return the new value. Otherwise the old value is returned.
\end{itemize}

The {\tt \$memwr} cells have a clock input \B{CLK}, an enable input \B{EN} (one
enable bit for each data bit), an address input \B{ADDR} and a data input
\B{DATA}. They also have the following parameters:

\begin{itemize}
\item \B{MEMID} \\
The name of the RTLIL::Memory object that is associated with this write port.

\item \B{ABITS} \\
The number of address bits (width of the \B{ADDR} input port).

\item \B{WIDTH} \\
The number of data bits (width of the \B{DATA} output port).

\item \B{CLK\_ENABLE} \\
When this parameter is non-zero, the clock is used. Otherwise this write port is asynchronous and
the \B{CLK} input is not used.

\item \B{CLK\_POLARITY} \\
Clock is active on positive edge if this parameter has the value {\tt 1'b1} and on the negative
edge if this parameter is {\tt 1'b0}.

\item \B{PRIORITY} \\
The cell with the higher integer value in this parameter wins a write conflict.
\end{itemize}

The {\tt \$meminit} cells have an address input \B{ADDR} and a data input \B{DATA}, with the width
of the \B{DATA} port equal to \B{WIDTH} parameter times \B{WORDS} parameter. Both of the inputs
must resolve to a constant for synthesis to succeed.

\begin{itemize}
\item \B{MEMID} \\
The name of the RTLIL::Memory object that is associated with this initialization cell.

\item \B{ABITS} \\
The number of address bits (width of the \B{ADDR} input port).

\item \B{WIDTH} \\
The number of data bits per memory location.

\item \B{WORDS} \\
The number of consecutive memory locations initialized by this cell.

\item \B{PRIORITY} \\
The cell with the higher integer value in this parameter wins an initialization conflict.
\end{itemize}

The HDL frontend models a memory using RTLIL::Memory objects and asynchronous
{\tt \$memrd} and {\tt \$memwr} cells. The {\tt memory} pass (i.e.~its various sub-passes) migrates
{\tt \$dff} cells into the {\tt \$memrd} and {\tt \$memwr} cells making them synchronous, then
converts them to a single {\tt \$mem} cell and (optionally) maps this cell type
to {\tt \$dff} cells for the individual words and multiplexer-based address decoders for the read and
write interfaces. When the last step is disabled or not possible, a {\tt \$mem} cell is left in the design.

The {\tt \$mem} cell provides the following parameters:

\begin{itemize}
\item \B{MEMID} \\
The name of the original RTLIL::Memory object that became this {\tt \$mem} cell.

\item \B{SIZE} \\
The number of words in the memory.

\item \B{ABITS} \\
The number of address bits.

\item \B{WIDTH} \\
The number of data bits per word.

\item \B{INIT} \\
The initial memory contents.

\item \B{RD\_PORTS} \\
The number of read ports on this memory cell.

\item \B{RD\_CLK\_ENABLE} \\
This parameter is \B{RD\_PORTS} bits wide, containing a clock enable bit for each read port.

\item \B{RD\_CLK\_POLARITY} \\
This parameter is \B{RD\_PORTS} bits wide, containing a clock polarity bit for each read port.

\item \B{RD\_TRANSPARENT} \\
This parameter is \B{RD\_PORTS} bits wide, containing a transparent bit for each read port.

\item \B{WR\_PORTS} \\
The number of write ports on this memory cell.

\item \B{WR\_CLK\_ENABLE} \\
This parameter is \B{WR\_PORTS} bits wide, containing a clock enable bit for each write port.

\item \B{WR\_CLK\_POLARITY} \\
This parameter is \B{WR\_PORTS} bits wide, containing a clock polarity bit for each write port.
\end{itemize}

The {\tt \$mem} cell has the following ports:

\begin{itemize}
\item \B{RD\_CLK} \\
This input is \B{RD\_PORTS} bits wide, containing all clock signals for the read ports.

\item \B{RD\_EN} \\
This input is \B{RD\_PORTS} bits wide, containing all enable signals for the read ports.

\item \B{RD\_ADDR} \\
This input is \B{RD\_PORTS}*\B{ABITS} bits wide, containing all address signals for the read ports.

\item \B{RD\_DATA} \\
This input is \B{RD\_PORTS}*\B{WIDTH} bits wide, containing all data signals for the read ports.

\item \B{WR\_CLK} \\
This input is \B{WR\_PORTS} bits wide, containing all clock signals for the write ports.

\item \B{WR\_EN} \\
This input is \B{WR\_PORTS}*\B{WIDTH} bits wide, containing all enable signals for the write ports.

\item \B{WR\_ADDR} \\
This input is \B{WR\_PORTS}*\B{ABITS} bits wide, containing all address signals for the write ports.

\item \B{WR\_DATA} \\
This input is \B{WR\_PORTS}*\B{WIDTH} bits wide, containing all data signals for the write ports.
\end{itemize}

The {\tt memory\_collect} pass can be used to convert discrete {\tt \$memrd}, {\tt \$memwr}, and {\tt \$meminit} cells
belonging to the same memory to a single {\tt \$mem} cell, whereas the {\tt memory\_unpack} pass performs the inverse operation.
The {\tt memory\_dff} pass can combine asynchronous memory ports that are fed by or feeding registers into synchronous memory ports.
The {\tt memory\_bram} pass can be used to recognize {\tt \$mem} cells that can be implemented with a block RAM resource on an FPGA.
The {\tt memory\_map} pass can be used to implement {\tt \$mem} cells as basic logic: word-wide DFFs and address decoders.

\subsection{Finite State Machines}

\begin{fixme}
Add a brief description of the {\tt \$fsm} cell type.
\end{fixme}

\section{Gates}
\label{sec:celllib_gates}

For gate level logic networks, fixed function single bit cells are used that do
not provide any parameters.

Simulation models for these cells can be found in the file {\tt techlibs/common/simcells.v} in the Yosys
source tree.

\begin{table}[t]
\hfil
\begin{tabular}[t]{ll}
Verilog & Cell Type \\
\hline
\lstinline[language=Verilog]; Y = ~A;    & {\tt \$\_NOT\_} \\
\lstinline[language=Verilog]; Y = A & B; & {\tt \$\_AND\_} \\
\lstinline[language=Verilog]; Y = ~(A & B); & {\tt \$\_NAND\_} \\
\lstinline[language=Verilog]; Y = A & ~B; & {\tt \$\_ANDNOT\_} \\
\lstinline[language=Verilog]; Y = A | B; & {\tt \$\_OR\_} \\
\lstinline[language=Verilog]; Y = ~(A | B); & {\tt \$\_NOR\_} \\
\lstinline[language=Verilog]; Y = A | ~B; & {\tt \$\_ORNOT\_} \\
\lstinline[language=Verilog]; Y = A ^ B; & {\tt \$\_XOR\_} \\
\lstinline[language=Verilog]; Y = ~(A ^ B); & {\tt \$\_XNOR\_} \\
\lstinline[language=Verilog]; Y = S ? B : A; & {\tt \$\_MUX\_} \\
\lstinline[language=Verilog]; Y = EN ? A : 'bz; & {\tt \$\_TBUF\_} \\
\hline
\lstinline[language=Verilog]; always @(negedge C) Q <= D; & {\tt \$\_DFF\_N\_} \\
\lstinline[language=Verilog]; always @(posedge C) Q <= D; & {\tt \$\_DFF\_P\_} \\
\end{tabular}
\hfil
\begin{tabular}[t]{llll}
$ClkEdge$ & $RstLvl$ & $RstVal$ & Cell Type \\
\hline
\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & {\tt \$\_DFF\_NN0\_} \\
\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & {\tt \$\_DFF\_NN1\_} \\
\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & {\tt \$\_DFF\_NP0\_} \\
\lstinline[language=Verilog];negedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & {\tt \$\_DFF\_NP1\_} \\
\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];0; & {\tt \$\_DFF\_PN0\_} \\
\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];0; & \lstinline[language=Verilog];1; & {\tt \$\_DFF\_PN1\_} \\
\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];0; & {\tt \$\_DFF\_PP0\_} \\
\lstinline[language=Verilog];posedge; & \lstinline[language=Verilog];1; & \lstinline[language=Verilog];1; & {\tt \$\_DFF\_PP1\_} \\
\end{tabular}
\caption{Cell types for gate level logic networks}
\label{tab:CellLib_gates}
\end{table}

Table~\ref{tab:CellLib_gates} lists all cell types used for gate level logic. The cell types
{\tt \$\_NOT\_}, {\tt \$\_AND\_}, {\tt \$\_NAND\_}, {\tt \$\_ANDNOT\_}, {\tt \$\_OR\_}, {\tt \$\_NOR\_},
{\tt \$\_ORNOT\_}, {\tt \$\_XOR\_}, {\tt \$\_XNOR\_} and {\tt \$\_MUX\_} are used to model combinatorial logic.
The cell type {\tt \$\_TBUF\_} is used to model tristate logic.
The cell types {\tt \$\_DFF\_N\_} and {\tt \$\_DFF\_P\_} represent d-type flip-flops.

The cell types {\tt \$\_DFF\_NN0\_}, {\tt \$\_DFF\_NN1\_}, {\tt \$\_DFF\_NP0\_}, {\tt \$\_DFF\_NP1\_},
{\tt \$\_DFF\_PN0\_}, {\tt \$\_DFF\_PN1\_}, {\tt \$\_DFF\_PP0\_} and {\tt \$\_DFF\_PP1\_} implement
d-type flip-flops with asynchronous resets. The values in the table for these cell types relate to the
following Verilog code template, where \lstinline[mathescape,language=Verilog];$RstEdge$; is \lstinline[language=Verilog];posedge;
if \lstinline[mathescape,language=Verilog];$RstLvl$; if \lstinline[language=Verilog];1;, and \lstinline[language=Verilog];negedge;
otherwise.

\begin{lstlisting}[mathescape,language=Verilog]
	always @($ClkEdge$ C, $RstEdge$ R)
		if (R == $RstLvl$)
			Q <= $RstVal$;
		else
			Q <= D;
\end{lstlisting}

In most cases gate level logic networks are created from RTL networks using the {\tt techmap} pass. The flip-flop cells
from the gate level logic network can be mapped to physical flip-flop cells from a Liberty file using the {\tt dfflibmap}
pass. The combinatorial logic cells can be mapped to physical cells from a Liberty file via ABC \citeweblink{ABC}
using the {\tt abc} pass.

\begin{fixme}
Add information about {\tt \$assert}, {\tt \$assume}, {\tt \$live}, {\tt \$fair}, {\tt \$cover}, {\tt \$equiv},
{\tt \$initstate}, {\tt \$anyconst}, {\tt \$anyseq}, {\tt \$allconst}, {\tt \$allseq} cells.
\end{fixme}

\begin{fixme}
Add information about {\tt \$specify2}, {\tt \$specify3}, and {\tt \$specrule} cells.
\end{fixme}

\begin{fixme}
Add information about {\tt \$slice} and {\tt \$concat} cells.
\end{fixme}

\begin{fixme}
Add information about {\tt \$lut} and {\tt \$sop} cells.
\end{fixme}

\begin{fixme}
Add information about {\tt \$alu}, {\tt \$macc}, {\tt \$fa}, and {\tt \$lcu} cells.
\end{fixme}

\begin{fixme}
Add information about {\tt \$ff} and {\tt \$\_FF\_} cells.
\end{fixme}

\begin{fixme}
Add information about {\tt \$dffe}, {\tt \$dffsr}, {\tt \$dlatch}, and {\tt \$dlatchsr} cells.
\end{fixme}

\begin{fixme}
Add information about {\tt \$\_DFFE\_??\_}, {\tt \$\_DFFSR\_???\_}, {\tt \$\_DLATCH\_?\_}, and {\tt \$\_DLATCHSR\_???\_} cells.
\end{fixme}

\begin{fixme}
Add information about {\tt \$\_AOI3\_}, {\tt \$\_OAI3\_}, {\tt \$\_AOI4\_}, {\tt \$\_OAI4\_}, and {\tt \$\_NMUX\_} cells.
\end{fixme}