From a6641da73cdc6704166ba484d98d1f0edfa23773 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Tue, 9 Apr 2024 12:24:26 +1200 Subject: [PATCH 01/68] Docs: Initial version of cell_ref autogen --- docs/.gitignore | 1 + docs/source/appendix.rst | 1 + docs/source/cell_ref.rst | 12 ++++++++ kernel/register.cc | 60 ++++++++++++++++++++++++++++++++++++++-- 4 files changed, 72 insertions(+), 2 deletions(-) create mode 100644 docs/source/cell_ref.rst diff --git a/docs/.gitignore b/docs/.gitignore index 65bbcdeaeb8..78a1f48e1a0 100644 --- a/docs/.gitignore +++ b/docs/.gitignore @@ -1,5 +1,6 @@ /build/ /source/cmd +/source/cell /source/generated /source/_images/**/*.log /source/_images/**/*.aux diff --git a/docs/source/appendix.rst b/docs/source/appendix.rst index 0b0a2d15b5d..9e8b8be34f3 100644 --- a/docs/source/appendix.rst +++ b/docs/source/appendix.rst @@ -16,3 +16,4 @@ Appendix :includehidden: cmd_ref + cell_ref diff --git a/docs/source/cell_ref.rst b/docs/source/cell_ref.rst new file mode 100644 index 00000000000..ddf66812d6d --- /dev/null +++ b/docs/source/cell_ref.rst @@ -0,0 +1,12 @@ +.. _cell_ref: + +================================================================================ +Internal cell reference +================================================================================ + +.. toctree:: + :caption: Internal cell reference + :maxdepth: 1 + :glob: + + /cell/* diff --git a/kernel/register.cc b/kernel/register.cc index 80bc44901b2..17bfb079ad4 100644 --- a/kernel/register.cc +++ b/kernel/register.cc @@ -771,7 +771,7 @@ struct HelpPass : public Pass { log(" help + .... print verilog code for given cell type\n"); log("\n"); } - void write_rst(std::string cmd, std::string title, std::string text) + void write_cmd_rst(std::string cmd, std::string title, std::string text) { FILE *f = fopen(stringf("docs/source/cmd/%s.rst", cmd.c_str()).c_str(), "wt"); // make header @@ -864,6 +864,57 @@ struct HelpPass : public Pass { } fclose(f); } + void write_cell_rst(std::string cell, std::string help, std::string code) + { + // open + string safe_name = cell.substr(1); + FILE *f = fopen(stringf("docs/source/cell/%s.rst", safe_name.c_str()).c_str(), "wt"); + + // make header + string short_help = ""; + string long_help = ""; + string title_line = cell; + for (auto line : split_tokens(help, "\n")) { + if (short_help == "") { + size_t first_pos = line.find_first_not_of(" \t"); + // skip empty lines + if (first_pos == string::npos) continue; + if (line.find(cell.c_str()) == string::npos) { + // strip leading/trailing space + size_t last_pos = line.find_last_not_of(" \t"); + short_help = line.substr(first_pos, last_pos - first_pos +1); + // skip missing help message + if (short_help == "No help message for this cell type found.") { + long_help += line; + long_help += "\n"; + } else { + title_line = stringf("%s - %s", cell.c_str(), short_help.c_str()); + } + } + } else { + long_help += line; + long_help += "\n"; + } + } + string underline = "\n"; + underline.insert(0, title_line.length(), '='); + fprintf(f, "%s\n", title_line.c_str()); + fprintf(f, "%s\n", underline.c_str()); + + // help text + fprintf(f, "%s\n", long_help.c_str()); + + // source code + fprintf(f, ".. code:: verilog\n\n"); + std::stringstream ss; + ss << code; + for (std::string line; std::getline(ss, line, '\n');) { + fprintf(f, "\t%s\n", line.c_str()); + } + + // close + fclose(f); + } void execute(std::vector args, RTLIL::Design*) override { if (args.size() == 1) { @@ -917,7 +968,12 @@ struct HelpPass : public Pass { log("\n"); } log_streams.pop_back(); - write_rst(it.first, it.second->short_help, buf.str()); + write_cmd_rst(it.first, it.second->short_help, buf.str()); + } + } + else if (args[1] == "-write-rst-cells-manual") { + for (auto &it : cell_help_messages.cell_help) { + write_cell_rst(it.first, it.second, cell_help_messages.cell_code.at(it.first + "+")); } } else if (pass_register.count(args[1])) { From 6bbe763845023c55f66c270cab347d54a989836f Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Tue, 9 Apr 2024 15:33:50 +1200 Subject: [PATCH 02/68] Docs: Put cell library help strings into a struct Allows for more expressive code when constructing help messages for cells. Will also move extra logic in parsing help strings into the initial python parse instead of doing it in the C++ at export time. --- kernel/register.cc | 43 +++++++++++++++++++------ techlibs/common/cellhelp.py | 64 +++++++++++++++++++++++++------------ 2 files changed, 78 insertions(+), 29 deletions(-) diff --git a/kernel/register.cc b/kernel/register.cc index 17bfb079ad4..85d3d4748e8 100644 --- a/kernel/register.cc +++ b/kernel/register.cc @@ -747,9 +747,25 @@ void Backend::backend_call(RTLIL::Design *design, std::ostream *f, std::string f design->selection_stack.pop_back(); } +struct SimHelper { + string name; + inline string filesafe_name() { + if (name.at(0) == '$') + return name.substr(1); + else + return name; + } + string short_desc; + string ports; + string desc; + string code; + string ver; +}; + static struct CellHelpMessages { - dict cell_help, cell_code; + dict cell_help, cell_code; CellHelpMessages() { + SimHelper tempCell; #include "techlibs/common/simlib_help.inc" #include "techlibs/common/simcells_help.inc" cell_help.sort(); @@ -947,9 +963,8 @@ struct HelpPass : public Pass { else if (args[1] == "-cells") { log("\n"); for (auto &it : cell_help_messages.cell_help) { - string line = split_tokens(it.second, "\n").at(0); - string cell_name = next_token(line); - log(" %-15s %s\n", cell_name.c_str(), line.c_str()); + SimHelper help_cell = it.second; + log(" %-15s %s\n", help_cell.name.c_str(), help_cell.ports.c_str()); } log("\n"); log("Type 'help ' for more information on a cell type.\n"); @@ -973,7 +988,7 @@ struct HelpPass : public Pass { } else if (args[1] == "-write-rst-cells-manual") { for (auto &it : cell_help_messages.cell_help) { - write_cell_rst(it.first, it.second, cell_help_messages.cell_code.at(it.first + "+")); + write_cell_rst(it.first, it.second.desc, it.second.code); } } else if (pass_register.count(args[1])) { @@ -985,13 +1000,23 @@ struct HelpPass : public Pass { } } else if (cell_help_messages.cell_help.count(args[1])) { - log("%s", cell_help_messages.cell_help.at(args[1]).c_str()); - log("Run 'help %s+' to display the Verilog model for this cell type.\n", args[1].c_str()); - log("\n"); + SimHelper help_cell = cell_help_messages.cell_help.at(args[1]); + if (help_cell.ver == "2") { + log("\n %s %s\n", help_cell.name.c_str(), help_cell.ports.c_str()); + log("\n%s\n", help_cell.short_desc.c_str()); + log("%s\n", help_cell.desc.c_str()); + log("Run 'help %s+' to display the Verilog model for this cell type.\n", args[1].c_str()); + log("\n"); + } else { + log("%s\n", help_cell.desc.c_str()); + log("Run 'help %s+' to display the Verilog model for this cell type.\n", args[1].c_str()); + log("\n"); + } } else if (cell_help_messages.cell_code.count(args[1])) { + SimHelper help_cell = cell_help_messages.cell_code.at(args[1]); log("\n"); - log("%s", cell_help_messages.cell_code.at(args[1]).c_str()); + log("%s\n", help_cell.code.c_str()); } else log("No such command or cell type: %s\n", args[1].c_str()); diff --git a/techlibs/common/cellhelp.py b/techlibs/common/cellhelp.py index 5c44cb8022b..8d0d7d757fb 100644 --- a/techlibs/common/cellhelp.py +++ b/techlibs/common/cellhelp.py @@ -1,34 +1,58 @@ #!/usr/bin/env python3 +from __future__ import annotations import fileinput import json -current_help_msg = [] -current_module_code = [] -current_module_name = None -current_module_signature = None +class SimHelper: + name: str = "" + short_desc: str = "" + ports: str = "" + desc: list[str] + code: list[str] + ver: str = "1" -def print_current_cell(): - print("cell_help[\"%s\"] = %s;" % (current_module_name, "\n".join([json.dumps(line) for line in current_help_msg]))) - print("cell_code[\"%s+\"] = %s;" % (current_module_name, "\n".join([json.dumps(line) for line in current_module_code]))) + def __init__(self) -> None: + self.desc = [] + + def __str__(self) -> str: + val = "tempCell = {\n" + val += f' {json.dumps(self.name)},\n' + val += f' {json.dumps(self.short_desc)},\n' + val += f' {json.dumps(self.ports)},\n' + val += ' ' + json.dumps("\n".join(self.desc)) + ',\n' + val += ' ' + json.dumps("\n".join(self.code)) + ',\n' + val += f' {json.dumps(self.ver)},\n' + val += "};\n" + val += f'cell_help[{json.dumps(self.name)}] = tempCell;' + val += "\n" + val += f'cell_code[{json.dumps(self.name + "+")}] = tempCell;' + return val + +simHelper = SimHelper() for line in fileinput.input(): + line = line.rstrip() + # special comments if line.startswith("//-"): - current_help_msg.append(line[4:] if len(line) > 4 else "\n") + simHelper.desc.append(line[4:] if len(line) > 4 else "") + elif line.startswith("//* "): + _, key, val = line.split(maxsplit=2) + setattr(simHelper, key, val) + + # code parsing if line.startswith("module "): - current_module_name = line.split()[1].strip("\\") - current_module_signature = " ".join(line.replace("\\", "").replace(";", "").split()[1:]) - current_module_code = [] + clean_line = line[7:].replace("\\", "").replace(";", "") + simHelper.name, simHelper.ports = clean_line.split(maxsplit=1) + simHelper.code = [] elif not line.startswith("endmodule"): line = " " + line - current_module_code.append(line.replace("\t", " ")) + try: + simHelper.code.append(line.replace("\t", " ")) + except AttributeError: + # no module definition, ignore line + pass if line.startswith("endmodule"): - if len(current_help_msg) == 0: - current_help_msg.append("\n") - current_help_msg.append(" %s\n" % current_module_signature) - current_help_msg.append("\n") - current_help_msg.append("No help message for this cell type found.\n") - current_help_msg.append("\n") - print_current_cell() - current_help_msg = [] + print(simHelper) + simHelper = SimHelper() From 600149a824f85808fb8231f187d848321d36bb46 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Tue, 9 Apr 2024 16:12:41 +1200 Subject: [PATCH 03/68] Docs: Add back message for empty help --- techlibs/common/cellhelp.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/techlibs/common/cellhelp.py b/techlibs/common/cellhelp.py index 8d0d7d757fb..4d40b73c071 100644 --- a/techlibs/common/cellhelp.py +++ b/techlibs/common/cellhelp.py @@ -53,6 +53,8 @@ def __str__(self) -> str: # no module definition, ignore line pass if line.startswith("endmodule"): + if not simHelper.desc: + simHelper.desc.append("No help message for this cell type found.\n") print(simHelper) simHelper = SimHelper() From 4662476ec80abec1ec56659bb4c500a1c6adb8d7 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Tue, 9 Apr 2024 16:13:10 +1200 Subject: [PATCH 04/68] Docs: Test $alu with v2 help format --- techlibs/common/simlib.v | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/techlibs/common/simlib.v b/techlibs/common/simlib.v index 60f98af2838..71bb58c415f 100644 --- a/techlibs/common/simlib.v +++ b/techlibs/common/simlib.v @@ -621,15 +621,12 @@ endmodule // -------------------------------------------------------- -// |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| -//- -//- $alu (A, B, CI, BI, X, Y, CO) -//- -//- Arithmetic logic unit. +//* ver 2 +//* short_desc Arithmetic logic unit //- A building block supporting both binary addition/subtraction operations, and //- indirectly, comparison operations. //- Typically created by the `alumacc` pass, which transforms: -//- $add, $sub, $lt, $le, $ge, $gt, $eq, $eqx, $ne, $nex +//- $add, $sub, $lt, $le, $ge, $gt, $eq, $eqx, $ne, $nex //- cells into this $alu cell. //- module \$alu (A, B, CI, BI, X, Y, CO); From 1e5a50ff3a7c4bb2cd0de35838a88f0fcfb66475 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Tue, 9 Apr 2024 16:13:37 +1200 Subject: [PATCH 05/68] Docs: Convert write_cell_rst to use SimHelper --- kernel/register.cc | 49 ++++++++++++++++------------------------------ 1 file changed, 17 insertions(+), 32 deletions(-) diff --git a/kernel/register.cc b/kernel/register.cc index 85d3d4748e8..edf6ea7ba7c 100644 --- a/kernel/register.cc +++ b/kernel/register.cc @@ -880,54 +880,39 @@ struct HelpPass : public Pass { } fclose(f); } - void write_cell_rst(std::string cell, std::string help, std::string code) + void write_cell_rst(Yosys::SimHelper cell) { // open - string safe_name = cell.substr(1); - FILE *f = fopen(stringf("docs/source/cell/%s.rst", safe_name.c_str()).c_str(), "wt"); + FILE *f = fopen(stringf("docs/source/cell/%s.rst", cell.filesafe_name().c_str()).c_str(), "wt"); // make header - string short_help = ""; - string long_help = ""; - string title_line = cell; - for (auto line : split_tokens(help, "\n")) { - if (short_help == "") { - size_t first_pos = line.find_first_not_of(" \t"); - // skip empty lines - if (first_pos == string::npos) continue; - if (line.find(cell.c_str()) == string::npos) { - // strip leading/trailing space - size_t last_pos = line.find_last_not_of(" \t"); - short_help = line.substr(first_pos, last_pos - first_pos +1); - // skip missing help message - if (short_help == "No help message for this cell type found.") { - long_help += line; - long_help += "\n"; - } else { - title_line = stringf("%s - %s", cell.c_str(), short_help.c_str()); - } - } - } else { - long_help += line; - long_help += "\n"; - } - } + string title_line; + if (cell.short_desc.length()) + title_line = stringf("%s - %s", cell.name.c_str(), cell.short_desc.c_str()); + else title_line = cell.name; string underline = "\n"; underline.insert(0, title_line.length(), '='); fprintf(f, "%s\n", title_line.c_str()); fprintf(f, "%s\n", underline.c_str()); // help text - fprintf(f, "%s\n", long_help.c_str()); + fprintf(f, "%s\n", cell.desc.c_str()); // source code + fprintf(f, "Simulation model (Verilog)\n"); + fprintf(f, "--------------------------\n\n"); fprintf(f, ".. code:: verilog\n\n"); std::stringstream ss; - ss << code; + ss << cell.code; for (std::string line; std::getline(ss, line, '\n');) { - fprintf(f, "\t%s\n", line.c_str()); + fprintf(f, " %s\n", line.c_str()); } + // footer + fprintf(f, "\n.. note::\n\n"); + fprintf(f, " This page was auto-generated from the output of\n"); + fprintf(f, " ``help %s``.\n", cell.name.c_str()); + // close fclose(f); } @@ -988,7 +973,7 @@ struct HelpPass : public Pass { } else if (args[1] == "-write-rst-cells-manual") { for (auto &it : cell_help_messages.cell_help) { - write_cell_rst(it.first, it.second.desc, it.second.code); + write_cell_rst(it.second); } } else if (pass_register.count(args[1])) { From 784292626e9235ba52cc4946dd81e54a58ef5cec Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Thu, 11 Apr 2024 11:15:24 +1200 Subject: [PATCH 06/68] cellhelp: Rename short_desc to title --- kernel/register.cc | 8 ++++---- techlibs/common/cellhelp.py | 4 ++-- techlibs/common/simlib.v | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/kernel/register.cc b/kernel/register.cc index edf6ea7ba7c..fe3495dadad 100644 --- a/kernel/register.cc +++ b/kernel/register.cc @@ -755,7 +755,7 @@ struct SimHelper { else return name; } - string short_desc; + string title; string ports; string desc; string code; @@ -887,8 +887,8 @@ struct HelpPass : public Pass { // make header string title_line; - if (cell.short_desc.length()) - title_line = stringf("%s - %s", cell.name.c_str(), cell.short_desc.c_str()); + if (cell.title.length()) + title_line = stringf("%s - %s", cell.name.c_str(), cell.title.c_str()); else title_line = cell.name; string underline = "\n"; underline.insert(0, title_line.length(), '='); @@ -988,7 +988,7 @@ struct HelpPass : public Pass { SimHelper help_cell = cell_help_messages.cell_help.at(args[1]); if (help_cell.ver == "2") { log("\n %s %s\n", help_cell.name.c_str(), help_cell.ports.c_str()); - log("\n%s\n", help_cell.short_desc.c_str()); + log("\n%s\n", help_cell.title.c_str()); log("%s\n", help_cell.desc.c_str()); log("Run 'help %s+' to display the Verilog model for this cell type.\n", args[1].c_str()); log("\n"); diff --git a/techlibs/common/cellhelp.py b/techlibs/common/cellhelp.py index 4d40b73c071..312446ad4b0 100644 --- a/techlibs/common/cellhelp.py +++ b/techlibs/common/cellhelp.py @@ -6,7 +6,7 @@ class SimHelper: name: str = "" - short_desc: str = "" + title: str = "" ports: str = "" desc: list[str] code: list[str] @@ -18,7 +18,7 @@ def __init__(self) -> None: def __str__(self) -> str: val = "tempCell = {\n" val += f' {json.dumps(self.name)},\n' - val += f' {json.dumps(self.short_desc)},\n' + val += f' {json.dumps(self.title)},\n' val += f' {json.dumps(self.ports)},\n' val += ' ' + json.dumps("\n".join(self.desc)) + ',\n' val += ' ' + json.dumps("\n".join(self.code)) + ',\n' diff --git a/techlibs/common/simlib.v b/techlibs/common/simlib.v index 71bb58c415f..96f143c2ab0 100644 --- a/techlibs/common/simlib.v +++ b/techlibs/common/simlib.v @@ -622,7 +622,7 @@ endmodule // -------------------------------------------------------- //* ver 2 -//* short_desc Arithmetic logic unit +//* title Arithmetic logic unit //- A building block supporting both binary addition/subtraction operations, and //- indirectly, comparison operations. //- Typically created by the `alumacc` pass, which transforms: From a2b2904ed899f22aae91c9dc033a692622e72fd7 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Fri, 12 Apr 2024 13:57:51 +1200 Subject: [PATCH 07/68] cellhelp: Add source line to help Include Source file and line number in SimHelper struct, and use it for verilog code caption in rst dump. Also reformat python string conversion to iterate over a list of fields instead of repeating code for each. --- kernel/register.cc | 4 +++- techlibs/common/cellhelp.py | 21 +++++++++++++++------ 2 files changed, 18 insertions(+), 7 deletions(-) diff --git a/kernel/register.cc b/kernel/register.cc index fe3495dadad..99225ba51ae 100644 --- a/kernel/register.cc +++ b/kernel/register.cc @@ -757,6 +757,7 @@ struct SimHelper { } string title; string ports; + string source; string desc; string code; string ver; @@ -901,7 +902,8 @@ struct HelpPass : public Pass { // source code fprintf(f, "Simulation model (Verilog)\n"); fprintf(f, "--------------------------\n\n"); - fprintf(f, ".. code:: verilog\n\n"); + fprintf(f, ".. code-block:: verilog\n"); + fprintf(f, " :caption: %s\n\n", cell.source.c_str()); std::stringstream ss; ss << cell.code; for (std::string line; std::getline(ss, line, '\n');) { diff --git a/techlibs/common/cellhelp.py b/techlibs/common/cellhelp.py index 312446ad4b0..1d55d17f508 100644 --- a/techlibs/common/cellhelp.py +++ b/techlibs/common/cellhelp.py @@ -3,11 +3,13 @@ from __future__ import annotations import fileinput import json +from pathlib import Path class SimHelper: name: str = "" title: str = "" ports: str = "" + source: str = "" desc: list[str] code: list[str] ver: str = "1" @@ -16,14 +18,19 @@ def __init__(self) -> None: self.desc = [] def __str__(self) -> str: + printed_fields = [ + "name", "title", "ports", "source", "desc", "code", "ver", + ] + # generate C++ struct val = "tempCell = {\n" - val += f' {json.dumps(self.name)},\n' - val += f' {json.dumps(self.title)},\n' - val += f' {json.dumps(self.ports)},\n' - val += ' ' + json.dumps("\n".join(self.desc)) + ',\n' - val += ' ' + json.dumps("\n".join(self.code)) + ',\n' - val += f' {json.dumps(self.ver)},\n' + for field in printed_fields: + field_val = getattr(self, field) + if isinstance(field_val, list): + field_val = "\n".join(field_val) + val += f' {json.dumps(field_val)},\n' val += "};\n" + + # map name to struct val += f'cell_help[{json.dumps(self.name)}] = tempCell;' val += "\n" val += f'cell_code[{json.dumps(self.name + "+")}] = tempCell;' @@ -45,6 +52,8 @@ def __str__(self) -> str: clean_line = line[7:].replace("\\", "").replace(";", "") simHelper.name, simHelper.ports = clean_line.split(maxsplit=1) simHelper.code = [] + short_filename = Path(fileinput.filename()).name + simHelper.source = f'{short_filename}:{fileinput.filelineno()}' elif not line.startswith("endmodule"): line = " " + line try: From 57cd8d29db5e0fb32aaa7b813617b91c5ab31792 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Fri, 12 Apr 2024 15:48:47 +1200 Subject: [PATCH 08/68] cellhelp: Add default format parse for simcells Since `simcells.v` uses consistent formatting we can handle it specifically to help tidy up sphinx warnings about the truth tables, and instead chuck them in a code block which when printing to rst. Also has the side effect that rst code blocks can be added manually with `//- ::` followed by a blank line. --- kernel/register.cc | 12 ++++++++---- techlibs/common/cellhelp.py | 23 +++++++++++++++++++++++ 2 files changed, 31 insertions(+), 4 deletions(-) diff --git a/kernel/register.cc b/kernel/register.cc index 99225ba51ae..38345052538 100644 --- a/kernel/register.cc +++ b/kernel/register.cc @@ -988,10 +988,14 @@ struct HelpPass : public Pass { } else if (cell_help_messages.cell_help.count(args[1])) { SimHelper help_cell = cell_help_messages.cell_help.at(args[1]); - if (help_cell.ver == "2") { - log("\n %s %s\n", help_cell.name.c_str(), help_cell.ports.c_str()); - log("\n%s\n", help_cell.title.c_str()); - log("%s\n", help_cell.desc.c_str()); + if (help_cell.ver == "2" || help_cell.ver == "2a") { + log("\n %s %s\n\n", help_cell.name.c_str(), help_cell.ports.c_str()); + if (help_cell.title != "") log("%s\n", help_cell.title.c_str()); + std::stringstream ss; + ss << help_cell.desc; + for (std::string line; std::getline(ss, line, '\n');) { + if (line != "::") log("%s\n", line.c_str()); + } log("Run 'help %s+' to display the Verilog model for this cell type.\n", args[1].c_str()); log("\n"); } else { diff --git a/techlibs/common/cellhelp.py b/techlibs/common/cellhelp.py index 1d55d17f508..a975c31e5b3 100644 --- a/techlibs/common/cellhelp.py +++ b/techlibs/common/cellhelp.py @@ -36,6 +36,24 @@ def __str__(self) -> str: val += f'cell_code[{json.dumps(self.name + "+")}] = tempCell;' return val +def simcells_reparse(cell: SimHelper): + # cut manual signature + cell.desc = cell.desc[3:] + + # code-block truth table + new_desc = [] + indent = "" + for line in cell.desc: + if line.startswith("Truth table:"): + indent = " " + new_desc.pop() + new_desc.extend(["::", ""]) + new_desc.append(indent + line) + cell.desc = new_desc + + # set version + cell.ver = "2a" + simHelper = SimHelper() for line in fileinput.input(): @@ -62,7 +80,12 @@ def __str__(self) -> str: # no module definition, ignore line pass if line.startswith("endmodule"): + short_filename = Path(fileinput.filename()).name + if simHelper.ver == "1" and short_filename == "simcells.v": + # default simcells parsing + simcells_reparse(simHelper) if not simHelper.desc: + # no help simHelper.desc.append("No help message for this cell type found.\n") print(simHelper) simHelper = SimHelper() From 1a4ada40fe679a1cf309558f43200dc9af146220 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Mon, 15 Apr 2024 10:32:02 +1200 Subject: [PATCH 09/68] Docs: Add cell gen to makefile Generate in a temp directory and use `rsync -rc` to only update rst files that have changed. This prevents sphinx from having to re-generate every cmd/cell page any time the git sha changes. Also change cmd gen to match. --- Makefile | 13 +++++++++++-- docs/Makefile | 2 +- 2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 86e5064c918..eaf133ff713 100644 --- a/Makefile +++ b/Makefile @@ -981,8 +981,17 @@ endif # also others, but so long as it doesn't fail this is enough to know we tried docs/source/cmd/abc.rst: $(TARGETS) $(EXTRA_TARGETS) - mkdir -p docs/source/cmd - ./$(PROGRAM_PREFIX)yosys -p 'help -write-rst-command-reference-manual' + $(Q) mkdir -p docs/source/cmd + $(Q) mkdir -p temp/docs/source/cmd + $(Q) cd temp && ./../$(PROGRAM_PREFIX)yosys -p 'help -write-rst-command-reference-manual' + $(Q) rsync -rc temp/docs/source/cmd docs/source + $(Q) rm -rf temp +docs/source/cell/add.rst: $(TARGETS) $(EXTRA_TARGETS) + $(Q) mkdir -p docs/source/cell + $(Q) mkdir -p temp/docs/source/cell + $(Q) cd temp && ./../$(PROGRAM_PREFIX)yosys -p 'help -write-rst-cells-manual' + $(Q) rsync -rc temp/docs/source/cell docs/source + $(Q) rm -rf temp PHONY: docs/gen_examples docs/gen_images docs/guidelines docs/usage docs/reqs docs/gen_examples: $(TARGETS) diff --git a/docs/Makefile b/docs/Makefile index 6dbf6f4902b..9be050d35ea 100644 --- a/docs/Makefile +++ b/docs/Makefile @@ -47,7 +47,7 @@ help: .PHONY: clean clean: clean-examples rm -rf $(BUILDDIR)/* - rm -rf source/cmd util/__pycache__ + rm -rf source/cell source/cmd util/__pycache__ rm -rf source/generated $(MAKE) -C source/_images clean From d629aa6bf1de19c4e63802d2050c0828175bea2e Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Fri, 3 May 2024 09:16:55 +1200 Subject: [PATCH 10/68] cellhelp: Split gate-level and word-level cells --- Makefile | 4 ++-- docs/source/cell_gate.rst | 9 +++++++++ docs/source/cell_ref.rst | 9 +++++---- docs/source/cell_word.rst | 9 +++++++++ kernel/register.cc | 5 ++++- 5 files changed, 29 insertions(+), 7 deletions(-) create mode 100644 docs/source/cell_gate.rst create mode 100644 docs/source/cell_word.rst diff --git a/Makefile b/Makefile index eaf133ff713..87e62adb593 100644 --- a/Makefile +++ b/Makefile @@ -986,7 +986,7 @@ docs/source/cmd/abc.rst: $(TARGETS) $(EXTRA_TARGETS) $(Q) cd temp && ./../$(PROGRAM_PREFIX)yosys -p 'help -write-rst-command-reference-manual' $(Q) rsync -rc temp/docs/source/cmd docs/source $(Q) rm -rf temp -docs/source/cell/add.rst: $(TARGETS) $(EXTRA_TARGETS) +docs/source/cell/word_add.rst: $(TARGETS) $(EXTRA_TARGETS) $(Q) mkdir -p docs/source/cell $(Q) mkdir -p temp/docs/source/cell $(Q) cd temp && ./../$(PROGRAM_PREFIX)yosys -p 'help -write-rst-cells-manual' @@ -1034,7 +1034,7 @@ docs/reqs: $(Q) $(MAKE) -C docs reqs .PHONY: docs/prep -docs/prep: docs/source/cmd/abc.rst docs/gen_examples docs/gen_images docs/guidelines docs/usage +docs/prep: docs/source/cmd/abc.rst docs/source/cell/word_add.rst docs/gen_examples docs/gen_images docs/guidelines docs/usage DOC_TARGET ?= html docs: docs/prep diff --git a/docs/source/cell_gate.rst b/docs/source/cell_gate.rst new file mode 100644 index 00000000000..74dd57bc727 --- /dev/null +++ b/docs/source/cell_gate.rst @@ -0,0 +1,9 @@ +Gate-level cells +---------------- + +.. toctree:: + :caption: Gate-level cells + :maxdepth: 1 + :glob: + + /cell/gate_* diff --git a/docs/source/cell_ref.rst b/docs/source/cell_ref.rst index ddf66812d6d..dc143124edb 100644 --- a/docs/source/cell_ref.rst +++ b/docs/source/cell_ref.rst @@ -5,8 +5,9 @@ Internal cell reference ================================================================================ .. toctree:: - :caption: Internal cell reference - :maxdepth: 1 - :glob: + :caption: Internal cell reference + :maxdepth: 2 + :glob: - /cell/* + cell_word + cell_gate diff --git a/docs/source/cell_word.rst b/docs/source/cell_word.rst new file mode 100644 index 00000000000..f7205e6eee3 --- /dev/null +++ b/docs/source/cell_word.rst @@ -0,0 +1,9 @@ +Word-level cells +---------------- + +.. toctree:: + :caption: Word-level cells + :maxdepth: 1 + :glob: + + /cell/word_* diff --git a/kernel/register.cc b/kernel/register.cc index 38345052538..1d899b32083 100644 --- a/kernel/register.cc +++ b/kernel/register.cc @@ -751,7 +751,10 @@ struct SimHelper { string name; inline string filesafe_name() { if (name.at(0) == '$') - return name.substr(1); + if (name.at(1) == '_') + return "gate" + name.substr(1); + else + return "word_" + name.substr(1); else return name; } From c98d13466284800723a40804db0e52dd197dc43c Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Fri, 3 May 2024 09:23:54 +1200 Subject: [PATCH 11/68] cellhelp: Extra newline Fix `$macc` page. --- kernel/register.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/register.cc b/kernel/register.cc index 1d899b32083..4e54dcca389 100644 --- a/kernel/register.cc +++ b/kernel/register.cc @@ -900,7 +900,7 @@ struct HelpPass : public Pass { fprintf(f, "%s\n", underline.c_str()); // help text - fprintf(f, "%s\n", cell.desc.c_str()); + fprintf(f, "%s\n\n", cell.desc.c_str()); // source code fprintf(f, "Simulation model (Verilog)\n"); From f9b4e04fef158f52974b996dd64a55848e288aab Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Fri, 3 May 2024 11:45:17 +1200 Subject: [PATCH 12/68] Docs: Add cell reference Subclass the command reference code in order to support smart references to the internal cells. --- docs/util/cmdref.py | 83 ++++++++++++++++++++++++--------------------- kernel/register.cc | 21 ++++++++---- 2 files changed, 60 insertions(+), 44 deletions(-) diff --git a/docs/util/cmdref.py b/docs/util/cmdref.py index ec146e23173..ce010471cd1 100644 --- a/docs/util/cmdref.py +++ b/docs/util/cmdref.py @@ -1,30 +1,5 @@ # based on https://github.com/ofosos/sphinxrecipes/blob/master/sphinxrecipes/sphinxrecipes.py -# license: -# Copyright 2019 Mark Meyer -# -# Permission is hereby granted, free of charge, to any person obtaining -# a copy of this software and associated documentation files (the -# "Software"), to deal in the Software without restriction, including -# without limitation the rights to use, copy, modify, merge, publish, -# distribute, sublicense, and/or sell copies of the Software, and to -# permit persons to whom the Software is furnished to do so, subject to -# the following conditions: -# -# The above copyright notice and this permission notice shall be -# included in all copies or substantial portions of the Software. -# -# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, -# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF -# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND -# NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE -# LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION -# OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION -# WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. - -import docutils -from docutils import nodes -import sphinx -from docutils.parsers import rst + from docutils.parsers.rst import directives from sphinx.domains import Domain, Index from sphinx.domains.std import StandardDomain @@ -35,7 +10,8 @@ class CommandNode(ObjectDescription): """A custom node that describes a command.""" - + + name = 'cmd' required_arguments = 1 option_spec = { @@ -49,24 +25,29 @@ def handle_signature(self, sig, signode: addnodes.desc_signature): return sig def add_target_and_index(self, name_cls, sig, signode): - signode['ids'].append('cmd' + '-' + sig) + signode['ids'].append(type(self).name + '-' + sig) if 'noindex' not in self.options: - name = "{}.{}.{}".format('cmd', type(self).__name__, sig) - tagmap = self.env.domaindata['cmd']['obj2tag'] + name = "{}.{}.{}".format(self.name, type(self).__name__, sig) + tagmap = self.env.domaindata[type(self).name]['obj2tag'] tagmap[name] = list(self.options.get('tags', '').split(' ')) title = self.options.get('title') - titlemap = self.env.domaindata['cmd']['obj2title'] + titlemap = self.env.domaindata[type(self).name]['obj2title'] titlemap[name] = title - objs = self.env.domaindata['cmd']['objects'] + objs = self.env.domaindata[type(self).name]['objects'] objs.append((name, sig, title, self.env.docname, - 'cmd' + '-' + sig, + type(self).name + '-' + sig, 0)) +class CellNode(CommandNode): + """A custom node that describes an internal cell.""" + + name = 'cell' + class TagIndex(Index): - """A custom directive that creates an tag matrix.""" + """A custom directive that creates a tag matrix.""" name = 'tag' localname = 'Tag Index' @@ -167,7 +148,7 @@ def generate(self, docnames=None): in self.domain.get_objects()) items = sorted(items, key=lambda item: item[0]) for name, dispname, typ, docname, anchor in items: - lis = content.setdefault('Command', []) + lis = content.setdefault(self.shortname, []) lis.append(( dispname, 0, docname, anchor, @@ -177,10 +158,14 @@ def generate(self, docnames=None): return (re, True) +class CellIndex(CommandIndex): + name = 'cell' + localname = 'Internal cell reference' + shortname = 'Internal cell' class CommandDomain(Domain): name = 'cmd' - label = 'Command Sample' + label = 'Yosys commands' roles = { 'ref': XRefRole() @@ -203,7 +188,7 @@ class CommandDomain(Domain): def get_full_qualified_name(self, node): """Return full qualified name for a given node""" - return "{}.{}.{}".format('cmd', + return "{}.{}.{}".format(type(self).name, type(node).__name__, node.arguments[0]) @@ -229,18 +214,40 @@ def resolve_xref(self, env, fromdocname, builder, typ, else: print(f"Missing ref for {target} in {fromdocname} ") return None + +class CellDomain(CommandDomain): + name = 'cell' + label = 'Yosys internal cells' + + directives = { + 'def': CellNode, + } + + indices = { + CellIndex, + TagIndex + } def setup(app): app.add_domain(CommandDomain) + app.add_domain(CellDomain) StandardDomain.initial_data['labels']['commandindex'] =\ ('cmd-cmd', '', 'Command Reference') StandardDomain.initial_data['labels']['tagindex'] =\ ('cmd-tag', '', 'Tag Index') + StandardDomain.initial_data['labels']['cellindex'] =\ + ('cell-cell', '', 'Internal cell reference') + StandardDomain.initial_data['labels']['tagindex'] =\ + ('cell-tag', '', 'Tag Index') StandardDomain.initial_data['anonlabels']['commandindex'] =\ ('cmd-cmd', '') StandardDomain.initial_data['anonlabels']['tagindex'] =\ ('cmd-tag', '') + StandardDomain.initial_data['anonlabels']['cellindex'] =\ + ('cell-cell', '') + StandardDomain.initial_data['anonlabels']['tagindex'] =\ + ('cell-tag', '') - return {'version': '0.1'} + return {'version': '0.2'} diff --git a/kernel/register.cc b/kernel/register.cc index 4e54dcca389..b16a6f85268 100644 --- a/kernel/register.cc +++ b/kernel/register.cc @@ -899,17 +899,26 @@ struct HelpPass : public Pass { fprintf(f, "%s\n", title_line.c_str()); fprintf(f, "%s\n", underline.c_str()); - // help text - fprintf(f, "%s\n\n", cell.desc.c_str()); + // help text, with cell def for links + fprintf(f, ".. cell:def:: %s\n", cell.name.c_str()); + if (cell.title.length()) + fprintf(f, " :title: %s\n\n", cell.title.c_str()); + else + fprintf(f, " :title: %s\n\n", cell.name.c_str()); + std::stringstream ss; + ss << cell.desc; + for (std::string line; std::getline(ss, line, '\n');) { + fprintf(f, " %s\n", line.c_str()); + } // source code - fprintf(f, "Simulation model (Verilog)\n"); + fprintf(f, "\nSimulation model (Verilog)\n"); fprintf(f, "--------------------------\n\n"); fprintf(f, ".. code-block:: verilog\n"); fprintf(f, " :caption: %s\n\n", cell.source.c_str()); - std::stringstream ss; - ss << cell.code; - for (std::string line; std::getline(ss, line, '\n');) { + std::stringstream ss2; + ss2 << cell.code; + for (std::string line; std::getline(ss2, line, '\n');) { fprintf(f, " %s\n", line.c_str()); } From c0f9828b3c23745de26ec9749af0fd856ea06a66 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Fri, 3 May 2024 12:55:08 +1200 Subject: [PATCH 13/68] Docs: Add autoref role Use new `autoref` role when using single backticks. Allows automatic mapping to a cmd ref or a cell ref. --- docs/source/conf.py | 3 +++ docs/util/cmdref.py | 11 ++++++++++- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/docs/source/conf.py b/docs/source/conf.py index 8e30fcc7c03..bfabe60e514 100644 --- a/docs/source/conf.py +++ b/docs/source/conf.py @@ -41,6 +41,9 @@ pygments_style = 'colorful' highlight_language = 'none' +# default single quotes to attempt auto reference, or fallback to code +default_role = 'autoref' + extensions = ['sphinx.ext.autosectionlabel', 'sphinxcontrib.bibtex'] if os.getenv("READTHEDOCS"): diff --git a/docs/util/cmdref.py b/docs/util/cmdref.py index ce010471cd1..aac8993889f 100644 --- a/docs/util/cmdref.py +++ b/docs/util/cmdref.py @@ -1,6 +1,8 @@ # based on https://github.com/ofosos/sphinxrecipes/blob/master/sphinxrecipes/sphinxrecipes.py from docutils.parsers.rst import directives +from docutils.parsers.rst.states import Inliner +from sphinx.application import Sphinx from sphinx.domains import Domain, Index from sphinx.domains.std import StandardDomain from sphinx.roles import XRefRole @@ -228,7 +230,12 @@ class CellDomain(CommandDomain): TagIndex } -def setup(app): +def autoref(name, rawtext, text, lineno, inliner: Inliner, + options=None, content=None): + role = 'cell:ref' if text[0] == '$' else 'cmd:ref' + return inliner.interpreted(rawtext, text, role, lineno) + +def setup(app: Sphinx): app.add_domain(CommandDomain) app.add_domain(CellDomain) @@ -249,5 +256,7 @@ def setup(app): ('cell-cell', '') StandardDomain.initial_data['anonlabels']['tagindex'] =\ ('cell-tag', '') + + app.add_role('autoref', autoref) return {'version': '0.2'} From e4ec3717bcceed6e78e646f1afd4ca1e22840ead Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Fri, 3 May 2024 13:14:25 +1200 Subject: [PATCH 14/68] Docs: Update internal cells to autoref --- docs/source/getting_started/example_synth.rst | 64 +++--- .../getting_started/scripting_intro.rst | 15 +- .../interactive_investigation.rst | 4 +- .../using_yosys/more_scripting/selections.rst | 12 +- .../using_yosys/synthesis/cell_libs.rst | 4 +- docs/source/using_yosys/synthesis/fsm.rst | 18 +- docs/source/using_yosys/synthesis/memory.rst | 10 +- docs/source/using_yosys/synthesis/opt.rst | 30 +-- .../yosys_internals/flow/verilog_frontend.rst | 4 +- .../yosys_internals/formats/cell_library.rst | 183 +++++++++--------- .../yosys_internals/formats/rtlil_rep.rst | 16 +- docs/source/yosys_internals/techmap.rst | 2 +- 12 files changed, 183 insertions(+), 179 deletions(-) diff --git a/docs/source/getting_started/example_synth.rst b/docs/source/getting_started/example_synth.rst index ae0a9a36620..28e74ecc0d2 100644 --- a/docs/source/getting_started/example_synth.rst +++ b/docs/source/getting_started/example_synth.rst @@ -129,7 +129,7 @@ Our ``addr_gen`` circuit now looks like this: Simple operations like ``addr + 1`` and ``addr == MAX_DATA-1`` can be extracted from our ``always @`` block in :ref:`addr_gen-v`. This gives us the highlighted -``$add`` and ``$eq`` cells we see. But control logic (like the ``if .. else``) +`$add` and `$eq` cells we see. But control logic (like the ``if .. else``) and memory elements (like the ``addr <= 0``) are not so straightforward. These get put into "processes", shown in the schematic as ``PROC``. Note how the second line refers to the line numbers of the start/end of the corresponding @@ -151,8 +151,8 @@ automatic optimizations which would normally happen. ``addr_gen`` module after :yoscrypt:`proc -noopt` There are now a few new cells from our ``always @``, which have been -highlighted. The ``if`` statements are now modeled with ``$mux`` cells, while -the register uses an ``$adff`` cell. If we look at the terminal output we can +highlighted. The ``if`` statements are now modeled with `$mux` cells, while +the register uses an `$adff` cell. If we look at the terminal output we can also see all of the different ``proc_*`` commands being called. We will look at each of these in more detail in :doc:`/using_yosys/synthesis/proc`. @@ -171,7 +171,7 @@ clean`. ``addr_gen`` module after :yoscrypt:`opt_expr; clean` -You may also notice that the highlighted ``$eq`` cell input of ``255`` has +You may also notice that the highlighted `$eq` cell input of ``255`` has changed to ``8'11111111``. Constant values are presented in the format ``'``, with 32-bit values instead using the decimal number. This indicates that the constant input has been reduced from 32-bit wide to @@ -218,7 +218,7 @@ could restart our shell session, but instead let's use two new commands: :end-before: yosys> proc :caption: reloading :file:`fifo.v` and running :yoscrypt:`hierarchy -check -top fifo` -Notice how this time we didn't see any of those `$abstract` modules? That's +Notice how this time we didn't see any of those ``$abstract`` modules? That's because when we ran ``yosys fifo.v``, the first command Yosys called was :yoscrypt:`read_verilog -defer fifo.v`. The ``-defer`` option there tells :cmd:ref:`read_verilog` only read the abstract syntax tree and defer actual @@ -263,10 +263,10 @@ The highlighted ``fifo_reader`` block contains an instance of the instance of the ``addr_gen`` module with the ``MAX_DATA`` parameter set to the given value. -The other highlighted block is a ``$memrd`` cell. At this stage of synthesis we +The other highlighted block is a `$memrd` cell. At this stage of synthesis we don't yet know what type of memory is going to be implemented, but we *do* know that ``rdata <= data[raddr];`` could be implemented as a read from memory. Note -that the ``$memrd`` cell here is asynchronous, with both the clock and enable +that the `$memrd` cell here is asynchronous, with both the clock and enable signal undefined; shown with the ``1'x`` inputs. .. seealso:: Advanced usage docs for @@ -309,7 +309,7 @@ optimizations between modules which would otherwise be missed. Let's run The pieces have moved around a bit, but we can see :ref:`addr_gen_proc` from earlier has replaced the ``fifo_reader`` block in :ref:`rdata_proc`. We can also see that the ``addr`` output has been renamed to :file:`fifo_reader.addr` -and merged with the ``raddr`` wire feeding into the ``$memrd`` cell. This wire +and merged with the ``raddr`` wire feeding into the `$memrd` cell. This wire merging happened during the call to :cmd:ref:`clean` which we can see in the :ref:`flat_clean`. @@ -375,8 +375,8 @@ which are explored in more detail in :doc:`/using_yosys/synthesis/opt` and Up until now, the data path for ``rdata`` has remained the same since :ref:`rdata_flat`. However the next call to :cmd:ref:`opt` does cause a change. Specifically, the call to :cmd:ref:`opt_dff` without the ``-nodffe -nosdff`` -options is able to fold one of the ``$mux`` cells into the ``$adff`` to form an -``$adffe`` cell; highlighted below: +options is able to fold one of the `$mux` cells into the `$adff` to form an +`$adffe` cell; highlighted below: .. literalinclude:: /code_examples/fifo/fifo.out :language: doscon @@ -418,7 +418,7 @@ First up is :doc:`/cmd/wreduce`. If we run this we get the following: Looking at the data path for ``rdata``, the most relevant of these width reductions are the ones affecting ``fifo.$flatten\fifo_reader.$add$fifo.v``. -That is the ``$add`` cell incrementing the fifo_reader address. We can look at +That is the `$add` cell incrementing the fifo_reader address. We can look at the schematic and see the output of that cell has now changed. .. todo:: pending bugfix in :cmd:ref:`wreduce` and/or :cmd:ref:`opt_clean` @@ -451,8 +451,8 @@ Our next command to run is ``rdata`` output after :cmd:ref:`memory_dff` -As the title suggests, :cmd:ref:`memory_dff` has merged the output ``$dff`` into -the ``$memrd`` cell and converted it to a ``$memrd_v2`` (highlighted). This has +As the title suggests, :cmd:ref:`memory_dff` has merged the output `$dff` into +the `$memrd` cell and converted it to a `$memrd_v2` (highlighted). This has also connected the ``CLK`` port to the ``clk`` input as it is now a synchronous memory read with appropriate enable (``EN=1'1``) and reset (``ARST=1'0`` and ``SRST=1'0``) inputs. @@ -482,12 +482,12 @@ what they do. :name: synth_coarse3 :yoscrypt:`wreduce t:$mul` performs width reduction again, this time targetting -only cells of type ``$mul``. :yoscrypt:`techmap -map +/mul2dsp.v -map +only cells of type `$mul`. :yoscrypt:`techmap -map +/mul2dsp.v -map +/ice40/dsp_map.v ... -D DSP_NAME=$__MUL16X16` uses :cmd:ref:`techmap` to map -``$mul`` cells to ``$__MUL16X16`` which are, in turn, mapped to the iCE40 +`$mul` cells to ``$__MUL16X16`` which are, in turn, mapped to the iCE40 ``SB_MAC16``. Any multipliers which aren't compatible with conversion to ``$__MUL16X16`` are relabelled to ``$__soft_mul`` before :cmd:ref:`chtype` -changes them back to ``$mul``. +changes them back to `$mul`. During the mul2dsp conversion, some of the intermediate signals are marked with the attribute ``mul2dsp``. By calling :yoscrypt:`select a:mul2dsp` we restrict @@ -522,8 +522,8 @@ That brings us to the fourth and final part for the iCE40 synthesis flow: :caption: ``coarse`` section (part 4) :name: synth_coarse4 -Where before each type of arithmetic operation had its own cell, e.g. ``$add``, -we now want to extract these into ``$alu`` and ``$macc`` cells which can help +Where before each type of arithmetic operation had its own cell, e.g. `$add`, +we now want to extract these into `$alu` and `$macc` cells which can help identify opportunities for reusing logic. We do this by running :cmd:ref:`alumacc`, which we can see produce the following changes in our example design: @@ -542,7 +542,7 @@ example design: Once these cells have been inserted, the call to :cmd:ref:`opt` can combine cells which are now identical but may have been missed due to e.g. the -difference between ``$add`` and ``$sub``. +difference between `$add` and `$sub`. The other new command in this part is :doc:`/cmd/memory`. :cmd:ref:`memory` is another macro command which we examine in more detail in @@ -559,7 +559,7 @@ combines all of the reads and writes for a memory block into a single cell. ``rdata`` output after :cmd:ref:`memory_collect` Looking at the schematic after running :cmd:ref:`memory_collect` we see that our -``$memrd_v2`` cell has been replaced with a ``$mem_v2`` cell named ``data``, the +`$memrd_v2` cell has been replaced with a `$mem_v2` cell named ``data``, the same name that we used in :ref:`fifo-v`. Where before we had a single set of signals for address and enable, we now have one set for reading (``RD_*``) and one for writing (``WR_*``), as well as both ``WR_DATA`` input and ``RD_DATA`` @@ -609,10 +609,10 @@ Mapping to hard memory blocks uses a combination of :cmd:ref:`memory_libmap` and ``rdata`` output after :ref:`map_ram` -The :ref:`map_ram` converts the generic ``$mem_v2`` into the iCE40 +The :ref:`map_ram` converts the generic `$mem_v2` into the iCE40 ``SB_RAM40_4K`` (highlighted). We can also see the memory address has been remapped, and the data bits have been reordered (or swizzled). There is also -now a ``$mux`` cell controlling the value of ``rdata``. In :ref:`fifo-v` we +now a `$mux` cell controlling the value of ``rdata``. In :ref:`fifo-v` we wrote our memory as read-before-write, however the ``SB_RAM40_4K`` has undefined behaviour when reading from and writing to the same address in the same cycle. As a result, extra logic is added so that the generated circuit matches the @@ -655,7 +655,7 @@ into flip flops (the ``logic fallback``) with :cmd:ref:`memory_map`. The visual clutter on the ``RDATA`` output port (highlighted) is an unfortunate side effect of :cmd:ref:`opt_clean` on the swizzled data bits. In - connecting the ``$mux`` input port directly to ``RDATA`` to reduce the number + connecting the `$mux` input port directly to ``RDATA`` to reduce the number of wires, the ``$techmap579\data.0.0.RDATA`` wire becomes more visually complex. @@ -668,10 +668,10 @@ Arithmetic ^^^^^^^^^^ Uses :cmd:ref:`techmap` to map basic arithmetic logic to hardware. This sees -somewhat of an explosion in cells as multi-bit ``$mux`` and ``$adffe`` are -replaced with single-bit ``$_MUX_`` and ``$_DFFE_PP0P_`` cells, while the -``$alu`` is replaced with primitive ``$_OR_`` and ``$_NOT_`` gates and a -``$lut`` cell. +somewhat of an explosion in cells as multi-bit :cell:ref:`$mux` and `$adffe` are +replaced with single-bit `$_MUX_` and `$_DFFE_PP0P_` cells, while the +:cell:ref:`$alu` is replaced with primitive `$_OR_` and `$_NOT_` gates and a +`$lut` cell. .. literalinclude:: /cmd/synth_ice40.rst :language: yoscrypt @@ -695,12 +695,12 @@ Flip-flops Convert FFs to the types supported in hardware with :cmd:ref:`dfflegalize`, and then use :cmd:ref:`techmap` to map them. In our example, this converts the -``$_DFFE_PP0P_`` cells to ``SB_DFFER``. +`$_DFFE_PP0P_` cells to ``SB_DFFER``. We also run :cmd:ref:`simplemap` here to convert any remaining cells which could not be mapped to hardware into gate-level primitives. This includes optimizing -``$_MUX_`` cells where one of the inputs is a constant ``1'0``, replacing it -instead with an ``$_AND_`` cell. +`$_MUX_` cells where one of the inputs is a constant ``1'0``, replacing it +instead with an `$_AND_` cell. .. literalinclude:: /cmd/synth_ice40.rst :language: yoscrypt @@ -723,7 +723,7 @@ LUTs ^^^^ :cmd:ref:`abc` and :cmd:ref:`techmap` are used to map LUTs; converting primitive -cell types to use ``$lut`` and ``SB_CARRY`` cells. Note that the iCE40 flow +cell types to use `$lut` and ``SB_CARRY`` cells. Note that the iCE40 flow uses :cmd:ref:`abc9` rather than :cmd:ref:`abc`. For more on what these do, and what the difference between these two commands are, refer to :doc:`/using_yosys/synthesis/abc`. @@ -742,7 +742,7 @@ what the difference between these two commands are, refer to ``rdata`` output after :ref:`map_luts` -Finally we use :cmd:ref:`techmap` to map the generic ``$lut`` cells to iCE40 +Finally we use :cmd:ref:`techmap` to map the generic `$lut` cells to iCE40 ``SB_LUT4`` cells. .. literalinclude:: /cmd/synth_ice40.rst diff --git a/docs/source/getting_started/scripting_intro.rst b/docs/source/getting_started/scripting_intro.rst index a6b4cb6bb42..1e2ebabff93 100644 --- a/docs/source/getting_started/scripting_intro.rst +++ b/docs/source/getting_started/scripting_intro.rst @@ -99,7 +99,7 @@ signifies we are matching on the *cell type*, and the ``*`` means to match anything. For this (very simple) selection, we are trying to find all of the cells, regardless of their type. The active selection is now shown as ``[addr_gen]*``, indicating some sub-selection of the ``addr_gen`` module. This -gives us the ``$add`` and ``$eq`` cells, which we want to highlight for the +gives us the `$add` and `$eq` cells, which we want to highlight for the :ref:`addr_gen_hier` image. .. _select_new_cells: @@ -111,10 +111,11 @@ by referring to it as ``@new_cells``, which we will see later. Then we clear the selection so that the following commands can operate on the full design. While we split that out for this document, we could have done the same thing in a single line by calling :yoscrypt:`select -set new_cells addr_gen/t:*`. If we -know we only have the one module in our design, we can even skip the `addr_gen/` -part. Looking further down :ref:`the fifo.ys code ` we can see this -with :yoscrypt:`select -set new_cells t:$mux t:*dff`. We can also see in that -command that selections don't have to be limited to a single statement. +know we only have the one module in our design, we can even skip the +``addr_gen/`` part. Looking further down :ref:`the fifo.ys code ` we +can see this with :yoscrypt:`select -set new_cells t:$mux t:*dff`. We can also +see in that command that selections don't have to be limited to a single +statement. Many commands also support an optional ``[selection]`` argument which can be used to override the currently selected objects. We could, for example, call @@ -184,8 +185,8 @@ like when we called :yoscrypt:`select -module addr_gen` in :ref:`select_intro`. That last parameter doesn't have to be a module name, it can be any valid selection string. Remember when we :ref:`assigned a name to a selection` and called it ``new_cells``? We saw in the -:yoscrypt:`select -list` output that it contained two cells, an ``$add`` and an -``$eq``. We can call :cmd:ref:`show` on that selection just as easily: +:yoscrypt:`select -list` output that it contained two cells, an `$add` and an +`$eq`. We can call :cmd:ref:`show` on that selection just as easily: .. figure:: /_images/code_examples/fifo/new_cells_show.* :class: width-helper invert-helper diff --git a/docs/source/using_yosys/more_scripting/interactive_investigation.rst b/docs/source/using_yosys/more_scripting/interactive_investigation.rst index 03a1faefa73..77d826376fd 100644 --- a/docs/source/using_yosys/more_scripting/interactive_investigation.rst +++ b/docs/source/using_yosys/more_scripting/interactive_investigation.rst @@ -81,7 +81,7 @@ internal representation of the decision-trees and synchronization events modelled in a Verilog ``always``-block. The label reads ``PROC`` followed by a unique identifier in the first line and contains the source code location of the original ``always``-block in the second line. Note how the multiplexer from the -``?:``-expression is represented as a ``$mux`` cell but the multiplexer from the +``?:``-expression is represented as a `$mux` cell but the multiplexer from the ``if``-statement is yet still hidden within the process. The :cmd:ref:`proc` command transforms the process from the first diagram into a @@ -117,7 +117,7 @@ leads us to the third diagram: Here we see that the :cmd:ref:`opt` command not only has removed the artifacts left behind by :cmd:ref:`proc`, but also determined correctly that it can remove -the first ``$mux`` cell without changing the behavior of the circuit. +the first `$mux` cell without changing the behavior of the circuit. Break-out boxes for signal vectors ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/docs/source/using_yosys/more_scripting/selections.rst b/docs/source/using_yosys/more_scripting/selections.rst index b0028347499..9c76b20b754 100644 --- a/docs/source/using_yosys/more_scripting/selections.rst +++ b/docs/source/using_yosys/more_scripting/selections.rst @@ -105,7 +105,7 @@ The :cmd:ref:`select` command is actually much more powerful than it might seem at first glance. When it is called with multiple arguments, each argument is evaluated and pushed separately on a stack. After all arguments have been processed it simply creates the union of all elements on the stack. So -:yoscrypt:`select t:$add a:foo` will select all ``$add`` cells and all objects +:yoscrypt:`select t:$add a:foo` will select all `$add` cells and all objects with the ``foo`` attribute set: .. literalinclude:: /code_examples/selections/foobaraddsub.v @@ -126,7 +126,7 @@ ineffective way of selecting the interesting part of the design. Special arguments can be used to combine the elements on the stack. For example the ``%i`` arguments pops the last two elements from the stack, intersects them, and pushes the result back on the stack. So :yoscrypt:`select t:$add a:foo %i` will -select all ``$add`` cells that have the ``foo`` attribute set: +select all `$add` cells that have the ``foo`` attribute set: .. code-block:: :caption: Output for command ``select t:$add a:foo %i -list`` on :numref:`foobaraddsub` @@ -220,7 +220,7 @@ The following sequence of diagrams demonstrates this step-wise expansion: Output of :yoscrypt:`show prod %ci %ci %ci` on :numref:`sumprod` Notice the subtle difference between :yoscrypt:`show prod %ci` and -:yoscrypt:`show prod %ci %ci`. Both images show the ``$mul`` cell driven by +:yoscrypt:`show prod %ci %ci`. Both images show the `$mul` cell driven by some inputs ``$3_Y`` and ``c``. However it is not until the second image, having called ``%ci`` the second time, that :cmd:ref:`show` is able to distinguish between ``$3_Y`` being a wire and ``c`` being an input. We can see @@ -296,7 +296,7 @@ cones`_ from above, we can use :yoscrypt:`show y %ci2`: Output of :yoscrypt:`show y %ci2` -From this we would learn that ``y`` is driven by a ``$dff cell``, that ``y`` is +From this we would learn that ``y`` is driven by a `$dff` cell, that ``y`` is connected to the output port ``Q``, that the ``clk`` signal goes into the ``CLK`` input port of the cell, and that the data comes from an auto-generated wire into the input ``D`` of the flip-flop cell (indicated by the ``$`` at the @@ -313,7 +313,7 @@ inputs. To add a pattern we add a colon followed by the pattern to the ``%ci`` action. The pattern itself starts with ``-`` or ``+``, indicating if it is an include or exclude pattern, followed by an optional comma separated list of cell types, followed by an optional comma separated list of port names in square -brackets. In this case, we want to exclude the ``S`` port of the ``$mux`` cell +brackets. In this case, we want to exclude the ``S`` port of the `$mux` cell type with :yoscrypt:`show y %ci5:-$mux[S]`: .. figure:: /_images/code_examples/selections/memdemo_03.* @@ -334,7 +334,7 @@ multiplexer select inputs and flip-flop cells: Output of ``show y %ci2:+$dff[Q,D] %ci*:-$mux[S]:-$dff`` Or we could use :yoscrypt:`show y %ci*:-[CLK,S]:+$dff:+$mux` instead, following -the input cone all the way but only following ``$dff`` and ``$mux`` cells, and +the input cone all the way but only following `$dff` and `$mux` cells, and ignoring any ports named ``CLK`` or ``S``: .. TODO:: pending discussion on whether rule ordering is a bug or a feature diff --git a/docs/source/using_yosys/synthesis/cell_libs.rst b/docs/source/using_yosys/synthesis/cell_libs.rst index 4e800bdf2b6..58b6431a588 100644 --- a/docs/source/using_yosys/synthesis/cell_libs.rst +++ b/docs/source/using_yosys/synthesis/cell_libs.rst @@ -98,8 +98,8 @@ our internal cell library will be mapped to: :name: mycells-lib :caption: :file:`mycells.lib` -Recall that the Yosys built-in logic gate types are ``$_NOT_``, ``$_AND_``, -``$_OR_``, ``$_XOR_``, and ``$_MUX_`` with an assortment of dff memory types. +Recall that the Yosys built-in logic gate types are `$_NOT_`, `$_AND_`, +`$_OR_`, `$_XOR_`, and `$_MUX_` with an assortment of dff memory types. :ref:`mycells-lib` defines our target cells as ``BUF``, ``NOT``, ``NAND``, ``NOR``, and ``DFF``. Mapping between these is performed with the commands :cmd:ref:`dfflibmap` and :cmd:ref:`abc` as follows: diff --git a/docs/source/using_yosys/synthesis/fsm.rst b/docs/source/using_yosys/synthesis/fsm.rst index e1ed5513397..3c5a80ad346 100644 --- a/docs/source/using_yosys/synthesis/fsm.rst +++ b/docs/source/using_yosys/synthesis/fsm.rst @@ -24,12 +24,12 @@ following description: - Does not already have the ``\fsm_encoding`` attribute. - Is not an output of the containing module. -- Is driven by single ``$dff`` or ``$adff`` cell. -- The ``\D``-Input of this ``$dff`` or ``$adff`` cell is driven by a +- Is driven by single `$dff` or `$adff` cell. +- The ``\D``-Input of this `$dff` or `$adff` cell is driven by a multiplexer tree that only has constants or the old state value on its leaves. - The state value is only used in the said multiplexer tree or by simple - relational cells that compare the state value to a constant (usually ``$eq`` + relational cells that compare the state value to a constant (usually `$eq` cells). This heuristic has proven to work very well. It is possible to overwrite it by @@ -64,9 +64,11 @@ information is determined: The state registers (and asynchronous reset state, if applicable) is simply determined by identifying the driver for the state signal. -From there the ``$mux-tree`` driving the state register inputs is recursively +.. todo:: Figure out what `$mux-tree` should actually be. + +From there the `$mux-tree` driving the state register inputs is recursively traversed. All select inputs are control signals and the leaves of the -``$mux-tree`` are the states. The algorithm fails if a non-constant leaf that is +`$mux-tree` are the states. The algorithm fails if a non-constant leaf that is not the state signal itself is found. The list of control outputs is initialized with the bits from the state signal. @@ -99,18 +101,18 @@ create a transition table. For each state: 6. If step 4 was successful: Emit transition -Finally a ``$fsm`` cell is created with the generated transition table and added +Finally a `$fsm` cell is created with the generated transition table and added to the module. This new cell is connected to the control signals and the old drivers for the control outputs are disconnected. FSM optimization ~~~~~~~~~~~~~~~~ -The :cmd:ref:`fsm_opt` pass performs basic optimizations on ``$fsm`` cells (not +The :cmd:ref:`fsm_opt` pass performs basic optimizations on `$fsm` cells (not including state recoding). The following optimizations are performed (in this order): -- Unused control outputs are removed from the ``$fsm`` cell. The attribute +- Unused control outputs are removed from the `$fsm` cell. The attribute ``\unused_bits`` (that is usually set by the :cmd:ref:`opt_clean` pass) is used to determine which control outputs are unused. diff --git a/docs/source/using_yosys/synthesis/memory.rst b/docs/source/using_yosys/synthesis/memory.rst index e95a648757a..dcbde2ae69b 100644 --- a/docs/source/using_yosys/synthesis/memory.rst +++ b/docs/source/using_yosys/synthesis/memory.rst @@ -75,7 +75,7 @@ For example: techmap -map my_memory_map.v memory_map -:cmd:ref:`memory_libmap` attempts to convert memory cells (``$mem_v2`` etc) into +:cmd:ref:`memory_libmap` attempts to convert memory cells (`$mem_v2` etc) into hardware supported memory using a provided library (:file:`my_memory_map.txt` in the example above). Where necessary, emulation logic is added to ensure functional equivalence before and after this conversion. :yoscrypt:`techmap -map @@ -171,10 +171,10 @@ In general, you can expect the automatic selection process to work roughly like This process can be overridden by attaching a ram_style attribute to the memory: -- `(* ram_style = "logic" *)` selects FF RAM -- `(* ram_style = "distributed" *)` selects LUT RAM -- `(* ram_style = "block" *)` selects block RAM -- `(* ram_style = "huge" *)` selects huge RAM +- ``(* ram_style = "logic" *)`` selects FF RAM +- ``(* ram_style = "distributed" *)`` selects LUT RAM +- ``(* ram_style = "block" *)`` selects block RAM +- ``(* ram_style = "huge" *)`` selects huge RAM It is an error if this override cannot be realized for the given target. diff --git a/docs/source/using_yosys/synthesis/opt.rst b/docs/source/using_yosys/synthesis/opt.rst index 2a06aadd118..cd40f699906 100644 --- a/docs/source/using_yosys/synthesis/opt.rst +++ b/docs/source/using_yosys/synthesis/opt.rst @@ -31,7 +31,7 @@ described in :doc:`/yosys_internals/formats/cell_library`. This means a cell with all constant inputs is replaced with the constant value this cell drives. In some cases this pass can also optimize cells with some constant inputs. -.. table:: Const folding rules for ``$_AND_`` cells as used in :cmd:ref:`opt_expr`. +.. table:: Const folding rules for `$_AND_` cells as used in :cmd:ref:`opt_expr`. :name: tab:opt_expr_and :align: center @@ -54,7 +54,7 @@ In some cases this pass can also optimize cells with some constant inputs. ========= ========= =========== :numref:`Table %s ` shows the replacement rules used for -optimizing an ``$_AND_`` gate. The first three rules implement the obvious const +optimizing an `$_AND_` gate. The first three rules implement the obvious const folding rules. Note that 'any' might include dynamic values calculated by other parts of the circuit. The following three lines propagate undef (X) states. These are the only three cases in which it is allowed to propagate an undef @@ -66,18 +66,18 @@ substitutions are possible they are performed first, in the hope that the 'any' will change to an undef value or a 1 and therefore the output can be set to undef. -The last two lines simply replace an ``$_AND_`` gate with one constant-1 input +The last two lines simply replace an `$_AND_` gate with one constant-1 input with a buffer. Besides this basic const folding the :cmd:ref:`opt_expr` pass can replace 1-bit -wide ``$eq`` and ``$ne`` cells with buffers or not-gates if one input is +wide `$eq` and `$ne` cells with buffers or not-gates if one input is constant. Equality checks may also be reduced in size if there are redundant bits in the arguments (i.e. bits which are constant on both inputs). This can, for example, result in a 32-bit wide constant like ``255`` being reduced to the 8-bit value of ``8'11111111`` if the signal being compared is only 8-bit as in :ref:`addr_gen_clean` of :doc:`/getting_started/example_synth`. -The :cmd:ref:`opt_expr` pass is very conservative regarding optimizing ``$mux`` +The :cmd:ref:`opt_expr` pass is very conservative regarding optimizing `$mux` cells, as these cells are often used to model decision-trees and breaking these trees can interfere with other optimizations. @@ -100,7 +100,7 @@ identifies cells with identical inputs and replaces them with a single instance of the cell. The option ``-nomux`` can be used to disable resource sharing for multiplexer -cells (``$mux`` and ``$pmux``.) This can be useful as it prevents multiplexer +cells (`$mux` and `$pmux`.) This can be useful as it prevents multiplexer trees to be merged, which might prevent :cmd:ref:`opt_muxtree` to identify possible optimizations. @@ -141,16 +141,16 @@ Simplifying large MUXes and AND/OR gates - :cmd:ref:`opt_reduce` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is a simple optimization pass that identifies and consolidates identical -input bits to ``$reduce_and`` and ``$reduce_or`` cells. It also sorts the input -bits to ease identification of shareable ``$reduce_and`` and ``$reduce_or`` +input bits to `$reduce_and` and `$reduce_or` cells. It also sorts the input +bits to ease identification of shareable `$reduce_and` and `$reduce_or` cells in other passes. This pass also identifies and consolidates identical inputs to multiplexer -cells. In this case the new shared select bit is driven using a ``$reduce_or`` +cells. In this case the new shared select bit is driven using a `$reduce_or` cell that combines the original select bits. -Lastly this pass consolidates trees of ``$reduce_and`` cells and trees of -``$reduce_or`` cells to single large ``$reduce_and`` or ``$reduce_or`` cells. +Lastly this pass consolidates trees of `$reduce_and` cells and trees of +`$reduce_or` cells to single large `$reduce_and` or `$reduce_or` cells. These three simple optimizations are performed in a loop until a stable result is produced. @@ -160,7 +160,7 @@ Merging mutually exclusive cells with shared inputs - :cmd:ref:`opt_share` This pass identifies mutually exclusive cells of the same type that: a. share an input signal, and - b. drive the same ``$mux``, ``$_MUX_``, or ``$pmux`` multiplexing cell, + b. drive the same `$mux`, `$_MUX_`, or `$pmux` multiplexing cell, allowing the cell to be merged and the multiplexer to be moved from multiplexing its output to multiplexing the non-shared input signals. @@ -176,14 +176,14 @@ multiplexing its output to multiplexing the non-shared input signals. Before and after :cmd:ref:`opt_share` -When running :cmd:ref:`opt` in full, the original ``$mux`` (labeled ``$3``) is +When running :cmd:ref:`opt` in full, the original `$mux` (labeled ``$3``) is optimized away by :cmd:ref:`opt_expr`. Performing DFF optimizations - :cmd:ref:`opt_dff` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -This pass identifies single-bit d-type flip-flops (``$_DFF_``, ``$dff``, and -``$adff`` cells) with a constant data input and replaces them with a constant +This pass identifies single-bit d-type flip-flops (`$_DFF_`, `$dff`, and +`$adff` cells) with a constant data input and replaces them with a constant driver. It can also merge clock enables and synchronous reset multiplexers, removing unused control inputs. diff --git a/docs/source/yosys_internals/flow/verilog_frontend.rst b/docs/source/yosys_internals/flow/verilog_frontend.rst index f2eaeae97b3..7c8c9d8fbad 100644 --- a/docs/source/yosys_internals/flow/verilog_frontend.rst +++ b/docs/source/yosys_internals/flow/verilog_frontend.rst @@ -627,7 +627,7 @@ from a behavioural model to an RTL representation is performed by the asynchronous resets if necessary). - | :cmd:ref:`proc_dff` - | This pass replaces the ``RTLIL::MemWriteAction``\ s with ``$memwr`` cells. + | This pass replaces the ``RTLIL::MemWriteAction``\ s with `$memwr` cells. - | :cmd:ref:`proc_clean` | A final call to :cmd:ref:`proc_clean` removes the now empty @@ -646,7 +646,7 @@ to extend the actual Verilog frontend. .. todo:: Synthesizing Verilog arrays - Add some information on the generation of ``$memrd`` and ``$memwr`` cells and + Add some information on the generation of `$memrd` and `$memwr` cells and how they are processed in the memory pass. diff --git a/docs/source/yosys_internals/formats/cell_library.rst b/docs/source/yosys_internals/formats/cell_library.rst index 2e30ee25c5d..cd1496e11e4 100644 --- a/docs/source/yosys_internals/formats/cell_library.rst +++ b/docs/source/yosys_internals/formats/cell_library.rst @@ -73,15 +73,15 @@ also have the following parameters: :verilog:`Y = !A` $logic_not ================== ============ -For the unary cells that output a logical value (``$reduce_and``, -``$reduce_or``, ``$reduce_xor``, ``$reduce_xnor``, ``$reduce_bool``, -``$logic_not``), when the ``\Y_WIDTH`` parameter is greater than 1, the output +For the unary cells that output a logical value (`$reduce_and`, +`$reduce_or`, `$reduce_xor`, `$reduce_xnor`, `$reduce_bool`, +`$logic_not`), when the ``\Y_WIDTH`` parameter is greater than 1, the output is zero-extended, and only the least significant bit varies. -Note that ``$reduce_or`` and ``$reduce_bool`` actually represent the same logic +Note that `$reduce_or` and `$reduce_bool` actually represent the same logic function. But the HDL frontends generate them in different situations. A -``$reduce_or`` cell is generated when the prefix ``|`` operator is being used. A -``$reduce_bool`` cell is generated when a bit vector is used as a condition in +`$reduce_or` cell is generated when the prefix ``|`` operator is being used. A +`$reduce_bool` cell is generated when a bit vector is used as a condition in an ``if``-statement or ``?:``-expression. Binary operators @@ -130,28 +130,28 @@ All binary RTL cells have two input ports ``\A`` and ``\B`` and one output port :verilog:`Y = A ** B` $pow ``N/A`` $modfloor ======================= ============= ======================= ========= -The ``$shl`` and ``$shr`` cells implement logical shifts, whereas the ``$sshl`` -and ``$sshr`` cells implement arithmetic shifts. The ``$shl`` and ``$sshl`` +The `$shl` and `$shr` cells implement logical shifts, whereas the `$sshl` +and `$sshr` cells implement arithmetic shifts. The `$shl` and `$sshl` cells implement the same operation. All four of these cells interpret the second operand as unsigned, and require ``\B_SIGNED`` to be zero. Two additional shift operator cells are available that do not directly -correspond to any operator in Verilog, ``$shift`` and ``$shiftx``. The -``$shift`` cell performs a right logical shift if the second operand is positive -(or unsigned), and a left logical shift if it is negative. The ``$shiftx`` cell -performs the same operation as the ``$shift`` cell, but the vacated bit +correspond to any operator in Verilog, `$shift` and `$shiftx`. The +`$shift` cell performs a right logical shift if the second operand is positive +(or unsigned), and a left logical shift if it is negative. The `$shiftx` cell +performs the same operation as the `$shift` cell, but the vacated bit positions are filled with undef (x) bits, and corresponds to the Verilog indexed part-select expression. -For the binary cells that output a logical value (``$logic_and``, ``$logic_or``, -``$eqx``, ``$nex``, ``$lt``, ``$le``, ``$eq``, ``$ne``, ``$ge``, ``$gt``), when +For the binary cells that output a logical value (`$logic_and`, `$logic_or`, +`$eqx`, `$nex`, `$lt`, `$le`, `$eq`, `$ne`, `$ge`, `$gt`), when the ``\Y_WIDTH`` parameter is greater than 1, the output is zero-extended, and only the least significant bit varies. Division and modulo cells are available in two rounding modes. The original -``$div`` and ``$mod`` cells are based on truncating division, and correspond to -the semantics of the verilog ``/`` and ``%`` operators. The ``$divfloor`` and -``$modfloor`` cells represent flooring division and flooring modulo, the latter +`$div` and `$mod` cells are based on truncating division, and correspond to +the semantics of the verilog ``/`` and ``%`` operators. The `$divfloor` and +`$modfloor` cells represent flooring division and flooring modulo, the latter of which is also known as "remainder" in several languages. See :numref:`tab:CellLib_divmod` for a side-by-side comparison between the different semantics. @@ -180,14 +180,14 @@ Multiplexers are generated by the Verilog HDL frontend for ``?:``-expressions. Multiplexers are also generated by the proc pass to map the decision trees from RTLIL::Process objects to logic. -The simplest multiplexer cell type is ``$mux``. Cells of this type have a +The simplest multiplexer cell type is `$mux`. Cells of this type have a ``\WITDH`` parameter and data inputs ``\A`` and ``\B`` and a data output ``\Y``, all of the specified width. This cell also has a single bit control input ``\S``. If ``\S`` is 0 the value from the input ``\A`` is sent to the output, if -it is 1 the value from the ``\B`` input is sent to the output. So the ``$mux`` +it is 1 the value from the ``\B`` input is sent to the output. So the `$mux` cell implements the function :verilog:`Y = S ? B : A`. -The ``$pmux`` cell is used to multiplex between many inputs using a one-hot +The `$pmux` cell is used to multiplex between many inputs using a one-hot select signal. Cells of this type have a ``\WIDTH`` and a ``\S_WIDTH`` parameter and inputs ``\A``, ``\B``, and ``\S`` and an output ``\Y``. The ``\S`` input is ``\S_WIDTH`` bits wide. The ``\A`` input and the output are both ``\WIDTH`` bits @@ -199,24 +199,24 @@ from ``\S`` is set the output is undefined. Cells of this type are used to model "parallel cases" (defined by using the ``parallel_case`` attribute or detected by an optimization). -The ``$tribuf`` cell is used to implement tristate logic. Cells of this type +The `$tribuf` cell is used to implement tristate logic. Cells of this type have a ``\WIDTH`` parameter and inputs ``\A`` and ``\EN`` and an output ``\Y``. The ``\A`` input and ``\Y`` output are ``\WIDTH`` bits wide, and the ``\EN`` input is one bit wide. When ``\EN`` is 0, the output is not driven. When ``\EN`` is 1, the value from ``\A`` input is sent to the ``\Y`` output. Therefore, the -``$tribuf`` cell implements the function :verilog:`Y = EN ? A : 'bz`. +`$tribuf` cell implements the function :verilog:`Y = EN ? A : 'bz`. Behavioural code with cascaded if-then-else- and 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 ``$and`` gate). +constant zero with an `$and` gate). Registers ~~~~~~~~~ -SR-type latches are represented by ``$sr`` cells. These cells have input ports +SR-type latches are represented by `$sr` cells. These cells have input ports ``\SET`` and ``\CLR`` and an output port ``\Q``. They have the following parameters: @@ -232,12 +232,12 @@ parameters: ``1'b1`` and active-low if this parameter is ``1'b0``. Both set and reset inputs have separate bits for every output bit. When both the -set and reset inputs of an ``$sr`` cell are active for a given bit index, the +set and reset inputs of an `$sr` cell are active for a given bit index, the reset input takes precedence. -D-type flip-flops are represented by ``$dff`` cells. These cells have a clock +D-type flip-flops are represented by `$dff` cells. These cells have a clock port ``\CLK``, an input port ``\D`` and an output port ``\Q``. The following -parameters are available for ``$dff`` cells: +parameters are available for `$dff` cells: ``\WIDTH`` The width of input ``\D`` and output ``\Q``. @@ -246,8 +246,8 @@ parameters are available for ``$dff`` cells: Clock is active on the positive edge if this parameter has the value ``1'b1`` and on the negative edge if this parameter is ``1'b0``. -D-type flip-flops with asynchronous reset are represented by ``$adff`` cells. As -the ``$dff`` cells they have ``\CLK``, ``\D`` and ``\Q`` ports. In addition they +D-type flip-flops with asynchronous reset are represented by `$adff` cells. As +the `$dff` cells they have ``\CLK``, ``\D`` and ``\Q`` ports. In addition they also have a single-bit ``\ARST`` input port for the reset pin and the following additional two parameters: @@ -261,8 +261,8 @@ additional two parameters: Usually these cells are generated by the :cmd:ref:`proc` pass using the information in the designs RTLIL::Process objects. -D-type flip-flops with synchronous reset are represented by ``$sdff`` cells. As -the ``$dff`` cells they have ``\CLK``, ``\D`` and ``\Q`` ports. In addition they +D-type flip-flops with synchronous reset are represented by `$sdff` cells. As +the `$dff` cells they have ``\CLK``, ``\D`` and ``\Q`` ports. In addition they also have a single-bit ``\SRST`` input port for the reset pin and the following additional two parameters: @@ -273,11 +273,11 @@ additional two parameters: ``\SRST_VALUE`` The state of ``\Q`` will be set to this value when the reset is active. -Note that the ``$adff`` and ``$sdff`` cells can only be used when the reset +Note that the `$adff` and `$sdff` cells can only be used when the reset value is constant. -D-type flip-flops with asynchronous load are represented by ``$aldff`` cells. As -the ``$dff`` cells they have ``\CLK``, ``\D`` and ``\Q`` ports. In addition they +D-type flip-flops with asynchronous load are represented by `$aldff` cells. As +the `$dff` cells they have ``\CLK``, ``\D`` and ``\Q`` ports. In addition they also have a single-bit ``\ALOAD`` input port for the async load enable pin, a ``\AD`` input port with the same width as data for the async load data, and the following additional parameter: @@ -286,15 +286,15 @@ following additional parameter: The asynchronous load is active-high if this parameter has the value ``1'b1`` and active-low if this parameter is ``1'b0``. -D-type flip-flops with asynchronous set and reset are represented by ``$dffsr`` -cells. As the ``$dff`` cells they have ``\CLK``, ``\D`` and ``\Q`` ports. In +D-type flip-flops with asynchronous set and reset are represented by `$dffsr` +cells. As the `$dff` cells they have ``\CLK``, ``\D`` and ``\Q`` ports. In addition they also have multi-bit ``\SET`` and ``\CLR`` input ports and the -corresponding polarity parameters, like ``$sr`` cells. +corresponding polarity parameters, like `$sr` cells. -D-type flip-flops with enable are represented by ``$dffe``, ``$adffe``, -``$aldffe``, ``$dffsre``, ``$sdffe``, and ``$sdffce`` cells, which are enhanced -variants of ``$dff``, ``$adff``, ``$aldff``, ``$dffsr``, ``$sdff`` (with reset -over enable) and ``$sdff`` (with enable over reset) cells, respectively. They +D-type flip-flops with enable are represented by `$dffe`, `$adffe`, +`$aldffe`, `$dffsre`, `$sdffe`, and `$sdffce` cells, which are enhanced +variants of `$dff`, `$adff`, `$aldff`, `$dffsr`, `$sdff` (with reset +over enable) and `$sdff` (with enable over reset) cells, respectively. They have the same ports and parameters as their base cell. In addition they also have a single-bit ``\EN`` input port for the enable pin and the following parameter: @@ -303,9 +303,9 @@ parameter: The enable input is active-high if this parameter has the value ``1'b1`` and active-low if this parameter is ``1'b0``. -D-type latches are represented by ``$dlatch`` cells. These cells have an enable +D-type latches are represented by `$dlatch` cells. These cells have an enable port ``\EN``, an input port ``\D``, and an output port ``\Q``. The following -parameters are available for ``$dlatch`` cells: +parameters are available for `$dlatch` cells: ``\WIDTH`` The width of input ``\D`` and output ``\Q``. @@ -316,8 +316,8 @@ parameters are available for ``$dlatch`` cells: The latch is transparent when the ``\EN`` input is active. -D-type latches with reset are represented by ``$adlatch`` cells. In addition to -``$dlatch`` ports and parameters, they also have a single-bit ``\ARST`` input +D-type latches with reset are represented by `$adlatch` cells. In addition to +`$dlatch` ports and parameters, they also have a single-bit ``\ARST`` input port for the reset pin and the following additional parameters: ``\ARST_POLARITY`` @@ -327,9 +327,9 @@ port for the reset pin and the following additional parameters: ``\ARST_VALUE`` The state of ``\Q`` will be set to this value when the reset is active. -D-type latches with set and reset are represented by ``$dlatchsr`` cells. In -addition to ``$dlatch`` ports and parameters, they also have multi-bit ``\SET`` -and ``\CLR`` input ports and the corresponding polarity parameters, like ``$sr`` +D-type latches with set and reset are represented by `$dlatchsr` cells. In +addition to `$dlatch` ports and parameters, they also have multi-bit ``\SET`` +and ``\CLR`` input ports and the corresponding polarity parameters, like `$sr` cells. .. _sec:memcells: @@ -337,20 +337,20 @@ cells. Memories ~~~~~~~~ -Memories are either represented using ``RTLIL::Memory`` objects, ``$memrd_v2``, -``$memwr_v2``, and ``$meminit_v2`` cells, or by ``$mem_v2`` cells alone. +Memories are either represented using ``RTLIL::Memory`` objects, `$memrd_v2`, +`$memwr_v2`, and `$meminit_v2` cells, or by `$mem_v2` 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 -``$memrd_v2`` (read port) or ``$memwr_v2`` (write port) cell is created. Having +`$memrd_v2` (read port) or `$memwr_v2` (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 ``$meminit_v2`` cells, which allow +memory initialization data is represented by `$meminit_v2` cells, which allow delaying constant folding for initialization addresses and data until after the frontend finishes. -The ``$memrd_v2`` cells have a clock input ``\CLK``, an enable input ``\EN``, an +The `$memrd_v2` cells have a clock input ``\CLK``, an enable input ``\EN``, an address input ``\ADDR``, a data output ``\DATA``, an asynchronous reset input ``\ARST``, and a synchronous reset input ``\SRST``. They also have the following parameters: @@ -411,7 +411,7 @@ parameters: when ``\EN`` is true. Otherwise, ``\SRST`` is recognized regardless of ``\EN``. -The ``$memwr_v2`` cells have a clock input ``\CLK``, an enable input ``\EN`` +The `$memwr_v2` cells have a clock input ``\CLK``, an enable input ``\EN`` (one enable bit for each data bit), an address input ``\ADDR`` and a data input ``\DATA``. They also have the following parameters: @@ -424,7 +424,7 @@ The ``$memwr_v2`` cells have a clock input ``\CLK``, an enable input ``\EN`` ``\WIDTH`` The number of data bits (width of the ``\DATA`` output port). Like with - ``$memrd_v2`` cells, the width is allowed to be any power-of-two + `$memrd_v2` cells, the width is allowed to be any power-of-two multiple of memory width, with the corresponding restriction on address. ``\CLK_ENABLE`` @@ -448,7 +448,7 @@ The ``$memwr_v2`` cells have a clock input ``\CLK``, an enable input ``\EN`` undefined. Priority can only be set between two synchronous ports sharing the same clock domain. -The ``$meminit_v2`` cells have an address input ``\ADDR``, a data input +The `$meminit_v2` cells have an address input ``\ADDR``, a data input ``\DATA``, with the width of the ``\DATA`` port equal to ``\WIDTH`` parameter times ``\WORDS`` parameter, and a bit enable mask input ``\EN`` with width equal to ``\WIDTH`` parameter. All three of the inputs must resolve to a constant for @@ -472,19 +472,19 @@ synthesis to succeed. initialization conflict. The HDL frontend models a memory using ``RTLIL::Memory`` objects and -asynchronous ``$memrd_v2`` and ``$memwr_v2`` cells. The :cmd:ref:`memory` pass -(i.e. its various sub-passes) migrates ``$dff`` cells into the ``$memrd_v2`` and -``$memwr_v2`` cells making them synchronous, then converts them to a single -``$mem_v2`` cell and (optionally) maps this cell type to ``$dff`` cells for the +asynchronous `$memrd_v2` and `$memwr_v2` cells. The :cmd:ref:`memory` pass +(i.e. its various sub-passes) migrates `$dff` cells into the `$memrd_v2` and +`$memwr_v2` cells making them synchronous, then converts them to a single +`$mem_v2` cell and (optionally) maps this cell type to `$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 ``$mem_v2`` cell +interfaces. When the last step is disabled or not possible, a `$mem_v2` cell is left in the design. -The ``$mem_v2`` cell provides the following parameters: +The `$mem_v2` cell provides the following parameters: ``\MEMID`` The name of the original ``RTLIL::Memory`` object that became this - ``$mem_v2`` cell. + `$mem_v2` cell. ``\SIZE`` The number of words in the memory. @@ -519,12 +519,12 @@ The ``$mem_v2`` cell provides the following parameters: ``\RD_TRANSPARENCY_MASK`` This parameter is ``\RD_PORTS*\WR_PORTS`` bits wide, containing a concatenation of all ``\TRANSPARENCY_MASK`` values of the original - ``$memrd_v2`` cells. + `$memrd_v2` cells. ``\RD_COLLISION_X_MASK`` This parameter is ``\RD_PORTS*\WR_PORTS`` bits wide, containing a concatenation of all ``\COLLISION_X_MASK`` values of the original - ``$memrd_v2`` cells. + `$memrd_v2` cells. ``\RD_CE_OVER_SRST`` This parameter is ``\RD_PORTS`` bits wide, determining relative @@ -560,9 +560,9 @@ The ``$mem_v2`` cell provides the following parameters: ``\WR_PRIORITY_MASK`` This parameter is ``\WR_PORTS*\WR_PORTS`` bits wide, containing a concatenation of all ``\PRIORITY_MASK`` values of the original - ``$memwr_v2`` cells. + `$memwr_v2` cells. -The ``$mem_v2`` cell has the following ports: +The `$mem_v2` cell has the following ports: ``\RD_CLK`` This input is ``\RD_PORTS`` bits wide, containing all clock signals for @@ -605,24 +605,24 @@ The ``$mem_v2`` cell has the following ports: signals for the write ports. The :cmd:ref:`memory_collect` pass can be used to convert discrete -``$memrd_v2``, ``$memwr_v2``, and ``$meminit_v2`` cells belonging to the same -memory to a single ``$mem_v2`` cell, whereas the :cmd:ref:`memory_unpack` pass +`$memrd_v2`, `$memwr_v2`, and `$meminit_v2` cells belonging to the same +memory to a single `$mem_v2` cell, whereas the :cmd:ref:`memory_unpack` pass performs the inverse operation. The :cmd:ref:`memory_dff` pass can combine asynchronous memory ports that are fed by or feeding registers into synchronous memory ports. The :cmd:ref:`memory_bram` pass can be used to recognize -``$mem_v2`` cells that can be implemented with a block RAM resource on an FPGA. -The :cmd:ref:`memory_map` pass can be used to implement ``$mem_v2`` cells as +`$mem_v2` cells that can be implemented with a block RAM resource on an FPGA. +The :cmd:ref:`memory_map` pass can be used to implement `$mem_v2` cells as basic logic: word-wide DFFs and address decoders. Finite state machines ~~~~~~~~~~~~~~~~~~~~~ -Add a brief description of the ``$fsm`` cell type. +Add a brief description of the `$fsm` cell type. Coarse arithmetics ~~~~~~~~~~~~~~~~~~~~~ -The ``$macc`` cell type represents a generalized multiply and accumulate operation. The cell is purely combinational. It outputs the result of summing up a sequence of products and other injected summands. +The `$macc` cell type represents a generalized multiply and accumulate operation. The cell is purely combinational. It outputs the result of summing up a sequence of products and other injected summands. .. code-block:: @@ -708,21 +708,21 @@ in the ``\TABLE`` values. Specify rules ~~~~~~~~~~~~~ -Add information about ``$specify2``, ``$specify3``, and ``$specrule`` cells. +Add information about `$specify2`, `$specify3`, and `$specrule` cells. Formal verification cells ~~~~~~~~~~~~~~~~~~~~~~~~~ -Add information about ``$check``, ``$assert``, ``$assume``, ``$live``, ``$fair``, -``$cover``, ``$equiv``, ``$initstate``, ``$anyconst``, ``$anyseq``, -``$anyinit``, ``$allconst``, ``$allseq`` cells. +Add information about `$check`, `$assert`, `$assume`, `$live`, `$fair`, +`$cover`, `$equiv`, `$initstate`, `$anyconst`, `$anyseq`, +`$anyinit`, `$allconst`, `$allseq` cells. -Add information about ``$ff`` and ``$_FF_`` cells. +Add information about `$ff` and `$_FF_` cells. Debugging cells ~~~~~~~~~~~~~~~ -The ``$print`` cell is used to log the values of signals, akin to (and +The `$print` cell is used to log the values of signals, akin to (and translatable to) the ``$display`` and ``$write`` family of tasks in Verilog. It has the following parameters: @@ -746,13 +746,14 @@ If ``\TRG_ENABLE`` is true, the following parameters also apply: negative-edge triggered. ``\PRIORITY`` - When multiple ``$print`` or ``$$check`` cells fire on the same trigger, they\ + When multiple `$print` or `$check` cells fire on the same trigger, they execute in descending priority order. Ports: ``\TRG`` - The signals that control when this ``$print`` cell is triggered. + The signals that control when this `$print` cell is triggered. + If the width of this port is zero and ``\TRG_ENABLE`` is true, the cell is triggered during initial evaluation (time zero) only. @@ -1040,14 +1041,14 @@ Tables :numref:`%s `, :numref:`%s `, :numref:`%s `, :numref:`%s `, :numref:`%s `, :numref:`%s ` and :numref:`%s ` list all -cell types used for gate level logic. The cell types ``$_BUF_``, ``$_NOT_``, -``$_AND_``, ``$_NAND_``, ``$_ANDNOT_``, ``$_OR_``, ``$_NOR_``, ``$_ORNOT_``, -``$_XOR_``, ``$_XNOR_``, ``$_AOI3_``, ``$_OAI3_``, ``$_AOI4_``, ``$_OAI4_``, -``$_MUX_``, ``$_MUX4_``, ``$_MUX8_``, ``$_MUX16_`` and ``$_NMUX_`` are used to -model combinatorial logic. The cell type ``$_TBUF_`` is used to model tristate +cell types used for gate level logic. The cell types `$_BUF_`, `$_NOT_`, +`$_AND_`, `$_NAND_`, `$_ANDNOT_`, `$_OR_`, `$_NOR_`, `$_ORNOT_`, +`$_XOR_`, `$_XNOR_`, `$_AOI3_`, `$_OAI3_`, `$_AOI4_`, `$_OAI4_`, +`$_MUX_`, `$_MUX4_`, `$_MUX8_`, `$_MUX16_` and `$_NMUX_` are used to +model combinatorial logic. The cell type `$_TBUF_` is used to model tristate logic. -The ``$_MUX4_``, ``$_MUX8_`` and ``$_MUX16_`` cells are used to model wide +The `$_MUX4_`, `$_MUX8_` and `$_MUX16_` cells are used to model wide muxes, and correspond to the following Verilog code: .. code-block:: verilog @@ -1071,7 +1072,7 @@ muxes, and correspond to the following Verilog code: T ? (S ? D : C) : (S ? B : A); -The cell types ``$_DFF_N_`` and ``$_DFF_P_`` represent d-type flip-flops. +The cell types `$_DFF_N_` and `$_DFF_P_` represent d-type flip-flops. The cell types ``$_DFFE_[NP][NP]_`` implement d-type flip-flops with enable. The values in the table for these cell types relate to the following Verilog code @@ -1186,7 +1187,7 @@ is ``posedge`` if ``SET_LVL`` if ``1``, ``negedge`` otherwise. else if (E == EN_LVL) Q <= D; -The cell types ``$_DLATCH_N_`` and ``$_DLATCH_P_`` represent d-type latches. +The cell types `$_DLATCH_N_` and `$_DLATCH_P_` represent d-type latches. The cell types ``$_DLATCH_[NP][NP][01]_`` implement d-type latches with reset. The values in the table for these cell types relate to the following Verilog @@ -1234,8 +1235,8 @@ mapped to physical flip-flop cells from a Liberty file using the dfflibmap pass. The combinatorial logic cells can be mapped to physical cells from a Liberty file via ABC using the abc pass. -.. todo:: Add information about ``$slice`` and ``$concat`` cells. +.. todo:: Add information about `$slice` and `$concat` cells. -.. todo:: Add information about ``$alu``, ``$fa``, and ``$lcu`` cells. +.. todo:: Add information about `$alu`, `$fa`, and `$lcu` cells. .. todo:: Add information about ``$demux`` cell. \ No newline at end of file diff --git a/docs/source/yosys_internals/formats/rtlil_rep.rst b/docs/source/yosys_internals/formats/rtlil_rep.rst index 2737cd4bd46..785a2d28b38 100644 --- a/docs/source/yosys_internals/formats/rtlil_rep.rst +++ b/docs/source/yosys_internals/formats/rtlil_rep.rst @@ -79,7 +79,7 @@ This has three advantages: example, :cmd:ref:`opt_clean` tries to preserve signals with a user-provided name but doesn't hesitate to delete signals that have auto-generated names when they just duplicate other signals. Note that this can be overridden - with the `-purge` option to also delete internal nets with user-provided + with the ``-purge`` option to also delete internal nets with user-provided names. - Third, the delicate job of finding suitable auto-generated public visible @@ -366,7 +366,7 @@ multiplexer for the enable signal: end Different combinations of passes may yield different results. Note that -``$adff`` and ``$mux`` are internal cell types that still need to be mapped to +`$adff` and `$mux` are internal cell types that still need to be mapped to cell types from the target cell library. Some passes refuse to operate on modules that still contain ``RTLIL::Process`` @@ -389,25 +389,25 @@ A memory object has the following properties: - The width of an addressable word - The size of the memory in number of words -All read accesses to the memory are transformed to ``$memrd`` cells and all -write accesses to ``$memwr`` cells by the language frontend. These cells consist +All read accesses to the memory are transformed to `$memrd` cells and all +write accesses to `$memwr` cells by the language frontend. These cells consist of independent read- and write-ports to the memory. Memory initialization is -transformed to ``$meminit`` cells by the language frontend. The ``\MEMID`` +transformed to `$meminit` cells by the language frontend. The ``\MEMID`` parameter on these cells is used to link them together and to the ``RTLIL::Memory`` object they belong to. The rationale behind using separate cells for the individual ports versus creating a large multiport memory cell right in the language frontend is that -the separate ``$memrd`` and ``$memwr`` cells can be consolidated using resource +the separate `$memrd` and `$memwr` cells can be consolidated using resource sharing. As resource sharing is a non-trivial optimization problem where different synthesis tasks can have different requirements it lends itself to do the optimisation in separate passes and merge the ``RTLIL::Memory`` objects and -``$memrd`` and ``$memwr`` cells to multiport memory blocks after resource +`$memrd` and `$memwr` cells to multiport memory blocks after resource sharing is completed. The memory pass performs this conversion and can (depending on the options passed to it) transform the memories directly to d-type flip-flops and address -logic or yield multiport memory blocks (represented using ``$mem`` cells). +logic or yield multiport memory blocks (represented using `$mem` cells). See :ref:`sec:memcells` for details about the memory cell types. diff --git a/docs/source/yosys_internals/techmap.rst b/docs/source/yosys_internals/techmap.rst index 00fce26bd4f..e5d6972ee78 100644 --- a/docs/source/yosys_internals/techmap.rst +++ b/docs/source/yosys_internals/techmap.rst @@ -3,7 +3,7 @@ Techmap by example As a quick recap, the :cmd:ref:`techmap` command replaces cells in the design with implementations given as Verilog code (called "map files"). It can replace -Yosys' internal cell types (such as ``$or``) as well as user-defined cell types. +Yosys' internal cell types (such as `$or`) as well as user-defined cell types. - Verilog parameters are used extensively to customize the internal cell types. - Additional special parameters are used by techmap to communicate meta-data to From 829e02ec5b2bcdfc5a6ee308c62836bfcea248f9 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Fri, 3 May 2024 13:16:48 +1200 Subject: [PATCH 15/68] Docs: Shorten cmd:ref --- docs/source/appendix/auxlibs.rst | 14 +- docs/source/appendix/env_vars.rst | 2 +- docs/source/getting_started/example_synth.rst | 162 +++++++++--------- docs/source/getting_started/installation.rst | 6 +- .../getting_started/scripting_intro.rst | 41 +++-- .../interactive_investigation.rst | 104 +++++------ .../more_scripting/model_checking.rst | 2 +- .../using_yosys/more_scripting/selections.rst | 30 ++-- docs/source/using_yosys/synthesis/abc.rst | 20 +-- .../using_yosys/synthesis/cell_libs.rst | 8 +- docs/source/using_yosys/synthesis/extract.rst | 20 +-- docs/source/using_yosys/synthesis/fsm.rst | 18 +- docs/source/using_yosys/synthesis/index.rst | 12 +- docs/source/using_yosys/synthesis/memory.rst | 24 +-- docs/source/using_yosys/synthesis/opt.rst | 66 +++---- docs/source/using_yosys/synthesis/proc.rst | 10 +- docs/source/using_yosys/synthesis/synth.rst | 2 +- .../extending_yosys/extensions.rst | 6 +- .../yosys_internals/flow/verilog_frontend.rst | 20 +-- .../yosys_internals/formats/cell_library.rst | 14 +- .../yosys_internals/formats/rtlil_rep.rst | 4 +- docs/source/yosys_internals/techmap.rst | 8 +- 22 files changed, 296 insertions(+), 297 deletions(-) diff --git a/docs/source/appendix/auxlibs.rst b/docs/source/appendix/auxlibs.rst index 321cb52c4d1..8c78ed6b3d2 100644 --- a/docs/source/appendix/auxlibs.rst +++ b/docs/source/appendix/auxlibs.rst @@ -29,7 +29,7 @@ ezSAT The files in ``libs/ezsat`` provide a library for simplifying generating CNF formulas for SAT solvers. It also contains bindings of MiniSAT. The ezSAT -library is written by C. Wolf. It is used by the :cmd:ref:`sat` pass (see +library is written by C. Wolf. It is used by the `sat` pass (see :doc:`/cmd/sat`). fst @@ -37,22 +37,22 @@ fst ``libfst`` files from `gtkwave`_ are included in ``libs/fst`` to support reading/writing signal traces from/to the GTKWave developed FST format. This is -primarily used in the :cmd:ref:`sim` command. +primarily used in the `sim` command. .. _gtkwave: https://github.com/gtkwave/gtkwave json11 ------ -For reading/writing designs from/to JSON, :cmd:ref:`read_json` and -:cmd:ref:`write_json` should be used. For everything else there is the `json11 +For reading/writing designs from/to JSON, `read_json` and +`write_json` should be used. For everything else there is the `json11 library`_: json11 is a tiny JSON library for C++11, providing JSON parsing and serialization. -This library is used for outputting machine-readable statistics (:cmd:ref:`stat` -with ``-json`` flag), using the RPC frontend (:cmd:ref:`connect_rpc`), and the +This library is used for outputting machine-readable statistics (`stat` +with ``-json`` flag), using the RPC frontend (`connect_rpc`), and the yosys-witness ``yw`` format. .. _json11 library: https://github.com/dropbox/json11 @@ -61,7 +61,7 @@ MiniSAT ------- The files in ``libs/minisat`` provide a high-performance SAT solver, used by the -:cmd:ref:`sat` command. +`sat` command. SHA1 ---- diff --git a/docs/source/appendix/env_vars.rst b/docs/source/appendix/env_vars.rst index 26cc37c8133..69e86c922ad 100644 --- a/docs/source/appendix/env_vars.rst +++ b/docs/source/appendix/env_vars.rst @@ -3,7 +3,7 @@ Yosys environment variables ``HOME`` Yosys command history is stored in :file:`$HOME/.yosys_history`. Graphics - (from :cmd:ref:`show` and :cmd:ref:`viz` commands) will output to this + (from `show` and `viz` commands) will output to this directory by default. This environment variable is also used in some cases for resolving filenames with :file:`~`. diff --git a/docs/source/getting_started/example_synth.rst b/docs/source/getting_started/example_synth.rst index 28e74ecc0d2..ec1f967ea48 100644 --- a/docs/source/getting_started/example_synth.rst +++ b/docs/source/getting_started/example_synth.rst @@ -2,9 +2,9 @@ Synthesis starter ----------------- This page will be a guided walkthrough of the prepackaged iCE40 FPGA synthesis -script - :cmd:ref:`synth_ice40`. We will take a simple design through each +script - `synth_ice40`. We will take a simple design through each step, looking at the commands being called and what they do to the design. While -:cmd:ref:`synth_ice40` is specific to the iCE40 platform, most of the operations +`synth_ice40` is specific to the iCE40 platform, most of the operations we will be discussing are common across the majority of FPGA synthesis scripts. Thus, this document will provide a good foundational understanding of how synthesis in Yosys is performed, regardless of the actual architecture being @@ -59,8 +59,8 @@ can run each of the commands individually for a better sense of how each part contributes to the flow. We will also start with just a single module; ``addr_gen``. -At the bottom of the :cmd:ref:`help` output for -:cmd:ref:`synth_ice40` is the complete list of commands called by this script. +At the bottom of the `help` output for +`synth_ice40` is the complete list of commands called by this script. Let's start with the section labeled ``begin``: .. literalinclude:: /cmd/synth_ice40.rst @@ -105,8 +105,8 @@ Since we're just getting started, let's instead begin with :yoscrypt:`hierarchy .. note:: - :cmd:ref:`hierarchy` should always be the first command after the design has - been read. By specifying the top module, :cmd:ref:`hierarchy` will also set + `hierarchy` should always be the first command after the design has + been read. By specifying the top module, `hierarchy` will also set the ``(* top *)`` attribute on it. This is used by other commands that need to know which module is the top. @@ -125,7 +125,7 @@ Our ``addr_gen`` circuit now looks like this: :class: width-helper invert-helper :name: addr_gen_hier - ``addr_gen`` module after :cmd:ref:`hierarchy` + ``addr_gen`` module after `hierarchy` Simple operations like ``addr + 1`` and ``addr == MAX_DATA-1`` can be extracted from our ``always @`` block in :ref:`addr_gen-v`. This gives us the highlighted @@ -137,9 +137,9 @@ second line refers to the line numbers of the start/end of the corresponding ``PROC`` referring to line 0. To handle these, let us now introduce the next command: :doc:`/cmd/proc`. -:cmd:ref:`proc` is a macro command like :cmd:ref:`synth_ice40`. Rather than +`proc` is a macro command like `synth_ice40`. Rather than modifying the design directly, it instead calls a series of other commands. In -the case of :cmd:ref:`proc`, these sub-commands work to convert the behavioral +the case of `proc`, these sub-commands work to convert the behavioral logic of processes into multiplexers and registers. Let's see what happens when we run it. For now, we will call :yoscrypt:`proc -noopt` to prevent some automatic optimizations which would normally happen. @@ -160,8 +160,8 @@ Notice how in the top left of :ref:`addr_gen_proc` we have a floating wire, generated from the initial assignment of 0 to the ``addr`` wire. However, this initial assignment is not synthesizable, so this will need to be cleaned up before we can generate the physical hardware. We can do this now by calling -:cmd:ref:`clean`. We're also going to call :cmd:ref:`opt_expr` now, which would -normally be called at the end of :cmd:ref:`proc`. We can call both commands at +`clean`. We're also going to call `opt_expr` now, which would +normally be called at the end of `proc`. We can call both commands at the same time by separating them with a colon and space: :yoscrypt:`opt_expr; clean`. @@ -175,7 +175,7 @@ You may also notice that the highlighted `$eq` cell input of ``255`` has changed to ``8'11111111``. Constant values are presented in the format ``'``, with 32-bit values instead using the decimal number. This indicates that the constant input has been reduced from 32-bit wide to -8-bit wide. This is a side-effect of running :cmd:ref:`opt_expr`, which +8-bit wide. This is a side-effect of running `opt_expr`, which performs constant folding and simple expression rewriting. For more on why this happens, refer to :doc:`/using_yosys/synthesis/opt` and the :ref:`section on opt_expr `. @@ -185,7 +185,7 @@ on opt_expr `. :doc:`/cmd/clean` can also be called with two semicolons after any command, for example we could have called :yoscrypt:`opt_expr;;` instead of :yoscrypt:`opt_expr; clean`. You may notice some scripts will end each line - with ``;;``. It is beneficial to run :cmd:ref:`clean` before inspecting + with ``;;``. It is beneficial to run `clean` before inspecting intermediate products to remove disconnected parts of the circuit which have been left over, and in some cases can reduce the processing required in subsequent commands. @@ -202,7 +202,7 @@ The full example Let's now go back and check on our full design by using :yoscrypt:`hierarchy -check -top fifo`. By passing the ``-check`` option there we are also telling -the :cmd:ref:`hierarchy` command that if the design includes any non-blackbox +the `hierarchy` command that if the design includes any non-blackbox modules without an implementation it should return an error. Note that if we tried to run this command now then we would get an error. This @@ -221,15 +221,15 @@ could restart our shell session, but instead let's use two new commands: Notice how this time we didn't see any of those ``$abstract`` modules? That's because when we ran ``yosys fifo.v``, the first command Yosys called was :yoscrypt:`read_verilog -defer fifo.v`. The ``-defer`` option there tells -:cmd:ref:`read_verilog` only read the abstract syntax tree and defer actual -compilation to a later :cmd:ref:`hierarchy` command. This is useful in cases +`read_verilog` only read the abstract syntax tree and defer actual +compilation to a later `hierarchy` command. This is useful in cases where the default parameters of modules yield invalid code which is not synthesizable. This is why Yosys defers compilation automatically and is one of the reasons why hierarchy should always be the first command after loading the design. If we know that our design won't run into this issue, we can skip the ``-defer``. -.. todo:: :cmd:ref:`hierarchy` failure modes +.. todo:: `hierarchy` failure modes .. note:: @@ -243,19 +243,19 @@ design. If we know that our design won't run into this issue, we can skip the interactive terminal. :kbd:`ctrl+c` (i.e. SIGINT) will also end the terminal session but will return an error code rather than exiting gracefully. -We can also run :cmd:ref:`proc` now to finish off the full :ref:`synth_begin`. +We can also run `proc` now to finish off the full :ref:`synth_begin`. Because the design schematic is quite large, we will be showing just the data path for the ``rdata`` output. If you would like to see the entire design for -yourself, you can do so with :doc:`/cmd/show`. Note that the :cmd:ref:`show` +yourself, you can do so with :doc:`/cmd/show`. Note that the `show` command only works with a single module, so you may need to call it with :yoscrypt:`show fifo`. :ref:`show_intro` section in -:doc:`/getting_started/scripting_intro` has more on how to use :cmd:ref:`show`. +:doc:`/getting_started/scripting_intro` has more on how to use `show`. .. figure:: /_images/code_examples/fifo/rdata_proc.* :class: width-helper invert-helper :name: rdata_proc - ``rdata`` output after :cmd:ref:`proc` + ``rdata`` output after `proc` The highlighted ``fifo_reader`` block contains an instance of the :ref:`addr_gen_proc` that we looked at earlier. Notice how the type is shown as @@ -276,7 +276,7 @@ Flattening ~~~~~~~~~~ At this stage of a synthesis flow there are a few other commands we could run. -In :cmd:ref:`synth_ice40` we get these: +In `synth_ice40` we get these: .. literalinclude:: /cmd/synth_ice40.rst :language: yoscrypt @@ -286,7 +286,7 @@ In :cmd:ref:`synth_ice40` we get these: :name: synth_flatten :caption: ``flatten`` section -First off is :cmd:ref:`flatten`. Flattening the design like this can allow for +First off is `flatten`. Flattening the design like this can allow for optimizations between modules which would otherwise be missed. Let's run :yoscrypt:`flatten;;` on our design. @@ -310,19 +310,19 @@ The pieces have moved around a bit, but we can see :ref:`addr_gen_proc` from earlier has replaced the ``fifo_reader`` block in :ref:`rdata_proc`. We can also see that the ``addr`` output has been renamed to :file:`fifo_reader.addr` and merged with the ``raddr`` wire feeding into the `$memrd` cell. This wire -merging happened during the call to :cmd:ref:`clean` which we can see in the +merging happened during the call to `clean` which we can see in the :ref:`flat_clean`. .. note:: - :cmd:ref:`flatten` and :cmd:ref:`clean` would normally be combined into a + `flatten` and `clean` would normally be combined into a single :yoterm:`yosys> flatten;;` output, but they appear separately here as - a side effect of using :cmd:ref:`echo` for generating the terminal style + a side effect of using `echo` for generating the terminal style output. Depending on the target architecture, this stage of synthesis might also see -commands such as :cmd:ref:`tribuf` with the ``-logic`` option and -:cmd:ref:`deminout`. These remove tristate and inout constructs respectively, +commands such as `tribuf` with the ``-logic`` option and +`deminout`. These remove tristate and inout constructs respectively, replacing them with logic suitable for mapping to an FPGA. Since we do not have any such constructs in our example running these commands does not change our design. @@ -342,7 +342,7 @@ optimizations and other transformations done previously. .. note:: - While the iCE40 flow had a :ref:`synth_flatten` and put :cmd:ref:`proc` in + While the iCE40 flow had a :ref:`synth_flatten` and put `proc` in the :ref:`synth_begin`, some synthesis scripts will instead include these in this section. @@ -359,8 +359,8 @@ In the iCE40 flow, we start with the following commands: :caption: ``coarse`` section (part 1) :name: synth_coarse1 -We've already come across :cmd:ref:`opt_expr`, and :cmd:ref:`opt_clean` is the -same as :cmd:ref:`clean` but with more verbose output. The :cmd:ref:`check` +We've already come across `opt_expr`, and `opt_clean` is the +same as `clean` but with more verbose output. The `check` pass identifies a few obvious problems which will cause errors later. Calling it here lets us fail faster rather than wasting time on something we know is impossible. @@ -368,13 +368,13 @@ impossible. Next up is :yoscrypt:`opt -nodffe -nosdff` performing a set of simple optimizations on the design. This command also ensures that only a specific subset of FF types are included, in preparation for the next command: -:doc:`/cmd/fsm`. Both :cmd:ref:`opt` and :cmd:ref:`fsm` are macro commands +:doc:`/cmd/fsm`. Both `opt` and `fsm` are macro commands which are explored in more detail in :doc:`/using_yosys/synthesis/opt` and :doc:`/using_yosys/synthesis/fsm` respectively. Up until now, the data path for ``rdata`` has remained the same since -:ref:`rdata_flat`. However the next call to :cmd:ref:`opt` does cause a change. -Specifically, the call to :cmd:ref:`opt_dff` without the ``-nodffe -nosdff`` +:ref:`rdata_flat`. However the next call to `opt` does cause a change. +Specifically, the call to `opt_dff` without the ``-nodffe -nosdff`` options is able to fold one of the `$mux` cells into the `$adff` to form an `$adffe` cell; highlighted below: @@ -382,13 +382,13 @@ options is able to fold one of the `$mux` cells into the `$adff` to form an :language: doscon :start-at: yosys> opt_dff :end-before: yosys> select - :caption: output of :cmd:ref:`opt_dff` + :caption: output of `opt_dff` .. figure:: /_images/code_examples/fifo/rdata_adffe.* :class: width-helper invert-helper :name: rdata_adffe - ``rdata`` output after :cmd:ref:`opt_dff` + ``rdata`` output after `opt_dff` .. seealso:: Advanced usage docs for @@ -414,26 +414,26 @@ First up is :doc:`/cmd/wreduce`. If we run this we get the following: :language: doscon :start-at: yosys> wreduce :end-before: yosys> select - :caption: output of :cmd:ref:`wreduce` + :caption: output of `wreduce` Looking at the data path for ``rdata``, the most relevant of these width reductions are the ones affecting ``fifo.$flatten\fifo_reader.$add$fifo.v``. That is the `$add` cell incrementing the fifo_reader address. We can look at the schematic and see the output of that cell has now changed. -.. todo:: pending bugfix in :cmd:ref:`wreduce` and/or :cmd:ref:`opt_clean` +.. todo:: pending bugfix in `wreduce` and/or `opt_clean` .. figure:: /_images/code_examples/fifo/rdata_wreduce.* :class: width-helper invert-helper :name: rdata_wreduce - ``rdata`` output after :cmd:ref:`wreduce` + ``rdata`` output after `wreduce` The next two (new) commands are :doc:`/cmd/peepopt` and :doc:`/cmd/share`. Neither of these affect our design, and they're explored in more detail in :doc:`/using_yosys/synthesis/opt`, so let's skip over them. :yoscrypt:`techmap -map +/cmp2lut.v -D LUT_WIDTH=4` optimizes certain comparison operators by -converting them to LUTs instead. The usage of :cmd:ref:`techmap` is explored +converting them to LUTs instead. The usage of `techmap` is explored more in :doc:`/using_yosys/synthesis/techmap_synth`. Our next command to run is @@ -443,15 +443,15 @@ Our next command to run is :language: doscon :start-at: yosys> memory_dff :end-before: yosys> select - :caption: output of :cmd:ref:`memory_dff` + :caption: output of `memory_dff` .. figure:: /_images/code_examples/fifo/rdata_memrdv2.* :class: width-helper invert-helper :name: rdata_memrdv2 - ``rdata`` output after :cmd:ref:`memory_dff` + ``rdata`` output after `memory_dff` -As the title suggests, :cmd:ref:`memory_dff` has merged the output `$dff` into +As the title suggests, `memory_dff` has merged the output `$dff` into the `$memrd` cell and converted it to a `$memrd_v2` (highlighted). This has also connected the ``CLK`` port to the ``clk`` input as it is now a synchronous memory read with appropriate enable (``EN=1'1``) and reset (``ARST=1'0`` and @@ -466,7 +466,7 @@ memory read with appropriate enable (``EN=1'1``) and reset (``ARST=1'0`` and Part 3 ^^^^^^ -The third part of the :cmd:ref:`synth_ice40` flow is a series of commands for +The third part of the `synth_ice40` flow is a series of commands for mapping to DSPs. By default, the iCE40 flow will not map to the hardware DSP blocks and will only be performed if called with the ``-dsp`` flag: :yoscrypt:`synth_ice40 -dsp`. While our example has nothing that could be @@ -483,24 +483,24 @@ what they do. :yoscrypt:`wreduce t:$mul` performs width reduction again, this time targetting only cells of type `$mul`. :yoscrypt:`techmap -map +/mul2dsp.v -map -+/ice40/dsp_map.v ... -D DSP_NAME=$__MUL16X16` uses :cmd:ref:`techmap` to map ++/ice40/dsp_map.v ... -D DSP_NAME=$__MUL16X16` uses `techmap` to map `$mul` cells to ``$__MUL16X16`` which are, in turn, mapped to the iCE40 ``SB_MAC16``. Any multipliers which aren't compatible with conversion to -``$__MUL16X16`` are relabelled to ``$__soft_mul`` before :cmd:ref:`chtype` +``$__MUL16X16`` are relabelled to ``$__soft_mul`` before `chtype` changes them back to `$mul`. During the mul2dsp conversion, some of the intermediate signals are marked with the attribute ``mul2dsp``. By calling :yoscrypt:`select a:mul2dsp` we restrict the following commands to only operate on the cells and wires used for these -signals. :cmd:ref:`setattr` removes the now unnecessary ``mul2dsp`` attribute. -:cmd:ref:`opt_expr` we've already come across for const folding and simple +signals. `setattr` removes the now unnecessary ``mul2dsp`` attribute. +`opt_expr` we've already come across for const folding and simple expression rewriting, the ``-fine`` option just enables more fine-grain optimizations. Then we perform width reduction a final time and clear the selection. .. todo:: ``ice40_dsp`` is pmgen -Finally we have :cmd:ref:`ice40_dsp`: similar to the :cmd:ref:`memory_dff` +Finally we have `ice40_dsp`: similar to the `memory_dff` command we saw in the previous section, this merges any surrounding registers into the ``SB_MAC16`` cell. This includes not just the input/output registers, but also pipeline registers and even a post-adder where applicable: turning a @@ -525,40 +525,40 @@ That brings us to the fourth and final part for the iCE40 synthesis flow: Where before each type of arithmetic operation had its own cell, e.g. `$add`, we now want to extract these into `$alu` and `$macc` cells which can help identify opportunities for reusing logic. We do this by running -:cmd:ref:`alumacc`, which we can see produce the following changes in our +`alumacc`, which we can see produce the following changes in our example design: .. literalinclude:: /code_examples/fifo/fifo.out :language: doscon :start-at: yosys> alumacc :end-before: yosys> select - :caption: output of :cmd:ref:`alumacc` + :caption: output of `alumacc` .. figure:: /_images/code_examples/fifo/rdata_alumacc.* :class: width-helper invert-helper :name: rdata_alumacc - ``rdata`` output after :cmd:ref:`alumacc` + ``rdata`` output after `alumacc` -Once these cells have been inserted, the call to :cmd:ref:`opt` can combine +Once these cells have been inserted, the call to `opt` can combine cells which are now identical but may have been missed due to e.g. the difference between `$add` and `$sub`. -The other new command in this part is :doc:`/cmd/memory`. :cmd:ref:`memory` is +The other new command in this part is :doc:`/cmd/memory`. `memory` is another macro command which we examine in more detail in :doc:`/using_yosys/synthesis/memory`. For this document, let us focus just on -the step most relevant to our example: :cmd:ref:`memory_collect`. Up until this +the step most relevant to our example: `memory_collect`. Up until this point, our memory reads and our memory writes have been totally disjoint cells; -operating on the same memory only in the abstract. :cmd:ref:`memory_collect` +operating on the same memory only in the abstract. `memory_collect` combines all of the reads and writes for a memory block into a single cell. .. figure:: /_images/code_examples/fifo/rdata_coarse.* :class: width-helper invert-helper :name: rdata_coarse - ``rdata`` output after :cmd:ref:`memory_collect` + ``rdata`` output after `memory_collect` -Looking at the schematic after running :cmd:ref:`memory_collect` we see that our +Looking at the schematic after running `memory_collect` we see that our `$memrd_v2` cell has been replaced with a `$mem_v2` cell named ``data``, the same name that we used in :ref:`fifo-v`. Where before we had a single set of signals for address and enable, we now have one set for reading (``RD_*``) and @@ -592,8 +592,8 @@ If you skipped calling :yoscrypt:`read_verilog -D ICE40_HX -lib -specify Memory blocks ^^^^^^^^^^^^^ -Mapping to hard memory blocks uses a combination of :cmd:ref:`memory_libmap` and -:cmd:ref:`techmap`. +Mapping to hard memory blocks uses a combination of `memory_libmap` and +`techmap`. .. literalinclude:: /cmd/synth_ice40.rst :language: yoscrypt @@ -619,7 +619,7 @@ As a result, extra logic is added so that the generated circuit matches the behaviour of the verilog. :ref:`no_rw_check` describes how we could change our verilog to match our hardware instead. -If we run :cmd:ref:`memory_libmap` under the :cmd:ref:`debug` command we can see +If we run `memory_libmap` under the `debug` command we can see candidates which were identified for mapping, along with the costs of each and what logic requires emulation. @@ -628,9 +628,9 @@ what logic requires emulation. :lines: 2, 6- The ``$__ICE40_RAM4K_`` cell is defined in the file |techlibs/ice40/brams.txt|_, -with the mapping to ``SB_RAM40_4K`` done by :cmd:ref:`techmap` using +with the mapping to ``SB_RAM40_4K`` done by `techmap` using |techlibs/ice40/brams_map.v|_. Any leftover memory cells are then converted -into flip flops (the ``logic fallback``) with :cmd:ref:`memory_map`. +into flip flops (the ``logic fallback``) with `memory_map`. .. |techlibs/ice40/brams.txt| replace:: :file:`techlibs/ice40/brams.txt` .. _techlibs/ice40/brams.txt: https://github.com/YosysHQ/yosys/tree/main/techlibs/ice40/brams.txt @@ -654,7 +654,7 @@ into flip flops (the ``logic fallback``) with :cmd:ref:`memory_map`. .. note:: The visual clutter on the ``RDATA`` output port (highlighted) is an - unfortunate side effect of :cmd:ref:`opt_clean` on the swizzled data bits. In + unfortunate side effect of `opt_clean` on the swizzled data bits. In connecting the `$mux` input port directly to ``RDATA`` to reduce the number of wires, the ``$techmap579\data.0.0.RDATA`` wire becomes more visually complex. @@ -667,7 +667,7 @@ into flip flops (the ``logic fallback``) with :cmd:ref:`memory_map`. Arithmetic ^^^^^^^^^^ -Uses :cmd:ref:`techmap` to map basic arithmetic logic to hardware. This sees +Uses `techmap` to map basic arithmetic logic to hardware. This sees somewhat of an explosion in cells as multi-bit :cell:ref:`$mux` and `$adffe` are replaced with single-bit `$_MUX_` and `$_DFFE_PP0P_` cells, while the :cell:ref:`$alu` is replaced with primitive `$_OR_` and `$_NOT_` gates and a @@ -693,11 +693,11 @@ replaced with single-bit `$_MUX_` and `$_DFFE_PP0P_` cells, while the Flip-flops ^^^^^^^^^^ -Convert FFs to the types supported in hardware with :cmd:ref:`dfflegalize`, and -then use :cmd:ref:`techmap` to map them. In our example, this converts the +Convert FFs to the types supported in hardware with `dfflegalize`, and +then use `techmap` to map them. In our example, this converts the `$_DFFE_PP0P_` cells to ``SB_DFFER``. -We also run :cmd:ref:`simplemap` here to convert any remaining cells which could +We also run `simplemap` here to convert any remaining cells which could not be mapped to hardware into gate-level primitives. This includes optimizing `$_MUX_` cells where one of the inputs is a constant ``1'0``, replacing it instead with an `$_AND_` cell. @@ -722,9 +722,9 @@ instead with an `$_AND_` cell. LUTs ^^^^ -:cmd:ref:`abc` and :cmd:ref:`techmap` are used to map LUTs; converting primitive +`abc` and `techmap` are used to map LUTs; converting primitive cell types to use `$lut` and ``SB_CARRY`` cells. Note that the iCE40 flow -uses :cmd:ref:`abc9` rather than :cmd:ref:`abc`. For more on what these do, and +uses `abc9` rather than `abc`. For more on what these do, and what the difference between these two commands are, refer to :doc:`/using_yosys/synthesis/abc`. @@ -742,7 +742,7 @@ what the difference between these two commands are, refer to ``rdata`` output after :ref:`map_luts` -Finally we use :cmd:ref:`techmap` to map the generic `$lut` cells to iCE40 +Finally we use `techmap` to map the generic `$lut` cells to iCE40 ``SB_LUT4`` cells. .. literalinclude:: /cmd/synth_ice40.rst @@ -769,12 +769,12 @@ Other cells The following commands may also be used for mapping other cells: -:cmd:ref:`hilomap` +`hilomap` Some architectures require special driver cells for driving a constant hi or lo value. This command replaces simple constants with instances of such driver cells. -:cmd:ref:`iopadmap` +`iopadmap` Top-level input/outputs must usually be implemented using special I/O-pad cells. This command inserts such cells to the design. @@ -801,27 +801,27 @@ The new commands here are: - :doc:`/cmd/stat`, and - :doc:`/cmd/blackbox`. -The output from :cmd:ref:`stat` is useful for checking resource utilization; +The output from `stat` is useful for checking resource utilization; providing a list of cells used in the design and the number of each, as well as the number of other resources used such as wires and processes. For this -design, the final call to :cmd:ref:`stat` should look something like the +design, the final call to `stat` should look something like the following: .. literalinclude:: /code_examples/fifo/fifo.stat :language: doscon :start-at: yosys> stat -top fifo -Note that the :yoscrypt:`-top fifo` here is optional. :cmd:ref:`stat` will +Note that the :yoscrypt:`-top fifo` here is optional. `stat` will automatically use the module with the ``top`` attribute set, which ``fifo`` was -when we called :cmd:ref:`hierarchy`. If no module is marked ``top``, then stats +when we called `hierarchy`. If no module is marked ``top``, then stats will be shown for each module selected. -The :cmd:ref:`stat` output is also useful as a kind of sanity-check: Since we -have already run :cmd:ref:`proc`, we wouldn't expect there to be any processes. +The `stat` output is also useful as a kind of sanity-check: Since we +have already run `proc`, we wouldn't expect there to be any processes. We also expect ``data`` to use hard memory; if instead of an ``SB_RAM40_4K`` saw a high number of flip-flops being used we might suspect something was wrong. -If we instead called :cmd:ref:`stat` immediately after :yoscrypt:`read_verilog +If we instead called `stat` immediately after :yoscrypt:`read_verilog fifo.v` we would see something very different: .. literalinclude:: /code_examples/fifo/fifo.stat @@ -845,7 +845,7 @@ The iCE40 synthesis flow has the following output modes available: As an example, if we called :yoscrypt:`synth_ice40 -top fifo -json fifo.json`, our synthesized ``fifo`` design will be output as :file:`fifo.json`. We can -then read the design back into Yosys with :cmd:ref:`read_json`, but make sure +then read the design back into Yosys with `read_json`, but make sure you use :yoscrypt:`design -reset` or open a new interactive terminal first. The JSON output we get can also be loaded into `nextpnr`_ to do place and route; but that is beyond the scope of this documentation. diff --git a/docs/source/getting_started/installation.rst b/docs/source/getting_started/installation.rst index 4d1a2f36a58..8ed7cebb87c 100644 --- a/docs/source/getting_started/installation.rst +++ b/docs/source/getting_started/installation.rst @@ -88,7 +88,7 @@ A C++ compiler with C++17 support is required as well as some standard tools such as GNU Flex, GNU Bison, Make and Python. Some additional tools: readline, libffi, Tcl and zlib; are optional but enabled by default (see :makevar:`ENABLE_*` settings in Makefile). Graphviz and Xdot are used by the -:cmd:ref:`show` command to display schematics. +`show` command to display schematics. Installing all prerequisites for Ubuntu 20.04: @@ -185,8 +185,8 @@ directories: ``passes/`` This directory contains a subdirectory for each pass or group of passes. For example as of this writing the directory :file:`passes/hierarchy/` contains the - code for three passes: :cmd:ref:`hierarchy`, :cmd:ref:`submod`, and - :cmd:ref:`uniquify`. + code for three passes: `hierarchy`, `submod`, and + `uniquify`. ``techlibs/`` This directory contains simulation models and standard implementations for diff --git a/docs/source/getting_started/scripting_intro.rst b/docs/source/getting_started/scripting_intro.rst index 1e2ebabff93..ef728e1cf12 100644 --- a/docs/source/getting_started/scripting_intro.rst +++ b/docs/source/getting_started/scripting_intro.rst @@ -7,8 +7,7 @@ file format and how you can make your own synthesis scripts. Yosys script files typically use the :file:`.ys` extension and contain a set of commands for Yosys to run sequentially. These commands are the same ones we -were using on the previous page like :cmd:ref:`read_verilog` and -:cmd:ref:`hierarchy`. +were using on the previous page like `read_verilog` and `hierarchy`. Script parsing ~~~~~~~~~~~~~~ @@ -39,9 +38,9 @@ Another special character that can be used in Yosys scripts is the bang ``!``. Anything after the bang will be executed as a shell command. This can only be terminated with a new line. Any semicolons, hashes, or other special characters will be passed to the shell. If an error code is returned from the shell it -will be raised by Yosys. :cmd:ref:`exec` provides a much more flexible way of -executing commands, allowing the output to be logged and more control over when -to generate errors. +will be raised by Yosys. `exec` provides a much more flexible way of executing +commands, allowing the output to be logged and more control over when to +generate errors. The synthesis starter script ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -62,7 +61,7 @@ already, let's take a look at some of those script files now. :caption: A section of :file:`fifo.ys`, generating the images used for :ref:`addr_gen_example` :name: fifo-ys -The first command there, :yoscrypt:`echo on`, uses :cmd:ref:`echo` to enable +The first command there, :yoscrypt:`echo on`, uses `echo` to enable command echoes on. This is how we generated the code listing for :ref:`hierarchy_output`. Turning command echoes on prints the ``yosys> hierarchy -top addr_gen`` line, making the output look the same as if it were an @@ -70,15 +69,15 @@ interactive terminal. :yoscrypt:`hierarchy -top addr_gen` is of course the command we were demonstrating, including the output text and an image of the design schematic after running it. -We briefly touched on :cmd:ref:`select` when it came up in -:cmd:ref:`synth_ice40`, but let's look at it more now. +We briefly touched on `select` when it came up in +`synth_ice40`, but let's look at it more now. .. _select_intro: Selections intro ^^^^^^^^^^^^^^^^ -The :cmd:ref:`select` command is used to modify and view the list of selected +The `select` command is used to modify and view the list of selected objects: .. literalinclude:: /code_examples/fifo/fifo.out @@ -119,7 +118,7 @@ statement. Many commands also support an optional ``[selection]`` argument which can be used to override the currently selected objects. We could, for example, call -:yoscrypt:`clean addr_gen` to have :cmd:ref:`clean` operate on *just* the +:yoscrypt:`clean addr_gen` to have `clean` operate on *just* the ``addr_gen`` module. Detailed documentation of the select framework can be found under @@ -131,9 +130,9 @@ Detailed documentation of the select framework can be found under Displaying schematics ^^^^^^^^^^^^^^^^^^^^^ -While the :cmd:ref:`select` command is very useful, sometimes nothing beats -being able to see a design for yourself. This is where :cmd:ref:`show` comes -in. Note that this document is just an introduction to the :cmd:ref:`show` +While the `select` command is very useful, sometimes nothing beats +being able to see a design for yourself. This is where `show` comes +in. Note that this document is just an introduction to the `show` command, only covering the basics. For more information, including a guide on what the different symbols represent, see :ref:`interactive_show` and the :doc:`/using_yosys/more_scripting/interactive_investigation` page. @@ -142,11 +141,11 @@ what the different symbols represent, see :ref:`interactive_show` and the :class: width-helper invert-helper :name: addr_gen_show - Calling :yoscrypt:`show addr_gen` after :cmd:ref:`hierarchy` + Calling :yoscrypt:`show addr_gen` after `hierarchy` .. note:: - The :cmd:ref:`show` command requires a working installation of `GraphViz`_ + The `show` command requires a working installation of `GraphViz`_ and `xdot`_ for displaying the actual circuit diagrams. .. _GraphViz: http://www.graphviz.org/ @@ -161,7 +160,7 @@ we see the following: :start-at: -prefix addr_gen_show :end-before: yosys> show -Calling :cmd:ref:`show` with :yoscrypt:`-format dot` tells it we want to output +Calling `show` with :yoscrypt:`-format dot` tells it we want to output a :file:`.dot` file rather than opening it for display. The :yoscrypt:`-prefix addr_gen_show` option indicates we want the file to be called :file:`addr_gen_show.{*}`. Remember, we do this in :file:`fifo.ys` because we @@ -186,7 +185,7 @@ That last parameter doesn't have to be a module name, it can be any valid selection string. Remember when we :ref:`assigned a name to a selection` and called it ``new_cells``? We saw in the :yoscrypt:`select -list` output that it contained two cells, an `$add` and an -`$eq`. We can call :cmd:ref:`show` on that selection just as easily: +`$eq`. We can call `show` on that selection just as easily: .. figure:: /_images/code_examples/fifo/new_cells_show.* :class: width-helper invert-helper @@ -208,10 +207,10 @@ the two ``PROC`` blocks. To achieve this highlight, we make use of the Calling :yoscrypt:`show -color maroon3 @new_cells -color cornflowerblue p:* -notitle` -As described in the the :cmd:ref:`help` output for :cmd:ref:`show` (or by -clicking on the :cmd:ref:`show` link), colors are specified as :yoscrypt:`-color +As described in the the `help` output for `show` (or by +clicking on the `show` link), colors are specified as :yoscrypt:`-color `. Color names for the ```` portion can be found on the -`GraphViz color docs`_. Unlike the final :cmd:ref:`show` parameter which can +`GraphViz color docs`_. Unlike the final `show` parameter which can have be any selection string, the ```` part must be a single selection expression or named selection. That means while we can use ``@new_cells``, we couldn't use ``t:$eq t:$add``. In general, if a command lists ``[selection]`` @@ -221,7 +220,7 @@ expression instead. .. _GraphViz color docs: https://graphviz.org/doc/info/colors -For all of the options available to :cmd:ref:`show`, check the command reference +For all of the options available to `show`, check the command reference at :doc:`/cmd/show`. .. seealso:: :ref:`interactive_show` on the diff --git a/docs/source/using_yosys/more_scripting/interactive_investigation.rst b/docs/source/using_yosys/more_scripting/interactive_investigation.rst index 77d826376fd..f2e3d5219d8 100644 --- a/docs/source/using_yosys/more_scripting/interactive_investigation.rst +++ b/docs/source/using_yosys/more_scripting/interactive_investigation.rst @@ -13,7 +13,7 @@ A look at the show command .. TODO:: merge into :doc:`/getting_started/scripting_intro` show section -This section explores the :cmd:ref:`show` command and explains the symbols used +This section explores the `show` command and explains the symbols used in the circuit diagrams generated by it. The code used is included in the Yosys code base under |code_examples/show|_. @@ -24,7 +24,7 @@ A simple circuit ^^^^^^^^^^^^^^^^ :ref:`example_v` below provides the Verilog code for a simple circuit which we -will use to demonstrate the usage of :cmd:ref:`show` in a simple setting. +will use to demonstrate the usage of `show` in a simple setting. .. literalinclude:: /code_examples/show/example.v :language: Verilog @@ -32,7 +32,7 @@ will use to demonstrate the usage of :cmd:ref:`show` in a simple setting. :name: example_v The Yosys synthesis script we will be running is included as -:numref:`example_ys`. Note that :cmd:ref:`show` is called with the ``-pause`` +:numref:`example_ys`. Note that `show` is called with the ``-pause`` option, that halts execution of the Yosys script until the user presses the Enter key. Using :yoscrypt:`show -pause` also allows the user to enter an interactive shell to further investigate the circuit before continuing @@ -58,7 +58,7 @@ is shown. .. figure:: /_images/code_examples/show/example_first.* :class: width-helper invert-helper - Output of the first :cmd:ref:`show` command in :numref:`example_ys` + Output of the first `show` command in :numref:`example_ys` The first output shows the design directly after being read by the Verilog front-end. Input and output ports are displayed as octagonal shapes. Cells are @@ -84,39 +84,39 @@ original ``always``-block in the second line. Note how the multiplexer from the ``?:``-expression is represented as a `$mux` cell but the multiplexer from the ``if``-statement is yet still hidden within the process. -The :cmd:ref:`proc` command transforms the process from the first diagram into a +The `proc` command transforms the process from the first diagram into a multiplexer and a d-type flip-flop, which brings us to the second diagram: .. figure:: /_images/code_examples/show/example_second.* :class: width-helper invert-helper - Output of the second :cmd:ref:`show` command in :numref:`example_ys` + Output of the second `show` command in :numref:`example_ys` The Rhombus shape to the right is a dangling wire. (Wire nodes are only shown if they are dangling or have "public" names, for example names assigned from the Verilog input.) Also note that the design now contains two instances of a -``BUF``-node. These are artefacts left behind by the :cmd:ref:`proc` command. It +``BUF``-node. These are artefacts left behind by the `proc` command. It is quite usual to see such artefacts after calling commands that perform changes in the design, as most commands only care about doing the transformation in the least complicated way, not about cleaning up after them. The next call to -:cmd:ref:`clean` (or :cmd:ref:`opt`, which includes :cmd:ref:`clean` as one of +`clean` (or `opt`, which includes `clean` as one of its operations) will clean up these artefacts. This operation is so common in Yosys scripts that it can simply be abbreviated with the ``;;`` token, which doubles as separator for commands. Unless one wants to specifically analyze this artefacts left behind some operations, it is therefore recommended to always -call :cmd:ref:`clean` before calling :cmd:ref:`show`. +call `clean` before calling `show`. -In this script we directly call :cmd:ref:`opt` as the next step, which finally +In this script we directly call `opt` as the next step, which finally leads us to the third diagram: .. figure:: /_images/code_examples/show/example_third.* :class: width-helper invert-helper :name: example_out - Output of the third :cmd:ref:`show` command in :ref:`example_ys` + Output of the third `show` command in :ref:`example_ys` -Here we see that the :cmd:ref:`opt` command not only has removed the artifacts -left behind by :cmd:ref:`proc`, but also determined correctly that it can remove +Here we see that the `opt` command not only has removed the artifacts +left behind by `proc`, but also determined correctly that it can remove the first `$mux` cell without changing the behavior of the circuit. Break-out boxes for signal vectors @@ -129,7 +129,7 @@ accesses. :caption: :file:`splice.v` :name: splice_src -Notice how the output for this circuit from the :cmd:ref:`show` command +Notice how the output for this circuit from the `show` command (:numref:`splice_dia`) appears quite complex. This is an unfortunate side effect of the way Yosys handles signal vectors (aka. multi-bit wires or buses) as native objects. While this provides great advantages when analyzing circuits @@ -169,7 +169,7 @@ mapped to a cell library: :name: first_pitfall A half-adder built from simple CMOS gates, demonstrating common pitfalls when - using :cmd:ref:`show` + using `show` .. literalinclude:: /code_examples/show/cmos.ys :language: yoscrypt @@ -188,7 +188,7 @@ individual bits, resulting in an unnecessary complex diagram. :class: width-helper invert-helper :name: second_pitfall - Effects of :cmd:ref:`splitnets` command and of providing a cell library on + Effects of `splitnets` command and of providing a cell library on design in :numref:`first_pitfall` .. literalinclude:: /code_examples/show/cmos.ys @@ -201,11 +201,11 @@ individual bits, resulting in an unnecessary complex diagram. For :numref:`second_pitfall`, Yosys has been given a description of the cell library as Verilog file containing blackbox modules. There are two ways to load cell descriptions into Yosys: First the Verilog file for the cell library can be -passed directly to the :cmd:ref:`show` command using the ``-lib `` +passed directly to the `show` command using the ``-lib `` option. Secondly it is possible to load cell libraries into the design with the :yoscrypt:`read_verilog -lib ` command. The second method has the great advantage that the library only needs to be loaded once and can then be -used in all subsequent calls to the :cmd:ref:`show` command. +used in all subsequent calls to the `show` command. In addition to that, :numref:`second_pitfall` was generated after :yoscrypt:`splitnet -ports` was run on the design. This command splits all @@ -216,7 +216,7 @@ module ports. Per default the command only operates on interior signals. Miscellaneous notes ^^^^^^^^^^^^^^^^^^^ -Per default the :cmd:ref:`show` command outputs a temporary dot file and +Per default the `show` command outputs a temporary dot file and launches ``xdot`` to display it. The options ``-format``, ``-viewer`` and ``-prefix`` can be used to change format, viewer and filename prefix. Note that the ``pdf`` and ``ps`` format are the only formats that support plotting @@ -225,13 +225,13 @@ modules, however ``xdot`` will raise an error when trying to read them. In densely connected circuits it is sometimes hard to keep track of the individual signal wires. For these cases it can be useful to call -:cmd:ref:`show` with the ``-colors `` argument, which randomly assigns +`show` with the ``-colors `` argument, which randomly assigns colors to the nets. The integer (> 0) is used as seed value for the random color assignments. Sometimes it is necessary it try some values to find an assignment of colors that looks good. The command :yoscrypt:`help show` prints a complete listing of all options -supported by the :cmd:ref:`show` command. +supported by the `show` command. Navigating the design ~~~~~~~~~~~~~~~~~~~~~ @@ -245,9 +245,9 @@ In addition to *what* to display one also needs to carefully decide *when* to display it, with respect to the synthesis flow. In general it is a good idea to troubleshoot a circuit in the earliest state in which a problem can be reproduced. So if, for example, the internal state before calling the -:cmd:ref:`techmap` command already fails to verify, it is better to troubleshoot -the coarse-grain version of the circuit before :cmd:ref:`techmap` than the -gate-level circuit after :cmd:ref:`techmap`. +`techmap` command already fails to verify, it is better to troubleshoot +the coarse-grain version of the circuit before `techmap` than the +gate-level circuit after `techmap`. .. Note:: @@ -260,16 +260,16 @@ Interactive navigation ^^^^^^^^^^^^^^^^^^^^^^ Once the right state within the synthesis flow for debugging the circuit has -been identified, it is recommended to simply add the :cmd:ref:`shell` command to +been identified, it is recommended to simply add the `shell` command to the matching place in the synthesis script. This command will stop the synthesis at the specified moment and go to shell mode, where the user can interactively enter commands. For most cases, the shell will start with the whole design selected (i.e. when the synthesis script does not already narrow the selection). The command -:cmd:ref:`ls` can now be used to create a list of all modules. The command -:cmd:ref:`cd` can be used to switch to one of the modules (type ``cd ..`` to -switch back). Now the :cmd:ref:`ls` command lists the objects within that +`ls` can now be used to create a list of all modules. The command +`cd` can be used to switch to one of the modules (type ``cd ..`` to +switch back). Now the `ls` command lists the objects within that module. This is demonstrated below using :file:`example.v` from `A simple circuit`_: @@ -277,10 +277,10 @@ circuit`_: :language: doscon :start-at: yosys> ls :end-before: yosys [example]> dump - :caption: Output of :cmd:ref:`ls` and :cmd:ref:`cd` after running :file:`yosys example.v` + :caption: Output of `ls` and `cd` after running :file:`yosys example.v` :name: lscd -When a module is selected using the :cmd:ref:`cd` command, all commands (with a +When a module is selected using the `cd` command, all commands (with a few exceptions, such as the ``read_`` and ``write_`` commands) operate only on the selected module. This can also be useful for synthesis scripts where different synthesis strategies should be applied to different modules in the @@ -293,12 +293,12 @@ contains some additional information on the origin of the named object. But in most cases those names can simply be abbreviated using the last part. Usually all interactive work is done with one module selected using the -:cmd:ref:`cd` command. But it is also possible to work from the design-context +`cd` command. But it is also possible to work from the design-context (``cd ..``). In this case all object names must be prefixed with ``/``. For example ``a*/b*`` would refer to all objects whose names start with ``b`` from all modules whose names start with ``a``. -The :cmd:ref:`dump` command can be used to print all information about an +The `dump` command can be used to print all information about an object. For example, calling :yoscrypt:`dump $2` after the :yoscrypt:`cd example` above: @@ -323,10 +323,10 @@ tools). - The selection mechanism, especially patterns such as ``%ci`` and ``%co``, can be used to figure out how parts of the design are connected. -- Commands such as :cmd:ref:`submod`, :cmd:ref:`expose`, and :cmd:ref:`splice` +- Commands such as `submod`, `expose`, and `splice` can be used to transform the design into an equivalent design that is easier to analyse. -- Commands such as :cmd:ref:`eval` and :cmd:ref:`sat` can be used to investigate +- Commands such as `eval` and `sat` can be used to investigate the behavior of the circuit. - :doc:`/cmd/show`. - :doc:`/cmd/dump`. @@ -342,10 +342,10 @@ The code used is included in the Yosys code base under Changing design hierarchy ^^^^^^^^^^^^^^^^^^^^^^^^^ -Commands such as :cmd:ref:`flatten` and :cmd:ref:`submod` can be used to change +Commands such as `flatten` and `submod` can be used to change the design hierarchy, i.e. flatten the hierarchy or moving parts of a module to a submodule. This has applications in synthesis scripts as well as in reverse -engineering and analysis. An example using :cmd:ref:`submod` is shown below for +engineering and analysis. An example using `submod` is shown below for reorganizing a module in Yosys and checking the resulting circuit. .. literalinclude:: /code_examples/scrambler/scrambler.v @@ -388,7 +388,7 @@ Analyzing the resulting circuit with :doc:`/cmd/eval`: Behavioral changes ^^^^^^^^^^^^^^^^^^ -Commands such as :cmd:ref:`techmap` can be used to make behavioral changes to +Commands such as `techmap` can be used to make behavioral changes to the design, for example changing asynchronous resets to synchronous resets. This has applications in design space exploration (evaluation of various architectures for one circuit). @@ -425,7 +425,7 @@ Yosys script for ASIC synthesis of the Amber ARMv2 CPU. endmodule -For more on the :cmd:ref:`techmap` command, see the page on +For more on the `techmap` command, see the page on :doc:`/yosys_internals/techmap`. Advanced investigation techniques @@ -448,12 +448,12 @@ Recall the ``memdemo`` design from :ref:`advanced_logic_cones`: Because this produces a rather large circuit, it can be useful to split it into smaller parts for viewing and working with. :numref:`submod` does exactly that, -utilising the :cmd:ref:`submod` command to split the circuit into three +utilising the `submod` command to split the circuit into three sections: ``outstage``, ``selstage``, and ``scramble``. .. literalinclude:: /code_examples/selections/submod.ys :language: yoscrypt - :caption: Using :cmd:ref:`submod` to break up the circuit from :file:`memdemo.v` + :caption: Using `submod` to break up the circuit from :file:`memdemo.v` :start-after: cd memdemo :end-before: cd .. :name: submod @@ -481,7 +481,7 @@ below. Evaluation of combinatorial circuits ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The :cmd:ref:`eval` command can be used to evaluate combinatorial circuits. As +The `eval` command can be used to evaluate combinatorial circuits. As an example, we will use the ``selstage`` subnet of ``memdemo`` which we found above and is shown in :numref:`selstage`. @@ -526,20 +526,20 @@ The ``-table`` option can be used to create a truth table. For example: Assumed undef (x) value for the following signals: \s2 -Note that the :cmd:ref:`eval` command (as well as the :cmd:ref:`sat` command +Note that the `eval` command (as well as the `sat` command discussed in the next sections) does only operate on flattened modules. It can not analyze signals that are passed through design hierarchy levels. So the -:cmd:ref:`flatten` command must be used on modules that instantiate other +`flatten` command must be used on modules that instantiate other modules before these commands can be applied. Solving combinatorial SAT problems ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Often the opposite of the :cmd:ref:`eval` command is needed, i.e. the circuits +Often the opposite of the `eval` command is needed, i.e. the circuits output is given and we want to find the matching input signals. For small circuits with only a few input bits this can be accomplished by trying all possible input combinations, as it is done by the ``eval -table`` command. For -larger circuits however, Yosys provides the :cmd:ref:`sat` command that uses a +larger circuits however, Yosys provides the `sat` command that uses a `SAT`_ solver, `MiniSAT`_, to solve this kind of problems. .. _SAT: http://en.wikipedia.org/wiki/Circuit_satisfiability @@ -551,7 +551,7 @@ larger circuits however, Yosys provides the :cmd:ref:`sat` command that uses a While it is possible to perform model checking directly in Yosys, it is highly recommended to use SBY or EQY for formal hardware verification. -The :cmd:ref:`sat` command works very similar to the :cmd:ref:`eval` command. +The `sat` command works very similar to the `eval` command. The main difference is that it is now also possible to set output values and find the corresponding input values. For Example: @@ -580,7 +580,7 @@ find the corresponding input values. For Example: \s1 0 0 00 \s2 0 0 00 -Note that the :cmd:ref:`sat` command supports signal names in both arguments to +Note that the `sat` command supports signal names in both arguments to the ``-set`` option. In the above example we used ``-set s1 s2`` to constraint ``s1`` and ``s2`` to be equal. When more complex constraints are needed, a wrapper circuit must be constructed that checks the constraints and signals if @@ -642,7 +642,7 @@ of course be to perform the test in 32 bits, for example by replacing ``p != a*b`` in the miter with ``p != {16'd0,a}b``, or by using a temporary variable for the 32 bit product ``a*b``. But as 31 fits well into 8 bits (and as the purpose of this document is to show off Yosys features) we can also simply force -the upper 8 bits of ``a`` and ``b`` to zero for the :cmd:ref:`sat` call, as is +the upper 8 bits of ``a`` and ``b`` to zero for the `sat` call, as is done below. .. todo:: replace inline code @@ -705,16 +705,16 @@ command: sat -seq 6 -show y -show d -set-init-undef \ -max_undef -set-at 4 y 1 -set-at 5 y 2 -set-at 6 y 3 -The ``-seq 6`` option instructs the :cmd:ref:`sat` command to solve a sequential +The ``-seq 6`` option instructs the `sat` command to solve a sequential problem in 6 time steps. (Experiments with lower number of steps have show that at least 3 cycles are necessary to bring the circuit in a state from which the sequence 1, 2, 3 can be produced.) -The ``-set-init-undef`` option tells the :cmd:ref:`sat` command to initialize +The ``-set-init-undef`` option tells the `sat` command to initialize all registers to the undef (``x``) state. The way the ``x`` state is treated in Verilog will ensure that the solution will work for any initial state. -The ``-max_undef`` option instructs the :cmd:ref:`sat` command to find a +The ``-max_undef`` option instructs the `sat` command to find a solution with a maximum number of undefs. This way we can see clearly which inputs bits are relevant to the solution. @@ -807,7 +807,7 @@ is the only way of setting the ``s1`` and ``s2`` registers to a known value. The input values for the other steps are a bit harder to work out manually, but the SAT solver finds the correct solution in an instant. -There is much more to write about the :cmd:ref:`sat` command. For example, there +There is much more to write about the `sat` command. For example, there is a set of options that can be used to performs sequential proofs using temporal induction :cite:p:`een2003temporal`. The command ``help sat`` can be used to print a list of all options with short descriptions of their functions. diff --git a/docs/source/using_yosys/more_scripting/model_checking.rst b/docs/source/using_yosys/more_scripting/model_checking.rst index 92a9d85ce67..88eeb9bcd5e 100644 --- a/docs/source/using_yosys/more_scripting/model_checking.rst +++ b/docs/source/using_yosys/more_scripting/model_checking.rst @@ -17,7 +17,7 @@ passes in Yosys. Other applications include checking if a module conforms to interface standards. -The :cmd:ref:`sat` command in Yosys can be used to perform Symbolic Model +The `sat` command in Yosys can be used to perform Symbolic Model Checking. Checking techmap diff --git a/docs/source/using_yosys/more_scripting/selections.rst b/docs/source/using_yosys/more_scripting/selections.rst index 9c76b20b754..1f0efb1f321 100644 --- a/docs/source/using_yosys/more_scripting/selections.rst +++ b/docs/source/using_yosys/more_scripting/selections.rst @@ -9,7 +9,7 @@ The selection framework .. todo:: reduce overlap with :doc:`/getting_started/scripting_intro` select section -The :cmd:ref:`select` command can be used to create a selection for subsequent +The `select` command can be used to create a selection for subsequent commands. For example: .. code:: yoscrypt @@ -17,7 +17,7 @@ commands. For example: select foobar # select the module foobar delete # delete selected objects -Normally the :cmd:ref:`select` command overwrites a previous selection. The +Normally the `select` command overwrites a previous selection. The commands :yoscrypt:`select -add` and :yoscrypt:`select -del` can be used to add or remove objects from the current selection. @@ -26,16 +26,16 @@ default, which is a complete selection of everything in the current module. This selection framework can also be used directly in many other commands. Whenever a command has ``[selection]`` as last argument in its usage help, this -means that it will use the engine behind the :cmd:ref:`select` command to +means that it will use the engine behind the `select` command to evaluate additional arguments and use the resulting selection instead of the -selection created by the last :cmd:ref:`select` command. +selection created by the last `select` command. -For example, the command :cmd:ref:`delete` will delete everything in the current +For example, the command `delete` will delete everything in the current selection; while :yoscrypt:`delete foobar` will only delete the module foobar. -If no :cmd:ref:`select` command has been made, then the "current selection" will +If no `select` command has been made, then the "current selection" will be the whole design. -.. note:: Many of the examples on this page make use of the :cmd:ref:`show` +.. note:: Many of the examples on this page make use of the `show` command to visually demonstrate the effect of selections. For a more detailed look at this command, refer to :ref:`interactive_show`. @@ -59,7 +59,7 @@ Module and design context ^^^^^^^^^^^^^^^^^^^^^^^^^ Commands can be executed in *module/* or *design/* context. Until now, all -commands have been executed in design context. The :cmd:ref:`cd` command can be +commands have been executed in design context. The `cd` command can be used to switch to module context. In module context, all commands only effect the active module. Objects in the @@ -101,7 +101,7 @@ Operations on selections Combining selections ^^^^^^^^^^^^^^^^^^^^ -The :cmd:ref:`select` command is actually much more powerful than it might seem +The `select` command is actually much more powerful than it might seem at first glance. When it is called with multiple arguments, each argument is evaluated and pushed separately on a stack. After all arguments have been processed it simply creates the union of all elements on the stack. So @@ -190,7 +190,7 @@ Selecting logic cones :numref:`sumprod_01` shows what is called the ``input cone`` of ``sum``, i.e. all cells and signals that are used to generate the signal ``sum``. The ``%ci`` action can be used to select the input cones of all object in the top selection -in the stack maintained by the :cmd:ref:`select` command. +in the stack maintained by the `select` command. As with the ``%x`` action, these commands broaden the selection by one "step". But this time the operation only works against the direction of data flow. That @@ -222,9 +222,9 @@ The following sequence of diagrams demonstrates this step-wise expansion: Notice the subtle difference between :yoscrypt:`show prod %ci` and :yoscrypt:`show prod %ci %ci`. Both images show the `$mul` cell driven by some inputs ``$3_Y`` and ``c``. However it is not until the second image, -having called ``%ci`` the second time, that :cmd:ref:`show` is able to +having called ``%ci`` the second time, that `show` is able to distinguish between ``$3_Y`` being a wire and ``c`` being an input. We can see -this better with the :cmd:ref:`dump` command instead: +this better with the `dump` command instead: .. literalinclude:: /code_examples/selections/sumprod.out :language: RTLIL @@ -276,7 +276,7 @@ look at the first section: This loads :numref:`memdemo_src` and synthesizes the included module. Note that this code can be copied and run directly in a Yosys command line session, provided :file:`memdemo.v` is in the same directory. We can now change to the -``memdemo`` module with ``cd memdemo``, and call :cmd:ref:`show` to see the +``memdemo`` module with ``cd memdemo``, and call `show` to see the diagram in :numref:`memdemo_00`. .. figure:: /_images/code_examples/selections/memdemo_00.* @@ -387,14 +387,14 @@ Storing and recalling selections The current selection can be stored in memory with the command ``select -set ``. It can later be recalled using ``select @``. In fact, the ``@`` expression pushes the stored selection on the stack maintained by -the :cmd:ref:`select` command. So for example :yoscrypt:`select @foo @bar %i` +the `select` command. So for example :yoscrypt:`select @foo @bar %i` will select the intersection between the stored selections ``foo`` and ``bar``. In larger investigation efforts it is highly recommended to maintain a script that sets up relevant selections, so they can easily be recalled, for example when Yosys needs to be re-run after a design or source code change. -The :cmd:ref:`history` command can be used to list all recent interactive +The `history` command can be used to list all recent interactive commands. This feature can be useful for creating such a script from the commands used in an interactive session. diff --git a/docs/source/using_yosys/synthesis/abc.rst b/docs/source/using_yosys/synthesis/abc.rst index fca9ddec063..0c2e4868adf 100644 --- a/docs/source/using_yosys/synthesis/abc.rst +++ b/docs/source/using_yosys/synthesis/abc.rst @@ -10,11 +10,11 @@ fine-grained optimisation and LUT mapping. Yosys has two different commands, which both use this logic toolbox, but use it in different ways. -The :cmd:ref:`abc` pass can be used for both ASIC (e.g. :yoscrypt:`abc +The `abc` pass can be used for both ASIC (e.g. :yoscrypt:`abc -liberty`) and FPGA (:yoscrypt:`abc -lut`) mapping, but this page will focus on FPGA mapping. -The :cmd:ref:`abc9` pass generally provides superior mapping quality due to +The `abc9` pass generally provides superior mapping quality due to being aware of combination boxes and DFF and LUT timings, giving it a more global view of the mapping problem. @@ -23,7 +23,7 @@ global view of the mapping problem. ABC: the unit delay model, simple and efficient ----------------------------------------------- -The :cmd:ref:`abc` pass uses a highly simplified view of an FPGA: +The `abc` pass uses a highly simplified view of an FPGA: - An FPGA is made up of a network of inputs that connect through LUTs to a network of outputs. These inputs may actually be I/O pins, D flip-flops, @@ -126,7 +126,7 @@ guide to the syntax: By convention, all delays in ``specify`` blocks are in integer picoseconds. Files containing ``specify`` blocks should be read with the ``-specify`` option -to :cmd:ref:`read_verilog` so that they aren't skipped. +to `read_verilog` so that they aren't skipped. LUTs ^^^^ @@ -145,9 +145,9 @@ DFFs DFFs should be annotated with an ``(* abc9_flop *)`` attribute, however ABC9 has some specific requirements for this to be valid: - the DFF must initialise to -zero (consider using :cmd:ref:`dfflegalize` to ensure this). - the DFF cannot -have any asynchronous resets/sets (see the simplification idiom and the Boxes -section for what to do here). +zero (consider using `dfflegalize` to ensure this). - the DFF cannot have any +asynchronous resets/sets (see the simplification idiom and the Boxes section for +what to do here). It is worth noting that in pure ``abc9`` mode, only the setup and arrival times are passed to ABC9 (specifically, they are modelled as buffers with the given @@ -158,9 +158,9 @@ Some vendors have universal DFF models which include async sets/resets even when they're unused. Therefore *the simplification idiom* exists to handle this: by using a ``techmap`` file to discover flops which have a constant driver to those asynchronous controls, they can be mapped into an intermediate, simplified flop -which qualifies as an ``(* abc9_flop *)``, ran through :cmd:ref:`abc9`, and then -mapped back to the original flop. This is used in :cmd:ref:`synth_intel_alm` and -:cmd:ref:`synth_quicklogic` for the PolarPro3. +which qualifies as an ``(* abc9_flop *)``, ran through `abc9`, and then mapped +back to the original flop. This is used in `synth_intel_alm` and +`synth_quicklogic` for the PolarPro3. DFFs are usually specified to have setup constraints against the clock on the input signals, and an arrival time for the ``Q`` output. diff --git a/docs/source/using_yosys/synthesis/cell_libs.rst b/docs/source/using_yosys/synthesis/cell_libs.rst index 58b6431a588..c8dbba8381a 100644 --- a/docs/source/using_yosys/synthesis/cell_libs.rst +++ b/docs/source/using_yosys/synthesis/cell_libs.rst @@ -54,7 +54,7 @@ Our circuit now looks like this: :class: width-helper invert-helper :name: counter-hierarchy - ``counter`` after :cmd:ref:`hierarchy` + ``counter`` after `hierarchy` Coarse-grain representation ~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -82,7 +82,7 @@ Logic gate mapping .. figure:: /_images/code_examples/intro/counter_02.* :class: width-helper invert-helper - ``counter`` after :cmd:ref:`techmap` + ``counter`` after `techmap` Mapping to hardware ~~~~~~~~~~~~~~~~~~~ @@ -102,7 +102,7 @@ Recall that the Yosys built-in logic gate types are `$_NOT_`, `$_AND_`, `$_OR_`, `$_XOR_`, and `$_MUX_` with an assortment of dff memory types. :ref:`mycells-lib` defines our target cells as ``BUF``, ``NOT``, ``NAND``, ``NOR``, and ``DFF``. Mapping between these is performed with the commands -:cmd:ref:`dfflibmap` and :cmd:ref:`abc` as follows: +`dfflibmap` and `abc` as follows: .. literalinclude:: /code_examples/intro/counter.ys :language: yoscrypt @@ -117,7 +117,7 @@ The final version of our ``counter`` module looks like this: ``counter`` after hardware cell mapping -Before finally being output as a verilog file with :cmd:ref:`write_verilog`, +Before finally being output as a verilog file with `write_verilog`, which can then be loaded into another tool: .. literalinclude:: /code_examples/intro/counter.ys diff --git a/docs/source/using_yosys/synthesis/extract.rst b/docs/source/using_yosys/synthesis/extract.rst index c9b76840e3b..176e2ffdd5c 100644 --- a/docs/source/using_yosys/synthesis/extract.rst +++ b/docs/source/using_yosys/synthesis/extract.rst @@ -1,13 +1,13 @@ The extract pass ---------------- -- Like the :cmd:ref:`techmap` pass, the :cmd:ref:`extract` pass is called with a +- Like the `techmap` pass, the `extract` pass is called with a map file. It compares the circuits inside the modules of the map file with the design and looks for sub-circuits in the design that match any of the modules in the map file. -- If a match is found, the :cmd:ref:`extract` pass will replace the matching +- If a match is found, the `extract` pass will replace the matching subcircuit with an instance of the module from the map file. -- In a way the :cmd:ref:`extract` pass is the inverse of the techmap pass. +- In a way the `extract` pass is the inverse of the techmap pass. .. todo:: add/expand supporting text, also mention custom pattern matching and pmgen @@ -25,7 +25,7 @@ Example code can be found in |code_examples/macc|_. .. figure:: /_images/code_examples/macc/macc_simple_test_00a.* :class: width-helper invert-helper - before :cmd:ref:`extract` + before `extract` .. literalinclude:: /code_examples/macc/macc_simple_test.ys :language: yoscrypt @@ -34,7 +34,7 @@ Example code can be found in |code_examples/macc|_. .. figure:: /_images/code_examples/macc/macc_simple_test_00b.* :class: width-helper invert-helper - after :cmd:ref:`extract` + after `extract` .. literalinclude:: /code_examples/macc/macc_simple_test.v :language: verilog @@ -76,18 +76,18 @@ wrap-extract-unwrap method: wrap Identify candidate-cells in the circuit and wrap them in a cell with a - constant wider bit-width using :cmd:ref:`techmap`. The wrappers use the same + constant wider bit-width using `techmap`. The wrappers use the same parameters as the original cell, so the information about the original width - of the ports is preserved. Then use the :cmd:ref:`connwrappers` command to + of the ports is preserved. Then use the `connwrappers` command to connect up the bit-extended in- and outputs of the wrapper cells. extract Now all operations are encoded using the same bit-width as the coarse grain - element. The :cmd:ref:`extract` command can be used to replace circuits with + element. The `extract` command can be used to replace circuits with cells of the target architecture. unwrap - The remaining wrapper cell can be unwrapped using :cmd:ref:`techmap`. + The remaining wrapper cell can be unwrapped using `techmap`. Example: DSP48_MACC ~~~~~~~~~~~~~~~~~~~ @@ -127,7 +127,7 @@ Extract: :file:`macc_xilinx_xmap.v` :caption: :file:`macc_xilinx_xmap.v` ... simply use the same wrapping commands on this module as on the design to -create a template for the :cmd:ref:`extract` command. +create a template for the `extract` command. Unwrapping multipliers: :file:`macc_xilinx_unwrap_map.v` diff --git a/docs/source/using_yosys/synthesis/fsm.rst b/docs/source/using_yosys/synthesis/fsm.rst index 3c5a80ad346..cb65a298be0 100644 --- a/docs/source/using_yosys/synthesis/fsm.rst +++ b/docs/source/using_yosys/synthesis/fsm.rst @@ -1,14 +1,14 @@ FSM handling ============ -The :cmd:ref:`fsm` command identifies, extracts, optimizes (re-encodes), and +The `fsm` command identifies, extracts, optimizes (re-encodes), and re-synthesizes finite state machines. It again is a macro that calls a series of other commands: .. literalinclude:: /code_examples/macro_commands/fsm.ys :language: yoscrypt :start-after: #end: - :caption: Passes called by :cmd:ref:`fsm` + :caption: Passes called by `fsm` See also :doc:`/cmd/fsm`. @@ -18,7 +18,7 @@ general reported technique :cite:p:`fsmextract`. FSM detection ~~~~~~~~~~~~~ -The :cmd:ref:`fsm_detect` pass identifies FSM state registers. It sets the +The `fsm_detect` pass identifies FSM state registers. It sets the ``\fsm_encoding = "auto"`` attribute on any (multi-bit) wire that matches the following description: @@ -44,7 +44,7 @@ results. FSM extraction ~~~~~~~~~~~~~~ -The :cmd:ref:`fsm_extract` pass operates on all state signals marked with the +The `fsm_extract` pass operates on all state signals marked with the (``\fsm_encoding != "none"``) attribute. For each state signal the following information is determined: @@ -87,7 +87,7 @@ given set of result signals using a set of signal-value assignments. It can also be passed a list of stop-signals that abort the ConstEval algorithm if the value of a stop-signal is needed in order to calculate the result signals. -The :cmd:ref:`fsm_extract` pass uses the ConstEval class in the following way to +The `fsm_extract` pass uses the ConstEval class in the following way to create a transition table. For each state: 1. Create a ConstEval object for the module containing the FSM @@ -108,12 +108,12 @@ drivers for the control outputs are disconnected. FSM optimization ~~~~~~~~~~~~~~~~ -The :cmd:ref:`fsm_opt` pass performs basic optimizations on `$fsm` cells (not +The `fsm_opt` pass performs basic optimizations on `$fsm` cells (not including state recoding). The following optimizations are performed (in this order): - Unused control outputs are removed from the `$fsm` cell. The attribute - ``\unused_bits`` (that is usually set by the :cmd:ref:`opt_clean` pass) is + ``\unused_bits`` (that is usually set by the `opt_clean` pass) is used to determine which control outputs are unused. - Control inputs that are connected to the same driver are merged. @@ -134,11 +134,11 @@ order): FSM recoding ~~~~~~~~~~~~ -The :cmd:ref:`fsm_recode` pass assigns new bit pattern to the states. Usually +The `fsm_recode` pass assigns new bit pattern to the states. Usually this also implies a change in the width of the state signal. At the moment of this writing only one-hot encoding with all-zero for the reset state is supported. -The :cmd:ref:`fsm_recode` pass can also write a text file with the changes +The `fsm_recode` pass can also write a text file with the changes performed by it that can be used when verifying designs synthesized by Yosys using Synopsys Formality. diff --git a/docs/source/using_yosys/synthesis/index.rst b/docs/source/using_yosys/synthesis/index.rst index c00a940daa6..ae6da302a21 100644 --- a/docs/source/using_yosys/synthesis/index.rst +++ b/docs/source/using_yosys/synthesis/index.rst @@ -8,17 +8,17 @@ coarse-grain optimizations before being mapped to hard blocks and fine-grain cells. Most commands in Yosys will target either coarse-grain representation or fine-grain representation, with only a select few compatible with both states. -Commands such as :cmd:ref:`proc`, :cmd:ref:`fsm`, and :cmd:ref:`memory` rely on +Commands such as `proc`, `fsm`, and `memory` rely on the additional information in the coarse-grain representation, along with a -number of optimizations such as :cmd:ref:`wreduce`, :cmd:ref:`share`, and -:cmd:ref:`alumacc`. :cmd:ref:`opt` provides optimizations which are useful in -both states, while :cmd:ref:`techmap` is used to convert coarse-grain cells +number of optimizations such as `wreduce`, `share`, and +`alumacc`. `opt` provides optimizations which are useful in +both states, while `techmap` is used to convert coarse-grain cells to the corresponding fine-grain representation. Single-bit cells (logic gates, FFs) as well as LUTs, half-adders, and full-adders make up the bulk of the fine-grain representation and are necessary -for commands such as :cmd:ref:`abc`\ /:cmd:ref:`abc9`, :cmd:ref:`simplemap`, -:cmd:ref:`dfflegalize`, and :cmd:ref:`memory_map`. +for commands such as `abc`\ /`abc9`, `simplemap`, +`dfflegalize`, and `memory_map`. .. toctree:: :maxdepth: 3 diff --git a/docs/source/using_yosys/synthesis/memory.rst b/docs/source/using_yosys/synthesis/memory.rst index dcbde2ae69b..ad8b47d78fc 100644 --- a/docs/source/using_yosys/synthesis/memory.rst +++ b/docs/source/using_yosys/synthesis/memory.rst @@ -1,11 +1,11 @@ Memory handling =============== -The :cmd:ref:`memory` command +The `memory` command ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In the RTL netlist, memory reads and writes are individual cells. This makes -consolidating the number of ports for a memory easier. The :cmd:ref:`memory` +consolidating the number of ports for a memory easier. The `memory` pass transforms memories to an implementation. Per default that is logic for address decoders and registers. It also is a macro command that calls the other common ``memory_*`` passes in a sensible order: @@ -13,19 +13,19 @@ common ``memory_*`` passes in a sensible order: .. literalinclude:: /code_examples/macro_commands/memory.ys :language: yoscrypt :start-after: #end: - :caption: Passes called by :cmd:ref:`memory` + :caption: Passes called by `memory` .. todo:: Make ``memory_*`` notes less quick Some quick notes: -- :cmd:ref:`memory_dff` merges registers into the memory read- and write cells. -- :cmd:ref:`memory_collect` collects all read and write cells for a memory and +- `memory_dff` merges registers into the memory read- and write cells. +- `memory_collect` collects all read and write cells for a memory and transforms them into one multi-port memory cell. -- :cmd:ref:`memory_map` takes the multi-port memory cell and transforms it to +- `memory_map` takes the multi-port memory cell and transforms it to address decoder logic and registers. -For more information about :cmd:ref:`memory`, such as disabling certain sub +For more information about `memory`, such as disabling certain sub commands, see :doc:`/cmd/memory`. Example @@ -75,22 +75,22 @@ For example: techmap -map my_memory_map.v memory_map -:cmd:ref:`memory_libmap` attempts to convert memory cells (`$mem_v2` etc) into +`memory_libmap` attempts to convert memory cells (`$mem_v2` etc) into hardware supported memory using a provided library (:file:`my_memory_map.txt` in the example above). Where necessary, emulation logic is added to ensure functional equivalence before and after this conversion. :yoscrypt:`techmap -map -my_memory_map.v` then uses :cmd:ref:`techmap` to map to hardware primitives. Any +my_memory_map.v` then uses `techmap` to map to hardware primitives. Any leftover memory cells unable to be converted are then picked up by -:cmd:ref:`memory_map` and mapped to DFFs and address decoders. +`memory_map` and mapped to DFFs and address decoders. .. note:: More information about what mapping options are available and associated costs of each can be found by enabling debug outputs. This can be done with - the :cmd:ref:`debug` command, or by using the ``-g`` flag when calling Yosys + the `debug` command, or by using the ``-g`` flag when calling Yosys to globally enable debug messages. -For more on the lib format for :cmd:ref:`memory_libmap`, see +For more on the lib format for `memory_libmap`, see `passes/memory/memlib.md `_ diff --git a/docs/source/using_yosys/synthesis/opt.rst b/docs/source/using_yosys/synthesis/opt.rst index cd40f699906..db1525a05ad 100644 --- a/docs/source/using_yosys/synthesis/opt.rst +++ b/docs/source/using_yosys/synthesis/opt.rst @@ -6,10 +6,10 @@ This chapter outlines these optimizations. .. todo:: "outlines these optimizations" or "outlines *some*.."? -The :cmd:ref:`opt` macro command +The `opt` macro command -------------------------------- -The Yosys pass :cmd:ref:`opt` runs a number of simple optimizations. This +The Yosys pass `opt` runs a number of simple optimizations. This includes removing unused signals and cells and const folding. It is recommended to run this pass after each major step in the synthesis script. As listed in :doc:`/cmd/opt`, this macro command calls the following ``opt_*`` commands: @@ -17,11 +17,11 @@ to run this pass after each major step in the synthesis script. As listed in .. literalinclude:: /code_examples/macro_commands/opt.ys :language: yoscrypt :start-after: #end: - :caption: Passes called by :cmd:ref:`opt` + :caption: Passes called by `opt` .. _adv_opt_expr: -Constant folding and simple expression rewriting - :cmd:ref:`opt_expr` +Constant folding and simple expression rewriting - `opt_expr` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. todo:: unsure if this is too much detail and should be in :doc:`/yosys_internals/index` @@ -31,7 +31,7 @@ described in :doc:`/yosys_internals/formats/cell_library`. This means a cell with all constant inputs is replaced with the constant value this cell drives. In some cases this pass can also optimize cells with some constant inputs. -.. table:: Const folding rules for `$_AND_` cells as used in :cmd:ref:`opt_expr`. +.. table:: Const folding rules for `$_AND_` cells as used in `opt_expr`. :name: tab:opt_expr_and :align: center @@ -69,7 +69,7 @@ undef. The last two lines simply replace an `$_AND_` gate with one constant-1 input with a buffer. -Besides this basic const folding the :cmd:ref:`opt_expr` pass can replace 1-bit +Besides this basic const folding the `opt_expr` pass can replace 1-bit wide `$eq` and `$ne` cells with buffers or not-gates if one input is constant. Equality checks may also be reduced in size if there are redundant bits in the arguments (i.e. bits which are constant on both inputs). This can, @@ -77,7 +77,7 @@ for example, result in a 32-bit wide constant like ``255`` being reduced to the 8-bit value of ``8'11111111`` if the signal being compared is only 8-bit as in :ref:`addr_gen_clean` of :doc:`/getting_started/example_synth`. -The :cmd:ref:`opt_expr` pass is very conservative regarding optimizing `$mux` +The `opt_expr` pass is very conservative regarding optimizing `$mux` cells, as these cells are often used to model decision-trees and breaking these trees can interfere with other optimizations. @@ -85,14 +85,14 @@ trees can interfere with other optimizations. :language: Verilog :start-after: read_verilog <fixup_ports()`` after changing the ``port_*`` properties of wires. - You can safely remove cells or change the ``connections`` property of a cell, diff --git a/docs/source/yosys_internals/flow/verilog_frontend.rst b/docs/source/yosys_internals/flow/verilog_frontend.rst index 7c8c9d8fbad..fced46e8ca7 100644 --- a/docs/source/yosys_internals/flow/verilog_frontend.rst +++ b/docs/source/yosys_internals/flow/verilog_frontend.rst @@ -600,15 +600,15 @@ The proc pass The ProcessGenerator converts a behavioural model in AST representation to a behavioural model in ``RTLIL::Process`` representation. The actual conversion from a behavioural model to an RTL representation is performed by the -:cmd:ref:`proc` pass and the passes it launches: +`proc` pass and the passes it launches: -- | :cmd:ref:`proc_clean` and :cmd:ref:`proc_rmdead` +- | `proc_clean` and `proc_rmdead` | These two passes just clean up the ``RTLIL::Process`` structure. The - :cmd:ref:`proc_clean` pass removes empty parts (eg. empty assignments) from - the process and :cmd:ref:`proc_rmdead` detects and removes unreachable + `proc_clean` pass removes empty parts (eg. empty assignments) from + the process and `proc_rmdead` detects and removes unreachable branches from the process's decision trees. -- | :cmd:ref:`proc_arst` +- | `proc_arst` | This pass detects processes that describe d-type flip-flops with asynchronous resets and rewrites the process to better reflect what they are modelling: Before this pass, an asynchronous reset has two @@ -616,21 +616,21 @@ from a behavioural model to an RTL representation is performed by the reset path. After this pass the sync rule for the reset is level-sensitive and the top-level ``RTLIL::SwitchRule`` has been removed. -- | :cmd:ref:`proc_mux` +- | `proc_mux` | This pass converts the ``RTLIL::CaseRule``/\ ``RTLIL::SwitchRule``-tree to a tree of multiplexers per written signal. After this, the ``RTLIL::Process`` structure only contains the ``RTLIL::SyncRule`` s that describe the output registers. -- | :cmd:ref:`proc_dff` +- | `proc_dff` | This pass replaces the ``RTLIL::SyncRule``\ s to d-type flip-flops (with asynchronous resets if necessary). -- | :cmd:ref:`proc_dff` +- | `proc_dff` | This pass replaces the ``RTLIL::MemWriteAction``\ s with `$memwr` cells. -- | :cmd:ref:`proc_clean` - | A final call to :cmd:ref:`proc_clean` removes the now empty +- | `proc_clean` + | A final call to `proc_clean` removes the now empty ``RTLIL::Process`` objects. Performing these last processing steps in passes instead of in the Verilog diff --git a/docs/source/yosys_internals/formats/cell_library.rst b/docs/source/yosys_internals/formats/cell_library.rst index cd1496e11e4..e9ed4d7f9be 100644 --- a/docs/source/yosys_internals/formats/cell_library.rst +++ b/docs/source/yosys_internals/formats/cell_library.rst @@ -258,7 +258,7 @@ additional two parameters: ``\ARST_VALUE`` The state of ``\Q`` will be set to this value when the reset is active. -Usually these cells are generated by the :cmd:ref:`proc` pass using the +Usually these cells are generated by the `proc` pass using the information in the designs RTLIL::Process objects. D-type flip-flops with synchronous reset are represented by `$sdff` cells. As @@ -472,7 +472,7 @@ synthesis to succeed. initialization conflict. The HDL frontend models a memory using ``RTLIL::Memory`` objects and -asynchronous `$memrd_v2` and `$memwr_v2` cells. The :cmd:ref:`memory` pass +asynchronous `$memrd_v2` and `$memwr_v2` cells. The `memory` pass (i.e. its various sub-passes) migrates `$dff` cells into the `$memrd_v2` and `$memwr_v2` cells making them synchronous, then converts them to a single `$mem_v2` cell and (optionally) maps this cell type to `$dff` cells for the @@ -604,14 +604,14 @@ The `$mem_v2` cell has the following ports: This input is ``\WR_PORTS*\WIDTH`` bits wide, containing all data signals for the write ports. -The :cmd:ref:`memory_collect` pass can be used to convert discrete +The `memory_collect` pass can be used to convert discrete `$memrd_v2`, `$memwr_v2`, and `$meminit_v2` cells belonging to the same -memory to a single `$mem_v2` cell, whereas the :cmd:ref:`memory_unpack` pass -performs the inverse operation. The :cmd:ref:`memory_dff` pass can combine +memory to a single `$mem_v2` cell, whereas the `memory_unpack` pass +performs the inverse operation. The `memory_dff` pass can combine asynchronous memory ports that are fed by or feeding registers into synchronous -memory ports. The :cmd:ref:`memory_bram` pass can be used to recognize +memory ports. The `memory_bram` pass can be used to recognize `$mem_v2` cells that can be implemented with a block RAM resource on an FPGA. -The :cmd:ref:`memory_map` pass can be used to implement `$mem_v2` cells as +The `memory_map` pass can be used to implement `$mem_v2` cells as basic logic: word-wide DFFs and address decoders. Finite state machines diff --git a/docs/source/yosys_internals/formats/rtlil_rep.rst b/docs/source/yosys_internals/formats/rtlil_rep.rst index 785a2d28b38..fec970532af 100644 --- a/docs/source/yosys_internals/formats/rtlil_rep.rst +++ b/docs/source/yosys_internals/formats/rtlil_rep.rst @@ -76,7 +76,7 @@ This has three advantages: - Second, the information about which identifiers were originally provided by the user is always available which can help guide some optimizations. For - example, :cmd:ref:`opt_clean` tries to preserve signals with a user-provided + example, `opt_clean` tries to preserve signals with a user-provided name but doesn't hesitate to delete signals that have auto-generated names when they just duplicate other signals. Note that this can be overridden with the ``-purge`` option to also delete internal nets with user-provided @@ -320,7 +320,7 @@ trees before further processing them. One of the first actions performed on a design in RTLIL representation in most synthesis scripts is identifying asynchronous resets. This is usually done using -the :cmd:ref:`proc_arst` pass. This pass transforms the above example to the +the `proc_arst` pass. This pass transforms the above example to the following ``RTLIL::Process``: .. code:: RTLIL diff --git a/docs/source/yosys_internals/techmap.rst b/docs/source/yosys_internals/techmap.rst index e5d6972ee78..f894394bb04 100644 --- a/docs/source/yosys_internals/techmap.rst +++ b/docs/source/yosys_internals/techmap.rst @@ -1,7 +1,7 @@ Techmap by example ------------------ -As a quick recap, the :cmd:ref:`techmap` command replaces cells in the design +As a quick recap, the `techmap` command replaces cells in the design with implementations given as Verilog code (called "map files"). It can replace Yosys' internal cell types (such as `$or`) as well as user-defined cell types. @@ -87,14 +87,14 @@ Scripting in map modules - You can even call techmap recursively! - Example use-cases: - - Using always blocks in map module: call :cmd:ref:`proc` - - Perform expensive optimizations (such as :cmd:ref:`freduce`) on cells + - Using always blocks in map module: call `proc` + - Perform expensive optimizations (such as `freduce`) on cells where this is known to work well. - Interacting with custom commands. .. note:: PROTIP: - Commands such as :cmd:ref:`shell`, ``show -pause``, and :cmd:ref:`dump` can + Commands such as `shell`, ``show -pause``, and `dump` can be used in the ``_TECHMAP_DO_*`` scripts for debugging map modules. Example: From 40ba92e956461beb2a6369a638fcec050962a36d Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Fri, 3 May 2024 13:38:01 +1200 Subject: [PATCH 16/68] Docs: Reflow line length --- docs/source/getting_started/example_synth.rst | 316 +++++++-------- docs/source/getting_started/installation.rst | 5 +- .../getting_started/scripting_intro.rst | 56 ++- docs/source/introduction.rst | 26 +- .../interactive_investigation.rst | 221 +++++------ .../more_scripting/model_checking.rst | 3 +- .../using_yosys/more_scripting/selections.rst | 74 ++-- docs/source/using_yosys/synthesis/abc.rst | 11 +- .../using_yosys/synthesis/cell_libs.rst | 8 +- docs/source/using_yosys/synthesis/extract.rst | 28 +- docs/source/using_yosys/synthesis/fsm.rst | 31 +- docs/source/using_yosys/synthesis/index.rst | 15 +- docs/source/using_yosys/synthesis/memory.rst | 210 +++++----- docs/source/using_yosys/synthesis/opt.rst | 82 ++-- docs/source/using_yosys/synthesis/proc.rst | 18 +- .../extending_yosys/extensions.rst | 15 +- .../yosys_internals/flow/verilog_frontend.rst | 26 +- .../yosys_internals/formats/cell_library.rst | 375 +++++++++--------- .../yosys_internals/formats/rtlil_rep.rst | 47 ++- docs/source/yosys_internals/techmap.rst | 8 +- 20 files changed, 786 insertions(+), 789 deletions(-) diff --git a/docs/source/getting_started/example_synth.rst b/docs/source/getting_started/example_synth.rst index ec1f967ea48..f8530b45bbf 100644 --- a/docs/source/getting_started/example_synth.rst +++ b/docs/source/getting_started/example_synth.rst @@ -2,13 +2,12 @@ Synthesis starter ----------------- This page will be a guided walkthrough of the prepackaged iCE40 FPGA synthesis -script - `synth_ice40`. We will take a simple design through each -step, looking at the commands being called and what they do to the design. While -`synth_ice40` is specific to the iCE40 platform, most of the operations -we will be discussing are common across the majority of FPGA synthesis scripts. -Thus, this document will provide a good foundational understanding of how -synthesis in Yosys is performed, regardless of the actual architecture being -used. +script - `synth_ice40`. We will take a simple design through each step, looking +at the commands being called and what they do to the design. While `synth_ice40` +is specific to the iCE40 platform, most of the operations we will be discussing +are common across the majority of FPGA synthesis scripts. Thus, this document +will provide a good foundational understanding of how synthesis in Yosys is +performed, regardless of the actual architecture being used. .. seealso:: Advanced usage docs for :doc:`/using_yosys/synthesis/synth` @@ -105,10 +104,10 @@ Since we're just getting started, let's instead begin with :yoscrypt:`hierarchy .. note:: - `hierarchy` should always be the first command after the design has - been read. By specifying the top module, `hierarchy` will also set - the ``(* top *)`` attribute on it. This is used by other commands that need - to know which module is the top. + `hierarchy` should always be the first command after the design has been + read. By specifying the top module, `hierarchy` will also set the ``(* top + *)`` attribute on it. This is used by other commands that need to know which + module is the top. .. use doscon for a console-like display that supports the `yosys> [command]` format. @@ -129,20 +128,20 @@ Our ``addr_gen`` circuit now looks like this: Simple operations like ``addr + 1`` and ``addr == MAX_DATA-1`` can be extracted from our ``always @`` block in :ref:`addr_gen-v`. This gives us the highlighted -`$add` and `$eq` cells we see. But control logic (like the ``if .. else``) -and memory elements (like the ``addr <= 0``) are not so straightforward. These -get put into "processes", shown in the schematic as ``PROC``. Note how the -second line refers to the line numbers of the start/end of the corresponding -``always @`` block. In the case of an ``initial`` block, we instead see the -``PROC`` referring to line 0. - -To handle these, let us now introduce the next command: :doc:`/cmd/proc`. -`proc` is a macro command like `synth_ice40`. Rather than -modifying the design directly, it instead calls a series of other commands. In -the case of `proc`, these sub-commands work to convert the behavioral -logic of processes into multiplexers and registers. Let's see what happens when -we run it. For now, we will call :yoscrypt:`proc -noopt` to prevent some -automatic optimizations which would normally happen. +`$add` and `$eq` cells we see. But control logic (like the ``if .. else``) and +memory elements (like the ``addr <= 0``) are not so straightforward. These get +put into "processes", shown in the schematic as ``PROC``. Note how the second +line refers to the line numbers of the start/end of the corresponding ``always +@`` block. In the case of an ``initial`` block, we instead see the ``PROC`` +referring to line 0. + +To handle these, let us now introduce the next command: :doc:`/cmd/proc`. `proc` +is a macro command like `synth_ice40`. Rather than modifying the design +directly, it instead calls a series of other commands. In the case of `proc`, +these sub-commands work to convert the behavioral logic of processes into +multiplexers and registers. Let's see what happens when we run it. For now, we +will call :yoscrypt:`proc -noopt` to prevent some automatic optimizations which +would normally happen. .. figure:: /_images/code_examples/fifo/addr_gen_proc.* :class: width-helper invert-helper @@ -151,19 +150,18 @@ automatic optimizations which would normally happen. ``addr_gen`` module after :yoscrypt:`proc -noopt` There are now a few new cells from our ``always @``, which have been -highlighted. The ``if`` statements are now modeled with `$mux` cells, while -the register uses an `$adff` cell. If we look at the terminal output we can -also see all of the different ``proc_*`` commands being called. We will look at -each of these in more detail in :doc:`/using_yosys/synthesis/proc`. +highlighted. The ``if`` statements are now modeled with `$mux` cells, while the +register uses an `$adff` cell. If we look at the terminal output we can also +see all of the different ``proc_*`` commands being called. We will look at each +of these in more detail in :doc:`/using_yosys/synthesis/proc`. Notice how in the top left of :ref:`addr_gen_proc` we have a floating wire, generated from the initial assignment of 0 to the ``addr`` wire. However, this initial assignment is not synthesizable, so this will need to be cleaned up before we can generate the physical hardware. We can do this now by calling -`clean`. We're also going to call `opt_expr` now, which would -normally be called at the end of `proc`. We can call both commands at -the same time by separating them with a colon and space: :yoscrypt:`opt_expr; -clean`. +`clean`. We're also going to call `opt_expr` now, which would normally be +called at the end of `proc`. We can call both commands at the same time by +separating them with a colon and space: :yoscrypt:`opt_expr; clean`. .. figure:: /_images/code_examples/fifo/addr_gen_clean.* :class: width-helper invert-helper @@ -171,24 +169,24 @@ clean`. ``addr_gen`` module after :yoscrypt:`opt_expr; clean` -You may also notice that the highlighted `$eq` cell input of ``255`` has -changed to ``8'11111111``. Constant values are presented in the format +You may also notice that the highlighted `$eq` cell input of ``255`` has changed +to ``8'11111111``. Constant values are presented in the format ``'``, with 32-bit values instead using the decimal number. This indicates that the constant input has been reduced from 32-bit wide to -8-bit wide. This is a side-effect of running `opt_expr`, which -performs constant folding and simple expression rewriting. For more on why -this happens, refer to :doc:`/using_yosys/synthesis/opt` and the :ref:`section -on opt_expr `. +8-bit wide. This is a side-effect of running `opt_expr`, which performs +constant folding and simple expression rewriting. For more on why this +happens, refer to :doc:`/using_yosys/synthesis/opt` and the :ref:`section on +opt_expr `. .. note:: :doc:`/cmd/clean` can also be called with two semicolons after any command, for example we could have called :yoscrypt:`opt_expr;;` instead of :yoscrypt:`opt_expr; clean`. You may notice some scripts will end each line - with ``;;``. It is beneficial to run `clean` before inspecting - intermediate products to remove disconnected parts of the circuit which have - been left over, and in some cases can reduce the processing required in - subsequent commands. + with ``;;``. It is beneficial to run `clean` before inspecting intermediate + products to remove disconnected parts of the circuit which have been left + over, and in some cases can reduce the processing required in subsequent + commands. .. todo:: consider a brief glossary for terms like adff @@ -202,8 +200,8 @@ The full example Let's now go back and check on our full design by using :yoscrypt:`hierarchy -check -top fifo`. By passing the ``-check`` option there we are also telling -the `hierarchy` command that if the design includes any non-blackbox -modules without an implementation it should return an error. +the `hierarchy` command that if the design includes any non-blackbox modules +without an implementation it should return an error. Note that if we tried to run this command now then we would get an error. This is because we already removed all of the modules other than ``addr_gen``. We @@ -221,13 +219,12 @@ could restart our shell session, but instead let's use two new commands: Notice how this time we didn't see any of those ``$abstract`` modules? That's because when we ran ``yosys fifo.v``, the first command Yosys called was :yoscrypt:`read_verilog -defer fifo.v`. The ``-defer`` option there tells -`read_verilog` only read the abstract syntax tree and defer actual -compilation to a later `hierarchy` command. This is useful in cases -where the default parameters of modules yield invalid code which is not -synthesizable. This is why Yosys defers compilation automatically and is one of -the reasons why hierarchy should always be the first command after loading the -design. If we know that our design won't run into this issue, we can skip the -``-defer``. +`read_verilog` only read the abstract syntax tree and defer actual compilation +to a later `hierarchy` command. This is useful in cases where the default +parameters of modules yield invalid code which is not synthesizable. This is why +Yosys defers compilation automatically and is one of the reasons why hierarchy +should always be the first command after loading the design. If we know that +our design won't run into this issue, we can skip the ``-defer``. .. todo:: `hierarchy` failure modes @@ -243,13 +240,13 @@ design. If we know that our design won't run into this issue, we can skip the interactive terminal. :kbd:`ctrl+c` (i.e. SIGINT) will also end the terminal session but will return an error code rather than exiting gracefully. -We can also run `proc` now to finish off the full :ref:`synth_begin`. -Because the design schematic is quite large, we will be showing just the data -path for the ``rdata`` output. If you would like to see the entire design for -yourself, you can do so with :doc:`/cmd/show`. Note that the `show` -command only works with a single module, so you may need to call it with -:yoscrypt:`show fifo`. :ref:`show_intro` section in -:doc:`/getting_started/scripting_intro` has more on how to use `show`. +We can also run `proc` now to finish off the full :ref:`synth_begin`. Because +the design schematic is quite large, we will be showing just the data path for +the ``rdata`` output. If you would like to see the entire design for yourself, +you can do so with :doc:`/cmd/show`. Note that the `show` command only works +with a single module, so you may need to call it with :yoscrypt:`show fifo`. +:ref:`show_intro` section in :doc:`/getting_started/scripting_intro` has more on +how to use `show`. .. figure:: /_images/code_examples/fifo/rdata_proc.* :class: width-helper invert-helper @@ -321,11 +318,10 @@ merging happened during the call to `clean` which we can see in the output. Depending on the target architecture, this stage of synthesis might also see -commands such as `tribuf` with the ``-logic`` option and -`deminout`. These remove tristate and inout constructs respectively, -replacing them with logic suitable for mapping to an FPGA. Since we do not have -any such constructs in our example running these commands does not change our -design. +commands such as `tribuf` with the ``-logic`` option and `deminout`. These +remove tristate and inout constructs respectively, replacing them with logic +suitable for mapping to an FPGA. Since we do not have any such constructs in +our example running these commands does not change our design. The coarse-grain representation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -342,9 +338,9 @@ optimizations and other transformations done previously. .. note:: - While the iCE40 flow had a :ref:`synth_flatten` and put `proc` in - the :ref:`synth_begin`, some synthesis scripts will instead include these in - this section. + While the iCE40 flow had a :ref:`synth_flatten` and put `proc` in the + :ref:`synth_begin`, some synthesis scripts will instead include these in this + section. Part 1 ^^^^^^ @@ -359,24 +355,23 @@ In the iCE40 flow, we start with the following commands: :caption: ``coarse`` section (part 1) :name: synth_coarse1 -We've already come across `opt_expr`, and `opt_clean` is the -same as `clean` but with more verbose output. The `check` -pass identifies a few obvious problems which will cause errors later. Calling -it here lets us fail faster rather than wasting time on something we know is -impossible. +We've already come across `opt_expr`, and `opt_clean` is the same as `clean` but +with more verbose output. The `check` pass identifies a few obvious problems +which will cause errors later. Calling it here lets us fail faster rather than +wasting time on something we know is impossible. Next up is :yoscrypt:`opt -nodffe -nosdff` performing a set of simple optimizations on the design. This command also ensures that only a specific subset of FF types are included, in preparation for the next command: -:doc:`/cmd/fsm`. Both `opt` and `fsm` are macro commands -which are explored in more detail in :doc:`/using_yosys/synthesis/opt` and +:doc:`/cmd/fsm`. Both `opt` and `fsm` are macro commands which are explored in +more detail in :doc:`/using_yosys/synthesis/opt` and :doc:`/using_yosys/synthesis/fsm` respectively. Up until now, the data path for ``rdata`` has remained the same since :ref:`rdata_flat`. However the next call to `opt` does cause a change. -Specifically, the call to `opt_dff` without the ``-nodffe -nosdff`` -options is able to fold one of the `$mux` cells into the `$adff` to form an -`$adffe` cell; highlighted below: +Specifically, the call to `opt_dff` without the ``-nodffe -nosdff`` options is +able to fold one of the `$mux` cells into the `$adff` to form an `$adffe` cell; +highlighted below: .. literalinclude:: /code_examples/fifo/fifo.out :language: doscon @@ -433,8 +428,8 @@ The next two (new) commands are :doc:`/cmd/peepopt` and :doc:`/cmd/share`. Neither of these affect our design, and they're explored in more detail in :doc:`/using_yosys/synthesis/opt`, so let's skip over them. :yoscrypt:`techmap -map +/cmp2lut.v -D LUT_WIDTH=4` optimizes certain comparison operators by -converting them to LUTs instead. The usage of `techmap` is explored -more in :doc:`/using_yosys/synthesis/techmap_synth`. +converting them to LUTs instead. The usage of `techmap` is explored more in +:doc:`/using_yosys/synthesis/techmap_synth`. Our next command to run is :doc:`/cmd/memory_dff`. @@ -451,9 +446,9 @@ Our next command to run is ``rdata`` output after `memory_dff` -As the title suggests, `memory_dff` has merged the output `$dff` into -the `$memrd` cell and converted it to a `$memrd_v2` (highlighted). This has -also connected the ``CLK`` port to the ``clk`` input as it is now a synchronous +As the title suggests, `memory_dff` has merged the output `$dff` into the +`$memrd` cell and converted it to a `$memrd_v2` (highlighted). This has also +connected the ``CLK`` port to the ``clk`` input as it is now a synchronous memory read with appropriate enable (``EN=1'1``) and reset (``ARST=1'0`` and ``SRST=1'0``) inputs. @@ -466,12 +461,11 @@ memory read with appropriate enable (``EN=1'1``) and reset (``ARST=1'0`` and Part 3 ^^^^^^ -The third part of the `synth_ice40` flow is a series of commands for -mapping to DSPs. By default, the iCE40 flow will not map to the hardware DSP -blocks and will only be performed if called with the ``-dsp`` flag: -:yoscrypt:`synth_ice40 -dsp`. While our example has nothing that could be -mapped to DSPs we can still take a quick look at the commands here and describe -what they do. +The third part of the `synth_ice40` flow is a series of commands for mapping to +DSPs. By default, the iCE40 flow will not map to the hardware DSP blocks and +will only be performed if called with the ``-dsp`` flag: :yoscrypt:`synth_ice40 +-dsp`. While our example has nothing that could be mapped to DSPs we can still +take a quick look at the commands here and describe what they do. .. literalinclude:: /cmd/synth_ice40.rst :language: yoscrypt @@ -483,28 +477,26 @@ what they do. :yoscrypt:`wreduce t:$mul` performs width reduction again, this time targetting only cells of type `$mul`. :yoscrypt:`techmap -map +/mul2dsp.v -map -+/ice40/dsp_map.v ... -D DSP_NAME=$__MUL16X16` uses `techmap` to map -`$mul` cells to ``$__MUL16X16`` which are, in turn, mapped to the iCE40 -``SB_MAC16``. Any multipliers which aren't compatible with conversion to -``$__MUL16X16`` are relabelled to ``$__soft_mul`` before `chtype` -changes them back to `$mul`. ++/ice40/dsp_map.v ... -D DSP_NAME=$__MUL16X16` uses `techmap` to map `$mul` +cells to ``$__MUL16X16`` which are, in turn, mapped to the iCE40 ``SB_MAC16``. +Any multipliers which aren't compatible with conversion to ``$__MUL16X16`` are +relabelled to ``$__soft_mul`` before `chtype` changes them back to `$mul`. During the mul2dsp conversion, some of the intermediate signals are marked with the attribute ``mul2dsp``. By calling :yoscrypt:`select a:mul2dsp` we restrict the following commands to only operate on the cells and wires used for these signals. `setattr` removes the now unnecessary ``mul2dsp`` attribute. -`opt_expr` we've already come across for const folding and simple -expression rewriting, the ``-fine`` option just enables more fine-grain -optimizations. Then we perform width reduction a final time and clear the -selection. +`opt_expr` we've already come across for const folding and simple expression +rewriting, the ``-fine`` option just enables more fine-grain optimizations. +Then we perform width reduction a final time and clear the selection. .. todo:: ``ice40_dsp`` is pmgen -Finally we have `ice40_dsp`: similar to the `memory_dff` -command we saw in the previous section, this merges any surrounding registers -into the ``SB_MAC16`` cell. This includes not just the input/output registers, -but also pipeline registers and even a post-adder where applicable: turning a -multiply + add into a single multiply-accumulate. +Finally we have `ice40_dsp`: similar to the `memory_dff` command we saw in the +previous section, this merges any surrounding registers into the ``SB_MAC16`` +cell. This includes not just the input/output registers, but also pipeline +registers and even a post-adder where applicable: turning a multiply + add into +a single multiply-accumulate. .. seealso:: Advanced usage docs for :doc:`/using_yosys/synthesis/techmap_synth` @@ -522,11 +514,10 @@ That brings us to the fourth and final part for the iCE40 synthesis flow: :caption: ``coarse`` section (part 4) :name: synth_coarse4 -Where before each type of arithmetic operation had its own cell, e.g. `$add`, -we now want to extract these into `$alu` and `$macc` cells which can help -identify opportunities for reusing logic. We do this by running -`alumacc`, which we can see produce the following changes in our -example design: +Where before each type of arithmetic operation had its own cell, e.g. `$add`, we +now want to extract these into `$alu` and `$macc` cells which can help identify +opportunities for reusing logic. We do this by running `alumacc`, which we can +see produce the following changes in our example design: .. literalinclude:: /code_examples/fifo/fifo.out :language: doscon @@ -540,17 +531,17 @@ example design: ``rdata`` output after `alumacc` -Once these cells have been inserted, the call to `opt` can combine -cells which are now identical but may have been missed due to e.g. the -difference between `$add` and `$sub`. +Once these cells have been inserted, the call to `opt` can combine cells which +are now identical but may have been missed due to e.g. the difference between +`$add` and `$sub`. -The other new command in this part is :doc:`/cmd/memory`. `memory` is -another macro command which we examine in more detail in +The other new command in this part is :doc:`/cmd/memory`. `memory` is another +macro command which we examine in more detail in :doc:`/using_yosys/synthesis/memory`. For this document, let us focus just on -the step most relevant to our example: `memory_collect`. Up until this -point, our memory reads and our memory writes have been totally disjoint cells; -operating on the same memory only in the abstract. `memory_collect` -combines all of the reads and writes for a memory block into a single cell. +the step most relevant to our example: `memory_collect`. Up until this point, +our memory reads and our memory writes have been totally disjoint cells; +operating on the same memory only in the abstract. `memory_collect` combines all +of the reads and writes for a memory block into a single cell. .. figure:: /_images/code_examples/fifo/rdata_coarse.* :class: width-helper invert-helper @@ -609,19 +600,19 @@ Mapping to hard memory blocks uses a combination of `memory_libmap` and ``rdata`` output after :ref:`map_ram` -The :ref:`map_ram` converts the generic `$mem_v2` into the iCE40 -``SB_RAM40_4K`` (highlighted). We can also see the memory address has been -remapped, and the data bits have been reordered (or swizzled). There is also -now a `$mux` cell controlling the value of ``rdata``. In :ref:`fifo-v` we -wrote our memory as read-before-write, however the ``SB_RAM40_4K`` has undefined -behaviour when reading from and writing to the same address in the same cycle. -As a result, extra logic is added so that the generated circuit matches the -behaviour of the verilog. :ref:`no_rw_check` describes how we could change our -verilog to match our hardware instead. +The :ref:`map_ram` converts the generic `$mem_v2` into the iCE40 ``SB_RAM40_4K`` +(highlighted). We can also see the memory address has been remapped, and the +data bits have been reordered (or swizzled). There is also now a `$mux` cell +controlling the value of ``rdata``. In :ref:`fifo-v` we wrote our memory as +read-before-write, however the ``SB_RAM40_4K`` has undefined behaviour when +reading from and writing to the same address in the same cycle. As a result, +extra logic is added so that the generated circuit matches the behaviour of the +verilog. :ref:`no_rw_check` describes how we could change our verilog to match +our hardware instead. -If we run `memory_libmap` under the `debug` command we can see -candidates which were identified for mapping, along with the costs of each and -what logic requires emulation. +If we run `memory_libmap` under the `debug` command we can see candidates which +were identified for mapping, along with the costs of each and what logic +requires emulation. .. literalinclude:: /code_examples/fifo/fifo.libmap :language: doscon @@ -667,11 +658,10 @@ into flip flops (the ``logic fallback``) with `memory_map`. Arithmetic ^^^^^^^^^^ -Uses `techmap` to map basic arithmetic logic to hardware. This sees -somewhat of an explosion in cells as multi-bit :cell:ref:`$mux` and `$adffe` are -replaced with single-bit `$_MUX_` and `$_DFFE_PP0P_` cells, while the -:cell:ref:`$alu` is replaced with primitive `$_OR_` and `$_NOT_` gates and a -`$lut` cell. +Uses `techmap` to map basic arithmetic logic to hardware. This sees somewhat of +an explosion in cells as multi-bit `$mux` and `$adffe` are replaced with +single-bit `$_MUX_` and `$_DFFE_PP0P_` cells, while the `$alu` is replaced with +primitive `$_OR_` and `$_NOT_` gates and a `$lut` cell. .. literalinclude:: /cmd/synth_ice40.rst :language: yoscrypt @@ -693,12 +683,12 @@ replaced with single-bit `$_MUX_` and `$_DFFE_PP0P_` cells, while the Flip-flops ^^^^^^^^^^ -Convert FFs to the types supported in hardware with `dfflegalize`, and -then use `techmap` to map them. In our example, this converts the -`$_DFFE_PP0P_` cells to ``SB_DFFER``. +Convert FFs to the types supported in hardware with `dfflegalize`, and then use +`techmap` to map them. In our example, this converts the `$_DFFE_PP0P_` cells +to ``SB_DFFER``. -We also run `simplemap` here to convert any remaining cells which could -not be mapped to hardware into gate-level primitives. This includes optimizing +We also run `simplemap` here to convert any remaining cells which could not be +mapped to hardware into gate-level primitives. This includes optimizing `$_MUX_` cells where one of the inputs is a constant ``1'0``, replacing it instead with an `$_AND_` cell. @@ -722,11 +712,10 @@ instead with an `$_AND_` cell. LUTs ^^^^ -`abc` and `techmap` are used to map LUTs; converting primitive -cell types to use `$lut` and ``SB_CARRY`` cells. Note that the iCE40 flow -uses `abc9` rather than `abc`. For more on what these do, and -what the difference between these two commands are, refer to -:doc:`/using_yosys/synthesis/abc`. +`abc` and `techmap` are used to map LUTs; converting primitive cell types to use +`$lut` and ``SB_CARRY`` cells. Note that the iCE40 flow uses `abc9` rather than +`abc`. For more on what these do, and what the difference between these two +commands are, refer to :doc:`/using_yosys/synthesis/abc`. .. literalinclude:: /cmd/synth_ice40.rst :language: yoscrypt @@ -742,8 +731,8 @@ what the difference between these two commands are, refer to ``rdata`` output after :ref:`map_luts` -Finally we use `techmap` to map the generic `$lut` cells to iCE40 -``SB_LUT4`` cells. +Finally we use `techmap` to map the generic `$lut` cells to iCE40 ``SB_LUT4`` +cells. .. literalinclude:: /cmd/synth_ice40.rst :language: yoscrypt @@ -801,28 +790,27 @@ The new commands here are: - :doc:`/cmd/stat`, and - :doc:`/cmd/blackbox`. -The output from `stat` is useful for checking resource utilization; -providing a list of cells used in the design and the number of each, as well as -the number of other resources used such as wires and processes. For this -design, the final call to `stat` should look something like the -following: +The output from `stat` is useful for checking resource utilization; providing a +list of cells used in the design and the number of each, as well as the number +of other resources used such as wires and processes. For this design, the final +call to `stat` should look something like the following: .. literalinclude:: /code_examples/fifo/fifo.stat :language: doscon :start-at: yosys> stat -top fifo -Note that the :yoscrypt:`-top fifo` here is optional. `stat` will -automatically use the module with the ``top`` attribute set, which ``fifo`` was -when we called `hierarchy`. If no module is marked ``top``, then stats -will be shown for each module selected. +Note that the :yoscrypt:`-top fifo` here is optional. `stat` will automatically +use the module with the ``top`` attribute set, which ``fifo`` was when we called +`hierarchy`. If no module is marked ``top``, then stats will be shown for each +module selected. -The `stat` output is also useful as a kind of sanity-check: Since we -have already run `proc`, we wouldn't expect there to be any processes. -We also expect ``data`` to use hard memory; if instead of an ``SB_RAM40_4K`` saw -a high number of flip-flops being used we might suspect something was wrong. +The `stat` output is also useful as a kind of sanity-check: Since we have +already run `proc`, we wouldn't expect there to be any processes. We also expect +``data`` to use hard memory; if instead of an ``SB_RAM40_4K`` saw a high number +of flip-flops being used we might suspect something was wrong. -If we instead called `stat` immediately after :yoscrypt:`read_verilog -fifo.v` we would see something very different: +If we instead called `stat` immediately after :yoscrypt:`read_verilog fifo.v` we +would see something very different: .. literalinclude:: /code_examples/fifo/fifo.stat :language: doscon @@ -845,10 +833,10 @@ The iCE40 synthesis flow has the following output modes available: As an example, if we called :yoscrypt:`synth_ice40 -top fifo -json fifo.json`, our synthesized ``fifo`` design will be output as :file:`fifo.json`. We can -then read the design back into Yosys with `read_json`, but make sure -you use :yoscrypt:`design -reset` or open a new interactive terminal first. The -JSON output we get can also be loaded into `nextpnr`_ to do place and route; but -that is beyond the scope of this documentation. +then read the design back into Yosys with `read_json`, but make sure you use +:yoscrypt:`design -reset` or open a new interactive terminal first. The JSON +output we get can also be loaded into `nextpnr`_ to do place and route; but that +is beyond the scope of this documentation. .. _nextpnr: https://github.com/YosysHQ/nextpnr diff --git a/docs/source/getting_started/installation.rst b/docs/source/getting_started/installation.rst index 8ed7cebb87c..5fed508ed25 100644 --- a/docs/source/getting_started/installation.rst +++ b/docs/source/getting_started/installation.rst @@ -184,9 +184,8 @@ directories: ``passes/`` This directory contains a subdirectory for each pass or group of passes. For - example as of this writing the directory :file:`passes/hierarchy/` contains the - code for three passes: `hierarchy`, `submod`, and - `uniquify`. + example as of this writing the directory :file:`passes/hierarchy/` contains + the code for three passes: `hierarchy`, `submod`, and `uniquify`. ``techlibs/`` This directory contains simulation models and standard implementations for diff --git a/docs/source/getting_started/scripting_intro.rst b/docs/source/getting_started/scripting_intro.rst index ef728e1cf12..01954c6615c 100644 --- a/docs/source/getting_started/scripting_intro.rst +++ b/docs/source/getting_started/scripting_intro.rst @@ -61,24 +61,23 @@ already, let's take a look at some of those script files now. :caption: A section of :file:`fifo.ys`, generating the images used for :ref:`addr_gen_example` :name: fifo-ys -The first command there, :yoscrypt:`echo on`, uses `echo` to enable -command echoes on. This is how we generated the code listing for +The first command there, :yoscrypt:`echo on`, uses `echo` to enable command +echoes on. This is how we generated the code listing for :ref:`hierarchy_output`. Turning command echoes on prints the ``yosys> hierarchy -top addr_gen`` line, making the output look the same as if it were an interactive terminal. :yoscrypt:`hierarchy -top addr_gen` is of course the command we were demonstrating, including the output text and an image of the design schematic after running it. -We briefly touched on `select` when it came up in -`synth_ice40`, but let's look at it more now. +We briefly touched on `select` when it came up in `synth_ice40`, but let's look +at it more now. .. _select_intro: Selections intro ^^^^^^^^^^^^^^^^ -The `select` command is used to modify and view the list of selected -objects: +The `select` command is used to modify and view the list of selected objects: .. literalinclude:: /code_examples/fifo/fifo.out :language: doscon @@ -118,8 +117,8 @@ statement. Many commands also support an optional ``[selection]`` argument which can be used to override the currently selected objects. We could, for example, call -:yoscrypt:`clean addr_gen` to have `clean` operate on *just* the -``addr_gen`` module. +:yoscrypt:`clean addr_gen` to have `clean` operate on *just* the ``addr_gen`` +module. Detailed documentation of the select framework can be found under :doc:`/using_yosys/more_scripting/selections` or in the command reference at @@ -130,11 +129,11 @@ Detailed documentation of the select framework can be found under Displaying schematics ^^^^^^^^^^^^^^^^^^^^^ -While the `select` command is very useful, sometimes nothing beats -being able to see a design for yourself. This is where `show` comes -in. Note that this document is just an introduction to the `show` -command, only covering the basics. For more information, including a guide on -what the different symbols represent, see :ref:`interactive_show` and the +While the `select` command is very useful, sometimes nothing beats being able to +see a design for yourself. This is where `show` comes in. Note that this +document is just an introduction to the `show` command, only covering the +basics. For more information, including a guide on what the different symbols +represent, see :ref:`interactive_show` and the :doc:`/using_yosys/more_scripting/interactive_investigation` page. .. figure:: /_images/code_examples/fifo/addr_gen_show.* @@ -145,8 +144,8 @@ what the different symbols represent, see :ref:`interactive_show` and the .. note:: - The `show` command requires a working installation of `GraphViz`_ - and `xdot`_ for displaying the actual circuit diagrams. + The `show` command requires a working installation of `GraphViz`_ and `xdot`_ + for displaying the actual circuit diagrams. .. _GraphViz: http://www.graphviz.org/ .. _xdot: https://github.com/jrfonseca/xdot.py @@ -160,8 +159,8 @@ we see the following: :start-at: -prefix addr_gen_show :end-before: yosys> show -Calling `show` with :yoscrypt:`-format dot` tells it we want to output -a :file:`.dot` file rather than opening it for display. The :yoscrypt:`-prefix +Calling `show` with :yoscrypt:`-format dot` tells it we want to output a +:file:`.dot` file rather than opening it for display. The :yoscrypt:`-prefix addr_gen_show` option indicates we want the file to be called :file:`addr_gen_show.{*}`. Remember, we do this in :file:`fifo.ys` because we need to store the image for displaying in the documentation you're reading. But @@ -207,21 +206,20 @@ the two ``PROC`` blocks. To achieve this highlight, we make use of the Calling :yoscrypt:`show -color maroon3 @new_cells -color cornflowerblue p:* -notitle` -As described in the the `help` output for `show` (or by -clicking on the `show` link), colors are specified as :yoscrypt:`-color - `. Color names for the ```` portion can be found on the -`GraphViz color docs`_. Unlike the final `show` parameter which can -have be any selection string, the ```` part must be a single selection -expression or named selection. That means while we can use ``@new_cells``, we -couldn't use ``t:$eq t:$add``. In general, if a command lists ``[selection]`` -as its final parameter it can be any selection string. Any selections that are -not the final parameter, such as those used in options, must be a single -expression instead. +As described in the the `help` output for `show` (or by clicking on the `show` +link), colors are specified as :yoscrypt:`-color `. Color names +for the ```` portion can be found on the `GraphViz color docs`_. Unlike +the final `show` parameter which can have be any selection string, the +```` part must be a single selection expression or named selection. +That means while we can use ``@new_cells``, we couldn't use ``t:$eq t:$add``. +In general, if a command lists ``[selection]`` as its final parameter it can be +any selection string. Any selections that are not the final parameter, such as +those used in options, must be a single expression instead. .. _GraphViz color docs: https://graphviz.org/doc/info/colors -For all of the options available to `show`, check the command reference -at :doc:`/cmd/show`. +For all of the options available to `show`, check the command reference at +:doc:`/cmd/show`. .. seealso:: :ref:`interactive_show` on the :doc:`/using_yosys/more_scripting/interactive_investigation` page. diff --git a/docs/source/introduction.rst b/docs/source/introduction.rst index 1d9cd008044..7261d8edb74 100644 --- a/docs/source/introduction.rst +++ b/docs/source/introduction.rst @@ -161,9 +161,9 @@ Benefits of open source HDL synthesis - Cost (also applies to ``free as in free beer`` solutions): - Today the cost for a mask set in 180nm technology is far less than - the cost for the design tools needed to design the mask layouts. Open Source - ASIC flows are an important enabler for ASIC-level Open Source Hardware. + Today the cost for a mask set in 180nm technology is far less than the cost + for the design tools needed to design the mask layouts. Open Source ASIC flows + are an important enabler for ASIC-level Open Source Hardware. - Availability and Reproducibility: @@ -171,21 +171,23 @@ Benefits of open source HDL synthesis else can also use. Even if most universities have access to all major commercial tools, you usually do not have easy access to the version that was used in a research project a couple of years ago. With Open Source tools you - can even release the source code of the tool you have used alongside your data. + can even release the source code of the tool you have used alongside your + data. - Framework: - Yosys is not only a tool. It is a framework that can be used as basis for other - developments, so researchers and hackers alike do not need to re-invent the - basic functionality. Extensibility was one of Yosys' design goals. + Yosys is not only a tool. It is a framework that can be used as basis for + other developments, so researchers and hackers alike do not need to re-invent + the basic functionality. Extensibility was one of Yosys' design goals. - All-in-one: - Because of the framework characteristics of Yosys, an increasing number of features - become available in one tool. Yosys not only can be used for circuit synthesis but - also for formal equivalence checking, SAT solving, and for circuit analysis, to - name just a few other application domains. With proprietary software one needs to - learn a new tool for each of these applications. + Because of the framework characteristics of Yosys, an increasing number of + features become available in one tool. Yosys not only can be used for circuit + synthesis but also for formal equivalence checking, SAT solving, and for + circuit analysis, to name just a few other application domains. With + proprietary software one needs to learn a new tool for each of these + applications. - Educational Tool: diff --git a/docs/source/using_yosys/more_scripting/interactive_investigation.rst b/docs/source/using_yosys/more_scripting/interactive_investigation.rst index f2e3d5219d8..f078ed59e5b 100644 --- a/docs/source/using_yosys/more_scripting/interactive_investigation.rst +++ b/docs/source/using_yosys/more_scripting/interactive_investigation.rst @@ -13,9 +13,9 @@ A look at the show command .. TODO:: merge into :doc:`/getting_started/scripting_intro` show section -This section explores the `show` command and explains the symbols used -in the circuit diagrams generated by it. The code used is included in the Yosys -code base under |code_examples/show|_. +This section explores the `show` command and explains the symbols used in the +circuit diagrams generated by it. The code used is included in the Yosys code +base under |code_examples/show|_. .. |code_examples/show| replace:: :file:`docs/source/code_examples/show` .. _code_examples/show: https://github.com/YosysHQ/yosys/tree/main/docs/source/code_examples/show @@ -32,11 +32,10 @@ will use to demonstrate the usage of `show` in a simple setting. :name: example_v The Yosys synthesis script we will be running is included as -:numref:`example_ys`. Note that `show` is called with the ``-pause`` -option, that halts execution of the Yosys script until the user presses the -Enter key. Using :yoscrypt:`show -pause` also allows the user to enter an -interactive shell to further investigate the circuit before continuing -synthesis. +:numref:`example_ys`. Note that `show` is called with the ``-pause`` option, +that halts execution of the Yosys script until the user presses the Enter key. +Using :yoscrypt:`show -pause` also allows the user to enter an interactive shell +to further investigate the circuit before continuing synthesis. .. literalinclude:: /code_examples/show/example_show.ys :language: yoscrypt @@ -95,19 +94,19 @@ multiplexer and a d-type flip-flop, which brings us to the second diagram: The Rhombus shape to the right is a dangling wire. (Wire nodes are only shown if they are dangling or have "public" names, for example names assigned from the Verilog input.) Also note that the design now contains two instances of a -``BUF``-node. These are artefacts left behind by the `proc` command. It -is quite usual to see such artefacts after calling commands that perform changes -in the design, as most commands only care about doing the transformation in the -least complicated way, not about cleaning up after them. The next call to -`clean` (or `opt`, which includes `clean` as one of -its operations) will clean up these artefacts. This operation is so common in -Yosys scripts that it can simply be abbreviated with the ``;;`` token, which -doubles as separator for commands. Unless one wants to specifically analyze this -artefacts left behind some operations, it is therefore recommended to always -call `clean` before calling `show`. - -In this script we directly call `opt` as the next step, which finally -leads us to the third diagram: +``BUF``-node. These are artefacts left behind by the `proc` command. It is quite +usual to see such artefacts after calling commands that perform changes in the +design, as most commands only care about doing the transformation in the least +complicated way, not about cleaning up after them. The next call to `clean` (or +`opt`, which includes `clean` as one of its operations) will clean up these +artefacts. This operation is so common in Yosys scripts that it can simply be +abbreviated with the ``;;`` token, which doubles as separator for commands. +Unless one wants to specifically analyze this artefacts left behind some +operations, it is therefore recommended to always call `clean` before calling +`show`. + +In this script we directly call `opt` as the next step, which finally leads us +to the third diagram: .. figure:: /_images/code_examples/show/example_third.* :class: width-helper invert-helper @@ -115,9 +114,9 @@ leads us to the third diagram: Output of the third `show` command in :ref:`example_ys` -Here we see that the `opt` command not only has removed the artifacts -left behind by `proc`, but also determined correctly that it can remove -the first `$mux` cell without changing the behavior of the circuit. +Here we see that the `opt` command not only has removed the artifacts left +behind by `proc`, but also determined correctly that it can remove the first +`$mux` cell without changing the behavior of the circuit. Break-out boxes for signal vectors ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -188,8 +187,8 @@ individual bits, resulting in an unnecessary complex diagram. :class: width-helper invert-helper :name: second_pitfall - Effects of `splitnets` command and of providing a cell library on - design in :numref:`first_pitfall` + Effects of `splitnets` command and of providing a cell library on design in + :numref:`first_pitfall` .. literalinclude:: /code_examples/show/cmos.ys :language: yoscrypt @@ -201,8 +200,8 @@ individual bits, resulting in an unnecessary complex diagram. For :numref:`second_pitfall`, Yosys has been given a description of the cell library as Verilog file containing blackbox modules. There are two ways to load cell descriptions into Yosys: First the Verilog file for the cell library can be -passed directly to the `show` command using the ``-lib `` -option. Secondly it is possible to load cell libraries into the design with the +passed directly to the `show` command using the ``-lib `` option. +Secondly it is possible to load cell libraries into the design with the :yoscrypt:`read_verilog -lib ` command. The second method has the great advantage that the library only needs to be loaded once and can then be used in all subsequent calls to the `show` command. @@ -216,19 +215,19 @@ module ports. Per default the command only operates on interior signals. Miscellaneous notes ^^^^^^^^^^^^^^^^^^^ -Per default the `show` command outputs a temporary dot file and -launches ``xdot`` to display it. The options ``-format``, ``-viewer`` and -``-prefix`` can be used to change format, viewer and filename prefix. Note that -the ``pdf`` and ``ps`` format are the only formats that support plotting -multiple modules in one run. The ``dot`` format can be used to output multiple -modules, however ``xdot`` will raise an error when trying to read them. +Per default the `show` command outputs a temporary dot file and launches +``xdot`` to display it. The options ``-format``, ``-viewer`` and ``-prefix`` can +be used to change format, viewer and filename prefix. Note that the ``pdf`` and +``ps`` format are the only formats that support plotting multiple modules in one +run. The ``dot`` format can be used to output multiple modules, however +``xdot`` will raise an error when trying to read them. In densely connected circuits it is sometimes hard to keep track of the -individual signal wires. For these cases it can be useful to call -`show` with the ``-colors `` argument, which randomly assigns -colors to the nets. The integer (> 0) is used as seed value for the random color -assignments. Sometimes it is necessary it try some values to find an assignment -of colors that looks good. +individual signal wires. For these cases it can be useful to call `show` with +the ``-colors `` argument, which randomly assigns colors to the nets. +The integer (> 0) is used as seed value for the random color assignments. +Sometimes it is necessary it try some values to find an assignment of colors +that looks good. The command :yoscrypt:`help show` prints a complete listing of all options supported by the `show` command. @@ -244,10 +243,10 @@ relevant portions of the circuit. In addition to *what* to display one also needs to carefully decide *when* to display it, with respect to the synthesis flow. In general it is a good idea to troubleshoot a circuit in the earliest state in which a problem can be -reproduced. So if, for example, the internal state before calling the -`techmap` command already fails to verify, it is better to troubleshoot -the coarse-grain version of the circuit before `techmap` than the -gate-level circuit after `techmap`. +reproduced. So if, for example, the internal state before calling the `techmap` +command already fails to verify, it is better to troubleshoot the coarse-grain +version of the circuit before `techmap` than the gate-level circuit after +`techmap`. .. Note:: @@ -260,18 +259,17 @@ Interactive navigation ^^^^^^^^^^^^^^^^^^^^^^ Once the right state within the synthesis flow for debugging the circuit has -been identified, it is recommended to simply add the `shell` command to -the matching place in the synthesis script. This command will stop the synthesis -at the specified moment and go to shell mode, where the user can interactively +been identified, it is recommended to simply add the `shell` command to the +matching place in the synthesis script. This command will stop the synthesis at +the specified moment and go to shell mode, where the user can interactively enter commands. For most cases, the shell will start with the whole design selected (i.e. when -the synthesis script does not already narrow the selection). The command -`ls` can now be used to create a list of all modules. The command -`cd` can be used to switch to one of the modules (type ``cd ..`` to -switch back). Now the `ls` command lists the objects within that -module. This is demonstrated below using :file:`example.v` from `A simple -circuit`_: +the synthesis script does not already narrow the selection). The command `ls` +can now be used to create a list of all modules. The command `cd` can be used to +switch to one of the modules (type ``cd ..`` to switch back). Now the `ls` +command lists the objects within that module. This is demonstrated below using +:file:`example.v` from `A simple circuit`_: .. literalinclude:: /code_examples/show/example.out :language: doscon @@ -280,11 +278,10 @@ circuit`_: :caption: Output of `ls` and `cd` after running :file:`yosys example.v` :name: lscd -When a module is selected using the `cd` command, all commands (with a -few exceptions, such as the ``read_`` and ``write_`` commands) operate only on -the selected module. This can also be useful for synthesis scripts where -different synthesis strategies should be applied to different modules in the -design. +When a module is selected using the `cd` command, all commands (with a few +exceptions, such as the ``read_`` and ``write_`` commands) operate only on the +selected module. This can also be useful for synthesis scripts where different +synthesis strategies should be applied to different modules in the design. We can see that the cell names from :numref:`example_out` are just abbreviations of the actual cell names, namely the part after the last dollar-sign. Most @@ -292,15 +289,14 @@ auto-generated names (the ones starting with a dollar sign) are rather long and contains some additional information on the origin of the named object. But in most cases those names can simply be abbreviated using the last part. -Usually all interactive work is done with one module selected using the -`cd` command. But it is also possible to work from the design-context -(``cd ..``). In this case all object names must be prefixed with -``/``. For example ``a*/b*`` would refer to all objects whose names -start with ``b`` from all modules whose names start with ``a``. +Usually all interactive work is done with one module selected using the `cd` +command. But it is also possible to work from the design-context (``cd ..``). In +this case all object names must be prefixed with ``/``. For example +``a*/b*`` would refer to all objects whose names start with ``b`` from all +modules whose names start with ``a``. -The `dump` command can be used to print all information about an -object. For example, calling :yoscrypt:`dump $2` after the :yoscrypt:`cd -example` above: +The `dump` command can be used to print all information about an object. For +example, calling :yoscrypt:`dump $2` after the :yoscrypt:`cd example` above: .. literalinclude:: /code_examples/show/example.out :language: RTLIL @@ -323,11 +319,10 @@ tools). - The selection mechanism, especially patterns such as ``%ci`` and ``%co``, can be used to figure out how parts of the design are connected. -- Commands such as `submod`, `expose`, and `splice` - can be used to transform the design into an equivalent design that is easier - to analyse. -- Commands such as `eval` and `sat` can be used to investigate - the behavior of the circuit. +- Commands such as `submod`, `expose`, and `splice` can be used to transform the + design into an equivalent design that is easier to analyse. +- Commands such as `eval` and `sat` can be used to investigate the behavior of + the circuit. - :doc:`/cmd/show`. - :doc:`/cmd/dump`. - :doc:`/cmd/add` and :doc:`/cmd/delete` can be used to modify and reorganize a @@ -342,9 +337,9 @@ The code used is included in the Yosys code base under Changing design hierarchy ^^^^^^^^^^^^^^^^^^^^^^^^^ -Commands such as `flatten` and `submod` can be used to change -the design hierarchy, i.e. flatten the hierarchy or moving parts of a module to -a submodule. This has applications in synthesis scripts as well as in reverse +Commands such as `flatten` and `submod` can be used to change the design +hierarchy, i.e. flatten the hierarchy or moving parts of a module to a +submodule. This has applications in synthesis scripts as well as in reverse engineering and analysis. An example using `submod` is shown below for reorganizing a module in Yosys and checking the resulting circuit. @@ -388,10 +383,10 @@ Analyzing the resulting circuit with :doc:`/cmd/eval`: Behavioral changes ^^^^^^^^^^^^^^^^^^ -Commands such as `techmap` can be used to make behavioral changes to -the design, for example changing asynchronous resets to synchronous resets. This -has applications in design space exploration (evaluation of various -architectures for one circuit). +Commands such as `techmap` can be used to make behavioral changes to the design, +for example changing asynchronous resets to synchronous resets. This has +applications in design space exploration (evaluation of various architectures +for one circuit). The following techmap map file replaces all positive-edge async reset flip-flops with positive-edge sync reset flip-flops. The code is taken from the example @@ -448,8 +443,8 @@ Recall the ``memdemo`` design from :ref:`advanced_logic_cones`: Because this produces a rather large circuit, it can be useful to split it into smaller parts for viewing and working with. :numref:`submod` does exactly that, -utilising the `submod` command to split the circuit into three -sections: ``outstage``, ``selstage``, and ``scramble``. +utilising the `submod` command to split the circuit into three sections: +``outstage``, ``selstage``, and ``scramble``. .. literalinclude:: /code_examples/selections/submod.ys :language: yoscrypt @@ -481,9 +476,9 @@ below. Evaluation of combinatorial circuits ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The `eval` command can be used to evaluate combinatorial circuits. As -an example, we will use the ``selstage`` subnet of ``memdemo`` which we found -above and is shown in :numref:`selstage`. +The `eval` command can be used to evaluate combinatorial circuits. As an +example, we will use the ``selstage`` subnet of ``memdemo`` which we found above +and is shown in :numref:`selstage`. .. todo:: replace inline code @@ -526,21 +521,21 @@ The ``-table`` option can be used to create a truth table. For example: Assumed undef (x) value for the following signals: \s2 -Note that the `eval` command (as well as the `sat` command -discussed in the next sections) does only operate on flattened modules. It can -not analyze signals that are passed through design hierarchy levels. So the -`flatten` command must be used on modules that instantiate other -modules before these commands can be applied. +Note that the `eval` command (as well as the `sat` command discussed in the next +sections) does only operate on flattened modules. It can not analyze signals +that are passed through design hierarchy levels. So the `flatten` command must +be used on modules that instantiate other modules before these commands can be +applied. Solving combinatorial SAT problems ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Often the opposite of the `eval` command is needed, i.e. the circuits -output is given and we want to find the matching input signals. For small -circuits with only a few input bits this can be accomplished by trying all -possible input combinations, as it is done by the ``eval -table`` command. For -larger circuits however, Yosys provides the `sat` command that uses a -`SAT`_ solver, `MiniSAT`_, to solve this kind of problems. +Often the opposite of the `eval` command is needed, i.e. the circuits output is +given and we want to find the matching input signals. For small circuits with +only a few input bits this can be accomplished by trying all possible input +combinations, as it is done by the ``eval -table`` command. For larger circuits +however, Yosys provides the `sat` command that uses a `SAT`_ solver, `MiniSAT`_, +to solve this kind of problems. .. _SAT: http://en.wikipedia.org/wiki/Circuit_satisfiability @@ -551,9 +546,9 @@ larger circuits however, Yosys provides the `sat` command that uses a While it is possible to perform model checking directly in Yosys, it is highly recommended to use SBY or EQY for formal hardware verification. -The `sat` command works very similar to the `eval` command. -The main difference is that it is now also possible to set output values and -find the corresponding input values. For Example: +The `sat` command works very similar to the `eval` command. The main difference +is that it is now also possible to set output values and find the corresponding +input values. For Example: .. todo:: replace inline code @@ -580,8 +575,8 @@ find the corresponding input values. For Example: \s1 0 0 00 \s2 0 0 00 -Note that the `sat` command supports signal names in both arguments to -the ``-set`` option. In the above example we used ``-set s1 s2`` to constraint +Note that the `sat` command supports signal names in both arguments to the +``-set`` option. In the above example we used ``-set s1 s2`` to constraint ``s1`` and ``s2`` to be equal. When more complex constraints are needed, a wrapper circuit must be constructed that checks the constraints and signals if the constraint was met using an extra output port, which then can be forced to a @@ -642,8 +637,8 @@ of course be to perform the test in 32 bits, for example by replacing ``p != a*b`` in the miter with ``p != {16'd0,a}b``, or by using a temporary variable for the 32 bit product ``a*b``. But as 31 fits well into 8 bits (and as the purpose of this document is to show off Yosys features) we can also simply force -the upper 8 bits of ``a`` and ``b`` to zero for the `sat` call, as is -done below. +the upper 8 bits of ``a`` and ``b`` to zero for the `sat` call, as is done +below. .. todo:: replace inline code @@ -705,18 +700,18 @@ command: sat -seq 6 -show y -show d -set-init-undef \ -max_undef -set-at 4 y 1 -set-at 5 y 2 -set-at 6 y 3 -The ``-seq 6`` option instructs the `sat` command to solve a sequential -problem in 6 time steps. (Experiments with lower number of steps have show that -at least 3 cycles are necessary to bring the circuit in a state from which the -sequence 1, 2, 3 can be produced.) +The ``-seq 6`` option instructs the `sat` command to solve a sequential problem +in 6 time steps. (Experiments with lower number of steps have show that at least +3 cycles are necessary to bring the circuit in a state from which the sequence +1, 2, 3 can be produced.) -The ``-set-init-undef`` option tells the `sat` command to initialize -all registers to the undef (``x``) state. The way the ``x`` state is treated in +The ``-set-init-undef`` option tells the `sat` command to initialize all +registers to the undef (``x``) state. The way the ``x`` state is treated in Verilog will ensure that the solution will work for any initial state. -The ``-max_undef`` option instructs the `sat` command to find a -solution with a maximum number of undefs. This way we can see clearly which -inputs bits are relevant to the solution. +The ``-max_undef`` option instructs the `sat` command to find a solution with a +maximum number of undefs. This way we can see clearly which inputs bits are +relevant to the solution. Finally the three ``-set-at`` options add constraints for the ``y`` signal to play the 1, 2, 3 sequence, starting with time step 4. @@ -807,7 +802,7 @@ is the only way of setting the ``s1`` and ``s2`` registers to a known value. The input values for the other steps are a bit harder to work out manually, but the SAT solver finds the correct solution in an instant. -There is much more to write about the `sat` command. For example, there -is a set of options that can be used to performs sequential proofs using -temporal induction :cite:p:`een2003temporal`. The command ``help sat`` can be -used to print a list of all options with short descriptions of their functions. +There is much more to write about the `sat` command. For example, there is a set +of options that can be used to performs sequential proofs using temporal +induction :cite:p:`een2003temporal`. The command ``help sat`` can be used to +print a list of all options with short descriptions of their functions. diff --git a/docs/source/using_yosys/more_scripting/model_checking.rst b/docs/source/using_yosys/more_scripting/model_checking.rst index 88eeb9bcd5e..799c99b6f16 100644 --- a/docs/source/using_yosys/more_scripting/model_checking.rst +++ b/docs/source/using_yosys/more_scripting/model_checking.rst @@ -17,8 +17,7 @@ passes in Yosys. Other applications include checking if a module conforms to interface standards. -The `sat` command in Yosys can be used to perform Symbolic Model -Checking. +The `sat` command in Yosys can be used to perform Symbolic Model Checking. Checking techmap ~~~~~~~~~~~~~~~~ diff --git a/docs/source/using_yosys/more_scripting/selections.rst b/docs/source/using_yosys/more_scripting/selections.rst index 1f0efb1f321..e82f2349766 100644 --- a/docs/source/using_yosys/more_scripting/selections.rst +++ b/docs/source/using_yosys/more_scripting/selections.rst @@ -9,31 +9,31 @@ The selection framework .. todo:: reduce overlap with :doc:`/getting_started/scripting_intro` select section -The `select` command can be used to create a selection for subsequent -commands. For example: +The `select` command can be used to create a selection for subsequent commands. +For example: .. code:: yoscrypt select foobar # select the module foobar delete # delete selected objects -Normally the `select` command overwrites a previous selection. The -commands :yoscrypt:`select -add` and :yoscrypt:`select -del` can be used to add -or remove objects from the current selection. +Normally the `select` command overwrites a previous selection. The commands +:yoscrypt:`select -add` and :yoscrypt:`select -del` can be used to add or remove +objects from the current selection. The command :yoscrypt:`select -clear` can be used to reset the selection to the default, which is a complete selection of everything in the current module. This selection framework can also be used directly in many other commands. Whenever a command has ``[selection]`` as last argument in its usage help, this -means that it will use the engine behind the `select` command to -evaluate additional arguments and use the resulting selection instead of the -selection created by the last `select` command. +means that it will use the engine behind the `select` command to evaluate +additional arguments and use the resulting selection instead of the selection +created by the last `select` command. For example, the command `delete` will delete everything in the current selection; while :yoscrypt:`delete foobar` will only delete the module foobar. -If no `select` command has been made, then the "current selection" will -be the whole design. +If no `select` command has been made, then the "current selection" will be the +whole design. .. note:: Many of the examples on this page make use of the `show` command to visually demonstrate the effect of selections. For a more @@ -59,8 +59,8 @@ Module and design context ^^^^^^^^^^^^^^^^^^^^^^^^^ Commands can be executed in *module/* or *design/* context. Until now, all -commands have been executed in design context. The `cd` command can be -used to switch to module context. +commands have been executed in design context. The `cd` command can be used to +switch to module context. In module context, all commands only effect the active module. Objects in the module are selected without the ``/`` prefix. For example: @@ -91,7 +91,7 @@ Special patterns can be used to select by object property or type. For example: a:foobar=42` - select all modules with the attribute ``blabla`` set: :yoscrypt:`select A:blabla` -- select all $add cells from the module foo: :yoscrypt:`select foo/t:$add` +- select all `$add` cells from the module foo: :yoscrypt:`select foo/t:$add` A complete list of pattern expressions can be found in :doc:`/cmd/select`. @@ -101,12 +101,12 @@ Operations on selections Combining selections ^^^^^^^^^^^^^^^^^^^^ -The `select` command is actually much more powerful than it might seem -at first glance. When it is called with multiple arguments, each argument is -evaluated and pushed separately on a stack. After all arguments have been -processed it simply creates the union of all elements on the stack. So -:yoscrypt:`select t:$add a:foo` will select all `$add` cells and all objects -with the ``foo`` attribute set: +The `select` command is actually much more powerful than it might seem at first +glance. When it is called with multiple arguments, each argument is evaluated +and pushed separately on a stack. After all arguments have been processed it +simply creates the union of all elements on the stack. So :yoscrypt:`select +t:$add a:foo` will select all `$add` cells and all objects with the ``foo`` +attribute set: .. literalinclude:: /code_examples/selections/foobaraddsub.v :caption: Test module for operations on selections @@ -220,11 +220,11 @@ The following sequence of diagrams demonstrates this step-wise expansion: Output of :yoscrypt:`show prod %ci %ci %ci` on :numref:`sumprod` Notice the subtle difference between :yoscrypt:`show prod %ci` and -:yoscrypt:`show prod %ci %ci`. Both images show the `$mul` cell driven by -some inputs ``$3_Y`` and ``c``. However it is not until the second image, -having called ``%ci`` the second time, that `show` is able to -distinguish between ``$3_Y`` being a wire and ``c`` being an input. We can see -this better with the `dump` command instead: +:yoscrypt:`show prod %ci %ci`. Both images show the `$mul` cell driven by some +inputs ``$3_Y`` and ``c``. However it is not until the second image, having +called ``%ci`` the second time, that `show` is able to distinguish between +``$3_Y`` being a wire and ``c`` being an input. We can see this better with the +`dump` command instead: .. literalinclude:: /code_examples/selections/sumprod.out :language: RTLIL @@ -241,8 +241,8 @@ be a bit dull. So there is a shortcut for that: the number of iterations can be appended to the action. So for example the action ``%ci3`` is identical to performing the ``%ci`` action three times. -The action ``%ci*`` performs the ``%ci`` action over and over again until it -has no effect anymore. +The action ``%ci*`` performs the ``%ci`` action over and over again until it has +no effect anymore. .. _advanced_logic_cones: @@ -264,8 +264,8 @@ source repository. :name: memdemo_src :language: verilog -The script :file:`memdemo.ys` is used to generate the images included here. Let's -look at the first section: +The script :file:`memdemo.ys` is used to generate the images included here. +Let's look at the first section: .. literalinclude:: /code_examples/selections/memdemo.ys :caption: Synthesizing :ref:`memdemo_src` @@ -276,8 +276,8 @@ look at the first section: This loads :numref:`memdemo_src` and synthesizes the included module. Note that this code can be copied and run directly in a Yosys command line session, provided :file:`memdemo.v` is in the same directory. We can now change to the -``memdemo`` module with ``cd memdemo``, and call `show` to see the -diagram in :numref:`memdemo_00`. +``memdemo`` module with ``cd memdemo``, and call `show` to see the diagram in +:numref:`memdemo_00`. .. figure:: /_images/code_examples/selections/memdemo_00.* :class: width-helper invert-helper @@ -371,8 +371,8 @@ selection instead of overwriting it. select -del reg_42 # but not this one select -add state %ci # and add more stuff -Within a select expression the token ``%`` can be used to push the previous selection -on the stack. +Within a select expression the token ``%`` can be used to push the previous +selection on the stack. .. code:: yoscrypt @@ -387,16 +387,16 @@ Storing and recalling selections The current selection can be stored in memory with the command ``select -set ``. It can later be recalled using ``select @``. In fact, the ``@`` expression pushes the stored selection on the stack maintained by -the `select` command. So for example :yoscrypt:`select @foo @bar %i` -will select the intersection between the stored selections ``foo`` and ``bar``. +the `select` command. So for example :yoscrypt:`select @foo @bar %i` will select +the intersection between the stored selections ``foo`` and ``bar``. In larger investigation efforts it is highly recommended to maintain a script that sets up relevant selections, so they can easily be recalled, for example when Yosys needs to be re-run after a design or source code change. -The `history` command can be used to list all recent interactive -commands. This feature can be useful for creating such a script from the -commands used in an interactive session. +The `history` command can be used to list all recent interactive commands. This +feature can be useful for creating such a script from the commands used in an +interactive session. Remember that select expressions can also be used directly as arguments to most commands. Some commands also accept a single select argument to some options. In diff --git a/docs/source/using_yosys/synthesis/abc.rst b/docs/source/using_yosys/synthesis/abc.rst index 0c2e4868adf..91de775e687 100644 --- a/docs/source/using_yosys/synthesis/abc.rst +++ b/docs/source/using_yosys/synthesis/abc.rst @@ -10,13 +10,12 @@ fine-grained optimisation and LUT mapping. Yosys has two different commands, which both use this logic toolbox, but use it in different ways. -The `abc` pass can be used for both ASIC (e.g. :yoscrypt:`abc --liberty`) and FPGA (:yoscrypt:`abc -lut`) mapping, but this page will focus on -FPGA mapping. +The `abc` pass can be used for both ASIC (e.g. :yoscrypt:`abc -liberty`) and +FPGA (:yoscrypt:`abc -lut`) mapping, but this page will focus on FPGA mapping. -The `abc9` pass generally provides superior mapping quality due to -being aware of combination boxes and DFF and LUT timings, giving it a more -global view of the mapping problem. +The `abc9` pass generally provides superior mapping quality due to being aware +of combination boxes and DFF and LUT timings, giving it a more global view of +the mapping problem. .. _ABC: https://github.com/berkeley-abc/abc diff --git a/docs/source/using_yosys/synthesis/cell_libs.rst b/docs/source/using_yosys/synthesis/cell_libs.rst index c8dbba8381a..50811fd1e7e 100644 --- a/docs/source/using_yosys/synthesis/cell_libs.rst +++ b/docs/source/using_yosys/synthesis/cell_libs.rst @@ -98,8 +98,8 @@ our internal cell library will be mapped to: :name: mycells-lib :caption: :file:`mycells.lib` -Recall that the Yosys built-in logic gate types are `$_NOT_`, `$_AND_`, -`$_OR_`, `$_XOR_`, and `$_MUX_` with an assortment of dff memory types. +Recall that the Yosys built-in logic gate types are `$_NOT_`, `$_AND_`, `$_OR_`, +`$_XOR_`, and `$_MUX_` with an assortment of dff memory types. :ref:`mycells-lib` defines our target cells as ``BUF``, ``NOT``, ``NAND``, ``NOR``, and ``DFF``. Mapping between these is performed with the commands `dfflibmap` and `abc` as follows: @@ -117,8 +117,8 @@ The final version of our ``counter`` module looks like this: ``counter`` after hardware cell mapping -Before finally being output as a verilog file with `write_verilog`, -which can then be loaded into another tool: +Before finally being output as a verilog file with `write_verilog`, which can +then be loaded into another tool: .. literalinclude:: /code_examples/intro/counter.ys :language: yoscrypt diff --git a/docs/source/using_yosys/synthesis/extract.rst b/docs/source/using_yosys/synthesis/extract.rst index 176e2ffdd5c..73957bb554b 100644 --- a/docs/source/using_yosys/synthesis/extract.rst +++ b/docs/source/using_yosys/synthesis/extract.rst @@ -1,12 +1,12 @@ The extract pass ---------------- -- Like the `techmap` pass, the `extract` pass is called with a - map file. It compares the circuits inside the modules of the map file with the - design and looks for sub-circuits in the design that match any of the modules - in the map file. -- If a match is found, the `extract` pass will replace the matching - subcircuit with an instance of the module from the map file. +- Like the `techmap` pass, the `extract` pass is called with a map file. It + compares the circuits inside the modules of the map file with the design and + looks for sub-circuits in the design that match any of the modules in the map + file. +- If a match is found, the `extract` pass will replace the matching subcircuit + with an instance of the module from the map file. - In a way the `extract` pass is the inverse of the techmap pass. .. todo:: add/expand supporting text, also mention custom pattern matching and @@ -68,23 +68,23 @@ The wrap-extract-unwrap method ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Often a coarse-grain element has a constant bit-width, but can be used to -implement operations with a smaller bit-width. For example, a 18x25-bit multiplier -can also be used to implement 16x20-bit multiplication. +implement operations with a smaller bit-width. For example, a 18x25-bit +multiplier can also be used to implement 16x20-bit multiplication. A way of mapping such elements in coarse grain synthesis is the wrap-extract-unwrap method: wrap Identify candidate-cells in the circuit and wrap them in a cell with a - constant wider bit-width using `techmap`. The wrappers use the same - parameters as the original cell, so the information about the original width - of the ports is preserved. Then use the `connwrappers` command to - connect up the bit-extended in- and outputs of the wrapper cells. + constant wider bit-width using `techmap`. The wrappers use the same parameters + as the original cell, so the information about the original width of the ports + is preserved. Then use the `connwrappers` command to connect up the + bit-extended in- and outputs of the wrapper cells. extract Now all operations are encoded using the same bit-width as the coarse grain - element. The `extract` command can be used to replace circuits with - cells of the target architecture. + element. The `extract` command can be used to replace circuits with cells of + the target architecture. unwrap The remaining wrapper cell can be unwrapped using `techmap`. diff --git a/docs/source/using_yosys/synthesis/fsm.rst b/docs/source/using_yosys/synthesis/fsm.rst index cb65a298be0..cc3d0879d07 100644 --- a/docs/source/using_yosys/synthesis/fsm.rst +++ b/docs/source/using_yosys/synthesis/fsm.rst @@ -25,9 +25,8 @@ following description: - Does not already have the ``\fsm_encoding`` attribute. - Is not an output of the containing module. - Is driven by single `$dff` or `$adff` cell. -- The ``\D``-Input of this `$dff` or `$adff` cell is driven by a - multiplexer tree that only has constants or the old state value on its - leaves. +- The ``\D``-Input of this `$dff` or `$adff` cell is driven by a multiplexer + tree that only has constants or the old state value on its leaves. - The state value is only used in the said multiplexer tree or by simple relational cells that compare the state value to a constant (usually `$eq` cells). @@ -87,8 +86,8 @@ given set of result signals using a set of signal-value assignments. It can also be passed a list of stop-signals that abort the ConstEval algorithm if the value of a stop-signal is needed in order to calculate the result signals. -The `fsm_extract` pass uses the ConstEval class in the following way to -create a transition table. For each state: +The `fsm_extract` pass uses the ConstEval class in the following way to create a +transition table. For each state: 1. Create a ConstEval object for the module containing the FSM 2. Add all control inputs to the list of stop signals @@ -108,13 +107,12 @@ drivers for the control outputs are disconnected. FSM optimization ~~~~~~~~~~~~~~~~ -The `fsm_opt` pass performs basic optimizations on `$fsm` cells (not -including state recoding). The following optimizations are performed (in this -order): +The `fsm_opt` pass performs basic optimizations on `$fsm` cells (not including +state recoding). The following optimizations are performed (in this order): - Unused control outputs are removed from the `$fsm` cell. The attribute - ``\unused_bits`` (that is usually set by the `opt_clean` pass) is - used to determine which control outputs are unused. + ``\unused_bits`` (that is usually set by the `opt_clean` pass) is used to + determine which control outputs are unused. - Control inputs that are connected to the same driver are merged. @@ -134,11 +132,10 @@ order): FSM recoding ~~~~~~~~~~~~ -The `fsm_recode` pass assigns new bit pattern to the states. Usually -this also implies a change in the width of the state signal. At the moment of -this writing only one-hot encoding with all-zero for the reset state is -supported. +The `fsm_recode` pass assigns new bit pattern to the states. Usually this also +implies a change in the width of the state signal. At the moment of this writing +only one-hot encoding with all-zero for the reset state is supported. -The `fsm_recode` pass can also write a text file with the changes -performed by it that can be used when verifying designs synthesized by Yosys -using Synopsys Formality. +The `fsm_recode` pass can also write a text file with the changes performed by +it that can be used when verifying designs synthesized by Yosys using Synopsys +Formality. diff --git a/docs/source/using_yosys/synthesis/index.rst b/docs/source/using_yosys/synthesis/index.rst index ae6da302a21..60581668ffe 100644 --- a/docs/source/using_yosys/synthesis/index.rst +++ b/docs/source/using_yosys/synthesis/index.rst @@ -8,17 +8,16 @@ coarse-grain optimizations before being mapped to hard blocks and fine-grain cells. Most commands in Yosys will target either coarse-grain representation or fine-grain representation, with only a select few compatible with both states. -Commands such as `proc`, `fsm`, and `memory` rely on -the additional information in the coarse-grain representation, along with a -number of optimizations such as `wreduce`, `share`, and -`alumacc`. `opt` provides optimizations which are useful in -both states, while `techmap` is used to convert coarse-grain cells -to the corresponding fine-grain representation. +Commands such as `proc`, `fsm`, and `memory` rely on the additional information +in the coarse-grain representation, along with a number of optimizations such as +`wreduce`, `share`, and `alumacc`. `opt` provides optimizations which are +useful in both states, while `techmap` is used to convert coarse-grain cells to +the corresponding fine-grain representation. Single-bit cells (logic gates, FFs) as well as LUTs, half-adders, and full-adders make up the bulk of the fine-grain representation and are necessary -for commands such as `abc`\ /`abc9`, `simplemap`, -`dfflegalize`, and `memory_map`. +for commands such as `abc`\ /`abc9`, `simplemap`, `dfflegalize`, and +`memory_map`. .. toctree:: :maxdepth: 3 diff --git a/docs/source/using_yosys/synthesis/memory.rst b/docs/source/using_yosys/synthesis/memory.rst index ad8b47d78fc..a8f2280f77d 100644 --- a/docs/source/using_yosys/synthesis/memory.rst +++ b/docs/source/using_yosys/synthesis/memory.rst @@ -5,10 +5,10 @@ The `memory` command ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In the RTL netlist, memory reads and writes are individual cells. This makes -consolidating the number of ports for a memory easier. The `memory` -pass transforms memories to an implementation. Per default that is logic for -address decoders and registers. It also is a macro command that calls the other -common ``memory_*`` passes in a sensible order: +consolidating the number of ports for a memory easier. The `memory` pass +transforms memories to an implementation. Per default that is logic for address +decoders and registers. It also is a macro command that calls the other common +``memory_*`` passes in a sensible order: .. literalinclude:: /code_examples/macro_commands/memory.ys :language: yoscrypt @@ -22,11 +22,11 @@ Some quick notes: - `memory_dff` merges registers into the memory read- and write cells. - `memory_collect` collects all read and write cells for a memory and transforms them into one multi-port memory cell. -- `memory_map` takes the multi-port memory cell and transforms it to - address decoder logic and registers. +- `memory_map` takes the multi-port memory cell and transforms it to address + decoder logic and registers. -For more information about `memory`, such as disabling certain sub -commands, see :doc:`/cmd/memory`. +For more information about `memory`, such as disabling certain sub commands, see +:doc:`/cmd/memory`. Example ------- @@ -75,20 +75,20 @@ For example: techmap -map my_memory_map.v memory_map -`memory_libmap` attempts to convert memory cells (`$mem_v2` etc) into -hardware supported memory using a provided library (:file:`my_memory_map.txt` in the +`memory_libmap` attempts to convert memory cells (`$mem_v2` etc) into hardware +supported memory using a provided library (:file:`my_memory_map.txt` in the example above). Where necessary, emulation logic is added to ensure functional equivalence before and after this conversion. :yoscrypt:`techmap -map -my_memory_map.v` then uses `techmap` to map to hardware primitives. Any -leftover memory cells unable to be converted are then picked up by -`memory_map` and mapped to DFFs and address decoders. +my_memory_map.v` then uses `techmap` to map to hardware primitives. Any leftover +memory cells unable to be converted are then picked up by `memory_map` and +mapped to DFFs and address decoders. .. note:: More information about what mapping options are available and associated costs of each can be found by enabling debug outputs. This can be done with - the `debug` command, or by using the ``-g`` flag when calling Yosys - to globally enable debug messages. + the `debug` command, or by using the ``-g`` flag when calling Yosys to + globally enable debug messages. For more on the lib format for `memory_libmap`, see `passes/memory/memlib.md @@ -110,13 +110,15 @@ Notes Memory kind selection ~~~~~~~~~~~~~~~~~~~~~ -The memory inference code will automatically pick target memory primitive based on memory geometry -and features used. Depending on the target, there can be up to four memory primitive classes -available for selection: +The memory inference code will automatically pick target memory primitive based +on memory geometry and features used. Depending on the target, there can be up +to four memory primitive classes available for selection: -- FF RAM (aka logic): no hardware primitive used, memory lowered to a bunch of FFs and multiplexers +- FF RAM (aka logic): no hardware primitive used, memory lowered to a bunch of + FFs and multiplexers - - Can handle arbitrary number of write ports, as long as all write ports are in the same clock domain + - Can handle arbitrary number of write ports, as long as all write ports are + in the same clock domain - Can handle arbitrary number and kind of read ports - LUT RAM (aka distributed RAM): uses LUT storage as RAM @@ -131,7 +133,8 @@ available for selection: - Supported on basically all FPGAs - Supports only synchronous reads - Two ports with separate clocks - - Usually supports true dual port (with notable exception of ice40 that only supports SDP) + - Usually supports true dual port (with notable exception of ice40 that only + supports SDP) - Usually supports asymmetric memories and per-byte write enables - Several kilobits in size @@ -155,19 +158,22 @@ available for selection: - Two ports, both with mutually exclusive synchronous read and write - Single clock - - Will not be automatically selected by memory inference code, needs explicit opt-in via - ram_style attribute + - Will not be automatically selected by memory inference code, needs explicit + opt-in via ram_style attribute -In general, you can expect the automatic selection process to work roughly like this: +In general, you can expect the automatic selection process to work roughly like +this: - If any read port is asynchronous, only LUT RAM (or FF RAM) can be used. -- If there is more than one write port, only block RAM can be used, and this needs to be a - hardware-supported true dual port pattern +- If there is more than one write port, only block RAM can be used, and this + needs to be a hardware-supported true dual port pattern - - … unless all write ports are in the same clock domain, in which case FF RAM can also be used, - but this is generally not what you want for anything but really small memories + - … unless all write ports are in the same clock domain, in which case FF RAM + can also be used, but this is generally not what you want for anything but + really small memories -- Otherwise, either FF RAM, LUT RAM, or block RAM will be used, depending on memory size +- Otherwise, either FF RAM, LUT RAM, or block RAM will be used, depending on + memory size This process can be overridden by attaching a ram_style attribute to the memory: @@ -178,15 +184,17 @@ This process can be overridden by attaching a ram_style attribute to the memory: It is an error if this override cannot be realized for the given target. -Many alternate spellings of the attribute are also accepted, for compatibility with other software. +Many alternate spellings of the attribute are also accepted, for compatibility +with other software. Initial data ~~~~~~~~~~~~ -Most FPGA targets support initializing all kinds of memory to user-provided values. If explicit -initialization is not used the initial memory value is undefined. Initial data can be provided by -either initial statements writing memory cells one by one of ``$readmemh`` or ``$readmemb`` system -tasks. For an example pattern, see `sr_init`_. +Most FPGA targets support initializing all kinds of memory to user-provided +values. If explicit initialization is not used the initial memory value is +undefined. Initial data can be provided by either initial statements writing +memory cells one by one of ``$readmemh`` or ``$readmemb`` system tasks. For an +example pattern, see `sr_init`_. .. _wbe: @@ -194,12 +202,13 @@ Write port with byte enables ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Byte enables can be used with any supported pattern -- To ensure that multiple writes will be merged into one port, they need to have disjoint bit - ranges, have the same address, and the same clock -- Any write enable granularity will be accepted (down to per-bit write enables), but using smaller - granularity than natively supported by the target is very likely to be inefficient (eg. using - 4-bit bytes on ECP5 will result in either padding the bytes with 5 dummy bits to native 9-bit - units or splitting the RAM into two block RAMs) +- To ensure that multiple writes will be merged into one port, they need to have + disjoint bit ranges, have the same address, and the same clock +- Any write enable granularity will be accepted (down to per-bit write enables), + but using smaller granularity than natively supported by the target is very + likely to be inefficient (eg. using 4-bit bytes on ECP5 will result in either + padding the bytes with 5 dummy bits to native 9-bit units or splitting the RAM + into two block RAMs) .. code:: verilog @@ -240,7 +249,8 @@ Synchronous SDP with clock domain crossing ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Will result in block RAM or LUT RAM depending on size -- No behavior guarantees in case of simultaneous read and write to the same address +- No behavior guarantees in case of simultaneous read and write to the same + address .. code:: verilog @@ -261,9 +271,9 @@ Synchronous SDP read first - The read and write parts can be in the same or different processes. - Will result in block RAM or LUT RAM depending on size -- As long as the same clock is used for both, yosys will ensure read-first behavior. This may - require extra circuitry on some targets for block RAM. If this is not necessary, use one of the - patterns below. +- As long as the same clock is used for both, yosys will ensure read-first + behavior. This may require extra circuitry on some targets for block RAM. If + this is not necessary, use one of the patterns below. .. code:: verilog @@ -281,8 +291,8 @@ Synchronous SDP read first Synchronous SDP with undefined collision behavior ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Like above, but the read value is undefined when read and write ports target the same address in - the same cycle +- Like above, but the read value is undefined when read and write ports target + the same address in the same cycle .. code:: verilog @@ -322,8 +332,8 @@ Synchronous SDP with write-first behavior ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Will result in block RAM or LUT RAM depending on size -- May use additional circuitry for block RAM if write-first is not natively supported. Will always - use additional circuitry for LUT RAM. +- May use additional circuitry for block RAM if write-first is not natively + supported. Will always use additional circuitry for LUT RAM. .. code:: verilog @@ -343,7 +353,8 @@ Synchronous SDP with write-first behavior Synchronous SDP with write-first behavior (alternate pattern) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- This pattern is supported for compatibility, but is much less flexible than the above +- This pattern is supported for compatibility, but is much less flexible than + the above .. code:: verilog @@ -378,8 +389,10 @@ Synchronous single-port RAM with mutually exclusive read/write ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Will result in single-port block RAM or LUT RAM depending on size -- This is the correct pattern to infer ice40 SPRAM (with manual ram_style selection) -- On targets that don't support read/write block RAM ports (eg. ice40), will result in SDP block RAM instead +- This is the correct pattern to infer ice40 SPRAM (with manual ram_style + selection) +- On targets that don't support read/write block RAM ports (eg. ice40), will + result in SDP block RAM instead - For block RAM, will use "NO_CHANGE" mode if available .. code:: verilog @@ -396,12 +409,14 @@ Synchronous single-port RAM with mutually exclusive read/write Synchronous single-port RAM with read-first behavior ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Will only result in single-port block RAM when read-first behavior is natively supported; - otherwise, SDP RAM with additional circuitry will be used -- Many targets (Xilinx, ECP5, …) can only natively support read-first/write-first single-port RAM - (or TDP RAM) where the write_enable signal implies the read_enable signal (ie. can never write - without reading). The memory inference code will run a simple SAT solver on the control signals to - determine if this is the case, and insert emulation circuitry if it cannot be easily proven. +- Will only result in single-port block RAM when read-first behavior is natively + supported; otherwise, SDP RAM with additional circuitry will be used +- Many targets (Xilinx, ECP5, …) can only natively support + read-first/write-first single-port RAM (or TDP RAM) where the write_enable + signal implies the read_enable signal (ie. can never write without reading). + The memory inference code will run a simple SAT solver on the control signals + to determine if this is the case, and insert emulation circuitry if it cannot + be easily proven. .. code:: verilog @@ -418,7 +433,8 @@ Synchronous single-port RAM with write-first behavior ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Will result in single-port block RAM or LUT RAM when supported -- Block RAMs will require extra circuitry if write-first behavior not natively supported +- Block RAMs will require extra circuitry if write-first behavior not natively + supported .. code:: verilog @@ -440,8 +456,8 @@ Synchronous read port with initial value ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Initial read port values can be combined with any other supported pattern -- If block RAM is used and initial read port values are not natively supported by the target, small - emulation circuit will be inserted +- If block RAM is used and initial read port values are not natively supported + by the target, small emulation circuit will be inserted .. code:: verilog @@ -459,10 +475,11 @@ Synchronous read port with initial value Read register reset patterns ---------------------------- -Resets can be combined with any other supported pattern (except that synchronous reset and -asynchronous reset cannot both be used on a single read port). If block RAM is used and the -selected reset (synchronous or asynchronous) is used but not natively supported by the target, small -emulation circuitry will be inserted. +Resets can be combined with any other supported pattern (except that synchronous +reset and asynchronous reset cannot both be used on a single read port). If +block RAM is used and the selected reset (synchronous or asynchronous) is used +but not natively supported by the target, small emulation circuitry will be +inserted. Synchronous reset, reset priority over enable ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -520,22 +537,26 @@ Synchronous read port with asynchronous reset Asymmetric memory patterns -------------------------- -To construct an asymmetric memory (memory with read/write ports of differing widths): +To construct an asymmetric memory (memory with read/write ports of differing +widths): - Declare the memory with the width of the narrowest intended port - Split all wide ports into multiple narrow ports - To ensure the wide ports will be correctly merged: - - For the address, use a concatenation of actual address in the high bits and a constant in the - low bits - - Ensure the actual address is identical for all ports belonging to the wide port + - For the address, use a concatenation of actual address in the high bits and + a constant in the low bits + - Ensure the actual address is identical for all ports belonging to the wide + port - Ensure that clock is identical - - For read ports, ensure that enable/reset signals are identical (for write ports, the enable - signal may vary — this will result in using the byte enable functionality) + - For read ports, ensure that enable/reset signals are identical (for write + ports, the enable signal may vary — this will result in using the byte + enable functionality) -Asymmetric memory is supported on all targets, but may require emulation circuitry where not -natively supported. Note that when the memory is larger than the underlying block RAM primitive, -hardware asymmetric memory support is likely not to be used even if present as it is more expensive. +Asymmetric memory is supported on all targets, but may require emulation +circuitry where not natively supported. Note that when the memory is larger +than the underlying block RAM primitive, hardware asymmetric memory support is +likely not to be used even if present as it is more expensive. .. _wide_sr: @@ -615,20 +636,25 @@ Wide write port True dual port (TDP) patterns ----------------------------- -- Many different variations of true dual port memory can be created by combining two single-port RAM - patterns on the same memory -- When TDP memory is used, memory inference code has much less maneuver room to create requested - semantics compared to individual single-port patterns (which can end up lowered to SDP memory - where necessary) — supported patterns depend strongly on the target -- In particular, when both ports have the same clock, it's likely that "undefined collision" mode - needs to be manually selected to enable TDP memory inference -- The examples below are non-exhaustive — many more combinations of port types are possible -- Note: if two write ports are in the same process, this defines a priority relation between them - (if both ports are active in the same clock, the later one wins). On almost all targets, this will - result in a bit of extra circuitry to ensure the priority semantics. If this is not what you want, - put them in separate processes. - - - Priority is not supported when using the verific front end and any priority semantics are ignored. +- Many different variations of true dual port memory can be created by combining + two single-port RAM patterns on the same memory +- When TDP memory is used, memory inference code has much less maneuver room to + create requested semantics compared to individual single-port patterns (which + can end up lowered to SDP memory where necessary) — supported patterns depend + strongly on the target +- In particular, when both ports have the same clock, it's likely that + "undefined collision" mode needs to be manually selected to enable TDP memory + inference +- The examples below are non-exhaustive — many more combinations of port types + are possible +- Note: if two write ports are in the same process, this defines a priority + relation between them (if both ports are active in the same clock, the later + one wins). On almost all targets, this will result in a bit of extra circuitry + to ensure the priority semantics. If this is not what you want, put them in + separate processes. + + - Priority is not supported when using the verific front end and any priority + semantics are ignored. TDP with different clocks, exclusive read/write ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -654,7 +680,8 @@ TDP with different clocks, exclusive read/write TDP with same clock, read-first behavior ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- This requires hardware inter-port read-first behavior, and will only work on some targets (Xilinx, Nexus) +- This requires hardware inter-port read-first behavior, and will only work on + some targets (Xilinx, Nexus) .. code:: verilog @@ -677,9 +704,10 @@ TDP with same clock, read-first behavior TDP with multiple read ports ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- The combination of a single write port with an arbitrary amount of read ports is supported on all - targets — if a multi-read port primitive is available (like Xilinx RAM64M), it'll be used as - appropriate. Otherwise, the memory will be automatically split into multiple primitives. +- The combination of a single write port with an arbitrary amount of read ports + is supported on all targets — if a multi-read port primitive is available + (like Xilinx RAM64M), it'll be used as appropriate. Otherwise, the memory + will be automatically split into multiple primitives. .. code:: verilog diff --git a/docs/source/using_yosys/synthesis/opt.rst b/docs/source/using_yosys/synthesis/opt.rst index db1525a05ad..7af2231c9d7 100644 --- a/docs/source/using_yosys/synthesis/opt.rst +++ b/docs/source/using_yosys/synthesis/opt.rst @@ -9,9 +9,9 @@ This chapter outlines these optimizations. The `opt` macro command -------------------------------- -The Yosys pass `opt` runs a number of simple optimizations. This -includes removing unused signals and cells and const folding. It is recommended -to run this pass after each major step in the synthesis script. As listed in +The Yosys pass `opt` runs a number of simple optimizations. This includes +removing unused signals and cells and const folding. It is recommended to run +this pass after each major step in the synthesis script. As listed in :doc:`/cmd/opt`, this macro command calls the following ``opt_*`` commands: .. literalinclude:: /code_examples/macro_commands/opt.ys @@ -69,17 +69,17 @@ undef. The last two lines simply replace an `$_AND_` gate with one constant-1 input with a buffer. -Besides this basic const folding the `opt_expr` pass can replace 1-bit -wide `$eq` and `$ne` cells with buffers or not-gates if one input is -constant. Equality checks may also be reduced in size if there are redundant -bits in the arguments (i.e. bits which are constant on both inputs). This can, -for example, result in a 32-bit wide constant like ``255`` being reduced to the -8-bit value of ``8'11111111`` if the signal being compared is only 8-bit as in +Besides this basic const folding the `opt_expr` pass can replace 1-bit wide +`$eq` and `$ne` cells with buffers or not-gates if one input is constant. +Equality checks may also be reduced in size if there are redundant bits in the +arguments (i.e. bits which are constant on both inputs). This can, for example, +result in a 32-bit wide constant like ``255`` being reduced to the 8-bit value +of ``8'11111111`` if the signal being compared is only 8-bit as in :ref:`addr_gen_clean` of :doc:`/getting_started/example_synth`. -The `opt_expr` pass is very conservative regarding optimizing `$mux` -cells, as these cells are often used to model decision-trees and breaking these -trees can interfere with other optimizations. +The `opt_expr` pass is very conservative regarding optimizing `$mux` cells, as +these cells are often used to model decision-trees and breaking these trees can +interfere with other optimizations. .. literalinclude:: /code_examples/opt/opt_expr.ys :language: Verilog @@ -100,9 +100,9 @@ identifies cells with identical inputs and replaces them with a single instance of the cell. The option ``-nomux`` can be used to disable resource sharing for multiplexer -cells (`$mux` and `$pmux`.) This can be useful as it prevents multiplexer -trees to be merged, which might prevent `opt_muxtree` to identify -possible optimizations. +cells (`$mux` and `$pmux`.) This can be useful as it prevents multiplexer trees +to be merged, which might prevent `opt_muxtree` to identify possible +optimizations. .. literalinclude:: /code_examples/opt/opt_merge.ys :language: Verilog @@ -128,9 +128,9 @@ Consider the following simple example: :caption: example verilog for demonstrating `opt_muxtree` The output can never be ``c``, as this would require ``a`` to be 1 for the outer -multiplexer and 0 for the inner multiplexer. The `opt_muxtree` pass -detects this contradiction and replaces the inner multiplexer with a constant 1, -yielding the logic for ``y = a ? b : d``. +multiplexer and 0 for the inner multiplexer. The `opt_muxtree` pass detects this +contradiction and replaces the inner multiplexer with a constant 1, yielding the +logic for ``y = a ? b : d``. .. figure:: /_images/code_examples/opt/opt_muxtree.* :class: width-helper invert-helper @@ -141,9 +141,9 @@ Simplifying large MUXes and AND/OR gates - `opt_reduce` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is a simple optimization pass that identifies and consolidates identical -input bits to `$reduce_and` and `$reduce_or` cells. It also sorts the input -bits to ease identification of shareable `$reduce_and` and `$reduce_or` -cells in other passes. +input bits to `$reduce_and` and `$reduce_or` cells. It also sorts the input bits +to ease identification of shareable `$reduce_and` and `$reduce_or` cells in +other passes. This pass also identifies and consolidates identical inputs to multiplexer cells. In this case the new shared select bit is driven using a `$reduce_or` @@ -162,8 +162,8 @@ This pass identifies mutually exclusive cells of the same type that: a. share an input signal, and b. drive the same `$mux`, `$_MUX_`, or `$pmux` multiplexing cell, -allowing the cell to be merged and the multiplexer to be moved from -multiplexing its output to multiplexing the non-shared input signals. +allowing the cell to be merged and the multiplexer to be moved from multiplexing +its output to multiplexing the non-shared input signals. .. literalinclude:: /code_examples/opt/opt_share.ys :language: Verilog @@ -176,16 +176,16 @@ multiplexing its output to multiplexing the non-shared input signals. Before and after `opt_share` -When running `opt` in full, the original `$mux` (labeled ``$3``) is -optimized away by `opt_expr`. +When running `opt` in full, the original `$mux` (labeled ``$3``) is optimized +away by `opt_expr`. Performing DFF optimizations - `opt_dff` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -This pass identifies single-bit d-type flip-flops (`$_DFF_`, `$dff`, and -`$adff` cells) with a constant data input and replaces them with a constant -driver. It can also merge clock enables and synchronous reset multiplexers, -removing unused control inputs. +This pass identifies single-bit d-type flip-flops (`$_DFF_`, `$dff`, and `$adff` +cells) with a constant data input and replaces them with a constant driver. It +can also merge clock enables and synchronous reset multiplexers, removing unused +control inputs. Called with ``-nodffe`` and ``-nosdff``, this pass is used to prepare a design for :doc:`/using_yosys/synthesis/fsm`. @@ -200,20 +200,20 @@ attribute can be used for debugging or by other optimization passes. When to use `opt` or `clean` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Usually it does not hurt to call `opt` after each regular command in -the synthesis script. But it increases the synthesis time, so it is favourable -to only call `opt` when an improvement can be achieved. +Usually it does not hurt to call `opt` after each regular command in the +synthesis script. But it increases the synthesis time, so it is favourable to +only call `opt` when an improvement can be achieved. -It is generally a good idea to call `opt` before inherently expensive -commands such as `sat` or `freduce`, as the possible gain is -much higher in these cases as the possible loss. +It is generally a good idea to call `opt` before inherently expensive commands +such as `sat` or `freduce`, as the possible gain is much higher in these cases +as the possible loss. -The `clean` command, which is an alias for `opt_clean` with -fewer outputs, on the other hand is very fast and many commands leave a mess -(dangling signal wires, etc). For example, most commands do not remove any wires -or cells. They just change the connections and depend on a later call to clean -to get rid of the now unused objects. So the occasional ``;;``, which itself is -an alias for `clean`, is a good idea in every synthesis script, e.g: +The `clean` command, which is an alias for `opt_clean` with fewer outputs, on +the other hand is very fast and many commands leave a mess (dangling signal +wires, etc). For example, most commands do not remove any wires or cells. They +just change the connections and depend on a later call to clean to get rid of +the now unused objects. So the occasional ``;;``, which itself is an alias for +`clean`, is a good idea in every synthesis script, e.g: .. code-block:: yoscrypt diff --git a/docs/source/using_yosys/synthesis/proc.rst b/docs/source/using_yosys/synthesis/proc.rst index cc22fcec71e..b7cd348d778 100644 --- a/docs/source/using_yosys/synthesis/proc.rst +++ b/docs/source/using_yosys/synthesis/proc.rst @@ -5,23 +5,23 @@ Converting process blocks :language: yoscrypt The Verilog frontend converts ``always``-blocks to RTL netlists for the -expressions and "processess" for the control- and memory elements. The -`proc` command then transforms these "processess" to netlists of RTL -multiplexer and register cells. It also is a macro command that calls the other -``proc_*`` commands in a sensible order: +expressions and "processess" for the control- and memory elements. The `proc` +command then transforms these "processess" to netlists of RTL multiplexer and +register cells. It also is a macro command that calls the other ``proc_*`` +commands in a sensible order: .. literalinclude:: /code_examples/macro_commands/proc.ys :language: yoscrypt :start-after: #end: :caption: Passes called by `proc` -After all the ``proc_*`` commands, `opt_expr` is called. This can be -disabled by calling :yoscrypt:`proc -noopt`. For more information about -`proc`, such as disabling certain sub commands, see :doc:`/cmd/proc`. +After all the ``proc_*`` commands, `opt_expr` is called. This can be disabled by +calling :yoscrypt:`proc -noopt`. For more information about `proc`, such as +disabling certain sub commands, see :doc:`/cmd/proc`. Many commands can not operate on modules with "processess" in them. Usually a -call to `proc` is the first command in the actual synthesis procedure -after design elaboration. +call to `proc` is the first command in the actual synthesis procedure after +design elaboration. Example ^^^^^^^ diff --git a/docs/source/yosys_internals/extending_yosys/extensions.rst b/docs/source/yosys_internals/extending_yosys/extensions.rst index 2a34c700a4c..88e001d0666 100644 --- a/docs/source/yosys_internals/extending_yosys/extensions.rst +++ b/docs/source/yosys_internals/extending_yosys/extensions.rst @@ -20,8 +20,8 @@ CodingStyle may be of interest. Quick guide ----------- -Code examples from this section are included in the -|code_examples/extensions|_ directory of the Yosys source code. +Code examples from this section are included in the |code_examples/extensions|_ +directory of the Yosys source code. .. |code_examples/extensions| replace:: :file:`docs/source/code_examples/extensions` .. _code_examples/extensions: https://github.com/YosysHQ/yosys/tree/main/docs/source/code_examples/extensions @@ -56,10 +56,9 @@ It is possible to only work on this simpler version: } When trying to understand what a command does, creating a small test case to -look at the output of `dump` and `show` before and after the -command has been executed can be helpful. -:doc:`/using_yosys/more_scripting/selections` has more information on using -these commands. +look at the output of `dump` and `show` before and after the command has been +executed can be helpful. :doc:`/using_yosys/more_scripting/selections` has more +information on using these commands. Creating a command ~~~~~~~~~~~~~~~~~~ @@ -151,8 +150,8 @@ Most commands modify existing modules, not create new ones. When modifying existing modules, stick to the following DOs and DON'Ts: -- Do not remove wires. Simply disconnect them and let a successive - `clean` command worry about removing it. +- Do not remove wires. Simply disconnect them and let a successive `clean` + command worry about removing it. - Use ``module->fixup_ports()`` after changing the ``port_*`` properties of wires. - You can safely remove cells or change the ``connections`` property of a cell, diff --git a/docs/source/yosys_internals/flow/verilog_frontend.rst b/docs/source/yosys_internals/flow/verilog_frontend.rst index fced46e8ca7..e5346668761 100644 --- a/docs/source/yosys_internals/flow/verilog_frontend.rst +++ b/docs/source/yosys_internals/flow/verilog_frontend.rst @@ -599,14 +599,14 @@ The proc pass The ProcessGenerator converts a behavioural model in AST representation to a behavioural model in ``RTLIL::Process`` representation. The actual conversion -from a behavioural model to an RTL representation is performed by the -`proc` pass and the passes it launches: +from a behavioural model to an RTL representation is performed by the `proc` +pass and the passes it launches: - | `proc_clean` and `proc_rmdead` | These two passes just clean up the ``RTLIL::Process`` structure. The - `proc_clean` pass removes empty parts (eg. empty assignments) from - the process and `proc_rmdead` detects and removes unreachable - branches from the process's decision trees. + `proc_clean` pass removes empty parts (eg. empty assignments) from the + process and `proc_rmdead` detects and removes unreachable branches from the + process's decision trees. - | `proc_arst` | This pass detects processes that describe d-type flip-flops with @@ -617,10 +617,10 @@ from a behavioural model to an RTL representation is performed by the and the top-level ``RTLIL::SwitchRule`` has been removed. - | `proc_mux` - | This pass converts the ``RTLIL::CaseRule``/\ ``RTLIL::SwitchRule``-tree to a - tree of multiplexers per written signal. After this, the ``RTLIL::Process`` - structure only contains the ``RTLIL::SyncRule`` s that describe the output - registers. + | This pass converts the ``RTLIL::CaseRule``/\ ``RTLIL::SwitchRule``-tree to + a tree of multiplexers per written signal. After this, the + ``RTLIL::Process`` structure only contains the ``RTLIL::SyncRule`` s that + describe the output registers. - | `proc_dff` | This pass replaces the ``RTLIL::SyncRule``\ s to d-type flip-flops (with @@ -630,8 +630,8 @@ from a behavioural model to an RTL representation is performed by the | This pass replaces the ``RTLIL::MemWriteAction``\ s with `$memwr` cells. - | `proc_clean` - | A final call to `proc_clean` removes the now empty - ``RTLIL::Process`` objects. + | A final call to `proc_clean` removes the now empty ``RTLIL::Process`` + objects. Performing these last processing steps in passes instead of in the Verilog frontend has two important benefits: @@ -646,8 +646,8 @@ to extend the actual Verilog frontend. .. todo:: Synthesizing Verilog arrays - Add some information on the generation of `$memrd` and `$memwr` cells and - how they are processed in the memory pass. + Add some information on the generation of `$memrd` and `$memwr` cells and how + they are processed in the memory pass. .. todo:: Synthesizing parametric designs diff --git a/docs/source/yosys_internals/formats/cell_library.rst b/docs/source/yosys_internals/formats/cell_library.rst index e9ed4d7f9be..c17976319c0 100644 --- a/docs/source/yosys_internals/formats/cell_library.rst +++ b/docs/source/yosys_internals/formats/cell_library.rst @@ -73,16 +73,16 @@ also have the following parameters: :verilog:`Y = !A` $logic_not ================== ============ -For the unary cells that output a logical value (`$reduce_and`, -`$reduce_or`, `$reduce_xor`, `$reduce_xnor`, `$reduce_bool`, -`$logic_not`), when the ``\Y_WIDTH`` parameter is greater than 1, the output -is zero-extended, and only the least significant bit varies. +For the unary cells that output a logical value (`$reduce_and`, `$reduce_or`, +`$reduce_xor`, `$reduce_xnor`, `$reduce_bool`, `$logic_not`), when the +``\Y_WIDTH`` parameter is greater than 1, the output is zero-extended, and only +the least significant bit varies. Note that `$reduce_or` and `$reduce_bool` actually represent the same logic function. But the HDL frontends generate them in different situations. A `$reduce_or` cell is generated when the prefix ``|`` operator is being used. A -`$reduce_bool` cell is generated when a bit vector is used as a condition in -an ``if``-statement or ``?:``-expression. +`$reduce_bool` cell is generated when a bit vector is used as a condition in an +``if``-statement or ``?:``-expression. Binary operators ~~~~~~~~~~~~~~~~ @@ -91,15 +91,15 @@ All binary RTL cells have two input ports ``\A`` and ``\B`` and one output port ``\Y``. They also have the following parameters: ``\A_SIGNED`` - Set to a non-zero value if the input ``\A`` is signed and therefore - should be sign-extended when needed. + Set to a non-zero value if the input ``\A`` is signed and therefore should be + sign-extended when needed. ``\A_WIDTH`` The width of the input port ``\A``. ``\B_SIGNED`` - Set to a non-zero value if the input ``\B`` is signed and therefore - should be sign-extended when needed. + Set to a non-zero value if the input ``\B`` is signed and therefore should be + sign-extended when needed. ``\B_WIDTH`` The width of the input port ``\B``. @@ -130,29 +130,28 @@ All binary RTL cells have two input ports ``\A`` and ``\B`` and one output port :verilog:`Y = A ** B` $pow ``N/A`` $modfloor ======================= ============= ======================= ========= -The `$shl` and `$shr` cells implement logical shifts, whereas the `$sshl` -and `$sshr` cells implement arithmetic shifts. The `$shl` and `$sshl` -cells implement the same operation. All four of these cells interpret the second +The `$shl` and `$shr` cells implement logical shifts, whereas the `$sshl` and +`$sshr` cells implement arithmetic shifts. The `$shl` and `$sshl` cells +implement the same operation. All four of these cells interpret the second operand as unsigned, and require ``\B_SIGNED`` to be zero. Two additional shift operator cells are available that do not directly -correspond to any operator in Verilog, `$shift` and `$shiftx`. The -`$shift` cell performs a right logical shift if the second operand is positive -(or unsigned), and a left logical shift if it is negative. The `$shiftx` cell -performs the same operation as the `$shift` cell, but the vacated bit -positions are filled with undef (x) bits, and corresponds to the Verilog indexed -part-select expression. +correspond to any operator in Verilog, `$shift` and `$shiftx`. The `$shift` cell +performs a right logical shift if the second operand is positive (or unsigned), +and a left logical shift if it is negative. The `$shiftx` cell performs the same +operation as the `$shift` cell, but the vacated bit positions are filled with +undef (x) bits, and corresponds to the Verilog indexed part-select expression. For the binary cells that output a logical value (`$logic_and`, `$logic_or`, -`$eqx`, `$nex`, `$lt`, `$le`, `$eq`, `$ne`, `$ge`, `$gt`), when -the ``\Y_WIDTH`` parameter is greater than 1, the output is zero-extended, and -only the least significant bit varies. +`$eqx`, `$nex`, `$lt`, `$le`, `$eq`, `$ne`, `$ge`, `$gt`), when the ``\Y_WIDTH`` +parameter is greater than 1, the output is zero-extended, and only the least +significant bit varies. Division and modulo cells are available in two rounding modes. The original -`$div` and `$mod` cells are based on truncating division, and correspond to -the semantics of the verilog ``/`` and ``%`` operators. The `$divfloor` and -`$modfloor` cells represent flooring division and flooring modulo, the latter -of which is also known as "remainder" in several languages. See +`$div` and `$mod` cells are based on truncating division, and correspond to the +semantics of the verilog ``/`` and ``%`` operators. The `$divfloor` and +`$modfloor` cells represent flooring division and flooring modulo, the latter of +which is also known as "remainder" in several languages. See :numref:`tab:CellLib_divmod` for a side-by-side comparison between the different semantics. @@ -187,9 +186,9 @@ all of the specified width. This cell also has a single bit control input it is 1 the value from the ``\B`` input is sent to the output. So the `$mux` cell implements the function :verilog:`Y = S ? B : A`. -The `$pmux` cell is used to multiplex between many inputs using a one-hot -select signal. Cells of this type have a ``\WIDTH`` and a ``\S_WIDTH`` parameter -and inputs ``\A``, ``\B``, and ``\S`` and an output ``\Y``. The ``\S`` input is +The `$pmux` cell is used to multiplex between many inputs using a one-hot select +signal. Cells of this type have a ``\WIDTH`` and a ``\S_WIDTH`` parameter and +inputs ``\A``, ``\B``, and ``\S`` and an output ``\Y``. The ``\S`` input is ``\S_WIDTH`` bits wide. The ``\A`` input and the output are both ``\WIDTH`` bits wide and the ``\B`` input is ``\WIDTH*\S_WIDTH`` bits wide. When all bits of ``\S`` are zero, the value from ``\A`` input is sent to the output. If the @@ -199,8 +198,8 @@ from ``\S`` is set the output is undefined. Cells of this type are used to model "parallel cases" (defined by using the ``parallel_case`` attribute or detected by an optimization). -The `$tribuf` cell is used to implement tristate logic. Cells of this type -have a ``\WIDTH`` parameter and inputs ``\A`` and ``\EN`` and an output ``\Y``. The +The `$tribuf` cell is used to implement tristate logic. Cells of this type have +a ``\WIDTH`` parameter and inputs ``\A`` and ``\EN`` and an output ``\Y``. The ``\A`` input and ``\Y`` output are ``\WIDTH`` bits wide, and the ``\EN`` input is one bit wide. When ``\EN`` is 0, the output is not driven. When ``\EN`` is 1, the value from ``\A`` input is sent to the ``\Y`` output. Therefore, the @@ -224,27 +223,27 @@ parameters: The width of inputs ``\SET`` and ``\CLR`` and output ``\Q``. ``\SET_POLARITY`` - The set input bits are active-high if this parameter has the value - ``1'b1`` and active-low if this parameter is ``1'b0``. + The set input bits are active-high if this parameter has the value ``1'b1`` + and active-low if this parameter is ``1'b0``. ``\CLR_POLARITY`` - The reset input bits are active-high if this parameter has the value - ``1'b1`` and active-low if this parameter is ``1'b0``. + The reset input bits are active-high if this parameter has the value ``1'b1`` + and active-low if this parameter is ``1'b0``. Both set and reset inputs have separate bits for every output bit. When both the set and reset inputs of an `$sr` cell are active for a given bit index, the reset input takes precedence. -D-type flip-flops are represented by `$dff` cells. These cells have a clock -port ``\CLK``, an input port ``\D`` and an output port ``\Q``. The following +D-type flip-flops are represented by `$dff` cells. These cells have a clock port +``\CLK``, an input port ``\D`` and an output port ``\Q``. The following parameters are available for `$dff` cells: ``\WIDTH`` The width of input ``\D`` and output ``\Q``. ``\CLK_POLARITY`` - Clock is active on the positive edge if this parameter has the value - ``1'b1`` and on the negative edge if this parameter is ``1'b0``. + Clock is active on the positive edge if this parameter has the value ``1'b1`` + and on the negative edge if this parameter is ``1'b0``. D-type flip-flops with asynchronous reset are represented by `$adff` cells. As the `$dff` cells they have ``\CLK``, ``\D`` and ``\Q`` ports. In addition they @@ -258,8 +257,8 @@ additional two parameters: ``\ARST_VALUE`` The state of ``\Q`` will be set to this value when the reset is active. -Usually these cells are generated by the `proc` pass using the -information in the designs RTLIL::Process objects. +Usually these cells are generated by the `proc` pass using the information in +the designs RTLIL::Process objects. D-type flip-flops with synchronous reset are represented by `$sdff` cells. As the `$dff` cells they have ``\CLK``, ``\D`` and ``\Q`` ports. In addition they @@ -267,14 +266,14 @@ also have a single-bit ``\SRST`` input port for the reset pin and the following additional two parameters: ``\SRST_POLARITY`` - The synchronous reset is active-high if this parameter has the value - ``1'b1`` and active-low if this parameter is ``1'b0``. + The synchronous reset is active-high if this parameter has the value ``1'b1`` + and active-low if this parameter is ``1'b0``. ``\SRST_VALUE`` The state of ``\Q`` will be set to this value when the reset is active. -Note that the `$adff` and `$sdff` cells can only be used when the reset -value is constant. +Note that the `$adff` and `$sdff` cells can only be used when the reset value is +constant. D-type flip-flops with asynchronous load are represented by `$aldff` cells. As the `$dff` cells they have ``\CLK``, ``\D`` and ``\Q`` ports. In addition they @@ -283,25 +282,24 @@ also have a single-bit ``\ALOAD`` input port for the async load enable pin, a following additional parameter: ``\ALOAD_POLARITY`` - The asynchronous load is active-high if this parameter has the value - ``1'b1`` and active-low if this parameter is ``1'b0``. + The asynchronous load is active-high if this parameter has the value ``1'b1`` + and active-low if this parameter is ``1'b0``. D-type flip-flops with asynchronous set and reset are represented by `$dffsr` cells. As the `$dff` cells they have ``\CLK``, ``\D`` and ``\Q`` ports. In addition they also have multi-bit ``\SET`` and ``\CLR`` input ports and the corresponding polarity parameters, like `$sr` cells. -D-type flip-flops with enable are represented by `$dffe`, `$adffe`, -`$aldffe`, `$dffsre`, `$sdffe`, and `$sdffce` cells, which are enhanced -variants of `$dff`, `$adff`, `$aldff`, `$dffsr`, `$sdff` (with reset -over enable) and `$sdff` (with enable over reset) cells, respectively. They -have the same ports and parameters as their base cell. In addition they also -have a single-bit ``\EN`` input port for the enable pin and the following -parameter: +D-type flip-flops with enable are represented by `$dffe`, `$adffe`, `$aldffe`, +`$dffsre`, `$sdffe`, and `$sdffce` cells, which are enhanced variants of `$dff`, +`$adff`, `$aldff`, `$dffsr`, `$sdff` (with reset over enable) and `$sdff` (with +enable over reset) cells, respectively. They have the same ports and parameters +as their base cell. In addition they also have a single-bit ``\EN`` input port +for the enable pin and the following parameter: ``\EN_POLARITY`` - The enable input is active-high if this parameter has the value ``1'b1`` - and active-low if this parameter is ``1'b0``. + The enable input is active-high if this parameter has the value ``1'b1`` and + active-low if this parameter is ``1'b0``. D-type latches are represented by `$dlatch` cells. These cells have an enable port ``\EN``, an input port ``\D``, and an output port ``\Q``. The following @@ -311,14 +309,14 @@ parameters are available for `$dlatch` cells: The width of input ``\D`` and output ``\Q``. ``\EN_POLARITY`` - The enable input is active-high if this parameter has the value ``1'b1`` - and active-low if this parameter is ``1'b0``. + The enable input is active-high if this parameter has the value ``1'b1`` and + active-low if this parameter is ``1'b0``. The latch is transparent when the ``\EN`` input is active. D-type latches with reset are represented by `$adlatch` cells. In addition to -`$dlatch` ports and parameters, they also have a single-bit ``\ARST`` input -port for the reset pin and the following additional parameters: +`$dlatch` ports and parameters, they also have a single-bit ``\ARST`` input port +for the reset pin and the following additional parameters: ``\ARST_POLARITY`` The asynchronous reset is active-high if this parameter has the value @@ -363,56 +361,53 @@ parameters: The number of address bits (width of the ``\ADDR`` input port). ``\WIDTH`` - The number of data bits (width of the ``\DATA`` output port). Note that - this may be a power-of-two multiple of the underlying memory's width -- - such ports are called wide ports and access an aligned group of cells at - once. In this case, the corresponding low bits of ``\ADDR`` must be - tied to 0. + The number of data bits (width of the ``\DATA`` output port). Note that this + may be a power-of-two multiple of the underlying memory's width -- such ports + are called wide ports and access an aligned group of cells at once. In this + case, the corresponding low bits of ``\ADDR`` must be tied to 0. ``\CLK_ENABLE`` - When this parameter is non-zero, the clock is used. Otherwise this read - port is asynchronous and the ``\CLK`` input is not used. + When this parameter is non-zero, the clock is used. Otherwise this read port + is asynchronous and the ``\CLK`` input is not used. ``\CLK_POLARITY`` - Clock is active on the positive edge if this parameter has the value - ``1'b1`` and on the negative edge if this parameter is ``1'b0``. + Clock is active on the positive edge if this parameter has the value ``1'b1`` + and on the negative edge if this parameter is ``1'b0``. ``\TRANSPARENCY_MASK`` - This parameter is a bitmask of write ports that this read port is - transparent with. The bits of this parameter are indexed by the write - port's ``\PORTID`` parameter. Transparency can only be enabled between - synchronous ports sharing a clock domain. When transparency is enabled - for a given port pair, a read and write to the same address in the same - cycle will return the new value. Otherwise the old value is returned. + This parameter is a bitmask of write ports that this read port is transparent + with. The bits of this parameter are indexed by the write port's ``\PORTID`` + parameter. Transparency can only be enabled between synchronous ports sharing + a clock domain. When transparency is enabled for a given port pair, a read + and write to the same address in the same cycle will return the new value. + Otherwise the old value is returned. ``\COLLISION_X_MASK`` This parameter is a bitmask of write ports that have undefined collision - behavior with this port. The bits of this parameter are indexed by the - write port's ``\PORTID`` parameter. This behavior can only be enabled - between synchronous ports sharing a clock domain. When undefined - collision is enabled for a given port pair, a read and write to the same - address in the same cycle will return the undefined (all-X) value.This - option is exclusive (for a given port pair) with the transparency - option. + behavior with this port. The bits of this parameter are indexed by the write + port's ``\PORTID`` parameter. This behavior can only be enabled between + synchronous ports sharing a clock domain. When undefined collision is enabled + for a given port pair, a read and write to the same address in the same cycle + will return the undefined (all-X) value.This option is exclusive (for a given + port pair) with the transparency option. ``\ARST_VALUE`` - Whenever the ``\ARST`` input is asserted, the data output will be reset - to this value. Only used for synchronous ports. + Whenever the ``\ARST`` input is asserted, the data output will be reset to + this value. Only used for synchronous ports. ``\SRST_VALUE`` - Whenever the ``\SRST`` input is synchronously asserted, the data output - will be reset to this value. Only used for synchronous ports. + Whenever the ``\SRST`` input is synchronously asserted, the data output will + be reset to this value. Only used for synchronous ports. ``\INIT_VALUE`` The initial value of the data output, for synchronous ports. ``\CE_OVER_SRST`` - If this parameter is non-zero, the ``\SRST`` input is only recognized - when ``\EN`` is true. Otherwise, ``\SRST`` is recognized regardless of - ``\EN``. + If this parameter is non-zero, the ``\SRST`` input is only recognized when + ``\EN`` is true. Otherwise, ``\SRST`` is recognized regardless of ``\EN``. -The `$memwr_v2` cells have a clock input ``\CLK``, an enable input ``\EN`` -(one enable bit for each data bit), an address input ``\ADDR`` and a data input +The `$memwr_v2` cells have a clock input ``\CLK``, an enable input ``\EN`` (one +enable bit for each data bit), an address input ``\ADDR`` and a data input ``\DATA``. They also have the following parameters: ``\MEMID`` @@ -424,16 +419,16 @@ The `$memwr_v2` cells have a clock input ``\CLK``, an enable input ``\EN`` ``\WIDTH`` The number of data bits (width of the ``\DATA`` output port). Like with - `$memrd_v2` cells, the width is allowed to be any power-of-two - multiple of memory width, with the corresponding restriction on address. + `$memrd_v2` cells, the width is allowed to be any power-of-two multiple of + memory width, with the corresponding restriction on address. ``\CLK_ENABLE`` - When this parameter is non-zero, the clock is used. Otherwise this write - port is asynchronous and the ``\CLK`` input is not used. + When this parameter is non-zero, the clock is used. Otherwise this write port + is asynchronous and the ``\CLK`` input is not used. ``\CLK_POLARITY`` - Clock is active on positive edge if this parameter has the value - ``1'b1`` and on the negative edge if this parameter is ``1'b0``. + Clock is active on positive edge if this parameter has the value ``1'b1`` and + on the negative edge if this parameter is ``1'b0``. ``\PORTID`` An identifier for this write port, used to index write port bit mask @@ -442,16 +437,16 @@ The `$memwr_v2` cells have a clock input ``\CLK``, an enable input ``\EN`` ``\PRIORITY_MASK`` This parameter is a bitmask of write ports that this write port has priority over in case of writing to the same address. The bits of this parameter are - indexed by the other write port's ``\PORTID`` parameter. Write ports can - only have priority over write ports with lower port ID. When two ports write - to the same address and neither has priority over the other, the result is + indexed by the other write port's ``\PORTID`` parameter. Write ports can only + have priority over write ports with lower port ID. When two ports write to + the same address and neither has priority over the other, the result is undefined. Priority can only be set between two synchronous ports sharing the same clock domain. -The `$meminit_v2` cells have an address input ``\ADDR``, a data input -``\DATA``, with the width of the ``\DATA`` port equal to ``\WIDTH`` parameter -times ``\WORDS`` parameter, and a bit enable mask input ``\EN`` with width equal -to ``\WIDTH`` parameter. All three of the inputs must resolve to a constant for +The `$meminit_v2` cells have an address input ``\ADDR``, a data input ``\DATA``, +with the width of the ``\DATA`` port equal to ``\WIDTH`` parameter times +``\WORDS`` parameter, and a bit enable mask input ``\EN`` with width equal to +``\WIDTH`` parameter. All three of the inputs must resolve to a constant for synthesis to succeed. ``\MEMID`` @@ -472,19 +467,18 @@ synthesis to succeed. initialization conflict. The HDL frontend models a memory using ``RTLIL::Memory`` objects and -asynchronous `$memrd_v2` and `$memwr_v2` cells. The `memory` pass -(i.e. its various sub-passes) migrates `$dff` cells into the `$memrd_v2` and -`$memwr_v2` cells making them synchronous, then converts them to a single -`$mem_v2` cell and (optionally) maps this cell type to `$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 `$mem_v2` cell -is left in the design. +asynchronous `$memrd_v2` and `$memwr_v2` cells. The `memory` pass (i.e. its +various sub-passes) migrates `$dff` cells into the `$memrd_v2` and `$memwr_v2` +cells making them synchronous, then converts them to a single `$mem_v2` cell and +(optionally) maps this cell type to `$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 `$mem_v2` cell is left in the design. The `$mem_v2` cell provides the following parameters: ``\MEMID`` - The name of the original ``RTLIL::Memory`` object that became this - `$mem_v2` cell. + The name of the original ``RTLIL::Memory`` object that became this `$mem_v2` + cell. ``\SIZE`` The number of words in the memory. @@ -502,19 +496,19 @@ The `$mem_v2` cell provides the following parameters: The number of read ports on this memory cell. ``\RD_WIDE_CONTINUATION`` - This parameter is ``\RD_PORTS`` bits wide, containing a bitmask of - "wide continuation" read ports. Such ports are used to represent the - extra data bits of wide ports in the combined cell, and must have all - control signals identical with the preceding port, except for address, - which must have the proper sub-cell address encoded in the low bits. + This parameter is ``\RD_PORTS`` bits wide, containing a bitmask of "wide + continuation" read ports. Such ports are used to represent the extra data + bits of wide ports in the combined cell, and must have all control signals + identical with the preceding port, except for address, which must have the + proper sub-cell address encoded in the low bits. ``\RD_CLK_ENABLE`` - This parameter is ``\RD_PORTS`` bits wide, containing a clock enable bit - for each read port. + This parameter is ``\RD_PORTS`` bits wide, containing a clock enable bit for + each read port. ``\RD_CLK_POLARITY`` - This parameter is ``\RD_PORTS`` bits wide, containing a clock polarity - bit for each read port. + This parameter is ``\RD_PORTS`` bits wide, containing a clock polarity bit + for each read port. ``\RD_TRANSPARENCY_MASK`` This parameter is ``\RD_PORTS*\WR_PORTS`` bits wide, containing a @@ -523,62 +517,62 @@ The `$mem_v2` cell provides the following parameters: ``\RD_COLLISION_X_MASK`` This parameter is ``\RD_PORTS*\WR_PORTS`` bits wide, containing a - concatenation of all ``\COLLISION_X_MASK`` values of the original - `$memrd_v2` cells. + concatenation of all ``\COLLISION_X_MASK`` values of the original `$memrd_v2` + cells. ``\RD_CE_OVER_SRST`` - This parameter is ``\RD_PORTS`` bits wide, determining relative - synchronous reset and enable priority for each read port. + This parameter is ``\RD_PORTS`` bits wide, determining relative synchronous + reset and enable priority for each read port. ``\RD_INIT_VALUE`` This parameter is ``\RD_PORTS*\WIDTH`` bits wide, containing the initial value for each synchronous read port. ``\RD_ARST_VALUE`` - This parameter is ``\RD_PORTS*\WIDTH`` bits wide, containing the - asynchronous reset value for each synchronous read port. + This parameter is ``\RD_PORTS*\WIDTH`` bits wide, containing the asynchronous + reset value for each synchronous read port. ``\RD_SRST_VALUE`` - This parameter is ``\RD_PORTS*\WIDTH`` bits wide, containing the - synchronous reset value for each synchronous read port. + This parameter is ``\RD_PORTS*\WIDTH`` bits wide, containing the synchronous + reset value for each synchronous read port. ``\WR_PORTS`` The number of write ports on this memory cell. ``\WR_WIDE_CONTINUATION`` - This parameter is ``\WR_PORTS`` bits wide, containing a bitmask of - "wide continuation" write ports. + This parameter is ``\WR_PORTS`` bits wide, containing a bitmask of "wide + continuation" write ports. ``\WR_CLK_ENABLE`` - This parameter is ``\WR_PORTS`` bits wide, containing a clock enable bit - for each write port. + This parameter is ``\WR_PORTS`` bits wide, containing a clock enable bit for + each write port. ``\WR_CLK_POLARITY`` - This parameter is ``\WR_PORTS`` bits wide, containing a clock polarity - bit for each write port. + This parameter is ``\WR_PORTS`` bits wide, containing a clock polarity bit + for each write port. ``\WR_PRIORITY_MASK`` This parameter is ``\WR_PORTS*\WR_PORTS`` bits wide, containing a - concatenation of all ``\PRIORITY_MASK`` values of the original - `$memwr_v2` cells. + concatenation of all ``\PRIORITY_MASK`` values of the original `$memwr_v2` + cells. The `$mem_v2` cell has the following ports: ``\RD_CLK`` - This input is ``\RD_PORTS`` bits wide, containing all clock signals for - the read ports. + This input is ``\RD_PORTS`` bits wide, containing all clock signals for the + read ports. ``\RD_EN`` - This input is ``\RD_PORTS`` bits wide, containing all enable signals for - the read ports. + This input is ``\RD_PORTS`` bits wide, containing all enable signals for the + read ports. ``\RD_ADDR`` - This input is ``\RD_PORTS*\ABITS`` bits wide, containing all address - signals for the read ports. + This input is ``\RD_PORTS*\ABITS`` bits wide, containing all address signals + for the read ports. ``\RD_DATA`` - This output is ``\RD_PORTS*\WIDTH`` bits wide, containing all data - signals for the read ports. + This output is ``\RD_PORTS*\WIDTH`` bits wide, containing all data signals + for the read ports. ``\RD_ARST`` This input is ``\RD_PORTS`` bits wide, containing all asynchronous reset @@ -593,26 +587,25 @@ The `$mem_v2` cell has the following ports: the write ports. ``\WR_EN`` - This input is ``\WR_PORTS*\WIDTH`` bits wide, containing all enable - signals for the write ports. + This input is ``\WR_PORTS*\WIDTH`` bits wide, containing all enable signals + for the write ports. ``\WR_ADDR`` - This input is ``\WR_PORTS*\ABITS`` bits wide, containing all address - signals for the write ports. + This input is ``\WR_PORTS*\ABITS`` bits wide, containing all address signals + for the write ports. ``\WR_DATA`` - This input is ``\WR_PORTS*\WIDTH`` bits wide, containing all data - signals for the write ports. - -The `memory_collect` pass can be used to convert discrete -`$memrd_v2`, `$memwr_v2`, and `$meminit_v2` cells belonging to the same -memory to a single `$mem_v2` cell, whereas the `memory_unpack` pass -performs the inverse operation. The `memory_dff` pass can combine -asynchronous memory ports that are fed by or feeding registers into synchronous -memory ports. The `memory_bram` pass can be used to recognize -`$mem_v2` cells that can be implemented with a block RAM resource on an FPGA. -The `memory_map` pass can be used to implement `$mem_v2` cells as -basic logic: word-wide DFFs and address decoders. + This input is ``\WR_PORTS*\WIDTH`` bits wide, containing all data signals for + the write ports. + +The `memory_collect` pass can be used to convert discrete `$memrd_v2`, +`$memwr_v2`, and `$meminit_v2` cells belonging to the same memory to a single +`$mem_v2` cell, whereas the `memory_unpack` pass performs the inverse operation. +The `memory_dff` pass can combine asynchronous memory ports that are fed by or +feeding registers into synchronous memory ports. The `memory_bram` pass can be +used to recognize `$mem_v2` cells that can be implemented with a block RAM +resource on an FPGA. The `memory_map` pass can be used to implement `$mem_v2` +cells as basic logic: word-wide DFFs and address decoders. Finite state machines ~~~~~~~~~~~~~~~~~~~~~ @@ -622,15 +615,17 @@ Add a brief description of the `$fsm` cell type. Coarse arithmetics ~~~~~~~~~~~~~~~~~~~~~ -The `$macc` cell type represents a generalized multiply and accumulate operation. The cell is purely combinational. It outputs the result of summing up a sequence of products and other injected summands. +The `$macc` cell type represents a generalized multiply and accumulate +operation. The cell is purely combinational. It outputs the result of summing up +a sequence of products and other injected summands. .. code-block:: Y = 0 +- a0factor1 * a0factor2 +- a1factor1 * a1factor2 +- ... + B[0] + B[1] + ... -The A port consists of concatenated pairs of multiplier inputs ("factors"). -A zero length factor2 acts as a constant 1, turning factor1 into a simple summand. +The A port consists of concatenated pairs of multiplier inputs ("factors"). A +zero length factor2 acts as a constant 1, turning factor1 into a simple summand. In this pseudocode, ``u(foo)`` means an unsigned int that's foo bits long. @@ -644,8 +639,8 @@ In this pseudocode, ``u(foo)`` means an unsigned int that's foo bits long. ... }; -The cell's ``CONFIG`` parameter determines the layout of cell port ``A``. -The CONFIG parameter carries the following information: +The cell's ``CONFIG`` parameter determines the layout of cell port ``A``. The +CONFIG parameter carries the following information: .. code-block:: @@ -714,8 +709,8 @@ Formal verification cells ~~~~~~~~~~~~~~~~~~~~~~~~~ Add information about `$check`, `$assert`, `$assume`, `$live`, `$fair`, -`$cover`, `$equiv`, `$initstate`, `$anyconst`, `$anyseq`, -`$anyinit`, `$allconst`, `$allseq` cells. +`$cover`, `$equiv`, `$initstate`, `$anyconst`, `$anyseq`, `$anyinit`, +`$allconst`, `$allseq` cells. Add information about `$ff` and `$_FF_` cells. @@ -733,8 +728,8 @@ has the following parameters: The width (in bits) of the signal on the ``\ARGS`` port. ``\TRG_ENABLE`` - True if triggered on specific signals defined in ``\TRG``; false if - triggered whenever ``\ARGS`` or ``\EN`` change and ``\EN`` is 1. + True if triggered on specific signals defined in ``\TRG``; false if triggered + whenever ``\ARGS`` or ``\EN`` change and ``\EN`` is 1. If ``\TRG_ENABLE`` is true, the following parameters also apply: @@ -792,12 +787,13 @@ width\ *?* (optional) The number of characters wide to pad to. base - * ``b`` for base-2 integers (binary) - * ``o`` for base-8 integers (octal) - * ``d`` for base-10 integers (decimal) - * ``h`` for base-16 integers (hexadecimal) - * ``c`` for ASCII characters/strings - * ``t`` and ``r`` for simulation time (corresponding to :verilog:`$time` and :verilog:`$realtime`) + * ``b`` for base-2 integers (binary) + * ``o`` for base-8 integers (octal) + * ``d`` for base-10 integers (decimal) + * ``h`` for base-16 integers (hexadecimal) + * ``c`` for ASCII characters/strings + * ``t`` and ``r`` for simulation time (corresponding to :verilog:`$time` and + :verilog:`$realtime`) For integers, this item may follow: @@ -1042,14 +1038,13 @@ Tables :numref:`%s `, :numref:`%s `, :numref:`%s `, :numref:`%s ` and :numref:`%s ` list all cell types used for gate level logic. The cell types `$_BUF_`, `$_NOT_`, -`$_AND_`, `$_NAND_`, `$_ANDNOT_`, `$_OR_`, `$_NOR_`, `$_ORNOT_`, -`$_XOR_`, `$_XNOR_`, `$_AOI3_`, `$_OAI3_`, `$_AOI4_`, `$_OAI4_`, -`$_MUX_`, `$_MUX4_`, `$_MUX8_`, `$_MUX16_` and `$_NMUX_` are used to -model combinatorial logic. The cell type `$_TBUF_` is used to model tristate -logic. +`$_AND_`, `$_NAND_`, `$_ANDNOT_`, `$_OR_`, `$_NOR_`, `$_ORNOT_`, `$_XOR_`, +`$_XNOR_`, `$_AOI3_`, `$_OAI3_`, `$_AOI4_`, `$_OAI4_`, `$_MUX_`, `$_MUX4_`, +`$_MUX8_`, `$_MUX16_` and `$_NMUX_` are used to model combinatorial logic. The +cell type `$_TBUF_` is used to model tristate logic. -The `$_MUX4_`, `$_MUX8_` and `$_MUX16_` cells are used to model wide -muxes, and correspond to the following Verilog code: +The `$_MUX4_`, `$_MUX8_` and `$_MUX16_` cells are used to model wide muxes, and +correspond to the following Verilog code: .. code-block:: verilog :force: @@ -1114,8 +1109,8 @@ following Verilog code template: The cell types ``$_DFFE_[NP][NP][01][NP]_`` implement d-type flip-flops with asynchronous reset and enable. The values in the table for these cell types -relate to the following Verilog code template, where ``RST_EDGE`` is -``posedge`` if ``RST_LVL`` if ``1``, and ``negedge`` otherwise. +relate to the following Verilog code template, where ``RST_EDGE`` is ``posedge`` +if ``RST_LVL`` if ``1``, and ``negedge`` otherwise. .. code-block:: verilog :force: @@ -1156,8 +1151,8 @@ in the table for these cell types relate to the following Verilog code template: The cell types ``$_DFFSR_[NP][NP][NP]_`` implement d-type flip-flops with asynchronous set and reset. The values in the table for these cell types relate to the following Verilog code template, where ``RST_EDGE`` is ``posedge`` if -``RST_LVL`` if ``1``, ``negedge`` otherwise, and ``SET_EDGE`` is ``posedge`` -if ``SET_LVL`` if ``1``, ``negedge`` otherwise. +``RST_LVL`` if ``1``, ``negedge`` otherwise, and ``SET_EDGE`` is ``posedge`` if +``SET_LVL`` if ``1``, ``negedge`` otherwise. .. code-block:: verilog :force: @@ -1173,8 +1168,8 @@ if ``SET_LVL`` if ``1``, ``negedge`` otherwise. The cell types ``$_DFFSRE_[NP][NP][NP][NP]_`` implement d-type flip-flops with asynchronous set and reset and enable. The values in the table for these cell types relate to the following Verilog code template, where ``RST_EDGE`` is -``posedge`` if ``RST_LVL`` if ``1``, ``negedge`` otherwise, and ``SET_EDGE`` -is ``posedge`` if ``SET_LVL`` if ``1``, ``negedge`` otherwise. +``posedge`` if ``RST_LVL`` if ``1``, ``negedge`` otherwise, and ``SET_EDGE`` is +``posedge`` if ``SET_LVL`` if ``1``, ``negedge`` otherwise. .. code-block:: verilog :force: diff --git a/docs/source/yosys_internals/formats/rtlil_rep.rst b/docs/source/yosys_internals/formats/rtlil_rep.rst index fec970532af..b0cbfe3a512 100644 --- a/docs/source/yosys_internals/formats/rtlil_rep.rst +++ b/docs/source/yosys_internals/formats/rtlil_rep.rst @@ -76,11 +76,10 @@ This has three advantages: - Second, the information about which identifiers were originally provided by the user is always available which can help guide some optimizations. For - example, `opt_clean` tries to preserve signals with a user-provided - name but doesn't hesitate to delete signals that have auto-generated names - when they just duplicate other signals. Note that this can be overridden - with the ``-purge`` option to also delete internal nets with user-provided - names. + example, `opt_clean` tries to preserve signals with a user-provided name but + doesn't hesitate to delete signals that have auto-generated names when they + just duplicate other signals. Note that this can be overridden with the + ``-purge`` option to also delete internal nets with user-provided names. - Third, the delicate job of finding suitable auto-generated public visible names is deferred to one central location. Internally auto-generated names @@ -204,8 +203,8 @@ A "signal" is everything that can be applied to a cell port. I.e. - | Concatenations of the above | 1em For example: ``{16'd1337, mywire[15:8]}`` -The ``RTLIL::SigSpec`` data type is used to represent signals. The ``RTLIL::Cell`` -object contains one ``RTLIL::SigSpec`` for each cell port. +The ``RTLIL::SigSpec`` data type is used to represent signals. The +``RTLIL::Cell`` object contains one ``RTLIL::SigSpec`` for each cell port. In addition, connections between wires are represented using a pair of ``RTLIL::SigSpec`` objects. Such pairs are needed in different locations. @@ -234,9 +233,9 @@ control logic of the behavioural code. Let's consider a simple example: q <= d; endmodule -In this example there is no data path and therefore the ``RTLIL::Module`` generated -by the frontend only contains a few ``RTLIL::Wire`` objects and an ``RTLIL::Process`` . -The ``RTLIL::Process`` in RTLIL syntax: +In this example there is no data path and therefore the ``RTLIL::Module`` +generated by the frontend only contains a few ``RTLIL::Wire`` objects and an +``RTLIL::Process``. The ``RTLIL::Process`` in RTLIL syntax: .. code:: RTLIL :number-lines: @@ -320,8 +319,8 @@ trees before further processing them. One of the first actions performed on a design in RTLIL representation in most synthesis scripts is identifying asynchronous resets. This is usually done using -the `proc_arst` pass. This pass transforms the above example to the -following ``RTLIL::Process``: +the `proc_arst` pass. This pass transforms the above example to the following +``RTLIL::Process``: .. code:: RTLIL :number-lines: @@ -340,9 +339,9 @@ following ``RTLIL::Process``: end This pass has transformed the outer ``RTLIL::SwitchRule`` into a modified -``RTLIL::SyncRule`` object for the ``\reset`` signal. Further processing converts the -``RTLIL::Process`` into e.g. a d-type flip-flop with asynchronous reset and a -multiplexer for the enable signal: +``RTLIL::SyncRule`` object for the ``\reset`` signal. Further processing +converts the ``RTLIL::Process`` into e.g. a d-type flip-flop with asynchronous +reset and a multiplexer for the enable signal: .. code:: RTLIL :number-lines: @@ -365,11 +364,11 @@ multiplexer for the enable signal: connect \Y $0\q[0:0] end -Different combinations of passes may yield different results. Note that -`$adff` and `$mux` are internal cell types that still need to be mapped to -cell types from the target cell library. +Different combinations of passes may yield different results. Note that `$adff` +and `$mux` are internal cell types that still need to be mapped to cell types +from the target cell library. -Some passes refuse to operate on modules that still contain ``RTLIL::Process`` +Some passes refuse to operate on modules that still contain ``RTLIL::Process`` objects as the presence of these objects in a module increases the complexity. Therefore the passes to translate processes to a netlist of cells are usually called early in a synthesis script. The proc pass calls a series of other passes @@ -389,9 +388,9 @@ A memory object has the following properties: - The width of an addressable word - The size of the memory in number of words -All read accesses to the memory are transformed to `$memrd` cells and all -write accesses to `$memwr` cells by the language frontend. These cells consist -of independent read- and write-ports to the memory. Memory initialization is +All read accesses to the memory are transformed to `$memrd` cells and all write +accesses to `$memwr` cells by the language frontend. These cells consist of +independent read- and write-ports to the memory. Memory initialization is transformed to `$meminit` cells by the language frontend. The ``\MEMID`` parameter on these cells is used to link them together and to the ``RTLIL::Memory`` object they belong to. @@ -402,8 +401,8 @@ the separate `$memrd` and `$memwr` cells can be consolidated using resource sharing. As resource sharing is a non-trivial optimization problem where different synthesis tasks can have different requirements it lends itself to do the optimisation in separate passes and merge the ``RTLIL::Memory`` objects and -`$memrd` and `$memwr` cells to multiport memory blocks after resource -sharing is completed. +`$memrd` and `$memwr` cells to multiport memory blocks after resource sharing is +completed. The memory pass performs this conversion and can (depending on the options passed to it) transform the memories directly to d-type flip-flops and address diff --git a/docs/source/yosys_internals/techmap.rst b/docs/source/yosys_internals/techmap.rst index f894394bb04..21b09c9032b 100644 --- a/docs/source/yosys_internals/techmap.rst +++ b/docs/source/yosys_internals/techmap.rst @@ -1,8 +1,8 @@ Techmap by example ------------------ -As a quick recap, the `techmap` command replaces cells in the design -with implementations given as Verilog code (called "map files"). It can replace +As a quick recap, the `techmap` command replaces cells in the design with +implementations given as Verilog code (called "map files"). It can replace Yosys' internal cell types (such as `$or`) as well as user-defined cell types. - Verilog parameters are used extensively to customize the internal cell types. @@ -94,8 +94,8 @@ Scripting in map modules .. note:: PROTIP: - Commands such as `shell`, ``show -pause``, and `dump` can - be used in the ``_TECHMAP_DO_*`` scripts for debugging map modules. + Commands such as `shell`, ``show -pause``, and `dump` can be used in the + ``_TECHMAP_DO_*`` scripts for debugging map modules. Example: From 21747c468c20fb743cbec6354e941d8ca18bf532 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Thu, 16 May 2024 11:32:14 +1200 Subject: [PATCH 17/68] Docs: Improve cell_help usage - Drop `cell_code` and instead map code lookups to the `cell_help` dict. - Add helper functions to struct for checking and getting the right cell. - Add `CellType` for cell to `write_cell_rst` function declaration in preparation for use in future. - Iterate over `yosys_celltypes.cell_types` when exporting cell rst files, reporting errors for any cells defined in `cell_types` but not `cell_help_messages`. --- kernel/register.cc | 65 +++++++++++++++++++++++-------------- techlibs/common/cellhelp.py | 8 ++--- 2 files changed, 43 insertions(+), 30 deletions(-) diff --git a/kernel/register.cc b/kernel/register.cc index b16a6f85268..9fbd5902093 100644 --- a/kernel/register.cc +++ b/kernel/register.cc @@ -766,15 +766,23 @@ struct SimHelper { string ver; }; +static bool is_code_getter(string name) { + return *(--(name.end())) == '+'; +} + +static string get_cell_name(string name) { + return is_code_getter(name) ? name.substr(0, name.length()-1) : name; +} + static struct CellHelpMessages { - dict cell_help, cell_code; + dict cell_help; CellHelpMessages() { - SimHelper tempCell; #include "techlibs/common/simlib_help.inc" #include "techlibs/common/simcells_help.inc" cell_help.sort(); - cell_code.sort(); } + bool contains(string name) { return cell_help.count(get_cell_name(name)) > 0; } + SimHelper get(string name) { return cell_help[get_cell_name(name)]; } } cell_help_messages; struct HelpPass : public Pass { @@ -884,7 +892,7 @@ struct HelpPass : public Pass { } fclose(f); } - void write_cell_rst(Yosys::SimHelper cell) + void write_cell_rst(Yosys::SimHelper cell, Yosys::CellType) { // open FILE *f = fopen(stringf("docs/source/cell/%s.rst", cell.filesafe_name().c_str()).c_str(), "wt"); @@ -985,9 +993,20 @@ struct HelpPass : public Pass { write_cmd_rst(it.first, it.second->short_help, buf.str()); } } + // this option is also undocumented as it is for internal use only else if (args[1] == "-write-rst-cells-manual") { - for (auto &it : cell_help_messages.cell_help) { - write_cell_rst(it.second); + bool raise_error = false; + for (auto &it : yosys_celltypes.cell_types) { + auto name = it.first.str(); + if (cell_help_messages.contains(name)) { + write_cell_rst(cell_help_messages.get(name), it.second); + } else { + log("ERROR: Missing cell help for cell '%s'.\n", name.c_str()); + raise_error |= true; + } + } + if (raise_error) { + log_error("One or more cells defined in celltypes.h are missing help documentation.\n"); } } else if (pass_register.count(args[1])) { @@ -998,29 +1017,27 @@ struct HelpPass : public Pass { log("\n"); } } - else if (cell_help_messages.cell_help.count(args[1])) { - SimHelper help_cell = cell_help_messages.cell_help.at(args[1]); - if (help_cell.ver == "2" || help_cell.ver == "2a") { - log("\n %s %s\n\n", help_cell.name.c_str(), help_cell.ports.c_str()); - if (help_cell.title != "") log("%s\n", help_cell.title.c_str()); - std::stringstream ss; - ss << help_cell.desc; - for (std::string line; std::getline(ss, line, '\n');) { - if (line != "::") log("%s\n", line.c_str()); - } - log("Run 'help %s+' to display the Verilog model for this cell type.\n", args[1].c_str()); - log("\n"); + else if (cell_help_messages.contains(args[1])) { + auto help_cell = cell_help_messages.get(args[1]); + if (is_code_getter(args[1])) { + log("\n"); + log("%s\n", help_cell.code.c_str()); } else { - log("%s\n", help_cell.desc.c_str()); + if (help_cell.ver == "2" || help_cell.ver == "2a") { + log("\n %s %s\n\n", help_cell.name.c_str(), help_cell.ports.c_str()); + if (help_cell.title != "") log("%s\n", help_cell.title.c_str()); + std::stringstream ss; + ss << help_cell.desc; + for (std::string line; std::getline(ss, line, '\n');) { + if (line != "::") log("%s\n", line.c_str()); + } + } else { + log("%s\n", help_cell.desc.c_str()); + } log("Run 'help %s+' to display the Verilog model for this cell type.\n", args[1].c_str()); log("\n"); } } - else if (cell_help_messages.cell_code.count(args[1])) { - SimHelper help_cell = cell_help_messages.cell_code.at(args[1]); - log("\n"); - log("%s\n", help_cell.code.c_str()); - } else log("No such command or cell type: %s\n", args[1].c_str()); return; diff --git a/techlibs/common/cellhelp.py b/techlibs/common/cellhelp.py index a975c31e5b3..0cfb2052fd1 100644 --- a/techlibs/common/cellhelp.py +++ b/techlibs/common/cellhelp.py @@ -22,18 +22,14 @@ def __str__(self) -> str: "name", "title", "ports", "source", "desc", "code", "ver", ] # generate C++ struct - val = "tempCell = {\n" + val = f"cell_help[{json.dumps(self.name)}] = " + val += "{\n" for field in printed_fields: field_val = getattr(self, field) if isinstance(field_val, list): field_val = "\n".join(field_val) val += f' {json.dumps(field_val)},\n' val += "};\n" - - # map name to struct - val += f'cell_help[{json.dumps(self.name)}] = tempCell;' - val += "\n" - val += f'cell_code[{json.dumps(self.name + "+")}] = tempCell;' return val def simcells_reparse(cell: SimHelper): From 4c9c4c1419fbddd0333afca44087093cfebcf213 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Thu, 16 May 2024 12:15:57 +1200 Subject: [PATCH 18/68] celltypes.h: Add extra properties --- kernel/celltypes.h | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/kernel/celltypes.h b/kernel/celltypes.h index 6aebabc19b5..3167a9addf9 100644 --- a/kernel/celltypes.h +++ b/kernel/celltypes.h @@ -29,6 +29,8 @@ struct CellType RTLIL::IdString type; pool inputs, outputs; bool is_evaluable; + bool is_combinatorial; + bool is_synthesizable; }; struct CellTypes @@ -56,9 +58,9 @@ struct CellTypes setup_stdcells_mem(); } - void setup_type(RTLIL::IdString type, const pool &inputs, const pool &outputs, bool is_evaluable = false) + void setup_type(RTLIL::IdString type, const pool &inputs, const pool &outputs, bool is_evaluable = false, bool is_combinatorial = false, bool is_synthesizable = false) { - CellType ct = {type, inputs, outputs, is_evaluable}; + CellType ct = {type, inputs, outputs, is_evaluable, is_combinatorial, is_synthesizable}; cell_types[ct.type] = ct; } From 063a6bc2d71085274810556e4f0d0b1dda70b37b Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Thu, 16 May 2024 12:16:24 +1200 Subject: [PATCH 19/68] register.cc: Include properties in docs --- kernel/register.cc | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/kernel/register.cc b/kernel/register.cc index 9fbd5902093..4dfa798450c 100644 --- a/kernel/register.cc +++ b/kernel/register.cc @@ -892,7 +892,7 @@ struct HelpPass : public Pass { } fclose(f); } - void write_cell_rst(Yosys::SimHelper cell, Yosys::CellType) + void write_cell_rst(Yosys::SimHelper cell, Yosys::CellType ct) { // open FILE *f = fopen(stringf("docs/source/cell/%s.rst", cell.filesafe_name().c_str()).c_str(), "wt"); @@ -919,9 +919,21 @@ struct HelpPass : public Pass { fprintf(f, " %s\n", line.c_str()); } + // properties + fprintf(f, "\nProperties"); + fprintf(f, "\n----------\n\n"); + dict prop_dict = { + {"is_evaluable", ct.is_evaluable}, + {"is_combinatorial", ct.is_combinatorial}, + {"is_synthesizable", ct.is_synthesizable}, + }; + for (auto &it : prop_dict) { + fprintf(f, "- %s: %s\n", it.first.c_str(), it.second ? "true" : "false"); + } + // source code - fprintf(f, "\nSimulation model (Verilog)\n"); - fprintf(f, "--------------------------\n\n"); + fprintf(f, "\nSimulation model (Verilog)"); + fprintf(f, "\n--------------------------\n\n"); fprintf(f, ".. code-block:: verilog\n"); fprintf(f, " :caption: %s\n\n", cell.source.c_str()); std::stringstream ss2; From 06e5e18371bce001710b7c7183f481cabc405b24 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Thu, 16 May 2024 12:17:03 +1200 Subject: [PATCH 20/68] simlib.v: Autolink referenced cells in alu --- techlibs/common/simlib.v | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/techlibs/common/simlib.v b/techlibs/common/simlib.v index 96f143c2ab0..6bcace49891 100644 --- a/techlibs/common/simlib.v +++ b/techlibs/common/simlib.v @@ -626,8 +626,8 @@ endmodule //- A building block supporting both binary addition/subtraction operations, and //- indirectly, comparison operations. //- Typically created by the `alumacc` pass, which transforms: -//- $add, $sub, $lt, $le, $ge, $gt, $eq, $eqx, $ne, $nex -//- cells into this $alu cell. +//- `$add`, `$sub`, `$lt`, `$le`, `$ge`, `$gt`, `$eq`, `$eqx`, `$ne`, `$nex` +//- cells into this `$alu` cell. //- module \$alu (A, B, CI, BI, X, Y, CO); From e5f54dd7cd2c449360dbb787ad10dd10df450638 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Fri, 17 May 2024 17:54:08 +1200 Subject: [PATCH 21/68] Docs: Cell reference as a custom documenter Use autodocs to perform cell reference docs generation instead of generating rst files directly. e.g. ``` .. autocell:: simlib.v:$alu :source: :linenos: ``` --- docs/source/conf.py | 15 +- docs/util/cellref.py | 367 +++++++++++++++++++++++++++++++++++++++++++ docs/util/cmdref.py | 153 +++++++++++++++++- 3 files changed, 526 insertions(+), 9 deletions(-) create mode 100644 docs/util/cellref.py diff --git a/docs/source/conf.py b/docs/source/conf.py index bfabe60e514..9a22d50d346 100644 --- a/docs/source/conf.py +++ b/docs/source/conf.py @@ -100,9 +100,14 @@ sys.path += [os.path.dirname(__file__) + "/../"] extensions.append('util.cmdref') -def setup(sphinx): - from util.RtlilLexer import RtlilLexer - sphinx.add_lexer("RTLIL", RtlilLexer) +# use autodocs +extensions.append('sphinx.ext.autodoc') +extensions.append('util.cellref') - from util.YoscryptLexer import YoscryptLexer - sphinx.add_lexer("yoscrypt", YoscryptLexer) \ No newline at end of file +from sphinx.application import Sphinx +def setup(app: Sphinx) -> None: + from util.RtlilLexer import RtlilLexer + app.add_lexer("RTLIL", RtlilLexer) + + from util.YoscryptLexer import YoscryptLexer + app.add_lexer("yoscrypt", YoscryptLexer) diff --git a/docs/util/cellref.py b/docs/util/cellref.py new file mode 100644 index 00000000000..4deda41dddb --- /dev/null +++ b/docs/util/cellref.py @@ -0,0 +1,367 @@ +#!/usr/bin/env python3 +from __future__ import annotations + +from pathlib import Path +import re + +from typing import Any +from sphinx.application import Sphinx +from sphinx.ext import autodoc +from sphinx.ext.autodoc import Documenter +from sphinx.util import logging + +logger = logging.getLogger(__name__) + +# cell signature +cell_ext_sig_re = re.compile( + r'''^ (?:([\w._/]+):)? # explicit file name + ([\w$._]+?)? # module and/or class name(s) + (?:\.([\w_]+))? # optional: thing name + (::[\w_]+)? # attribute + \s* $ # and nothing more + ''', re.VERBOSE) + +class SimHelper: + name: str = "" + title: str = "" + ports: str = "" + source: str = "" + desc: list[str] + code: list[str] + group: str = "" + ver: str = "1" + + def __init__(self) -> None: + self.desc = [] + +def simcells_reparse(cell: SimHelper): + # cut manual signature + cell.desc = cell.desc[3:] + + # code-block truth table + new_desc = [] + indent = "" + for line in cell.desc: + if line.startswith("Truth table:"): + indent = " " + new_desc.pop() + new_desc.extend(["::", ""]) + new_desc.append(indent + line) + cell.desc = new_desc + + # set version + cell.ver = "2a" + +def load_cell_lib(file: Path): + simHelpers: dict[str, SimHelper] = {} + simHelper = SimHelper() + with open(file, "r") as f: + lines = f.readlines() + + for lineno, line in enumerate(lines, 1): + line = line.rstrip() + # special comments + if line.startswith("//-"): + simHelper.desc.append(line[4:] if len(line) > 4 else "") + elif line.startswith("//* "): + _, key, val = line.split(maxsplit=2) + setattr(simHelper, key, val) + + # code parsing + if line.startswith("module "): + clean_line = line[7:].replace("\\", "").replace(";", "") + simHelper.name, simHelper.ports = clean_line.split(maxsplit=1) + simHelper.code = [] + simHelper.source = f'{file.name}:{lineno}' + elif not line.startswith("endmodule"): + line = " " + line + try: + simHelper.code.append(line.replace("\t", " ")) + except AttributeError: + # no module definition, ignore line + pass + if line.startswith("endmodule"): + if simHelper.ver == "1" and file.name == "simcells.v": + # default simcells parsing + simcells_reparse(simHelper) + if not simHelper.desc: + # no help + simHelper.desc.append("No help message for this cell type found.\n") + elif simHelper.ver == "1" and file.name == "simlib.v" and simHelper.desc[1].startswith(' '): + simHelper.desc.pop(1) + simHelpers[simHelper.name] = simHelper + simHelper = SimHelper() + return simHelpers + +class YosysCellDocumenter(Documenter): + objtype = 'cell' + parsed_libs: dict[Path, dict[str, SimHelper]] = {} + object: SimHelper + + option_spec = { + 'source': autodoc.bool_option, + 'linenos': autodoc.bool_option, + } + + @classmethod + def can_document_member( + cls, + member: Any, + membername: str, + isattr: bool, + parent: Any + ) -> bool: + sourcename = str(member).split(":")[0] + if not sourcename.endswith(".v"): + return False + if membername == "__source": + return False + + def parse_name(self) -> bool: + try: + matched = cell_ext_sig_re.match(self.name) + path, modname, thing, attribute = matched.groups() + except AttributeError: + logger.warning(('invalid signature for auto%s (%r)') % (self.objtype, self.name), + type='cellref') + return False + + if not path: + return False + + self.modname = modname + self.objpath = [path] + self.attribute = attribute + self.fullname = ((self.modname) + (thing or '')) + + return True + + def import_object(self, raiseerror: bool = False) -> bool: + # find cell lib file + objpath = Path('/'.join(self.objpath)) + if not objpath.exists(): + objpath = Path('source') / 'generated' / objpath + + # load cell lib + try: + parsed_lib = self.parsed_libs[objpath] + except KeyError: + parsed_lib = load_cell_lib(objpath) + self.parsed_libs[objpath] = parsed_lib + + # get cell + try: + self.object = parsed_lib[self.modname] + except KeyError: + return False + + self.real_modname = f'{objpath}:{self.modname}' + return True + + def get_sourcename(self) -> str: + return self.objpath + + def format_name(self) -> str: + return self.object.name + + def format_signature(self, **kwargs: Any) -> str: + return f"{self.object.name} {self.object.ports}" + + def add_directive_header(self, sig: str) -> None: + domain = getattr(self, 'domain', self.objtype) + directive = getattr(self, 'directivetype', 'def') + name = self.format_name() + sourcename = self.get_sourcename() + cell = self.object + + # cell definition + self.add_line(f'.. {domain}:{directive}:: {name}', sourcename) + + # options + opt_attrs = ["title", ] + for attr in opt_attrs: + val = getattr(cell, attr, None) + if val: + self.add_line(f' :{attr}: {val}', sourcename) + + if self.options.noindex: + self.add_line(' :noindex:', sourcename) + + def add_content(self, more_content: Any | None) -> None: + # set sourcename and add content from attribute documentation + sourcename = self.get_sourcename() + startline = int(self.object.source.split(":")[1]) + + for i, line in enumerate(self.object.desc, startline): + self.add_line(line, sourcename, i) + + # add additional content (e.g. from document), if present + if more_content: + for line, src in zip(more_content.data, more_content.items): + self.add_line(line, src[0], src[1]) + + def filter_members( + self, + members: list[tuple[str, Any]], + want_all: bool + ) -> list[tuple[str, Any, bool]]: + return [(x[0], x[1], False) for x in members] + + def get_object_members( + self, + want_all: bool + ) -> tuple[bool, list[tuple[str, Any]]]: + ret: list[tuple[str, str]] = [] + + if self.options.source: + ret.append(('__source', self.real_modname)) + + return False, ret + + def document_members(self, all_members: bool = False) -> None: + want_all = (all_members or + self.options.inherited_members) + # find out which members are documentable + members_check_module, members = self.get_object_members(want_all) + + # document non-skipped members + memberdocumenters: list[tuple[Documenter, bool]] = [] + for (mname, member, isattr) in self.filter_members(members, want_all): + classes = [cls for cls in self.documenters.values() + if cls.can_document_member(member, mname, isattr, self)] + if not classes: + # don't know how to document this member + continue + # prefer the documenter with the highest priority + classes.sort(key=lambda cls: cls.priority) + # give explicitly separated module name, so that members + # of inner classes can be documented + full_mname = self.real_modname + '::' + mname + documenter = classes[-1](self.directive, full_mname, self.indent) + memberdocumenters.append((documenter, isattr)) + + member_order = self.options.member_order or self.config.autodoc_member_order + memberdocumenters = self.sort_members(memberdocumenters, member_order) + + for documenter, isattr in memberdocumenters: + documenter.generate( + all_members=True, real_modname=self.real_modname, + check_module=members_check_module and not isattr) + + def generate( + self, + more_content: Any | None = None, + real_modname: str | None = None, + check_module: bool = False, + all_members: bool = False + ) -> None: + if not self.parse_name(): + # need a cell lib to import from + logger.warning( + f"don't know which cell lib to import for autodocumenting {self.name}", + type = 'cellref' + ) + return + + self.import_object() + + # check __module__ of object (for members not given explicitly) + # if check_module: + # if not self.check_module(): + # return + + sourcename = self.get_sourcename() + self.add_line('', sourcename) + + # format the object's signature, if any + try: + sig = self.format_signature() + except Exception as exc: + logger.warning(('error while formatting signature for %s: %s'), + self.fullname, exc, type='cellref') + return + + # generate the directive header and options, if applicable + self.add_directive_header(sig) + self.add_line('', sourcename) + + # e.g. the module directive doesn't have content + self.indent += self.content_indent + + # add all content (from docstrings, attribute docs etc.) + self.add_content(more_content) + + # document members, if possible + self.document_members(all_members) + +class YosysCellSourceDocumenter(YosysCellDocumenter): + objtype = 'cellsource' + priority = 20 + + @classmethod + def can_document_member( + cls, + member: Any, + membername: str, + isattr: bool, + parent: Any + ) -> bool: + sourcename = str(member).split(":")[0] + if not sourcename.endswith(".v"): + return False + if membername != "__source": + return False + if isinstance(parent, YosysCellDocumenter): + return True + return False + + def add_directive_header(self, sig: str) -> None: + domain = getattr(self, 'domain', 'cell') + directive = getattr(self, 'directivetype', 'source') + name = self.format_name() + sourcename = self.get_sourcename() + cell = self.object + + # cell definition + self.add_line(f'.. {domain}:{directive}:: {name}', sourcename) + + if self.options.linenos: + self.add_line(f' :source: {cell.source.split(":")[0]}', sourcename) + else: + self.add_line(f' :source: {cell.source}', sourcename) + self.add_line(f' :language: verilog', sourcename) + + if self.options.linenos: + startline = int(self.object.source.split(":")[1]) + self.add_line(f' :lineno-start: {startline}', sourcename) + + if self.options.noindex: + self.add_line(' :noindex:', sourcename) + + def add_content(self, more_content: Any | None) -> None: + # set sourcename and add content from attribute documentation + sourcename = self.get_sourcename() + startline = int(self.object.source.split(":")[1]) + + for i, line in enumerate(self.object.code, startline-1): + self.add_line(line, sourcename, i) + + # add additional content (e.g. from document), if present + if more_content: + for line, src in zip(more_content.data, more_content.items): + self.add_line(line, src[0], src[1]) + + def get_object_members( + self, + want_all: bool + ) -> tuple[bool, list[tuple[str, Any]]]: + return False, [] + +def setup(app: Sphinx) -> dict[str, Any]: + app.setup_extension('sphinx.ext.autodoc') + app.add_autodocumenter(YosysCellDocumenter) + app.add_autodocumenter(YosysCellSourceDocumenter) + return { + 'version': '1', + 'parallel_read_safe': True, + } diff --git a/docs/util/cmdref.py b/docs/util/cmdref.py index aac8993889f..df1f3fb21ab 100644 --- a/docs/util/cmdref.py +++ b/docs/util/cmdref.py @@ -1,5 +1,9 @@ # based on https://github.com/ofosos/sphinxrecipes/blob/master/sphinxrecipes/sphinxrecipes.py +from __future__ import annotations + +from docutils import nodes +from docutils.nodes import Node, Element from docutils.parsers.rst import directives from docutils.parsers.rst.states import Inliner from sphinx.application import Sphinx @@ -7,24 +11,59 @@ from sphinx.domains.std import StandardDomain from sphinx.roles import XRefRole from sphinx.directives import ObjectDescription +from sphinx.directives.code import container_wrapper from sphinx.util.nodes import make_refnode from sphinx import addnodes -class CommandNode(ObjectDescription): +class TocNode(ObjectDescription): + def _object_hierarchy_parts(self, sig_node: addnodes.desc_signature) -> tuple[str, ...]: + if 'fullname' not in sig_node: + return () + + modname = sig_node.get('module') + fullname = sig_node['fullname'] + + if modname: + return (modname, *fullname.split('::')) + else: + return tuple(fullname.split('::')) + + def _toc_entry_name(self, sig_node: addnodes.desc_signature) -> str: + if not sig_node.get('_toc_parts'): + return '' + + config = self.env.app.config + objtype = sig_node.parent.get('objtype') + if config.add_function_parentheses and objtype in {'function', 'method'}: + parens = '()' + else: + parens = '' + *parents, name = sig_node['_toc_parts'] + if config.toc_object_entries_show_parents == 'domain': + return sig_node.get('fullname', name) + parens + if config.toc_object_entries_show_parents == 'hide': + return name + parens + if config.toc_object_entries_show_parents == 'all': + return '.'.join(parents + [name + parens]) + return '' + +class CommandNode(TocNode): """A custom node that describes a command.""" name = 'cmd' required_arguments = 1 option_spec = { - 'title': directives.unchanged_required, + 'title': directives.unchanged, 'tags': directives.unchanged } def handle_signature(self, sig, signode: addnodes.desc_signature): + fullname = sig + signode['fullname'] = fullname signode += addnodes.desc_addname(text="yosys> help ") signode += addnodes.desc_name(text=sig) - return sig + return fullname def add_target_and_index(self, name_cls, sig, signode): signode['ids'].append(type(self).name + '-' + sig) @@ -32,7 +71,7 @@ def add_target_and_index(self, name_cls, sig, signode): name = "{}.{}.{}".format(self.name, type(self).__name__, sig) tagmap = self.env.domaindata[type(self).name]['obj2tag'] tagmap[name] = list(self.options.get('tags', '').split(' ')) - title = self.options.get('title') + title = self.options.get('title', sig) titlemap = self.env.domaindata[type(self).name]['obj2title'] titlemap[name] = title objs = self.env.domaindata[type(self).name]['objects'] @@ -48,6 +87,111 @@ class CellNode(CommandNode): name = 'cell' +class CellSourceNode(TocNode): + """A custom code block for including cell source.""" + + name = 'cellsource' + + option_spec = { + "source": directives.unchanged_required, + "language": directives.unchanged_required, + 'lineno-start': int, + } + + def handle_signature( + self, + sig, + signode: addnodes.desc_signature + ) -> str: + language = self.options.get('language') + fullname = sig + "::" + language + signode['fullname'] = fullname + signode += addnodes.desc_name(text="Simulation model") + signode += addnodes.desc_sig_space() + signode += addnodes.desc_addname(text=f'({language})') + return fullname + + def add_target_and_index( + self, + name: str, + sig: str, + signode: addnodes.desc_signature + ) -> None: + idx = f'{".".join(self.name.split(":"))}.{sig}' + signode['ids'].append(idx) + + def run(self) -> list[Node]: + """Override run to parse content as a code block""" + if ':' in self.name: + self.domain, self.objtype = self.name.split(':', 1) + else: + self.domain, self.objtype = '', self.name + self.indexnode = addnodes.index(entries=[]) + + node = addnodes.desc() + node.document = self.state.document + source, line = self.get_source_info() + if line is not None: + line -= 1 + self.state.document.note_source(source, line) + node['domain'] = self.domain + # 'desctype' is a backwards compatible attribute + node['objtype'] = node['desctype'] = self.objtype + node['noindex'] = noindex = ('noindex' in self.options) + node['noindexentry'] = ('noindexentry' in self.options) + node['nocontentsentry'] = ('nocontentsentry' in self.options) + if self.domain: + node['classes'].append(self.domain) + node['classes'].append(node['objtype']) + + self.names = [] + signatures = self.get_signatures() + for sig in signatures: + # add a signature node for each signature in the current unit + # and add a reference target for it + signode = addnodes.desc_signature(sig, '') + self.set_source_info(signode) + node.append(signode) + try: + # name can also be a tuple, e.g. (classname, objname); + # this is strictly domain-specific (i.e. no assumptions may + # be made in this base class) + name = self.handle_signature(sig, signode) + except ValueError: + # signature parsing failed + signode.clear() + signode += addnodes.desc_name(sig, sig) + continue # we don't want an index entry here + finally: + # Private attributes for ToC generation. Will be modified or removed + # without notice. + if self.env.app.config.toc_object_entries: + signode['_toc_parts'] = self._object_hierarchy_parts(signode) + signode['_toc_name'] = self._toc_entry_name(signode) + else: + signode['_toc_parts'] = () + signode['_toc_name'] = '' + if name not in self.names: + self.names.append(name) + if not noindex: + # only add target and index entry if this is the first + # description of the object with this name in this desc block + self.add_target_and_index(name, sig, signode) + + # handle code + code = '\n'.join(self.content) + literal: Element = nodes.literal_block(code, code) + if 'lineno-start' in self.options: + literal['linenos'] = True + literal['highlight_args'] = { + 'linenostart': self.options['lineno-start'] + } + literal['classes'] += self.options.get('class', []) + literal['language'] = self.options.get('language') + literal = container_wrapper(self, literal, self.options.get('source')) + + return [self.indexnode, node, literal] + class TagIndex(Index): """A custom directive that creates a tag matrix.""" @@ -223,6 +367,7 @@ class CellDomain(CommandDomain): directives = { 'def': CellNode, + 'source': CellSourceNode, } indices = { From a66e94c5da9bd67c44a540a53455ba4f6384d9f9 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Mon, 20 May 2024 12:29:23 +1200 Subject: [PATCH 22/68] Docs: Switch to furo-ys --- docs/source/_static/favico.png | Bin 33435 -> 0 bytes docs/source/_static/yosyshq.css | 40 ---------------------------- docs/source/_templates/page.html | 44 ------------------------------- docs/source/conf.py | 30 +++------------------ docs/source/requirements.txt | 2 +- 5 files changed, 4 insertions(+), 112 deletions(-) delete mode 100644 docs/source/_static/favico.png delete mode 100644 docs/source/_static/yosyshq.css delete mode 100644 docs/source/_templates/page.html diff --git a/docs/source/_static/favico.png b/docs/source/_static/favico.png deleted file mode 100644 index 3f5afba76569d0610c2f7efead58417c4c9ab050..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 33435 zcmb4rcRbbY|Nq-TN+OYL#a#%=D0?P~P!uQgWTYq~dmpLDOt!3&RMsg(=823lBZ_R< zdvAWP_i=wdpYOlF9*_IJJJ)<&ukn11>w4c$uWG3sqGqK=5aiJ1ODZ}DLP0?P*}o53 zCQsxw!+$6ol`mi44}ZM&TLdD=apba!(sj4QsUFP`qq{DrMjW}{#vhSlef*C(Vi+US zg*WJ^p|@~H$oD1wApCfGh30B!{k+-ff_6IFj;1{B0+G_Q_QCk+&|~jzx?Abli3)A- z-ZXK$wOoY7`(Yw${-LZg_Y_HcZuMGSUv$w!>0^+^BCjv^V2Q-c;=SS$Z1nmo>ADcN zS=XjxWI){i#~-`r>E!6}o)0&BQqDURA7!zL7YRPKV=>zn+9!|{-2R4$f$rYBXL zKPMito9Ws9Rwbq8A81cnz{3U|AZDvpvvQ+CFH&0}Y(GqXi4urUj<<4HF6#~p)E-$~ z?)OyP4}3`F?RfA1BUCnL)X>N~SIWkx*w=M2@1ocJjm86lup!pLrv1y92m7oFr@lic zhyG~9yn_lKAx?%D#Esw{-@oo@7;)38#*L+KHn&NBt)O{!XKm8bOL(JdZ@$uG`;ObQ z4=-5qEPeX^J#NG7w+Xf=T37&S_@!FlYb6<&W*MtbPanTN|FMEMvw8ms=*kLQw)S1w z`q^G|=ULuBV_AuUJ64=rpqkX_)NSB=wm7-3yD228^(HrWg4YI#E;gP=Ftz0t>^kMa z=^GKB&6k_}ZMyXUR)`us&)D11k{sHgaGLT{VybNIy?W#9S+sj|L{LiO9E3&Rr011t z-u7XnPl;~&Vomsp3QpQ0udB~ibfSSdx@kfF|A@9pX;sRP5=L+k^f*Fn|2lB6{4tga zeSnH^P+NU8b#scu{FpykGun24=anq(#Wp=S!E$4Kf7U)qCYYH2J1^o(oB#RQ5|7M~ zagPFpGaUXix;PMyqQ?EHsdkaTo-BUa( zs$QG=Cy}%lQzz_|J34<%;F`%rmD?c_nVUUqzOQdEVqv?MBf=}jmNi9AF`vKd)^~qC zvPT3FF?7?eztoA+=InVW5OZ9OJY`pw(zom3So>pfh)#?n+h<|H+axtCY0 zaDO46i#OKb;tSgT>`!8-#O%pujq2wUL=`XTv#rvS!&eCxU$s0T7(jH8H-zaI5sWqb}}) zqJAmsIrAw0Qtt;syMuEh86|3w9m~lGuXJgVADk)8CGzxXc$?cr263f zpz$dfRH}EBer#+!S9Fu21Rnt#XxCg)wEghGv%*j&VAK7VrNs%S%xtoy=Q_hyb#NaJ z$Lq6md5s?Pl{b)V5T>3pjs_6tZj}CFn}vDEGgwZ|3B0ADMa?}x z+}I{1Pkut&i?qvfO?=|=Yo}Ov_7?fw-PzaJu;SHwQ_26%*5+_FBetQj?N;#j%-B-N z&}C3dbt^ELVk<{0UkTAq8lza}c#ZPIAzIgPA`+SwH>9f!EkhD)-0j^aZH=YD-L`Oi z&pi1(j+N){eORg*)J_#_Ic)X&?NMNpDJr3HK7fvr``0&Jqx9=7L!K4FT3l61u3;Xx zuV_D6e@r^Qj;P0U-w}EU{9-*2fumo z%^ue_o(e_3>S(zQLT^xrZSTVB_N7}Ai(p8O1=ptU^XGoIUU;XA-NH~Z>Bm^DUmK^< zU%2;rZp>cCW}OU4ttCOib(5p99c6O|KRO}B(;ykGoMF?bCOGM$r^1G*!g^$@2(W&* z3-IfOtXy4=R%}+nf3RPA-}C?lll}wIkap`DF;_Y}pNXfS{!4WLh1Ls8$qVo0Lg*Ky zVf*}t5-K!io2c5Xn2{mG3BycURf&bQ<6<@Gd2^zmV(Na?=^P|wRv*O%hID>AOE*=G zLGbM^JmGZQRhv68-$Fk8+3y~Y3D)o|wjT1&t&e+h1a{Nw7-`zcS$JOtTZvLK#dfIZ zrHcs~)$rvE9}6g)m~OoW^sjgR?#$#dFL9#nt!6&ar;Bso4~X<&^-iE~?)G-dE7z5V zD9PUWMf;A+?U|^iFC{EIe=Vs6&sa&0^;~OW|9fA85rZfeqP|sR|LmkpCG!bkK0?v! zHz{gTR3Em-sBi1yS?-Ytze%2xab7oWm{m7_i){Mm5);f(z@}^I#tq-lvIr?*n_c zw765jV-kfmW!JLSpadaS=Zs2}L=1R)s+}7U;{%Gv=Jd)qk`26s&DpDDuL7?XW$w>R z&E9^4d0iDkf8-@`@FA<3gzvSQOXvpEc{iu+)M{MD*^QD!lmR*a{CLfop7z4-%~#;P zUgz7DPiBX0*^TIH_Fuy}*z#WR#g(=NADPrEBdPvU=WSc%?o%MspHumeB!(D{5{eO|@thLg<72>vf0x zk7b~nr+0y&hSGT6)sGUX^Z|*T37!8^e+|_hoqN|kWnfWnSX9HW+Eb2;Yl(5_Bg$IB zRfrh`scyzLeHmoonG&XCnspXszn(7Ul#D71lNrc|!=hUt$$$8)>TgqO!KRn<0adbm zfG@Zl@D11gj_0sZZB{eiQs5`JWmH|3J0#)O5RT3r8S(Hjzw1c{%ksjq=h?Bn@^)f~w9SYC;S_2=HB zL9(c;#%O9%2>nU`CfF3`MM$+e*-?h#L+YV_S(iRtnj}(Leib*r@7TncnU)8@nt;}m@0lIU zUsr|<3ob?jsx(0$REr<|_hPd;R+7KYL2P6FNnK z;L_0`FXodYOZ*ugLuYEia&s?2wWz8{gFkqaGaO(yOt&ETY`P+Y`^;|sNI=`~q6#zD z)T59e-_Fi*Xj<34BSWzKFWR^7M&7zBqi+^sU%*cY+&|=>6d@wVGNLrjjJhi@4!#Aa zU%di34cC9D>*DC?Yp7&SntQk{w)LP)#c|sH{ZOXgaPf9S$9wXNV?jE&TV90VeILBt zCUbZ?5X7nLc0mOMx9N@qY1^+Knm-As`#qljl7l)P)Ib5!jGmO~3o1v3j=wsZPOMzR z#ahnDC;!Ytm+$9BWfqySI#p)YE9zL!JYcPZTTYz+GGp_^eb!#*4-5D#E2CyR7cta8 zGr#Q(=x%%IzSvaHTunNuHVnE`1|cG^*ijlmtr~;z{S7IY%+Z9i@`N?o4S%IDsM=sm||)`p#0mJ|hLJj=_{R`nufCMFD=uHAy!>LJV&ytie2k>Y7h@q<`i~Bn5LSaMZ7TDBy#Llp z#y9j|pZ4XU_`GxCd4-)Hu_>~GAVs_nngN*GZ(JN_Uux-`8|m#yS-XU6um~-_vhgzlL=qUB*Sh%L*mF_8&-qXe2ZVk699=|+vSxx}-8lMcIdjlandQh~DGwbL8Q)RNlCNBKk{IYP; zc?sXOVP0)@H8KR}j4E#YT@1cMQZATlXS^qrH{H?xoEC05Wc~|hJ#$h~{9y!7*#)p3 zrJvt;)=W>DTt9<2!7}787b~*8Vqh>qix9iBZ&0OOnmu81t!z~BSE1AS-&Twi?0M9^!|A7BU@GpXsmuhUtcDqw&C7+eA6RrdGausr> zLi#`ctEB3q_|>~!oHMeNdfLofe?vvz@cL(I)B^OpfDA8*1vuO94W86wx>Tk+mq4&;}!LUe8wVicZ!>dgw`0q0ZK1I{XC<@A`P$ z(&wTo7%(?|uF!AJrx8_k2;zX?{Jyh8Cbxg5t7ll$xRIjFFT)_MaN!_$M12RkYN-$LDbxJx2!8=__%Fs6ItwS1t%+h zf?jtT-DI|Xerzyc-axiT32E3Kp2<$VZWA^Cq{p!q(yc_Db=1o1S^c*SdmR}j5SQzJ z8SoxZfIpp92bV298bGc^ekIi_X zB%;`y4eEJm_TbHvQUXc%U|n1`;od%*bg`EEEFYHF^vZNm77f#gy0rN_=v^XZo^9$J zX+(p&IaI?F3HfvfkYmAh zBWS&xLNGQr4pDK%h7qa1F(=V1Lbik;g4dD(DZYOXnMYIaB>zPqMsUc#;bzU$kH!rx z(vaSoCKC>pj!T5reex2nK^PlK7A}ixkmYb`PuxT$B}j4?SB|X{HbfOpbNHc)q_P`) ztQ!=sDz)NbLWtG|5QF;Dr1>u?lMpuLzO=Gm!NY`0o4Hu_O~_jHI?zN>)3Jp|Vh|jz z8XTtq!lM^AtOn4tV5QJ%#hVwMWAPyct@M&ylpR6t(liS8SZdPjS`;|0!17uQ@)ukm zV{EDuEv>_EvXVNhmSxLhS$co{kck(8*!qRp1VY(Cjpma-IrFZp+#*AqdQ}SwBgeV< zHZs3utXy)%V{9HLGIPDAK<7)NMJ2TnK$g_kA&JpV#7$73OOa@dzZB^W4!cLZ?)N$A zOS6_&er0Yuj5C+Mfaw-PzlDdztGWwNVac3-zb&ImH4uMmt*pfblxlvg%0oa_>gDT@ z`NCh_M&w8fCF;UxE60w@{<1KC^=_CEE5Hq!u44j7fMQn@#A2R*-%*9nQF{`)wEPNA zw_;qoUVh7><1MhcLxvbwr*%~@u=M7B(fF@vPQxPo_Bz_3bgie+W9C2qq2yNLCsL^g z0(v;mKh#R!f0U&y5*)ob#2sZ&eEa!#ybKOn)@q>}498R+l3M(hMAVLmu z6`x4}keV%OUJ5p>G1}kAh~;n$E?+4^JZvykdUi{RyN=B`*(DX{~ej9U}WDfCp7tb=Zrem{^! zDx~52d(VRL0kE&R5@T z>t_X`I@YSIjNk=CrS~t!*6cStsX^6m22sJC%(0vRNRpq^q1`hog zNRLSn6>c(6bL9!;OxD|w&a@ZHNoZ75T$$}pa0_kj&wfdqcm^uwGel?wSfS%x&PQc> z=B)Jo;8>Ql#)z>0=1-8-lue3m0+(qBrr>cLqB*omun$o* zWZ`&pGB3FJC@{!D@?FM&+gb03#wOIkLxhwX3S4}UUiD8lEE&kYap*$D|KVTP*RkVK zAFfSzUN(-yWb!1`g=<*h)4wzOdN#@nBKTt=w8}~>Ht9S|NtjG>U?HDqw};}a#n+fW z5@bm7XUfh5rW3A@aI7XQjxn)2*hc zRrHd`dno)2m_KDP_JrJx2c%65VzZcfV_eiC9encH9@-mi()AMS0nJS_aC)O%iiKa!OI7=+S)|FC>!Y%0Y8=)o^7}k;>xAFNok5pYsz8GSRacKl3l$ zMk`IDkn;tNrul2dUQja%x4R8T48>$VCI!b+D}IjFdmfyO43VDn@NxVzcHHR_8f1H? z5v^ZFzI<$Ne}ZKwa)9_z7fFpo=|`&5|MUkG zq{yAUSV*j91t%1a$-GFCp-3D#h)6LQjXdh!0xxo!IJ1VY;R@=$wH)LcsX-~y@ek?A zUuDwsm&0nnnIlh?&D{zMIf6m%qm>IQ5Bo!zuh8=NOJPRr{pTiYXZ6t?nQnq>Ck51J z6-fTokTRbFR8unXXPbQp^GGwg^pRhSY+$hu6WpW)l3vm=VugOtB$hwCC;~E%0+j+s z;pv0D2oyiYWS&IT<}upEh*pC4v6KLlf}iKL9@qe(W1v9G$Rt&1hH3;gYH;x)5Nly+ zJP9!upu5jR*W`;R%A}b4Bo0a*pcR0_R_o#l6qAS5(!~^oNxecS3%P##7uZv0oj)tT zzdo|DY2dX>=`jRbgl1WyrL%Yw0+r1VM(krWCXEXS7-oIL`w}54lep-#z~)g&TKDLR z6LU`MW6S#gYC6`~|K3Cc!IQz`D~!;=9d(JhtHnfJx2NTTl@M-3$8%o4&Y%|4AW$EVAAK@F{Lals2)g@8ofk2Q6p<;tVHXS8 zfm1Dd`0=XKb4TES%6>P95a$JCI=@W+2sVKJwD{4j7vgj9AJ!C+2W)M4%RdvM)BXfFaEOooMn%RxVlQ5#~ zcSHFJT}{h_&c8XpsQ&DQpHJ`iXD8e{l`fXWO4;$812UwdmlR#X=1!vQ-Dd!(?xc_u z;0@^AbaX^sD~nzz#^zh=j=)&hJr_Sab0J+n|-T6%WStuSO960^DQ?EHk7DM3)) zGk2e$rZIcy4VO-(%00Sj@s0u^K;Vy5;vLox37&h)gluID9Cn zff*uvC$%>RvfOoWLf5){DSM(t{!?frc34`hI)~S$st_cuvaF$n7t(q%nZfwFp3|_LIo*{??E2QDKDBK*NLca~J6JlxwE` zt$h&ONYzLC4eFwYiP2i5F=o3*vz}*#pDJLxNQSHKsT-2+;iffGf@~&p)0QWZoU-Gi zqzercikGI(!7haFD0%4hAX(N!UCIu2K0*v}M*u6w@?m)OJd&03@`n=6MD&V9qaViR zK*B(OS}O~F-R8+>8$esVX1KrO6-|soMqW8E3>d-OS19%iD%Px7NJ7fH4>_vc1u$K=Kw-@Z~*N|Gz~Bqh3-v68y)nnozg> zoe_J`YWL`p5`+7u47Wqmf8GK>u|xxW(wR}XU$%f-3|ibd%Y>%l)07>UPG3s7=OWT5 zAS6MW9qxGe%xy9z>%8Jzt|H98{gEP2?Y?if4{>TZUUh*FH?W7T^{|@-?4}JRHt}~o zMidCg2S9JOX|k9TV!TkBjmOx$oT_-(i{^k-s)vzOa#GrV%Rz>~sL5BK3+i!v#Z)QW zGH(&}nzc|-ng(|$BbJ!BFNRyJ#-`m*!ST#x7^Qu|ozlC5#<=Pba{m)N4!Av{HO{VB z;dQvS_@M@{wyu--LvgGiWc=TN4=-V}@U!X^ZhT+Oeql{mApWkO%#zVzntVJFjdp390!}c^6LS)VsI7&rFBjN)K`P(E78^Q!;M5&(c4e~DMX1( z{v1(TP(7{4Px3(mAI>QG6(B37WWx2QTtNvXz9UzELy8-WR*3NBGB4>2}mQxzDK z2oY&;tf!&CR7C?K8zcdPQv}9_9_@{744XGY_^jY{!_$1veRuqqtbUy2BaAdqUGKl2 zaLZ%jAVP`lrpmSb6y(H*XdQ%9-Y2q2`Z+`8LhAd=Hhln=NVw887&wF+{D_8b zX{VFO`$M~fJZ`}VYgRSH&k;>esBAA_@RTeTx`uF;_=_{g(ufJX`nNF0AZ{Lbz4Dh5 z8EF8?929&|!3^Y~R||2uRA;^`yCQKiz%{KptN_PL4Iph{`rKkB@ubBSuD3tr_@3kSp?uq33brBG~Px7VW1`h53xIs?KHEwZtK`n00c zuyW4&@vx*yXBI#8jF+XDoSYA^^qEFj zIuZq}mZNY`Nwzyz{G{rb75 zflZoz=eSJliQS11GTlyxZY3!%7%|MU^2o}jHsMEhC~ zJt97|$a9o@w|$lz{|gi>i!r#n`J$gQCF;79H;`a)2ofleJ8bBh<`J7vl*sA-W20qC zb}&Z7(<`$V4Y<212VHPS4^<7stzN?!SI3+C5C_ji6bd;};jIL1sr0TzhF+YReMu~S zc;#TX-$|4hi1+Z-)5HmNDvRC=e$MAiaKs02n}}wh;JnjONmhS7LKBVr(No?Zk09Ak@|%TjC}v_d=hk` zN~J@g%L2WQz)2+%J&sX!oLuYQAJswQSm?A5!RE8M-vixaLj%N@P^O5rKW|@l@+!9G zH>j;%=YQY;i9rj5fc1K?I`iw#*Hb0oKv+xg0^Wa5RTk>vjFry=y+Y4OkW8coNsVQP zaDi^YjDylpRyZ3=oqrKZW&z835E`5nhN;`PBR2o=5zfFVVD9vD%?`L6dT5B~Jp`3) z<|p(j`#E2;GP$ByZxK?#@f9t#+1~(X{SLZQENkv$OJ5zV@WV_#6m`sY+K2x&eB91( zj8^g2Id^L~lPA~L5B_3ysl;MQ;eS%2QD)SihdZw;lhVk(f#yny&wA2|v0yOsPu;yz zvy+9Lc9VR!zFDQGDH?YBxQIGzJuzjyNYlH1^>kjm?B-@n=G}!w*If=PZSKKuY(4{% z3Ofst0gKuc!G#ckB*^CEIUU9`U6P?!MX8(Iz z?TNdkI>!&)7T)!^y|{thl@zUA)VMm5v9qb2TDpyFC%tg>ofkge=>My{s_M9A$a{UJsVJ6f<9`xLKj5F{mOl@s<0P$|MljTL&liwm2Kr!ne;T`tljjE-Mqx^sIPQwzF_xi zMp<&=PL1&Hy27sZ?si}x6+Qj0oa)FD3E$Pr@woiXnx-8;IvXTc`hWKZ`A-?J$ISg? zS`IWHE8c}zpm?_W-8;APE8=3OB1FEQs-YK=myrwm5?p&rQ+{`rrPFBJ)7NuxmXA<8 zlHO*by_;?7JKt5rLGR$gI2R6%|J&;T3PWz`!DxY5xFMyPcN1Ih^QC zbCf<}Cmtp-TRJ7gOK2Jg*wfA#z6QnI(RP(Z-Ge>uDSf+x_6geBYV)sBS-%>5T}|^k zIc%yBYMQ%K+bUA@+IOC+ZOvuF^~`efd3rjYp~-s*0altjmLvVQ+7i9DO}BdbywCPU zMWGp74m`$+cPT?kbEJY5dMipCGMvKBJ76Xg1?{PdYm{A0*8CMVtyj!ue;yyA(yUo4 z`BC21rq5;7IPmvpsrawl>bAa(=%N+ht>D&cMUNu6wl~suJ452+J%vW5I{9<*>b#~Y z^chSgG`*ylzeeWexeYGqtr~?7aSR_N8iIPH^W=wOCQJ8rTQzxCzGl6(bT@>@Y{iVK zJ##Z7`6xm!5<6dR>AoRTkwctF&FfnmzLO(7b$?{6#B!I#@P`VG=-||n;_kj_vf=nG(}HJ&`}Cc~Vk)KyX?Z}Mh3?fHOf~k;!Jd-wc7_}C z{-?|m=-VXaLIc-k#M|G?Y-d*(OJic~H|!V%2)(CM%3@#KuF?B?lO{zt+PCaCD{V7p zv5>1T{Q5XxpI)f1M&Dg#>l zVtvcSQWZaEc{q!}7v4mp-aeH+v zuq;f)rs~Vp`a^knab=Rm&MqFZ+qPedlWq{DEEt;YdS!x-r3KK>9~YJ9q8a@1zRydt z;jM-hyqA+9Hyu7P?Q-J@&bA!GuJWuY$7Mrzh-o ztrWsdJ(ij^YWp!eoxaPFt@OoXlcxriZZEEn_jmcKsi30CFxv9Kr#pBo5G5I+9JN2E2Xuf>7g1he^LmWPo ztVu4*$DRgN-q{Gv5bsxHde>5zihV1pPIqvdxwx>JKR((bV#l99Xm!8mWdS58s>$db zV9VXkE$i|9_g@k{Qk=+75MJqdz1-y5+4`YZGv1Y#J_%1+^qLlx1wJ)t4Xx{}jpUtr zl2SMvQ*}z)hK?G^Ib9a+t>w2&3$?n2VIAV>`cso>m$z|8nTjhu)mjS-3MPKUcv!GU z$go(+SY_1C2kfq8Qn55PtB11L!ke-P5yO>LO03dQD_NJa-}0FY+EacYhcsI-k%4(|Q@GGc9X{GGG;j^W9%=&iXn?HfCfP#?SxAGuG3(NoG_X+;-C{ z<66bq)}$pYyWp)`QcJB0?fTfzx-)Hm8={R_T0q+O6W} z^H!s7E{l?5medUF7^$-grP;nVOdB7Hopko)8vonz{JZ#m$3)pd)HFNwqsuQMk#~ zyRNOeJ2Iuf$3ca&L@ST2Eb5M!$@}7oQ2%jx=}E$Xwl^CyD~gC-Z{Jq5>C?V#PlZs@ zzjjx5Hx!0aWY@R`{UiGXIS%65LwE)+571nM1Hj#&KrY^=gs8lV1~;9Z5`Q!!xl)p9 zeop%#+slQ!?R_EReY;fi+Pj;(GUe;OVH&k$Se6T(`$7+wUv_LfNZ!A$yjmExwLQ?x zbszp!QS9pCv32Z+Mbg0E({L}WoJM?rnG9_*d*4OwftJ_mq`7@&t4%%bs@VS#b%6)= zVGV0a<230&%-2JY5PJIgimmqD@@+PSjh>WkwcTZ3G3$i4A^R~1aY4#2o#>Hv&un6m zMe%FymQ4kVjqk2P`LWP0co<5}8cTaM0W+!DdXW71V5cbXVQw}CG8UvP#)JArvI+VI z8mgi2#|;hqAtCsOvcsk+=W+U1XjA+XqCv$6R!}VViwKWskZIAtH@~QC8L_#JF zi*)BCxdb>`i?&%FcXY-EdQJ2&W<5axEnPJS1e0YFf0p^c-4;AwfI#^qi|ui= z%i!Iw09Z>{itTF_Bqs1k@|WexW(x!*Ct240Tj603R9P%YZyc@$VJ0od_bEe5YC%mp zc@#kYjoi`8a1x~JlHYPSSjNR>(r^3V0SR9!AO9#asQDw>Ewcjc6%&1^F0LKBGh+`Vr-10VLBY?S06^; zC~2N?OW)q$*vRCJw^THk9&NU*|>>2RJH#E+Niel zktl5wau^kW(?wy@UPy6TETx|6PAW-@k){mzWf7u5l5@WoOh(CXVeu9s2s%)~U&jJ{ zn6NBudkm6HfgjL_I6c`TNpI5Fk5mLBvDeWYAi7ClFZ)x+@Uoh z>Ek1$YjUwf!DWvVF4hS^^o6|-P4Kqxcg27It~EA#=n*}MGQ91b1z`;}zKbOKTF9*E zfvNxfRmHrru&)w6r~)b#d8c}|pK|P(lWyD6>b}ZAc_ysp(n=Bfy->?dZFMTXcfOQ* zDt6(2P@Ujt|2hih{j+wDcHP#0Nxc7i@+rI|N0+Q$UjOg%nddZR`I27d_a4P+7C$}= z-D6?pvlT&OxBQM;HO8j%Kns$n-!>+?v8N?)Ra-!nE*7;XqB|eTh3&(yk_4L{LpjsD zluKk)nKeWKC{=(}PIZYuWR-P3i0XL@y{4Cmv@+XL&K@U&D#A>Cu1a4(8>}lyWTuiQ zxUE4hG%4~bfU+aJeCz8Jd}M&McxZ|PgYE@e?Q34ovI71& zeEeqmM9#;liRyc$`|r5vP_lBqjk?Hso_nHq9(YgZf#j=lni+*F>AVQAVIG8$OhhGAd24ZyAzJZtRywD78qR% zZe^Qzokk|G_XXEay`XV{bcvsrdCB#f(oCa!(Id?rm#VeTTYXq1u{v%+Oi{v$|M@>hf#W07?zs+psBZF=0p5ghG z?QtjK_lVt>OQ>^6Ezt?9PnQr^${_FfS$9+!Z3;;=cjM8L@-CoDqQ#c0px%QqGHun` z?wi`k%F8w~8{4agcmgV}K|B5_a7JS2r^h&l=8tjw@_`Ig82E1wHYOCMxd;!Ma$`tr zcM53Jr~0*yKdP%m(qV?bOYM+W;^aOFkbXxFEVU0f$>SOiy-%w9pzDD`ZHo`T+VE2Q z7Z`R?F2D(6l%=gIZYNfC_>5p$z3!lbnuQ)-B5TS*@V&>qShp!?^!RCZk6wc zcTP!6tVG3MbG)`jZ?-$SRjf;ySgifM_Y2w@#;3NcDt{w7`Nt_thqsmo6{3{o5Es460j;@=&5OZ10$LHmNX{9Dxoen?3u~+>vdk$Cwtqcrl}0aXTd>aXvZGF~mhi>(QmZ=Z$28yrCj>bq z5I*=(z<;@)qJu~Fd{F4#ng_oB2>-E^H+aK)KQ{cV#9J3-_#gnmYpwki@NX^_#R_9O zOgQ6fo{IR8z`w3DqmQCENYAKY{m7&3>{r@iHC1l4@)7&QzhN1IHig=V9YtNh)+ zdZ)CSlqYJxu5LxYk;JFfOSyo#kXUT!CQfFP(nRxqS|Y`;FN`rby%41`Aky)kT2one z?`MJZLV_=*gG}-<%BjXkM;hI)(RFQQLg9H5&+*QP7QA0X6#f5>sfG16N;(g>_qGz2 z*lD$i(#J_glv*zTnS1S6+9iG2@4cXIWKyJs&OJ{{;jvQ-)3>W(_@iY|5Q%qY_WT^g zFuvT11|6vyU?73NpR(tw{w>F~b6`47G|;`@dC|Pw!83f2M5E#hFQ#|gt2`N|7ys_? zwa!`FxtC0dsvjZHj{of)Tj&{Idhj}qzYL|?z{1ML+x^|r{t3(XOZYblY}cy-jiP&j zaOD1T9l`RV;sUG()iO7ZlFcQj{erX7t4)ER-O-y-P%M}f3aWho%IjE(m1cg%0VAYM_gie{ircKdqME?4%ETg z2e9U%5^tYK4M&rtktzhkbTJ*wa*GDeC&NnvP=bdB8JXxY9lzxkJ)HT~jQGn?nC>F- z3vyFrna}^WHF?Uuy*K+%Vx=-sdLNK7b`3Q%X1WZ*VM5rq?$oZQWu^a^0U^X6Qjgp3 zV>(0rzQCNh#CpsWV?tWF3$ed;3Xl3Y`})%BUv+qgFbrX29H04N_##%)kni`F%S=ppJtr zB3HRPT*ifX-_t+#T5kt~z2Zj*T< z%&WHq^(X{i{^~4UY|jZ?J5en6hQ8L!u#`T04~XD)6DucZ$udvLm+8bk$Vse0%|^|U zI#Y%sD?!RJ+d$!S?C689(XEC^D(wOTFY2$X8~C$q4->5Kz}6}5)0OM_FJigXDwa4A zzPqy(Zc6=_O$6Ed{{nnmqM*esHKNl}&2@r0hugD(fA*ymS*$W}d?4KI`~#4NO!_LK zcz}nOz-l>bh+#q~Ut_&}mZRfa#U$l1dgKkJnde7xjpG(3c_Pyrqnd_`G0Vp>5E^_{N#Wh_jQdVfZC(=eTvKnX)A2SNeJZ^`x)^|%qbg0`Q z_#yjA?FwBFjOmFK`GNPmNP$T7M+LUR5PUngolut0o4{E0Sr|pwT#9tq)b=S^qT#Ic zl|X)8Rv%A4reDaUF^lt}$YT1|_D#+dF_<1%EoVrxlfUM%&lEVv;IQbaRY!JJShu&* z`Y2iE$zB7j;nK=c{Sw#41Lm>2Ns{w5 zn+}5+Tq?z%4Lx+yrscOSrsTFQy4_a_2b((kPRj*6S*xwsaqr%!o(8Oy2Sm3U(RIvS ziFuM9pktz1Yw}EK^Scy3}>WqBF#`i1ZEK}k5_QS4k29;mW(V@Xah?2U9qqHq3 z_hB$(bdIJjNDp9DGW}iA+TcXTy>SlN1bjQJi<9@Q`{y;KNL*xy zHe0T4&+cp$TN5SAd@_?bXOG4MR}9oe#K1Nqe?7zB5c{8P!bWG*`OB8zh-Tv)Udhnu z-ZhT0i|?-VV}%#LLhv_u?Bokq9=w(WAc1x#gP^=oy+V^Sa{i_a1nWUi*DH@m^{T5> zQq^6HnYp01U*s@)n%zms#mxL${=i4%+%uhqM6JRzF{G|TD2qd*fPS=Z%Rqg+GC0#P zFWvPxuDueR`u1MHB>X~spn2-taoo|B|Em&6xnMfh$fU>X-BMT%1A)4@oNzw!V*sSO zcVff)P&gvGrTdVd@E_FqZ)?}yx6?oN5ANs#66;Qy ziXqn1-%NW?%KXz}DB!PITpF?n}P$0N5Qjyvyb?WSXrAyo6)N`@N+3AYySkKo0NfI~yD z@4IA=DmE-Kl>&XSSJKyZKw3q2&yis|D7xc=4uaw(Ow1d)0+yyK*=`S_c^N~bPD66o zpJVE?V;Hi@IAfA+jDxNq0n0*mI5L8EiG-01RWYw-^+md3E(I9V!WCzX+vp)fq9({=R^MWw~#RrhNz5v5O| zT+ngZpuR)(Yd_g-}Qq?qSaJ>d|KU769+HV$Fjsi8FZ0vX`S1tO+cFg;Ex$=02G zGj2b&w!iUlL0-hi+`~xre1U0iQ114E-Z%^LGtQ0jaD+~=z3p-?*xnCSOoszlMvF3p zwsSXZD|m2ZDk>^nZ4_aC_;a`IGy-%*R|3pv)iYK3tDBmREVsR55TI_z}DJvSKl?1^FLbx6xLCN?YhigmS0-@ zjv?eJ{@gwibF{vnZt>`wsbC22>lTtD$Fn+kAMO`;oxid*Az*7A3TN2onvrovm4u3? zzVHhoGZI@rs35Wasi!XDDc!T6x5B(1tG3ip*=6>6Y7(PpCAbyfi$)lvr83i_&XkfO zX0^5hShc7OV-AYqVVjE5VG&n^d(fnmwTC4-ne3`(8-Kn(&k;gcf2h^3GZ%xvgpn&< zHz6qq3|!qAA^`QbFFCllJ5TD2vuK{eakMT!F6b1G?lz~C9)Bm%7o5@Sl?(2edSi~4 zt9s@T*9!8xkTLUL=3R%3peISIPq>UM^|kN%r~;TLURl*u6|kB8Dhg=I8j}BzO&;#` zu$@*W#Ve_=?Y5ULnEpdC_SUp)9^Pjo0nc;<&*a)}9PU1`A4`Qo<*9&7f4J@NT^dyg zsir!$5H8OrN1pmwr+5vxD3)#|9*TEXbk%x2t48gcMyB!=#5bhvGv}Ia zg`8EI-I_Bt<)n~&h`Pw);nM?T2e4FgC`?6ho188qPt_{#@#TeoGT?Zp`t=nyj*~2k z1qqGS@wn^mtZOQXKvtF`oYnYxYQP0gwI0c}m6Z7i5n7$!bR8_KShSZR{(imWt$$!u zo7k06qIpwP70CURUveTm*k=V=~rPcxR_X8&rvS;;B9oSs)RV zo>>N!Dwzp&qDLU=4qY?aCQ*6!_W8`Z4%+RsyTY>l_^$%^Z;;~Jj_5X*cNs2x`$c8{ zcjAp>n^-mlpx|KmtI`6x++FV1` z=k;od5#byhTAlr>u-wfccy$dDhB^- zyQ*uG^^^H5r_l{^?QVe`txNpf4BVG&au{yVR?f4VWGdOnoC{zz~ zj`%b^Z6&w1l$Lr!b(RdEB2-~xk*m7WcP(J;^9_uMuSh#lnrn${3(3%4^~oifm#K$TXX)&6{8C+a4{)?mxS)M8d^2w-b|OG)(R|yB`2lVDg&Ruv z^Y+na;qrHOvD-r-i{n&Kns^I%0GIHl27t~YsCbzBN5aGX3=I8@VYTQhCi&6JH8 z@P!X9=-I6U%ARzV#(~weT(N8R<>~bqVS`)N^~m{|Hf`ybluqAkXZxP^u$4HV^P9jJ zJA`dxlPQS*IBlK2RhWCY7-nA5E?YN|T^{jF*=$Dl^YZGuFsJZh*F#0cYwPPbx7Bf8 z-tzxf*_Q`G*+maOCQ`gFDQgK)vXzkRt(GE0mJuWZ#o5`ObZ&e(&%5{`=;?``qo^v)_Bp+{@KV-Rr;7aBjl1%YVQ+p?Eg5L#|lC zrI;LGp6=|AA^`>Q*#)%U=} zxK2r~k8L67lZ{Vm&DW|4px)%5rQQdI6(AgHfM&mpAKby50nQ*79{$Ar|WfupfPyUr(B zZT^)9*i9aP^?PQM^J1V{Hn(v_hxtl*(en5^&>#DkpUj^tp9xw~U7o-EyUTq@GP3#E z1|rfu-g9i&&k1D7a0@EnTDKIS^n<8^`QF&g!`GPgy9NAp@n;H5BglVrcUy;XjB>6l z-_|osJ_P(Lhl~}PAhm2_AH!#l{1``e^Y9)%{RDS{+hKM}i!U!XKhVT5wI!E6-%{q^y3YkuFv_12HkUv4|CXfx)+K#@nt44OUl0tc-ewYFwmY(lm7;ds`86yA z+<8XH}9H9%<{nuh@HF?gT4EeQa0+YH7|7bd5$SxQEOekBpbi8 zPk)5TW}KuIEAa4%YK{Fqh$xhQ65qjo9_Kd8A|P_aMSZ-0pH*Xt(WeU>)2J7CsNi=( zQ;Ez7C~f#tO1~AK_$EW2=CX(`)Jzr{c4y1n!z7*hqlXcMqHQ;Be%jJ3N-F#Bm;@S* zACa_c%yKNV^48JRCzxF?%z=*>9F^{f*PnvrziIz+*clzE!0(kvJMJrCy>{kb`QuWHpeyzyDWjRcqIfr=&6WGCLZC_BNGUp`5EQ zRA|4{MyiYMivIf^#6i7HE;U-4406eC$g{gKf@BGEi#3+=4yO`n#cDgO(ZIX4-aA~c zB*ZYP>y4&2p2{WD7e%0If8>)&<8rI5B(#qw_IaS@$_e1rq21j2@{?Oh;ZINJR!kt& zIe8v8dOF0tmMEDzp!aJhe8F_?JU;wMa%Q!e3nRFCwIOD{=@u(RiLW)}moUO9{Kbx2 zVZdzVLf@rxeN56x!C#K7h@-CkcWph~KbEU3NMBEp*QrOJ_=B2%Zy-v3yll9rgaF~c z9d#PIO>d{(lSTm{Oh4Lo`chhj`I>X=zZiqasSOFcGUCjBdMxb*kj#u4QZK^^CHxBZ zG~wi^*q4W77Tg{<5>$KN^T3{_%cT(cO9M5Es2trIP=`md53exKD-;8tgHR$S2Y2V0H=H918iGRqXM)~2HA9oeL^#z1v+pfZ!0tx?x2heW?;lyH%J7IE-RM4DBCu_-YOlDNkyyt58=390+p^1 zYGd&nkN7ki-x@JC7RocDi?Q=3(WD%gxzENM+$GbuAgw_DE;&W^(R?O-or~+wO2Un( z^eA@X-50gXdr$|~yJDAP7spOBNvAbsruuI}y;jv2QRv+4#KuyylajL?sF`4$*@RVY z%<)OKQ<`UN#2`X|rI%P0edYd_C^>Bt^~(=6`ne_ck}@#-tuiM(IF|ff`)u z$1_uWtQcV5_O^oNMl{uzO2dDYgGNfig-;hinS5W}V(=}!GIuwc%%HZZ97T9F`i~c^ zCC+_ok3w8VZm2QJ)IOd`c5{)vaHSB>LCSQjcy>ZD{sar<hpFZ&LaQw!Wa)HK+i2yd@e+!TGopbYXo8y<(OGrf zu~o2?Fb4MdOVqo9zkduSEAC5QylY#6t5))hYLyrGK4qfqwl*^*I5@A@cLSt{?v;YwE7Is&A zd}=qPdI)N!Ae=TVu%;?O4Yu1XqN*UeiiPq{J6A~M<{zW0-yl~ikk+ag$cycQ(M|9&x#5%jQbB!4OfbF+7`@W&f;G3&q zF_9^q>5Upl8%5>ErsVEO&BXm3%&5A+t!Da-c8w5iy|Fj;AMQ#x%WX7Fuw8S-- z&F%~H9p*_Fv}h<62In`>c)lRPb_vBIe?&OjYtcfS*pQ9t^}nRz$J6wfOlL5M#wAs} z$nzC1@7F9bu+hqwAtef!bg1;{GUiSFmXMP_1jw%i99P(uyp$?KESMZ+WRT?`mc>p) z0m#4Tp;ge^ig3xY?L5H;xf2EvrFf*(wb8n^`_-a}^r}_}3ceRbs{g|lFYee5&qb-n zsgP38mup1P`4hgz-t8FR?+!aY0W7t(3b$e-+r4wNwn1$S|6H+<>nI4X1 zKf;a-n*bji7IH;?!^VrUIs@(60|b;JGj;&!g50b_sGix}D(S-lrO*7Xulz8@uX{0W> zJt9HXQWhvmUaVEgK@9d|$8!T##N0k9wTu~tB?j7F#w88@QtM9SMD)IYeEf%;I)dn_ zOLp<1)6z2Jr-+I^^vWu}Czj37k(197W}>sYRmvb*+^GKIfixbECaXfiNJ@gQ@Aw9k z^Z`maq;o+n6~X=QH{S(hJbr`~ucMA%`F^56=x;tjvGhP&_i&=6Y*~r{GeuVUTcC+kg4JeU zIM?H{LJ@T=A~Z8_NsKfW2!~_9X>Bi6i!Kvd{m1Ch)pBqo1>fvnCD;xQ_x@f>T-ps2 zNizCXiJUWM<=jtGB}2S^wi@!B5aB;qLGA`*x}Y>5NCxGxTX7n=%-I5{KUA9ek$=r~EjQGqce!Op-coc>GYuaxL+l{qGY6Tq$i5 zIJC;zDtmAgpUa2+f1N?Z^Es5Zm7L}B;jhPhI`B~vilL0jQVbN$CLVGvf>uTH{Pl6DwX*qqjun4eukWbwpH8>>sqE7uTj{3%tGm}{;5TZ(^O zVoqO6WMT9hZp2GB>LFV|G!32R0bH`68+_(6)R{6@f6vMC#)ljh*9mY~PIzz};$JNl z@5_9^q=Qkq#~679?Lq{(K&=3!!ASwhAL32#>LaCjgziqQD(M+;uWW z#~Fz~_znL0w2ZiO);T-r!O}R3@8_c@j4NS{(#(*sdNO`QDVgJ`d<~gLjt~W zWYa@HF@7Jf$`qsrcR>o&uIV2&nPuAocyqQeWj;mhC%R;^9rfE^V|3}KwbQ1Ir;tSP z0A)@YfU$v^{SSc4m2kIW(g}j6^){ASf6c`QZIH~?MHQvw3kI|cxEZxpvr9|#XF2j5>#GrV z7nztcSwOE&K4DC)fCw9;(_wj#b^+0KgAZggallyVfl+C(xT`ZkQis9fkXQN&ZsmlO z$?!LPtd`oe3vrOmqx~)48dq^qcdl6X;F)W$J>m6%-2s;hrq3RPk&49!e9r?dqAIj0t9X3-Vi_-N~<^fn$&}a$j}>h|LFi|9Os5Vgd72yCMd(i>erubod_BI7s`~AlggFD&e$ZjnX%(3qT<|qg zcEe7_aQe|#Mmww1Vtk#cmduohIM8kDa$yYn|6vW!v;;#5=`WoV9rIp1S(Snai zU^9*xf?oL?+a)rr%oNHXk4G?&Cp}hhdDDW4srPD-*^18OjSoxb&b~>6)FMz3qN2ct zcMW$e^oej0c#|NH5cKeXSWti*)E+ZwkUQ$NSn64s#w@c}0hCT|EJ}X?6n7Xuv~C|Q z>wUIquNY}cWhO8~Sj9(>6BZ+{ohxcRrA6Si!LzSae72&mw`x+XF8z#A(w#{5XO(u1tzI-*RvXMid)_2$-!i7ggy%g*`Ef8n7jE@TTdzeDS5L-q1 zcpX8>ZM}Nqm6@qvgx`KVj#rk*o*si-8;~ar*hu#A^ox?@cyT0v2AY(Ga~5($t;$VF z!z8{OemW(u{HgWV&}^QvdKr5Q=F_S@mR0(`Gd@qLMFfe3RUx^8Ko z@>-%`Ceq%O5_@pw>b?K1tqnPE8iDQ`sLJj$IW|NtBoikj-c@~Hd_G{S>`vg_umxoa z=7)J!GOr~bt$S~jEgEF_43@n6WW;aqs--jnL0a$M|6iOzUR}bM6NB%=4Iim7%ZTeD za_}Vc-Z?Nb7P@CG23Q)!%(YW`zI> zC;b^N*dOgCSPWku3nOb8q3z0kzgy;ChIpxwytJ0s9Dx!Yj|F>b=|kZj zD(pJd$D=4tGO|Q07P07C*Z*DdqifS~?hWWR&9S~neo zPI%U);2r3+mbg0xK}0o#PTNUM_Gp^-T;}-f={u%Ec-K+wOW(QA=zfFUDNJ=tN#)%O zPpwTbTQ^crowa)SJbp-#A0NzBnAqbQHQ~;Fy98M{WiS74K+~MfftykLO5VtMO3g?oC=A6f(BmL1~pvNL1w%F zG9LkjfA9he)U2lta^nSlgQVvOz1@nqrJLOP&{FuVWXTjrAjOzeAcPA}ME z{d!;x(McFhCSg!|O_qz=%Z?AkKgA|=n0Ad7NgVmshMe9<%rc&9P`mq4>LIm#Jn9K# z7MoMQXW6Ci=B;o6SP_j9W(;FaR^34D<@%mux(Q+2Nk%*O`4`J>NE;Y7pk4FBN6g)j zL+W9cY1@uQip%76I4=d0VEpJ)rD{j;w0@H!C@LfG^xHE~0>BY6)k8pHN&{XOq|GI0l=ht9%x zl>rbms~B@x?@MXgy&)3RUN%Ws52;=yyjEh{0Amy;D5*gy@B7fFGAVR- z8(ciOIuDD<%+wH3Fqkyz$p1_q(G#UQio1i z&dt<3TCox708_n@MyW(Dy!Qd(E-Yf3UV05Ka6fkViV0`o(=Q?a2$NyBYWbTz123l8 z*o;XB4ul(Nd{IrRm_7h5UFhKBQtu`QH6{X!BsG~TtVglAu^vZ+IN;4mtLa zz|OlLkQAS0I2Q$+PZepX&4lL($XD28h$8i$(tK2E1JPZ(q(r)m1D!{PmxWj6zFOL> z|CvQ9Ge%x-m+R5#^I^y4Rr8Will=Wi*X_EpYN`Xc9#`%NL?+NvQo0?>U3q(RB&nnW ziiX4f3FXJq(P|x{@YTL6V-14kO{CGT!Oc)DZ$sC^pC5q_DNn*qML!rz={A4+(THsG z6skW%b=LV8qHkHHfbOYbU*}$Cm0sJHOuM%21Aj|o*31#gfgzA@Dx3Vw0;tr^|4n>qW_D zqw--`K;O=IJ2826 z6q%Z+;eSYX?@ynL?ukD29`MBiK%W`$UGH!VVMOLy9lvi<#~5GPi%Tp-CM8`~EL$6A z@a6x-;KzBD1t1!lw<}4Kdi<`m(Eme z{X@h=mLhKe%BViFSom@t{l-Dy>@K=qpiWtr|BwuA_893kn?uC#sRUtYdgS7ro%A7jpF1)B{9mz;?JN zDw_5}aUV>nuL%M1-7*nq7uw$NAoMSw@ts!l;w- zH_yH7n*1n2f!9hXxmD>xm-X`!xezD8_1b5DlsAt347Kj~iBaTo*1d@@@q9GdG~!cc zV6u?!Dg0czkN4dkZC~Q#Q|&97#;VqkTKgM%*%&+%8u1fAoUC z;U5%OP8lDE8{ug#a?mgTKh;IvrVy$@=b4n`CepUQ^fUIzEF1@CW3ofuRzC5Dk2!5S z{AD(2^k=%zMg2VbPEdg55{SGS6Js3kPC`s9fqh;Ev`crqothX2QX{0-XK*~vbdMLg za+6-F^l|vU06=eB7pN|^XwOm*rfX^~T0z9&{Uve>iNIbY?_n^q9OnBCCZH`AmwKea zMQ``uyRnCLYY;5H1Q^Jnx=gw^9xx&e5`V}8RC+5MAJPPOjn-J z2;U#eWxTWebn%_cBI1|HIQd1LuC5rEq7){5c|L6T$jpx+>oeog4RBw<_V~(fBahD$ zS7=s}Q0oAy-1ET>1XYZVU6}2QFRH_1KLH=Dw+ZYLk5w{)U}VjzWLLnT|4F-l8eB@; znwM(yk0%Fjf(IB!GUYP1b2a(543C;`YRN-Hn|Jt+J-ijJvT%D0zKj+Rd{vm zj=IF$28I-cf5EbUZKz#za){5W-W3D)uAiuKifK|E*HDIsIYfX>WbQEJU~}GJEI>|u zfv>BTK_9Xnn+)j@C=}e{$-O43sIt-EjWP0#7KR2^cr(TVsK3{=vbPYKD_`d|G8DABU-4Dx4>c=NCdStRqSxMC?7;@O_h=R z=^JDBwZKkcNGK1)({$;vB9)cCUGsiF$4BH&Ih=9Jdhy$ zj+vKw50q7a!-dp!7;%HZTMKPHFBXavOjdItY}i>d-@0eS?Qu<7>I_(|pt?~Z58-CG zF4Af{YT@uu{aI$=mx!<<$a0x)!!1a(IZYMF?eLW$ja&kOKpt$bxt$QQ4_=o&z#h=l ziCdUkt17R~{q&eqHO$LUMdSO1B%Jj_203vR=^>!WVF08eypW@G6{aU{%a3~=IS z9f~@$z)54(HL_%k_NKOOeC}n}-eEsFyE18q1&rKUse5X9IJ6;DDl;b~ zmzcc-d+$V4W#4~9oJub60Q)vbQ^TnCJ2?xab1;}v^ZKd@jMi6lzgX32gsoQ=K9#<` z>VYMvBZGbkuJSUBqY>ugzNZUmYmUs8S#QtqJ)z2pQH5N1S>Kg)ErYwkdv~o2+2(_~ zm$CWfyv=Yig9XTRv_SumOnZ$qas~+VJcT;5BoGA#)kw2v?B;-HK=&eC@y78SB=;!he%F;mTPTty>;w{K^=@Sv7$-V?EDC2BPpwRHRt1eTJUB8si4boY(0nnS=2Lp-LCIaMOUoPYZjL5F1(o8`9dV z`3)3?2g+Cj;h8$*c0%61Mg}Waljna*mDEC);fU}lSpq?u^fz0>#M_qm$$MY7owWRF zfSV>&6ZYDb_g^5{Y0$XT-uM)6ey%ZGZJ9I*da;rlW5GL3+559tgl4=8T5M$?WRLut z0~Xl4pujQ!DF{%;+yp4Mxj27YZt_q|T#6`NMSJ%?Y)Zy|3z zVQU$T)DNa1sqs#%6_+YTvVRsz$Rh^0xh&_@4A!eb~o0M-YaU) zDueg>YEYf>e6jtm2c~Sp7go1eG)EgdOy&W@O491|vJiIE&*QRi17k$K2f_p%lCd=t zg#&0L{jIOsXW2V#M*pH&VtSwd&{6P8_(rbz;LeH#R&)Y@;AsZ+9&BI!>a&-iksF1F zK&_#$6DWHjT}T@4q@K(A`-K&a*l=PCmRSw>@rGMzD7R`0-h_T;Q!}c}`WT1x+FI~2 z6Ac0Ht#y?SH?k7w$T6RMByW2U9P9D%J-{C$I)K)jAS*6l?s~i*gojNgf%|2t9e|A5 z*m!INVZQ(xfoN-TTdWU9ub02@h$Fy0nG*JOcZz>^$L1(#Wx*zc^?|C?MCzoWpP{G) z*OC=ua2hhqGf58gWv>qSw&jZTH<#c)k_eRAv76IuWDj7~-t7R&dak9*?yAfCdeT)* zE8fCFh^qva&sV)>m{5!tOgwqcMVOuJRUP(vw6thrR0Dz5XG~(6%=C8`94Lq3e(W@*pR)?_R z_rRY44)Nhgp9x_xdUo!OE+x*L9bK}CEMz*^LGo>P=Rv=TdV>MlBM;2~({0vvVYsn{ ziKGJ8kIbLhr}pDFh_Q|GdW^l|symhqSErC0QI|>3;%}ugBMwbq4m)j?>(hD6F)JRp ztHb;|xD&fXIm(D@s1JAA@VX{!CTD_f?X5xkG|eA2;K!MoYTUwACvEn9*pV|rf^$Ny zz+WUqFM!D5%EIYW4bvj>;$VB63K-N4usG($LYoD>Ln|ou%yn9+H%MC=2=_d3$)r*D z9HDn6!O%);LgqyYY};*)VNP)45LQ>Ire(Gg6h3T$9N9Q*o*4;PHUL@|3Cnni+tJao zFGGS7&#{=p+5z#-ldz3~XXVJVaKBFS8ZBPhy<=8PR15~=POT;okA+BMyur}-MlzJv zq0${xdR$GA&~#>@5y0D}-r=^ut~@Rxkk(32F`|74C{9$mg-UEtLP{WbwDI|{WHv?= z2QG`L0XUb@VoX~i)BEg(tguiSFp5oTp=0Br);`8y$9!b~wR+Ex;>%sJOZ#MchN(2E zkBw{!&sUS4m06xyrV4P1Wt>Bj@)Fan33HBicIxaHLoS>70l=DWk;L;wuBHILoEhR> z7D`GTzllJP1VEq&5SSUjj#Ec-r6jRoxs&oxi)W5qhfrh|CwD)wTtXT4l~{HltTWmT zP8CE?PkN_aQQDKS-FhdpnSpkIx3yI`a140_oL~|inUMyYo$B*5+Uo9;n~8QDd8?>! zGd)HL2R||>aDsNPSiR1lw<8F!*BTC^7R-#lo-?;`6*9BXaNf>NG#R&KBExq@ed(+3#M>0m z?Xznq>;ib>P>Z*f-lsNm&5rmazH@$M?OAwHiez!ND!FFqdo}Hjiarm>6<0=M#lS+by$4`3+ut|1#Q9+Ag9-2C-lthu?*(9sUIi;b zzX=`9o-7%WzP@d*=cgo=ia=h8EI^wg(S7C7(WbLYQhles65*r?uF3Sh!f==1Q6OLo ztH4@I3xuU^$EvsLHgct=%Dhf3@;Boa>Med{uRQ+zFe+jdmI>}G_IdEMROTkGlR-VF z6s?5LA9LV9f?yOxrWa3=tw3}!% zeu9bi2Glz3n&+H#j6D1I(Z~7mT5j{W%(3D|7n2b=%UgH#BO91Nz!-0WJbU&XRD#_c z7E`@cL$NUR8&W(pe>OI#t=uDcGZqtrYML8sC=d2sta?ky=rI?V1K09K{{cBT84=}B znCZxy@7jN!1*=8iOZRqt{zpvI+ONrrNUw_JTG*9QWV&l3yzLk!HtiJCQiwZyUa(nC zr4h(Ht_&XJGAh5KG%{yYx%{T7w+4}*)TxmTZdo){g_HVyfPAGDU$OCkQPgIN z!fGph@t+P<1S}c$+x$LNwM&fk?o?mVT(6VkBaGY!;y|tH9(8pDsh!*R&AqjJnRCVE zVH5Gt%0$5OrC;>{3rYKat0+{NR*1-39~E2ulmc!U@H<&};Y%H)7Z5~`XdW;r>mKUN z+SC7=lJV-7*Q43`@`Zt^fR&~R-74G4<*}88lJ_ghiw_Q*DNXOI>P??(p}LA=BspL> zvds_2N3%&Qv-?U`%2%fLO%`u4KYx!aFr$X=Q~0L9fSwCd6pTCvCI}NAy`7db;n>jK z-AH*w5gpg|{CelMd_?d8ld03ixhf_^Xo5J)_xbj;fMUf&$Ih(Ni)YPRx}?fns%_5j z1SV95X0-D=I{q#@kkbOD3f$%Gz_d=Ozgq&9KP`ucmu|8cJ5$jWdSr*0mG(cG!H<9K05R2aW@g|dRSX@OkAB{SPdQ@9xcn3D7;!O)>H>x+z|sp+U@#SVwy z&(fLvnpK)cESQWGz(wVT>zRjII|`j0Y{e!T>{{wGLcq7Ni*{BL1!upoSKOj<^7)hY zw&1CYy#1S$UIcMuuEJ{f0}3eD_dR^|%Cao6yELJ@J$+i(&a^8$m^gLMA;C0EOw@%} zR#bE+dq!!lirf)s4Ua)%RI{C-*}=iJ=d){*OgBx@8&{S~IU3IK1Sb8iT*z;x3(M*~ l3tm&n4F|RVUq4OFUjb=r)7yPCHYlKuN3;wyvk#K4{U6v3*!che diff --git a/docs/source/_static/yosyshq.css b/docs/source/_static/yosyshq.css deleted file mode 100644 index 447c8536743..00000000000 --- a/docs/source/_static/yosyshq.css +++ /dev/null @@ -1,40 +0,0 @@ -/* Don't hide the right sidebar as we're placing our fixed links there */ -aside.no-toc { - display: block !important; -} - -/* Colorful headings */ -h1 { - color: var(--color-brand-primary); - } - -h2, h3, h4, h5, h6 { - color: var(--color-brand-content); -} - -/* Use a different color for external links */ -a.external { - color: var(--color-brand-primary) !important; -} - -.wy-table-responsive table td { - white-space: normal; -} - -th { - text-align: left; -} - -body[data-theme="dark"] { - .invert-helper { - filter: url("data:image/svg+xml,#f"); - } -} - -@media (prefers-color-scheme: dark) { - body:not([data-theme="light"]) { - .invert-helper { - filter: url("data:image/svg+xml,#f"); - } - } -} \ No newline at end of file diff --git a/docs/source/_templates/page.html b/docs/source/_templates/page.html deleted file mode 100644 index d830124c176..00000000000 --- a/docs/source/_templates/page.html +++ /dev/null @@ -1,44 +0,0 @@ -{# - -See https://github.com/pradyunsg/furo/blob/main/src/furo/theme/furo/page.html for the original -block this is overwriting. - -The part that is customized is between the "begin of custom part" and "end of custom part" -comments below. It uses the same styles as the existing right sidebar code. - -#} -{% extends "furo/page.html" %} -{% block right_sidebar %} -
- {# begin of custom part #} -
- - YosysHQ - -
-
-
- -
-
- {# end of custom part #} - {% if not furo_hide_toc %} -
- - {{ _("On this page") }} - -
-
-
- {{ toc }} -
-
- {% endif %} -
-{% endblock %} - \ No newline at end of file diff --git a/docs/source/conf.py b/docs/source/conf.py index 9a22d50d346..d63523ab096 100644 --- a/docs/source/conf.py +++ b/docs/source/conf.py @@ -8,37 +8,13 @@ yosys_ver = "0.46" # select HTML theme -html_theme = 'furo' -templates_path = ["_templates"] -html_logo = '_static/logo.png' -html_favicon = '_static/favico.png' -html_css_files = ['yosyshq.css', 'custom.css'] - -html_theme_options = { - "sidebar_hide_name": True, - - "light_css_variables": { - "color-brand-primary": "#d6368f", - "color-brand-content": "#4b72b8", - "color-api-name": "#8857a3", - "color-api-pre-name": "#4b72b8", - "color-link": "#8857a3", - }, - - "dark_css_variables": { - "color-brand-primary": "#e488bb", - "color-brand-content": "#98bdff", - "color-api-name": "#8857a3", - "color-api-pre-name": "#4b72b8", - "color-link": "#be95d5", - }, -} +html_theme = 'furo-ys' +html_css_files = ['custom.css'] # These folders are copied to the documentation's HTML output html_static_path = ['_static', "_images"] -# code blocks style -pygments_style = 'colorful' +# default to no highlight highlight_language = 'none' # default single quotes to attempt auto reference, or fallback to code diff --git a/docs/source/requirements.txt b/docs/source/requirements.txt index dbba558321e..203205169fd 100644 --- a/docs/source/requirements.txt +++ b/docs/source/requirements.txt @@ -1,3 +1,3 @@ -furo +furo-ys @ git+https://github.com/YosysHQ/furo-ys sphinxcontrib-bibtex rtds-action From 1b0d8633c4ef6a37c9f148363ac0f8bd6807fb65 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Mon, 20 May 2024 15:49:49 +1200 Subject: [PATCH 23/68] Docs: Add root to ToC --- docs/source/index.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/source/index.rst b/docs/source/index.rst index 106ddbab86b..b76b5fe062c 100644 --- a/docs/source/index.rst +++ b/docs/source/index.rst @@ -36,6 +36,7 @@ available, go to :ref:`commandindex`. :maxdepth: 3 :includehidden: + self introduction getting_started/index using_yosys/index From ccd3bace2303ee0a33ce2e04dcb362497e9b9c14 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Mon, 20 May 2024 15:50:28 +1200 Subject: [PATCH 24/68] Docs: Add cells loc config value --- docs/source/conf.py | 2 ++ docs/util/cellref.py | 6 ++++-- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/docs/source/conf.py b/docs/source/conf.py index d63523ab096..e16179cb03c 100644 --- a/docs/source/conf.py +++ b/docs/source/conf.py @@ -1,4 +1,5 @@ #!/usr/bin/env python3 +from pathlib import Path import sys import os @@ -79,6 +80,7 @@ # use autodocs extensions.append('sphinx.ext.autodoc') extensions.append('util.cellref') +cells_loc = Path(__file__).parent / 'generated' from sphinx.application import Sphinx def setup(app: Sphinx) -> None: diff --git a/docs/util/cellref.py b/docs/util/cellref.py index 4deda41dddb..63e6dd543d7 100644 --- a/docs/util/cellref.py +++ b/docs/util/cellref.py @@ -1,7 +1,7 @@ #!/usr/bin/env python3 from __future__ import annotations -from pathlib import Path +from pathlib import Path, PosixPath, WindowsPath import re from typing import Any @@ -140,7 +140,8 @@ def import_object(self, raiseerror: bool = False) -> bool: # find cell lib file objpath = Path('/'.join(self.objpath)) if not objpath.exists(): - objpath = Path('source') / 'generated' / objpath + cells_loc: Path = self.config.cells_loc + objpath = cells_loc / objpath # load cell lib try: @@ -358,6 +359,7 @@ def get_object_members( return False, [] def setup(app: Sphinx) -> dict[str, Any]: + app.add_config_value('cells_loc', False, 'html', [Path, PosixPath, WindowsPath]) app.setup_extension('sphinx.ext.autodoc') app.add_autodocumenter(YosysCellDocumenter) app.add_autodocumenter(YosysCellSourceDocumenter) From 84f29680315adaf32846c09b9da0489eeacaf341 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Mon, 20 May 2024 16:45:23 +1200 Subject: [PATCH 25/68] cellref: Better name checking Fix RTD not including source with warning `WARNING: invalid signature for autocellsource ('/home/docs/checkouts/readthedocs.org/user_builds/yosys/checkouts/manual-rewrite/source/generated/simlib.v:$alu::__source')`. --- docs/util/cellref.py | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/docs/util/cellref.py b/docs/util/cellref.py index 63e6dd543d7..4b970310158 100644 --- a/docs/util/cellref.py +++ b/docs/util/cellref.py @@ -14,7 +14,7 @@ # cell signature cell_ext_sig_re = re.compile( - r'''^ (?:([\w._/]+):)? # explicit file name + r'''^ (?:([^:\s]+):)? # explicit file name ([\w$._]+?)? # module and/or class name(s) (?:\.([\w_]+))? # optional: thing name (::[\w_]+)? # attribute @@ -147,9 +147,18 @@ def import_object(self, raiseerror: bool = False) -> bool: try: parsed_lib = self.parsed_libs[objpath] except KeyError: - parsed_lib = load_cell_lib(objpath) + try: + parsed_lib = load_cell_lib(objpath) + except FileNotFoundError: + logger.warning( + f"unable to find cell lib at {'/'.join(self.objpath)}", + type = 'cellref', + subtype = 'import_object' + ) + return False self.parsed_libs[objpath] = parsed_lib + # get cell try: self.object = parsed_lib[self.modname] @@ -264,7 +273,12 @@ def generate( ) return - self.import_object() + if not self.import_object(): + logger.warning( + f"unable to load {self.name}", + type = 'cellref' + ) + return # check __module__ of object (for members not given explicitly) # if check_module: From 7eb33f19333fc23d1b0bcde0bf22abd034287f10 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Mon, 20 May 2024 16:49:52 +1200 Subject: [PATCH 26/68] Docs: Testing autocell --- docs/source/appendix.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/source/appendix.rst b/docs/source/appendix.rst index 9e8b8be34f3..4a8976be092 100644 --- a/docs/source/appendix.rst +++ b/docs/source/appendix.rst @@ -1,6 +1,12 @@ Appendix ======== +.. autocell:: simlib.v:$alu + :source: + :linenos: + +.. autocell:: simlib.v:$lcu + .. toctree:: :maxdepth: 2 :includehidden: From 7c5b10fe504a190c03ed6885e27e33c6430ee310 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Tue, 21 May 2024 12:16:32 +1200 Subject: [PATCH 27/68] cellref: Add json dump New `help -dump-cells-json ` to dump cells list. Add 'group' field to SimHelper class/struct with defaults to gate_other and word_other depending on source (simcells or simlib). Add 'unary' group to unary operator cells for testing (based on internal cell library docs page). --- kernel/register.cc | 83 +++++++++++++++++++++++++++++++++++++ techlibs/common/cellhelp.py | 20 ++++++++- techlibs/common/simlib.v | 17 +++++--- 3 files changed, 113 insertions(+), 7 deletions(-) diff --git a/kernel/register.cc b/kernel/register.cc index 4dfa798450c..4e8e62741a0 100644 --- a/kernel/register.cc +++ b/kernel/register.cc @@ -19,6 +19,7 @@ #include "kernel/yosys.h" #include "kernel/satgen.h" +#include "kernel/json.h" #include #include @@ -763,6 +764,7 @@ struct SimHelper { string source; string desc; string code; + string group; string ver; }; @@ -950,6 +952,77 @@ struct HelpPass : public Pass { // close fclose(f); } + bool dump_cells_json(PrettyJson &json) { + // init json + json.begin_object(); + json.entry("version", "Yosys internal cells"); + json.entry("generator", yosys_version_str); + + dict>> groups; + + // iterate over cells + bool raise_error = false; + for (auto &it : yosys_celltypes.cell_types) { + auto name = it.first.str(); + if (cell_help_messages.contains(name)) { + auto cell_help = cell_help_messages.get(name); + dict> *cell_group; + if (groups.count(cell_help.group) != 0) { + cell_group = &groups.at(cell_help.group); + } else { + cell_group = new dict>(); + groups.emplace(cell_help.group, *cell_group); + } + auto cell_pair = pair(cell_help, it.second); + cell_group->emplace(name, cell_pair); + } else { + log("ERROR: Missing cell help for cell '%s'.\n", name.c_str()); + raise_error |= true; + } + } + + // write to json + json.name("groups"); + json.begin_array(); + groups.sort(); + for (auto &it : groups) { + json.begin_object(); + json.name("group"); json.value(it.first.c_str()); + json.name("cells"); json.begin_array(); + for (auto &it2 : it.second) { + auto ch = it2.second.first; + auto ct = it2.second.second; + json.begin_object(); + json.name("cell"); json.value(ch.name); + json.name("title"); json.value(ch.title); + json.name("ports"); json.value(ch.ports); + json.name("source"); json.value(ch.source); + json.name("desc"); json.value(ch.desc); + json.name("code"); json.value(ch.code); + json.name("inputs"); json.begin_array(); + for (auto &input : ct.inputs) + json.value(input.c_str()); + json.end_array(); + json.name("outputs"); json.begin_array(); + for (auto &output : ct.outputs) + json.value(output.c_str()); + json.end_array(); + dict prop_dict = { + {"is_evaluable", ct.is_evaluable}, + {"is_combinatorial", ct.is_combinatorial}, + {"is_synthesizable", ct.is_synthesizable}, + }; + json.name("properties"); json.value(prop_dict); + json.end_object(); + } + json.end_array(); + json.end_object(); + } + json.end_array(); + + json.end_object(); + return raise_error; + } void execute(std::vector args, RTLIL::Design*) override { if (args.size() == 1) { @@ -1053,6 +1126,16 @@ struct HelpPass : public Pass { else log("No such command or cell type: %s\n", args[1].c_str()); return; + } else if (args.size() == 3) { + if (args[1] == "-dump-cells-json") { + PrettyJson json; + if (!json.write_to_file(args[2])) + log_error("Can't open file `%s' for writing: %s\n", args[2].c_str(), strerror(errno)); + if (dump_cells_json(json)) { + log_error("One or more cells defined in celltypes.h are missing help documentation.\n"); + } + } + return; } help(); diff --git a/techlibs/common/cellhelp.py b/techlibs/common/cellhelp.py index 0cfb2052fd1..299b7affd73 100644 --- a/techlibs/common/cellhelp.py +++ b/techlibs/common/cellhelp.py @@ -12,6 +12,7 @@ class SimHelper: source: str = "" desc: list[str] code: list[str] + group: str = "" ver: str = "1" def __init__(self) -> None: @@ -19,7 +20,7 @@ def __init__(self) -> None: def __str__(self) -> str: printed_fields = [ - "name", "title", "ports", "source", "desc", "code", "ver", + "name", "title", "ports", "source", "desc", "code", "group", "ver", ] # generate C++ struct val = f"cell_help[{json.dumps(self.name)}] = " @@ -28,6 +29,7 @@ def __str__(self) -> str: field_val = getattr(self, field) if isinstance(field_val, list): field_val = "\n".join(field_val) + field_val = field_val.strip() val += f' {json.dumps(field_val)},\n' val += "};\n" return val @@ -80,9 +82,23 @@ def simcells_reparse(cell: SimHelper): if simHelper.ver == "1" and short_filename == "simcells.v": # default simcells parsing simcells_reparse(simHelper) + + # check help if not simHelper.desc: - # no help simHelper.desc.append("No help message for this cell type found.\n") + elif simHelper.ver == "1" and short_filename == "simlib.v" and simHelper.desc[1].startswith(' '): + simHelper.desc.pop(1) + + # check group + if not simHelper.group: + if short_filename == 'simcells.v': + simHelper.group = "gate_" + elif short_filename == 'simlib.v': + simHelper.group = "word_" + simHelper.group += "other" + + # dump print(simHelper) + # new simHelper = SimHelper() diff --git a/techlibs/common/simlib.v b/techlibs/common/simlib.v index 6bcace49891..b8a754825ad 100644 --- a/techlibs/common/simlib.v +++ b/techlibs/common/simlib.v @@ -33,11 +33,10 @@ // -------------------------------------------------------- -// |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| -//- -//- $not (A, Y) -//- -//- A bit-wise inverter. This corresponds to the Verilog unary prefix '~' operator. +//* ver 2 +//* title Bit-wise inverter +//* group unary +//- This corresponds to the Verilog unary prefix '~' operator. //- module \$not (A, Y); @@ -63,6 +62,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $pos (A, Y) +//* group unary //- //- A buffer. This corresponds to the Verilog unary prefix '+' operator. //- @@ -111,6 +111,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $neg (A, Y) +//* group unary //- //- An arithmetic inverter. This corresponds to the Verilog unary prefix '-' operator. //- @@ -258,6 +259,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $reduce_and (A, Y) +//* group unary //- //- An AND reduction. This corresponds to the Verilog unary prefix '&' operator. //- @@ -285,6 +287,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $reduce_or (A, Y) +//* group unary //- //- An OR reduction. This corresponds to the Verilog unary prefix '|' operator. //- @@ -312,6 +315,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $reduce_xor (A, Y) +//* group unary //- //- A XOR reduction. This corresponds to the Verilog unary prefix '^' operator. //- @@ -339,6 +343,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $reduce_xnor (A, Y) +//* group unary //- //- A XNOR reduction. This corresponds to the Verilog unary prefix '~^' operator. //- @@ -366,6 +371,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $reduce_bool (A, Y) +//* group unary //- //- An OR reduction. This cell type is used instead of $reduce_or when a signal is //- implicitly converted to a boolean signal, e.g. for operands of '&&' and '||'. @@ -1359,6 +1365,7 @@ endmodule //- //- A logical inverter. This corresponds to the Verilog unary prefix '!' operator. //- +//* group unary module \$logic_not (A, Y); parameter A_SIGNED = 0; From a119d41303aeadd79931e4ac8dbd1892bdcec6a3 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Tue, 21 May 2024 12:17:39 +1200 Subject: [PATCH 28/68] Docs: Move appendix toc to main toc Adds an Appendix header to sidebar toc instead of being an (empty) subpage. --- docs/source/appendix.rst | 25 ------------------------- docs/source/index.rst | 23 ++++++++++++++++------- 2 files changed, 16 insertions(+), 32 deletions(-) delete mode 100644 docs/source/appendix.rst diff --git a/docs/source/appendix.rst b/docs/source/appendix.rst deleted file mode 100644 index 4a8976be092..00000000000 --- a/docs/source/appendix.rst +++ /dev/null @@ -1,25 +0,0 @@ -Appendix -======== - -.. autocell:: simlib.v:$alu - :source: - :linenos: - -.. autocell:: simlib.v:$lcu - -.. toctree:: - :maxdepth: 2 - :includehidden: - - appendix/primer - appendix/auxlibs - appendix/auxprogs - - bib - -.. toctree:: - :maxdepth: 1 - :includehidden: - - cmd_ref - cell_ref diff --git a/docs/source/index.rst b/docs/source/index.rst index b76b5fe062c..ce612f9b0bc 100644 --- a/docs/source/index.rst +++ b/docs/source/index.rst @@ -27,19 +27,28 @@ available, go to :ref:`commandindex`. .. todolist:: -.. only:: html - - Table of contents - ----------------- - .. toctree:: :maxdepth: 3 :includehidden: - self + Yosys (index) introduction + getting_started/index using_yosys/index yosys_internals/index - appendix +.. toctree:: + :caption: Appendix + :titlesonly: + :includehidden: + + appendix/primer + appendix/auxlibs + appendix/auxprogs + + bib + + cell_word + cell_gate + cmd_ref From 9533cf2916b02aeb9be51ac3b440274b35f1023a Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Tue, 21 May 2024 14:04:38 +1200 Subject: [PATCH 29/68] Makefile: Use dump-cells-json for docs --- Makefile | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 87e62adb593..e5ca83aeafe 100644 --- a/Makefile +++ b/Makefile @@ -993,6 +993,9 @@ docs/source/cell/word_add.rst: $(TARGETS) $(EXTRA_TARGETS) $(Q) rsync -rc temp/docs/source/cell docs/source $(Q) rm -rf temp +docs/source/generated/cells.json: docs/source/generated $(TARGETS) $(EXTRA_TARGETS) + $(Q) ./$(PROGRAM_PREFIX)yosys -p 'help -dump-cells-json $@' + PHONY: docs/gen_examples docs/gen_images docs/guidelines docs/usage docs/reqs docs/gen_examples: $(TARGETS) $(Q) $(MAKE) -C docs examples @@ -1034,7 +1037,7 @@ docs/reqs: $(Q) $(MAKE) -C docs reqs .PHONY: docs/prep -docs/prep: docs/source/cmd/abc.rst docs/source/cell/word_add.rst docs/gen_examples docs/gen_images docs/guidelines docs/usage +docs/prep: docs/source/cmd/abc.rst docs/source/generated/cells.json docs/gen_examples docs/gen_images docs/guidelines docs/usage DOC_TARGET ?= html docs: docs/prep From 37573a6f00a8d8ed9ef5a16b5f1ac718c66b07aa Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Tue, 21 May 2024 14:06:08 +1200 Subject: [PATCH 30/68] Docs: Use json for cellref e.g. ``` .. autocell:: $alu :source: :linenos: ``` --- docs/util/cellref.py | 155 +++++++++++++------------------------------ 1 file changed, 45 insertions(+), 110 deletions(-) diff --git a/docs/util/cellref.py b/docs/util/cellref.py index 4b970310158..0d5c9ba563a 100644 --- a/docs/util/cellref.py +++ b/docs/util/cellref.py @@ -1,6 +1,8 @@ #!/usr/bin/env python3 from __future__ import annotations +from dataclasses import dataclass +import json from pathlib import Path, PosixPath, WindowsPath import re @@ -15,94 +17,55 @@ # cell signature cell_ext_sig_re = re.compile( r'''^ (?:([^:\s]+):)? # explicit file name - ([\w$._]+?)? # module and/or class name(s) + ([\w$._]+?) # module name (?:\.([\w_]+))? # optional: thing name (::[\w_]+)? # attribute \s* $ # and nothing more ''', re.VERBOSE) -class SimHelper: - name: str = "" - title: str = "" - ports: str = "" - source: str = "" - desc: list[str] - code: list[str] - group: str = "" - ver: str = "1" - - def __init__(self) -> None: - self.desc = [] - -def simcells_reparse(cell: SimHelper): - # cut manual signature - cell.desc = cell.desc[3:] - - # code-block truth table - new_desc = [] - indent = "" - for line in cell.desc: - if line.startswith("Truth table:"): - indent = " " - new_desc.pop() - new_desc.extend(["::", ""]) - new_desc.append(indent + line) - cell.desc = new_desc - - # set version - cell.ver = "2a" - -def load_cell_lib(file: Path): - simHelpers: dict[str, SimHelper] = {} - simHelper = SimHelper() - with open(file, "r") as f: - lines = f.readlines() - - for lineno, line in enumerate(lines, 1): - line = line.rstrip() - # special comments - if line.startswith("//-"): - simHelper.desc.append(line[4:] if len(line) > 4 else "") - elif line.startswith("//* "): - _, key, val = line.split(maxsplit=2) - setattr(simHelper, key, val) - - # code parsing - if line.startswith("module "): - clean_line = line[7:].replace("\\", "").replace(";", "") - simHelper.name, simHelper.ports = clean_line.split(maxsplit=1) - simHelper.code = [] - simHelper.source = f'{file.name}:{lineno}' - elif not line.startswith("endmodule"): - line = " " + line - try: - simHelper.code.append(line.replace("\t", " ")) - except AttributeError: - # no module definition, ignore line - pass - if line.startswith("endmodule"): - if simHelper.ver == "1" and file.name == "simcells.v": - # default simcells parsing - simcells_reparse(simHelper) - if not simHelper.desc: - # no help - simHelper.desc.append("No help message for this cell type found.\n") - elif simHelper.ver == "1" and file.name == "simlib.v" and simHelper.desc[1].startswith(' '): - simHelper.desc.pop(1) - simHelpers[simHelper.name] = simHelper - simHelper = SimHelper() - return simHelpers +@dataclass +class YosysCell: + cell: str + title: str + ports: str + source: str + desc: str + code: str + inputs: list[str] + outputs: list[str] + properties: dict[str, bool] class YosysCellDocumenter(Documenter): objtype = 'cell' - parsed_libs: dict[Path, dict[str, SimHelper]] = {} - object: SimHelper + object: YosysCell option_spec = { 'source': autodoc.bool_option, 'linenos': autodoc.bool_option, } + __cell_lib: dict[str, YosysCell] | None = None + @property + def cell_lib(self) -> dict[str, YosysCell]: + if not self.__cell_lib: + self.__cell_lib = {} + cells_obj: dict[str, list[dict[str, list[dict[str]]]]] + try: + with open(self.config.cells_json, "r") as f: + cells_obj = json.loads(f.read()) + except FileNotFoundError: + logger.warning( + f"unable to find cell lib at {self.config.cells_json}", + type = 'cellref', + subtype = 'cell_lib' + ) + else: + for group in cells_obj.get("groups", []): + for cell in group.get("cells", []): + yosysCell = YosysCell(**cell) + self.__cell_lib[yosysCell.cell] = yosysCell + return self.__cell_lib + @classmethod def can_document_member( cls, @@ -125,9 +88,6 @@ def parse_name(self) -> bool: logger.warning(('invalid signature for auto%s (%r)') % (self.objtype, self.name), type='cellref') return False - - if not path: - return False self.modname = modname self.objpath = [path] @@ -137,45 +97,23 @@ def parse_name(self) -> bool: return True def import_object(self, raiseerror: bool = False) -> bool: - # find cell lib file - objpath = Path('/'.join(self.objpath)) - if not objpath.exists(): - cells_loc: Path = self.config.cells_loc - objpath = cells_loc / objpath - - # load cell lib - try: - parsed_lib = self.parsed_libs[objpath] - except KeyError: - try: - parsed_lib = load_cell_lib(objpath) - except FileNotFoundError: - logger.warning( - f"unable to find cell lib at {'/'.join(self.objpath)}", - type = 'cellref', - subtype = 'import_object' - ) - return False - self.parsed_libs[objpath] = parsed_lib - - # get cell try: - self.object = parsed_lib[self.modname] + self.object = self.cell_lib[self.modname] except KeyError: return False - self.real_modname = f'{objpath}:{self.modname}' + self.real_modname = self.modname or '' return True def get_sourcename(self) -> str: - return self.objpath + return self.object.source.split(":")[0] def format_name(self) -> str: - return self.object.name + return self.object.cell def format_signature(self, **kwargs: Any) -> str: - return f"{self.object.name} {self.object.ports}" + return f"{self.object.cell} {self.object.ports}" def add_directive_header(self, sig: str) -> None: domain = getattr(self, 'domain', self.objtype) @@ -202,7 +140,7 @@ def add_content(self, more_content: Any | None) -> None: sourcename = self.get_sourcename() startline = int(self.object.source.split(":")[1]) - for i, line in enumerate(self.object.desc, startline): + for i, line in enumerate(self.object.desc.splitlines(), startline): self.add_line(line, sourcename, i) # add additional content (e.g. from document), if present @@ -321,9 +259,6 @@ def can_document_member( isattr: bool, parent: Any ) -> bool: - sourcename = str(member).split(":")[0] - if not sourcename.endswith(".v"): - return False if membername != "__source": return False if isinstance(parent, YosysCellDocumenter): @@ -358,7 +293,7 @@ def add_content(self, more_content: Any | None) -> None: sourcename = self.get_sourcename() startline = int(self.object.source.split(":")[1]) - for i, line in enumerate(self.object.code, startline-1): + for i, line in enumerate(self.object.code.splitlines(), startline-1): self.add_line(line, sourcename, i) # add additional content (e.g. from document), if present @@ -373,7 +308,7 @@ def get_object_members( return False, [] def setup(app: Sphinx) -> dict[str, Any]: - app.add_config_value('cells_loc', False, 'html', [Path, PosixPath, WindowsPath]) + app.add_config_value('cells_json', False, 'html', [Path, PosixPath, WindowsPath]) app.setup_extension('sphinx.ext.autodoc') app.add_autodocumenter(YosysCellDocumenter) app.add_autodocumenter(YosysCellSourceDocumenter) From 65723200e5edbb6f19ad1fb60dd27be86994e2bb Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Tue, 21 May 2024 14:06:28 +1200 Subject: [PATCH 31/68] Docs: Delete unused cell_ref.rst --- docs/source/cell_ref.rst | 13 ------------- 1 file changed, 13 deletions(-) delete mode 100644 docs/source/cell_ref.rst diff --git a/docs/source/cell_ref.rst b/docs/source/cell_ref.rst deleted file mode 100644 index dc143124edb..00000000000 --- a/docs/source/cell_ref.rst +++ /dev/null @@ -1,13 +0,0 @@ -.. _cell_ref: - -================================================================================ -Internal cell reference -================================================================================ - -.. toctree:: - :caption: Internal cell reference - :maxdepth: 2 - :glob: - - cell_word - cell_gate From 5a4a4191af072bee5d19008a5708fa9074cb2601 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Tue, 21 May 2024 14:06:57 +1200 Subject: [PATCH 32/68] Docs: Update conf.py for cellref --- docs/source/conf.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/source/conf.py b/docs/source/conf.py index e16179cb03c..8e504df5577 100644 --- a/docs/source/conf.py +++ b/docs/source/conf.py @@ -80,7 +80,7 @@ # use autodocs extensions.append('sphinx.ext.autodoc') extensions.append('util.cellref') -cells_loc = Path(__file__).parent / 'generated' +cells_json = Path(__file__).parent / 'generated' / 'cells.json' from sphinx.application import Sphinx def setup(app: Sphinx) -> None: From b127ac07f8e7f1d9316a1cc06e3fa2e216bcbe0d Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Tue, 21 May 2024 18:10:20 +1200 Subject: [PATCH 33/68] Docs: Preliminary autocellgroup usage Remove `/source/cell` from .gitignore. Add a few initial cell pages. Add YosysCellGroup documenter and cell:group directive. Update Documenters to use nested json. Better nested tocs for group.module.source layout. --- docs/.gitignore | 1 - docs/source/cell/gate_other.rst | 5 + docs/source/cell/word_other.rst | 5 + docs/source/cell/word_unary.rst | 50 ++++++++ docs/source/cell_gate.rst | 5 +- docs/source/cell_word.rst | 6 +- docs/util/cellref.py | 205 ++++++++++++++++++++++---------- docs/util/cmdref.py | 103 ++++++++++++---- kernel/register.cc | 81 +++++++------ 9 files changed, 331 insertions(+), 130 deletions(-) create mode 100644 docs/source/cell/gate_other.rst create mode 100644 docs/source/cell/word_other.rst create mode 100644 docs/source/cell/word_unary.rst diff --git a/docs/.gitignore b/docs/.gitignore index 78a1f48e1a0..65bbcdeaeb8 100644 --- a/docs/.gitignore +++ b/docs/.gitignore @@ -1,6 +1,5 @@ /build/ /source/cmd -/source/cell /source/generated /source/_images/**/*.log /source/_images/**/*.aux diff --git a/docs/source/cell/gate_other.rst b/docs/source/cell/gate_other.rst new file mode 100644 index 00000000000..7696ba824e9 --- /dev/null +++ b/docs/source/cell/gate_other.rst @@ -0,0 +1,5 @@ +.. autocellgroup:: gate_other + :caption: Other gate-level cells + :members: + :source: + :linenos: diff --git a/docs/source/cell/word_other.rst b/docs/source/cell/word_other.rst new file mode 100644 index 00000000000..9e5ac2a3778 --- /dev/null +++ b/docs/source/cell/word_other.rst @@ -0,0 +1,5 @@ +.. autocellgroup:: word_other + :caption: Other word-level cells + :members: + :source: + :linenos: diff --git a/docs/source/cell/word_unary.rst b/docs/source/cell/word_unary.rst new file mode 100644 index 00000000000..59f03397c83 --- /dev/null +++ b/docs/source/cell/word_unary.rst @@ -0,0 +1,50 @@ +.. role:: verilog(code) + :language: Verilog + +Unary operators +--------------- + +All unary RTL cells have one input port ``A`` and one output port ``Y``. They +also have the following parameters: + +``A_SIGNED`` + Set to a non-zero value if the input ``A`` is signed and therefore should be + sign-extended when needed. + +``A_WIDTH`` + The width of the input port ``A``. + +``Y_WIDTH`` + The width of the output port ``Y``. + +.. table:: Cell types for unary operators with their corresponding Verilog expressions. + + ================== ============== + Verilog Cell Type + ================== ============== + :verilog:`Y = ~A` `$not` + :verilog:`Y = +A` `$pos` + :verilog:`Y = -A` `$neg` + :verilog:`Y = &A` `$reduce_and` + :verilog:`Y = |A` `$reduce_or` + :verilog:`Y = ^A` `$reduce_xor` + :verilog:`Y = ~^A` `$reduce_xnor` + :verilog:`Y = |A` `$reduce_bool` + :verilog:`Y = !A` `$logic_not` + ================== ============== + +For the unary cells that output a logical value (`$reduce_and`, `$reduce_or`, +`$reduce_xor`, `$reduce_xnor`, `$reduce_bool`, `$logic_not`), when the +``Y_WIDTH`` parameter is greater than 1, the output is zero-extended, and only +the least significant bit varies. + +Note that `$reduce_or` and `$reduce_bool` actually represent the same logic +function. But the HDL frontends generate them in different situations. A +`$reduce_or` cell is generated when the prefix ``|`` operator is being used. A +`$reduce_bool` cell is generated when a bit vector is used as a condition in an +``if``-statement or ``?:``-expression. + +.. autocellgroup:: unary + :members: + :source: + :linenos: diff --git a/docs/source/cell_gate.rst b/docs/source/cell_gate.rst index 74dd57bc727..0e977c58798 100644 --- a/docs/source/cell_gate.rst +++ b/docs/source/cell_gate.rst @@ -3,7 +3,6 @@ Gate-level cells .. toctree:: :caption: Gate-level cells - :maxdepth: 1 - :glob: + :maxdepth: 2 - /cell/gate_* + /cell/gate_other diff --git a/docs/source/cell_word.rst b/docs/source/cell_word.rst index f7205e6eee3..9b781132468 100644 --- a/docs/source/cell_word.rst +++ b/docs/source/cell_word.rst @@ -2,8 +2,8 @@ Word-level cells ---------------- .. toctree:: - :caption: Word-level cells - :maxdepth: 1 + :maxdepth: 2 :glob: - /cell/word_* + /cell/word_unary + /cell/word_other diff --git a/docs/util/cellref.py b/docs/util/cellref.py index 0d5c9ba563a..3bba278763b 100644 --- a/docs/util/cellref.py +++ b/docs/util/cellref.py @@ -16,7 +16,7 @@ # cell signature cell_ext_sig_re = re.compile( - r'''^ (?:([^:\s]+):)? # explicit file name + r'''^ ([^:\s]+::)? # optional group or file name ([\w$._]+?) # module name (?:\.([\w_]+))? # optional: thing name (::[\w_]+)? # attribute @@ -25,7 +25,7 @@ @dataclass class YosysCell: - cell: str + name: str title: str ports: str source: str @@ -34,22 +34,26 @@ class YosysCell: inputs: list[str] outputs: list[str] properties: dict[str, bool] - -class YosysCellDocumenter(Documenter): - objtype = 'cell' - object: YosysCell + +class YosysCellGroupDocumenter(Documenter): + objtype = 'cellgroup' + priority = 10 + object: tuple[str, list[str]] + lib_key = 'groups' option_spec = { + 'caption': autodoc.annotation_option, + 'members': autodoc.members_option, 'source': autodoc.bool_option, 'linenos': autodoc.bool_option, } - __cell_lib: dict[str, YosysCell] | None = None + __cell_lib: dict[str, list[str] | dict[str]] | None = None @property - def cell_lib(self) -> dict[str, YosysCell]: + def cell_lib(self) -> dict[str, list[str] | dict[str]]: if not self.__cell_lib: self.__cell_lib = {} - cells_obj: dict[str, list[dict[str, list[dict[str]]]]] + cells_obj: dict[str, dict[str, list[str] | dict[str]]] try: with open(self.config.cells_json, "r") as f: cells_obj = json.loads(f.read()) @@ -60,12 +64,10 @@ def cell_lib(self) -> dict[str, YosysCell]: subtype = 'cell_lib' ) else: - for group in cells_obj.get("groups", []): - for cell in group.get("cells", []): - yosysCell = YosysCell(**cell) - self.__cell_lib[yosysCell.cell] = yosysCell + for (name, obj) in cells_obj.get(self.lib_key, {}).items(): + self.__cell_lib[name] = obj return self.__cell_lib - + @classmethod def can_document_member( cls, @@ -74,75 +76,51 @@ def can_document_member( isattr: bool, parent: Any ) -> bool: - sourcename = str(member).split(":")[0] - if not sourcename.endswith(".v"): - return False - if membername == "__source": - return False + return False def parse_name(self) -> bool: - try: - matched = cell_ext_sig_re.match(self.name) - path, modname, thing, attribute = matched.groups() - except AttributeError: - logger.warning(('invalid signature for auto%s (%r)') % (self.objtype, self.name), - type='cellref') - return False - - self.modname = modname - self.objpath = [path] - self.attribute = attribute - self.fullname = ((self.modname) + (thing or '')) - + if not self.options.caption: + self.content_indent = '' + self.fullname = self.modname = self.name return True def import_object(self, raiseerror: bool = False) -> bool: # get cell try: - self.object = self.cell_lib[self.modname] + self.object = (self.modname, self.cell_lib[self.modname]) except KeyError: + if raiseerror: + raise return False - self.real_modname = self.modname or '' + self.real_modname = self.modname return True def get_sourcename(self) -> str: - return self.object.source.split(":")[0] + return self.env.doc2path(self.env.docname) def format_name(self) -> str: - return self.object.cell + return self.options.caption or '' def format_signature(self, **kwargs: Any) -> str: - return f"{self.object.cell} {self.object.ports}" + return self.modname def add_directive_header(self, sig: str) -> None: - domain = getattr(self, 'domain', self.objtype) - directive = getattr(self, 'directivetype', 'def') + domain = getattr(self, 'domain', 'cell') + directive = getattr(self, 'directivetype', 'group') name = self.format_name() sourcename = self.get_sourcename() - cell = self.object + cell_list = self.object # cell definition - self.add_line(f'.. {domain}:{directive}:: {name}', sourcename) - - # options - opt_attrs = ["title", ] - for attr in opt_attrs: - val = getattr(cell, attr, None) - if val: - self.add_line(f' :{attr}: {val}', sourcename) + self.add_line(f'.. {domain}:{directive}:: {sig}', sourcename) + self.add_line(f' :caption: {name}', sourcename) if self.options.noindex: self.add_line(' :noindex:', sourcename) def add_content(self, more_content: Any | None) -> None: - # set sourcename and add content from attribute documentation - sourcename = self.get_sourcename() - startline = int(self.object.source.split(":")[1]) - - for i, line in enumerate(self.object.desc.splitlines(), startline): - self.add_line(line, sourcename, i) - + # groups have no native content # add additional content (e.g. from document), if present if more_content: for line, src in zip(more_content.data, more_content.items): @@ -161,14 +139,25 @@ def get_object_members( ) -> tuple[bool, list[tuple[str, Any]]]: ret: list[tuple[str, str]] = [] - if self.options.source: - ret.append(('__source', self.real_modname)) + if want_all: + for member in self.object[1]: + ret.append((member, self.modname)) + else: + memberlist = self.options.members or [] + for name in memberlist: + if name in self.object: + ret.append((name, self.modname)) + else: + logger.warning(('unknown module mentioned in :members: option: ' + f'group {self.modname}, module {name}'), + type='cellref') return False, ret def document_members(self, all_members: bool = False) -> None: want_all = (all_members or - self.options.inherited_members) + self.options.inherited_members or + self.options.members is autodoc.ALL) # find out which members are documentable members_check_module, members = self.get_object_members(want_all) @@ -184,7 +173,7 @@ def document_members(self, all_members: bool = False) -> None: classes.sort(key=lambda cls: cls.priority) # give explicitly separated module name, so that members # of inner classes can be documented - full_mname = self.real_modname + '::' + mname + full_mname = self.format_signature() + '::' + mname documenter = classes[-1](self.directive, full_mname, self.indent) memberdocumenters.append((documenter, isattr)) @@ -247,6 +236,101 @@ def generate( # document members, if possible self.document_members(all_members) +class YosysCellDocumenter(YosysCellGroupDocumenter): + objtype = 'cell' + priority = 15 + object: YosysCell + lib_key = 'cells' + + @classmethod + def can_document_member( + cls, + member: Any, + membername: str, + isattr: bool, + parent: Any + ) -> bool: + if membername == "__source": + return False + if not membername.startswith('$'): + return False + return isinstance(parent, YosysCellGroupDocumenter) + + def parse_name(self) -> bool: + try: + matched = cell_ext_sig_re.match(self.name) + group, modname, thing, attribute = matched.groups() + except AttributeError: + logger.warning(('invalid signature for auto%s (%r)') % (self.objtype, self.name), + type='cellref') + return False + + self.modname = modname + self.groupname = group or '' + self.attribute = attribute or '' + self.fullname = ((self.modname) + (thing or '')) + + return True + + def import_object(self, raiseerror: bool = False) -> bool: + if super().import_object(raiseerror): + self.object = YosysCell(self.modname, **self.object[1]) + return True + return False + + def get_sourcename(self) -> str: + return self.object.source.split(":")[0] + + def format_name(self) -> str: + return self.object.name + + def format_signature(self, **kwargs: Any) -> str: + return self.groupname + self.fullname + self.attribute + + def add_directive_header(self, sig: str) -> None: + domain = getattr(self, 'domain', self.objtype) + directive = getattr(self, 'directivetype', 'def') + name = self.format_name() + sourcename = self.get_sourcename() + cell = self.object + + # cell definition + self.add_line(f'.. {domain}:{directive}:: {sig}', sourcename) + + # options + opt_attrs = ["title", ] + for attr in opt_attrs: + val = getattr(cell, attr, None) + if val: + self.add_line(f' :{attr}: {val}', sourcename) + + if self.options.noindex: + self.add_line(' :noindex:', sourcename) + + def add_content(self, more_content: Any | None) -> None: + # set sourcename and add content from attribute documentation + sourcename = self.get_sourcename() + startline = int(self.object.source.split(":")[1]) + + for i, line in enumerate(self.object.desc.splitlines(), startline): + self.add_line(line, sourcename, i) + + # add additional content (e.g. from document), if present + if more_content: + for line, src in zip(more_content.data, more_content.items): + self.add_line(line, src[0], src[1]) + + def get_object_members( + self, + want_all: bool + ) -> tuple[bool, list[tuple[str, Any]]]: + ret: list[tuple[str, str]] = [] + + if self.options.source: + ret.append(('__source', self.real_modname)) + + return False, ret + class YosysCellSourceDocumenter(YosysCellDocumenter): objtype = 'cellsource' priority = 20 @@ -273,7 +357,7 @@ def add_directive_header(self, sig: str) -> None: cell = self.object # cell definition - self.add_line(f'.. {domain}:{directive}:: {name}', sourcename) + self.add_line(f'.. {domain}:{directive}:: {sig}', sourcename) if self.options.linenos: self.add_line(f' :source: {cell.source.split(":")[0]}', sourcename) @@ -312,6 +396,7 @@ def setup(app: Sphinx) -> dict[str, Any]: app.setup_extension('sphinx.ext.autodoc') app.add_autodocumenter(YosysCellDocumenter) app.add_autodocumenter(YosysCellSourceDocumenter) + app.add_autodocumenter(YosysCellGroupDocumenter) return { 'version': '1', 'parallel_read_safe': True, diff --git a/docs/util/cmdref.py b/docs/util/cmdref.py index df1f3fb21ab..6fbd813726d 100644 --- a/docs/util/cmdref.py +++ b/docs/util/cmdref.py @@ -15,7 +15,16 @@ from sphinx.util.nodes import make_refnode from sphinx import addnodes -class TocNode(ObjectDescription): +class TocNode(ObjectDescription): + def add_target_and_index( + self, + name: str, + sig: str, + signode: addnodes.desc_signature + ) -> None: + idx = ".".join(name.split("::")) + signode['ids'].append(idx) + def _object_hierarchy_parts(self, sig_node: addnodes.desc_signature) -> tuple[str, ...]: if 'fullname' not in sig_node: return () @@ -34,17 +43,13 @@ def _toc_entry_name(self, sig_node: addnodes.desc_signature) -> str: config = self.env.app.config objtype = sig_node.parent.get('objtype') - if config.add_function_parentheses and objtype in {'function', 'method'}: - parens = '()' - else: - parens = '' *parents, name = sig_node['_toc_parts'] if config.toc_object_entries_show_parents == 'domain': - return sig_node.get('fullname', name) + parens + return sig_node.get('tocname', name) if config.toc_object_entries_show_parents == 'hide': - return name + parens + return name if config.toc_object_entries_show_parents == 'all': - return '.'.join(parents + [name + parens]) + return '.'.join(parents + [name]) return '' class CommandNode(TocNode): @@ -59,11 +64,10 @@ class CommandNode(TocNode): } def handle_signature(self, sig, signode: addnodes.desc_signature): - fullname = sig - signode['fullname'] = fullname + signode['fullname'] = sig signode += addnodes.desc_addname(text="yosys> help ") signode += addnodes.desc_name(text=sig) - return fullname + return signode['fullname'] def add_target_and_index(self, name_cls, sig, signode): signode['ids'].append(type(self).name + '-' + sig) @@ -82,11 +86,47 @@ def add_target_and_index(self, name_cls, sig, signode): type(self).name + '-' + sig, 0)) -class CellNode(CommandNode): +class CellNode(TocNode): """A custom node that describes an internal cell.""" name = 'cell' + option_spec = { + 'title': directives.unchanged, + 'ports': directives.unchanged, + } + + def handle_signature(self, sig: str, signode: addnodes.desc_signature): + signode['fullname'] = sig + signode['tocname'] = tocname = sig.split('::')[-1] + signode += addnodes.desc_addname(text="yosys> help ") + signode += addnodes.desc_name(text=tocname) + return signode['fullname'] + + def add_target_and_index( + self, + name: str, + sig: str, + signode: addnodes.desc_signature + ) -> None: + idx = ".".join(name.split("::")) + signode['ids'].append(idx) + if 'noindex' not in self.options: + tocname: str = signode.get('tocname', name) + tagmap = self.env.domaindata[self.domain]['obj2tag'] + tagmap[name] = list(self.options.get('tags', '').split(' ')) + title: str = self.options.get('title', sig) + titlemap = self.env.domaindata[self.domain]['obj2title'] + titlemap[name] = title + objs = self.env.domaindata[self.domain]['objects'] + # (name, sig, typ, docname, anchor, prio) + objs.append((name, + tocname, + title, + self.env.docname, + idx, + 0)) + class CellSourceNode(TocNode): """A custom code block for including cell source.""" @@ -104,21 +144,12 @@ def handle_signature( signode: addnodes.desc_signature ) -> str: language = self.options.get('language') - fullname = sig + "::" + language - signode['fullname'] = fullname + signode['fullname'] = sig + signode['tocname'] = f"{sig.split('::')[-2]} {language}" signode += addnodes.desc_name(text="Simulation model") signode += addnodes.desc_sig_space() signode += addnodes.desc_addname(text=f'({language})') - return fullname - - def add_target_and_index( - self, - name: str, - sig: str, - signode: addnodes.desc_signature - ) -> None: - idx = f'{".".join(self.name.split(":"))}.{sig}' - signode['ids'].append(idx) + return signode['fullname'] def run(self) -> list[Node]: """Override run to parse content as a code block""" @@ -192,6 +223,29 @@ def run(self) -> list[Node]: return [self.indexnode, node, literal] +class CellGroupNode(TocNode): + name = 'cellgroup' + + option_spec = { + 'caption': directives.unchanged, + } + + def add_target_and_index(self, name: str, sig: str, signode: addnodes.desc_signature) -> None: + if self.options.get('caption', ''): + super().add_target_and_index(name, sig, signode) + + def handle_signature( + self, + sig, + signode: addnodes.desc_signature + ) -> str: + signode['fullname'] = fullname = sig + caption = self.options.get("caption", fullname) + if caption: + signode['tocname'] = caption + signode += addnodes.desc_name(text=caption) + return fullname + class TagIndex(Index): """A custom directive that creates a tag matrix.""" @@ -368,6 +422,7 @@ class CellDomain(CommandDomain): directives = { 'def': CellNode, 'source': CellSourceNode, + 'group': CellGroupNode, } indices = { diff --git a/kernel/register.cc b/kernel/register.cc index 4e8e62741a0..bc49f4cb914 100644 --- a/kernel/register.cc +++ b/kernel/register.cc @@ -958,7 +958,8 @@ struct HelpPass : public Pass { json.entry("version", "Yosys internal cells"); json.entry("generator", yosys_version_str); - dict>> groups; + dict> groups; + dict> cells; // iterate over cells bool raise_error = false; @@ -966,59 +967,61 @@ struct HelpPass : public Pass { auto name = it.first.str(); if (cell_help_messages.contains(name)) { auto cell_help = cell_help_messages.get(name); - dict> *cell_group; if (groups.count(cell_help.group) != 0) { - cell_group = &groups.at(cell_help.group); + auto group_cells = &groups.at(cell_help.group); + group_cells->push_back(name); } else { - cell_group = new dict>(); - groups.emplace(cell_help.group, *cell_group); + auto group_cells = new vector(1, name); + groups.emplace(cell_help.group, *group_cells); } auto cell_pair = pair(cell_help, it.second); - cell_group->emplace(name, cell_pair); + cells.emplace(name, cell_pair); } else { log("ERROR: Missing cell help for cell '%s'.\n", name.c_str()); raise_error |= true; } } + for (auto &it : cell_help_messages.cell_help) { + if (cells.count(it.first) == 0) { + log_warning("Found cell model '%s' without matching cell type.\n", it.first.c_str()); + } + } // write to json - json.name("groups"); - json.begin_array(); + json.name("groups"); json.begin_object(); groups.sort(); for (auto &it : groups) { - json.begin_object(); - json.name("group"); json.value(it.first.c_str()); - json.name("cells"); json.begin_array(); - for (auto &it2 : it.second) { - auto ch = it2.second.first; - auto ct = it2.second.second; - json.begin_object(); - json.name("cell"); json.value(ch.name); - json.name("title"); json.value(ch.title); - json.name("ports"); json.value(ch.ports); - json.name("source"); json.value(ch.source); - json.name("desc"); json.value(ch.desc); - json.name("code"); json.value(ch.code); - json.name("inputs"); json.begin_array(); - for (auto &input : ct.inputs) - json.value(input.c_str()); - json.end_array(); - json.name("outputs"); json.begin_array(); - for (auto &output : ct.outputs) - json.value(output.c_str()); - json.end_array(); - dict prop_dict = { - {"is_evaluable", ct.is_evaluable}, - {"is_combinatorial", ct.is_combinatorial}, - {"is_synthesizable", ct.is_synthesizable}, - }; - json.name("properties"); json.value(prop_dict); - json.end_object(); - } - json.end_array(); + json.name(it.first.c_str()); json.value(it.second); + } + json.end_object(); + + json.name("cells"); json.begin_object(); + cells.sort(); + for (auto &it : cells) { + auto ch = it.second.first; + auto ct = it.second.second; + json.name(ch.name.c_str()); json.begin_object(); + json.name("title"); json.value(ch.title); + json.name("ports"); json.value(ch.ports); + json.name("source"); json.value(ch.source); + json.name("desc"); json.value(ch.desc); + json.name("code"); json.value(ch.code); + vector inputs, outputs; + for (auto &input : ct.inputs) + inputs.push_back(input.str()); + json.name("inputs"); json.value(inputs); + for (auto &output : ct.outputs) + outputs.push_back(output.str()); + json.name("outputs"); json.value(outputs); + dict prop_dict = { + {"is_evaluable", ct.is_evaluable}, + {"is_combinatorial", ct.is_combinatorial}, + {"is_synthesizable", ct.is_synthesizable}, + }; + json.name("properties"); json.value(prop_dict); json.end_object(); } - json.end_array(); + json.end_object(); json.end_object(); return raise_error; From c66252931612020d22258b02091bcff6f1e6b095 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Mon, 27 May 2024 12:31:42 +1200 Subject: [PATCH 34/68] Docs: Move binary operators to cell appendix Add binary group tag to relevant cells. Remove content from `cell_library.rst` that is already moved. --- docs/source/cell/word_binary.rst | 91 +++++++++++ docs/source/cell_word.rst | 13 ++ .../yosys_internals/formats/cell_library.rst | 151 ------------------ techlibs/common/simlib.v | 30 +++- 4 files changed, 133 insertions(+), 152 deletions(-) create mode 100644 docs/source/cell/word_binary.rst diff --git a/docs/source/cell/word_binary.rst b/docs/source/cell/word_binary.rst new file mode 100644 index 00000000000..47a847ee446 --- /dev/null +++ b/docs/source/cell/word_binary.rst @@ -0,0 +1,91 @@ +.. role:: verilog(code) + :language: Verilog + +Binary operators +~~~~~~~~~~~~~~~~ + +All binary RTL cells have two input ports ``A`` and ``B`` and one output port +``Y``. They also have the following parameters: + +``A_SIGNED`` + Set to a non-zero value if the input ``A`` is signed and therefore should be + sign-extended when needed. + +``A_WIDTH`` + The width of the input port ``A``. + +``B_SIGNED`` + Set to a non-zero value if the input ``B`` is signed and therefore should be + sign-extended when needed. + +``B_WIDTH`` + The width of the input port ``B``. + +``Y_WIDTH`` + The width of the output port ``Y``. + +.. table:: Cell types for binary operators with their corresponding Verilog expressions. + + ======================= =============== ======================= =========== + Verilog Cell Type Verilog Cell Type + ======================= =============== ======================= =========== + :verilog:`Y = A & B` `$and` :verilog:`Y = A ** B` `$pow` + :verilog:`Y = A | B` `$or` :verilog:`Y = A < B` `$lt` + :verilog:`Y = A ^ B` `$xor` :verilog:`Y = A <= B` `$le` + :verilog:`Y = A ~^ B` `$xnor` :verilog:`Y = A == B` `$eq` + :verilog:`Y = A << B` `$shl` :verilog:`Y = A != B` `$ne` + :verilog:`Y = A >> B` `$shr` :verilog:`Y = A >= B` `$ge` + :verilog:`Y = A <<< B` `$sshl` :verilog:`Y = A > B` `$gt` + :verilog:`Y = A >>> B` `$sshr` :verilog:`Y = A + B` `$add` + :verilog:`Y = A && B` `$logic_and` :verilog:`Y = A - B` `$sub` + :verilog:`Y = A || B` `$logic_or` :verilog:`Y = A * B` `$mul` + :verilog:`Y = A === B` `$eqx` :verilog:`Y = A / B` `$div` + :verilog:`Y = A !== B` `$nex` :verilog:`Y = A % B` `$mod` + ``N/A`` `$shift` ``N/A`` `$divfloor` + ``N/A`` `$shiftx` ``N/A`` `$modfloor` + ======================= =============== ======================= =========== + +The `$shl` and `$shr` cells implement logical shifts, whereas the `$sshl` and +`$sshr` cells implement arithmetic shifts. The `$shl` and `$sshl` cells +implement the same operation. All four of these cells interpret the second +operand as unsigned, and require ``B_SIGNED`` to be zero. + +Two additional shift operator cells are available that do not directly +correspond to any operator in Verilog, `$shift` and `$shiftx`. The `$shift` cell +performs a right logical shift if the second operand is positive (or unsigned), +and a left logical shift if it is negative. The `$shiftx` cell performs the same +operation as the `$shift` cell, but the vacated bit positions are filled with +undef (x) bits, and corresponds to the Verilog indexed part-select expression. + +For the binary cells that output a logical value (`$logic_and`, `$logic_or`, +`$eqx`, `$nex`, `$lt`, `$le`, `$eq`, `$ne`, `$ge`, `$gt`), when the ``Y_WIDTH`` +parameter is greater than 1, the output is zero-extended, and only the least +significant bit varies. + +Division and modulo cells are available in two rounding modes. The original +`$div` and `$mod` cells are based on truncating division, and correspond to the +semantics of the verilog ``/`` and ``%`` operators. The `$divfloor` and +`$modfloor` cells represent flooring division and flooring modulo, the latter of +which is also known as "remainder" in several languages. See the following table +for a side-by-side comparison between the different semantics. + +.. table:: Comparison between different rounding modes for division and modulo cells. + + +-----------+--------+-----------+-----------+-----------+-----------+ + | Division | Result | Truncating | Flooring | + +-----------+--------+-----------+-----------+-----------+-----------+ + | | | $div | $mod | $divfloor | $modfloor | + +===========+========+===========+===========+===========+===========+ + | -10 / 3 | -3.3 | -3 | -1 | -4 | 2 | + +-----------+--------+-----------+-----------+-----------+-----------+ + | 10 / -3 | -3.3 | -3 | 1 | -4 | -2 | + +-----------+--------+-----------+-----------+-----------+-----------+ + | -10 / -3 | 3.3 | 3 | -1 | 3 | -1 | + +-----------+--------+-----------+-----------+-----------+-----------+ + | 10 / 3 | 3.3 | 3 | 1 | 3 | 1 | + +-----------+--------+-----------+-----------+-----------+-----------+ + +.. autocellgroup:: binary + :members: + :source: + :linenos: diff --git a/docs/source/cell_word.rst b/docs/source/cell_word.rst index 9b781132468..c23a4e1b15d 100644 --- a/docs/source/cell_word.rst +++ b/docs/source/cell_word.rst @@ -1,9 +1,22 @@ Word-level 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 +:file:`techlibs/common/simlib.v` in the Yosys source tree. + .. toctree:: :maxdepth: 2 :glob: /cell/word_unary + /cell/word_binary /cell/word_other diff --git a/docs/source/yosys_internals/formats/cell_library.rst b/docs/source/yosys_internals/formats/cell_library.rst index c17976319c0..73dbc4e6999 100644 --- a/docs/source/yosys_internals/formats/cell_library.rst +++ b/docs/source/yosys_internals/formats/cell_library.rst @@ -13,8 +13,6 @@ Most of the passes in Yosys operate on netlists, i.e. they only care about the chapter discusses the cell types used by Yosys to represent a behavioural design internally. -.. TODO:: is this chapter split preserved - 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 @@ -23,155 +21,6 @@ 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. -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 -:file:`techlibs/common/simlib.v` in the Yosys source tree. - -Unary operators -~~~~~~~~~~~~~~~ - -All unary RTL cells have one input port ``\A`` and one output port ``\Y``. They -also have the following parameters: - -``\A_SIGNED`` - Set to a non-zero value if the input ``\A`` is signed and therefore should be - sign-extended when needed. - -``\A_WIDTH`` - The width of the input port ``\A``. - -``\Y_WIDTH`` - The width of the output port ``\Y``. - -:numref:`tab:CellLib_unary` lists all cells for unary RTL operators. - -.. table:: Cell types for unary operators with their corresponding Verilog expressions. - :name: tab:CellLib_unary - - ================== ============ - Verilog Cell Type - ================== ============ - :verilog:`Y = ~A` $not - :verilog:`Y = +A` $pos - :verilog:`Y = -A` $neg - :verilog:`Y = &A` $reduce_and - :verilog:`Y = |A` $reduce_or - :verilog:`Y = ^A` $reduce_xor - :verilog:`Y = ~^A` $reduce_xnor - :verilog:`Y = |A` $reduce_bool - :verilog:`Y = !A` $logic_not - ================== ============ - -For the unary cells that output a logical value (`$reduce_and`, `$reduce_or`, -`$reduce_xor`, `$reduce_xnor`, `$reduce_bool`, `$logic_not`), when the -``\Y_WIDTH`` parameter is greater than 1, the output is zero-extended, and only -the least significant bit varies. - -Note that `$reduce_or` and `$reduce_bool` actually represent the same logic -function. But the HDL frontends generate them in different situations. A -`$reduce_or` cell is generated when the prefix ``|`` operator is being used. A -`$reduce_bool` cell is generated when a bit vector is used as a condition in an -``if``-statement or ``?:``-expression. - -Binary operators -~~~~~~~~~~~~~~~~ - -All binary RTL cells have two input ports ``\A`` and ``\B`` and one output port -``\Y``. They also have the following parameters: - -``\A_SIGNED`` - Set to a non-zero value if the input ``\A`` is signed and therefore should be - sign-extended when needed. - -``\A_WIDTH`` - The width of the input port ``\A``. - -``\B_SIGNED`` - Set to a non-zero value if the input ``\B`` is signed and therefore should be - sign-extended when needed. - -``\B_WIDTH`` - The width of the input port ``\B``. - -``\Y_WIDTH`` - The width of the output port ``\Y``. - -:numref:`tab:CellLib_binary` lists all cells for binary RTL operators. - -.. table:: Cell types for binary operators with their corresponding Verilog expressions. - :name: tab:CellLib_binary - - ======================= ============= ======================= ========= - Verilog Cell Type Verilog Cell Type - ======================= ============= ======================= ========= - :verilog:`Y = A & B` $and :verilog:`Y = A < B` $lt - :verilog:`Y = A | B` $or :verilog:`Y = A <= B` $le - :verilog:`Y = A ^ B` $xor :verilog:`Y = A == B` $eq - :verilog:`Y = A ~^ B` $xnor :verilog:`Y = A != B` $ne - :verilog:`Y = A << B` $shl :verilog:`Y = A >= B` $ge - :verilog:`Y = A >> B` $shr :verilog:`Y = A > B` $gt - :verilog:`Y = A <<< B` $sshl :verilog:`Y = A + B` $add - :verilog:`Y = A >>> B` $sshr :verilog:`Y = A - B` $sub - :verilog:`Y = A && B` $logic_and :verilog:`Y = A * B` $mul - :verilog:`Y = A || B` $logic_or :verilog:`Y = A / B` $div - :verilog:`Y = A === B` $eqx :verilog:`Y = A % B` $mod - :verilog:`Y = A !== B` $nex ``N/A`` $divfloor - :verilog:`Y = A ** B` $pow ``N/A`` $modfloor - ======================= ============= ======================= ========= - -The `$shl` and `$shr` cells implement logical shifts, whereas the `$sshl` and -`$sshr` cells implement arithmetic shifts. The `$shl` and `$sshl` cells -implement the same operation. All four of these cells interpret the second -operand as unsigned, and require ``\B_SIGNED`` to be zero. - -Two additional shift operator cells are available that do not directly -correspond to any operator in Verilog, `$shift` and `$shiftx`. The `$shift` cell -performs a right logical shift if the second operand is positive (or unsigned), -and a left logical shift if it is negative. The `$shiftx` cell performs the same -operation as the `$shift` cell, but the vacated bit positions are filled with -undef (x) bits, and corresponds to the Verilog indexed part-select expression. - -For the binary cells that output a logical value (`$logic_and`, `$logic_or`, -`$eqx`, `$nex`, `$lt`, `$le`, `$eq`, `$ne`, `$ge`, `$gt`), when the ``\Y_WIDTH`` -parameter is greater than 1, the output is zero-extended, and only the least -significant bit varies. - -Division and modulo cells are available in two rounding modes. The original -`$div` and `$mod` cells are based on truncating division, and correspond to the -semantics of the verilog ``/`` and ``%`` operators. The `$divfloor` and -`$modfloor` cells represent flooring division and flooring modulo, the latter of -which is also known as "remainder" in several languages. See -:numref:`tab:CellLib_divmod` for a side-by-side comparison between the different -semantics. - -.. table:: Comparison between different rounding modes for division and modulo cells. - :name: tab:CellLib_divmod - - +-----------+--------+-----------+-----------+-----------+-----------+ - | Division | Result | Truncating | Flooring | - +-----------+--------+-----------+-----------+-----------+-----------+ - | | | $div | $mod | $divfloor | $modfloor | - +===========+========+===========+===========+===========+===========+ - | -10 / 3 | -3.3 | -3 | -1 | -4 | 2 | - +-----------+--------+-----------+-----------+-----------+-----------+ - | 10 / -3 | -3.3 | -3 | 1 | -4 | -2 | - +-----------+--------+-----------+-----------+-----------+-----------+ - | -10 / -3 | 3.3 | 3 | -1 | 3 | -1 | - +-----------+--------+-----------+-----------+-----------+-----------+ - | 10 / 3 | 3.3 | 3 | 1 | 3 | 1 | - +-----------+--------+-----------+-----------+-----------+-----------+ - Multiplexers ~~~~~~~~~~~~ diff --git a/techlibs/common/simlib.v b/techlibs/common/simlib.v index b8a754825ad..fb294b53bd1 100644 --- a/techlibs/common/simlib.v +++ b/techlibs/common/simlib.v @@ -139,6 +139,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $and (A, B, Y) +//* group binary //- //- A bit-wise AND. This corresponds to the Verilog '&' operator. //- @@ -169,6 +170,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $or (A, B, Y) +//* group binary //- //- A bit-wise OR. This corresponds to the Verilog '|' operator. //- @@ -199,6 +201,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $xor (A, B, Y) +//* group binary //- //- A bit-wise XOR. This corresponds to the Verilog '^' operator. //- @@ -229,6 +232,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $xnor (A, B, Y) +//* group binary //- //- A bit-wise XNOR. This corresponds to the Verilog '~^' operator. //- @@ -400,6 +404,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $shl (A, B, Y) +//* group binary //- //- A logical shift-left operation. This corresponds to the Verilog '<<' operator. //- @@ -430,6 +435,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $shr (A, B, Y) +//* group binary //- //- A logical shift-right operation. This corresponds to the Verilog '>>' operator. //- @@ -460,6 +466,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $sshl (A, B, Y) +//* group binary //- //- An arithmatic shift-left operation. //- This corresponds to the Verilog '<<<' operator. @@ -491,6 +498,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $sshr (A, B, Y) +//* group binary //- //- An arithmatic shift-right operation. //- This corresponds to the Verilog '>>>' operator. @@ -518,6 +526,7 @@ endgenerate endmodule // -------------------------------------------------------- +//* group binary module \$shift (A, B, Y); @@ -550,6 +559,7 @@ endgenerate endmodule // -------------------------------------------------------- +//* group binary module \$shiftx (A, B, Y); @@ -691,6 +701,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $lt (A, B, Y) +//* group binary //- //- A less-than comparison between inputs 'A' and 'B'. //- This corresponds to the Verilog '<' operator. @@ -722,6 +733,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $le (A, B, Y) +//* group binary //- //- A less-than-or-equal-to comparison between inputs 'A' and 'B'. //- This corresponds to the Verilog '<=' operator. @@ -753,6 +765,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $eq (A, B, Y) +//* group binary //- //- An equality comparison between inputs 'A' and 'B'. //- This corresponds to the Verilog '==' operator. @@ -784,6 +797,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $ne (A, B, Y) +//* group binary //- //- An inequality comparison between inputs 'A' and 'B'. //- This corresponds to the Verilog '!=' operator. @@ -815,6 +829,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $eqx (A, B, Y) +//* group binary //- //- An exact equality comparison between inputs 'A' and 'B'. //- This corresponds to the Verilog '===' operator. @@ -848,6 +863,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $nex (A, B, Y) +//* group binary //- //- An exact inequality comparison between inputs 'A' and 'B'. //- This corresponds to the Verilog '!==' operator. @@ -881,6 +897,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $ge (A, B, Y) +//* group binary //- //- A greater-than-or-equal-to comparison between inputs 'A' and 'B'. //- This corresponds to the Verilog '>=' operator. @@ -912,6 +929,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $gt (A, B, Y) +//* group binary //- //- A greater-than comparison between inputs 'A' and 'B'. //- This corresponds to the Verilog '>' operator. @@ -943,6 +961,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $add (A, B, Y) +//* group binary //- //- Addition of inputs 'A' and 'B'. This corresponds to the Verilog '+' operator. //- @@ -973,6 +992,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $sub (A, B, Y) +//* group binary //- //- Subtraction between inputs 'A' and 'B'. //- This corresponds to the Verilog '-' operator. @@ -1004,6 +1024,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $mul (A, B, Y) +//* group binary //- //- Multiplication of inputs 'A' and 'B'. //- This corresponds to the Verilog '*' operator. @@ -1185,6 +1206,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $div (A, B, Y) +//* group binary //- //- Division with truncated result (rounded towards 0). //- @@ -1215,6 +1237,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $mod (A, B, Y) +//* group binary //- //- Modulo/remainder of division with truncated result (rounded towards 0). //- @@ -1247,6 +1270,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $divfloor (A, B, Y) +//* group binary //- //- Division with floored result (rounded towards negative infinity). //- @@ -1284,6 +1308,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $modfloor (A, B, Y) +//* group binary //- //- Modulo/remainder of division with floored result (rounded towards negative infinity). //- @@ -1324,6 +1349,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $pow (A, B, Y) +//* group binary //- //- Exponentiation of an input (Y = A ** B). //- This corresponds to the Verilog '**' operator. @@ -1362,10 +1388,10 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $logic_not (A, Y) +//* group unary //- //- A logical inverter. This corresponds to the Verilog unary prefix '!' operator. //- -//* group unary module \$logic_not (A, Y); parameter A_SIGNED = 0; @@ -1390,6 +1416,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $logic_and (A, B, Y) +//* group binary //- //- A logical AND. This corresponds to the Verilog '&&' operator. //- @@ -1420,6 +1447,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $logic_or (A, B, Y) +//* group binary //- //- A logical OR. This corresponds to the Verilog '||' operator. //- From 04b0ae540d3ea8bf09e4f7caf9bc7991a615f4ec Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Mon, 27 May 2024 12:47:47 +1200 Subject: [PATCH 35/68] cellref: Move default help message to register.cc Drop the default help message from rst while still displaying it on the command line. Fix command line formatting for older style help messages. --- kernel/register.cc | 10 ++++++---- techlibs/common/cellhelp.py | 4 +--- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/kernel/register.cc b/kernel/register.cc index bc49f4cb914..ce6eb8018b2 100644 --- a/kernel/register.cc +++ b/kernel/register.cc @@ -1111,18 +1111,20 @@ struct HelpPass : public Pass { log("\n"); log("%s\n", help_cell.code.c_str()); } else { + log("\n %s %s\n\n", help_cell.name.c_str(), help_cell.ports.c_str()); if (help_cell.ver == "2" || help_cell.ver == "2a") { - log("\n %s %s\n\n", help_cell.name.c_str(), help_cell.ports.c_str()); - if (help_cell.title != "") log("%s\n", help_cell.title.c_str()); + if (help_cell.title != "") log("%s:\n", help_cell.title.c_str()); std::stringstream ss; ss << help_cell.desc; for (std::string line; std::getline(ss, line, '\n');) { if (line != "::") log("%s\n", line.c_str()); } - } else { + } else if (help_cell.desc.length()) { log("%s\n", help_cell.desc.c_str()); + } else { + log("No help message for this cell type found.\n"); } - log("Run 'help %s+' to display the Verilog model for this cell type.\n", args[1].c_str()); + log("\nRun 'help %s+' to display the Verilog model for this cell type.\n", args[1].c_str()); log("\n"); } } diff --git a/techlibs/common/cellhelp.py b/techlibs/common/cellhelp.py index 299b7affd73..9aa3def93cc 100644 --- a/techlibs/common/cellhelp.py +++ b/techlibs/common/cellhelp.py @@ -84,9 +84,7 @@ def simcells_reparse(cell: SimHelper): simcells_reparse(simHelper) # check help - if not simHelper.desc: - simHelper.desc.append("No help message for this cell type found.\n") - elif simHelper.ver == "1" and short_filename == "simlib.v" and simHelper.desc[1].startswith(' '): + if simHelper.desc and simHelper.ver == "1" and short_filename == "simlib.v" and simHelper.desc[1].startswith(' '): simHelper.desc.pop(1) # check group From 1374fc2e2b3ac0452b6e263a6afb8ea5ae011d07 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Mon, 27 May 2024 15:46:43 +1200 Subject: [PATCH 36/68] cellref: Deprecate cell_library.rst Most of the word/coarse level cells have an assigned group and individual page. The gate/fine level cells are all on one page. Fix links to `cell_library.rst`. --- docs/source/cell/word_arith.rst | 93 ++ docs/source/cell/word_debug.rst | 138 +++ docs/source/cell/word_formal.rst | 14 + docs/source/cell/word_fsm.rst | 9 + docs/source/cell/word_mem.rst | 281 +++++ docs/source/cell/word_mux.rst | 47 + docs/source/cell/word_other.rst | 5 - docs/source/cell/word_reg.rst | 124 ++ docs/source/cell/word_spec.rst | 9 + docs/source/cell_gate.rst | 389 ++++++ docs/source/cell_word.rst | 19 +- .../interactive_investigation.rst | 2 +- docs/source/using_yosys/synthesis/opt.rst | 8 +- .../yosys_internals/formats/cell_library.rst | 1086 ----------------- techlibs/common/simlib.v | 52 + 15 files changed, 1180 insertions(+), 1096 deletions(-) create mode 100644 docs/source/cell/word_arith.rst create mode 100644 docs/source/cell/word_debug.rst create mode 100644 docs/source/cell/word_formal.rst create mode 100644 docs/source/cell/word_fsm.rst create mode 100644 docs/source/cell/word_mem.rst create mode 100644 docs/source/cell/word_mux.rst delete mode 100644 docs/source/cell/word_other.rst create mode 100644 docs/source/cell/word_reg.rst create mode 100644 docs/source/cell/word_spec.rst delete mode 100644 docs/source/yosys_internals/formats/cell_library.rst diff --git a/docs/source/cell/word_arith.rst b/docs/source/cell/word_arith.rst new file mode 100644 index 00000000000..38111a7d542 --- /dev/null +++ b/docs/source/cell/word_arith.rst @@ -0,0 +1,93 @@ +Coarse arithmetics +------------------ + +Multiply-accumulate +~~~~~~~~~~~~~~~~~~~ + +The `$macc` cell type represents a generalized multiply and accumulate +operation. The cell is purely combinational. It outputs the result of summing up +a sequence of products and other injected summands. + +.. code-block:: + + Y = 0 +- a0factor1 * a0factor2 +- a1factor1 * a1factor2 +- ... + + B[0] + B[1] + ... + +The A port consists of concatenated pairs of multiplier inputs ("factors"). A +zero length factor2 acts as a constant 1, turning factor1 into a simple summand. + +In this pseudocode, ``u(foo)`` means an unsigned int that's foo bits long. + +.. code-block:: + + struct A { + u(CONFIG.mul_info[0].factor1_len) a0factor1; + u(CONFIG.mul_info[0].factor2_len) a0factor2; + u(CONFIG.mul_info[1].factor1_len) a1factor1; + u(CONFIG.mul_info[1].factor2_len) a1factor2; + ... + }; + +The cell's ``CONFIG`` parameter determines the layout of cell port ``A``. The +CONFIG parameter carries the following information: + +.. code-block:: + + struct CONFIG { + u4 num_bits; + struct mul_info { + bool is_signed; + bool is_subtract; + u(num_bits) factor1_len; + u(num_bits) factor2_len; + }[num_ports]; + }; + +B is an array of concatenated 1-bit-wide unsigned integers to also be summed up. + +Arbitrary logic functions +~~~~~~~~~~~~~~~~~~~~~~~~~ + +The `$lut` cell type implements a single-output LUT (lookup table). It +implements an arbitrary logic function with its ``\LUT`` parameter to map input +port ``\A`` to values of ``\Y`` output port values. In psuedocode: ``Y = +\LUT[A]``. ``\A`` has width set by parameter ``\WIDTH`` and ``\Y`` has a width +of 1. Every logic function with a single bit output has a unique `$lut` +representation. + +The `$sop` cell type implements a sum-of-products expression, also known as +disjunctive normal form (DNF). It implements an arbitrary logic function. Its +structure mimics a programmable logic array (PLA). Output port ``\Y`` is the sum +of products of the bits of the input port ``\A`` as defined by parameter +``\TABLE``. ``\A`` is ``\WIDTH`` bits wide. The number of products in the sum is +set by parameter ``\DEPTH``, and each product has two bits for each input bit - +for the presence of the unnegated and negated version of said input bit in the +product. Therefore the ``\TABLE`` parameter holds ``2 * \WIDTH * \DEPTH`` bits. + +For example: + +Let ``\WIDTH`` be 3. We would like to represent ``\Y =~\A[0] + \A[1]~\A[2]``. +There are 2 products to be summed, so ``\DEPTH`` shall be 2. + +.. code-block:: + + ~A[2]-----+ + A[2]----+| + ~A[1]---+|| + A[1]--+||| + ~A[0]-+|||| + A[0]+||||| + |||||| product formula + 010000 ~\A[0] + 001001 \A[1]~\A[2] + +So the value of ``\TABLE`` will become ``010000001001``. + +Any logic function with a single bit output can be represented with ``$sop`` but +may have variously minimized or ordered summands represented in the ``\TABLE`` +values. + +.. autocellgroup:: arith + :members: + :source: + :linenos: diff --git a/docs/source/cell/word_debug.rst b/docs/source/cell/word_debug.rst new file mode 100644 index 00000000000..92c753dbe7d --- /dev/null +++ b/docs/source/cell/word_debug.rst @@ -0,0 +1,138 @@ +.. role:: verilog(code) + :language: Verilog + +Debugging cells +--------------- + +The `$print` cell is used to log the values of signals, akin to (and +translatable to) the ``$display`` and ``$write`` family of tasks in Verilog. It +has the following parameters: + +``FORMAT`` + The internal format string. The syntax is described below. + +``ARGS_WIDTH`` + The width (in bits) of the signal on the ``ARGS`` port. + +``TRG_ENABLE`` + True if triggered on specific signals defined in ``TRG``; false if triggered + whenever ``ARGS`` or ``EN`` change and ``EN`` is 1. + +If ``TRG_ENABLE`` is true, the following parameters also apply: + +``TRG_WIDTH`` + The number of bits in the ``TRG`` port. + +``TRG_POLARITY`` + For each bit in ``TRG``, 1 if that signal is positive-edge triggered, 0 if + negative-edge triggered. + +``PRIORITY`` + When multiple `$print` or `$check` cells fire on the same trigger, they + execute in descending priority order. + +Ports: + +``TRG`` + The signals that control when this `$print` cell is triggered. + + If the width of this port is zero and ``TRG_ENABLE`` is true, the cell is + triggered during initial evaluation (time zero) only. + +``EN`` + Enable signal for the whole cell. + +``ARGS`` + The values to be displayed, in format string order. + +.. autocellgroup:: debug + :members: + :source: + :linenos: + +Format string syntax +~~~~~~~~~~~~~~~~~~~~ + +The format string syntax resembles Python f-strings. Regular text is passed +through unchanged until a format specifier is reached, starting with a ``{``. + +Format specifiers have the following syntax. Unless noted, all items are +required: + +``{`` + Denotes the start of the format specifier. + +size + Signal size in bits; this many bits are consumed from the ``ARGS`` port by + this specifier. + +``:`` + Separates the size from the remaining items. + +justify + ``>`` for right-justified, ``<`` for left-justified. + +padding + ``0`` for zero-padding, or a space for space-padding. + +width\ *?* + (optional) The number of characters wide to pad to. + +base + * ``b`` for base-2 integers (binary) + * ``o`` for base-8 integers (octal) + * ``d`` for base-10 integers (decimal) + * ``h`` for base-16 integers (hexadecimal) + * ``c`` for ASCII characters/strings + * ``t`` and ``r`` for simulation time (corresponding to :verilog:`$time` and + :verilog:`$realtime`) + +For integers, this item may follow: + +``+``\ *?* + (optional, decimals only) Include a leading plus for non-negative numbers. + This can assist with symmetry with negatives in tabulated output. + +signedness + ``u`` for unsigned, ``s`` for signed. This distinction is only respected + when rendering decimals. + +ASCII characters/strings have no special options, but the signal size must be +divisible by 8. + +For simulation time, the signal size must be zero. + +Finally: + +``}`` + Denotes the end of the format specifier. + +Some example format specifiers: + ++ ``{8:>02hu}`` - 8-bit unsigned integer rendered as hexadecimal, + right-justified, zero-padded to 2 characters wide. ++ ``{32:< 15d+s}`` - 32-bit signed integer rendered as decimal, left-justified, + space-padded to 15 characters wide, positive values prefixed with ``+``. ++ ``{16:< 10hu}`` - 16-bit unsigned integer rendered as hexadecimal, + left-justified, space-padded to 10 characters wide. ++ ``{0:>010t}`` - simulation time, right-justified, zero-padded to 10 characters + wide. + +To include literal ``{`` and ``}`` characters in your format string, use ``{{`` +and ``}}`` respectively. + +It is an error for a format string to consume more or less bits from ``ARGS`` +than the port width. + +Values are never truncated, regardless of the specified width. + +Note that further restrictions on allowable combinations of options may apply +depending on the backend used. + +For example, Verilog does not have a format specifier that allows zero-padding a +string (i.e. more than 1 ASCII character), though zero-padding a single +character is permitted. + +Thus, while the RTLIL format specifier ``{8:>02c}`` translates to ``%02c``, +``{16:>02c}`` cannot be represented in Verilog and will fail to emit. In this +case, ``{16:> 02c}`` must be used, which translates to ``%2s``. diff --git a/docs/source/cell/word_formal.rst b/docs/source/cell/word_formal.rst new file mode 100644 index 00000000000..81bab898873 --- /dev/null +++ b/docs/source/cell/word_formal.rst @@ -0,0 +1,14 @@ +Formal verification cells +------------------------- + +.. TODO:: Describe formal cells + + `$check`, `$assert`, `$assume`, `$live`, `$fair`, `$cover`, `$equiv`, + `$initstate`, `$anyconst`, `$anyseq`, `$anyinit`, `$allconst`, and `$allseq`. + + Also `$ff` and `$_FF_` cells. + +.. autocellgroup:: formal + :members: + :source: + :linenos: diff --git a/docs/source/cell/word_fsm.rst b/docs/source/cell/word_fsm.rst new file mode 100644 index 00000000000..943904b2b2e --- /dev/null +++ b/docs/source/cell/word_fsm.rst @@ -0,0 +1,9 @@ +Finite state machines +--------------------- + +.. TODO:: Describe `$fsm` cell + +.. autocellgroup:: fsm + :members: + :source: + :linenos: diff --git a/docs/source/cell/word_mem.rst b/docs/source/cell/word_mem.rst new file mode 100644 index 00000000000..434ddea3ec5 --- /dev/null +++ b/docs/source/cell/word_mem.rst @@ -0,0 +1,281 @@ +.. role:: verilog(code) + :language: Verilog + +.. _sec:memcells: + +Memories +~~~~~~~~ + +Memories are either represented using ``RTLIL::Memory`` objects, `$memrd_v2`, +`$memwr_v2`, and `$meminit_v2` cells, or by `$mem_v2` 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 +`$memrd_v2` (read port) or `$memwr_v2` (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 `$meminit_v2` cells, which allow +delaying constant folding for initialization addresses and data until after the +frontend finishes. + +The `$memrd_v2` cells have a clock input ``CLK``, an enable input ``EN``, an +address input ``ADDR``, a data output ``DATA``, an asynchronous reset input +``ARST``, and a synchronous reset input ``SRST``. They also have the following +parameters: + +``MEMID`` + The name of the ``RTLIL::Memory`` object that is associated with this read + port. + +``ABITS`` + The number of address bits (width of the ``ADDR`` input port). + +``WIDTH`` + The number of data bits (width of the ``DATA`` output port). Note that this + may be a power-of-two multiple of the underlying memory's width -- such ports + are called wide ports and access an aligned group of cells at once. In this + case, the corresponding low bits of ``ADDR`` must be tied to 0. + +``CLK_ENABLE`` + When this parameter is non-zero, the clock is used. Otherwise this read port + is asynchronous and the ``CLK`` input is not used. + +``CLK_POLARITY`` + Clock is active on the positive edge if this parameter has the value ``1'b1`` + and on the negative edge if this parameter is ``1'b0``. + +``TRANSPARENCY_MASK`` + This parameter is a bitmask of write ports that this read port is transparent + with. The bits of this parameter are indexed by the write port's ``PORTID`` + parameter. Transparency can only be enabled between synchronous ports sharing + a clock domain. When transparency is enabled for a given port pair, a read + and write to the same address in the same cycle will return the new value. + Otherwise the old value is returned. + +``COLLISION_X_MASK`` + This parameter is a bitmask of write ports that have undefined collision + behavior with this port. The bits of this parameter are indexed by the write + port's ``PORTID`` parameter. This behavior can only be enabled between + synchronous ports sharing a clock domain. When undefined collision is enabled + for a given port pair, a read and write to the same address in the same cycle + will return the undefined (all-X) value.This option is exclusive (for a given + port pair) with the transparency option. + +``ARST_VALUE`` + Whenever the ``ARST`` input is asserted, the data output will be reset to + this value. Only used for synchronous ports. + +``SRST_VALUE`` + Whenever the ``SRST`` input is synchronously asserted, the data output will + be reset to this value. Only used for synchronous ports. + +``INIT_VALUE`` + The initial value of the data output, for synchronous ports. + +``CE_OVER_SRST`` + If this parameter is non-zero, the ``SRST`` input is only recognized when + ``EN`` is true. Otherwise, ``SRST`` is recognized regardless of ``EN``. + +The `$memwr_v2` cells have a clock input ``CLK``, an enable input ``EN`` (one +enable bit for each data bit), an address input ``ADDR`` and a data input +``DATA``. They also have the following parameters: + +``MEMID`` + The name of the ``RTLIL::Memory`` object that is associated with this write + port. + +``ABITS`` + The number of address bits (width of the ``ADDR`` input port). + +``WIDTH`` + The number of data bits (width of the ``DATA`` output port). Like with + `$memrd_v2` cells, the width is allowed to be any power-of-two multiple of + memory width, with the corresponding restriction on address. + +``CLK_ENABLE`` + When this parameter is non-zero, the clock is used. Otherwise this write port + is asynchronous and the ``CLK`` input is not used. + +``CLK_POLARITY`` + Clock is active on positive edge if this parameter has the value ``1'b1`` and + on the negative edge if this parameter is ``1'b0``. + +``PORTID`` + An identifier for this write port, used to index write port bit mask + parameters. + +``PRIORITY_MASK`` + This parameter is a bitmask of write ports that this write port has priority + over in case of writing to the same address. The bits of this parameter are + indexed by the other write port's ``PORTID`` parameter. Write ports can only + have priority over write ports with lower port ID. When two ports write to + the same address and neither has priority over the other, the result is + undefined. Priority can only be set between two synchronous ports sharing + the same clock domain. + +The `$meminit_v2` cells have an address input ``ADDR``, a data input ``DATA``, +with the width of the ``DATA`` port equal to ``WIDTH`` parameter times ``WORDS`` +parameter, and a bit enable mask input ``EN`` with width equal to ``WIDTH`` +parameter. All three of the inputs must resolve to a constant for synthesis to +succeed. + +``MEMID`` + The name of the ``RTLIL::Memory`` object that is associated with this + initialization cell. + +``ABITS`` + The number of address bits (width of the ``ADDR`` input port). + +``WIDTH`` + The number of data bits per memory location. + +``WORDS`` + The number of consecutive memory locations initialized by this cell. + +``PRIORITY`` + The cell with the higher integer value in this parameter wins an + initialization conflict. + +The HDL frontend models a memory using ``RTLIL::Memory`` objects and +asynchronous `$memrd_v2` and `$memwr_v2` cells. The `memory` pass (i.e. its +various sub-passes) migrates `$dff` cells into the `$memrd_v2` and `$memwr_v2` +cells making them synchronous, then converts them to a single `$mem_v2` cell and +(optionally) maps this cell type to `$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 `$mem_v2` cell is left in the design. + +The `$mem_v2` cell provides the following parameters: + +``MEMID`` + The name of the original ``RTLIL::Memory`` object that became this `$mem_v2` + cell. + +``SIZE`` + The number of words in the memory. + +``ABITS`` + The number of address bits. + +``WIDTH`` + The number of data bits per word. + +``INIT`` + The initial memory contents. + +``RD_PORTS`` + The number of read ports on this memory cell. + +``RD_WIDE_CONTINUATION`` + This parameter is ``RD_PORTS`` bits wide, containing a bitmask of "wide + continuation" read ports. Such ports are used to represent the extra data + bits of wide ports in the combined cell, and must have all control signals + identical with the preceding port, except for address, which must have the + proper sub-cell address encoded in the low bits. + +``RD_CLK_ENABLE`` + This parameter is ``RD_PORTS`` bits wide, containing a clock enable bit for + each read port. + +``RD_CLK_POLARITY`` + This parameter is ``RD_PORTS`` bits wide, containing a clock polarity bit for + each read port. + +``RD_TRANSPARENCY_MASK`` + This parameter is ``RD_PORTS*WR_PORTS`` bits wide, containing a concatenation + of all ``TRANSPARENCY_MASK`` values of the original `$memrd_v2` cells. + +``RD_COLLISION_X_MASK`` + This parameter is ``RD_PORTS*WR_PORTS`` bits wide, containing a concatenation + of all ``COLLISION_X_MASK`` values of the original `$memrd_v2` cells. + +``RD_CE_OVER_SRST`` + This parameter is ``RD_PORTS`` bits wide, determining relative synchronous + reset and enable priority for each read port. + +``RD_INIT_VALUE`` + This parameter is ``RD_PORTS*WIDTH`` bits wide, containing the initial value + for each synchronous read port. + +``RD_ARST_VALUE`` + This parameter is ``RD_PORTS*WIDTH`` bits wide, containing the asynchronous + reset value for each synchronous read port. + +``RD_SRST_VALUE`` + This parameter is ``RD_PORTS*WIDTH`` bits wide, containing the synchronous + reset value for each synchronous read port. + +``WR_PORTS`` + The number of write ports on this memory cell. + +``WR_WIDE_CONTINUATION`` + This parameter is ``WR_PORTS`` bits wide, containing a bitmask of "wide + continuation" write ports. + +``WR_CLK_ENABLE`` + This parameter is ``WR_PORTS`` bits wide, containing a clock enable bit for + each write port. + +``WR_CLK_POLARITY`` + This parameter is ``WR_PORTS`` bits wide, containing a clock polarity bit for + each write port. + +``WR_PRIORITY_MASK`` + This parameter is ``WR_PORTS*WR_PORTS`` bits wide, containing a concatenation + of all ``PRIORITY_MASK`` values of the original `$memwr_v2` cells. + +The `$mem_v2` cell has the following ports: + +``RD_CLK`` + This input is ``RD_PORTS`` bits wide, containing all clock signals for the + read ports. + +``RD_EN`` + This input is ``RD_PORTS`` bits wide, containing all enable signals for the + read ports. + +``RD_ADDR`` + This input is ``RD_PORTS*ABITS`` bits wide, containing all address signals + for the read ports. + +``RD_DATA`` + This output is ``RD_PORTS*WIDTH`` bits wide, containing all data signals for + the read ports. + +``RD_ARST`` + This input is ``RD_PORTS`` bits wide, containing all asynchronous reset + signals for the read ports. + +``RD_SRST`` + This input is ``RD_PORTS`` bits wide, containing all synchronous reset + signals for the read ports. + +``WR_CLK`` + This input is ``WR_PORTS`` bits wide, containing all clock signals for the + write ports. + +``WR_EN`` + This input is ``WR_PORTS*WIDTH`` bits wide, containing all enable signals for + the write ports. + +``WR_ADDR`` + This input is ``WR_PORTS*ABITS`` bits wide, containing all address signals + for the write ports. + +``WR_DATA`` + This input is ``WR_PORTS*WIDTH`` bits wide, containing all data signals for + the write ports. + +The `memory_collect` pass can be used to convert discrete `$memrd_v2`, +`$memwr_v2`, and `$meminit_v2` cells belonging to the same memory to a single +`$mem_v2` cell, whereas the `memory_unpack` pass performs the inverse operation. +The `memory_dff` pass can combine asynchronous memory ports that are fed by or +feeding registers into synchronous memory ports. The `memory_bram` pass can be +used to recognize `$mem_v2` cells that can be implemented with a block RAM +resource on an FPGA. The `memory_map` pass can be used to implement `$mem_v2` +cells as basic logic: word-wide DFFs and address decoders. + +.. autocellgroup:: mem + :members: + :source: + :linenos: diff --git a/docs/source/cell/word_mux.rst b/docs/source/cell/word_mux.rst new file mode 100644 index 00000000000..3eca310f3f0 --- /dev/null +++ b/docs/source/cell/word_mux.rst @@ -0,0 +1,47 @@ +.. role:: verilog(code) + :language: Verilog + +Multiplexers +------------ + +Multiplexers are generated by the Verilog HDL frontend for ``?:``-expressions. +Multiplexers are also generated by the proc pass to map the decision trees from +RTLIL::Process objects to logic. + +The simplest multiplexer cell type is `$mux`. Cells of this type have a +``WITDH`` parameter and data inputs ``A`` and ``B`` and a data output ``Y``, all +of the specified width. This cell also has a single bit control input ``S``. If +``S`` is 0 the value from the input ``A`` is sent to the output, if it is 1 the +value from the ``B`` input is sent to the output. So the `$mux` cell implements +the function :verilog:`Y = S ? B : A`. + +The `$pmux` cell is used to multiplex between many inputs using a one-hot select +signal. Cells of this type have a ``WIDTH`` and a ``S_WIDTH`` parameter and +inputs ``A``, ``B``, and ``S`` and an output ``Y``. The ``S`` input is +``S_WIDTH`` bits wide. The ``A`` input and the output are both ``WIDTH`` bits +wide and the ``B`` input is ``WIDTH*S_WIDTH`` bits wide. When all bits of ``S`` +are zero, the value from ``A`` input is sent to the output. If the :math:`n`\ +'th bit from ``S`` is set, the value :math:`n`\ 'th ``WIDTH`` bits wide slice of +the ``B`` input is sent to the output. When more than one bit from ``S`` is set +the output is undefined. Cells of this type are used to model "parallel cases" +(defined by using the ``parallel_case`` attribute or detected by an +optimization). + +The `$tribuf` cell is used to implement tristate logic. Cells of this type have +a ``WIDTH`` parameter and inputs ``A`` and ``EN`` and an output ``Y``. The ``A`` +input and ``Y`` output are ``WIDTH`` bits wide, and the ``EN`` input is one bit +wide. When ``EN`` is 0, the output is not driven. When ``EN`` is 1, the value +from ``A`` input is sent to the ``Y`` output. Therefore, the `$tribuf` cell +implements the function :verilog:`Y = EN ? A : 'bz`. + +Behavioural code with cascaded if-then-else- and 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 `$and` gate). + +.. autocellgroup:: mux + :members: + :source: + :linenos: diff --git a/docs/source/cell/word_other.rst b/docs/source/cell/word_other.rst deleted file mode 100644 index 9e5ac2a3778..00000000000 --- a/docs/source/cell/word_other.rst +++ /dev/null @@ -1,5 +0,0 @@ -.. autocellgroup:: word_other - :caption: Other word-level cells - :members: - :source: - :linenos: diff --git a/docs/source/cell/word_reg.rst b/docs/source/cell/word_reg.rst new file mode 100644 index 00000000000..25c82b8e63d --- /dev/null +++ b/docs/source/cell/word_reg.rst @@ -0,0 +1,124 @@ +.. role:: verilog(code) + :language: Verilog + +Registers +--------- + +SR-type latches are represented by `$sr` cells. These cells have input ports +``SET`` and ``CLR`` and an output port ``Q``. They have the following +parameters: + +``WIDTH`` + The width of inputs ``SET`` and ``CLR`` and output ``Q``. + +``SET_POLARITY`` + The set input bits are active-high if this parameter has the value ``1'b1`` + and active-low if this parameter is ``1'b0``. + +``CLR_POLARITY`` + The reset input bits are active-high if this parameter has the value ``1'b1`` + and active-low if this parameter is ``1'b0``. + +Both set and reset inputs have separate bits for every output bit. When both the +set and reset inputs of an `$sr` cell are active for a given bit index, the +reset input takes precedence. + +D-type flip-flops are represented by `$dff` cells. These cells have a clock port +``CLK``, an input port ``D`` and an output port ``Q``. The following parameters +are available for `$dff` cells: + +``WIDTH`` + The width of input ``D`` and output ``Q``. + +``CLK_POLARITY`` + Clock is active on the positive edge if this parameter has the value ``1'b1`` + and on the negative edge if this parameter is ``1'b0``. + +D-type flip-flops with asynchronous reset are represented by `$adff` cells. As +the `$dff` cells they have ``CLK``, ``D`` and ``Q`` ports. In addition they also +have a single-bit ``ARST`` input port for the reset pin and the following +additional two parameters: + +``ARST_POLARITY`` + The asynchronous reset is active-high if this parameter has the value + ``1'b1`` and active-low if this parameter is ``1'b0``. + +``ARST_VALUE`` + The state of ``Q`` will be set to this value when the reset is active. + +Usually these cells are generated by the `proc` pass using the information in +the designs RTLIL::Process objects. + +D-type flip-flops with synchronous reset are represented by `$sdff` cells. As +the `$dff` cells they have ``CLK``, ``D`` and ``Q`` ports. In addition they also +have a single-bit ``SRST`` input port for the reset pin and the following +additional two parameters: + +``SRST_POLARITY`` + The synchronous reset is active-high if this parameter has the value ``1'b1`` + and active-low if this parameter is ``1'b0``. + +``SRST_VALUE`` + The state of ``Q`` will be set to this value when the reset is active. + +Note that the `$adff` and `$sdff` cells can only be used when the reset value is +constant. + +D-type flip-flops with asynchronous load are represented by `$aldff` cells. As +the `$dff` cells they have ``CLK``, ``D`` and ``Q`` ports. In addition they also +have a single-bit ``ALOAD`` input port for the async load enable pin, a ``AD`` +input port with the same width as data for the async load data, and the +following additional parameter: + +``ALOAD_POLARITY`` + The asynchronous load is active-high if this parameter has the value ``1'b1`` + and active-low if this parameter is ``1'b0``. + +D-type flip-flops with asynchronous set and reset are represented by `$dffsr` +cells. As the `$dff` cells they have ``CLK``, ``D`` and ``Q`` ports. In addition +they also have multi-bit ``SET`` and ``CLR`` input ports and the corresponding +polarity parameters, like `$sr` cells. + +D-type flip-flops with enable are represented by `$dffe`, `$adffe`, `$aldffe`, +`$dffsre`, `$sdffe`, and `$sdffce` cells, which are enhanced variants of `$dff`, +`$adff`, `$aldff`, `$dffsr`, `$sdff` (with reset over enable) and `$sdff` (with +enable over reset) cells, respectively. They have the same ports and parameters +as their base cell. In addition they also have a single-bit ``EN`` input port +for the enable pin and the following parameter: + +``EN_POLARITY`` + The enable input is active-high if this parameter has the value ``1'b1`` and + active-low if this parameter is ``1'b0``. + +D-type latches are represented by `$dlatch` cells. These cells have an enable +port ``EN``, an input port ``D``, and an output port ``Q``. The following +parameters are available for `$dlatch` cells: + +``WIDTH`` + The width of input ``D`` and output ``Q``. + +``EN_POLARITY`` + The enable input is active-high if this parameter has the value ``1'b1`` and + active-low if this parameter is ``1'b0``. + +The latch is transparent when the ``EN`` input is active. + +D-type latches with reset are represented by `$adlatch` cells. In addition to +`$dlatch` ports and parameters, they also have a single-bit ``ARST`` input port +for the reset pin and the following additional parameters: + +``ARST_POLARITY`` + The asynchronous reset is active-high if this parameter has the value + ``1'b1`` and active-low if this parameter is ``1'b0``. + +``ARST_VALUE`` + The state of ``Q`` will be set to this value when the reset is active. + +D-type latches with set and reset are represented by `$dlatchsr` cells. In +addition to `$dlatch` ports and parameters, they also have multi-bit ``SET`` and +``CLR`` input ports and the corresponding polarity parameters, like `$sr` cells. + +.. autocellgroup:: reg + :members: + :source: + :linenos: diff --git a/docs/source/cell/word_spec.rst b/docs/source/cell/word_spec.rst new file mode 100644 index 00000000000..33ef407744f --- /dev/null +++ b/docs/source/cell/word_spec.rst @@ -0,0 +1,9 @@ +Specify rules +------------- + +.. TODO:: `$specify2`, `$specify3`, and `$specrule` cells. + +.. autocellgroup:: spec + :members: + :source: + :linenos: diff --git a/docs/source/cell_gate.rst b/docs/source/cell_gate.rst index 0e977c58798..4262fe210af 100644 --- a/docs/source/cell_gate.rst +++ b/docs/source/cell_gate.rst @@ -1,6 +1,395 @@ +.. role:: verilog(code) + :language: Verilog + +.. _sec:celllib_gates: + Gate-level cells ---------------- +.. todo:: Split gate-level cells into subpages + + Consider also checking wording to be less academic and consistent. + +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 +techlibs/common/simcells.v in the Yosys source tree. + +.. table:: Cell types for gate level logic networks (main list) + :name: tab:CellLib_gates + + ======================================= ============= + Verilog Cell Type + ======================================= ============= + :verilog:`Y = A` `$_BUF_` + :verilog:`Y = ~A` `$_NOT_` + :verilog:`Y = A & B` `$_AND_` + :verilog:`Y = ~(A & B)` `$_NAND_` + :verilog:`Y = A & ~B` `$_ANDNOT_` + :verilog:`Y = A | B` `$_OR_` + :verilog:`Y = ~(A | B)` `$_NOR_` + :verilog:`Y = A | ~B` `$_ORNOT_` + :verilog:`Y = A ^ B` `$_XOR_` + :verilog:`Y = ~(A ^ B)` `$_XNOR_` + :verilog:`Y = ~((A & B) | C)` `$_AOI3_` + :verilog:`Y = ~((A | B) & C)` `$_OAI3_` + :verilog:`Y = ~((A & B) | (C & D))` `$_AOI4_` + :verilog:`Y = ~((A | B) & (C | D))` `$_OAI4_` + :verilog:`Y = S ? B : A` `$_MUX_` + :verilog:`Y = ~(S ? B : A)` `$_NMUX_` + (see below) `$_MUX4_` + (see below) `$_MUX8_` + (see below) `$_MUX16_` + :verilog:`Y = EN ? A : 1'bz` `$_TBUF_` + :verilog:`always @(negedge C) Q <= D` `$_DFF_N_` + :verilog:`always @(posedge C) Q <= D` `$_DFF_P_` + :verilog:`always @* if (!E) Q <= D` `$_DLATCH_N_` + :verilog:`always @* if (E) Q <= D` `$_DLATCH_P_` + ======================================= ============= + +.. table:: Cell types for gate level logic networks (FFs with reset) + :name: tab:CellLib_gates_adff + + ================== ============== ============== =========================== + :math:`ClkEdge` :math:`RstLvl` :math:`RstVal` Cell Type + ================== ============== ============== =========================== + :verilog:`negedge` ``0`` ``0`` `$_DFF_NN0_`, `$_SDFF_NN0_` + :verilog:`negedge` ``0`` ``1`` `$_DFF_NN1_`, `$_SDFF_NN1_` + :verilog:`negedge` ``1`` ``0`` `$_DFF_NP0_`, `$_SDFF_NP0_` + :verilog:`negedge` ``1`` ``1`` `$_DFF_NP1_`, `$_SDFF_NP1_` + :verilog:`posedge` ``0`` ``0`` `$_DFF_PN0_`, `$_SDFF_PN0_` + :verilog:`posedge` ``0`` ``1`` `$_DFF_PN1_`, `$_SDFF_PN1_` + :verilog:`posedge` ``1`` ``0`` `$_DFF_PP0_`, `$_SDFF_PP0_` + :verilog:`posedge` ``1`` ``1`` `$_DFF_PP1_`, `$_SDFF_PP1_` + ================== ============== ============== =========================== + + +.. table:: Cell types for gate level logic networks (FFs with enable) + :name: tab:CellLib_gates_dffe + + ================== ============= ============ + :math:`ClkEdge` :math:`EnLvl` Cell Type + ================== ============= ============ + :verilog:`negedge` ``0`` `$_DFFE_NN_` + :verilog:`negedge` ``1`` `$_DFFE_NP_` + :verilog:`posedge` ``0`` `$_DFFE_PN_` + :verilog:`posedge` ``1`` `$_DFFE_PP_` + ================== ============= ============ + + +.. table:: Cell types for gate level logic networks (FFs with reset and enable) + :name: tab:CellLib_gates_adffe + + ================== ============== ============== ============= ================================================= + :math:`ClkEdge` :math:`RstLvl` :math:`RstVal` :math:`EnLvl` Cell Type + ================== ============== ============== ============= ================================================= + :verilog:`negedge` ``0`` ``0`` ``0`` `$_DFFE_NN0N_`, `$_SDFFE_NN0N_`, `$_SDFFCE_NN0N_` + :verilog:`negedge` ``0`` ``0`` ``1`` `$_DFFE_NN0P_`, `$_SDFFE_NN0P_`, `$_SDFFCE_NN0P_` + :verilog:`negedge` ``0`` ``1`` ``0`` `$_DFFE_NN1N_`, `$_SDFFE_NN1N_`, `$_SDFFCE_NN1N_` + :verilog:`negedge` ``0`` ``1`` ``1`` `$_DFFE_NN1P_`, `$_SDFFE_NN1P_`, `$_SDFFCE_NN1P_` + :verilog:`negedge` ``1`` ``0`` ``0`` `$_DFFE_NP0N_`, `$_SDFFE_NP0N_`, `$_SDFFCE_NP0N_` + :verilog:`negedge` ``1`` ``0`` ``1`` `$_DFFE_NP0P_`, `$_SDFFE_NP0P_`, `$_SDFFCE_NP0P_` + :verilog:`negedge` ``1`` ``1`` ``0`` `$_DFFE_NP1N_`, `$_SDFFE_NP1N_`, `$_SDFFCE_NP1N_` + :verilog:`negedge` ``1`` ``1`` ``1`` `$_DFFE_NP1P_`, `$_SDFFE_NP1P_`, `$_SDFFCE_NP1P_` + :verilog:`posedge` ``0`` ``0`` ``0`` `$_DFFE_PN0N_`, `$_SDFFE_PN0N_`, `$_SDFFCE_PN0N_` + :verilog:`posedge` ``0`` ``0`` ``1`` `$_DFFE_PN0P_`, `$_SDFFE_PN0P_`, `$_SDFFCE_PN0P_` + :verilog:`posedge` ``0`` ``1`` ``0`` `$_DFFE_PN1N_`, `$_SDFFE_PN1N_`, `$_SDFFCE_PN1N_` + :verilog:`posedge` ``0`` ``1`` ``1`` `$_DFFE_PN1P_`, `$_SDFFE_PN1P_`, `$_SDFFCE_PN1P_` + :verilog:`posedge` ``1`` ``0`` ``0`` `$_DFFE_PP0N_`, `$_SDFFE_PP0N_`, `$_SDFFCE_PP0N_` + :verilog:`posedge` ``1`` ``0`` ``1`` `$_DFFE_PP0P_`, `$_SDFFE_PP0P_`, `$_SDFFCE_PP0P_` + :verilog:`posedge` ``1`` ``1`` ``0`` `$_DFFE_PP1N_`, `$_SDFFE_PP1N_`, `$_SDFFCE_PP1N_` + :verilog:`posedge` ``1`` ``1`` ``1`` `$_DFFE_PP1P_`, `$_SDFFE_PP1P_`, `$_SDFFCE_PP1P_` + ================== ============== ============== ============= ================================================= + +.. table:: Cell types for gate level logic networks (FFs with set and reset) + :name: tab:CellLib_gates_dffsr + + ================== ============== ============== ============== + :math:`ClkEdge` :math:`SetLvl` :math:`RstLvl` Cell Type + ================== ============== ============== ============== + :verilog:`negedge` ``0`` ``0`` `$_DFFSR_NNN_` + :verilog:`negedge` ``0`` ``1`` `$_DFFSR_NNP_` + :verilog:`negedge` ``1`` ``0`` `$_DFFSR_NPN_` + :verilog:`negedge` ``1`` ``1`` `$_DFFSR_NPP_` + :verilog:`posedge` ``0`` ``0`` `$_DFFSR_PNN_` + :verilog:`posedge` ``0`` ``1`` `$_DFFSR_PNP_` + :verilog:`posedge` ``1`` ``0`` `$_DFFSR_PPN_` + :verilog:`posedge` ``1`` ``1`` `$_DFFSR_PPP_` + ================== ============== ============== ============== + + +.. table:: Cell types for gate level logic networks (FFs with set and reset and enable) + :name: tab:CellLib_gates_dffsre + + ================== ============== ============== ============= ================ + :math:`ClkEdge` :math:`SetLvl` :math:`RstLvl` :math:`EnLvl` Cell Type + ================== ============== ============== ============= ================ + :verilog:`negedge` ``0`` ``0`` ``0`` `$_DFFSRE_NNNN_` + :verilog:`negedge` ``0`` ``0`` ``1`` `$_DFFSRE_NNNP_` + :verilog:`negedge` ``0`` ``1`` ``0`` `$_DFFSRE_NNPN_` + :verilog:`negedge` ``0`` ``1`` ``1`` `$_DFFSRE_NNPP_` + :verilog:`negedge` ``1`` ``0`` ``0`` `$_DFFSRE_NPNN_` + :verilog:`negedge` ``1`` ``0`` ``1`` `$_DFFSRE_NPNP_` + :verilog:`negedge` ``1`` ``1`` ``0`` `$_DFFSRE_NPPN_` + :verilog:`negedge` ``1`` ``1`` ``1`` `$_DFFSRE_NPPP_` + :verilog:`posedge` ``0`` ``0`` ``0`` `$_DFFSRE_PNNN_` + :verilog:`posedge` ``0`` ``0`` ``1`` `$_DFFSRE_PNNP_` + :verilog:`posedge` ``0`` ``1`` ``0`` `$_DFFSRE_PNPN_` + :verilog:`posedge` ``0`` ``1`` ``1`` `$_DFFSRE_PNPP_` + :verilog:`posedge` ``1`` ``0`` ``0`` `$_DFFSRE_PPNN_` + :verilog:`posedge` ``1`` ``0`` ``1`` `$_DFFSRE_PPNP_` + :verilog:`posedge` ``1`` ``1`` ``0`` `$_DFFSRE_PPPN_` + :verilog:`posedge` ``1`` ``1`` ``1`` `$_DFFSRE_PPPP_` + ================== ============== ============== ============= ================ + + +.. table:: Cell types for gate level logic networks (latches with reset) + :name: tab:CellLib_gates_adlatch + + ============= ============== ============== =============== + :math:`EnLvl` :math:`RstLvl` :math:`RstVal` Cell Type + ============= ============== ============== =============== + ``0`` ``0`` ``0`` `$_DLATCH_NN0_` + ``0`` ``0`` ``1`` `$_DLATCH_NN1_` + ``0`` ``1`` ``0`` `$_DLATCH_NP0_` + ``0`` ``1`` ``1`` `$_DLATCH_NP1_` + ``1`` ``0`` ``0`` `$_DLATCH_PN0_` + ``1`` ``0`` ``1`` `$_DLATCH_PN1_` + ``1`` ``1`` ``0`` `$_DLATCH_PP0_` + ``1`` ``1`` ``1`` `$_DLATCH_PP1_` + ============= ============== ============== =============== + + +.. table:: Cell types for gate level logic networks (latches with set and reset) + :name: tab:CellLib_gates_dlatchsr + + ============= ============== ============== ================= + :math:`EnLvl` :math:`SetLvl` :math:`RstLvl` Cell Type + ============= ============== ============== ================= + ``0`` ``0`` ``0`` `$_DLATCHSR_NNN_` + ``0`` ``0`` ``1`` `$_DLATCHSR_NNP_` + ``0`` ``1`` ``0`` `$_DLATCHSR_NPN_` + ``0`` ``1`` ``1`` `$_DLATCHSR_NPP_` + ``1`` ``0`` ``0`` `$_DLATCHSR_PNN_` + ``1`` ``0`` ``1`` `$_DLATCHSR_PNP_` + ``1`` ``1`` ``0`` `$_DLATCHSR_PPN_` + ``1`` ``1`` ``1`` `$_DLATCHSR_PPP_` + ============= ============== ============== ================= + + + +.. table:: Cell types for gate level logic networks (SR latches) + :name: tab:CellLib_gates_sr + + ============== ============== ========== + :math:`SetLvl` :math:`RstLvl` Cell Type + ============== ============== ========== + ``0`` ``0`` `$_SR_NN_` + ``0`` ``1`` `$_SR_NP_` + ``1`` ``0`` `$_SR_PN_` + ``1`` ``1`` `$_SR_PP_` + ============== ============== ========== + + +Tables :numref:`%s `, :numref:`%s `, +:numref:`%s `, :numref:`%s `, +:numref:`%s `, :numref:`%s `, +:numref:`%s `, :numref:`%s +` and :numref:`%s ` list all +cell types used for gate level logic. The cell types `$_BUF_`, `$_NOT_`, +`$_AND_`, `$_NAND_`, `$_ANDNOT_`, `$_OR_`, `$_NOR_`, `$_ORNOT_`, `$_XOR_`, +`$_XNOR_`, `$_AOI3_`, `$_OAI3_`, `$_AOI4_`, `$_OAI4_`, `$_MUX_`, `$_MUX4_`, +`$_MUX8_`, `$_MUX16_` and `$_NMUX_` are used to model combinatorial logic. The +cell type `$_TBUF_` is used to model tristate logic. + +The `$_MUX4_`, `$_MUX8_` and `$_MUX16_` cells are used to model wide muxes, and +correspond to the following Verilog code: + +.. code-block:: verilog + :force: + + // $_MUX4_ + assign Y = T ? (S ? D : C) : + (S ? B : A); + // $_MUX8_ + assign Y = U ? T ? (S ? H : G) : + (S ? F : E) : + T ? (S ? D : C) : + (S ? B : A); + // $_MUX16_ + assign Y = V ? U ? T ? (S ? P : O) : + (S ? N : M) : + T ? (S ? L : K) : + (S ? J : I) : + U ? T ? (S ? H : G) : + (S ? F : E) : + T ? (S ? D : C) : + (S ? B : A); + +The cell types `$_DFF_N_` and `$_DFF_P_` represent d-type flip-flops. + +The cell types ``$_DFFE_[NP][NP]_`` implement d-type flip-flops with enable. The +values in the table for these cell types relate to the following Verilog code +template. + +.. code-block:: verilog + :force: + + always @(CLK_EDGE C) + if (EN == EN_LVL) + Q <= D; + +The cell types ``$_DFF_[NP][NP][01]_`` implement d-type flip-flops with +asynchronous reset. The values in the table for these cell types relate to the +following Verilog code template, where ``RST_EDGE`` is ``posedge`` if +``RST_LVL`` if ``1``, and ``negedge`` otherwise. + +.. code-block:: verilog + :force: + + always @(CLK_EDGE C, RST_EDGE R) + if (R == RST_LVL) + Q <= RST_VAL; + else + Q <= D; + +The cell types ``$_SDFF_[NP][NP][01]_`` implement d-type flip-flops with +synchronous reset. The values in the table for these cell types relate to the +following Verilog code template: + +.. code-block:: verilog + :force: + + always @(CLK_EDGE C) + if (R == RST_LVL) + Q <= RST_VAL; + else + Q <= D; + +The cell types ``$_DFFE_[NP][NP][01][NP]_`` implement d-type flip-flops with +asynchronous reset and enable. The values in the table for these cell types +relate to the following Verilog code template, where ``RST_EDGE`` is ``posedge`` +if ``RST_LVL`` if ``1``, and ``negedge`` otherwise. + +.. code-block:: verilog + :force: + + always @(CLK_EDGE C, RST_EDGE R) + if (R == RST_LVL) + Q <= RST_VAL; + else if (EN == EN_LVL) + Q <= D; + +The cell types ``$_SDFFE_[NP][NP][01][NP]_`` implement d-type flip-flops with +synchronous reset and enable, with reset having priority over enable. The values +in the table for these cell types relate to the following Verilog code template: + +.. code-block:: verilog + :force: + + always @(CLK_EDGE C) + if (R == RST_LVL) + Q <= RST_VAL; + else if (EN == EN_LVL) + Q <= D; + +The cell types ``$_SDFFCE_[NP][NP][01][NP]_`` implement d-type flip-flops with +synchronous reset and enable, with enable having priority over reset. The values +in the table for these cell types relate to the following Verilog code template: + +.. code-block:: verilog + :force: + + always @(CLK_EDGE C) + if (EN == EN_LVL) + if (R == RST_LVL) + Q <= RST_VAL; + else + Q <= D; + +The cell types ``$_DFFSR_[NP][NP][NP]_`` implement d-type flip-flops with +asynchronous set and reset. The values in the table for these cell types relate +to the following Verilog code template, where ``RST_EDGE`` is ``posedge`` if +``RST_LVL`` if ``1``, ``negedge`` otherwise, and ``SET_EDGE`` is ``posedge`` if +``SET_LVL`` if ``1``, ``negedge`` otherwise. + +.. code-block:: verilog + :force: + + always @(CLK_EDGE C, RST_EDGE R, SET_EDGE S) + if (R == RST_LVL) + Q <= 0; + else if (S == SET_LVL) + Q <= 1; + else + Q <= D; + +The cell types ``$_DFFSRE_[NP][NP][NP][NP]_`` implement d-type flip-flops with +asynchronous set and reset and enable. The values in the table for these cell +types relate to the following Verilog code template, where ``RST_EDGE`` is +``posedge`` if ``RST_LVL`` if ``1``, ``negedge`` otherwise, and ``SET_EDGE`` is +``posedge`` if ``SET_LVL`` if ``1``, ``negedge`` otherwise. + +.. code-block:: verilog + :force: + + always @(CLK_EDGE C, RST_EDGE R, SET_EDGE S) + if (R == RST_LVL) + Q <= 0; + else if (S == SET_LVL) + Q <= 1; + else if (E == EN_LVL) + Q <= D; + +The cell types `$_DLATCH_N_` and `$_DLATCH_P_` represent d-type latches. + +The cell types ``$_DLATCH_[NP][NP][01]_`` implement d-type latches with reset. +The values in the table for these cell types relate to the following Verilog +code template: + +.. code-block:: verilog + :force: + + always @* + if (R == RST_LVL) + Q <= RST_VAL; + else if (E == EN_LVL) + Q <= D; + +The cell types ``$_DLATCHSR_[NP][NP][NP]_`` implement d-type latches with set +and reset. The values in the table for these cell types relate to the following +Verilog code template: + +.. code-block:: verilog + :force: + + always @* + if (R == RST_LVL) + Q <= 0; + else if (S == SET_LVL) + Q <= 1; + else if (E == EN_LVL) + Q <= D; + +The cell types ``$_SR_[NP][NP]_`` implement sr-type latches. The values in the +table for these cell types relate to the following Verilog code template: + +.. code-block:: verilog + :force: + + always @* + if (R == RST_LVL) + Q <= 0; + else if (S == SET_LVL) + Q <= 1; + +In most cases gate level logic networks are created from RTL networks using the +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 dfflibmap pass. +The combinatorial logic cells can be mapped to physical cells from a Liberty +file via ABC using the abc pass. + .. toctree:: :caption: Gate-level cells :maxdepth: 2 diff --git a/docs/source/cell_word.rst b/docs/source/cell_word.rst index c23a4e1b15d..a736801fabc 100644 --- a/docs/source/cell_word.rst +++ b/docs/source/cell_word.rst @@ -19,4 +19,21 @@ Simulation models for the RTL cells can be found in the file /cell/word_unary /cell/word_binary - /cell/word_other + /cell/word_mux + /cell/word_reg + /cell/word_mem + /cell/word_fsm + /cell/word_arith + /cell/word_spec + /cell/word_formal + /cell/word_debug + +.. todo:: Add information about `$slice` and `$concat` cells. + +.. todo:: Add information about `$alu`, `$fa`, and `$lcu` cells. + +.. autocellgroup:: word_other + :caption: Other word-level cells + :members: + :source: + :linenos: diff --git a/docs/source/using_yosys/more_scripting/interactive_investigation.rst b/docs/source/using_yosys/more_scripting/interactive_investigation.rst index f078ed59e5b..68b5380760d 100644 --- a/docs/source/using_yosys/more_scripting/interactive_investigation.rst +++ b/docs/source/using_yosys/more_scripting/interactive_investigation.rst @@ -65,7 +65,7 @@ displayed as rectangles with inputs on the left and outputs on the right side. The cell labels are two lines long: The first line contains a unique identifier for the cell and the second line contains the cell type. Internal cell types are prefixed with a dollar sign. For more details on the internal cell library, see -:doc:`/yosys_internals/formats/cell_library`. +:doc:`/cell_gate` and :doc:`/cell_word`. Constants are shown as ellipses with the constant value as label. The syntax ``'`` is used for constants that are not 32-bit wide and/or diff --git a/docs/source/using_yosys/synthesis/opt.rst b/docs/source/using_yosys/synthesis/opt.rst index 7af2231c9d7..87763dbbe0a 100644 --- a/docs/source/using_yosys/synthesis/opt.rst +++ b/docs/source/using_yosys/synthesis/opt.rst @@ -27,9 +27,9 @@ Constant folding and simple expression rewriting - `opt_expr` .. todo:: unsure if this is too much detail and should be in :doc:`/yosys_internals/index` This pass performs constant folding on the internal combinational cell types -described in :doc:`/yosys_internals/formats/cell_library`. This means a cell -with all constant inputs is replaced with the constant value this cell drives. -In some cases this pass can also optimize cells with some constant inputs. +described in :doc:`/cell_gate` and :doc:`/cell_word`. This means a cell with all +constant inputs is replaced with the constant value this cell drives. In some +cases this pass can also optimize cells with some constant inputs. .. table:: Const folding rules for `$_AND_` cells as used in `opt_expr`. :name: tab:opt_expr_and @@ -182,6 +182,8 @@ away by `opt_expr`. Performing DFF optimizations - `opt_dff` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +.. todo:: ``$_DFF_`` isn't a valid cell + This pass identifies single-bit d-type flip-flops (`$_DFF_`, `$dff`, and `$adff` cells) with a constant data input and replaces them with a constant driver. It can also merge clock enables and synchronous reset multiplexers, removing unused diff --git a/docs/source/yosys_internals/formats/cell_library.rst b/docs/source/yosys_internals/formats/cell_library.rst deleted file mode 100644 index 73dbc4e6999..00000000000 --- a/docs/source/yosys_internals/formats/cell_library.rst +++ /dev/null @@ -1,1086 +0,0 @@ -.. role:: verilog(code) - :language: Verilog - -.. _chapter:celllib: - -Internal cell library -===================== - -.. todo:: less academic, also check formatting consistency - -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. - -Multiplexers -~~~~~~~~~~~~ - -Multiplexers are generated by the Verilog HDL frontend for ``?:``-expressions. -Multiplexers are also generated by the proc pass to map the decision trees from -RTLIL::Process objects to logic. - -The simplest multiplexer cell type is `$mux`. Cells of this type have a -``\WITDH`` parameter and data inputs ``\A`` and ``\B`` and a data output ``\Y``, -all of the specified width. This cell also has a single bit control input -``\S``. If ``\S`` is 0 the value from the input ``\A`` is sent to the output, if -it is 1 the value from the ``\B`` input is sent to the output. So the `$mux` -cell implements the function :verilog:`Y = S ? B : A`. - -The `$pmux` cell is used to multiplex between many inputs using a one-hot select -signal. Cells of this type have a ``\WIDTH`` and a ``\S_WIDTH`` parameter and -inputs ``\A``, ``\B``, and ``\S`` and an output ``\Y``. The ``\S`` input is -``\S_WIDTH`` bits wide. The ``\A`` input and the output are both ``\WIDTH`` bits -wide and the ``\B`` input is ``\WIDTH*\S_WIDTH`` bits wide. When all bits of -``\S`` are zero, the value from ``\A`` input is sent to the output. If the -:math:`n`\ 'th bit from ``\S`` is set, the value :math:`n`\ 'th ``\WIDTH`` bits -wide slice of the ``\B`` input is sent to the output. When more than one bit -from ``\S`` is set the output is undefined. Cells of this type are used to model -"parallel cases" (defined by using the ``parallel_case`` attribute or detected -by an optimization). - -The `$tribuf` cell is used to implement tristate logic. Cells of this type have -a ``\WIDTH`` parameter and inputs ``\A`` and ``\EN`` and an output ``\Y``. The -``\A`` input and ``\Y`` output are ``\WIDTH`` bits wide, and the ``\EN`` input -is one bit wide. When ``\EN`` is 0, the output is not driven. When ``\EN`` is 1, -the value from ``\A`` input is sent to the ``\Y`` output. Therefore, the -`$tribuf` cell implements the function :verilog:`Y = EN ? A : 'bz`. - -Behavioural code with cascaded if-then-else- and 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 `$and` gate). - -Registers -~~~~~~~~~ - -SR-type latches are represented by `$sr` cells. These cells have input ports -``\SET`` and ``\CLR`` and an output port ``\Q``. They have the following -parameters: - -``\WIDTH`` - The width of inputs ``\SET`` and ``\CLR`` and output ``\Q``. - -``\SET_POLARITY`` - The set input bits are active-high if this parameter has the value ``1'b1`` - and active-low if this parameter is ``1'b0``. - -``\CLR_POLARITY`` - The reset input bits are active-high if this parameter has the value ``1'b1`` - and active-low if this parameter is ``1'b0``. - -Both set and reset inputs have separate bits for every output bit. When both the -set and reset inputs of an `$sr` cell are active for a given bit index, the -reset input takes precedence. - -D-type flip-flops are represented by `$dff` cells. These cells have a clock port -``\CLK``, an input port ``\D`` and an output port ``\Q``. The following -parameters are available for `$dff` cells: - -``\WIDTH`` - The width of input ``\D`` and output ``\Q``. - -``\CLK_POLARITY`` - Clock is active on the positive edge if this parameter has the value ``1'b1`` - and on the negative edge if this parameter is ``1'b0``. - -D-type flip-flops with asynchronous reset are represented by `$adff` cells. As -the `$dff` cells they have ``\CLK``, ``\D`` and ``\Q`` ports. In addition they -also have a single-bit ``\ARST`` input port for the reset pin and the following -additional two parameters: - -``\ARST_POLARITY`` - The asynchronous reset is active-high if this parameter has the value - ``1'b1`` and active-low if this parameter is ``1'b0``. - -``\ARST_VALUE`` - The state of ``\Q`` will be set to this value when the reset is active. - -Usually these cells are generated by the `proc` pass using the information in -the designs RTLIL::Process objects. - -D-type flip-flops with synchronous reset are represented by `$sdff` cells. As -the `$dff` cells they have ``\CLK``, ``\D`` and ``\Q`` ports. In addition they -also have a single-bit ``\SRST`` input port for the reset pin and the following -additional two parameters: - -``\SRST_POLARITY`` - The synchronous reset is active-high if this parameter has the value ``1'b1`` - and active-low if this parameter is ``1'b0``. - -``\SRST_VALUE`` - The state of ``\Q`` will be set to this value when the reset is active. - -Note that the `$adff` and `$sdff` cells can only be used when the reset value is -constant. - -D-type flip-flops with asynchronous load are represented by `$aldff` cells. As -the `$dff` cells they have ``\CLK``, ``\D`` and ``\Q`` ports. In addition they -also have a single-bit ``\ALOAD`` input port for the async load enable pin, a -``\AD`` input port with the same width as data for the async load data, and the -following additional parameter: - -``\ALOAD_POLARITY`` - The asynchronous load is active-high if this parameter has the value ``1'b1`` - and active-low if this parameter is ``1'b0``. - -D-type flip-flops with asynchronous set and reset are represented by `$dffsr` -cells. As the `$dff` cells they have ``\CLK``, ``\D`` and ``\Q`` ports. In -addition they also have multi-bit ``\SET`` and ``\CLR`` input ports and the -corresponding polarity parameters, like `$sr` cells. - -D-type flip-flops with enable are represented by `$dffe`, `$adffe`, `$aldffe`, -`$dffsre`, `$sdffe`, and `$sdffce` cells, which are enhanced variants of `$dff`, -`$adff`, `$aldff`, `$dffsr`, `$sdff` (with reset over enable) and `$sdff` (with -enable over reset) cells, respectively. They have the same ports and parameters -as their base cell. In addition they also have a single-bit ``\EN`` input port -for the enable pin and the following parameter: - -``\EN_POLARITY`` - The enable input is active-high if this parameter has the value ``1'b1`` and - active-low if this parameter is ``1'b0``. - -D-type latches are represented by `$dlatch` cells. These cells have an enable -port ``\EN``, an input port ``\D``, and an output port ``\Q``. The following -parameters are available for `$dlatch` cells: - -``\WIDTH`` - The width of input ``\D`` and output ``\Q``. - -``\EN_POLARITY`` - The enable input is active-high if this parameter has the value ``1'b1`` and - active-low if this parameter is ``1'b0``. - -The latch is transparent when the ``\EN`` input is active. - -D-type latches with reset are represented by `$adlatch` cells. In addition to -`$dlatch` ports and parameters, they also have a single-bit ``\ARST`` input port -for the reset pin and the following additional parameters: - -``\ARST_POLARITY`` - The asynchronous reset is active-high if this parameter has the value - ``1'b1`` and active-low if this parameter is ``1'b0``. - -``\ARST_VALUE`` - The state of ``\Q`` will be set to this value when the reset is active. - -D-type latches with set and reset are represented by `$dlatchsr` cells. In -addition to `$dlatch` ports and parameters, they also have multi-bit ``\SET`` -and ``\CLR`` input ports and the corresponding polarity parameters, like `$sr` -cells. - -.. _sec:memcells: - -Memories -~~~~~~~~ - -Memories are either represented using ``RTLIL::Memory`` objects, `$memrd_v2`, -`$memwr_v2`, and `$meminit_v2` cells, or by `$mem_v2` 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 -`$memrd_v2` (read port) or `$memwr_v2` (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 `$meminit_v2` cells, which allow -delaying constant folding for initialization addresses and data until after the -frontend finishes. - -The `$memrd_v2` cells have a clock input ``\CLK``, an enable input ``\EN``, an -address input ``\ADDR``, a data output ``\DATA``, an asynchronous reset input -``\ARST``, and a synchronous reset input ``\SRST``. They also have the following -parameters: - -``\MEMID`` - The name of the ``RTLIL::Memory`` object that is associated with this read - port. - -``\ABITS`` - The number of address bits (width of the ``\ADDR`` input port). - -``\WIDTH`` - The number of data bits (width of the ``\DATA`` output port). Note that this - may be a power-of-two multiple of the underlying memory's width -- such ports - are called wide ports and access an aligned group of cells at once. In this - case, the corresponding low bits of ``\ADDR`` must be tied to 0. - -``\CLK_ENABLE`` - When this parameter is non-zero, the clock is used. Otherwise this read port - is asynchronous and the ``\CLK`` input is not used. - -``\CLK_POLARITY`` - Clock is active on the positive edge if this parameter has the value ``1'b1`` - and on the negative edge if this parameter is ``1'b0``. - -``\TRANSPARENCY_MASK`` - This parameter is a bitmask of write ports that this read port is transparent - with. The bits of this parameter are indexed by the write port's ``\PORTID`` - parameter. Transparency can only be enabled between synchronous ports sharing - a clock domain. When transparency is enabled for a given port pair, a read - and write to the same address in the same cycle will return the new value. - Otherwise the old value is returned. - -``\COLLISION_X_MASK`` - This parameter is a bitmask of write ports that have undefined collision - behavior with this port. The bits of this parameter are indexed by the write - port's ``\PORTID`` parameter. This behavior can only be enabled between - synchronous ports sharing a clock domain. When undefined collision is enabled - for a given port pair, a read and write to the same address in the same cycle - will return the undefined (all-X) value.This option is exclusive (for a given - port pair) with the transparency option. - -``\ARST_VALUE`` - Whenever the ``\ARST`` input is asserted, the data output will be reset to - this value. Only used for synchronous ports. - -``\SRST_VALUE`` - Whenever the ``\SRST`` input is synchronously asserted, the data output will - be reset to this value. Only used for synchronous ports. - -``\INIT_VALUE`` - The initial value of the data output, for synchronous ports. - -``\CE_OVER_SRST`` - If this parameter is non-zero, the ``\SRST`` input is only recognized when - ``\EN`` is true. Otherwise, ``\SRST`` is recognized regardless of ``\EN``. - -The `$memwr_v2` cells have a clock input ``\CLK``, an enable input ``\EN`` (one -enable bit for each data bit), an address input ``\ADDR`` and a data input -``\DATA``. They also have the following parameters: - -``\MEMID`` - The name of the ``RTLIL::Memory`` object that is associated with this write - port. - -``\ABITS`` - The number of address bits (width of the ``\ADDR`` input port). - -``\WIDTH`` - The number of data bits (width of the ``\DATA`` output port). Like with - `$memrd_v2` cells, the width is allowed to be any power-of-two multiple of - memory width, with the corresponding restriction on address. - -``\CLK_ENABLE`` - When this parameter is non-zero, the clock is used. Otherwise this write port - is asynchronous and the ``\CLK`` input is not used. - -``\CLK_POLARITY`` - Clock is active on positive edge if this parameter has the value ``1'b1`` and - on the negative edge if this parameter is ``1'b0``. - -``\PORTID`` - An identifier for this write port, used to index write port bit mask - parameters. - -``\PRIORITY_MASK`` - This parameter is a bitmask of write ports that this write port has priority - over in case of writing to the same address. The bits of this parameter are - indexed by the other write port's ``\PORTID`` parameter. Write ports can only - have priority over write ports with lower port ID. When two ports write to - the same address and neither has priority over the other, the result is - undefined. Priority can only be set between two synchronous ports sharing - the same clock domain. - -The `$meminit_v2` cells have an address input ``\ADDR``, a data input ``\DATA``, -with the width of the ``\DATA`` port equal to ``\WIDTH`` parameter times -``\WORDS`` parameter, and a bit enable mask input ``\EN`` with width equal to -``\WIDTH`` parameter. All three of the inputs must resolve to a constant for -synthesis to succeed. - -``\MEMID`` - The name of the ``RTLIL::Memory`` object that is associated with this - initialization cell. - -``\ABITS`` - The number of address bits (width of the ``\ADDR`` input port). - -``\WIDTH`` - The number of data bits per memory location. - -``\WORDS`` - The number of consecutive memory locations initialized by this cell. - -``\PRIORITY`` - The cell with the higher integer value in this parameter wins an - initialization conflict. - -The HDL frontend models a memory using ``RTLIL::Memory`` objects and -asynchronous `$memrd_v2` and `$memwr_v2` cells. The `memory` pass (i.e. its -various sub-passes) migrates `$dff` cells into the `$memrd_v2` and `$memwr_v2` -cells making them synchronous, then converts them to a single `$mem_v2` cell and -(optionally) maps this cell type to `$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 `$mem_v2` cell is left in the design. - -The `$mem_v2` cell provides the following parameters: - -``\MEMID`` - The name of the original ``RTLIL::Memory`` object that became this `$mem_v2` - cell. - -``\SIZE`` - The number of words in the memory. - -``\ABITS`` - The number of address bits. - -``\WIDTH`` - The number of data bits per word. - -``\INIT`` - The initial memory contents. - -``\RD_PORTS`` - The number of read ports on this memory cell. - -``\RD_WIDE_CONTINUATION`` - This parameter is ``\RD_PORTS`` bits wide, containing a bitmask of "wide - continuation" read ports. Such ports are used to represent the extra data - bits of wide ports in the combined cell, and must have all control signals - identical with the preceding port, except for address, which must have the - proper sub-cell address encoded in the low bits. - -``\RD_CLK_ENABLE`` - This parameter is ``\RD_PORTS`` bits wide, containing a clock enable bit for - each read port. - -``\RD_CLK_POLARITY`` - This parameter is ``\RD_PORTS`` bits wide, containing a clock polarity bit - for each read port. - -``\RD_TRANSPARENCY_MASK`` - This parameter is ``\RD_PORTS*\WR_PORTS`` bits wide, containing a - concatenation of all ``\TRANSPARENCY_MASK`` values of the original - `$memrd_v2` cells. - -``\RD_COLLISION_X_MASK`` - This parameter is ``\RD_PORTS*\WR_PORTS`` bits wide, containing a - concatenation of all ``\COLLISION_X_MASK`` values of the original `$memrd_v2` - cells. - -``\RD_CE_OVER_SRST`` - This parameter is ``\RD_PORTS`` bits wide, determining relative synchronous - reset and enable priority for each read port. - -``\RD_INIT_VALUE`` - This parameter is ``\RD_PORTS*\WIDTH`` bits wide, containing the initial - value for each synchronous read port. - -``\RD_ARST_VALUE`` - This parameter is ``\RD_PORTS*\WIDTH`` bits wide, containing the asynchronous - reset value for each synchronous read port. - -``\RD_SRST_VALUE`` - This parameter is ``\RD_PORTS*\WIDTH`` bits wide, containing the synchronous - reset value for each synchronous read port. - -``\WR_PORTS`` - The number of write ports on this memory cell. - -``\WR_WIDE_CONTINUATION`` - This parameter is ``\WR_PORTS`` bits wide, containing a bitmask of "wide - continuation" write ports. - -``\WR_CLK_ENABLE`` - This parameter is ``\WR_PORTS`` bits wide, containing a clock enable bit for - each write port. - -``\WR_CLK_POLARITY`` - This parameter is ``\WR_PORTS`` bits wide, containing a clock polarity bit - for each write port. - -``\WR_PRIORITY_MASK`` - This parameter is ``\WR_PORTS*\WR_PORTS`` bits wide, containing a - concatenation of all ``\PRIORITY_MASK`` values of the original `$memwr_v2` - cells. - -The `$mem_v2` cell has the following ports: - -``\RD_CLK`` - This input is ``\RD_PORTS`` bits wide, containing all clock signals for the - read ports. - -``\RD_EN`` - This input is ``\RD_PORTS`` bits wide, containing all enable signals for the - read ports. - -``\RD_ADDR`` - This input is ``\RD_PORTS*\ABITS`` bits wide, containing all address signals - for the read ports. - -``\RD_DATA`` - This output is ``\RD_PORTS*\WIDTH`` bits wide, containing all data signals - for the read ports. - -``\RD_ARST`` - This input is ``\RD_PORTS`` bits wide, containing all asynchronous reset - signals for the read ports. - -``\RD_SRST`` - This input is ``\RD_PORTS`` bits wide, containing all synchronous reset - signals for the read ports. - -``\WR_CLK`` - This input is ``\WR_PORTS`` bits wide, containing all clock signals for - the write ports. - -``\WR_EN`` - This input is ``\WR_PORTS*\WIDTH`` bits wide, containing all enable signals - for the write ports. - -``\WR_ADDR`` - This input is ``\WR_PORTS*\ABITS`` bits wide, containing all address signals - for the write ports. - -``\WR_DATA`` - This input is ``\WR_PORTS*\WIDTH`` bits wide, containing all data signals for - the write ports. - -The `memory_collect` pass can be used to convert discrete `$memrd_v2`, -`$memwr_v2`, and `$meminit_v2` cells belonging to the same memory to a single -`$mem_v2` cell, whereas the `memory_unpack` pass performs the inverse operation. -The `memory_dff` pass can combine asynchronous memory ports that are fed by or -feeding registers into synchronous memory ports. The `memory_bram` pass can be -used to recognize `$mem_v2` cells that can be implemented with a block RAM -resource on an FPGA. The `memory_map` pass can be used to implement `$mem_v2` -cells as basic logic: word-wide DFFs and address decoders. - -Finite state machines -~~~~~~~~~~~~~~~~~~~~~ - -Add a brief description of the `$fsm` cell type. - -Coarse arithmetics -~~~~~~~~~~~~~~~~~~~~~ - -The `$macc` cell type represents a generalized multiply and accumulate -operation. The cell is purely combinational. It outputs the result of summing up -a sequence of products and other injected summands. - -.. code-block:: - - Y = 0 +- a0factor1 * a0factor2 +- a1factor1 * a1factor2 +- ... - + B[0] + B[1] + ... - -The A port consists of concatenated pairs of multiplier inputs ("factors"). A -zero length factor2 acts as a constant 1, turning factor1 into a simple summand. - -In this pseudocode, ``u(foo)`` means an unsigned int that's foo bits long. - -.. code-block:: - - struct A { - u(CONFIG.mul_info[0].factor1_len) a0factor1; - u(CONFIG.mul_info[0].factor2_len) a0factor2; - u(CONFIG.mul_info[1].factor1_len) a1factor1; - u(CONFIG.mul_info[1].factor2_len) a1factor2; - ... - }; - -The cell's ``CONFIG`` parameter determines the layout of cell port ``A``. The -CONFIG parameter carries the following information: - -.. code-block:: - - struct CONFIG { - u4 num_bits; - struct mul_info { - bool is_signed; - bool is_subtract; - u(num_bits) factor1_len; - u(num_bits) factor2_len; - }[num_ports]; - }; - -B is an array of concatenated 1-bit-wide unsigned integers to also be summed up. - -Arbitrary logic functions -~~~~~~~~~~~~~~~~~~~~~~~~~ - -The ``$lut`` cell type implements a single-output LUT (lookup table). -It implements an arbitrary logic function with its ``\LUT`` parameter to map -input port ``\A`` to values of ``\Y`` output port values. -In psuedocode: ``Y = \LUT[A]``. -``\A`` has width set by parameter ``\WIDTH`` and ``\Y`` has a width of 1. -Every logic function with a single bit output has a unique ``$lut`` -representation. - -The ``$sop`` cell type implements a sum-of-products expression, also known -as disjunctive normal form (DNF). It implements an arbitrary logic function. -Its structure mimics a programmable logic array (PLA). -Output port ``\Y`` is the sum of products of the bits of the input port ``\A`` -as defined by parameter ``\TABLE``. ``\A`` is ``\WIDTH`` bits wide. -The number of products in the sum is set by parameter ``\DEPTH``, and each -product has two bits for each input bit - for the presence of the -unnegated and negated version of said input bit in the product. -Therefore the ``\TABLE`` parameter holds ``2 * \WIDTH * \DEPTH`` bits. - -For example: - -Let ``\WIDTH`` be 3. We would like to represent ``\Y =~\A[0] + \A[1]~\A[2]``. -There are 2 products to be summed, so ``\DEPTH`` shall be 2. - -.. code-block:: - - ~A[2]-----+ - A[2]----+| - ~A[1]---+|| - A[1]--+||| - ~A[0]-+|||| - A[0]+||||| - |||||| product formula - 010000 ~\A[0] - 001001 \A[1]~\A[2] - -So the value of ``\TABLE`` will become ``010000001001``. - -Any logic function with a single bit output can be represented with -``$sop`` but may have variously minimized or ordered summands represented -in the ``\TABLE`` values. - -Specify rules -~~~~~~~~~~~~~ - -Add information about `$specify2`, `$specify3`, and `$specrule` cells. - -Formal verification cells -~~~~~~~~~~~~~~~~~~~~~~~~~ - -Add information about `$check`, `$assert`, `$assume`, `$live`, `$fair`, -`$cover`, `$equiv`, `$initstate`, `$anyconst`, `$anyseq`, `$anyinit`, -`$allconst`, `$allseq` cells. - -Add information about `$ff` and `$_FF_` cells. - -Debugging cells -~~~~~~~~~~~~~~~ - -The `$print` cell is used to log the values of signals, akin to (and -translatable to) the ``$display`` and ``$write`` family of tasks in Verilog. It -has the following parameters: - -``\FORMAT`` - The internal format string. The syntax is described below. - -``\ARGS_WIDTH`` - The width (in bits) of the signal on the ``\ARGS`` port. - -``\TRG_ENABLE`` - True if triggered on specific signals defined in ``\TRG``; false if triggered - whenever ``\ARGS`` or ``\EN`` change and ``\EN`` is 1. - -If ``\TRG_ENABLE`` is true, the following parameters also apply: - -``\TRG_WIDTH`` - The number of bits in the ``\TRG`` port. - -``\TRG_POLARITY`` - For each bit in ``\TRG``, 1 if that signal is positive-edge triggered, 0 if - negative-edge triggered. - -``\PRIORITY`` - When multiple `$print` or `$check` cells fire on the same trigger, they - execute in descending priority order. - -Ports: - -``\TRG`` - The signals that control when this `$print` cell is triggered. - - If the width of this port is zero and ``\TRG_ENABLE`` is true, the cell is - triggered during initial evaluation (time zero) only. - -``\EN`` - Enable signal for the whole cell. - -``\ARGS`` - The values to be displayed, in format string order. - -Format string syntax -^^^^^^^^^^^^^^^^^^^^ - -The format string syntax resembles Python f-strings. Regular text is passed -through unchanged until a format specifier is reached, starting with a ``{``. - -Format specifiers have the following syntax. Unless noted, all items are -required: - -``{`` - Denotes the start of the format specifier. - -size - Signal size in bits; this many bits are consumed from the ``\ARGS`` port by - this specifier. - -``:`` - Separates the size from the remaining items. - -justify - ``>`` for right-justified, ``<`` for left-justified. - -padding - ``0`` for zero-padding, or a space for space-padding. - -width\ *?* - (optional) The number of characters wide to pad to. - -base - * ``b`` for base-2 integers (binary) - * ``o`` for base-8 integers (octal) - * ``d`` for base-10 integers (decimal) - * ``h`` for base-16 integers (hexadecimal) - * ``c`` for ASCII characters/strings - * ``t`` and ``r`` for simulation time (corresponding to :verilog:`$time` and - :verilog:`$realtime`) - -For integers, this item may follow: - -``+``\ *?* - (optional, decimals only) Include a leading plus for non-negative numbers. - This can assist with symmetry with negatives in tabulated output. - -signedness - ``u`` for unsigned, ``s`` for signed. This distinction is only respected - when rendering decimals. - -ASCII characters/strings have no special options, but the signal size must be -divisible by 8. - -For simulation time, the signal size must be zero. - -Finally: - -``}`` - Denotes the end of the format specifier. - -Some example format specifiers: - -+ ``{8:>02hu}`` - 8-bit unsigned integer rendered as hexadecimal, - right-justified, zero-padded to 2 characters wide. -+ ``{32:< 15d+s}`` - 32-bit signed integer rendered as decimal, left-justified, - space-padded to 15 characters wide, positive values prefixed with ``+``. -+ ``{16:< 10hu}`` - 16-bit unsigned integer rendered as hexadecimal, - left-justified, space-padded to 10 characters wide. -+ ``{0:>010t}`` - simulation time, right-justified, zero-padded to 10 characters - wide. - -To include literal ``{`` and ``}`` characters in your format string, use ``{{`` -and ``}}`` respectively. - -It is an error for a format string to consume more or less bits from ``\ARGS`` -than the port width. - -Values are never truncated, regardless of the specified width. - -Note that further restrictions on allowable combinations of options may apply -depending on the backend used. - -For example, Verilog does not have a format specifier that allows zero-padding a -string (i.e. more than 1 ASCII character), though zero-padding a single -character is permitted. - -Thus, while the RTLIL format specifier ``{8:>02c}`` translates to ``%02c``, -``{16:>02c}`` cannot be represented in Verilog and will fail to emit. In this -case, ``{16:> 02c}`` must be used, which translates to ``%2s``. - -.. _sec:celllib_gates: - -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 -techlibs/common/simcells.v in the Yosys source tree. - -.. table:: Cell types for gate level logic networks (main list) - :name: tab:CellLib_gates - - ======================================= ============ - Verilog Cell Type - ======================================= ============ - :verilog:`Y = A` $_BUF_ - :verilog:`Y = ~A` $_NOT_ - :verilog:`Y = A & B` $_AND_ - :verilog:`Y = ~(A & B)` $_NAND_ - :verilog:`Y = A & ~B` $_ANDNOT_ - :verilog:`Y = A | B` $_OR_ - :verilog:`Y = ~(A | B)` $_NOR_ - :verilog:`Y = A | ~B` $_ORNOT_ - :verilog:`Y = A ^ B` $_XOR_ - :verilog:`Y = ~(A ^ B)` $_XNOR_ - :verilog:`Y = ~((A & B) | C)` $_AOI3_ - :verilog:`Y = ~((A | B) & C)` $_OAI3_ - :verilog:`Y = ~((A & B) | (C & D))` $_AOI4_ - :verilog:`Y = ~((A | B) & (C | D))` $_OAI4_ - :verilog:`Y = S ? B : A` $_MUX_ - :verilog:`Y = ~(S ? B : A)` $_NMUX_ - (see below) $_MUX4_ - (see below) $_MUX8_ - (see below) $_MUX16_ - :verilog:`Y = EN ? A : 1'bz` $_TBUF_ - :verilog:`always @(negedge C) Q <= D` $_DFF_N_ - :verilog:`always @(posedge C) Q <= D` $_DFF_P_ - :verilog:`always @* if (!E) Q <= D` $_DLATCH_N_ - :verilog:`always @* if (E) Q <= D` $_DLATCH_P_ - ======================================= ============ - -.. table:: Cell types for gate level logic networks (FFs with reset) - :name: tab:CellLib_gates_adff - - ================== ============== ============== ======================= - :math:`ClkEdge` :math:`RstLvl` :math:`RstVal` Cell Type - ================== ============== ============== ======================= - :verilog:`negedge` ``0`` ``0`` $_DFF_NN0_, $_SDFF_NN0_ - :verilog:`negedge` ``0`` ``1`` $_DFF_NN1_, $_SDFF_NN1_ - :verilog:`negedge` ``1`` ``0`` $_DFF_NP0_, $_SDFF_NP0_ - :verilog:`negedge` ``1`` ``1`` $_DFF_NP1_, $_SDFF_NP1_ - :verilog:`posedge` ``0`` ``0`` $_DFF_PN0_, $_SDFF_PN0_ - :verilog:`posedge` ``0`` ``1`` $_DFF_PN1_, $_SDFF_PN1_ - :verilog:`posedge` ``1`` ``0`` $_DFF_PP0_, $_SDFF_PP0_ - :verilog:`posedge` ``1`` ``1`` $_DFF_PP1_, $_SDFF_PP1_ - ================== ============== ============== ======================= - - -.. table:: Cell types for gate level logic networks (FFs with enable) - :name: tab:CellLib_gates_dffe - - ================== ============= =========== - :math:`ClkEdge` :math:`EnLvl` Cell Type - ================== ============= =========== - :verilog:`negedge` ``0`` $_DFFE_NN_ - :verilog:`negedge` ``1`` $_DFFE_NP_ - :verilog:`posedge` ``0`` $_DFFE_PN_ - :verilog:`posedge` ``1`` $_DFFE_PP_ - ================== ============= =========== - - -.. table:: Cell types for gate level logic networks (FFs with reset and enable) - :name: tab:CellLib_gates_adffe - - ================== ============== ============== ============= =========================================== - :math:`ClkEdge` :math:`RstLvl` :math:`RstVal` :math:`EnLvl` Cell Type - ================== ============== ============== ============= =========================================== - :verilog:`negedge` ``0`` ``0`` ``0`` $_DFFE_NN0N_, $_SDFFE_NN0N_, $_SDFFCE_NN0N_ - :verilog:`negedge` ``0`` ``0`` ``1`` $_DFFE_NN0P_, $_SDFFE_NN0P_, $_SDFFCE_NN0P_ - :verilog:`negedge` ``0`` ``1`` ``0`` $_DFFE_NN1N_, $_SDFFE_NN1N_, $_SDFFCE_NN1N_ - :verilog:`negedge` ``0`` ``1`` ``1`` $_DFFE_NN1P_, $_SDFFE_NN1P_, $_SDFFCE_NN1P_ - :verilog:`negedge` ``1`` ``0`` ``0`` $_DFFE_NP0N_, $_SDFFE_NP0N_, $_SDFFCE_NP0N_ - :verilog:`negedge` ``1`` ``0`` ``1`` $_DFFE_NP0P_, $_SDFFE_NP0P_, $_SDFFCE_NP0P_ - :verilog:`negedge` ``1`` ``1`` ``0`` $_DFFE_NP1N_, $_SDFFE_NP1N_, $_SDFFCE_NP1N_ - :verilog:`negedge` ``1`` ``1`` ``1`` $_DFFE_NP1P_, $_SDFFE_NP1P_, $_SDFFCE_NP1P_ - :verilog:`posedge` ``0`` ``0`` ``0`` $_DFFE_PN0N_, $_SDFFE_PN0N_, $_SDFFCE_PN0N_ - :verilog:`posedge` ``0`` ``0`` ``1`` $_DFFE_PN0P_, $_SDFFE_PN0P_, $_SDFFCE_PN0P_ - :verilog:`posedge` ``0`` ``1`` ``0`` $_DFFE_PN1N_, $_SDFFE_PN1N_, $_SDFFCE_PN1N_ - :verilog:`posedge` ``0`` ``1`` ``1`` $_DFFE_PN1P_, $_SDFFE_PN1P_, $_SDFFCE_PN1P_ - :verilog:`posedge` ``1`` ``0`` ``0`` $_DFFE_PP0N_, $_SDFFE_PP0N_, $_SDFFCE_PP0N_ - :verilog:`posedge` ``1`` ``0`` ``1`` $_DFFE_PP0P_, $_SDFFE_PP0P_, $_SDFFCE_PP0P_ - :verilog:`posedge` ``1`` ``1`` ``0`` $_DFFE_PP1N_, $_SDFFE_PP1N_, $_SDFFCE_PP1N_ - :verilog:`posedge` ``1`` ``1`` ``1`` $_DFFE_PP1P_, $_SDFFE_PP1P_, $_SDFFCE_PP1P_ - ================== ============== ============== ============= =========================================== - -.. table:: Cell types for gate level logic networks (FFs with set and reset) - :name: tab:CellLib_gates_dffsr - - ================== ============== ============== ============ - :math:`ClkEdge` :math:`SetLvl` :math:`RstLvl` Cell Type - ================== ============== ============== ============ - :verilog:`negedge` ``0`` ``0`` $_DFFSR_NNN_ - :verilog:`negedge` ``0`` ``1`` $_DFFSR_NNP_ - :verilog:`negedge` ``1`` ``0`` $_DFFSR_NPN_ - :verilog:`negedge` ``1`` ``1`` $_DFFSR_NPP_ - :verilog:`posedge` ``0`` ``0`` $_DFFSR_PNN_ - :verilog:`posedge` ``0`` ``1`` $_DFFSR_PNP_ - :verilog:`posedge` ``1`` ``0`` $_DFFSR_PPN_ - :verilog:`posedge` ``1`` ``1`` $_DFFSR_PPP_ - ================== ============== ============== ============ - - -.. table:: Cell types for gate level logic networks (FFs with set and reset and enable) - :name: tab:CellLib_gates_dffsre - - ================== ============== ============== ============= ============== - :math:`ClkEdge` :math:`SetLvl` :math:`RstLvl` :math:`EnLvl` Cell Type - ================== ============== ============== ============= ============== - :verilog:`negedge` ``0`` ``0`` ``0`` $_DFFSRE_NNNN_ - :verilog:`negedge` ``0`` ``0`` ``1`` $_DFFSRE_NNNP_ - :verilog:`negedge` ``0`` ``1`` ``0`` $_DFFSRE_NNPN_ - :verilog:`negedge` ``0`` ``1`` ``1`` $_DFFSRE_NNPP_ - :verilog:`negedge` ``1`` ``0`` ``0`` $_DFFSRE_NPNN_ - :verilog:`negedge` ``1`` ``0`` ``1`` $_DFFSRE_NPNP_ - :verilog:`negedge` ``1`` ``1`` ``0`` $_DFFSRE_NPPN_ - :verilog:`negedge` ``1`` ``1`` ``1`` $_DFFSRE_NPPP_ - :verilog:`posedge` ``0`` ``0`` ``0`` $_DFFSRE_PNNN_ - :verilog:`posedge` ``0`` ``0`` ``1`` $_DFFSRE_PNNP_ - :verilog:`posedge` ``0`` ``1`` ``0`` $_DFFSRE_PNPN_ - :verilog:`posedge` ``0`` ``1`` ``1`` $_DFFSRE_PNPP_ - :verilog:`posedge` ``1`` ``0`` ``0`` $_DFFSRE_PPNN_ - :verilog:`posedge` ``1`` ``0`` ``1`` $_DFFSRE_PPNP_ - :verilog:`posedge` ``1`` ``1`` ``0`` $_DFFSRE_PPPN_ - :verilog:`posedge` ``1`` ``1`` ``1`` $_DFFSRE_PPPP_ - ================== ============== ============== ============= ============== - - -.. table:: Cell types for gate level logic networks (latches with reset) - :name: tab:CellLib_gates_adlatch - - ============= ============== ============== ============= - :math:`EnLvl` :math:`RstLvl` :math:`RstVal` Cell Type - ============= ============== ============== ============= - ``0`` ``0`` ``0`` $_DLATCH_NN0_ - ``0`` ``0`` ``1`` $_DLATCH_NN1_ - ``0`` ``1`` ``0`` $_DLATCH_NP0_ - ``0`` ``1`` ``1`` $_DLATCH_NP1_ - ``1`` ``0`` ``0`` $_DLATCH_PN0_ - ``1`` ``0`` ``1`` $_DLATCH_PN1_ - ``1`` ``1`` ``0`` $_DLATCH_PP0_ - ``1`` ``1`` ``1`` $_DLATCH_PP1_ - ============= ============== ============== ============= - - -.. table:: Cell types for gate level logic networks (latches with set and reset) - :name: tab:CellLib_gates_dlatchsr - - ============= ============== ============== =============== - :math:`EnLvl` :math:`SetLvl` :math:`RstLvl` Cell Type - ============= ============== ============== =============== - ``0`` ``0`` ``0`` $_DLATCHSR_NNN_ - ``0`` ``0`` ``1`` $_DLATCHSR_NNP_ - ``0`` ``1`` ``0`` $_DLATCHSR_NPN_ - ``0`` ``1`` ``1`` $_DLATCHSR_NPP_ - ``1`` ``0`` ``0`` $_DLATCHSR_PNN_ - ``1`` ``0`` ``1`` $_DLATCHSR_PNP_ - ``1`` ``1`` ``0`` $_DLATCHSR_PPN_ - ``1`` ``1`` ``1`` $_DLATCHSR_PPP_ - ============= ============== ============== =============== - - - -.. table:: Cell types for gate level logic networks (SR latches) - :name: tab:CellLib_gates_sr - - ============== ============== ========= - :math:`SetLvl` :math:`RstLvl` Cell Type - ============== ============== ========= - ``0`` ``0`` $_SR_NN_ - ``0`` ``1`` $_SR_NP_ - ``1`` ``0`` $_SR_PN_ - ``1`` ``1`` $_SR_PP_ - ============== ============== ========= - - -Tables :numref:`%s `, :numref:`%s `, -:numref:`%s `, :numref:`%s `, -:numref:`%s `, :numref:`%s `, -:numref:`%s `, :numref:`%s -` and :numref:`%s ` list all -cell types used for gate level logic. The cell types `$_BUF_`, `$_NOT_`, -`$_AND_`, `$_NAND_`, `$_ANDNOT_`, `$_OR_`, `$_NOR_`, `$_ORNOT_`, `$_XOR_`, -`$_XNOR_`, `$_AOI3_`, `$_OAI3_`, `$_AOI4_`, `$_OAI4_`, `$_MUX_`, `$_MUX4_`, -`$_MUX8_`, `$_MUX16_` and `$_NMUX_` are used to model combinatorial logic. The -cell type `$_TBUF_` is used to model tristate logic. - -The `$_MUX4_`, `$_MUX8_` and `$_MUX16_` cells are used to model wide muxes, and -correspond to the following Verilog code: - -.. code-block:: verilog - :force: - - // $_MUX4_ - assign Y = T ? (S ? D : C) : - (S ? B : A); - // $_MUX8_ - assign Y = U ? T ? (S ? H : G) : - (S ? F : E) : - T ? (S ? D : C) : - (S ? B : A); - // $_MUX16_ - assign Y = V ? U ? T ? (S ? P : O) : - (S ? N : M) : - T ? (S ? L : K) : - (S ? J : I) : - U ? T ? (S ? H : G) : - (S ? F : E) : - T ? (S ? D : C) : - (S ? B : A); - -The cell types `$_DFF_N_` and `$_DFF_P_` represent d-type flip-flops. - -The cell types ``$_DFFE_[NP][NP]_`` implement d-type flip-flops with enable. The -values in the table for these cell types relate to the following Verilog code -template. - -.. code-block:: verilog - :force: - - always @(CLK_EDGE C) - if (EN == EN_LVL) - Q <= D; - -The cell types ``$_DFF_[NP][NP][01]_`` implement d-type flip-flops with -asynchronous reset. The values in the table for these cell types relate to the -following Verilog code template, where ``RST_EDGE`` is ``posedge`` if -``RST_LVL`` if ``1``, and ``negedge`` otherwise. - -.. code-block:: verilog - :force: - - always @(CLK_EDGE C, RST_EDGE R) - if (R == RST_LVL) - Q <= RST_VAL; - else - Q <= D; - -The cell types ``$_SDFF_[NP][NP][01]_`` implement d-type flip-flops with -synchronous reset. The values in the table for these cell types relate to the -following Verilog code template: - -.. code-block:: verilog - :force: - - always @(CLK_EDGE C) - if (R == RST_LVL) - Q <= RST_VAL; - else - Q <= D; - -The cell types ``$_DFFE_[NP][NP][01][NP]_`` implement d-type flip-flops with -asynchronous reset and enable. The values in the table for these cell types -relate to the following Verilog code template, where ``RST_EDGE`` is ``posedge`` -if ``RST_LVL`` if ``1``, and ``negedge`` otherwise. - -.. code-block:: verilog - :force: - - always @(CLK_EDGE C, RST_EDGE R) - if (R == RST_LVL) - Q <= RST_VAL; - else if (EN == EN_LVL) - Q <= D; - -The cell types ``$_SDFFE_[NP][NP][01][NP]_`` implement d-type flip-flops with -synchronous reset and enable, with reset having priority over enable. The values -in the table for these cell types relate to the following Verilog code template: - -.. code-block:: verilog - :force: - - always @(CLK_EDGE C) - if (R == RST_LVL) - Q <= RST_VAL; - else if (EN == EN_LVL) - Q <= D; - -The cell types ``$_SDFFCE_[NP][NP][01][NP]_`` implement d-type flip-flops with -synchronous reset and enable, with enable having priority over reset. The values -in the table for these cell types relate to the following Verilog code template: - -.. code-block:: verilog - :force: - - always @(CLK_EDGE C) - if (EN == EN_LVL) - if (R == RST_LVL) - Q <= RST_VAL; - else - Q <= D; - -The cell types ``$_DFFSR_[NP][NP][NP]_`` implement d-type flip-flops with -asynchronous set and reset. The values in the table for these cell types relate -to the following Verilog code template, where ``RST_EDGE`` is ``posedge`` if -``RST_LVL`` if ``1``, ``negedge`` otherwise, and ``SET_EDGE`` is ``posedge`` if -``SET_LVL`` if ``1``, ``negedge`` otherwise. - -.. code-block:: verilog - :force: - - always @(CLK_EDGE C, RST_EDGE R, SET_EDGE S) - if (R == RST_LVL) - Q <= 0; - else if (S == SET_LVL) - Q <= 1; - else - Q <= D; - -The cell types ``$_DFFSRE_[NP][NP][NP][NP]_`` implement d-type flip-flops with -asynchronous set and reset and enable. The values in the table for these cell -types relate to the following Verilog code template, where ``RST_EDGE`` is -``posedge`` if ``RST_LVL`` if ``1``, ``negedge`` otherwise, and ``SET_EDGE`` is -``posedge`` if ``SET_LVL`` if ``1``, ``negedge`` otherwise. - -.. code-block:: verilog - :force: - - always @(CLK_EDGE C, RST_EDGE R, SET_EDGE S) - if (R == RST_LVL) - Q <= 0; - else if (S == SET_LVL) - Q <= 1; - else if (E == EN_LVL) - Q <= D; - -The cell types `$_DLATCH_N_` and `$_DLATCH_P_` represent d-type latches. - -The cell types ``$_DLATCH_[NP][NP][01]_`` implement d-type latches with reset. -The values in the table for these cell types relate to the following Verilog -code template: - -.. code-block:: verilog - :force: - - always @* - if (R == RST_LVL) - Q <= RST_VAL; - else if (E == EN_LVL) - Q <= D; - -The cell types ``$_DLATCHSR_[NP][NP][NP]_`` implement d-type latches with set -and reset. The values in the table for these cell types relate to the following -Verilog code template: - -.. code-block:: verilog - :force: - - always @* - if (R == RST_LVL) - Q <= 0; - else if (S == SET_LVL) - Q <= 1; - else if (E == EN_LVL) - Q <= D; - -The cell types ``$_SR_[NP][NP]_`` implement sr-type latches. The values in the -table for these cell types relate to the following Verilog code template: - -.. code-block:: verilog - :force: - - always @* - if (R == RST_LVL) - Q <= 0; - else if (S == SET_LVL) - Q <= 1; - -In most cases gate level logic networks are created from RTL networks using the -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 dfflibmap pass. -The combinatorial logic cells can be mapped to physical cells from a Liberty -file via ABC using the abc pass. - -.. todo:: Add information about `$slice` and `$concat` cells. - -.. todo:: Add information about `$alu`, `$fa`, and `$lcu` cells. - -.. todo:: Add information about ``$demux`` cell. \ No newline at end of file diff --git a/techlibs/common/simlib.v b/techlibs/common/simlib.v index fb294b53bd1..d567b7b0b56 100644 --- a/techlibs/common/simlib.v +++ b/techlibs/common/simlib.v @@ -601,6 +601,7 @@ assign Y = t1 ^ C, X = (t2 | t3) ^ (Y ^ Y); endmodule // -------------------------------------------------------- +//* group arith // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- @@ -639,6 +640,7 @@ endmodule //* ver 2 //* title Arithmetic logic unit +//* group arith //- A building block supporting both binary addition/subtraction operations, and //- indirectly, comparison operations. //- Typically created by the `alumacc` pass, which transforms: @@ -1055,6 +1057,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $macc (A, B, Y) +//* group arith //- //- Multiply and accumulate. //- A building block for summing any number of negated and unnegated signals @@ -1510,6 +1513,7 @@ assign Y = {B, A}; endmodule // -------------------------------------------------------- +//* group mux // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- @@ -1530,6 +1534,7 @@ assign Y = S ? B : A; endmodule // -------------------------------------------------------- +//* group mux module \$bmux (A, S, Y); @@ -1557,6 +1562,7 @@ endgenerate endmodule // -------------------------------------------------------- +//* group mux module \$pmux (A, B, S, Y); @@ -1591,6 +1597,7 @@ end endmodule // -------------------------------------------------------- +//* group mux // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- @@ -1662,6 +1669,7 @@ end endmodule // -------------------------------------------------------- +//* group mux // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- @@ -1684,6 +1692,7 @@ assign Y = EN ? A : 'bz; endmodule // -------------------------------------------------------- +//* group spec module \$specify2 (EN, SRC, DST); @@ -1722,6 +1731,7 @@ endspecify endmodule // -------------------------------------------------------- +//* group spec module \$specify3 (EN, SRC, DST, DAT); @@ -1830,6 +1840,7 @@ endspecify endmodule // -------------------------------------------------------- +//* group spec module \$specrule (EN_SRC, EN_DST, SRC, DST); @@ -1896,6 +1907,7 @@ endgenerate endmodule // -------------------------------------------------------- +//* group formal module \$assert (A, EN); @@ -1913,6 +1925,7 @@ end endmodule // -------------------------------------------------------- +//* group formal module \$assume (A, EN); @@ -1930,6 +1943,7 @@ end endmodule // -------------------------------------------------------- +//* group formal module \$live (A, EN); @@ -1938,6 +1952,7 @@ input A, EN; endmodule // -------------------------------------------------------- +//* group formal module \$fair (A, EN); @@ -1946,6 +1961,7 @@ input A, EN; endmodule // -------------------------------------------------------- +//* group formal module \$cover (A, EN); @@ -1954,6 +1970,7 @@ input A, EN; endmodule // -------------------------------------------------------- +//* group formal module \$initstate (Y); @@ -1971,6 +1988,7 @@ end endmodule // -------------------------------------------------------- +//* group formal module \$anyconst (Y); @@ -1983,6 +2001,7 @@ assign Y = 'bx; endmodule // -------------------------------------------------------- +//* group formal module \$anyseq (Y); @@ -1999,6 +2018,7 @@ endmodule `ifndef SIMLIB_GLOBAL_CLOCK `define SIMLIB_GLOBAL_CLOCK $global_clk `endif +//* group formal module \$anyinit (D, Q); parameter WIDTH = 0; @@ -2015,6 +2035,7 @@ end endmodule `endif // -------------------------------------------------------- +//* group formal module \$allconst (Y); @@ -2027,6 +2048,7 @@ assign Y = 'bx; endmodule // -------------------------------------------------------- +//* group formal module \$allseq (Y); @@ -2039,6 +2061,7 @@ assign Y = 'bx; endmodule // -------------------------------------------------------- +//* group formal module \$equiv (A, B, Y); @@ -2059,6 +2082,7 @@ end endmodule // -------------------------------------------------------- +//* group debug module \$print (EN, TRG, ARGS); @@ -2078,6 +2102,7 @@ input [ARGS_WIDTH-1:0] ARGS; endmodule // -------------------------------------------------------- +//* group debug module \$check (A, EN, TRG, ARGS); @@ -2100,6 +2125,7 @@ endmodule // -------------------------------------------------------- `ifndef SIMLIB_NOSR +//* group reg module \$sr (SET, CLR, Q); @@ -2132,6 +2158,7 @@ endmodule `ifndef SIMLIB_GLOBAL_CLOCK `define SIMLIB_GLOBAL_CLOCK $global_clk `endif +//* group formal module \$ff (D, Q); @@ -2148,6 +2175,7 @@ endmodule `endif // -------------------------------------------------------- +//* group reg module \$dff (CLK, D, Q); @@ -2166,6 +2194,7 @@ end endmodule // -------------------------------------------------------- +//* group reg module \$dffe (CLK, EN, D, Q); @@ -2186,6 +2215,7 @@ endmodule // -------------------------------------------------------- `ifndef SIMLIB_NOSR +//* group reg module \$dffsr (CLK, SET, CLR, D, Q); @@ -2218,6 +2248,7 @@ endgenerate endmodule // -------------------------------------------------------- +//* group reg module \$dffsre (CLK, SET, CLR, EN, D, Q); @@ -2252,6 +2283,7 @@ endmodule `endif // -------------------------------------------------------- +//* group reg module \$adff (CLK, ARST, D, Q); @@ -2276,6 +2308,7 @@ end endmodule // -------------------------------------------------------- +//* group reg module \$aldff (CLK, ALOAD, AD, D, Q); @@ -2300,6 +2333,7 @@ end endmodule // -------------------------------------------------------- +//* group reg module \$sdff (CLK, SRST, D, Q); @@ -2324,6 +2358,7 @@ end endmodule // -------------------------------------------------------- +//* group reg module \$adffe (CLK, ARST, EN, D, Q); @@ -2349,6 +2384,7 @@ end endmodule // -------------------------------------------------------- +//* group reg module \$aldffe (CLK, ALOAD, AD, EN, D, Q); @@ -2374,6 +2410,7 @@ end endmodule // -------------------------------------------------------- +//* group reg module \$sdffe (CLK, SRST, EN, D, Q); @@ -2399,6 +2436,7 @@ end endmodule // -------------------------------------------------------- +//* group reg module \$sdffce (CLK, SRST, EN, D, Q); @@ -2426,6 +2464,7 @@ end endmodule // -------------------------------------------------------- +//* group reg module \$dlatch (EN, D, Q); @@ -2444,6 +2483,7 @@ end endmodule // -------------------------------------------------------- +//* group reg module \$adlatch (EN, ARST, D, Q); @@ -2467,6 +2507,7 @@ endmodule // -------------------------------------------------------- `ifndef SIMLIB_NOSR +//* group reg module \$dlatchsr (EN, SET, CLR, D, Q); @@ -2500,6 +2541,7 @@ endmodule `endif // -------------------------------------------------------- +//* group fsm module \$fsm (CLK, ARST, CTRL_IN, CTRL_OUT); @@ -2594,6 +2636,7 @@ endmodule // -------------------------------------------------------- `ifndef SIMLIB_NOMEM +//* group mem module \$memrd (CLK, EN, ADDR, DATA); @@ -2618,6 +2661,8 @@ end endmodule +//* group mem + module \$memrd_v2 (CLK, EN, ARST, SRST, ADDR, DATA); parameter MEMID = ""; @@ -2647,6 +2692,7 @@ end endmodule // -------------------------------------------------------- +//* group mem module \$memwr (CLK, EN, ADDR, DATA); @@ -2672,6 +2718,7 @@ end endmodule +//* group mem module \$memwr_v2 (CLK, EN, ADDR, DATA); parameter MEMID = ""; @@ -2698,6 +2745,7 @@ end endmodule // -------------------------------------------------------- +//* group mem module \$meminit (ADDR, DATA); @@ -2721,6 +2769,7 @@ end endmodule // -------------------------------------------------------- +//* group mem module \$meminit_v2 (ADDR, DATA, EN); @@ -2745,6 +2794,7 @@ end endmodule // -------------------------------------------------------- +//* group mem module \$mem (RD_CLK, RD_EN, RD_ADDR, RD_DATA, WR_CLK, WR_EN, WR_ADDR, WR_DATA); @@ -2833,6 +2883,8 @@ end endmodule +//* group mem + module \$mem_v2 (RD_CLK, RD_EN, RD_ARST, RD_SRST, RD_ADDR, RD_DATA, WR_CLK, WR_EN, WR_ADDR, WR_DATA); parameter MEMID = ""; From 46580cebb34ff8b5020c94237be8359c0423196a Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Mon, 27 May 2024 15:47:15 +1200 Subject: [PATCH 37/68] Docs: Move rtlil_text (back) to appendix --- .../formats => appendix}/rtlil_text.rst | 4 +- docs/source/index.rst | 1 + docs/source/yosys_internals/flow/overview.rst | 2 +- docs/source/yosys_internals/formats/index.rst | 58 +++++++++++++++++-- .../yosys_internals/formats/overview.rst | 53 ----------------- 5 files changed, 56 insertions(+), 62 deletions(-) rename docs/source/{yosys_internals/formats => appendix}/rtlil_text.rst (98%) delete mode 100644 docs/source/yosys_internals/formats/overview.rst diff --git a/docs/source/yosys_internals/formats/rtlil_text.rst b/docs/source/appendix/rtlil_text.rst similarity index 98% rename from docs/source/yosys_internals/formats/rtlil_text.rst rename to docs/source/appendix/rtlil_text.rst index 8b5c1068120..7febae2edfc 100644 --- a/docs/source/yosys_internals/formats/rtlil_text.rst +++ b/docs/source/appendix/rtlil_text.rst @@ -223,8 +223,8 @@ Cells Declares a cell, with zero or more attributes, with the given identifier and type in the enclosing module. -Cells perform functions on input signals. See -:doc:`/yosys_internals/formats/cell_library` for a detailed list of cell types. +Cells perform functions on input signals. See :doc:`/cell_gate` and +:doc:`/cell_word` for a detailed list of cell types. .. code:: BNF diff --git a/docs/source/index.rst b/docs/source/index.rst index ce612f9b0bc..fbdd5ac6f80 100644 --- a/docs/source/index.rst +++ b/docs/source/index.rst @@ -44,6 +44,7 @@ available, go to :ref:`commandindex`. :includehidden: appendix/primer + appendix/rtlil_text appendix/auxlibs appendix/auxprogs diff --git a/docs/source/yosys_internals/flow/overview.rst b/docs/source/yosys_internals/flow/overview.rst index b357e5b50ea..3effe462bc7 100644 --- a/docs/source/yosys_internals/flow/overview.rst +++ b/docs/source/yosys_internals/flow/overview.rst @@ -20,7 +20,7 @@ given in :doc:`/yosys_internals/formats/rtlil_rep`. There is also a text representation of the RTLIL data structure that can be parsed using the RTLIL Frontend which is described in -:doc:`/yosys_internals/formats/rtlil_text`. +:doc:`/appendix/rtlil_text`. The design data may then be transformed using a series of passes that all operate on the RTLIL representation of the design. diff --git a/docs/source/yosys_internals/formats/index.rst b/docs/source/yosys_internals/formats/index.rst index c187a8238a8..611370ebc43 100644 --- a/docs/source/yosys_internals/formats/index.rst +++ b/docs/source/yosys_internals/formats/index.rst @@ -1,13 +1,59 @@ Internal formats ================ -.. todo:: brief overview for the internal formats index +Yosys uses two different internal formats. The first is used to store an +abstract syntax tree (AST) of a Verilog input file. This format is simply called +AST and is generated by the Verilog Frontend. This data structure is consumed by +a subsystem called AST Frontend [1]_. This AST Frontend then generates a design +in Yosys' main internal format, the +Register-Transfer-Level-Intermediate-Language (RTLIL) representation. It does +that by first performing a number of simplifications within the AST +representation and then generating RTLIL from the simplified AST data structure. + +The RTLIL representation is used by all passes as input and outputs. This has +the following advantages over using different representational formats between +different passes: + +- The passes can be rearranged in a different order and passes can be removed + or inserted. + +- Passes can simply pass-thru the parts of the design they don't change without + the need to convert between formats. In fact Yosys passes output the same + data structure they received as input and performs all changes in place. + +- All passes use the same interface, thus reducing the effort required to + understand a pass when reading the Yosys source code, e.g. when adding + additional features. + +The RTLIL representation is basically a netlist representation with the +following additional features: + +- An internal cell library with fixed-function cells to represent RTL datapath + and register cells as well as logical gate-level cells (single-bit gates and + registers). + +- Support for multi-bit values that can use individual bits from wires as well + as constant bits to represent coarse-grain netlists. + +- Support for basic behavioural constructs (if-then-else structures and + multi-case switches with a sensitivity list for updating the outputs). + +- Support for multi-port memories. + +The use of RTLIL also has the disadvantage of having a very powerful format +between all passes, even when doing gate-level synthesis where the more advanced +features are not needed. In order to reduce complexity for passes that operate +on a low-level representation, these passes check the features used in the input +RTLIL and fail to run when unsupported high-level constructs are used. In such +cases a pass that transforms the higher-level constructs to lower-level +constructs must be called from the synthesis script first. .. toctree:: - :maxdepth: 3 + :maxdepth: 3 + + rtlil_rep - overview - rtlil_rep - rtlil_text - cell_library +.. [1] + In Yosys the term pass is only used to refer to commands that operate on the + RTLIL data structure. diff --git a/docs/source/yosys_internals/formats/overview.rst b/docs/source/yosys_internals/formats/overview.rst deleted file mode 100644 index cbf5369bc06..00000000000 --- a/docs/source/yosys_internals/formats/overview.rst +++ /dev/null @@ -1,53 +0,0 @@ -Format overview -=============== - -Yosys uses two different internal formats. The first is used to store an -abstract syntax tree (AST) of a Verilog input file. This format is simply called -AST and is generated by the Verilog Frontend. This data structure is consumed by -a subsystem called AST Frontend [1]_. This AST Frontend then generates a design -in Yosys' main internal format, the -Register-Transfer-Level-Intermediate-Language (RTLIL) representation. It does -that by first performing a number of simplifications within the AST -representation and then generating RTLIL from the simplified AST data structure. - -The RTLIL representation is used by all passes as input and outputs. This has -the following advantages over using different representational formats between -different passes: - -- The passes can be rearranged in a different order and passes can be removed - or inserted. - -- Passes can simply pass-thru the parts of the design they don't change without - the need to convert between formats. In fact Yosys passes output the same - data structure they received as input and performs all changes in place. - -- All passes use the same interface, thus reducing the effort required to - understand a pass when reading the Yosys source code, e.g. when adding - additional features. - -The RTLIL representation is basically a netlist representation with the -following additional features: - -- An internal cell library with fixed-function cells to represent RTL datapath - and register cells as well as logical gate-level cells (single-bit gates and - registers). - -- Support for multi-bit values that can use individual bits from wires as well - as constant bits to represent coarse-grain netlists. - -- Support for basic behavioural constructs (if-then-else structures and - multi-case switches with a sensitivity list for updating the outputs). - -- Support for multi-port memories. - -The use of RTLIL also has the disadvantage of having a very powerful format -between all passes, even when doing gate-level synthesis where the more advanced -features are not needed. In order to reduce complexity for passes that operate -on a low-level representation, these passes check the features used in the input -RTLIL and fail to run when unsupported high-level constructs are used. In such -cases a pass that transforms the higher-level constructs to lower-level -constructs must be called from the synthesis script first. - -.. [1] - In Yosys the term pass is only used to refer to commands that operate on the - RTLIL data structure. \ No newline at end of file From 2b4a4cb536edcbb03af9ac2277a8db53eae19a4c Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Mon, 27 May 2024 15:48:00 +1200 Subject: [PATCH 38/68] Docs: Fix fsm.rst `$mux-tree` should be `$mux`-tree. --- docs/source/using_yosys/synthesis/fsm.rst | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/docs/source/using_yosys/synthesis/fsm.rst b/docs/source/using_yosys/synthesis/fsm.rst index cc3d0879d07..9a0e045cc84 100644 --- a/docs/source/using_yosys/synthesis/fsm.rst +++ b/docs/source/using_yosys/synthesis/fsm.rst @@ -63,12 +63,10 @@ information is determined: The state registers (and asynchronous reset state, if applicable) is simply determined by identifying the driver for the state signal. -.. todo:: Figure out what `$mux-tree` should actually be. - -From there the `$mux-tree` driving the state register inputs is recursively -traversed. All select inputs are control signals and the leaves of the -`$mux-tree` are the states. The algorithm fails if a non-constant leaf that is -not the state signal itself is found. +From there the `$mux`\ -tree driving the state register inputs is recursively +traversed. All select inputs are control signals and the leaves of the `$mux`\ +-tree are the states. The algorithm fails if a non-constant leaf that is not the +state signal itself is found. The list of control outputs is initialized with the bits from the state signal. It is then extended by adding all values that are calculated by cells that From be5572ca0e3640c6d3365b64daab3ffec0c5e08c Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Mon, 27 May 2024 16:02:17 +1200 Subject: [PATCH 39/68] Docs: Less leading backslashes --- docs/source/using_yosys/synthesis/fsm.rst | 16 ++++++++-------- docs/source/using_yosys/synthesis/opt.rst | 2 +- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/source/using_yosys/synthesis/fsm.rst b/docs/source/using_yosys/synthesis/fsm.rst index 9a0e045cc84..6fad81d54e4 100644 --- a/docs/source/using_yosys/synthesis/fsm.rst +++ b/docs/source/using_yosys/synthesis/fsm.rst @@ -19,24 +19,24 @@ FSM detection ~~~~~~~~~~~~~ The `fsm_detect` pass identifies FSM state registers. It sets the -``\fsm_encoding = "auto"`` attribute on any (multi-bit) wire that matches the +``fsm_encoding = "auto"`` attribute on any (multi-bit) wire that matches the following description: -- Does not already have the ``\fsm_encoding`` attribute. +- Does not already have the ``fsm_encoding`` attribute. - Is not an output of the containing module. - Is driven by single `$dff` or `$adff` cell. -- The ``\D``-Input of this `$dff` or `$adff` cell is driven by a multiplexer +- The ``D``-Input of this `$dff` or `$adff` cell is driven by a multiplexer tree that only has constants or the old state value on its leaves. - The state value is only used in the said multiplexer tree or by simple relational cells that compare the state value to a constant (usually `$eq` cells). This heuristic has proven to work very well. It is possible to overwrite it by -setting ``\fsm_encoding = "auto"`` on registers that should be considered FSM -state registers and setting ``\fsm_encoding = "none"`` on registers that match +setting ``fsm_encoding = "auto"`` on registers that should be considered FSM +state registers and setting ``fsm_encoding = "none"`` on registers that match the above criteria but should not be considered FSM state registers. -Note however that marking state registers with ``\fsm_encoding`` that are not +Note however that marking state registers with ``fsm_encoding`` that are not suitable for FSM recoding can cause synthesis to fail or produce invalid results. @@ -44,7 +44,7 @@ FSM extraction ~~~~~~~~~~~~~~ The `fsm_extract` pass operates on all state signals marked with the -(``\fsm_encoding != "none"``) attribute. For each state signal the following +(``fsm_encoding != "none"``) attribute. For each state signal the following information is determined: - The state registers @@ -109,7 +109,7 @@ The `fsm_opt` pass performs basic optimizations on `$fsm` cells (not including state recoding). The following optimizations are performed (in this order): - Unused control outputs are removed from the `$fsm` cell. The attribute - ``\unused_bits`` (that is usually set by the `opt_clean` pass) is used to + ``unused_bits`` (that is usually set by the `opt_clean` pass) is used to determine which control outputs are unused. - Control inputs that are connected to the same driver are merged. diff --git a/docs/source/using_yosys/synthesis/opt.rst b/docs/source/using_yosys/synthesis/opt.rst index 87763dbbe0a..d79a66a755e 100644 --- a/docs/source/using_yosys/synthesis/opt.rst +++ b/docs/source/using_yosys/synthesis/opt.rst @@ -196,7 +196,7 @@ Removing unused cells and wires - `opt_clean` pass ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This pass identifies unused signals and cells and removes them from the design. -It also creates an ``\unused_bits`` attribute on wires with unused bits. This +It also creates an ``unused_bits`` attribute on wires with unused bits. This attribute can be used for debugging or by other optimization passes. When to use `opt` or `clean` From 6aceb6a29786426f0ee60551496d98e1c1b918a3 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Mon, 27 May 2024 16:32:45 +1200 Subject: [PATCH 40/68] cmdref.py: Support autoref for 'help ' --- docs/util/cmdref.py | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/util/cmdref.py b/docs/util/cmdref.py index 6fbd813726d..c7bb4e241d9 100644 --- a/docs/util/cmdref.py +++ b/docs/util/cmdref.py @@ -430,9 +430,12 @@ class CellDomain(CommandDomain): TagIndex } -def autoref(name, rawtext, text, lineno, inliner: Inliner, +def autoref(name, rawtext: str, text: str, lineno, inliner: Inliner, options=None, content=None): role = 'cell:ref' if text[0] == '$' else 'cmd:ref' + if text.startswith("help ") and text.count(' ') == 1: + _, cmd = text.split(' ', 1) + text = f'{text} <{cmd}>' return inliner.interpreted(rawtext, text, role, lineno) def setup(app: Sphinx): From e78841ba45b53e0b2370583ba57d22d6828383a3 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Mon, 27 May 2024 16:33:00 +1200 Subject: [PATCH 41/68] Docs: Fix invalid autorefs --- docs/source/getting_started/installation.rst | 4 ++-- docs/source/using_yosys/synthesis/techmap_synth.rst | 4 ++-- docs/source/yosys_internals/extending_yosys/extensions.rst | 6 +++--- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/source/getting_started/installation.rst b/docs/source/getting_started/installation.rst index 5fed508ed25..57ae5303639 100644 --- a/docs/source/getting_started/installation.rst +++ b/docs/source/getting_started/installation.rst @@ -109,7 +109,7 @@ Installing all prerequisites for macOS 11 (with Homebrew): Running the build system ^^^^^^^^^^^^^^^^^^^^^^^^ -From the root `yosys` directory, call the following commands: +From the root ``yosys`` directory, call the following commands: .. code:: console @@ -117,7 +117,7 @@ From the root `yosys` directory, call the following commands: sudo make install This will build and then install Yosys, making it available on the command line -as `yosys`. Note that this also downloads, builds, and installs `ABC`_ (using +as ``yosys``. Note that this also downloads, builds, and installs `ABC`_ (using :program:`yosys-abc` as the executable name). .. _ABC: https://github.com/berkeley-abc/abc diff --git a/docs/source/using_yosys/synthesis/techmap_synth.rst b/docs/source/using_yosys/synthesis/techmap_synth.rst index dc9d8b1954b..9e9d42df584 100644 --- a/docs/source/using_yosys/synthesis/techmap_synth.rst +++ b/docs/source/using_yosys/synthesis/techmap_synth.rst @@ -29,8 +29,8 @@ provided implementation. When no map file is provided, techmap uses a built-in map file that maps the Yosys RTL cell types to the internal gate library used by Yosys. The curious -reader may find this map file as `techlibs/common/techmap.v` in the Yosys source -tree. +reader may find this map file as :file:`techlibs/common/techmap.v` in the Yosys +source tree. Additional features have been added to techmap to allow for conditional mapping of cells (see :doc:`/cmd/techmap`). This can for example be useful if the target diff --git a/docs/source/yosys_internals/extending_yosys/extensions.rst b/docs/source/yosys_internals/extending_yosys/extensions.rst index 88e001d0666..4063641d479 100644 --- a/docs/source/yosys_internals/extending_yosys/extensions.rst +++ b/docs/source/yosys_internals/extending_yosys/extensions.rst @@ -11,9 +11,9 @@ Writing extensions This chapter contains some bits and pieces of information about programming yosys extensions. Don't be afraid to ask questions on the YosysHQ Slack. -The `guidelines/` directory of the Yosys source code contains notes on various -aspects of Yosys development. In particular, the files GettingStarted and -CodingStyle may be of interest. +The :file:`guidelines/` directory of the Yosys source code contains notes on +various aspects of Yosys development. In particular, the files GettingStarted +and CodingStyle may be of interest. .. todo:: what's in guidelines/GettingStarted that's missing from the manual? From 11d2cbced24b14690bb73abe57ca95b9cb894361 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Mon, 27 May 2024 16:42:06 +1200 Subject: [PATCH 42/68] Docs: Don't delete source/cell on make clean --- docs/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/Makefile b/docs/Makefile index 9be050d35ea..6dbf6f4902b 100644 --- a/docs/Makefile +++ b/docs/Makefile @@ -47,7 +47,7 @@ help: .PHONY: clean clean: clean-examples rm -rf $(BUILDDIR)/* - rm -rf source/cell source/cmd util/__pycache__ + rm -rf source/cmd util/__pycache__ rm -rf source/generated $(MAKE) -C source/_images clean From c6414e08ebf6368c10dd17ab57e065c35b58503a Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Sat, 8 Jun 2024 15:41:52 +1200 Subject: [PATCH 43/68] Docs: Switch to furo-ys for YoscryptLexer --- docs/source/conf.py | 2 +- docs/util/YoscryptLexer.py | 73 -------------------------------------- 2 files changed, 1 insertion(+), 74 deletions(-) delete mode 100644 docs/util/YoscryptLexer.py diff --git a/docs/source/conf.py b/docs/source/conf.py index 8e504df5577..babbc9b5320 100644 --- a/docs/source/conf.py +++ b/docs/source/conf.py @@ -87,5 +87,5 @@ def setup(app: Sphinx) -> None: from util.RtlilLexer import RtlilLexer app.add_lexer("RTLIL", RtlilLexer) - from util.YoscryptLexer import YoscryptLexer + from furo_ys.lexers.YoscryptLexer import YoscryptLexer app.add_lexer("yoscrypt", YoscryptLexer) diff --git a/docs/util/YoscryptLexer.py b/docs/util/YoscryptLexer.py deleted file mode 100644 index 8cb31c81aee..00000000000 --- a/docs/util/YoscryptLexer.py +++ /dev/null @@ -1,73 +0,0 @@ -from pygments.lexer import RegexLexer, bygroups, include -from pygments.token import (Comment, Error, Keyword, Name, Number, Operator, - String, Whitespace) - -__all__ = ['YoscryptLexer'] - -class YoscryptLexer(RegexLexer): - name = 'Yosys Script' - aliases = ['yoscrypt'] - filenames = ['*.ys'] - - - - tokens = { - 'common': [ - (r'\s+', Whitespace), - (r'#.*', Comment.Single), - (r'"', String, 'string'), - (r'(\d+)(\')([bdho]? ?\w+)', bygroups(Number, Operator, Number)), - (r'(\d+\.\d+)', Number.Float), - (r'(\d+)', Number), - (r'(\$[A-Za-z_0-9]*)', Name.Builtin), - (r'([A-Za-z_][A-Za-z_0-9\.\\/:-]*)', Name), - (r'(\[)(-\S*)(\])', # optional command - bygroups(Operator, Name.Attribute, Operator)), - (r'([\[<]\w*[\]>])', Name), # arguments - (r'[\{\}\|=\[\],]', Operator), - (r'.', Comment), - ], - 'root': [ - (r'([A-Za-z_][A-Za-z_0-9]*)', Keyword, 'command'), - (r'(-[A-Za-z_][A-Za-z_0-9]*)', Name.Attribute, 'command'), # shortcut for options - include('common'), - ], - 'command': [ - (r'(-[A-Za-z_][A-Za-z_0-9]*)', Name.Attribute), - (r'\+/[^\s]+', Name.Class), - (r'$', Whitespace, '#pop'), - (r';(?=\s)', Operator, '#pop'), - (r';{2,3}(?=\s)', Name.Class, '#pop'), - (r';{1,3}', Error, '#pop'), - (r'([ANwismctparn]:)', Keyword.Type, 'pattern'), - (r'@', Keyword.Type), - (r'%(x|ci|co)e?', Keyword.Type, 'expansion'), - (r'%[%nuidDcasmMCR]?', Keyword.Type), - (r'/', Operator), - include('common'), - ], - 'pattern': [ - (r'<<', Name), # Not an operator - (r'(=|<|<=|>|>=)', Operator), - (r':', Keyword.Type), - (r'$', Whitespace, '#pop:2'), - (r'\s+', Whitespace, '#pop'), - include('common'), - ], - 'expansion': [ - (r'$', Name.Class, '#pop:2'), - (r';(?=\s)', Operator, '#pop:2'), - (r';{2,3}(?=\s)', Name.Class, '#pop:2'), - (r'\s', Whitespace, '#pop'), - (r'[0-9\*]{1,3}', Number), - (r'[:+-,\[\]]', Operator), - include('common'), - ], - 'string': [ - (r'"', String, '#pop'), - (r'\\([\\abfnrtv"\']|x[a-fA-F0-9]{2,4}|[0-7]{1,3})', String.Escape), - (r'[^\\"\n]+', String), # all other characters - (r'(\\)(\n)', bygroups(String.Escape, Whitespace)), # line continuation - (r'\\', String), # stray backslash - ] - } From 78b9dbd4eab8b3ac5c35590e78649c5eb44d0b13 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Tue, 27 Aug 2024 10:48:28 +1200 Subject: [PATCH 44/68] Docs: Assign remaining word cells to groups Move todos to correct place. Add todo for x-prop cells. --- docs/source/cell/word_arith.rst | 2 ++ docs/source/cell/word_binary.rst | 2 ++ docs/source/cell/word_formal.rst | 8 ++++++++ docs/source/cell/word_wire.rst | 9 +++++++++ docs/source/cell_word.rst | 6 +++--- techlibs/common/simlib.v | 22 +++++++++++----------- 6 files changed, 35 insertions(+), 14 deletions(-) create mode 100644 docs/source/cell/word_wire.rst diff --git a/docs/source/cell/word_arith.rst b/docs/source/cell/word_arith.rst index 38111a7d542..eb1bfdada49 100644 --- a/docs/source/cell/word_arith.rst +++ b/docs/source/cell/word_arith.rst @@ -1,6 +1,8 @@ Coarse arithmetics ------------------ +.. todo:: Add information about `$alu`, `$fa`, and `$lcu` cells. + Multiply-accumulate ~~~~~~~~~~~~~~~~~~~ diff --git a/docs/source/cell/word_binary.rst b/docs/source/cell/word_binary.rst index 47a847ee446..68bc5a3aafc 100644 --- a/docs/source/cell/word_binary.rst +++ b/docs/source/cell/word_binary.rst @@ -4,6 +4,8 @@ Binary operators ~~~~~~~~~~~~~~~~ +.. todo:: Add detail on ``$*x`` cells, `$eqx`, `$nex`, `$bweqx`, `$shiftx` + All binary RTL cells have two input ports ``A`` and ``B`` and one output port ``Y``. They also have the following parameters: diff --git a/docs/source/cell/word_formal.rst b/docs/source/cell/word_formal.rst index 81bab898873..ae0f56025cf 100644 --- a/docs/source/cell/word_formal.rst +++ b/docs/source/cell/word_formal.rst @@ -12,3 +12,11 @@ Formal verification cells :members: :source: :linenos: + +Formal support cells +~~~~~~~~~~~~~~~~~~~~ + +.. autocellgroup:: formal_tag + :members: + :source: + :linenos: diff --git a/docs/source/cell/word_wire.rst b/docs/source/cell/word_wire.rst new file mode 100644 index 00000000000..0434cceaef4 --- /dev/null +++ b/docs/source/cell/word_wire.rst @@ -0,0 +1,9 @@ +Wire cells +------------------------- + +.. todo:: Add information about `$slice` and `$concat` cells. + +.. autocellgroup:: wire + :members: + :source: + :linenos: diff --git a/docs/source/cell_word.rst b/docs/source/cell_word.rst index a736801fabc..3c87d991345 100644 --- a/docs/source/cell_word.rst +++ b/docs/source/cell_word.rst @@ -27,10 +27,10 @@ Simulation models for the RTL cells can be found in the file /cell/word_spec /cell/word_formal /cell/word_debug + /cell/word_wire -.. todo:: Add information about `$slice` and `$concat` cells. - -.. todo:: Add information about `$alu`, `$fa`, and `$lcu` cells. +.. this should raise a warning, otherwise there are word-level cells without a + 'group' tag .. autocellgroup:: word_other :caption: Other word-level cells diff --git a/techlibs/common/simlib.v b/techlibs/common/simlib.v index d567b7b0b56..a954b64ec6d 100644 --- a/techlibs/common/simlib.v +++ b/techlibs/common/simlib.v @@ -585,7 +585,7 @@ endgenerate endmodule // -------------------------------------------------------- - +//* group arith module \$fa (A, B, C, X, Y); parameter WIDTH = 1; @@ -1477,7 +1477,7 @@ endgenerate endmodule // -------------------------------------------------------- - +//* group wire module \$slice (A, Y); parameter OFFSET = 0; @@ -1492,10 +1492,10 @@ assign Y = A >> OFFSET; endmodule // -------------------------------------------------------- - // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $concat (A, B, Y) +//* group wire //- //- Concatenation of inputs into a single output ( Y = {B, A} ). //- @@ -1870,7 +1870,7 @@ endspecify endmodule // -------------------------------------------------------- - +//* group binary module \$bweqx (A, B, Y); parameter WIDTH = 0; @@ -1888,7 +1888,7 @@ endgenerate endmodule // -------------------------------------------------------- - +//* group mux module \$bwmux (A, B, S, Y); parameter WIDTH = 0; @@ -3004,7 +3004,7 @@ endmodule `endif // -------------------------------------------------------- - +//* group formal_tag module \$set_tag (A, SET, CLR, Y); parameter TAG = ""; @@ -3020,7 +3020,7 @@ assign Y = A; endmodule // -------------------------------------------------------- - +//* group formal_tag module \$get_tag (A, Y); parameter TAG = ""; @@ -3034,7 +3034,7 @@ assign Y = A; endmodule // -------------------------------------------------------- - +//* group formal_tag module \$overwrite_tag (A, SET, CLR); parameter TAG = ""; @@ -3047,7 +3047,7 @@ input [WIDTH-1:0] CLR; endmodule // -------------------------------------------------------- - +//* group formal_tag module \$original_tag (A, Y); parameter TAG = ""; @@ -3061,7 +3061,7 @@ assign Y = A; endmodule // -------------------------------------------------------- - +//* group formal_tag module \$future_ff (A, Y); parameter WIDTH = 0; @@ -3074,7 +3074,7 @@ assign Y = A; endmodule // -------------------------------------------------------- - +//* group debug (* noblackbox *) module \$scopeinfo (); From 596d914eada3c0402061d8231417cc6e4b60a78b Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Thu, 29 Aug 2024 10:43:25 +1200 Subject: [PATCH 45/68] simcells: Apply group tags --- techlibs/common/gen_fine_ffs.py | 16 ++++ techlibs/common/simcells.v | 148 ++++++++++++++++++++++++++++++++ 2 files changed, 164 insertions(+) diff --git a/techlibs/common/gen_fine_ffs.py b/techlibs/common/gen_fine_ffs.py index 25c6ef171c4..9d4314ffa8d 100644 --- a/techlibs/common/gen_fine_ffs.py +++ b/techlibs/common/gen_fine_ffs.py @@ -3,6 +3,7 @@ // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SR_{S:N|P}{R:N|P}_ (S, R, Q) +//* group reg_latch //- //- A set-reset latch with {S:negative|positive} polarity SET and {R:negative|positive} polarity RESET. //- @@ -28,6 +29,7 @@ // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_FF_ (D, Q) +//* group reg_ff //- //- A D-type flip-flop that is clocked from the implicit global clock. (This cell //- type is usually only used in netlists for formal verification.) @@ -45,6 +47,7 @@ // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFF_{C:N|P}_ (D, C, Q) +//* group reg_ff //- //- A {C:negative|positive} edge D-type flip-flop. //- @@ -65,6 +68,7 @@ // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFE_{C:N|P}{E:N|P}_ (D, C, E, Q) +//* group reg_ff //- //- A {C:negative|positive} edge D-type flip-flop with {E:negative|positive} polarity enable. //- @@ -85,6 +89,7 @@ // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFF_{C:N|P}{R:N|P}{V:0|1}_ (D, C, R, Q) +//* group reg_ff //- //- A {C:negative|positive} edge D-type flip-flop with {R:negative|positive} polarity {V:reset|set}. //- @@ -109,6 +114,7 @@ // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFE_{C:N|P}{R:N|P}{V:0|1}{E:N|P}_ (D, C, R, E, Q) +//* group reg_ff //- //- A {C:negative|positive} edge D-type flip-flop with {R:negative|positive} polarity {V:reset|set} and {E:negative|positive} //- polarity clock enable. @@ -134,6 +140,7 @@ // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_ALDFF_{C:N|P}{L:N|P}_ (D, C, L, AD, Q) +//* group reg_ff //- //- A {C:negative|positive} edge D-type flip-flop with {L:negative|positive} polarity async load. //- @@ -158,6 +165,7 @@ // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_ALDFFE_{C:N|P}{L:N|P}{E:N|P}_ (D, C, L, AD, E, Q) +//* group reg_ff //- //- A {C:negative|positive} edge D-type flip-flop with {L:negative|positive} polarity async load and {E:negative|positive} //- polarity clock enable. @@ -183,6 +191,7 @@ // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSR_{C:N|P}{S:N|P}{R:N|P}_ (C, S, R, D, Q) +//* group reg_ff //- //- A {C:negative|positive} edge D-type flip-flop with {S:negative|positive} polarity set and {R:negative|positive} //- polarity reset. @@ -211,6 +220,7 @@ // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSRE_{C:N|P}{S:N|P}{R:N|P}{E:N|P}_ (C, S, R, E, D, Q) +//* group reg_ff //- //- A {C:negative|positive} edge D-type flip-flop with {S:negative|positive} polarity set, {R:negative|positive} //- polarity reset and {E:negative|positive} polarity clock enable. @@ -239,6 +249,7 @@ // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFF_{C:N|P}{R:N|P}{V:0|1}_ (D, C, R, Q) +//* group reg_ff //- //- A {C:negative|positive} edge D-type flip-flop with {R:negative|positive} polarity synchronous {V:reset|set}. //- @@ -263,6 +274,7 @@ // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFE_{C:N|P}{R:N|P}{V:0|1}{E:N|P}_ (D, C, R, E, Q) +//* group reg_ff //- //- A {C:negative|positive} edge D-type flip-flop with {R:negative|positive} polarity synchronous {V:reset|set} and {E:negative|positive} //- polarity clock enable (with {V:reset|set} having priority). @@ -288,6 +300,7 @@ // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFCE_{C:N|P}{R:N|P}{V:0|1}{E:N|P}_ (D, C, R, E, Q) +//* group reg_ff //- //- A {C:negative|positive} edge D-type flip-flop with {R:negative|positive} polarity synchronous {V:reset|set} and {E:negative|positive} //- polarity clock enable (with clock enable having priority). @@ -315,6 +328,7 @@ // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DLATCH_{E:N|P}_ (E, D, Q) +//* group reg_latch //- //- A {E:negative|positive} enable D-type latch. //- @@ -336,6 +350,7 @@ // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DLATCH_{E:N|P}{R:N|P}{V:0|1}_ (E, R, D, Q) +//* group reg_latch //- //- A {E:negative|positive} enable D-type latch with {R:negative|positive} polarity {V:reset|set}. //- @@ -360,6 +375,7 @@ // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DLATCHSR_{E:N|P}{S:N|P}{R:N|P}_ (E, S, R, D, Q) +//* group reg_latch //- //- A {E:negative|positive} enable D-type latch with {S:negative|positive} polarity set and {R:negative|positive} //- polarity reset. diff --git a/techlibs/common/simcells.v b/techlibs/common/simcells.v index ad1fdc81756..104022079cf 100644 --- a/techlibs/common/simcells.v +++ b/techlibs/common/simcells.v @@ -28,6 +28,7 @@ // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_BUF_ (A, Y) +//* group comb_simple //- //- A buffer. This cell type is always optimized away by the opt_clean pass. //- @@ -45,6 +46,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_NOT_ (A, Y) +//* group comb_simple //- //- An inverter gate. //- @@ -62,6 +64,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_AND_ (A, B, Y) +//* group comb_simple //- //- A 2-input AND gate. //- @@ -81,6 +84,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_NAND_ (A, B, Y) +//* group comb_simple //- //- A 2-input NAND gate. //- @@ -100,6 +104,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_OR_ (A, B, Y) +//* group comb_simple //- //- A 2-input OR gate. //- @@ -119,6 +124,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_NOR_ (A, B, Y) +//* group comb_simple //- //- A 2-input NOR gate. //- @@ -138,6 +144,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_XOR_ (A, B, Y) +//* group comb_simple //- //- A 2-input XOR gate. //- @@ -157,6 +164,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_XNOR_ (A, B, Y) +//* group comb_simple //- //- A 2-input XNOR gate. //- @@ -176,6 +184,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_ANDNOT_ (A, B, Y) +//* group comb_combined //- //- A 2-input AND-NOT gate. //- @@ -195,6 +204,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_ORNOT_ (A, B, Y) +//* group comb_combined //- //- A 2-input OR-NOT gate. //- @@ -214,6 +224,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_MUX_ (A, B, S, Y) +//* group comb_simple //- //- A 2-input MUX gate. //- @@ -233,6 +244,7 @@ endmodule //- $_NMUX_ (A, B, S, Y) //- //- A 2-input inverting MUX gate. +//* group comb_combined //- //- Truth table: A B S | Y //- -------+--- @@ -250,6 +262,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_MUX4_ (A, B, C, D, S, T, Y) +//* group comb_combined //- //- A 4-input MUX gate. //- @@ -270,6 +283,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_MUX8_ (A, B, C, D, E, F, G, H, S, T, U, Y) +//* group comb_combined //- //- An 8-input MUX gate. //- @@ -296,6 +310,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_MUX16_ (A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, S, T, U, V, Y) +//* group comb_combined //- //- A 16-input MUX gate. //- @@ -334,6 +349,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_AOI3_ (A, B, C, Y) +//* group comb_combined //- //- A 3-input And-Or-Invert gate. //- @@ -357,6 +373,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_OAI3_ (A, B, C, Y) +//* group comb_combined //- //- A 3-input Or-And-Invert gate. //- @@ -380,6 +397,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_AOI4_ (A, B, C, Y) +//* group comb_combined //- //- A 4-input And-Or-Invert gate. //- @@ -411,6 +429,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_OAI4_ (A, B, C, Y) +//* group comb_combined //- //- A 4-input Or-And-Invert gate. //- @@ -464,6 +483,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SR_NN_ (S, R, Q) +//* group reg_latch //- //- A set-reset latch with negative polarity SET and negative polarity RESET. //- @@ -487,6 +507,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SR_NP_ (S, R, Q) +//* group reg_latch //- //- A set-reset latch with negative polarity SET and positive polarity RESET. //- @@ -510,6 +531,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SR_PN_ (S, R, Q) +//* group reg_latch //- //- A set-reset latch with positive polarity SET and negative polarity RESET. //- @@ -533,6 +555,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SR_PP_ (S, R, Q) +//* group reg_latch //- //- A set-reset latch with positive polarity SET and positive polarity RESET. //- @@ -557,6 +580,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_FF_ (D, Q) +//* group reg_ff //- //- A D-type flip-flop that is clocked from the implicit global clock. (This cell //- type is usually only used in netlists for formal verification.) @@ -573,6 +597,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFF_N_ (D, C, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop. //- @@ -592,6 +617,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFF_P_ (D, C, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop. //- @@ -611,6 +637,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFE_NN_ (D, C, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity enable. //- @@ -630,6 +657,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFE_NP_ (D, C, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity enable. //- @@ -649,6 +677,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFE_PN_ (D, C, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity enable. //- @@ -668,6 +697,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFE_PP_ (D, C, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity enable. //- @@ -687,6 +717,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFF_NN0_ (D, C, R, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity reset. //- @@ -710,6 +741,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFF_NN1_ (D, C, R, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity set. //- @@ -733,6 +765,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFF_NP0_ (D, C, R, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity reset. //- @@ -756,6 +789,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFF_NP1_ (D, C, R, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity set. //- @@ -779,6 +813,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFF_PN0_ (D, C, R, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity reset. //- @@ -802,6 +837,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFF_PN1_ (D, C, R, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity set. //- @@ -825,6 +861,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFF_PP0_ (D, C, R, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity reset. //- @@ -848,6 +885,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFF_PP1_ (D, C, R, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity set. //- @@ -871,6 +909,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFE_NN0N_ (D, C, R, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity reset and negative //- polarity clock enable. @@ -895,6 +934,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFE_NN0P_ (D, C, R, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity reset and positive //- polarity clock enable. @@ -919,6 +959,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFE_NN1N_ (D, C, R, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity set and negative //- polarity clock enable. @@ -943,6 +984,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFE_NN1P_ (D, C, R, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity set and positive //- polarity clock enable. @@ -967,6 +1009,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFE_NP0N_ (D, C, R, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity reset and negative //- polarity clock enable. @@ -991,6 +1034,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFE_NP0P_ (D, C, R, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity reset and positive //- polarity clock enable. @@ -1015,6 +1059,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFE_NP1N_ (D, C, R, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity set and negative //- polarity clock enable. @@ -1039,6 +1084,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFE_NP1P_ (D, C, R, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity set and positive //- polarity clock enable. @@ -1063,6 +1109,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFE_PN0N_ (D, C, R, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity reset and negative //- polarity clock enable. @@ -1087,6 +1134,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFE_PN0P_ (D, C, R, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity reset and positive //- polarity clock enable. @@ -1111,6 +1159,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFE_PN1N_ (D, C, R, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity set and negative //- polarity clock enable. @@ -1135,6 +1184,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFE_PN1P_ (D, C, R, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity set and positive //- polarity clock enable. @@ -1159,6 +1209,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFE_PP0N_ (D, C, R, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity reset and negative //- polarity clock enable. @@ -1183,6 +1234,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFE_PP0P_ (D, C, R, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity reset and positive //- polarity clock enable. @@ -1207,6 +1259,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFE_PP1N_ (D, C, R, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity set and negative //- polarity clock enable. @@ -1231,6 +1284,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFE_PP1P_ (D, C, R, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity set and positive //- polarity clock enable. @@ -1255,6 +1309,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_ALDFF_NN_ (D, C, L, AD, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity async load. //- @@ -1278,6 +1333,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_ALDFF_NP_ (D, C, L, AD, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity async load. //- @@ -1301,6 +1357,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_ALDFF_PN_ (D, C, L, AD, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity async load. //- @@ -1324,6 +1381,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_ALDFF_PP_ (D, C, L, AD, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity async load. //- @@ -1347,6 +1405,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_ALDFFE_NNN_ (D, C, L, AD, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity async load and negative //- polarity clock enable. @@ -1371,6 +1430,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_ALDFFE_NNP_ (D, C, L, AD, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity async load and positive //- polarity clock enable. @@ -1395,6 +1455,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_ALDFFE_NPN_ (D, C, L, AD, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity async load and negative //- polarity clock enable. @@ -1419,6 +1480,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_ALDFFE_NPP_ (D, C, L, AD, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity async load and positive //- polarity clock enable. @@ -1443,6 +1505,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_ALDFFE_PNN_ (D, C, L, AD, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity async load and negative //- polarity clock enable. @@ -1467,6 +1530,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_ALDFFE_PNP_ (D, C, L, AD, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity async load and positive //- polarity clock enable. @@ -1491,6 +1555,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_ALDFFE_PPN_ (D, C, L, AD, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity async load and negative //- polarity clock enable. @@ -1515,6 +1580,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_ALDFFE_PPP_ (D, C, L, AD, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity async load and positive //- polarity clock enable. @@ -1539,6 +1605,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSR_NNN_ (C, S, R, D, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity set and negative //- polarity reset. @@ -1566,6 +1633,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSR_NNP_ (C, S, R, D, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity set and positive //- polarity reset. @@ -1593,6 +1661,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSR_NPN_ (C, S, R, D, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity set and negative //- polarity reset. @@ -1620,6 +1689,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSR_NPP_ (C, S, R, D, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity set and positive //- polarity reset. @@ -1647,6 +1717,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSR_PNN_ (C, S, R, D, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity set and negative //- polarity reset. @@ -1674,6 +1745,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSR_PNP_ (C, S, R, D, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity set and positive //- polarity reset. @@ -1701,6 +1773,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSR_PPN_ (C, S, R, D, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity set and negative //- polarity reset. @@ -1728,6 +1801,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSR_PPP_ (C, S, R, D, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity set and positive //- polarity reset. @@ -1755,6 +1829,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSRE_NNNN_ (C, S, R, E, D, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity set, negative //- polarity reset and negative polarity clock enable. @@ -1782,6 +1857,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSRE_NNNP_ (C, S, R, E, D, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity set, negative //- polarity reset and positive polarity clock enable. @@ -1809,6 +1885,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSRE_NNPN_ (C, S, R, E, D, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity set, positive //- polarity reset and negative polarity clock enable. @@ -1836,6 +1913,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSRE_NNPP_ (C, S, R, E, D, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity set, positive //- polarity reset and positive polarity clock enable. @@ -1863,6 +1941,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSRE_NPNN_ (C, S, R, E, D, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity set, negative //- polarity reset and negative polarity clock enable. @@ -1890,6 +1969,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSRE_NPNP_ (C, S, R, E, D, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity set, negative //- polarity reset and positive polarity clock enable. @@ -1917,6 +1997,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSRE_NPPN_ (C, S, R, E, D, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity set, positive //- polarity reset and negative polarity clock enable. @@ -1944,6 +2025,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSRE_NPPP_ (C, S, R, E, D, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity set, positive //- polarity reset and positive polarity clock enable. @@ -1971,6 +2053,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSRE_PNNN_ (C, S, R, E, D, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity set, negative //- polarity reset and negative polarity clock enable. @@ -1998,6 +2081,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSRE_PNNP_ (C, S, R, E, D, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity set, negative //- polarity reset and positive polarity clock enable. @@ -2025,6 +2109,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSRE_PNPN_ (C, S, R, E, D, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity set, positive //- polarity reset and negative polarity clock enable. @@ -2052,6 +2137,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSRE_PNPP_ (C, S, R, E, D, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity set, positive //- polarity reset and positive polarity clock enable. @@ -2079,6 +2165,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSRE_PPNN_ (C, S, R, E, D, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity set, negative //- polarity reset and negative polarity clock enable. @@ -2106,6 +2193,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSRE_PPNP_ (C, S, R, E, D, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity set, negative //- polarity reset and positive polarity clock enable. @@ -2133,6 +2221,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSRE_PPPN_ (C, S, R, E, D, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity set, positive //- polarity reset and negative polarity clock enable. @@ -2160,6 +2249,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DFFSRE_PPPP_ (C, S, R, E, D, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity set, positive //- polarity reset and positive polarity clock enable. @@ -2187,6 +2277,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFF_NN0_ (D, C, R, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity synchronous reset. //- @@ -2210,6 +2301,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFF_NN1_ (D, C, R, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity synchronous set. //- @@ -2233,6 +2325,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFF_NP0_ (D, C, R, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity synchronous reset. //- @@ -2256,6 +2349,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFF_NP1_ (D, C, R, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity synchronous set. //- @@ -2279,6 +2373,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFF_PN0_ (D, C, R, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity synchronous reset. //- @@ -2302,6 +2397,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFF_PN1_ (D, C, R, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity synchronous set. //- @@ -2325,6 +2421,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFF_PP0_ (D, C, R, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity synchronous reset. //- @@ -2348,6 +2445,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFF_PP1_ (D, C, R, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity synchronous set. //- @@ -2371,6 +2469,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFE_NN0N_ (D, C, R, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity synchronous reset and negative //- polarity clock enable (with reset having priority). @@ -2395,6 +2494,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFE_NN0P_ (D, C, R, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity synchronous reset and positive //- polarity clock enable (with reset having priority). @@ -2419,6 +2519,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFE_NN1N_ (D, C, R, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity synchronous set and negative //- polarity clock enable (with set having priority). @@ -2443,6 +2544,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFE_NN1P_ (D, C, R, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity synchronous set and positive //- polarity clock enable (with set having priority). @@ -2467,6 +2569,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFE_NP0N_ (D, C, R, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity synchronous reset and negative //- polarity clock enable (with reset having priority). @@ -2491,6 +2594,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFE_NP0P_ (D, C, R, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity synchronous reset and positive //- polarity clock enable (with reset having priority). @@ -2515,6 +2619,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFE_NP1N_ (D, C, R, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity synchronous set and negative //- polarity clock enable (with set having priority). @@ -2539,6 +2644,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFE_NP1P_ (D, C, R, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity synchronous set and positive //- polarity clock enable (with set having priority). @@ -2563,6 +2669,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFE_PN0N_ (D, C, R, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity synchronous reset and negative //- polarity clock enable (with reset having priority). @@ -2587,6 +2694,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFE_PN0P_ (D, C, R, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity synchronous reset and positive //- polarity clock enable (with reset having priority). @@ -2611,6 +2719,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFE_PN1N_ (D, C, R, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity synchronous set and negative //- polarity clock enable (with set having priority). @@ -2635,6 +2744,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFE_PN1P_ (D, C, R, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity synchronous set and positive //- polarity clock enable (with set having priority). @@ -2659,6 +2769,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFE_PP0N_ (D, C, R, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity synchronous reset and negative //- polarity clock enable (with reset having priority). @@ -2683,6 +2794,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFE_PP0P_ (D, C, R, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity synchronous reset and positive //- polarity clock enable (with reset having priority). @@ -2707,6 +2819,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFE_PP1N_ (D, C, R, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity synchronous set and negative //- polarity clock enable (with set having priority). @@ -2731,6 +2844,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFE_PP1P_ (D, C, R, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity synchronous set and positive //- polarity clock enable (with set having priority). @@ -2755,6 +2869,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFCE_NN0N_ (D, C, R, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity synchronous reset and negative //- polarity clock enable (with clock enable having priority). @@ -2781,6 +2896,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFCE_NN0P_ (D, C, R, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity synchronous reset and positive //- polarity clock enable (with clock enable having priority). @@ -2807,6 +2923,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFCE_NN1N_ (D, C, R, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity synchronous set and negative //- polarity clock enable (with clock enable having priority). @@ -2833,6 +2950,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFCE_NN1P_ (D, C, R, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with negative polarity synchronous set and positive //- polarity clock enable (with clock enable having priority). @@ -2859,6 +2977,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFCE_NP0N_ (D, C, R, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity synchronous reset and negative //- polarity clock enable (with clock enable having priority). @@ -2885,6 +3004,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFCE_NP0P_ (D, C, R, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity synchronous reset and positive //- polarity clock enable (with clock enable having priority). @@ -2911,6 +3031,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFCE_NP1N_ (D, C, R, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity synchronous set and negative //- polarity clock enable (with clock enable having priority). @@ -2937,6 +3058,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFCE_NP1P_ (D, C, R, E, Q) +//* group reg_ff //- //- A negative edge D-type flip-flop with positive polarity synchronous set and positive //- polarity clock enable (with clock enable having priority). @@ -2963,6 +3085,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFCE_PN0N_ (D, C, R, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity synchronous reset and negative //- polarity clock enable (with clock enable having priority). @@ -2989,6 +3112,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFCE_PN0P_ (D, C, R, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity synchronous reset and positive //- polarity clock enable (with clock enable having priority). @@ -3015,6 +3139,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFCE_PN1N_ (D, C, R, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity synchronous set and negative //- polarity clock enable (with clock enable having priority). @@ -3041,6 +3166,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFCE_PN1P_ (D, C, R, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with negative polarity synchronous set and positive //- polarity clock enable (with clock enable having priority). @@ -3067,6 +3193,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFCE_PP0N_ (D, C, R, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity synchronous reset and negative //- polarity clock enable (with clock enable having priority). @@ -3093,6 +3220,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFCE_PP0P_ (D, C, R, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity synchronous reset and positive //- polarity clock enable (with clock enable having priority). @@ -3119,6 +3247,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFCE_PP1N_ (D, C, R, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity synchronous set and negative //- polarity clock enable (with clock enable having priority). @@ -3145,6 +3274,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_SDFFCE_PP1P_ (D, C, R, E, Q) +//* group reg_ff //- //- A positive edge D-type flip-flop with positive polarity synchronous set and positive //- polarity clock enable (with clock enable having priority). @@ -3171,6 +3301,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DLATCH_N_ (E, D, Q) +//* group reg_latch //- //- A negative enable D-type latch. //- @@ -3191,6 +3322,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DLATCH_P_ (E, D, Q) +//* group reg_latch //- //- A positive enable D-type latch. //- @@ -3211,6 +3343,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DLATCH_NN0_ (E, R, D, Q) +//* group reg_latch //- //- A negative enable D-type latch with negative polarity reset. //- @@ -3234,6 +3367,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DLATCH_NN1_ (E, R, D, Q) +//* group reg_latch //- //- A negative enable D-type latch with negative polarity set. //- @@ -3257,6 +3391,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DLATCH_NP0_ (E, R, D, Q) +//* group reg_latch //- //- A negative enable D-type latch with positive polarity reset. //- @@ -3280,6 +3415,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DLATCH_NP1_ (E, R, D, Q) +//* group reg_latch //- //- A negative enable D-type latch with positive polarity set. //- @@ -3303,6 +3439,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DLATCH_PN0_ (E, R, D, Q) +//* group reg_latch //- //- A positive enable D-type latch with negative polarity reset. //- @@ -3326,6 +3463,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DLATCH_PN1_ (E, R, D, Q) +//* group reg_latch //- //- A positive enable D-type latch with negative polarity set. //- @@ -3349,6 +3487,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DLATCH_PP0_ (E, R, D, Q) +//* group reg_latch //- //- A positive enable D-type latch with positive polarity reset. //- @@ -3372,6 +3511,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DLATCH_PP1_ (E, R, D, Q) +//* group reg_latch //- //- A positive enable D-type latch with positive polarity set. //- @@ -3395,6 +3535,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DLATCHSR_NNN_ (E, S, R, D, Q) +//* group reg_latch //- //- A negative enable D-type latch with negative polarity set and negative //- polarity reset. @@ -3422,6 +3563,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DLATCHSR_NNP_ (E, S, R, D, Q) +//* group reg_latch //- //- A negative enable D-type latch with negative polarity set and positive //- polarity reset. @@ -3449,6 +3591,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DLATCHSR_NPN_ (E, S, R, D, Q) +//* group reg_latch //- //- A negative enable D-type latch with positive polarity set and negative //- polarity reset. @@ -3476,6 +3619,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DLATCHSR_NPP_ (E, S, R, D, Q) +//* group reg_latch //- //- A negative enable D-type latch with positive polarity set and positive //- polarity reset. @@ -3503,6 +3647,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DLATCHSR_PNN_ (E, S, R, D, Q) +//* group reg_latch //- //- A positive enable D-type latch with negative polarity set and negative //- polarity reset. @@ -3530,6 +3675,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DLATCHSR_PNP_ (E, S, R, D, Q) +//* group reg_latch //- //- A positive enable D-type latch with negative polarity set and positive //- polarity reset. @@ -3557,6 +3703,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DLATCHSR_PPN_ (E, S, R, D, Q) +//* group reg_latch //- //- A positive enable D-type latch with positive polarity set and negative //- polarity reset. @@ -3584,6 +3731,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_DLATCHSR_PPP_ (E, S, R, D, Q) +//* group reg_latch //- //- A positive enable D-type latch with positive polarity set and positive //- polarity reset. From b0bc29e215157f910a5fe5aa8d8ed3ab2b9ee46b Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Thu, 29 Aug 2024 10:43:46 +1200 Subject: [PATCH 46/68] Docs: Add todo for $check --- docs/source/cell/word_formal.rst | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/source/cell/word_formal.rst b/docs/source/cell/word_formal.rst index ae0f56025cf..8c52422a833 100644 --- a/docs/source/cell/word_formal.rst +++ b/docs/source/cell/word_formal.rst @@ -1,6 +1,10 @@ Formal verification cells ------------------------- +.. TODO:: note on `$check` + + If only I remembered what the note was... + .. TODO:: Describe formal cells `$check`, `$assert`, `$assume`, `$live`, `$fair`, `$cover`, `$equiv`, From 5473b60aeccf4aa43464c66e1cbf127351a324a1 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Thu, 29 Aug 2024 10:44:07 +1200 Subject: [PATCH 47/68] Docs: Split gate-level cells into subpages --- docs/source/cell/gate_comb_combined.rst | 53 ++++ docs/source/cell/gate_comb_simple.rst | 26 ++ docs/source/cell/gate_other.rst | 5 - docs/source/cell/gate_reg_ff.rst | 231 ++++++++++++++ docs/source/cell/gate_reg_latch.rst | 105 +++++++ docs/source/cell_gate.rst | 393 +----------------------- 6 files changed, 431 insertions(+), 382 deletions(-) create mode 100644 docs/source/cell/gate_comb_combined.rst create mode 100644 docs/source/cell/gate_comb_simple.rst delete mode 100644 docs/source/cell/gate_other.rst create mode 100644 docs/source/cell/gate_reg_ff.rst create mode 100644 docs/source/cell/gate_reg_latch.rst diff --git a/docs/source/cell/gate_comb_combined.rst b/docs/source/cell/gate_comb_combined.rst new file mode 100644 index 00000000000..1a1f548cc89 --- /dev/null +++ b/docs/source/cell/gate_comb_combined.rst @@ -0,0 +1,53 @@ +.. role:: verilog(code) + :language: Verilog + +Combinatorial cells (combined) +------------------------------ + +These cells combine two or more combinatorial cells (simple) into a single cell. + +.. table:: Cell types for gate level combinatorial cells (combined) + + ======================================= ============= + Verilog Cell Type + ======================================= ============= + :verilog:`Y = A & ~B` `$_ANDNOT_` + :verilog:`Y = A | ~B` `$_ORNOT_` + :verilog:`Y = ~((A & B) | C)` `$_AOI3_` + :verilog:`Y = ~((A | B) & C)` `$_OAI3_` + :verilog:`Y = ~((A & B) | (C & D))` `$_AOI4_` + :verilog:`Y = ~((A | B) & (C | D))` `$_OAI4_` + :verilog:`Y = ~(S ? B : A)` `$_NMUX_` + (see below) `$_MUX4_` + (see below) `$_MUX8_` + (see below) `$_MUX16_` + ======================================= ============= + +The `$_MUX4_`, `$_MUX8_` and `$_MUX16_` cells are used to model wide muxes, and +correspond to the following Verilog code: + +.. code-block:: verilog + :force: + + // $_MUX4_ + assign Y = T ? (S ? D : C) : + (S ? B : A); + // $_MUX8_ + assign Y = U ? T ? (S ? H : G) : + (S ? F : E) : + T ? (S ? D : C) : + (S ? B : A); + // $_MUX16_ + assign Y = V ? U ? T ? (S ? P : O) : + (S ? N : M) : + T ? (S ? L : K) : + (S ? J : I) : + U ? T ? (S ? H : G) : + (S ? F : E) : + T ? (S ? D : C) : + (S ? B : A); + +.. autocellgroup:: comb_combined + :members: + :source: + :linenos: diff --git a/docs/source/cell/gate_comb_simple.rst b/docs/source/cell/gate_comb_simple.rst new file mode 100644 index 00000000000..f45e64496d0 --- /dev/null +++ b/docs/source/cell/gate_comb_simple.rst @@ -0,0 +1,26 @@ +.. role:: verilog(code) + :language: Verilog + +Combinatorial cells (simple) +---------------------------- + +.. table:: Cell types for gate level combinatorial cells (simple) + + ======================================= ============= + Verilog Cell Type + ======================================= ============= + :verilog:`Y = A` `$_BUF_` + :verilog:`Y = ~A` `$_NOT_` + :verilog:`Y = A & B` `$_AND_` + :verilog:`Y = ~(A & B)` `$_NAND_` + :verilog:`Y = A | B` `$_OR_` + :verilog:`Y = ~(A | B)` `$_NOR_` + :verilog:`Y = A ^ B` `$_XOR_` + :verilog:`Y = ~(A ^ B)` `$_XNOR_` + :verilog:`Y = S ? B : A` `$_MUX_` + ======================================= ============= + +.. autocellgroup:: comb_simple + :members: + :source: + :linenos: diff --git a/docs/source/cell/gate_other.rst b/docs/source/cell/gate_other.rst deleted file mode 100644 index 7696ba824e9..00000000000 --- a/docs/source/cell/gate_other.rst +++ /dev/null @@ -1,5 +0,0 @@ -.. autocellgroup:: gate_other - :caption: Other gate-level cells - :members: - :source: - :linenos: diff --git a/docs/source/cell/gate_reg_ff.rst b/docs/source/cell/gate_reg_ff.rst new file mode 100644 index 00000000000..2a31a3f090f --- /dev/null +++ b/docs/source/cell/gate_reg_ff.rst @@ -0,0 +1,231 @@ +.. role:: verilog(code) + :language: Verilog + +Flip-flop cells +--------------- + +The cell types `$_DFF_N_` and `$_DFF_P_` represent d-type flip-flops. + +.. table:: Cell types for basic flip-flops + + ======================================= ============= + Verilog Cell Type + ======================================= ============= + :verilog:`always @(negedge C) Q <= D` `$_DFF_N_` + :verilog:`always @(posedge C) Q <= D` `$_DFF_P_` + ======================================= ============= + +The cell types ``$_DFFE_[NP][NP]_`` implement d-type flip-flops with enable. The +values in the table for these cell types relate to the following Verilog code +template. + +.. code-block:: verilog + :force: + + always @(CLK_EDGE C) + if (EN == EN_LVL) + Q <= D; + + +.. table:: Cell types for gate level logic networks (FFs with enable) + :name: tab:CellLib_gates_dffe + + ================== ============= ============ + :math:`ClkEdge` :math:`EnLvl` Cell Type + ================== ============= ============ + :verilog:`negedge` ``0`` `$_DFFE_NN_` + :verilog:`negedge` ``1`` `$_DFFE_NP_` + :verilog:`posedge` ``0`` `$_DFFE_PN_` + :verilog:`posedge` ``1`` `$_DFFE_PP_` + ================== ============= ============ + +The cell types ``$_DFF_[NP][NP][01]_`` implement d-type flip-flops with +asynchronous reset. The values in the table for these cell types relate to the +following Verilog code template, where ``RST_EDGE`` is ``posedge`` if +``RST_LVL`` if ``1``, and ``negedge`` otherwise. + +.. code-block:: verilog + :force: + + always @(CLK_EDGE C, RST_EDGE R) + if (R == RST_LVL) + Q <= RST_VAL; + else + Q <= D; + +The cell types ``$_SDFF_[NP][NP][01]_`` implement d-type flip-flops with +synchronous reset. The values in the table for these cell types relate to the +following Verilog code template: + +.. code-block:: verilog + :force: + + always @(CLK_EDGE C) + if (R == RST_LVL) + Q <= RST_VAL; + else + Q <= D; + +.. table:: Cell types for gate level logic networks (FFs with reset) + :name: tab:CellLib_gates_adff + + ================== ============== ============== =========================== + :math:`ClkEdge` :math:`RstLvl` :math:`RstVal` Cell Type + ================== ============== ============== =========================== + :verilog:`negedge` ``0`` ``0`` `$_DFF_NN0_`, `$_SDFF_NN0_` + :verilog:`negedge` ``0`` ``1`` `$_DFF_NN1_`, `$_SDFF_NN1_` + :verilog:`negedge` ``1`` ``0`` `$_DFF_NP0_`, `$_SDFF_NP0_` + :verilog:`negedge` ``1`` ``1`` `$_DFF_NP1_`, `$_SDFF_NP1_` + :verilog:`posedge` ``0`` ``0`` `$_DFF_PN0_`, `$_SDFF_PN0_` + :verilog:`posedge` ``0`` ``1`` `$_DFF_PN1_`, `$_SDFF_PN1_` + :verilog:`posedge` ``1`` ``0`` `$_DFF_PP0_`, `$_SDFF_PP0_` + :verilog:`posedge` ``1`` ``1`` `$_DFF_PP1_`, `$_SDFF_PP1_` + ================== ============== ============== =========================== + +The cell types ``$_DFFE_[NP][NP][01][NP]_`` implement d-type flip-flops with +asynchronous reset and enable. The values in the table for these cell types +relate to the following Verilog code template, where ``RST_EDGE`` is ``posedge`` +if ``RST_LVL`` if ``1``, and ``negedge`` otherwise. + +.. code-block:: verilog + :force: + + always @(CLK_EDGE C, RST_EDGE R) + if (R == RST_LVL) + Q <= RST_VAL; + else if (EN == EN_LVL) + Q <= D; + +The cell types ``$_SDFFE_[NP][NP][01][NP]_`` implement d-type flip-flops with +synchronous reset and enable, with reset having priority over enable. The values +in the table for these cell types relate to the following Verilog code template: + +.. code-block:: verilog + :force: + + always @(CLK_EDGE C) + if (R == RST_LVL) + Q <= RST_VAL; + else if (EN == EN_LVL) + Q <= D; + +The cell types ``$_SDFFCE_[NP][NP][01][NP]_`` implement d-type flip-flops with +synchronous reset and enable, with enable having priority over reset. The values +in the table for these cell types relate to the following Verilog code template: + +.. code-block:: verilog + :force: + + always @(CLK_EDGE C) + if (EN == EN_LVL) + if (R == RST_LVL) + Q <= RST_VAL; + else + Q <= D; + + +.. table:: Cell types for gate level logic networks (FFs with reset and enable) + :name: tab:CellLib_gates_adffe + + ================== ============== ============== ============= ================================================= + :math:`ClkEdge` :math:`RstLvl` :math:`RstVal` :math:`EnLvl` Cell Type + ================== ============== ============== ============= ================================================= + :verilog:`negedge` ``0`` ``0`` ``0`` `$_DFFE_NN0N_`, `$_SDFFE_NN0N_`, `$_SDFFCE_NN0N_` + :verilog:`negedge` ``0`` ``0`` ``1`` `$_DFFE_NN0P_`, `$_SDFFE_NN0P_`, `$_SDFFCE_NN0P_` + :verilog:`negedge` ``0`` ``1`` ``0`` `$_DFFE_NN1N_`, `$_SDFFE_NN1N_`, `$_SDFFCE_NN1N_` + :verilog:`negedge` ``0`` ``1`` ``1`` `$_DFFE_NN1P_`, `$_SDFFE_NN1P_`, `$_SDFFCE_NN1P_` + :verilog:`negedge` ``1`` ``0`` ``0`` `$_DFFE_NP0N_`, `$_SDFFE_NP0N_`, `$_SDFFCE_NP0N_` + :verilog:`negedge` ``1`` ``0`` ``1`` `$_DFFE_NP0P_`, `$_SDFFE_NP0P_`, `$_SDFFCE_NP0P_` + :verilog:`negedge` ``1`` ``1`` ``0`` `$_DFFE_NP1N_`, `$_SDFFE_NP1N_`, `$_SDFFCE_NP1N_` + :verilog:`negedge` ``1`` ``1`` ``1`` `$_DFFE_NP1P_`, `$_SDFFE_NP1P_`, `$_SDFFCE_NP1P_` + :verilog:`posedge` ``0`` ``0`` ``0`` `$_DFFE_PN0N_`, `$_SDFFE_PN0N_`, `$_SDFFCE_PN0N_` + :verilog:`posedge` ``0`` ``0`` ``1`` `$_DFFE_PN0P_`, `$_SDFFE_PN0P_`, `$_SDFFCE_PN0P_` + :verilog:`posedge` ``0`` ``1`` ``0`` `$_DFFE_PN1N_`, `$_SDFFE_PN1N_`, `$_SDFFCE_PN1N_` + :verilog:`posedge` ``0`` ``1`` ``1`` `$_DFFE_PN1P_`, `$_SDFFE_PN1P_`, `$_SDFFCE_PN1P_` + :verilog:`posedge` ``1`` ``0`` ``0`` `$_DFFE_PP0N_`, `$_SDFFE_PP0N_`, `$_SDFFCE_PP0N_` + :verilog:`posedge` ``1`` ``0`` ``1`` `$_DFFE_PP0P_`, `$_SDFFE_PP0P_`, `$_SDFFCE_PP0P_` + :verilog:`posedge` ``1`` ``1`` ``0`` `$_DFFE_PP1N_`, `$_SDFFE_PP1N_`, `$_SDFFCE_PP1N_` + :verilog:`posedge` ``1`` ``1`` ``1`` `$_DFFE_PP1P_`, `$_SDFFE_PP1P_`, `$_SDFFCE_PP1P_` + ================== ============== ============== ============= ================================================= + +The cell types ``$_DFFSR_[NP][NP][NP]_`` implement d-type flip-flops with +asynchronous set and reset. The values in the table for these cell types relate +to the following Verilog code template, where ``RST_EDGE`` is ``posedge`` if +``RST_LVL`` if ``1``, ``negedge`` otherwise, and ``SET_EDGE`` is ``posedge`` if +``SET_LVL`` if ``1``, ``negedge`` otherwise. + +.. code-block:: verilog + :force: + + always @(CLK_EDGE C, RST_EDGE R, SET_EDGE S) + if (R == RST_LVL) + Q <= 0; + else if (S == SET_LVL) + Q <= 1; + else + Q <= D; + +.. table:: Cell types for gate level logic networks (FFs with set and reset) + :name: tab:CellLib_gates_dffsr + + ================== ============== ============== ============== + :math:`ClkEdge` :math:`SetLvl` :math:`RstLvl` Cell Type + ================== ============== ============== ============== + :verilog:`negedge` ``0`` ``0`` `$_DFFSR_NNN_` + :verilog:`negedge` ``0`` ``1`` `$_DFFSR_NNP_` + :verilog:`negedge` ``1`` ``0`` `$_DFFSR_NPN_` + :verilog:`negedge` ``1`` ``1`` `$_DFFSR_NPP_` + :verilog:`posedge` ``0`` ``0`` `$_DFFSR_PNN_` + :verilog:`posedge` ``0`` ``1`` `$_DFFSR_PNP_` + :verilog:`posedge` ``1`` ``0`` `$_DFFSR_PPN_` + :verilog:`posedge` ``1`` ``1`` `$_DFFSR_PPP_` + ================== ============== ============== ============== + +The cell types ``$_DFFSRE_[NP][NP][NP][NP]_`` implement d-type flip-flops with +asynchronous set and reset and enable. The values in the table for these cell +types relate to the following Verilog code template, where ``RST_EDGE`` is +``posedge`` if ``RST_LVL`` if ``1``, ``negedge`` otherwise, and ``SET_EDGE`` is +``posedge`` if ``SET_LVL`` if ``1``, ``negedge`` otherwise. + +.. code-block:: verilog + :force: + + always @(CLK_EDGE C, RST_EDGE R, SET_EDGE S) + if (R == RST_LVL) + Q <= 0; + else if (S == SET_LVL) + Q <= 1; + else if (E == EN_LVL) + Q <= D; + + +.. table:: Cell types for gate level logic networks (FFs with set and reset and enable) + :name: tab:CellLib_gates_dffsre + + ================== ============== ============== ============= ================ + :math:`ClkEdge` :math:`SetLvl` :math:`RstLvl` :math:`EnLvl` Cell Type + ================== ============== ============== ============= ================ + :verilog:`negedge` ``0`` ``0`` ``0`` `$_DFFSRE_NNNN_` + :verilog:`negedge` ``0`` ``0`` ``1`` `$_DFFSRE_NNNP_` + :verilog:`negedge` ``0`` ``1`` ``0`` `$_DFFSRE_NNPN_` + :verilog:`negedge` ``0`` ``1`` ``1`` `$_DFFSRE_NNPP_` + :verilog:`negedge` ``1`` ``0`` ``0`` `$_DFFSRE_NPNN_` + :verilog:`negedge` ``1`` ``0`` ``1`` `$_DFFSRE_NPNP_` + :verilog:`negedge` ``1`` ``1`` ``0`` `$_DFFSRE_NPPN_` + :verilog:`negedge` ``1`` ``1`` ``1`` `$_DFFSRE_NPPP_` + :verilog:`posedge` ``0`` ``0`` ``0`` `$_DFFSRE_PNNN_` + :verilog:`posedge` ``0`` ``0`` ``1`` `$_DFFSRE_PNNP_` + :verilog:`posedge` ``0`` ``1`` ``0`` `$_DFFSRE_PNPN_` + :verilog:`posedge` ``0`` ``1`` ``1`` `$_DFFSRE_PNPP_` + :verilog:`posedge` ``1`` ``0`` ``0`` `$_DFFSRE_PPNN_` + :verilog:`posedge` ``1`` ``0`` ``1`` `$_DFFSRE_PPNP_` + :verilog:`posedge` ``1`` ``1`` ``0`` `$_DFFSRE_PPPN_` + :verilog:`posedge` ``1`` ``1`` ``1`` `$_DFFSRE_PPPP_` + ================== ============== ============== ============= ================ + +.. todo:: flip-flops with async load, ``$_ALDFFE?_[NP]{2,3}_`` + +.. autocellgroup:: reg_ff + :members: + :source: + :linenos: diff --git a/docs/source/cell/gate_reg_latch.rst b/docs/source/cell/gate_reg_latch.rst new file mode 100644 index 00000000000..bb01bc74c71 --- /dev/null +++ b/docs/source/cell/gate_reg_latch.rst @@ -0,0 +1,105 @@ +.. role:: verilog(code) + :language: Verilog + +Latch cells +----------- + +The cell types `$_DLATCH_N_` and `$_DLATCH_P_` represent d-type latches. + +.. table:: Cell types for basic latches + + ======================================= ============= + Verilog Cell Type + ======================================= ============= + :verilog:`always @* if (!E) Q <= D` `$_DLATCH_N_` + :verilog:`always @* if (E) Q <= D` `$_DLATCH_P_` + ======================================= ============= + +The cell types ``$_DLATCH_[NP][NP][01]_`` implement d-type latches with reset. +The values in the table for these cell types relate to the following Verilog +code template: + +.. code-block:: verilog + :force: + + always @* + if (R == RST_LVL) + Q <= RST_VAL; + else if (E == EN_LVL) + Q <= D; + +.. table:: Cell types for gate level logic networks (latches with reset) + :name: tab:CellLib_gates_adlatch + + ============= ============== ============== =============== + :math:`EnLvl` :math:`RstLvl` :math:`RstVal` Cell Type + ============= ============== ============== =============== + ``0`` ``0`` ``0`` `$_DLATCH_NN0_` + ``0`` ``0`` ``1`` `$_DLATCH_NN1_` + ``0`` ``1`` ``0`` `$_DLATCH_NP0_` + ``0`` ``1`` ``1`` `$_DLATCH_NP1_` + ``1`` ``0`` ``0`` `$_DLATCH_PN0_` + ``1`` ``0`` ``1`` `$_DLATCH_PN1_` + ``1`` ``1`` ``0`` `$_DLATCH_PP0_` + ``1`` ``1`` ``1`` `$_DLATCH_PP1_` + ============= ============== ============== =============== + +The cell types ``$_DLATCHSR_[NP][NP][NP]_`` implement d-type latches with set +and reset. The values in the table for these cell types relate to the following +Verilog code template: + +.. code-block:: verilog + :force: + + always @* + if (R == RST_LVL) + Q <= 0; + else if (S == SET_LVL) + Q <= 1; + else if (E == EN_LVL) + Q <= D; + +.. table:: Cell types for gate level logic networks (latches with set and reset) + :name: tab:CellLib_gates_dlatchsr + + ============= ============== ============== ================= + :math:`EnLvl` :math:`SetLvl` :math:`RstLvl` Cell Type + ============= ============== ============== ================= + ``0`` ``0`` ``0`` `$_DLATCHSR_NNN_` + ``0`` ``0`` ``1`` `$_DLATCHSR_NNP_` + ``0`` ``1`` ``0`` `$_DLATCHSR_NPN_` + ``0`` ``1`` ``1`` `$_DLATCHSR_NPP_` + ``1`` ``0`` ``0`` `$_DLATCHSR_PNN_` + ``1`` ``0`` ``1`` `$_DLATCHSR_PNP_` + ``1`` ``1`` ``0`` `$_DLATCHSR_PPN_` + ``1`` ``1`` ``1`` `$_DLATCHSR_PPP_` + ============= ============== ============== ================= + +The cell types ``$_SR_[NP][NP]_`` implement sr-type latches. The values in the +table for these cell types relate to the following Verilog code template: + +.. code-block:: verilog + :force: + + always @* + if (R == RST_LVL) + Q <= 0; + else if (S == SET_LVL) + Q <= 1; + +.. table:: Cell types for gate level logic networks (SR latches) + :name: tab:CellLib_gates_sr + + ============== ============== ========== + :math:`SetLvl` :math:`RstLvl` Cell Type + ============== ============== ========== + ``0`` ``0`` `$_SR_NN_` + ``0`` ``1`` `$_SR_NP_` + ``1`` ``0`` `$_SR_PN_` + ``1`` ``1`` `$_SR_PP_` + ============== ============== ========== + +.. autocellgroup:: reg_latch + :members: + :source: + :linenos: diff --git a/docs/source/cell_gate.rst b/docs/source/cell_gate.rst index 4262fe210af..e6fab4c1f5f 100644 --- a/docs/source/cell_gate.rst +++ b/docs/source/cell_gate.rst @@ -1,388 +1,13 @@ -.. role:: verilog(code) - :language: Verilog - .. _sec:celllib_gates: Gate-level cells ---------------- -.. todo:: Split gate-level cells into subpages - - Consider also checking wording to be less academic and consistent. - 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 -techlibs/common/simcells.v in the Yosys source tree. - -.. table:: Cell types for gate level logic networks (main list) - :name: tab:CellLib_gates - - ======================================= ============= - Verilog Cell Type - ======================================= ============= - :verilog:`Y = A` `$_BUF_` - :verilog:`Y = ~A` `$_NOT_` - :verilog:`Y = A & B` `$_AND_` - :verilog:`Y = ~(A & B)` `$_NAND_` - :verilog:`Y = A & ~B` `$_ANDNOT_` - :verilog:`Y = A | B` `$_OR_` - :verilog:`Y = ~(A | B)` `$_NOR_` - :verilog:`Y = A | ~B` `$_ORNOT_` - :verilog:`Y = A ^ B` `$_XOR_` - :verilog:`Y = ~(A ^ B)` `$_XNOR_` - :verilog:`Y = ~((A & B) | C)` `$_AOI3_` - :verilog:`Y = ~((A | B) & C)` `$_OAI3_` - :verilog:`Y = ~((A & B) | (C & D))` `$_AOI4_` - :verilog:`Y = ~((A | B) & (C | D))` `$_OAI4_` - :verilog:`Y = S ? B : A` `$_MUX_` - :verilog:`Y = ~(S ? B : A)` `$_NMUX_` - (see below) `$_MUX4_` - (see below) `$_MUX8_` - (see below) `$_MUX16_` - :verilog:`Y = EN ? A : 1'bz` `$_TBUF_` - :verilog:`always @(negedge C) Q <= D` `$_DFF_N_` - :verilog:`always @(posedge C) Q <= D` `$_DFF_P_` - :verilog:`always @* if (!E) Q <= D` `$_DLATCH_N_` - :verilog:`always @* if (E) Q <= D` `$_DLATCH_P_` - ======================================= ============= - -.. table:: Cell types for gate level logic networks (FFs with reset) - :name: tab:CellLib_gates_adff - - ================== ============== ============== =========================== - :math:`ClkEdge` :math:`RstLvl` :math:`RstVal` Cell Type - ================== ============== ============== =========================== - :verilog:`negedge` ``0`` ``0`` `$_DFF_NN0_`, `$_SDFF_NN0_` - :verilog:`negedge` ``0`` ``1`` `$_DFF_NN1_`, `$_SDFF_NN1_` - :verilog:`negedge` ``1`` ``0`` `$_DFF_NP0_`, `$_SDFF_NP0_` - :verilog:`negedge` ``1`` ``1`` `$_DFF_NP1_`, `$_SDFF_NP1_` - :verilog:`posedge` ``0`` ``0`` `$_DFF_PN0_`, `$_SDFF_PN0_` - :verilog:`posedge` ``0`` ``1`` `$_DFF_PN1_`, `$_SDFF_PN1_` - :verilog:`posedge` ``1`` ``0`` `$_DFF_PP0_`, `$_SDFF_PP0_` - :verilog:`posedge` ``1`` ``1`` `$_DFF_PP1_`, `$_SDFF_PP1_` - ================== ============== ============== =========================== - - -.. table:: Cell types for gate level logic networks (FFs with enable) - :name: tab:CellLib_gates_dffe - - ================== ============= ============ - :math:`ClkEdge` :math:`EnLvl` Cell Type - ================== ============= ============ - :verilog:`negedge` ``0`` `$_DFFE_NN_` - :verilog:`negedge` ``1`` `$_DFFE_NP_` - :verilog:`posedge` ``0`` `$_DFFE_PN_` - :verilog:`posedge` ``1`` `$_DFFE_PP_` - ================== ============= ============ - - -.. table:: Cell types for gate level logic networks (FFs with reset and enable) - :name: tab:CellLib_gates_adffe - - ================== ============== ============== ============= ================================================= - :math:`ClkEdge` :math:`RstLvl` :math:`RstVal` :math:`EnLvl` Cell Type - ================== ============== ============== ============= ================================================= - :verilog:`negedge` ``0`` ``0`` ``0`` `$_DFFE_NN0N_`, `$_SDFFE_NN0N_`, `$_SDFFCE_NN0N_` - :verilog:`negedge` ``0`` ``0`` ``1`` `$_DFFE_NN0P_`, `$_SDFFE_NN0P_`, `$_SDFFCE_NN0P_` - :verilog:`negedge` ``0`` ``1`` ``0`` `$_DFFE_NN1N_`, `$_SDFFE_NN1N_`, `$_SDFFCE_NN1N_` - :verilog:`negedge` ``0`` ``1`` ``1`` `$_DFFE_NN1P_`, `$_SDFFE_NN1P_`, `$_SDFFCE_NN1P_` - :verilog:`negedge` ``1`` ``0`` ``0`` `$_DFFE_NP0N_`, `$_SDFFE_NP0N_`, `$_SDFFCE_NP0N_` - :verilog:`negedge` ``1`` ``0`` ``1`` `$_DFFE_NP0P_`, `$_SDFFE_NP0P_`, `$_SDFFCE_NP0P_` - :verilog:`negedge` ``1`` ``1`` ``0`` `$_DFFE_NP1N_`, `$_SDFFE_NP1N_`, `$_SDFFCE_NP1N_` - :verilog:`negedge` ``1`` ``1`` ``1`` `$_DFFE_NP1P_`, `$_SDFFE_NP1P_`, `$_SDFFCE_NP1P_` - :verilog:`posedge` ``0`` ``0`` ``0`` `$_DFFE_PN0N_`, `$_SDFFE_PN0N_`, `$_SDFFCE_PN0N_` - :verilog:`posedge` ``0`` ``0`` ``1`` `$_DFFE_PN0P_`, `$_SDFFE_PN0P_`, `$_SDFFCE_PN0P_` - :verilog:`posedge` ``0`` ``1`` ``0`` `$_DFFE_PN1N_`, `$_SDFFE_PN1N_`, `$_SDFFCE_PN1N_` - :verilog:`posedge` ``0`` ``1`` ``1`` `$_DFFE_PN1P_`, `$_SDFFE_PN1P_`, `$_SDFFCE_PN1P_` - :verilog:`posedge` ``1`` ``0`` ``0`` `$_DFFE_PP0N_`, `$_SDFFE_PP0N_`, `$_SDFFCE_PP0N_` - :verilog:`posedge` ``1`` ``0`` ``1`` `$_DFFE_PP0P_`, `$_SDFFE_PP0P_`, `$_SDFFCE_PP0P_` - :verilog:`posedge` ``1`` ``1`` ``0`` `$_DFFE_PP1N_`, `$_SDFFE_PP1N_`, `$_SDFFCE_PP1N_` - :verilog:`posedge` ``1`` ``1`` ``1`` `$_DFFE_PP1P_`, `$_SDFFE_PP1P_`, `$_SDFFCE_PP1P_` - ================== ============== ============== ============= ================================================= - -.. table:: Cell types for gate level logic networks (FFs with set and reset) - :name: tab:CellLib_gates_dffsr - - ================== ============== ============== ============== - :math:`ClkEdge` :math:`SetLvl` :math:`RstLvl` Cell Type - ================== ============== ============== ============== - :verilog:`negedge` ``0`` ``0`` `$_DFFSR_NNN_` - :verilog:`negedge` ``0`` ``1`` `$_DFFSR_NNP_` - :verilog:`negedge` ``1`` ``0`` `$_DFFSR_NPN_` - :verilog:`negedge` ``1`` ``1`` `$_DFFSR_NPP_` - :verilog:`posedge` ``0`` ``0`` `$_DFFSR_PNN_` - :verilog:`posedge` ``0`` ``1`` `$_DFFSR_PNP_` - :verilog:`posedge` ``1`` ``0`` `$_DFFSR_PPN_` - :verilog:`posedge` ``1`` ``1`` `$_DFFSR_PPP_` - ================== ============== ============== ============== - - -.. table:: Cell types for gate level logic networks (FFs with set and reset and enable) - :name: tab:CellLib_gates_dffsre - - ================== ============== ============== ============= ================ - :math:`ClkEdge` :math:`SetLvl` :math:`RstLvl` :math:`EnLvl` Cell Type - ================== ============== ============== ============= ================ - :verilog:`negedge` ``0`` ``0`` ``0`` `$_DFFSRE_NNNN_` - :verilog:`negedge` ``0`` ``0`` ``1`` `$_DFFSRE_NNNP_` - :verilog:`negedge` ``0`` ``1`` ``0`` `$_DFFSRE_NNPN_` - :verilog:`negedge` ``0`` ``1`` ``1`` `$_DFFSRE_NNPP_` - :verilog:`negedge` ``1`` ``0`` ``0`` `$_DFFSRE_NPNN_` - :verilog:`negedge` ``1`` ``0`` ``1`` `$_DFFSRE_NPNP_` - :verilog:`negedge` ``1`` ``1`` ``0`` `$_DFFSRE_NPPN_` - :verilog:`negedge` ``1`` ``1`` ``1`` `$_DFFSRE_NPPP_` - :verilog:`posedge` ``0`` ``0`` ``0`` `$_DFFSRE_PNNN_` - :verilog:`posedge` ``0`` ``0`` ``1`` `$_DFFSRE_PNNP_` - :verilog:`posedge` ``0`` ``1`` ``0`` `$_DFFSRE_PNPN_` - :verilog:`posedge` ``0`` ``1`` ``1`` `$_DFFSRE_PNPP_` - :verilog:`posedge` ``1`` ``0`` ``0`` `$_DFFSRE_PPNN_` - :verilog:`posedge` ``1`` ``0`` ``1`` `$_DFFSRE_PPNP_` - :verilog:`posedge` ``1`` ``1`` ``0`` `$_DFFSRE_PPPN_` - :verilog:`posedge` ``1`` ``1`` ``1`` `$_DFFSRE_PPPP_` - ================== ============== ============== ============= ================ - - -.. table:: Cell types for gate level logic networks (latches with reset) - :name: tab:CellLib_gates_adlatch - - ============= ============== ============== =============== - :math:`EnLvl` :math:`RstLvl` :math:`RstVal` Cell Type - ============= ============== ============== =============== - ``0`` ``0`` ``0`` `$_DLATCH_NN0_` - ``0`` ``0`` ``1`` `$_DLATCH_NN1_` - ``0`` ``1`` ``0`` `$_DLATCH_NP0_` - ``0`` ``1`` ``1`` `$_DLATCH_NP1_` - ``1`` ``0`` ``0`` `$_DLATCH_PN0_` - ``1`` ``0`` ``1`` `$_DLATCH_PN1_` - ``1`` ``1`` ``0`` `$_DLATCH_PP0_` - ``1`` ``1`` ``1`` `$_DLATCH_PP1_` - ============= ============== ============== =============== - - -.. table:: Cell types for gate level logic networks (latches with set and reset) - :name: tab:CellLib_gates_dlatchsr - - ============= ============== ============== ================= - :math:`EnLvl` :math:`SetLvl` :math:`RstLvl` Cell Type - ============= ============== ============== ================= - ``0`` ``0`` ``0`` `$_DLATCHSR_NNN_` - ``0`` ``0`` ``1`` `$_DLATCHSR_NNP_` - ``0`` ``1`` ``0`` `$_DLATCHSR_NPN_` - ``0`` ``1`` ``1`` `$_DLATCHSR_NPP_` - ``1`` ``0`` ``0`` `$_DLATCHSR_PNN_` - ``1`` ``0`` ``1`` `$_DLATCHSR_PNP_` - ``1`` ``1`` ``0`` `$_DLATCHSR_PPN_` - ``1`` ``1`` ``1`` `$_DLATCHSR_PPP_` - ============= ============== ============== ================= - - - -.. table:: Cell types for gate level logic networks (SR latches) - :name: tab:CellLib_gates_sr - - ============== ============== ========== - :math:`SetLvl` :math:`RstLvl` Cell Type - ============== ============== ========== - ``0`` ``0`` `$_SR_NN_` - ``0`` ``1`` `$_SR_NP_` - ``1`` ``0`` `$_SR_PN_` - ``1`` ``1`` `$_SR_PP_` - ============== ============== ========== - - -Tables :numref:`%s `, :numref:`%s `, -:numref:`%s `, :numref:`%s `, -:numref:`%s `, :numref:`%s `, -:numref:`%s `, :numref:`%s -` and :numref:`%s ` list all -cell types used for gate level logic. The cell types `$_BUF_`, `$_NOT_`, -`$_AND_`, `$_NAND_`, `$_ANDNOT_`, `$_OR_`, `$_NOR_`, `$_ORNOT_`, `$_XOR_`, -`$_XNOR_`, `$_AOI3_`, `$_OAI3_`, `$_AOI4_`, `$_OAI4_`, `$_MUX_`, `$_MUX4_`, -`$_MUX8_`, `$_MUX16_` and `$_NMUX_` are used to model combinatorial logic. The -cell type `$_TBUF_` is used to model tristate logic. - -The `$_MUX4_`, `$_MUX8_` and `$_MUX16_` cells are used to model wide muxes, and -correspond to the following Verilog code: - -.. code-block:: verilog - :force: - - // $_MUX4_ - assign Y = T ? (S ? D : C) : - (S ? B : A); - // $_MUX8_ - assign Y = U ? T ? (S ? H : G) : - (S ? F : E) : - T ? (S ? D : C) : - (S ? B : A); - // $_MUX16_ - assign Y = V ? U ? T ? (S ? P : O) : - (S ? N : M) : - T ? (S ? L : K) : - (S ? J : I) : - U ? T ? (S ? H : G) : - (S ? F : E) : - T ? (S ? D : C) : - (S ? B : A); - -The cell types `$_DFF_N_` and `$_DFF_P_` represent d-type flip-flops. - -The cell types ``$_DFFE_[NP][NP]_`` implement d-type flip-flops with enable. The -values in the table for these cell types relate to the following Verilog code -template. - -.. code-block:: verilog - :force: - - always @(CLK_EDGE C) - if (EN == EN_LVL) - Q <= D; - -The cell types ``$_DFF_[NP][NP][01]_`` implement d-type flip-flops with -asynchronous reset. The values in the table for these cell types relate to the -following Verilog code template, where ``RST_EDGE`` is ``posedge`` if -``RST_LVL`` if ``1``, and ``negedge`` otherwise. - -.. code-block:: verilog - :force: - - always @(CLK_EDGE C, RST_EDGE R) - if (R == RST_LVL) - Q <= RST_VAL; - else - Q <= D; - -The cell types ``$_SDFF_[NP][NP][01]_`` implement d-type flip-flops with -synchronous reset. The values in the table for these cell types relate to the -following Verilog code template: - -.. code-block:: verilog - :force: - - always @(CLK_EDGE C) - if (R == RST_LVL) - Q <= RST_VAL; - else - Q <= D; - -The cell types ``$_DFFE_[NP][NP][01][NP]_`` implement d-type flip-flops with -asynchronous reset and enable. The values in the table for these cell types -relate to the following Verilog code template, where ``RST_EDGE`` is ``posedge`` -if ``RST_LVL`` if ``1``, and ``negedge`` otherwise. - -.. code-block:: verilog - :force: - - always @(CLK_EDGE C, RST_EDGE R) - if (R == RST_LVL) - Q <= RST_VAL; - else if (EN == EN_LVL) - Q <= D; - -The cell types ``$_SDFFE_[NP][NP][01][NP]_`` implement d-type flip-flops with -synchronous reset and enable, with reset having priority over enable. The values -in the table for these cell types relate to the following Verilog code template: - -.. code-block:: verilog - :force: - - always @(CLK_EDGE C) - if (R == RST_LVL) - Q <= RST_VAL; - else if (EN == EN_LVL) - Q <= D; - -The cell types ``$_SDFFCE_[NP][NP][01][NP]_`` implement d-type flip-flops with -synchronous reset and enable, with enable having priority over reset. The values -in the table for these cell types relate to the following Verilog code template: - -.. code-block:: verilog - :force: - - always @(CLK_EDGE C) - if (EN == EN_LVL) - if (R == RST_LVL) - Q <= RST_VAL; - else - Q <= D; - -The cell types ``$_DFFSR_[NP][NP][NP]_`` implement d-type flip-flops with -asynchronous set and reset. The values in the table for these cell types relate -to the following Verilog code template, where ``RST_EDGE`` is ``posedge`` if -``RST_LVL`` if ``1``, ``negedge`` otherwise, and ``SET_EDGE`` is ``posedge`` if -``SET_LVL`` if ``1``, ``negedge`` otherwise. - -.. code-block:: verilog - :force: - - always @(CLK_EDGE C, RST_EDGE R, SET_EDGE S) - if (R == RST_LVL) - Q <= 0; - else if (S == SET_LVL) - Q <= 1; - else - Q <= D; - -The cell types ``$_DFFSRE_[NP][NP][NP][NP]_`` implement d-type flip-flops with -asynchronous set and reset and enable. The values in the table for these cell -types relate to the following Verilog code template, where ``RST_EDGE`` is -``posedge`` if ``RST_LVL`` if ``1``, ``negedge`` otherwise, and ``SET_EDGE`` is -``posedge`` if ``SET_LVL`` if ``1``, ``negedge`` otherwise. - -.. code-block:: verilog - :force: - - always @(CLK_EDGE C, RST_EDGE R, SET_EDGE S) - if (R == RST_LVL) - Q <= 0; - else if (S == SET_LVL) - Q <= 1; - else if (E == EN_LVL) - Q <= D; - -The cell types `$_DLATCH_N_` and `$_DLATCH_P_` represent d-type latches. - -The cell types ``$_DLATCH_[NP][NP][01]_`` implement d-type latches with reset. -The values in the table for these cell types relate to the following Verilog -code template: - -.. code-block:: verilog - :force: - - always @* - if (R == RST_LVL) - Q <= RST_VAL; - else if (E == EN_LVL) - Q <= D; - -The cell types ``$_DLATCHSR_[NP][NP][NP]_`` implement d-type latches with set -and reset. The values in the table for these cell types relate to the following -Verilog code template: - -.. code-block:: verilog - :force: - - always @* - if (R == RST_LVL) - Q <= 0; - else if (S == SET_LVL) - Q <= 1; - else if (E == EN_LVL) - Q <= D; - -The cell types ``$_SR_[NP][NP]_`` implement sr-type latches. The values in the -table for these cell types relate to the following Verilog code template: - -.. code-block:: verilog - :force: - - always @* - if (R == RST_LVL) - Q <= 0; - else if (S == SET_LVL) - Q <= 1; +:file:`techlibs/common/simcells.v` in the Yosys source tree. In most cases gate level logic networks are created from RTL networks using the techmap pass. The flip-flop cells from the gate level logic network can be @@ -394,4 +19,18 @@ file via ABC using the abc pass. :caption: Gate-level cells :maxdepth: 2 - /cell/gate_other + /cell/gate_comb_simple + /cell/gate_comb_combined + /cell/gate_reg_ff + /cell/gate_reg_latch + +.. TODO:: Find a home for `$_TBUF_` + +.. this should raise a warning, otherwise there are gate-level cells without a + 'group' tag + +.. autocellgroup:: gate_other + :caption: Other gate-level cells + :members: + :source: + :linenos: From 00050833ef2d7f83f9e01c40fee5697a7fafdc61 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Tue, 3 Sep 2024 12:03:57 +1200 Subject: [PATCH 48/68] Docs: Add gate_other page Drop word_other block since it raises a warning, which will cause the RTDs build to fail. --- docs/source/cell/gate_other.rst | 8 ++++++++ docs/source/cell_gate.rst | 12 +----------- docs/source/cell_word.rst | 9 +-------- 3 files changed, 10 insertions(+), 19 deletions(-) create mode 100644 docs/source/cell/gate_other.rst diff --git a/docs/source/cell/gate_other.rst b/docs/source/cell/gate_other.rst new file mode 100644 index 00000000000..bac26094e8e --- /dev/null +++ b/docs/source/cell/gate_other.rst @@ -0,0 +1,8 @@ +Other gate-level cells +---------------------- + +.. autocellgroup:: gate_other + :caption: Other gate-level cells + :members: + :source: + :linenos: diff --git a/docs/source/cell_gate.rst b/docs/source/cell_gate.rst index e6fab4c1f5f..4ff38ec5e3b 100644 --- a/docs/source/cell_gate.rst +++ b/docs/source/cell_gate.rst @@ -23,14 +23,4 @@ file via ABC using the abc pass. /cell/gate_comb_combined /cell/gate_reg_ff /cell/gate_reg_latch - -.. TODO:: Find a home for `$_TBUF_` - -.. this should raise a warning, otherwise there are gate-level cells without a - 'group' tag - -.. autocellgroup:: gate_other - :caption: Other gate-level cells - :members: - :source: - :linenos: + /cell/gate_other diff --git a/docs/source/cell_word.rst b/docs/source/cell_word.rst index 3c87d991345..bfb14f5102d 100644 --- a/docs/source/cell_word.rst +++ b/docs/source/cell_word.rst @@ -29,11 +29,4 @@ Simulation models for the RTL cells can be found in the file /cell/word_debug /cell/word_wire -.. this should raise a warning, otherwise there are word-level cells without a - 'group' tag - -.. autocellgroup:: word_other - :caption: Other word-level cells - :members: - :source: - :linenos: +.. todo:: Add check for unexpected ``word_other`` cells From 217c2a15dd1af93835ce5afbe060b84663bb9e5c Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Tue, 3 Sep 2024 12:13:52 +1200 Subject: [PATCH 49/68] Docs: Add todos from JF --- docs/source/cell/word_binary.rst | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/docs/source/cell/word_binary.rst b/docs/source/cell/word_binary.rst index 68bc5a3aafc..5c802294c51 100644 --- a/docs/source/cell/word_binary.rst +++ b/docs/source/cell/word_binary.rst @@ -4,7 +4,17 @@ Binary operators ~~~~~~~~~~~~~~~~ -.. todo:: Add detail on ``$*x`` cells, `$eqx`, `$nex`, `$bweqx`, `$shiftx` +.. todo:: 'x' aware warning + + some passes will treat cell as the non 'x' aware cell, i.e. synthesis; `$eqx` + `$nex` `$bweqx` + +.. todo:: 'x' output + + shiftx, div, mod, pmux (less-so) can produce 'x' output even if all inputs + are defined + +.. todo:: `$eqx` is the case equality operator All binary RTL cells have two input ports ``A`` and ``B`` and one output port ``Y``. They also have the following parameters: From 5c4f7b4debfd7c7ae0dab6af4729b1244545f500 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Thu, 5 Sep 2024 16:10:28 +1200 Subject: [PATCH 50/68] Docs: $eqx aka case equality --- docs/source/cell/word_binary.rst | 2 -- techlibs/common/simlib.v | 9 +++++---- 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/docs/source/cell/word_binary.rst b/docs/source/cell/word_binary.rst index 5c802294c51..87d558eda8a 100644 --- a/docs/source/cell/word_binary.rst +++ b/docs/source/cell/word_binary.rst @@ -14,8 +14,6 @@ Binary operators shiftx, div, mod, pmux (less-so) can produce 'x' output even if all inputs are defined -.. todo:: `$eqx` is the case equality operator - All binary RTL cells have two input ports ``A`` and ``B`` and one output port ``Y``. They also have the following parameters: diff --git a/techlibs/common/simlib.v b/techlibs/common/simlib.v index a954b64ec6d..bf30443c5f4 100644 --- a/techlibs/common/simlib.v +++ b/techlibs/common/simlib.v @@ -833,10 +833,11 @@ endmodule //- $eqx (A, B, Y) //* group binary //- -//- An exact equality comparison between inputs 'A' and 'B'. -//- This corresponds to the Verilog '===' operator. -//- Unlike equality comparison that can give 'x' as output, -//- an exact equality comparison will strictly give '0' or '1' as output. +//- An exact equality comparison between inputs 'A' and 'B'. Also known as the +//- case equality operator. This corresponds to the Verilog '===' operator. +//- Unlike equality comparison that can give 'x' as output, an exact equality +//- comparison will strictly give '0' or '1' as output, even if input includes +//- 'x' or 'z' values. //- module \$eqx (A, B, Y); From f70a66f5b3bf8e66e5ffc49ce9050c8609a3ba64 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Thu, 5 Sep 2024 16:20:13 +1200 Subject: [PATCH 51/68] Docs: Assert cell has group Explicitly assign $_TBUF_ to `gate_other` and remove catch if a cell has no group. --- docs/source/cell_word.rst | 2 -- techlibs/common/cellhelp.py | 7 +------ techlibs/common/simcells.v | 1 + 3 files changed, 2 insertions(+), 8 deletions(-) diff --git a/docs/source/cell_word.rst b/docs/source/cell_word.rst index bfb14f5102d..d52c4c934e3 100644 --- a/docs/source/cell_word.rst +++ b/docs/source/cell_word.rst @@ -28,5 +28,3 @@ Simulation models for the RTL cells can be found in the file /cell/word_formal /cell/word_debug /cell/word_wire - -.. todo:: Add check for unexpected ``word_other`` cells diff --git a/techlibs/common/cellhelp.py b/techlibs/common/cellhelp.py index 9aa3def93cc..a6b2ce88a0a 100644 --- a/techlibs/common/cellhelp.py +++ b/techlibs/common/cellhelp.py @@ -88,12 +88,7 @@ def simcells_reparse(cell: SimHelper): simHelper.desc.pop(1) # check group - if not simHelper.group: - if short_filename == 'simcells.v': - simHelper.group = "gate_" - elif short_filename == 'simlib.v': - simHelper.group = "word_" - simHelper.group += "other" + assert simHelper.group, f"techlibs/common/{simHelper.source}: {simHelper.name} cell missing group" # dump print(simHelper) diff --git a/techlibs/common/simcells.v b/techlibs/common/simcells.v index 104022079cf..1a113447ef7 100644 --- a/techlibs/common/simcells.v +++ b/techlibs/common/simcells.v @@ -461,6 +461,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $_TBUF_ (A, E, Y) +//* group gate_other //- //- A tri-state buffer. //- From 9ce69521316d320c1078089f0b7cf63127950621 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Thu, 5 Sep 2024 16:22:16 +1200 Subject: [PATCH 52/68] Docs: TODOs block, todos don't --- docs/source/cell/word_formal.rst | 2 +- docs/source/cell/word_fsm.rst | 2 +- docs/source/cell/word_spec.rst | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/source/cell/word_formal.rst b/docs/source/cell/word_formal.rst index 8c52422a833..df78eb0b263 100644 --- a/docs/source/cell/word_formal.rst +++ b/docs/source/cell/word_formal.rst @@ -5,7 +5,7 @@ Formal verification cells If only I remembered what the note was... -.. TODO:: Describe formal cells +.. todo:: Describe formal cells `$check`, `$assert`, `$assume`, `$live`, `$fair`, `$cover`, `$equiv`, `$initstate`, `$anyconst`, `$anyseq`, `$anyinit`, `$allconst`, and `$allseq`. diff --git a/docs/source/cell/word_fsm.rst b/docs/source/cell/word_fsm.rst index 943904b2b2e..e6301bf3b9e 100644 --- a/docs/source/cell/word_fsm.rst +++ b/docs/source/cell/word_fsm.rst @@ -1,7 +1,7 @@ Finite state machines --------------------- -.. TODO:: Describe `$fsm` cell +.. todo:: Describe `$fsm` cell .. autocellgroup:: fsm :members: diff --git a/docs/source/cell/word_spec.rst b/docs/source/cell/word_spec.rst index 33ef407744f..b5ce967d08a 100644 --- a/docs/source/cell/word_spec.rst +++ b/docs/source/cell/word_spec.rst @@ -1,7 +1,7 @@ Specify rules ------------- -.. TODO:: `$specify2`, `$specify3`, and `$specrule` cells. +.. todo:: `$specify2`, `$specify3`, and `$specrule` cells. .. autocellgroup:: spec :members: From b1025dbaa6f81454486fb33778b8950a25045646 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Thu, 5 Sep 2024 16:51:26 +1200 Subject: [PATCH 53/68] cellhelp.py: Cells can have tags Tags are added to the list of properties when exporting to `cells.json`. --- kernel/register.cc | 21 +++++++++++++++------ techlibs/common/cellhelp.py | 3 +++ 2 files changed, 18 insertions(+), 6 deletions(-) diff --git a/kernel/register.cc b/kernel/register.cc index ce6eb8018b2..311c9296104 100644 --- a/kernel/register.cc +++ b/kernel/register.cc @@ -766,6 +766,7 @@ struct SimHelper { string code; string group; string ver; + string tags; }; static bool is_code_getter(string name) { @@ -1013,12 +1014,20 @@ struct HelpPass : public Pass { for (auto &output : ct.outputs) outputs.push_back(output.str()); json.name("outputs"); json.value(outputs); - dict prop_dict = { - {"is_evaluable", ct.is_evaluable}, - {"is_combinatorial", ct.is_combinatorial}, - {"is_synthesizable", ct.is_synthesizable}, - }; - json.name("properties"); json.value(prop_dict); + vector properties; + // CellType properties + if (ct.is_evaluable) properties.push_back("is_evaluable"); + if (ct.is_combinatorial) properties.push_back("is_combinatorial"); + if (ct.is_synthesizable) properties.push_back("is_synthesizable"); + // SimHelper properties + size_t last = 0; size_t next = 0; + while ((next = ch.tags.find(", ", last)) != string::npos) { + properties.push_back(ch.tags.substr(last, next-last)); + last = next + 2; + } + auto final_tag = ch.tags.substr(last); + if (final_tag.size()) properties.push_back(final_tag); + json.name("properties"); json.value(properties); json.end_object(); } json.end_object(); diff --git a/techlibs/common/cellhelp.py b/techlibs/common/cellhelp.py index a6b2ce88a0a..74155873084 100644 --- a/techlibs/common/cellhelp.py +++ b/techlibs/common/cellhelp.py @@ -14,13 +14,16 @@ class SimHelper: code: list[str] group: str = "" ver: str = "1" + tags: list[str] def __init__(self) -> None: self.desc = [] + self.tags = [] def __str__(self) -> str: printed_fields = [ "name", "title", "ports", "source", "desc", "code", "group", "ver", + "tags", ] # generate C++ struct val = f"cell_help[{json.dumps(self.name)}] = " From ed923742638a94f3f87137e3b928cdb0bafc2bb8 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Thu, 5 Sep 2024 17:46:46 +1200 Subject: [PATCH 54/68] simlib.v: Update case equality operators to v2 Also tag as x-aware cells and add titles. --- techlibs/common/simlib.v | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/techlibs/common/simlib.v b/techlibs/common/simlib.v index bf30443c5f4..959ba14198e 100644 --- a/techlibs/common/simlib.v +++ b/techlibs/common/simlib.v @@ -828,11 +828,10 @@ endmodule // -------------------------------------------------------- -// |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| -//- -//- $eqx (A, B, Y) +//* ver 2 +//* title Case equality //* group binary -//- +//* tags x-aware //- An exact equality comparison between inputs 'A' and 'B'. Also known as the //- case equality operator. This corresponds to the Verilog '===' operator. //- Unlike equality comparison that can give 'x' as output, an exact equality @@ -863,15 +862,13 @@ endmodule // -------------------------------------------------------- -// |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| -//- -//- $nex (A, B, Y) +//* ver 2 +//* title Case inequality //* group binary -//- -//- An exact inequality comparison between inputs 'A' and 'B'. +//* tags x-aware //- This corresponds to the Verilog '!==' operator. -//- Unlike inequality comparison that can give 'x' as output, -//- an exact inequality comparison will strictly give '0' or '1' as output. +//- +//- Refer to `$eqx` for more details. //- module \$nex (A, B, Y); @@ -1871,7 +1868,13 @@ endspecify endmodule // -------------------------------------------------------- + +//* ver 2 +//* title Bit-wise case equality //* group binary +//* tags x-aware +//- A bit-wise version of `$eqx`. +//- module \$bweqx (A, B, Y); parameter WIDTH = 0; From 1a2401816a7b6395ac48f092f94369712bafa814 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Thu, 5 Sep 2024 17:47:36 +1200 Subject: [PATCH 55/68] Docs: Add cell title TODO --- docs/source/cell/word_binary.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/source/cell/word_binary.rst b/docs/source/cell/word_binary.rst index 87d558eda8a..70b54004eaf 100644 --- a/docs/source/cell/word_binary.rst +++ b/docs/source/cell/word_binary.rst @@ -4,6 +4,8 @@ Binary operators ~~~~~~~~~~~~~~~~ +.. TODO:: display cell titles + .. todo:: 'x' aware warning some passes will treat cell as the non 'x' aware cell, i.e. synthesis; `$eqx` From e3d939b7190c20551ec8dbe0ba0c460af06b2d92 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Thu, 5 Sep 2024 17:50:32 +1200 Subject: [PATCH 56/68] Docs: Drop fifo.out and fifo.stat These two files can now be safely .gitignore'd. --- docs/source/code_examples/fifo/.gitignore | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 docs/source/code_examples/fifo/.gitignore diff --git a/docs/source/code_examples/fifo/.gitignore b/docs/source/code_examples/fifo/.gitignore new file mode 100644 index 00000000000..b858bebc659 --- /dev/null +++ b/docs/source/code_examples/fifo/.gitignore @@ -0,0 +1,2 @@ +*.out +*.stat From ce6a7fe4fc9949787f768b8e743b38ae017fe0ea Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Fri, 6 Sep 2024 15:17:51 +1200 Subject: [PATCH 57/68] docs/util: Cells now have properties Properties are both an option: ``` .. cell:def:: $add :properties: is_evaluable ``` and a field: ``` .. cell:def:: $eqx :property x-aware: :property is_evaluable: ``` Properties as an option appear in the property index: linking a given property to all cells with that property; while properties as a field display with the cell. --- docs/util/cellref.py | 15 +++- docs/util/cmdref.py | 190 ++++++++++++++++++++++++++++++++++++++----- 2 files changed, 184 insertions(+), 21 deletions(-) diff --git a/docs/util/cellref.py b/docs/util/cellref.py index 3bba278763b..71e8eecd1c8 100644 --- a/docs/util/cellref.py +++ b/docs/util/cellref.py @@ -33,7 +33,7 @@ class YosysCell: code: str inputs: list[str] outputs: list[str] - properties: dict[str, bool] + properties: list[str] class YosysCellGroupDocumenter(Documenter): objtype = 'cellgroup' @@ -298,11 +298,22 @@ def add_directive_header(self, sig: str) -> None: self.add_line(f'.. {domain}:{directive}:: {sig}', sourcename) # options - opt_attrs = ["title", ] + opt_attrs = ["title", "properties", ] for attr in opt_attrs: val = getattr(cell, attr, None) + if isinstance(val, list): + val = ' '.join(val) if val: self.add_line(f' :{attr}: {val}', sourcename) + + self.add_line('\n', sourcename) + + # fields + field_attrs = ["properties", ] + for field in field_attrs: + attr = getattr(cell, field, []) + for val in attr: + self.add_line(f' :{field} {val}:', sourcename) if self.options.noindex: self.add_line(' :noindex:', sourcename) diff --git a/docs/util/cmdref.py b/docs/util/cmdref.py index c7bb4e241d9..c177fdfa6b0 100644 --- a/docs/util/cmdref.py +++ b/docs/util/cmdref.py @@ -2,17 +2,22 @@ from __future__ import annotations +import re +from typing import cast + from docutils import nodes -from docutils.nodes import Node, Element +from docutils.nodes import Node, Element, system_message from docutils.parsers.rst import directives from docutils.parsers.rst.states import Inliner from sphinx.application import Sphinx from sphinx.domains import Domain, Index from sphinx.domains.std import StandardDomain +from sphinx.environment import BuildEnvironment from sphinx.roles import XRefRole from sphinx.directives import ObjectDescription from sphinx.directives.code import container_wrapper from sphinx.util.nodes import make_refnode +from sphinx.util.docfields import Field from sphinx import addnodes class TocNode(ObjectDescription): @@ -70,7 +75,8 @@ def handle_signature(self, sig, signode: addnodes.desc_signature): return signode['fullname'] def add_target_and_index(self, name_cls, sig, signode): - signode['ids'].append(type(self).name + '-' + sig) + idx = type(self).name + '-' + sig + signode['ids'].append(idx) if 'noindex' not in self.options: name = "{}.{}.{}".format(self.name, type(self).__name__, sig) tagmap = self.env.domaindata[type(self).name]['obj2tag'] @@ -79,13 +85,81 @@ def add_target_and_index(self, name_cls, sig, signode): titlemap = self.env.domaindata[type(self).name]['obj2title'] titlemap[name] = title objs = self.env.domaindata[type(self).name]['objects'] + # (name, sig, typ, docname, anchor, prio) objs.append((name, sig, - title, + type(self).name, self.env.docname, - type(self).name + '-' + sig, + idx, 0)) +class PropNode(TocNode): + name = 'prop' + fieldname = 'props' + + def handle_signature(self, sig: str, signode: addnodes.desc_signature): + signode['fullname'] = sig + signode['tocname'] = tocname = sig.split('::')[-1] + signode += addnodes.desc_name(text=tocname) + return signode['fullname'] + + def add_target_and_index( + self, + name: str, + sig: str, + signode: addnodes.desc_signature + ) -> None: + idx = ".".join(name.split("::")) + signode['ids'].append(idx) + if 'noindex' not in self.options: + tocname: str = signode.get('tocname', name) + objs = self.env.domaindata[self.domain]['objects'] + # (name, sig, typ, docname, anchor, prio) + objs.append((name, + tocname, + type(self).name, + self.env.docname, + idx, + 1)) + +class CellGroupedField(Field): + """Custom version of GroupedField which doesn't require content.""" + is_grouped = True + list_type = nodes.bullet_list + + def __init__(self, name: str, names: tuple[str, ...] = (), label: str = None, + rolename: str = None, can_collapse: bool = False) -> None: + super().__init__(name, names, label, True, rolename) + self.can_collapse = can_collapse + + def make_field(self, types: dict[str, list[Node]], domain: str, + items: tuple, env: BuildEnvironment = None, + inliner: Inliner = None, location: Node = None) -> nodes.field: + fieldname = nodes.field_name('', self.label) + listnode = self.list_type() + for fieldarg, content in items: + par = nodes.paragraph() + if fieldarg: + par.extend(self.make_xrefs(self.rolename, domain, + fieldarg, nodes.Text, + env=env, inliner=inliner, location=location)) + + if len(content) == 1 and ( + isinstance(content[0], nodes.Text) or + (isinstance(content[0], nodes.inline) and len(content[0]) == 1 and + isinstance(content[0][0], nodes.Text))): + par += nodes.Text(' -- ') + par += content + listnode += nodes.list_item('', par) + + if len(items) == 1 and self.can_collapse: + list_item = cast(nodes.list_item, listnode[0]) + fieldbody = nodes.field_body('', list_item[0]) + return nodes.field('', fieldname, fieldbody) + + fieldbody = nodes.field_body('', listnode) + return nodes.field('', fieldname, fieldbody) + class CellNode(TocNode): """A custom node that describes an internal cell.""" @@ -94,8 +168,15 @@ class CellNode(TocNode): option_spec = { 'title': directives.unchanged, 'ports': directives.unchanged, + 'properties': directives.unchanged, } + doc_field_types = [ + CellGroupedField('props', label='Properties', rolename='prop', + names=('properties', 'property', 'tag', 'tags'), + can_collapse=True), + ] + def handle_signature(self, sig: str, signode: addnodes.desc_signature): signode['fullname'] = sig signode['tocname'] = tocname = sig.split('::')[-1] @@ -113,16 +194,18 @@ def add_target_and_index( signode['ids'].append(idx) if 'noindex' not in self.options: tocname: str = signode.get('tocname', name) - tagmap = self.env.domaindata[self.domain]['obj2tag'] - tagmap[name] = list(self.options.get('tags', '').split(' ')) title: str = self.options.get('title', sig) titlemap = self.env.domaindata[self.domain]['obj2title'] titlemap[name] = title + props = self.options.get('properties', '') + if props: + propmap = self.env.domaindata[self.domain]['obj2prop'] + propmap[name] = props.split(' ') objs = self.env.domaindata[self.domain]['objects'] # (name, sig, typ, docname, anchor, prio) objs.append((name, tocname, - title, + type(self).name, self.env.docname, idx, 0)) @@ -288,7 +371,7 @@ def generate(self, docnames=None): in self.domain.get_objects()} tmap = {} - tags = self.domain.data['obj2tag'] + tags = self.domain.data[f'obj2{self.name}'] for name, tags in tags.items(): for tag in tags: tmap.setdefault(tag,[]) @@ -304,10 +387,9 @@ def generate(self, docnames=None): anchor, docname, '', typ )) - re = [(k, v) for k, v in sorted(content.items())] - - return (re, True) + ret = [(k, v) for k, v in sorted(content.items())] + return (ret, True) class CommandIndex(Index): name = 'cmd' @@ -345,7 +427,8 @@ def generate(self, docnames=None): content = {} items = ((name, dispname, typ, docname, anchor) for name, dispname, typ, docname, anchor, prio - in self.domain.get_objects()) + in self.domain.get_objects() + if typ == self.name) items = sorted(items, key=lambda item: item[0]) for name, dispname, typ, docname, anchor in items: lis = content.setdefault(self.shortname, []) @@ -354,15 +437,68 @@ def generate(self, docnames=None): anchor, '', '', typ )) - re = [(k, v) for k, v in sorted(content.items())] + ret = [(k, v) for k, v in sorted(content.items())] - return (re, True) + return (ret, True) class CellIndex(CommandIndex): name = 'cell' localname = 'Internal cell reference' shortname = 'Internal cell' +class PropIndex(TagIndex): + """A custom directive that creates a properties matrix.""" + + name = 'prop' + localname = 'Property Index' + shortname = 'Prop' + fieldname = 'props' + + def generate(self, docnames=None): + content = {} + + cells = {name: (dispname, docname, anchor) + for name, dispname, typ, docname, anchor, _ + in self.domain.get_objects() + if typ == 'cell'} + props = {name: (dispname, docname, anchor) + for name, dispname, typ, docname, anchor, _ + in self.domain.get_objects() + if typ == 'prop'} + + tmap: dict[str, list[str]] = {} + tags: dict[str, list[str]] = self.domain.data[f'obj2{self.name}'] + for name, tags in tags.items(): + for tag in tags: + tmap.setdefault(tag,[]) + tmap[tag].append(name) + + for tag in sorted(tmap.keys()): + test = re.match(r'^(\w+[_-])', tag) + tag_prefix = test.group(1) + lis = content.setdefault(tag_prefix, []) + try: + dispname, docname, anchor = props[tag] + except KeyError: + dispname = tag + docname = anchor = '' + lis.append(( + dispname, 1, docname, + anchor, + '', '', docname or 'unavailable' + )) + objlis = tmap[tag] + for objname in sorted(objlis): + dispname, docname, anchor = cells[objname] + lis.append(( + dispname, 2, docname, + anchor, + '', '', docname + )) + ret = [(k, v) for k, v in sorted(content.items())] + + return (ret, True) + class CommandDomain(Domain): name = 'cmd' label = 'Yosys commands' @@ -419,17 +555,33 @@ class CellDomain(CommandDomain): name = 'cell' label = 'Yosys internal cells' + roles = CommandDomain.roles.copy() + roles.update({ + 'prop': XRefRole() + }) + directives = { 'def': CellNode, + 'defprop': PropNode, 'source': CellSourceNode, 'group': CellGroupNode, } indices = { CellIndex, - TagIndex + PropIndex + } + + initial_data = { + 'objects': [], # object list + 'obj2prop': {}, # name -> properties + 'obj2title': {}, # name -> title } + def get_objects(self): + for obj in self.data['objects']: + yield(obj) + def autoref(name, rawtext: str, text: str, lineno, inliner: Inliner, options=None, content=None): role = 'cell:ref' if text[0] == '$' else 'cmd:ref' @@ -448,8 +600,8 @@ def setup(app: Sphinx): ('cmd-tag', '', 'Tag Index') StandardDomain.initial_data['labels']['cellindex'] =\ ('cell-cell', '', 'Internal cell reference') - StandardDomain.initial_data['labels']['tagindex'] =\ - ('cell-tag', '', 'Tag Index') + StandardDomain.initial_data['labels']['propindex'] =\ + ('cell-prop', '', 'Property Index') StandardDomain.initial_data['anonlabels']['commandindex'] =\ ('cmd-cmd', '') @@ -457,8 +609,8 @@ def setup(app: Sphinx): ('cmd-tag', '') StandardDomain.initial_data['anonlabels']['cellindex'] =\ ('cell-cell', '') - StandardDomain.initial_data['anonlabels']['tagindex'] =\ - ('cell-tag', '') + StandardDomain.initial_data['anonlabels']['propindex'] =\ + ('cell-prop', '') app.add_role('autoref', autoref) From 4d84d7e69f68143296e46999387d17f525df976d Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Fri, 6 Sep 2024 15:36:42 +1200 Subject: [PATCH 58/68] simlib.v: Add x-output tag Also a few extra cell help texts. --- techlibs/common/simlib.v | 33 +++++++++++++++++++++++---------- 1 file changed, 23 insertions(+), 10 deletions(-) diff --git a/techlibs/common/simlib.v b/techlibs/common/simlib.v index 959ba14198e..6da22dac07d 100644 --- a/techlibs/common/simlib.v +++ b/techlibs/common/simlib.v @@ -526,7 +526,13 @@ endgenerate endmodule // -------------------------------------------------------- + +//* ver 2 +//* title Indexed part-select //* group binary +//* tags x-output +//- Same as the `$shift` cell, but fills with 'x'. +//- module \$shift (A, B, Y); @@ -559,7 +565,13 @@ endgenerate endmodule // -------------------------------------------------------- + +//* ver 2 +//* title Variable shifter //* group binary +//- Performs a right logical shift if the second operand is positive (or +//- unsigned), and a left logical shift if it is negative. +//- module \$shiftx (A, B, Y); @@ -1204,12 +1216,12 @@ endmodule // -------------------------------------------------------- -// |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| -//- -//- $div (A, B, Y) +//* ver 2 +//* title Divider //* group binary -//- -//- Division with truncated result (rounded towards 0). +//* tags x-output +//- This corresponds to the Verilog '/' operator, performing division and +//- truncating the result (rounding towards 0). //- module \$div (A, B, Y); @@ -1235,12 +1247,12 @@ endmodule // -------------------------------------------------------- -// |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| -//- -//- $mod (A, B, Y) +//* ver 2 +//* title Modulo //* group binary -//- -//- Modulo/remainder of division with truncated result (rounded towards 0). +//* tags x-output +//- This corresponds to the Verilog '%' operator, giving the module (or +//- remainder) of division and truncating the result (rounding towards 0). //- //- Invariant: $div(A, B) * B + $mod(A, B) == A //- @@ -1561,6 +1573,7 @@ endmodule // -------------------------------------------------------- //* group mux +//* tags x-output module \$pmux (A, B, S, Y); From e40134c856260d610b3ab2f242234e21f4f58ccd Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Fri, 6 Sep 2024 15:40:22 +1200 Subject: [PATCH 59/68] Docs: Update for properties Add properties page, move cell_gate and cell_word under a singular cell_index along with properties. Fix links accordingly. Also drop x-aware and x-output todos since they are resolved. --- docs/source/appendix/rtlil_text.rst | 4 ++-- .../{cell_gate.rst => cell/index_gate.rst} | 1 - .../{cell_word.rst => cell/index_word.rst} | 1 - docs/source/cell/properties.rst | 18 ++++++++++++++++++ docs/source/cell/word_binary.rst | 10 ---------- docs/source/cell_index.rst | 11 +++++++++++ docs/source/index.rst | 3 +-- .../interactive_investigation.rst | 2 +- docs/source/using_yosys/synthesis/opt.rst | 2 +- 9 files changed, 34 insertions(+), 18 deletions(-) rename docs/source/{cell_gate.rst => cell/index_gate.rst} (96%) rename docs/source/{cell_word.rst => cell/index_word.rst} (98%) create mode 100644 docs/source/cell/properties.rst create mode 100644 docs/source/cell_index.rst diff --git a/docs/source/appendix/rtlil_text.rst b/docs/source/appendix/rtlil_text.rst index 7febae2edfc..2c7a82d190c 100644 --- a/docs/source/appendix/rtlil_text.rst +++ b/docs/source/appendix/rtlil_text.rst @@ -223,8 +223,8 @@ Cells Declares a cell, with zero or more attributes, with the given identifier and type in the enclosing module. -Cells perform functions on input signals. See :doc:`/cell_gate` and -:doc:`/cell_word` for a detailed list of cell types. +Cells perform functions on input signals. See :doc:`/cell_index` for a detailed +list of cell types. .. code:: BNF diff --git a/docs/source/cell_gate.rst b/docs/source/cell/index_gate.rst similarity index 96% rename from docs/source/cell_gate.rst rename to docs/source/cell/index_gate.rst index 4ff38ec5e3b..c9decc04594 100644 --- a/docs/source/cell_gate.rst +++ b/docs/source/cell/index_gate.rst @@ -16,7 +16,6 @@ The combinatorial logic cells can be mapped to physical cells from a Liberty file via ABC using the abc pass. .. toctree:: - :caption: Gate-level cells :maxdepth: 2 /cell/gate_comb_simple diff --git a/docs/source/cell_word.rst b/docs/source/cell/index_word.rst similarity index 98% rename from docs/source/cell_word.rst rename to docs/source/cell/index_word.rst index d52c4c934e3..cb81c69916b 100644 --- a/docs/source/cell_word.rst +++ b/docs/source/cell/index_word.rst @@ -15,7 +15,6 @@ Simulation models for the RTL cells can be found in the file .. toctree:: :maxdepth: 2 - :glob: /cell/word_unary /cell/word_binary diff --git a/docs/source/cell/properties.rst b/docs/source/cell/properties.rst new file mode 100644 index 00000000000..72ea7611262 --- /dev/null +++ b/docs/source/cell/properties.rst @@ -0,0 +1,18 @@ +Cell properties +--------------- + +.. TODO:: Fill :cell:ref:`is_evaluable` + +.. cell:defprop:: is_evaluable + +.. cell:defprop:: x-aware + + Some passes will treat these cells as the non 'x' aware cell. For example, + during synthesis `$eqx` will typically be treated as `$eq`. + +.. cell:defprop:: x-output + + These cells can produce 'x' output even if all inputs are defined. For + example, a `$div` cell with ``B=0`` has undefined output. + +Refer to the :ref:`propindex` for the list of cells with a given property. diff --git a/docs/source/cell/word_binary.rst b/docs/source/cell/word_binary.rst index 70b54004eaf..b0287f2d1cd 100644 --- a/docs/source/cell/word_binary.rst +++ b/docs/source/cell/word_binary.rst @@ -6,16 +6,6 @@ Binary operators .. TODO:: display cell titles -.. todo:: 'x' aware warning - - some passes will treat cell as the non 'x' aware cell, i.e. synthesis; `$eqx` - `$nex` `$bweqx` - -.. todo:: 'x' output - - shiftx, div, mod, pmux (less-so) can produce 'x' output even if all inputs - are defined - All binary RTL cells have two input ports ``A`` and ``B`` and one output port ``Y``. They also have the following parameters: diff --git a/docs/source/cell_index.rst b/docs/source/cell_index.rst new file mode 100644 index 00000000000..dcfd38a7613 --- /dev/null +++ b/docs/source/cell_index.rst @@ -0,0 +1,11 @@ +Internal cell library +===================== + +.. todo:: brief overview of internal cell library + +.. toctree:: + :maxdepth: 2 + + /cell/index_word + /cell/index_gate + /cell/properties diff --git a/docs/source/index.rst b/docs/source/index.rst index fbdd5ac6f80..8b9cff86921 100644 --- a/docs/source/index.rst +++ b/docs/source/index.rst @@ -50,6 +50,5 @@ available, go to :ref:`commandindex`. bib - cell_word - cell_gate + cell_index cmd_ref diff --git a/docs/source/using_yosys/more_scripting/interactive_investigation.rst b/docs/source/using_yosys/more_scripting/interactive_investigation.rst index 68b5380760d..c6180306da3 100644 --- a/docs/source/using_yosys/more_scripting/interactive_investigation.rst +++ b/docs/source/using_yosys/more_scripting/interactive_investigation.rst @@ -65,7 +65,7 @@ displayed as rectangles with inputs on the left and outputs on the right side. The cell labels are two lines long: The first line contains a unique identifier for the cell and the second line contains the cell type. Internal cell types are prefixed with a dollar sign. For more details on the internal cell library, see -:doc:`/cell_gate` and :doc:`/cell_word`. +:doc:`/cell_index`. Constants are shown as ellipses with the constant value as label. The syntax ``'`` is used for constants that are not 32-bit wide and/or diff --git a/docs/source/using_yosys/synthesis/opt.rst b/docs/source/using_yosys/synthesis/opt.rst index d79a66a755e..743b2499737 100644 --- a/docs/source/using_yosys/synthesis/opt.rst +++ b/docs/source/using_yosys/synthesis/opt.rst @@ -27,7 +27,7 @@ Constant folding and simple expression rewriting - `opt_expr` .. todo:: unsure if this is too much detail and should be in :doc:`/yosys_internals/index` This pass performs constant folding on the internal combinational cell types -described in :doc:`/cell_gate` and :doc:`/cell_word`. This means a cell with all +described in :doc:`/cell_index`. This means a cell with all constant inputs is replaced with the constant value this cell drives. In some cases this pass can also optimize cells with some constant inputs. From 9d808caba6f5a8b26954137618dc61dad0f57681 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Mon, 16 Sep 2024 13:02:54 +1200 Subject: [PATCH 60/68] Docs: Add note on $check --- docs/source/cell/word_formal.rst | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/docs/source/cell/word_formal.rst b/docs/source/cell/word_formal.rst index df78eb0b263..6bfa196567b 100644 --- a/docs/source/cell/word_formal.rst +++ b/docs/source/cell/word_formal.rst @@ -1,9 +1,14 @@ Formal verification cells ------------------------- -.. TODO:: note on `$check` +.. role:: yoscrypt(code) + :language: yoscrypt - If only I remembered what the note was... +.. note:: + + Some front-ends may not support the generic `$check` cell, in such cases + calling :yoscrypt:`chformal -lower` will convert each `$check` cell into it's + equivalent. See `chformal` for more. .. todo:: Describe formal cells From 7216f076916f3bddf271d3a6a3ea2fd612abcd44 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Mon, 16 Sep 2024 13:11:31 +1200 Subject: [PATCH 61/68] Docs: Define is_evaluable --- docs/source/cell/properties.rst | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/source/cell/properties.rst b/docs/source/cell/properties.rst index 72ea7611262..e853ea50a16 100644 --- a/docs/source/cell/properties.rst +++ b/docs/source/cell/properties.rst @@ -1,10 +1,12 @@ Cell properties --------------- -.. TODO:: Fill :cell:ref:`is_evaluable` - .. cell:defprop:: is_evaluable + These cells are able to be used in conjunction with the `eval` command. Some + passes, such as `opt_expr`, may also be able to perform additional + optimizations on cells which are evaluable. + .. cell:defprop:: x-aware Some passes will treat these cells as the non 'x' aware cell. For example, From 927dc445ddd99feb7373eb046e365f48897ff38d Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Mon, 16 Sep 2024 14:11:01 +1200 Subject: [PATCH 62/68] Docs: Render cell titles Also put property lists *after* cell description. --- docs/source/cell/word_binary.rst | 2 -- docs/util/cellref.py | 17 +++++++++-------- docs/util/cmdref.py | 8 ++++++++ 3 files changed, 17 insertions(+), 10 deletions(-) diff --git a/docs/source/cell/word_binary.rst b/docs/source/cell/word_binary.rst index b0287f2d1cd..47a847ee446 100644 --- a/docs/source/cell/word_binary.rst +++ b/docs/source/cell/word_binary.rst @@ -4,8 +4,6 @@ Binary operators ~~~~~~~~~~~~~~~~ -.. TODO:: display cell titles - All binary RTL cells have two input ports ``A`` and ``B`` and one output port ``Y``. They also have the following parameters: diff --git a/docs/util/cellref.py b/docs/util/cellref.py index 71e8eecd1c8..58e65c2eaea 100644 --- a/docs/util/cellref.py +++ b/docs/util/cellref.py @@ -305,15 +305,8 @@ def add_directive_header(self, sig: str) -> None: val = ' '.join(val) if val: self.add_line(f' :{attr}: {val}', sourcename) - - self.add_line('\n', sourcename) - # fields - field_attrs = ["properties", ] - for field in field_attrs: - attr = getattr(cell, field, []) - for val in attr: - self.add_line(f' :{field} {val}:', sourcename) + self.add_line('\n', sourcename) if self.options.noindex: self.add_line(' :noindex:', sourcename) @@ -331,6 +324,14 @@ def add_content(self, more_content: Any | None) -> None: for line, src in zip(more_content.data, more_content.items): self.add_line(line, src[0], src[1]) + # fields + self.add_line('\n', sourcename) + field_attrs = ["properties", ] + for field in field_attrs: + attr = getattr(self.object, field, []) + for val in attr: + self.add_line(f':{field} {val}:', sourcename) + def get_object_members( self, want_all: bool diff --git a/docs/util/cmdref.py b/docs/util/cmdref.py index c177fdfa6b0..a31b08e0d51 100644 --- a/docs/util/cmdref.py +++ b/docs/util/cmdref.py @@ -209,6 +209,14 @@ def add_target_and_index( self.env.docname, idx, 0)) + + def transform_content(self, contentnode: addnodes.desc_content) -> None: + # Add the cell title to the body + if 'title' in self.options: + titlenode = nodes.paragraph() + titlenode += nodes.strong() + titlenode[-1] += nodes.Text(self.options['title']) + contentnode.insert(0, titlenode) class CellSourceNode(TocNode): """A custom code block for including cell source.""" From dfe803b5c6921a56cbc80c1255c772d7d80d4f8e Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Mon, 16 Sep 2024 20:38:37 +1200 Subject: [PATCH 63/68] Docs: Comments from @jix - Unswap shift/shiftx - Add brief overview to cell lib - Clarify $div cell B input - Clarify unary operators - What is $modfloor --- docs/source/cell/properties.rst | 3 ++- docs/source/cell/word_binary.rst | 4 ++-- docs/source/cell/word_unary.rst | 10 +++++----- docs/source/cell_index.rst | 6 +++++- techlibs/common/simlib.v | 12 ++++++------ 5 files changed, 20 insertions(+), 15 deletions(-) diff --git a/docs/source/cell/properties.rst b/docs/source/cell/properties.rst index e853ea50a16..30c58ee51f2 100644 --- a/docs/source/cell/properties.rst +++ b/docs/source/cell/properties.rst @@ -15,6 +15,7 @@ Cell properties .. cell:defprop:: x-output These cells can produce 'x' output even if all inputs are defined. For - example, a `$div` cell with ``B=0`` has undefined output. + example, a `$div` cell with divisor (``B``) equal to zero has undefined + output. Refer to the :ref:`propindex` for the list of cells with a given property. diff --git a/docs/source/cell/word_binary.rst b/docs/source/cell/word_binary.rst index 47a847ee446..5e1e6cd1972 100644 --- a/docs/source/cell/word_binary.rst +++ b/docs/source/cell/word_binary.rst @@ -66,8 +66,8 @@ Division and modulo cells are available in two rounding modes. The original `$div` and `$mod` cells are based on truncating division, and correspond to the semantics of the verilog ``/`` and ``%`` operators. The `$divfloor` and `$modfloor` cells represent flooring division and flooring modulo, the latter of -which is also known as "remainder" in several languages. See the following table -for a side-by-side comparison between the different semantics. +which corresponds to the ``%`` operator in Python. See the following table for a +side-by-side comparison between the different semantics. .. table:: Comparison between different rounding modes for division and modulo cells. diff --git a/docs/source/cell/word_unary.rst b/docs/source/cell/word_unary.rst index 59f03397c83..1243ef60cea 100644 --- a/docs/source/cell/word_unary.rst +++ b/docs/source/cell/word_unary.rst @@ -38,11 +38,11 @@ For the unary cells that output a logical value (`$reduce_and`, `$reduce_or`, ``Y_WIDTH`` parameter is greater than 1, the output is zero-extended, and only the least significant bit varies. -Note that `$reduce_or` and `$reduce_bool` actually represent the same logic -function. But the HDL frontends generate them in different situations. A -`$reduce_or` cell is generated when the prefix ``|`` operator is being used. A -`$reduce_bool` cell is generated when a bit vector is used as a condition in an -``if``-statement or ``?:``-expression. +Note that `$reduce_or` and `$reduce_bool` generally represent the same logic +function. But the `read_verilog` frontend will generate them in different +situations. A `$reduce_or` cell is generated when the prefix ``|`` operator is +being used. A `$reduce_bool` cell is generated when a bit vector is used as a +condition in an ``if``-statement or ``?:``-expression. .. autocellgroup:: unary :members: diff --git a/docs/source/cell_index.rst b/docs/source/cell_index.rst index dcfd38a7613..2d64db95e9e 100644 --- a/docs/source/cell_index.rst +++ b/docs/source/cell_index.rst @@ -1,7 +1,11 @@ Internal cell library ===================== -.. todo:: brief overview of internal cell library +The intermediate language used by Yosys (RTLIL) represents logic and memory with +a series of cells. This section provides details for those cells, breaking them +down into two major categories: coarse-grain word-level cells; and fine-grain +gate-level cells. An additional section contains a list of properties which may +be shared across multiple cells. .. toctree:: :maxdepth: 2 diff --git a/techlibs/common/simlib.v b/techlibs/common/simlib.v index 6da22dac07d..19cb2f7a11d 100644 --- a/techlibs/common/simlib.v +++ b/techlibs/common/simlib.v @@ -528,10 +528,10 @@ endmodule // -------------------------------------------------------- //* ver 2 -//* title Indexed part-select +//* title Variable shifter //* group binary -//* tags x-output -//- Same as the `$shift` cell, but fills with 'x'. +//- Performs a right logical shift if the second operand is positive (or +//- unsigned), and a left logical shift if it is negative. //- module \$shift (A, B, Y); @@ -567,10 +567,10 @@ endmodule // -------------------------------------------------------- //* ver 2 -//* title Variable shifter +//* title Indexed part-select //* group binary -//- Performs a right logical shift if the second operand is positive (or -//- unsigned), and a left logical shift if it is negative. +//* tags x-output +//- Same as the `$shift` cell, but fills with 'x'. //- module \$shiftx (A, B, Y); From 1513366f215536c8e8376e6160ec4393c0223648 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Tue, 15 Oct 2024 07:11:56 +1300 Subject: [PATCH 64/68] Docs: Adding mux cell descriptions Also making ver2 cell descriptions consistently spaced. --- techlibs/common/simlib.v | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/techlibs/common/simlib.v b/techlibs/common/simlib.v index 19cb2f7a11d..3c429d757a4 100644 --- a/techlibs/common/simlib.v +++ b/techlibs/common/simlib.v @@ -32,7 +32,6 @@ */ // -------------------------------------------------------- - //* ver 2 //* title Bit-wise inverter //* group unary @@ -526,14 +525,12 @@ endgenerate endmodule // -------------------------------------------------------- - //* ver 2 //* title Variable shifter //* group binary //- Performs a right logical shift if the second operand is positive (or //- unsigned), and a left logical shift if it is negative. //- - module \$shift (A, B, Y); parameter A_SIGNED = 0; @@ -565,14 +562,12 @@ endgenerate endmodule // -------------------------------------------------------- - //* ver 2 //* title Indexed part-select //* group binary //* tags x-output //- Same as the `$shift` cell, but fills with 'x'. //- - module \$shiftx (A, B, Y); parameter A_SIGNED = 0; @@ -649,7 +644,6 @@ end endmodule // -------------------------------------------------------- - //* ver 2 //* title Arithmetic logic unit //* group arith @@ -839,7 +833,6 @@ endgenerate endmodule // -------------------------------------------------------- - //* ver 2 //* title Case equality //* group binary @@ -873,7 +866,6 @@ endgenerate endmodule // -------------------------------------------------------- - //* ver 2 //* title Case inequality //* group binary @@ -1215,7 +1207,6 @@ end endmodule // -------------------------------------------------------- - //* ver 2 //* title Divider //* group binary @@ -1246,7 +1237,6 @@ endgenerate endmodule // -------------------------------------------------------- - //* ver 2 //* title Modulo //* group binary @@ -1544,8 +1534,12 @@ assign Y = S ? B : A; endmodule // -------------------------------------------------------- +//* ver 2 +//* title Binary-encoded multiplexer //* group mux - +//- Selects between 'slices' of A where each value of S corresponds to a unique +//- slice. +//- module \$bmux (A, S, Y); parameter WIDTH = 0; @@ -1572,9 +1566,13 @@ endgenerate endmodule // -------------------------------------------------------- +//* ver 2 +//* title Priority-encoded multiplexer //* group mux //* tags x-output - +//- Selects between 'slices' of B where each slice corresponds to a single bit +//- of S. Outputs A when all bits of S are low. +//- module \$pmux (A, B, S, Y); parameter WIDTH = 0; @@ -1881,7 +1879,6 @@ endspecify endmodule // -------------------------------------------------------- - //* ver 2 //* title Bit-wise case equality //* group binary @@ -1905,7 +1902,11 @@ endgenerate endmodule // -------------------------------------------------------- +//* ver 2 +//* title Bit-wise multiplexer //* group mux +//- Equivalent to a series of 1-bit wide `$mux` cells. +//- module \$bwmux (A, B, S, Y); parameter WIDTH = 0; From 27b8b4e81e169cc008ed16c1390790b19a883420 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Tue, 15 Oct 2024 11:08:30 +1300 Subject: [PATCH 65/68] Docs: Fix missing groups $lut and $sop were missed in the rebase, and $buf is new to main since the last rebase. --- techlibs/common/simlib.v | 3 +++ 1 file changed, 3 insertions(+) diff --git a/techlibs/common/simlib.v b/techlibs/common/simlib.v index 3c429d757a4..df9e1feb1e4 100644 --- a/techlibs/common/simlib.v +++ b/techlibs/common/simlib.v @@ -89,6 +89,7 @@ endmodule // |---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---|---v---| //- //- $buf (A, Y) +//* group unary //- //- A simple coarse-grain buffer cell type for the experimental buffered-normalized //- mode. Note this cell does't get removed by 'opt_clean' and is not recommended @@ -1635,6 +1636,7 @@ endmodule // -------------------------------------------------------- `ifndef SIMLIB_NOLUT +//* group logic module \$lut (A, Y); @@ -1650,6 +1652,7 @@ endmodule `endif // -------------------------------------------------------- +//* group logic module \$sop (A, Y); From c93fd54e43e5628e5a02c1fc0943515ab59bb287 Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Tue, 15 Oct 2024 11:37:52 +1300 Subject: [PATCH 66/68] ci: Install docs/reqs (namely, furo-ys) --- .github/workflows/prepare-docs.yml | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/.github/workflows/prepare-docs.yml b/.github/workflows/prepare-docs.yml index e0388c7a35a..79dfb7912c4 100644 --- a/.github/workflows/prepare-docs.yml +++ b/.github/workflows/prepare-docs.yml @@ -64,6 +64,11 @@ jobs: docs/source/_images docs/source/code_examples + - name: Install doc prereqs + shell: bash + run: | + make docs/reqs + - name: Test build docs shell: bash run: | From bc77575c224d1f7d61474216416f66f75e5f175f Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Tue, 15 Oct 2024 11:46:21 +1300 Subject: [PATCH 67/68] Docs: Fix word_logic.rst It somehow got lost in the rebase. --- docs/source/cell/index_word.rst | 1 + docs/source/cell/word_arith.rst | 45 -------------------------------- docs/source/cell/word_logic.rst | 46 +++++++++++++++++++++++++++++++++ 3 files changed, 47 insertions(+), 45 deletions(-) create mode 100644 docs/source/cell/word_logic.rst diff --git a/docs/source/cell/index_word.rst b/docs/source/cell/index_word.rst index cb81c69916b..409e20d2637 100644 --- a/docs/source/cell/index_word.rst +++ b/docs/source/cell/index_word.rst @@ -23,6 +23,7 @@ Simulation models for the RTL cells can be found in the file /cell/word_mem /cell/word_fsm /cell/word_arith + /cell/word_logic /cell/word_spec /cell/word_formal /cell/word_debug diff --git a/docs/source/cell/word_arith.rst b/docs/source/cell/word_arith.rst index eb1bfdada49..49070814add 100644 --- a/docs/source/cell/word_arith.rst +++ b/docs/source/cell/word_arith.rst @@ -3,9 +3,6 @@ Coarse arithmetics .. todo:: Add information about `$alu`, `$fa`, and `$lcu` cells. -Multiply-accumulate -~~~~~~~~~~~~~~~~~~~ - The `$macc` cell type represents a generalized multiply and accumulate operation. The cell is purely combinational. It outputs the result of summing up a sequence of products and other injected summands. @@ -47,48 +44,6 @@ CONFIG parameter carries the following information: B is an array of concatenated 1-bit-wide unsigned integers to also be summed up. -Arbitrary logic functions -~~~~~~~~~~~~~~~~~~~~~~~~~ - -The `$lut` cell type implements a single-output LUT (lookup table). It -implements an arbitrary logic function with its ``\LUT`` parameter to map input -port ``\A`` to values of ``\Y`` output port values. In psuedocode: ``Y = -\LUT[A]``. ``\A`` has width set by parameter ``\WIDTH`` and ``\Y`` has a width -of 1. Every logic function with a single bit output has a unique `$lut` -representation. - -The `$sop` cell type implements a sum-of-products expression, also known as -disjunctive normal form (DNF). It implements an arbitrary logic function. Its -structure mimics a programmable logic array (PLA). Output port ``\Y`` is the sum -of products of the bits of the input port ``\A`` as defined by parameter -``\TABLE``. ``\A`` is ``\WIDTH`` bits wide. The number of products in the sum is -set by parameter ``\DEPTH``, and each product has two bits for each input bit - -for the presence of the unnegated and negated version of said input bit in the -product. Therefore the ``\TABLE`` parameter holds ``2 * \WIDTH * \DEPTH`` bits. - -For example: - -Let ``\WIDTH`` be 3. We would like to represent ``\Y =~\A[0] + \A[1]~\A[2]``. -There are 2 products to be summed, so ``\DEPTH`` shall be 2. - -.. code-block:: - - ~A[2]-----+ - A[2]----+| - ~A[1]---+|| - A[1]--+||| - ~A[0]-+|||| - A[0]+||||| - |||||| product formula - 010000 ~\A[0] - 001001 \A[1]~\A[2] - -So the value of ``\TABLE`` will become ``010000001001``. - -Any logic function with a single bit output can be represented with ``$sop`` but -may have variously minimized or ordered summands represented in the ``\TABLE`` -values. - .. autocellgroup:: arith :members: :source: diff --git a/docs/source/cell/word_logic.rst b/docs/source/cell/word_logic.rst new file mode 100644 index 00000000000..32945d560a0 --- /dev/null +++ b/docs/source/cell/word_logic.rst @@ -0,0 +1,46 @@ +Arbitrary logic functions +------------------------- + +The `$lut` cell type implements a single-output LUT (lookup table). It +implements an arbitrary logic function with its ``\LUT`` parameter to map input +port ``\A`` to values of ``\Y`` output port values. In psuedocode: ``Y = +\LUT[A]``. ``\A`` has width set by parameter ``\WIDTH`` and ``\Y`` has a width +of 1. Every logic function with a single bit output has a unique `$lut` +representation. + +The `$sop` cell type implements a sum-of-products expression, also known as +disjunctive normal form (DNF). It implements an arbitrary logic function. Its +structure mimics a programmable logic array (PLA). Output port ``\Y`` is the sum +of products of the bits of the input port ``\A`` as defined by parameter +``\TABLE``. ``\A`` is ``\WIDTH`` bits wide. The number of products in the sum is +set by parameter ``\DEPTH``, and each product has two bits for each input bit - +for the presence of the unnegated and negated version of said input bit in the +product. Therefore the ``\TABLE`` parameter holds ``2 * \WIDTH * \DEPTH`` bits. + +For example: + +Let ``\WIDTH`` be 3. We would like to represent ``\Y =~\A[0] + \A[1]~\A[2]``. +There are 2 products to be summed, so ``\DEPTH`` shall be 2. + +.. code-block:: + + ~A[2]-----+ + A[2]----+| + ~A[1]---+|| + A[1]--+||| + ~A[0]-+|||| + A[0]+||||| + |||||| product formula + 010000 ~\A[0] + 001001 \A[1]~\A[2] + +So the value of ``\TABLE`` will become ``010000001001``. + +Any logic function with a single bit output can be represented with ``$sop`` but +may have variously minimized or ordered summands represented in the ``\TABLE`` +values. + +.. autocellgroup:: logic + :members: + :source: + :linenos: \ No newline at end of file From e9d9e92804897d3c1cffadd1d626c5af322da3cd Mon Sep 17 00:00:00 2001 From: Krystine Sherwin <93062060+KrystalDelusion@users.noreply.github.com> Date: Thu, 17 Oct 2024 04:40:21 +1300 Subject: [PATCH 68/68] Docs: Make code_examples/extensions parallel safe --- docs/source/code_examples/extensions/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/source/code_examples/extensions/Makefile b/docs/source/code_examples/extensions/Makefile index 2e621d70bcb..74b547a20aa 100644 --- a/docs/source/code_examples/extensions/Makefile +++ b/docs/source/code_examples/extensions/Makefile @@ -4,8 +4,8 @@ YOSYS ?= ../../../../$(PROGRAM_PREFIX)yosys .PHONY: all dots examples all: dots examples -dots: test1.dot -examples: test0.log test1.log test2.log +dots: test1.dot my_cmd.so +examples: test0.log test1.log test2.log my_cmd.so CXXFLAGS=$(shell $(YOSYS)-config --cxxflags) DATDIR=$(shell $(YOSYS)-config --datdir)