mirror of
https://github.com/YosysHQ/yosys
synced 2026-07-15 19:55:41 +00:00
Merge remote-tracking branch 'upstream/main' into silimate
This commit is contained in:
Mohamed Gaber
commit
e58125b605
834 changed files with 25281 additions and 8780 deletions
|
|
@ -32,19 +32,20 @@ FORCE:
|
|||
TEX_FILES := $(shell find . -name *.tex)
|
||||
all_tex: $(TEX_FILES:.tex=.pdf) $(TEX_FILES:.tex=.svg)
|
||||
|
||||
# limit output size to US letter (same as latexpdf output) to avoid oversize error
|
||||
%.pdf: %.dot
|
||||
$(FAKETIME) dot -Tpdf -o $@ $<
|
||||
@$(FAKETIME) dot -Tpdf -Gsize="8.5,11" -o $@ $< >/dev/null 2>&1
|
||||
|
||||
%.pdf: %.tex
|
||||
cd $(@D) && $(FAKETIME) pdflatex $(<F) --interaction=nonstopmode
|
||||
@cd $(@D) && $(FAKETIME) pdflatex $(<F) --interaction=nonstopmode >/dev/null 2>&1
|
||||
|
||||
%.svg: %.pdf
|
||||
pdf2svg $< $@
|
||||
@pdf2svg $< $@ >/dev/null 2>&1
|
||||
|
||||
.PHONY: clean tidy
|
||||
tidy:
|
||||
rm -f **/*.log **/*.aux
|
||||
@rm -f **/*.log **/*.aux
|
||||
|
||||
clean: tidy
|
||||
rm -rf code_examples
|
||||
rm -f **/*.pdf **/*.svg
|
||||
@rm -rf code_examples
|
||||
@rm -f **/*.pdf **/*.svg
|
||||
|
|
|
|||
|
|
@ -14,8 +14,9 @@ Yosys environment variables
|
|||
Used for storing temporary files.
|
||||
|
||||
``ABC``
|
||||
When compiling Yosys with out-of-tree ABC using :makevar:`ABCEXTERNAL`, this
|
||||
variable can be used to override the external ABC executable.
|
||||
When compiling Yosys with out-of-tree ABC using
|
||||
:makevar:`YOSYS_ABC_EXECUTABLE`, this variable can be used to override the
|
||||
external ABC executable.
|
||||
|
||||
``YOSYS_NOVERIFIC``
|
||||
If Yosys was built with Verific, this environment variable can be used to
|
||||
|
|
|
|||
|
|
@ -154,6 +154,10 @@ 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.
|
||||
|
||||
When both set and reset are active, the state and output is undefined. The Verilog
|
||||
code model does not correspond to this due to limitations
|
||||
of synthesizable Verilog.
|
||||
|
||||
.. code-block:: verilog
|
||||
:force:
|
||||
|
||||
|
|
@ -187,6 +191,10 @@ 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.
|
||||
|
||||
When both set and reset are active, the state and output is undefined. The Verilog
|
||||
code model does not correspond to this due to limitations
|
||||
of synthesizable Verilog.
|
||||
|
||||
.. code-block:: verilog
|
||||
:force:
|
||||
|
||||
|
|
|
|||
|
|
@ -78,6 +78,7 @@ 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.
|
||||
When both set and reset are active, the state and output is undefined.
|
||||
|
||||
D-type flip-flops with enable are represented by `$dffe`, `$adffe`, `$aldffe`,
|
||||
`$dffsre`, `$sdffe`, and `$sdffce` cells, which are enhanced variants of `$dff`,
|
||||
|
|
|
|||
|
|
@ -1,33 +1,28 @@
|
|||
PROGRAM_PREFIX :=
|
||||
|
||||
YOSYS ?= ../../../../$(PROGRAM_PREFIX)yosys
|
||||
include ../../../common.mk
|
||||
|
||||
.PHONY: all dots examples
|
||||
all: dots examples
|
||||
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)
|
||||
|
||||
my_cmd.so: my_cmd.cc
|
||||
$(YOSYS)-config --exec --cxx $(subst $(DATDIR),../../../../share,$(CXXFLAGS)) --ldflags -o my_cmd.so -shared my_cmd.cc --ldlibs
|
||||
@$(YOSYS_CONFIG) --exec --cxx --cxxflags --ldflags -o my_cmd.so -shared my_cmd.cc --ldlibs
|
||||
|
||||
test0.log: my_cmd.so
|
||||
$(YOSYS) -QTl test0.log_new -m ./my_cmd.so -p 'my_cmd foo bar' -f verilog absval_ref.v
|
||||
mv test0.log_new test0.log
|
||||
@$(YOSYS) -QTl test0.log_new -m ./my_cmd.so -p 'my_cmd foo bar' -f verilog absval_ref.v >/dev/null 2>&1
|
||||
@mv test0.log_new test0.log
|
||||
|
||||
test1.log: my_cmd.so
|
||||
$(YOSYS) -QTl test1.log_new -m ./my_cmd.so -p 'clean; test1; dump' -f verilog absval_ref.v
|
||||
mv test1.log_new test1.log
|
||||
@$(YOSYS) -QTl test1.log_new -m ./my_cmd.so -p 'clean; test1; dump' -f verilog absval_ref.v >/dev/null 2>&1
|
||||
@mv test1.log_new test1.log
|
||||
|
||||
test1.dot: my_cmd.so
|
||||
$(YOSYS) -m ./my_cmd.so -p 'test1; show -format dot -prefix test1'
|
||||
@$(YOSYS) -m ./my_cmd.so -p 'test1; show -format dot -prefix test1' >/dev/null 2>&1
|
||||
|
||||
test2.log: my_cmd.so
|
||||
$(YOSYS) -QTl test2.log_new -m ./my_cmd.so -p 'hierarchy -top test; test2' -f verilog sigmap_test.v
|
||||
mv test2.log_new test2.log
|
||||
@$(YOSYS) -QTl test2.log_new -m ./my_cmd.so -p 'hierarchy -top test; test2' -f verilog sigmap_test.v >/dev/null 2>&1
|
||||
@mv test2.log_new test2.log
|
||||
|
||||
.PHONY: clean
|
||||
clean:
|
||||
rm -f *.d *.so *.dot
|
||||
@rm -f *.d *.so *.dot
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ struct MyPass : public Pass {
|
|||
|
||||
log("Modules in current design:\n");
|
||||
for (auto mod : design->modules())
|
||||
log(" %s (%d wires, %d cells)\n", log_id(mod),
|
||||
log(" %s (%d wires, %d cells)\n", mod,
|
||||
GetSize(mod->wires()), GetSize(mod->cells()));
|
||||
}
|
||||
} MyPass;
|
||||
|
|
@ -28,7 +28,7 @@ struct Test1Pass : public Pass {
|
|||
log_error("A module with the name absval already exists!\n");
|
||||
|
||||
RTLIL::Module *module = design->addModule("\\absval");
|
||||
log("Name of this module: %s\n", log_id(module));
|
||||
log("Name of this module: %s\n", module);
|
||||
|
||||
RTLIL::Wire *a = module->addWire("\\a", 4);
|
||||
a->port_input = true;
|
||||
|
|
|
|||
|
|
@ -1,6 +1,4 @@
|
|||
PROGRAM_PREFIX :=
|
||||
|
||||
YOSYS ?= ../../../../$(PROGRAM_PREFIX)yosys
|
||||
include ../../../common.mk
|
||||
|
||||
DOT_NAMES = addr_gen_hier addr_gen_proc addr_gen_clean
|
||||
DOT_NAMES += rdata_proc rdata_flat rdata_adffe rdata_memrdv2 rdata_alumacc rdata_coarse
|
||||
|
|
@ -16,12 +14,12 @@ dots: $(DOTS) $(MAPDOTS)
|
|||
examples: fifo.out fifo.stat
|
||||
|
||||
$(DOTS) fifo.out: fifo.v fifo.ys
|
||||
$(YOSYS) fifo.ys -l fifo.out -Q -T
|
||||
@$(YOSYS) fifo.ys -l fifo.out -Q -T >/dev/null 2>&1
|
||||
|
||||
$(MAPDOTS) fifo.stat: fifo.v fifo_map.ys
|
||||
$(YOSYS) fifo_map.ys
|
||||
@$(YOSYS) fifo_map.ys >/dev/null 2>&1
|
||||
|
||||
.PHONY: clean
|
||||
clean:
|
||||
rm -f *.dot
|
||||
rm -f fifo.out fifo.stat
|
||||
@rm -f *.dot
|
||||
@rm -f fifo.out fifo.stat
|
||||
|
|
|
|||
|
|
@ -24,19 +24,19 @@ struct FunctionalDummyBackend : public Backend {
|
|||
|
||||
// write node functions
|
||||
for (auto node : ir)
|
||||
*f << " assign " << id2cstr(node.name())
|
||||
*f << " assign " << node.name().unescape()
|
||||
<< " = " << node.to_string() << "\n";
|
||||
*f << "\n";
|
||||
|
||||
// write outputs and next state
|
||||
for (auto output : ir.outputs())
|
||||
*f << " " << id2cstr(output->kind)
|
||||
<< " " << id2cstr(output->name)
|
||||
<< " = " << id2cstr(output->value().name()) << "\n";
|
||||
*f << " " << output->kind.unescape()
|
||||
<< " " << output->name.unescape()
|
||||
<< " = " << output->value().name().unescape() << "\n";
|
||||
for (auto state : ir.states())
|
||||
*f << " " << id2cstr(state->kind)
|
||||
<< " " << id2cstr(state->name)
|
||||
<< " = " << id2cstr(state->next_value().name()) << "\n";
|
||||
*f << " " << state->kind.unescape()
|
||||
<< " " << state->name.unescape()
|
||||
<< " = " << state->next_value().name().unescape() << "\n";
|
||||
}
|
||||
}
|
||||
} FunctionalDummyBackend;
|
||||
|
|
|
|||
|
|
@ -1,6 +1,4 @@
|
|||
PROGRAM_PREFIX :=
|
||||
|
||||
YOSYS ?= ../../../../$(PROGRAM_PREFIX)yosys
|
||||
include ../../../common.mk
|
||||
|
||||
DOTS = counter_00.dot counter_01.dot counter_02.dot counter_03.dot
|
||||
|
||||
|
|
@ -10,8 +8,8 @@ dots: $(DOTS)
|
|||
examples:
|
||||
|
||||
$(DOTS): counter.v counter.ys mycells.lib
|
||||
$(YOSYS) counter.ys
|
||||
@$(YOSYS) counter.ys >/dev/null 2>&1
|
||||
|
||||
.PHONY: clean
|
||||
clean:
|
||||
rm -f *.dot
|
||||
@rm -f *.dot
|
||||
|
|
|
|||
|
|
@ -1,6 +1,4 @@
|
|||
PROGRAM_PREFIX :=
|
||||
|
||||
YOSYS ?= ../../../../$(PROGRAM_PREFIX)yosys
|
||||
include ../../../common.mk
|
||||
|
||||
DOTS = macc_simple_xmap.dot macc_xilinx_xmap.dot
|
||||
|
||||
|
|
@ -10,12 +8,12 @@ dots: $(DOTS)
|
|||
examples:
|
||||
|
||||
macc_simple_xmap.dot: macc_simple_*.v macc_simple_test.ys
|
||||
$(YOSYS) macc_simple_test.ys
|
||||
@$(YOSYS) macc_simple_test.ys >/dev/null 2>&1
|
||||
|
||||
macc_xilinx_xmap.dot: macc_xilinx_*.v macc_xilinx_test.ys
|
||||
$(YOSYS) macc_xilinx_test.ys
|
||||
@$(YOSYS) macc_xilinx_test.ys >/dev/null 2>&1
|
||||
|
||||
.PHONY: clean
|
||||
clean:
|
||||
rm -f *.dot
|
||||
@rm -f *.dot
|
||||
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ begin:
|
|||
proc
|
||||
|
||||
flatten:
|
||||
check
|
||||
flatten
|
||||
tribuf -logic
|
||||
deminout
|
||||
|
|
|
|||
|
|
@ -1,6 +1,4 @@
|
|||
PROGRAM_PREFIX :=
|
||||
|
||||
YOSYS ?= ../../../../$(PROGRAM_PREFIX)yosys
|
||||
include ../../../common.mk
|
||||
|
||||
DOT_NAMES = opt_share opt_muxtree opt_merge opt_expr
|
||||
|
||||
|
|
@ -12,9 +10,9 @@ dots: $(DOTS)
|
|||
examples:
|
||||
|
||||
%.dot: %.ys
|
||||
$(YOSYS) $<
|
||||
gvpack -u -o $@ $*_full.dot
|
||||
@$(YOSYS) $< >/dev/null 2>&1
|
||||
@gvpack -u -o $@ $*_full.dot >/dev/null 2>&1
|
||||
|
||||
.PHONY: clean
|
||||
clean:
|
||||
rm -f *.dot
|
||||
@rm -f *.dot
|
||||
|
|
|
|||
|
|
@ -1,6 +1,4 @@
|
|||
PROGRAM_PREFIX :=
|
||||
|
||||
YOSYS ?= ../../../../$(PROGRAM_PREFIX)yosys
|
||||
include ../../../common.mk
|
||||
|
||||
.PHONY: all dots examples
|
||||
all: dots examples
|
||||
|
|
@ -8,8 +6,8 @@ dots: scrambler_p01.dot scrambler_p02.dot
|
|||
examples:
|
||||
|
||||
scrambler_p01.dot scrambler_p02.dot: scrambler.ys scrambler.v
|
||||
$(YOSYS) scrambler.ys
|
||||
@$(YOSYS) scrambler.ys >/dev/null 2>&1
|
||||
|
||||
.PHONY: clean
|
||||
clean:
|
||||
rm -f *.dot
|
||||
@rm -f *.dot
|
||||
|
|
|
|||
|
|
@ -1,6 +1,4 @@
|
|||
PROGRAM_PREFIX :=
|
||||
|
||||
YOSYS ?= ../../../../$(PROGRAM_PREFIX)yosys
|
||||
include ../../../common.mk
|
||||
|
||||
SUMPROD = sumprod_00 sumprod_01 sumprod_02 sumprod_03 sumprod_04 sumprod_05
|
||||
SUMPROD_DOTS := $(addsuffix .dot,$(SUMPROD))
|
||||
|
|
@ -17,18 +15,18 @@ dots: select.dot $(SUMPROD_DOTS) $(MEMDEMO_DOTS) $(SUBMOD_DOTS)
|
|||
examples: sumprod.out
|
||||
|
||||
select.dot: select.v select.ys
|
||||
$(YOSYS) select.ys
|
||||
@$(YOSYS) select.ys >/dev/null 2>&1
|
||||
|
||||
$(SUMPROD_DOTS) sumprod.out: sumprod.v sumprod.ys
|
||||
$(YOSYS) sumprod.ys
|
||||
@$(YOSYS) sumprod.ys >/dev/null 2>&1
|
||||
|
||||
$(MEMDEMO_DOTS): memdemo.v memdemo.ys
|
||||
$(YOSYS) memdemo.ys
|
||||
@$(YOSYS) memdemo.ys >/dev/null 2>&1
|
||||
|
||||
$(SUBMOD_DOTS): memdemo.v submod.ys
|
||||
$(YOSYS) submod.ys
|
||||
@$(YOSYS) submod.ys >/dev/null 2>&1
|
||||
|
||||
.PHONY: clean
|
||||
clean:
|
||||
rm -rf *.dot
|
||||
rm -f sumprod.out
|
||||
@rm -rf *.dot
|
||||
@rm -f sumprod.out
|
||||
|
|
|
|||
|
|
@ -1,6 +1,4 @@
|
|||
PROGRAM_PREFIX :=
|
||||
|
||||
YOSYS ?= ../../../../$(PROGRAM_PREFIX)yosys
|
||||
include ../../../common.mk
|
||||
|
||||
EXAMPLE = example_first example_second example_third
|
||||
EXAMPLE_DOTS := $(addsuffix .dot,$(EXAMPLE))
|
||||
|
|
@ -14,18 +12,18 @@ dots: splice.dot $(EXAMPLE_DOTS) $(CMOS_DOTS)
|
|||
examples: example.out
|
||||
|
||||
splice.dot: splice.v
|
||||
$(YOSYS) -p 'prep -top splice_demo; show -format dot -prefix splice' splice.v
|
||||
@$(YOSYS) -p 'prep -top splice_demo; show -format dot -prefix splice' splice.v >/dev/null 2>&1
|
||||
|
||||
$(EXAMPLE_DOTS): example.v example.ys
|
||||
$(YOSYS) example.ys
|
||||
@$(YOSYS) example.ys >/dev/null 2>&1
|
||||
|
||||
example.out: example_lscd.ys example.v
|
||||
$(YOSYS) $< -l $@ -Q -T
|
||||
@$(YOSYS) $< -l $@ -Q -T >/dev/null 2>&1
|
||||
|
||||
$(CMOS_DOTS): cmos.v cmos.ys
|
||||
$(YOSYS) cmos.ys
|
||||
@$(YOSYS) cmos.ys >/dev/null 2>&1
|
||||
|
||||
.PHONY: clean
|
||||
clean:
|
||||
rm -rf *.dot
|
||||
rm -f example.out
|
||||
@rm -rf *.dot
|
||||
@rm -f example.out
|
||||
|
|
|
|||
|
|
@ -1,19 +1,20 @@
|
|||
include ../../../common.mk
|
||||
|
||||
.PHONY: all dots examples
|
||||
all: dots examples
|
||||
dots:
|
||||
examples:
|
||||
examples: test
|
||||
|
||||
.PHONY: test
|
||||
test: stubnets.so
|
||||
yosys -ql test1.log -m ./stubnets.so test.v -p "stubnets"
|
||||
yosys -ql test2.log -m ./stubnets.so test.v -p "opt; stubnets"
|
||||
yosys -ql test3.log -m ./stubnets.so test.v -p "techmap; opt; stubnets -report_bits"
|
||||
tail test1.log test2.log test3.log
|
||||
@$(YOSYS) -ql test1.log -m ./stubnets.so test.v -p "stubnets" >/dev/null 2>&1
|
||||
@$(YOSYS) -ql test2.log -m ./stubnets.so test.v -p "opt; stubnets" >/dev/null 2>&1
|
||||
@$(YOSYS) -ql test3.log -m ./stubnets.so test.v -p "techmap; opt; stubnets -report_bits" >/dev/null 2>&1
|
||||
|
||||
stubnets.so: stubnets.cc
|
||||
yosys-config --exec --cxx --cxxflags --ldflags -o $@ -shared $^ --ldlibs
|
||||
@$(YOSYS_CONFIG) --exec --cxx --cxxflags --ldflags -o $@ -shared $^ --ldlibs >/dev/null 2>&1
|
||||
|
||||
.PHONY: clean
|
||||
clean:
|
||||
rm -f test1.log test2.log test3.log
|
||||
rm -f stubnets.so stubnets.d
|
||||
@rm -f test1.log test2.log test3.log
|
||||
@rm -f stubnets.so stubnets.d
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ static void find_stub_nets(RTLIL::Design *design, RTLIL::Module *module, bool re
|
|||
// count output lines for this module (needed only for summary output at the end)
|
||||
int line_count = 0;
|
||||
|
||||
log("Looking for stub wires in module %s:\n", RTLIL::id2cstr(module->name));
|
||||
log("Looking for stub wires in module %s:\n", module);
|
||||
|
||||
// For all ports on all cells
|
||||
for (auto &cell_iter : module->cells_)
|
||||
|
|
@ -74,11 +74,11 @@ static void find_stub_nets(RTLIL::Design *design, RTLIL::Module *module, bool re
|
|||
// report stub bits and/or stub wires, don't report single bits
|
||||
// if called with report_bits set to false.
|
||||
if (GetSize(stub_bits) == GetSize(sig)) {
|
||||
log(" found stub wire: %s\n", RTLIL::id2cstr(wire->name));
|
||||
log(" found stub wire: %s\n", wire);
|
||||
} else {
|
||||
if (!report_bits)
|
||||
continue;
|
||||
log(" found wire with stub bits: %s [", RTLIL::id2cstr(wire->name));
|
||||
log(" found wire with stub bits: %s [", wire);
|
||||
for (int bit : stub_bits)
|
||||
log("%s%d", bit == *stub_bits.begin() ? "" : ", ", bit);
|
||||
log("]\n");
|
||||
|
|
|
|||
|
|
@ -1,12 +1,9 @@
|
|||
include ../../../common.mk
|
||||
|
||||
DOT_TARGETS += proc_01 proc_02 proc_03
|
||||
DOT_TARGETS += memory_01 memory_02
|
||||
DOT_TARGETS += techmap_01
|
||||
|
||||
PROGRAM_PREFIX :=
|
||||
|
||||
YOSYS ?= ../../../../$(PROGRAM_PREFIX)yosys
|
||||
|
||||
DOTS = $(addsuffix .dot,$(DOT_TARGETS))
|
||||
|
||||
.PHONY: all dots examples
|
||||
|
|
@ -15,9 +12,9 @@ dots: $(DOTS)
|
|||
examples:
|
||||
|
||||
%.dot: %.v %.ys
|
||||
$(YOSYS) -p 'script $*.ys; show -notitle -prefix $* -format dot'
|
||||
@$(YOSYS) -p 'script $*.ys; show -notitle -prefix $* -format dot' >/dev/null 2>&1
|
||||
|
||||
.PHONY: clean
|
||||
clean:
|
||||
rm -f *.dot
|
||||
@rm -f *.dot
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,4 @@
|
|||
PROGRAM_PREFIX :=
|
||||
|
||||
YOSYS ?= ../../../../$(PROGRAM_PREFIX)yosys
|
||||
include ../../../common.mk
|
||||
|
||||
.PHONY: all dots examples
|
||||
all: dots examples
|
||||
|
|
@ -8,20 +6,20 @@ dots: red_or3x1.dot sym_mul.dot mymul.dot mulshift.dot addshift.dot
|
|||
examples:
|
||||
|
||||
red_or3x1.dot: red_or3x1_*
|
||||
$(YOSYS) red_or3x1_test.ys
|
||||
@$(YOSYS) red_or3x1_test.ys >/dev/null 2>&1
|
||||
|
||||
sym_mul.dot: sym_mul_*
|
||||
$(YOSYS) sym_mul_test.ys
|
||||
@$(YOSYS) sym_mul_test.ys >/dev/null 2>&1
|
||||
|
||||
mymul.dot: mymul_*
|
||||
$(YOSYS) mymul_test.ys
|
||||
@$(YOSYS) mymul_test.ys >/dev/null 2>&1
|
||||
|
||||
mulshift.dot: mulshift_*
|
||||
$(YOSYS) mulshift_test.ys
|
||||
@$(YOSYS) mulshift_test.ys >/dev/null 2>&1
|
||||
|
||||
addshift.dot: addshift_*
|
||||
$(YOSYS) addshift_test.ys
|
||||
@$(YOSYS) addshift_test.ys >/dev/null 2>&1
|
||||
|
||||
.PHONY: clean
|
||||
clean:
|
||||
rm -f *.dot
|
||||
@rm -f *.dot
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ import os
|
|||
project = 'YosysHQ Yosys'
|
||||
author = 'YosysHQ GmbH'
|
||||
copyright ='2026 YosysHQ GmbH'
|
||||
yosys_ver = "0.62"
|
||||
yosys_ver = "0.66"
|
||||
|
||||
# select HTML theme
|
||||
html_theme = 'furo-ys'
|
||||
|
|
|
|||
|
|
@ -291,7 +291,10 @@ In `synth_ice40` we get these:
|
|||
:name: synth_flatten
|
||||
:caption: ``flatten`` section
|
||||
|
||||
First off is `flatten`. Flattening the design like this can allow for
|
||||
We start by runnning `check`. This doesn't affect the design, but it can
|
||||
identify 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 `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.
|
||||
|
||||
|
|
@ -363,17 +366,14 @@ 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.
|
||||
|
||||
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:
|
||||
:cmd:title:`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.
|
||||
We've already come across `opt_expr` and `check`, and `opt_clean` is the same as
|
||||
`clean` but with more verbose output. 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: :cmd:title:`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.
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ clone these submodules at the same time, use e.g.:
|
|||
|
||||
As of Yosys v0.47, releases include a ``yosys.tar.gz`` file which includes
|
||||
all source code and all sub-modules in a single archive. This can be used as
|
||||
an alternative which does not rely on ``git``.
|
||||
an alternative which does not rely on :program:`git`.
|
||||
|
||||
Supported platforms
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
|
@ -87,11 +87,11 @@ not regularly tested:
|
|||
Build prerequisites
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
A C++ compiler with C++17 support is required as well as some standard tools
|
||||
such as GNU Flex, GNU Bison (>=3.8), Make, and Python (>=3.11). 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
|
||||
`show` command to display schematics.
|
||||
A C++ compiler with C++20 support is required as well as some standard tools
|
||||
such as GNU Flex, GNU Bison (>=3.8), CMake (>=3.27), Make (or other CMake
|
||||
generator such as Ninja), and Python (>=3.11). Some additional tools: readline,
|
||||
libffi, Tcl and zlib; will be used if available but are optional. Graphviz and
|
||||
Xdot are used by the `show` command to display schematics.
|
||||
|
||||
Installing all prerequisites:
|
||||
|
||||
|
|
@ -102,7 +102,15 @@ Installing all prerequisites:
|
|||
sudo apt-get install gawk git make python3 lld bison clang flex \
|
||||
libffi-dev libfl-dev libreadline-dev pkg-config tcl-dev zlib1g-dev \
|
||||
graphviz xdot
|
||||
curl -LsSf https://astral.sh/uv/install.sh | sh
|
||||
sudo snap install cmake --classic
|
||||
|
||||
.. tab:: Ubuntu 24.04
|
||||
|
||||
.. code:: console
|
||||
|
||||
sudo apt-get install gawk git cmake make python3 lld bison clang flex \
|
||||
libffi-dev libfl-dev libreadline-dev pkg-config tcl-dev zlib1g-dev \
|
||||
graphviz xdot
|
||||
|
||||
.. tab:: macOS 13 (with Homebrew)
|
||||
|
||||
|
|
@ -114,19 +122,16 @@ Installing all prerequisites:
|
|||
|
||||
.. code:: console
|
||||
|
||||
sudo port install bison flex readline gawk libffi graphviz \
|
||||
sudo port install bison cmake flex readline gawk libffi graphviz \
|
||||
pkgconfig python311 zlib tcl
|
||||
|
||||
.. tab:: FreeBSD
|
||||
|
||||
.. code:: console
|
||||
|
||||
pkg install bison flex readline gawk libffi graphviz \
|
||||
pkg install bison cmake-core flex readline gawk libffi graphviz \
|
||||
pkgconf python311 tcl-wrapper
|
||||
|
||||
.. note:: On FreeBSD system use gmake instead of make. To run tests use:
|
||||
``MAKE=gmake CXX=cxx CC=cc gmake test``
|
||||
|
||||
.. tab:: Cygwin
|
||||
|
||||
Use the following command to install all prerequisites, or select these
|
||||
|
|
@ -134,7 +139,7 @@ Installing all prerequisites:
|
|||
|
||||
.. code:: console
|
||||
|
||||
setup-x86_64.exe -q --packages=bison,flex,gcc-core,gcc-g++,git,libffi-devel,libreadline-devel,make,pkg-config,python3,tcl-devel,zlib-devel
|
||||
setup-x86_64.exe -q --packages=bison,flex,gcc-core,gcc-g++,git,libffi-devel,libreadline-devel,cmake,make,pkg-config,python3,tcl-devel,zlib-devel
|
||||
|
||||
.. warning::
|
||||
|
||||
|
|
@ -142,7 +147,7 @@ Installing all prerequisites:
|
|||
minimum required version of Python is 3.11. This means that Cygwin is not
|
||||
compatible with many of the Python-based frontends. While this does not
|
||||
currently prevent Yosys itself from working, no guarantees are made for
|
||||
continued support. You may also need to specify ``CXXSTD=gnu++17`` to
|
||||
continued support. You may also need to specify ``CXXSTD=gnu++20`` to
|
||||
resolve missing ``strdup`` function when using gcc. It is instead
|
||||
recommended to use Windows Subsystem for Linux (WSL) and follow the
|
||||
instructions for Ubuntu.
|
||||
|
|
@ -168,71 +173,86 @@ Installing all prerequisites:
|
|||
Build configuration
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The Yosys build is based solely on Makefiles, and uses a number of variables
|
||||
which influence the build process. The recommended method for configuring
|
||||
builds is with a ``Makefile.conf`` file in the root ``yosys`` directory. The
|
||||
following commands will clean the directory and provide an initial configuration
|
||||
file:
|
||||
The Yosys build is configured via CMake, and uses a number of variables which
|
||||
influence the build process. When setting one-off variables, CMake provides the
|
||||
``-D <var>=<value>`` command line option. For example, disabling zlib support:
|
||||
|
||||
.. code:: console
|
||||
|
||||
make config-clang # ..or..
|
||||
make config-gcc
|
||||
cmake -B build . -DYOSYS_WITHOUT_ZLIB=ON
|
||||
|
||||
Check the root Makefile to see what other configuration targets are available.
|
||||
Other variables can then be added to the ``Makefile.conf`` as needed, for
|
||||
example:
|
||||
.. warning::
|
||||
|
||||
Yosys does not support in-tree builds. If calling :program:`cmake` from the
|
||||
root ``yosys`` directory the ``-B`` option must be provided.
|
||||
|
||||
For a more persistent configuration, we recommend creating and using a
|
||||
``CMakeUserPresets.json`` file in the root ``yosys`` directory. Below is an
|
||||
example file which enables ccache and sets the default compiler to clang when
|
||||
calling ``cmake --preset default``:
|
||||
|
||||
.. code-block:: json
|
||||
:caption: CMakeUserPresets.json
|
||||
|
||||
{
|
||||
"version": 1,
|
||||
"configurePresets": [
|
||||
{
|
||||
"name": "default",
|
||||
"binaryDir": "build",
|
||||
"generator": "Unix Makefiles",
|
||||
"cacheVariables": {
|
||||
"CMAKE_C_COMPILER": "clang",
|
||||
"CMAKE_CXX_COMPILER": "clang++",
|
||||
"YOSYS_COMPILER_LAUNCHER": "ccache"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
Once generated, available build variables can be inspected and modified with
|
||||
:program:`ccmake` or opening the generated ``build/CMakeCache.txt`` file:
|
||||
|
||||
.. code:: console
|
||||
|
||||
echo "ENABLE_ZLIB := 0" >> Makefile.conf
|
||||
|
||||
Using one of these targets will set the ``CONFIG`` variable to something other
|
||||
than ``none``, and will override the environment variable for ``CXX``. To use a
|
||||
different compiler than the default when building, use:
|
||||
|
||||
.. code:: console
|
||||
|
||||
make CXX=$CXX # ..or..
|
||||
make CXX="g++-11"
|
||||
|
||||
.. note::
|
||||
|
||||
Setting the compiler in this way will prevent some other options such as
|
||||
``ENABLE_CCACHE`` from working as expected.
|
||||
ccmake build #..or..
|
||||
vi build/CMakeCache.txt
|
||||
|
||||
If you have clang, and (a compatible version of) ``ld.lld`` available in PATH,
|
||||
it's recommended to speed up incremental builds with lld by enabling LTO with
|
||||
``ENABLE_LTO=1``. On macOS, LTO requires using clang from homebrew rather than
|
||||
clang from xcode. For example:
|
||||
``CMAKE_INTERPROCEDURAL_OPTIMIZATION=ON``. On macOS, LTO requires using clang
|
||||
from homebrew rather than clang from xcode. For example:
|
||||
|
||||
.. code:: console
|
||||
|
||||
make ENABLE_LTO=1 CXX=$(brew --prefix)/opt/llvm/bin/clang++
|
||||
cmake -B build . -DCMAKE_INTERPROCEDURAL_OPTIMIZATION=ON \
|
||||
-DCMAKE_C_COMPILER=$(brew --prefix)/opt/llvm/bin/clang \
|
||||
-DCMAKE_CXX_COMPILER=$(brew --prefix)/opt/llvm/bin/clang++
|
||||
|
||||
By default, building (and installing) yosys will build (and install) `ABC`_,
|
||||
By default, building (and installing) Yosys will build (and install) `ABC`_,
|
||||
using :program:`yosys-abc` as the executable name. To use an existing ABC
|
||||
executable instead, set the ``ABCEXTERNAL`` make variable to point to the
|
||||
desired executable.
|
||||
executable instead, set the :makevar:`YOSYS_ABC_EXECUTABLE` CMake variable to
|
||||
point to the desired executable.
|
||||
|
||||
Running the build system
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
From the root ``yosys`` directory, call the following commands:
|
||||
To quickly install Yosys with default settings, call the following commands from
|
||||
the root ``yosys`` directory:
|
||||
|
||||
.. code:: console
|
||||
|
||||
make
|
||||
sudo make install
|
||||
cmake -B build . -DCMAKE_BUILD_TYPE=Release --fresh
|
||||
cmake --build build --config Release --parallel $(nproc)
|
||||
sudo cmake --install build --strip
|
||||
|
||||
To use a separate (out-of-tree) build directory, provide a path to the Makefile.
|
||||
To use an existing configuration, use the ``--build`` option, e.g:
|
||||
|
||||
.. code:: console
|
||||
|
||||
mkdir build; cd build
|
||||
make -f ../Makefile
|
||||
|
||||
Out-of-tree builds require a clean source tree.
|
||||
cmake -B build .
|
||||
ccmake build # modify configuration
|
||||
cmake --build build
|
||||
|
||||
.. seealso::
|
||||
|
||||
|
|
@ -248,6 +268,9 @@ directories:
|
|||
``backends/``
|
||||
This directory contains a subdirectory for each of the backend modules.
|
||||
|
||||
``cmake/``
|
||||
Additional ``.cmake`` files used by CMake during build generation.
|
||||
|
||||
``docs/``
|
||||
Contains the source for this documentation, including images and sample code.
|
||||
|
||||
|
|
@ -281,6 +304,10 @@ directories:
|
|||
example as of this writing the directory :file:`passes/hierarchy/` contains
|
||||
the code for three passes: `hierarchy`, `submod`, and `uniquify`.
|
||||
|
||||
``pyosys/``
|
||||
Contains the scripts and wrappers necessary for building :doc:`Pyosys
|
||||
</using_yosys/pyosys>`.
|
||||
|
||||
``techlibs/``
|
||||
This directory contains simulation models and standard implementations for
|
||||
the cells from the internal cell library.
|
||||
|
|
@ -289,19 +316,26 @@ directories:
|
|||
This directory contains the suite of unit tests and regression tests used by
|
||||
Yosys. See :doc:`/yosys_internals/extending_yosys/test_suites`.
|
||||
|
||||
The top-level Makefile includes :file:`frontends/{*}/Makefile.inc`,
|
||||
:file:`passes/{*}/Makefile.inc` and :file:`backends/{*}/Makefile.inc`. So when
|
||||
extending Yosys it is enough to create a new directory in :file:`frontends/`,
|
||||
:file:`passes/` or :file:`backends/` with your sources and a
|
||||
:file:`Makefile.inc`. The Yosys kernel automatically detects all commands linked
|
||||
with Yosys. So it is not needed to add additional commands to a central list of
|
||||
commands.
|
||||
.. TODO:: CMAKE_TODO
|
||||
|
||||
Good starting points for reading example source code to learn how to write
|
||||
passes are :file:`passes/opt/opt_dff.cc` and :file:`passes/opt/opt_merge.cc`.
|
||||
- ``yosys_<pass|test_pass|frontend|backend>(<name>)`` for each pass
|
||||
|
||||
Users of the Qt Creator IDE can generate a QT Creator project file using make
|
||||
qtcreator. Users of the Eclipse IDE can use the "Makefile Project with Existing
|
||||
Code" project type in the Eclipse "New Project" dialog (only available after the
|
||||
CDT plugin has been installed) to create an Eclipse project in order to
|
||||
programming extensions to Yosys or just browse the Yosys code base.
|
||||
- see :file:`cmake/YosysComponent.cmake`
|
||||
|
||||
- if using a sub folder, add it to the parent's ``CMakeLists.txt`` with
|
||||
``add_subdirectory(<name>)``
|
||||
|
||||
- previous:
|
||||
|
||||
The Yosys kernel automatically detects all commands linked
|
||||
with Yosys. So it is not needed to add additional commands to a central list of
|
||||
commands.
|
||||
|
||||
Good starting points for reading example source code to learn how to write
|
||||
passes are :file:`passes/opt/opt_dff.cc` and :file:`passes/opt/opt_merge.cc`.
|
||||
|
||||
Users of the Qt Creator IDE can generate a QT Creator project file using make
|
||||
qtcreator. Users of the Eclipse IDE can use the "Makefile Project with Existing
|
||||
Code" project type in the Eclipse "New Project" dialog (only available after the
|
||||
CDT plugin has been installed) to create an Eclipse project in order to
|
||||
programming extensions to Yosys or just browse the Yosys code base.
|
||||
|
|
|
|||
|
|
@ -293,7 +293,7 @@ is still valid.
|
|||
:caption: Example test.sh for C-Reduce
|
||||
:name: egtest
|
||||
|
||||
#!/bin/bash
|
||||
#!/usr/bin/env bash
|
||||
verilator --lint-only test.v &&/
|
||||
yosys -p 'logger -expect error "unsupported" 1; read_verilog test.v'
|
||||
|
||||
|
|
@ -333,7 +333,7 @@ an input argument: ``sv-bugpoint outDir/ test.sh test.v``
|
|||
.. code-block:: bash
|
||||
:caption: Example test.sh for sv-bugpoint
|
||||
|
||||
#!/bin/bash
|
||||
#!/usr/bin/env bash
|
||||
verilator --lint-only $1 &&/
|
||||
yosys -p "logger -expect error \"unsupported\" 1; read_verilog $1"
|
||||
|
||||
|
|
|
|||
|
|
@ -3,9 +3,9 @@ Symbolic model checking
|
|||
|
||||
.. todo:: check text context
|
||||
|
||||
.. note::
|
||||
|
||||
While it is possible to perform model checking directly in Yosys, it
|
||||
.. note::
|
||||
|
||||
While it is possible to perform model checking directly in Yosys, it
|
||||
is highly recommended to use SBY or EQY for formal hardware verification.
|
||||
|
||||
Symbolic Model Checking (SMC) is used to formally prove that a circuit has (or
|
||||
|
|
@ -117,3 +117,32 @@ Result with fixed :file:`axis_master.v`:
|
|||
|
||||
Solving problem with 159144 variables and 441626 clauses..
|
||||
SAT proof finished - no model found: SUCCESS!
|
||||
|
||||
Witness framework and per-property tracking
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When using AIGER-based formal verification flows (such as the ``abc`` engine in
|
||||
SBY), Yosys provides infrastructure for tracking individual formal
|
||||
properties through the verification pipeline.
|
||||
|
||||
The `rename -witness` pass assigns public names to all cells that participate in
|
||||
the witness framework:
|
||||
|
||||
- Witness signal cells: `$anyconst`, `$anyseq`, `$anyinit`,
|
||||
`$allconst`, `$allseq`
|
||||
- Formal property cells: `$assert`, `$assume`, `$cover`, `$live`,
|
||||
`$fair`, `$check`
|
||||
|
||||
These public names allow downstream tools to refer to individual properties by
|
||||
their hierarchical path rather than by anonymous internal identifiers.
|
||||
|
||||
The `write_aiger -ywmap` option generates a map file for conversion to and from
|
||||
Yosys witness traces, and also allows for mapping AIGER bad-state properties and
|
||||
invariant constraints back to individual formal properties by name. This enables
|
||||
features like per-property pass/fail reporting (e.g. ``abc pdr`` with
|
||||
``--keep-going`` mode).
|
||||
|
||||
The `write_smt2` backend similarly uses the public witness names when emitting
|
||||
SMT2 comments. Cells whose ``hdlname`` attribute contains the ``_witness_``
|
||||
marker are treated as having private names for comment purposes, keeping solver
|
||||
output clean.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
Scripting with Pyosys
|
||||
=====================
|
||||
|
||||
.. TODO:: document libyosys sans python
|
||||
|
||||
Pyosys is a limited subset of the Yosys C++ API (aka "libyosys") made available
|
||||
using the Python programming language.
|
||||
|
||||
|
|
@ -14,6 +16,13 @@ Though unlike these two, Pyosys goes a bit further, allowing you to use the
|
|||
Yosys API to implement advanced functionality that would otherwise require
|
||||
custom passes written in C++.
|
||||
|
||||
.. note::
|
||||
|
||||
It is recommended to install :program:`uv` for managing python environments:
|
||||
|
||||
.. code:: console
|
||||
|
||||
curl -LsSf https://astral.sh/uv/install.sh | sh
|
||||
|
||||
Getting Pyosys
|
||||
--------------
|
||||
|
|
@ -21,7 +30,7 @@ Getting Pyosys
|
|||
Pyosys supports CPython 3.8 or higher. You can access Pyosys using one of two
|
||||
methods:
|
||||
|
||||
1. Compiling Yosys with the Makefile flag ``ENABLE_PYOSYS=1``
|
||||
1. Compiling Yosys with the CMake flag ``-DYOSYS_WITH_PYTHON=ON``
|
||||
|
||||
This adds the flag ``-y`` to the Yosys binary, which allows you to execute
|
||||
Python scripts using an interpreter embedded in Yosys itself:
|
||||
|
|
@ -29,12 +38,9 @@ methods:
|
|||
``yosys -y ./my_pyosys_script.py``
|
||||
|
||||
Do note this requires some build-time dependencies to be available to Python,
|
||||
namely, ``pybind11`` and ``cxxheaderparser``. By default, the required
|
||||
``uv`` package will be used to create an ephemeral environment with the
|
||||
correct versions of the tools installed.
|
||||
|
||||
You can force use of your current Python environment by passing the Makefile
|
||||
flag ``PYOSYS_USE_UV=0``.
|
||||
namely, ``pybind11`` and ``cxxheaderparser``. :program:`uv` may be used to
|
||||
create an ephemeral environment with the correct versions of the tools
|
||||
installed if the current python environment doesn't provide them.
|
||||
|
||||
2. Installing the Pyosys wheels
|
||||
|
||||
|
|
|
|||
|
|
@ -39,36 +39,30 @@ incorrect results.
|
|||
Compile options
|
||||
---------------
|
||||
|
||||
To enable Verific support ``ENABLE_VERIFIC`` has to be set to ``1`` and
|
||||
``VERIFIC_DIR`` needs to point to the location where the library is located.
|
||||
To enable Verific support, set the :makevar:`YOSYS_VERIFIC_DIR` CMake variable
|
||||
to point to the location where the library is located, e.g.
|
||||
|
||||
============== ========================== ===============================
|
||||
Parameter Default Description
|
||||
============== ========================== ===============================
|
||||
ENABLE_VERIFIC 0 Enable compilation with Verific
|
||||
VERIFIC_DIR /usr/local/src/verific_lib Library and headers location
|
||||
============== ========================== ===============================
|
||||
.. code-block:: console
|
||||
|
||||
Since there are multiple Verific library builds and they can have different
|
||||
features, there are compile options to select them.
|
||||
cmake -B build . -DYOSYS_VERIFIC_DIR="/usr/local/src/verific_lib"
|
||||
|
||||
================================= ======= ===================================
|
||||
Parameter Default Description
|
||||
================================= ======= ===================================
|
||||
ENABLE_VERIFIC_SYSTEMVERILOG 1 SystemVerilog support
|
||||
ENABLE_VERIFIC_VHDL 1 VHDL support
|
||||
ENABLE_VERIFIC_HIER_TREE 1 Hierarchy tree support
|
||||
ENABLE_VERIFIC_YOSYSHQ_EXTENSIONS 0 YosysHQ specific extensions support
|
||||
ENABLE_VERIFIC_EDIF 0 EDIF support
|
||||
ENABLE_VERIFIC_LIBERTY 0 Liberty file support
|
||||
================================= ======= ===================================
|
||||
During building, CMake will attempt to automatically detect available Verific
|
||||
library components to enable the corresponding compile-time option in Yosys.
|
||||
This can be overridden by manually setting the :makevar:`YOSYS_VERIFIC_FEATURES`
|
||||
CMake variable. This variable should contain a semi-colon separated list, e.g.
|
||||
``-DYOSYS_VERIFIC_FEATURES="systemverilog;hier_tree"``. The table below lists
|
||||
the features available to Yosys.
|
||||
|
||||
To find the compile options used for a given Yosys build, call ``yosys-config
|
||||
--cxxflags``. This documentation was built with the following compile options:
|
||||
|
||||
.. literalinclude:: /generated/yosys-config
|
||||
:start-at: --cxxflags
|
||||
:end-before: --linkflags
|
||||
============== =========== ===================================
|
||||
Feature Directory Description
|
||||
============== =========== ===================================
|
||||
systemverilog verilog SystemVerilog support
|
||||
vhdl vhdl VHDL support
|
||||
hier_tree hier_tree Hierarchy tree support
|
||||
extensions extensions YosysHQ specific extensions support
|
||||
edif edif EDIF support
|
||||
liberty synlib Liberty file support
|
||||
============== =========== ===================================
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
@ -82,11 +76,10 @@ are required for the Yosys-Verific patch:
|
|||
|
||||
* RTL elaboration with
|
||||
|
||||
* SystemVerilog with ``ENABLE_VERIFIC_SYSTEMVERILOG``, and/or
|
||||
* VHDL support with ``ENABLE_VERIFIC_VHDL``.
|
||||
* SystemVerilog with ``systemverilog``, and/or
|
||||
* VHDL support with ``vhdl``.
|
||||
|
||||
* Hierarchy tree support and static elaboration with
|
||||
``ENABLE_VERIFIC_HIER_TREE``.
|
||||
* Hierarchy tree support and static elaboration with ``hier_tree``.
|
||||
|
||||
Please be aware that the following Verific configuration build parameter needs
|
||||
to be enabled in order to create the fully supported build:
|
||||
|
|
@ -105,11 +98,12 @@ to be enabled in order to create the fully supported build:
|
|||
Optional Verific features
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The following Verific features are available with TabbyCAD and can be enabled in
|
||||
Yosys builds:
|
||||
The following Verific features are available with TabbyCAD and will be
|
||||
automatically enabled in Yosys builds if the listed directory is included in the
|
||||
:makevar:`YOSYS_VERIFIC_DIR`:
|
||||
|
||||
* EDIF support with ``ENABLE_VERIFIC_EDIF``, and
|
||||
* Liberty file support with ``ENABLE_VERIFIC_LIBERTY``.
|
||||
* EDIF support with ``edif`` directory, and
|
||||
* Liberty file support with ``synlib`` directory.
|
||||
|
||||
Partially supported builds
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -124,32 +118,18 @@ lists a series of build configurations which are possible, but only provide a
|
|||
limited subset of features. Please note that support is limited without YosysHQ
|
||||
specific extensions of Verific library.
|
||||
|
||||
Configuration values:
|
||||
a. ``ENABLE_VERIFIC_SYSTEMVERILOG``
|
||||
b. ``ENABLE_VERIFIC_VHDL``
|
||||
c. ``ENABLE_VERIFIC_HIER_TREE``
|
||||
d. ``ENABLE_VERIFIC_YOSYSHQ_EXTENSIONS``
|
||||
|
||||
+--------------------------------------------------------------------------+-----+-----+-----+-----+
|
||||
| | Configuration values |
|
||||
+--------------------------------------------------------------------------+-----+-----+-----+-----+
|
||||
| Features | a | b | c | d |
|
||||
+==========================================================================+=====+=====+=====+=====+
|
||||
| SystemVerilog + RTL elaboration | 1 | 0 | 0 | 0 |
|
||||
+--------------------------------------------------------------------------+-----+-----+-----+-----+
|
||||
| VHDL + RTL elaboration | 0 | 1 | 0 | 0 |
|
||||
+--------------------------------------------------------------------------+-----+-----+-----+-----+
|
||||
| SystemVerilog + VHDL + RTL elaboration | 1 | 1 | 0 | 0 |
|
||||
+--------------------------------------------------------------------------+-----+-----+-----+-----+
|
||||
| SystemVerilog + RTL elaboration + Static elaboration + Hier tree | 1 | 0 | 1 | 0 |
|
||||
+--------------------------------------------------------------------------+-----+-----+-----+-----+
|
||||
| VHDL + RTL elaboration + Static elaboration + Hier tree | 0 | 1 | 1 | 0 |
|
||||
+--------------------------------------------------------------------------+-----+-----+-----+-----+
|
||||
| SystemVerilog + VHDL + RTL elaboration + Static elaboration + Hier tree | 1 | 1 | 1 | 0 |
|
||||
+--------------------------------------------------------------------------+-----+-----+-----+-----+
|
||||
======================================================================= =================================
|
||||
Features :makevar:`YOSYS_VERIFIC_FEATURES`
|
||||
======================================================================= =================================
|
||||
SystemVerilog + RTL elaboration systemverilog
|
||||
VHDL + RTL elaboration vhdl
|
||||
SystemVerilog + VHDL + RTL elaboration systemverilog;vhdl
|
||||
SystemVerilog + RTL elaboration + Static elaboration + Hier tree systemverilog;vhdl;hier_tree
|
||||
VHDL + RTL elaboration + Static elaboration + Hier tree vhdl;hier_tree
|
||||
SystemVerilog + VHDL + RTL elaboration + Static elaboration + Hier tree systemverilog;vhdl;hier_tree
|
||||
======================================================================= =================================
|
||||
|
||||
.. note::
|
||||
|
||||
In case your Verific build has EDIF and/or Liberty support, you can enable
|
||||
those options. These are not mentioned above for simplification and since
|
||||
they are disabled by default.
|
||||
those options. These are not mentioned above for simplification.
|
||||
|
|
|
|||
|
|
@ -4,8 +4,10 @@ Contributing to Yosys
|
|||
Reporting bugs
|
||||
--------------
|
||||
|
||||
A good bug report includes the following information:
|
||||
We fix well-reported bugs the fastest. A good bug report is an issue on the `issue tracker`_
|
||||
and includes the following information:
|
||||
|
||||
.. _`issue tracker`: https://github.com/YosysHQ/yosys/issues
|
||||
|
||||
Title
|
||||
~~~~~
|
||||
|
|
@ -27,8 +29,10 @@ The reproduction steps should be a minimal, complete and verifiable
|
|||
example `MVCE`_.
|
||||
Providing an MVCE with your bug report drastically increases the likelihood that
|
||||
someone will be able to help resolve your issue.
|
||||
One way to minimize a design is to use the `bugpoint_` command.
|
||||
You can learn more in the `how-to guide for bugpoint_`.
|
||||
Make sure that your report input is free of any problems as reported by the
|
||||
`check` command.
|
||||
One way to minimize a design is to use the `bugpoint` command.
|
||||
You can learn more in the :doc:`how-to guide for bugpoint </using_yosys/bugpoint>`.
|
||||
|
||||
The reproduction steps are ideally a code-block (starting and ending with
|
||||
triple backquotes) containing
|
||||
|
|
@ -85,7 +89,6 @@ Don't forget to mention:
|
|||
reproduction steps to just the Yosys part.
|
||||
|
||||
.. _MVCE: https://stackoverflow.com/help/minimal-reproducible-example
|
||||
.. _bugpoint: https://yosys.readthedocs.io/en/latest/cmd/bugpoint.html
|
||||
.. _how-to guide for bugpoint: https://yosys.readthedocs.io/en/latest/using_yosys/bugpoint.html
|
||||
|
||||
Expected Behaviour
|
||||
|
|
@ -176,6 +179,12 @@ based on their descriptions first, code second.
|
|||
|
||||
Before you build or fix something, also search for existing `issues`_.
|
||||
|
||||
We have open `developer 'jour fixe' (Dev JF) meetings`_
|
||||
where developers from YosysHQ and the
|
||||
community come together to discuss open issues and PRs. This is also a good
|
||||
place to talk to us about how to implement larger PRs.
|
||||
|
||||
.. _`developer 'jour fixe' (Dev JF) meetings`: https://docs.google.com/document/d/1SapA6QAsJcsgwsdKJDgnGR2mr97pJjV4eeXg_TVJhRU/edit?usp=sharing
|
||||
.. _`Discourse forum`: https://yosyshq.discourse.group/
|
||||
.. _`issues`: https://github.com/YosysHQ/yosys/issues
|
||||
|
||||
|
|
@ -277,7 +286,7 @@ have incorrect results in unusual situations.
|
|||
Coding style
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Yosys is written in C++17.
|
||||
Yosys is written in C++20.
|
||||
|
||||
In general Yosys uses ``int`` instead of ``size_t``. To avoid compiler warnings
|
||||
for implicit type casts, always use ``GetSize(foobar)`` instead of
|
||||
|
|
@ -297,6 +306,26 @@ Otherwise stick to the `Linux Kernel Coding Style`_.
|
|||
|
||||
.. _Linux Kernel Coding Style: https://www.kernel.org/doc/Documentation/process/coding-style.rst
|
||||
|
||||
Pull requests (PRs)
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you are working on something to add to Yosys, or fix something that isn't
|
||||
working quite right,
|
||||
make a `pull request (PR)`_.
|
||||
|
||||
An open PR, even as a draft, tells everyone that you're working on it and they
|
||||
don't have to. It can also be a useful way to solicit feedback on in-progress
|
||||
changes.
|
||||
|
||||
We use `labels`_ to help categorise
|
||||
issues and PRs. If a label seems relevant to your work, please do add it; this
|
||||
also includes the labels beginning with 'status-'. The 'merge-' labels are used
|
||||
by maintainers for tracking and communicating which PRs are ready and pending
|
||||
merge; please do not use these labels if you are not a maintainer.
|
||||
|
||||
.. _`pull request (PR)`: https://github.com/YosysHQ/yosys/pulls
|
||||
.. _`labels`: https://github.com/YosysHQ/yosys/labels
|
||||
|
||||
Git style
|
||||
~~~~~~~~~
|
||||
|
||||
|
|
@ -317,10 +346,12 @@ Reviewing PRs is a totally valid form of external contributing to the project!
|
|||
Who's the reviewer?
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Yosys HQ is a company with the inherited mandate to make decisions on behalf
|
||||
of the open source project. As such, we at HQ are collectively the maintainers.
|
||||
Within HQ, we allocate reviews based on expertise with the topic at hand
|
||||
as well as member time constraints.
|
||||
YosysHQ GmbH is a company with a mandate to make decisions for the good
|
||||
of YosysHQ open source software. It was co-founded by Claire Xenia Wolf,
|
||||
the original author of Yosys.
|
||||
Within it, we allocate reviews based on expertise with the topic at hand
|
||||
as well as member time constraints. However, decisions including reviews
|
||||
are also contributed by people external to the company.
|
||||
|
||||
If you're intimately acquainted with a part of the codebase, we will be happy
|
||||
to defer to your experience and have you review PRs. The official way we like
|
||||
|
|
@ -339,7 +370,8 @@ and stop being responsive, in the future, we might decide to remove such code
|
|||
if convenient and costly to maintain. It's simply more respectful of the users'
|
||||
time to explicitly cut something out than let it "bitrot". Larger projects like
|
||||
LLVM or linux could not survive without such things, but Yosys is far smaller,
|
||||
and there are expectations
|
||||
and there are implicit expectations of stability we aim to
|
||||
respect within reason.
|
||||
|
||||
.. TODO this deserves its own section elsewhere I think? But it would be distracting elsewhere
|
||||
|
||||
|
|
@ -375,3 +407,5 @@ they just are good enough to merge as-is.
|
|||
The CI is required to go green for merging. New contributors need a CI
|
||||
run to be triggered by a maintainer before their PRs take up computing
|
||||
resources. It's a single click from the github web interface.
|
||||
We test on various platforms and compilers. Sanitizer builds are only
|
||||
tested on the main branch.
|
||||
|
|
|
|||
|
|
@ -230,8 +230,7 @@ Use ``log_error()`` to report a non-recoverable error:
|
|||
.. code:: C++
|
||||
|
||||
if (design->modules.count(module->name) != 0)
|
||||
log_error("A module with the name %s already exists!\n",
|
||||
RTLIL::id2cstr(module->name));
|
||||
log_error("A module with the name %s already exists!\n", module);
|
||||
|
||||
Use ``log_cmd_error()`` to report a recoverable error:
|
||||
|
||||
|
|
|
|||
|
|
@ -181,7 +181,7 @@ pointer ``f`` to the output file, or stdout if none is given.
|
|||
|
||||
For this minimal example all we are doing is printing out each node. The
|
||||
``node.name()`` method returns an ``RTLIL::IdString``, which we convert for
|
||||
printing with ``id2cstr()``. Then, to print the function of the node, we use
|
||||
printing with ``unescape()``. Then, to print the function of the node, we use
|
||||
``node.to_string()`` which gives us a string of the form ``function(args)``. The
|
||||
``function`` part is the result of ``Functional::IR::fn_to_string(node.fn())``;
|
||||
while ``args`` is the zero or more arguments passed to the function, most
|
||||
|
|
|
|||
|
|
@ -7,28 +7,29 @@ Running the included test suite
|
|||
-------------------------------
|
||||
|
||||
The Yosys source comes with a test suite to avoid regressions and keep
|
||||
everything working as expected. Tests can be run by calling ``make test`` from
|
||||
the root Yosys directory. By default, this runs vanilla and unit tests.
|
||||
everything working as expected. Tests can be run by building the ``test``
|
||||
target from the root Yosys directory. By default, this runs vanilla and unit
|
||||
tests.
|
||||
|
||||
.. code:: console
|
||||
|
||||
cmake -B build .
|
||||
cmake --build build --target test --parallel $(nproc)
|
||||
|
||||
Vanilla tests
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
These make up the majority of our testing coverage.
|
||||
They can be run with ``make vanilla-test`` and are based on calls to
|
||||
make subcommands (``make makefile-tests``) and shell scripts
|
||||
(``make seed-tests`` and ``make abcopt-tests``). Both use ``run-test.sh``
|
||||
files, but make-based tests only call ``tests/gen-tests-makefile.sh``
|
||||
to generate a makefile appropriate for the given directory, so only
|
||||
afterwards when make is invoked do the tests actually run.
|
||||
.. TODO:: update for test infra changes
|
||||
|
||||
Usually their structure looks something like this:
|
||||
you write a .ys file that gets automatically run,
|
||||
which runs a frontend like ``read_verilog`` or ``read_rtlil`` with
|
||||
a relative path or a heredoc, then runs some commands including the command
|
||||
under test, and then uses :doc:`/using_yosys/more_scripting/selections`
|
||||
with ``-assert-count``. Usually it's unnecessary to "register" the test anywhere
|
||||
as if it's being added to an existing directory, depending
|
||||
on how the ``run-test.sh`` in that directory works.
|
||||
These make up the majority of our testing coverage. They can be run with the
|
||||
``test-vanilla`` CMake target. Usually their structure looks something like
|
||||
this: you write a .ys file that gets automatically run, which runs a frontend
|
||||
like ``read_verilog`` or ``read_rtlil`` with a relative path or a heredoc, then
|
||||
runs some commands including the command under test, and then uses
|
||||
:doc:`/using_yosys/more_scripting/selections` with ``-assert-count``. Usually
|
||||
it's unnecessary to "register" the test anywhere as if it's being added to an
|
||||
existing directory, depending on how the ``run-test.sh`` in that directory
|
||||
works.
|
||||
|
||||
Unit tests
|
||||
~~~~~~~~~~
|
||||
|
|
@ -45,7 +46,7 @@ Running the unit tests requires the following additional packages:
|
|||
|
||||
No additional requirements.
|
||||
|
||||
Unit tests can be run with ``make unit-test``.
|
||||
Unit tests can be run with the ``test-unit`` CMake target.
|
||||
|
||||
Functional tests
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
|
@ -75,17 +76,23 @@ If you don't have one of the :ref:`getting_started/installation:CAD suite(s)`
|
|||
installed, you should also install Z3 `following their
|
||||
instructions <https://github.com/Z3Prover/z3>`_.
|
||||
|
||||
Then, set the :makevar:`ENABLE_FUNCTIONAL_TESTS` make variable when calling
|
||||
``make test`` and the functional tests will be run as well.
|
||||
.. TODO:: CMAKE_TODO
|
||||
|
||||
How does this work under CMake? Is it only via ``make -C tests
|
||||
ENABLE_FUNCTIONAL_TESTS=1`` and then manually setting ``BUILD_DIR`` and
|
||||
``PROGRAM_PREFIX``? And possibly also setting ``YOSYS`` et al if there is a
|
||||
``.exe``. Previous instructions:
|
||||
|
||||
Then, set the :makevar:`ENABLE_FUNCTIONAL_TESTS` make variable when calling
|
||||
``make test`` and the functional tests will be run as well.
|
||||
|
||||
Docs tests
|
||||
~~~~~~~~~~
|
||||
|
||||
There are some additional tests for checking examples included in the
|
||||
documentation, which can be run by calling ``make test`` from the
|
||||
:file:`yosys/docs` sub-directory (or ``make -C docs test`` from the root). This
|
||||
also includes checking some macro commands to ensure that descriptions of them
|
||||
are kept up to date, and is mostly intended for CI.
|
||||
documentation, which can be run with the ``test-docs`` CMake target. This also
|
||||
includes checking some macro commands to ensure that descriptions of them are
|
||||
kept up to date, and is mostly intended for CI.
|
||||
|
||||
|
||||
Automatic testing
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ wide range of real-world designs, including the `OpenRISC 1200 CPU`_, the
|
|||
|
||||
.. _k68 CPU: http://opencores.org/projects/k68
|
||||
|
||||
Yosys is written in C++, targeting C++17 at minimum. This chapter describes some
|
||||
Yosys is written in C++, targeting C++20 at minimum. This chapter describes some
|
||||
of the fundamental Yosys data structures. For the sake of simplicity the C++
|
||||
type names used in the Yosys implementation are used in this chapter, even
|
||||
though the chapter only explains the conceptual idea behind it and can be used
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue