`b_width_capped` already exists for preventing arithmetic overflow, limiting the value of `b_width` to 30. This just changes the left shifts to also use it.
The caveat of incorrect results for extremely large values of `a_width` still applies, as does the improbability of that actually happening.
This fixes#4844 (or at least, the floating point exception; the circuit still isn't valid but I think that's fine).
In the current documentation, it's unclear if `result.string` serves as
an example of a string name. It is furthermore unclear what the purpose
of `result.string` is. Clarify this by adding a small explanation (and
fix a typo)
The B port is for single-bit summands. These can just as well be
represented as an additional summand on the A port (which supports
summands of arbitrary width). An upcoming `$macc_v2` cell won't be
special-casing single-bit summands in any way.
In preparation, make the following changes:
* remove the `bit_ports` field from the `Macc` helper (instead add any
single-bit summands to `ports` next to other summands)
* leave `B` empty on cells emitted from `Macc::to_cell`
In commit ac988cf we made sure to undefine the CONST/VOID macros left
defined by `tcl.h`, but this in turn makes it an issue to include
additional Tcl headers later on (see issue #4808).
One way out is to avoid a global `tcl.h` include. In the process we drop
support for Tcl-enabled MXE builds, which were likely broken anyway due
to the additional Tcl APIs used from `tclapi.cc`.
Drop the parts that are being dropped.
Move the things that are being moved.
Also move the verilog stuff out of README and into the docs.
GettingStarted is less cut and dry, so hold off on that one.
Avoid error:
```
kernel/mem.cc:1683:7: error: conflicting declaration ‘using addr_t = using addr_t = uint32_t’
1683 | using addr_t = MemContents::addr_t;
| ^~~~~~
In file included from /usr/include/sys/types.h:222,
from /usr/include/pthread.h:11,
from /usr/lib/gcc/x86_64-pc-cygwin/12/include/c++/x86_64-pc-cygwin/bits/gthr-default.h:35,
from /usr/lib/gcc/x86_64-pc-cygwin/12/include/c++/x86_64-pc-cygwin/bits/gthr.h:148,
from /usr/lib/gcc/x86_64-pc-cygwin/12/include/c++/ext/atomicity.h:35,
from /usr/lib/gcc/x86_64-pc-cygwin/12/include/c++/bits/cow_string.h:37,
from /usr/lib/gcc/x86_64-pc-cygwin/12/include/c++/bits/basic_string.h:51,
from /usr/lib/gcc/x86_64-pc-cygwin/12/include/c++/string:53,
from ./kernel/yosys_common.h:27,
from ./kernel/yosys.h:42,
from ./kernel/mem.h:23,
from kernel/mem.cc:20:
/usr/include/machine/types.h:63:15: note: previous declaration as ‘typedef char* addr_t’
63 | typedef char *addr_t;
```
According to IntelliSense, only the return types need to be prefixed with `MemContents::`, the rest are automagically using the class definition and highlight as `using Yosys::MemContents::addr_t = uint32_t`.
`Const::size()` returns int, so change iterators that use it to `auto` instead of `size_t`.
For cases where size is being explicitly cast to `int`, use the wrapper that we already have instead: `Yosys::GetSize()`.
There's a mismatch between what `kernel/mem.cc` emits for memories
with no read ports and what the internal RTLIL check expects.
The point of dispute it whether some of the parameters relating to read
ports have a zero-width value in this case. The `mem.cc` code says no,
the internal checker says yes.
Surveying the other `$mem_v2` parameters, and internal cell parameters
in general, I am inclined to side with the `mem.cc` code.
This breaks RTLIL compatibility but for an obscure edge case.
Initialize "unsigned int inner" in hash() functions
Includes a log_assert() that might help catch corrupted data structures
or future incomplete modification of DriveType definition
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.
New `help -dump-cells-json <file>` 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).
- 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`.
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.
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.
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.
* `misc/__init__.py`:
* checks if there's a `yosys-abc` in the same directory - if yes, sets the variable `sys._pyosys_abc`
* checks if there's a `share` in the same directory - if yes, sets the variable `sys._pyosys_share_dirname`
* `yosys.cc::init_share_dirname`: check for `sys._pyosys_share_dirname`, use it at the highest priority if Python is enabled
* `yosys.cc::init_abc_executable_name`: check for `sys._pyosys_abc`, use it at at the highest priority if Python is enabled
* `Makefile`: add new target, `share`, to only create the extra targets
* `setup.py`: compile libyosys.so, yosys-abc and share, and copy them all as part of the pyosys build
* `test/arch/ecp5/add_sub.py`: ported `add_sub.ys` to Python to act as a test for the share directory and abc with Python wheels, used in CI
* Created `setup.py`: Python package manifest to build `pyosys` wheels with a custom extension to build and include `libyosys.so` using Make
* `.gitignore`: Added byproducts of the Python wheel build process
* `Makefile`: Added `-undefined dynamic_lookup` to `libyosys.so` so missing symbols can be resolved by importing into a Python interpreter
* `kernel/yosys.cc`: Gated `PyImport_AppendInittab` with `!Py_IsInitialized`; as of Python 3.12, the interpreter is already initialized and `PyImport_AppendInittab` would cause an exception to be raised
* Created `wheels.yml`: CI workflow for building wheels for CPython on:
* Linux (glibc, musl) and Darwin
* x86-64 and arm64
* Less brittle method of adding script dirname to sys.path
* Check if scriptfp successfully opens before using it
* Move `log_error` to after `PyErr_Print()` is called
This matches the behavior of running a Python interpreter, where the
first element of sys.path is the dirname of the script being run.
This allows importing of files and modules in the same directory without
messing with PYTHONPATH or similar.
This adds a Python equivalent to the `-c` option, where scripts importing `libyosys` can be imported and used.
Most of the work for this was already done to enable Python passes a couple years back, so this is a relatively small changeset.
"\x0a" is a perfectly valid escape sequence, but unfortunately "\x0ac"
is equivalent to "\xac", and not "\x0a" "c" as we might expect --- *any*
number of hexadecimal characters after the "\x" is accepted. This can be
hit pretty easily if a newline is present in a format string.
"\x{...}" syntax is only available as of C++23, so use octal format
instead; a maximum of 3 digits following the backslash is accepted.
The alternative would be to render every escape like `" "\x0a" "`, but
it seems more effort that way.
It adds `DriveBit`, `DriveChunk` and `DriveSpec` types which are similar
to `SigBit`, `SigChunk` and `SigSpec` but can also directly represent
cell ports, undriven bits and multiple drivers. For indexing an RTLIL
module and for querying signal drivers it comes with a `DriverMap` type
which is somewhat similar to a `SigMap` but is guaranteed to produce
signal drivers as returned representatives.
A `DriverMap` can also optionally preserve connections via intermediate
wires (e.g. querying the driver of a cell input port will return a
connected intermediate wire, querying the driver of that wire will
return the cell output port that's driving the wire).
This is already supported by `SigSpec` and since both `SigChunk` and
`SigSpec` implement `extract` which is the multi-bit variant of this,
there is no good reason for `SigChunk` to not support
`SigBit operator[](int offset)`.
When implementing custom log_... functions or custom overloads for the
core log functions like log_signal it is necessary to return `char *`
that are valid long enough.
The log_... functions implemented in log.cc use either `log_id_cache` or
`string_buf` which both are cleared on log_pop.
This commit adds a public `log_str` function which stores its argument
in the `log_id_cache` and returns the stored copy, such that custom
log functions outside of log.cc can also create strings that remain
valid until the next `log_pop`.
This adds a generic non-recursive implementation of Tarjan's linear time
SCC algorithm that produces components in topological order. It can be
instantiated to work directly on any graph representation for which the
enumerate_nodes and enumerate_successors interface can be implemented.
Only the `B` input (the shift amount) can be marked as signed on a
`$shiftx` cell. Adapt the helper accordingly and prevent it from
creating invalid RTLIL when called with `is_signed` set. Previously
it would mark both `A` and `B` as signed.
KrystalDelusion
David Sawatzke
Martin Povišer
Emil J
Miodrag Milanovic
N. Engelhardt
mikesinouye
Jannis Harder
Robin Ole Heinemann
Larry Doolittle
Lofty
Philippe Sauter
Mohamed Gaber
Mike Inouye
Roland Coeurjoly
Claire Xenia Wolf
Emily Schmidt
Asherah Connor
Emil J
Alexander von Gluck
George Rennie