yosys

mirror of https://github.com/YosysHQ/yosys synced 2025-04-27 10:55:51 +00:00

History

Catherine 02e3d508fa cxxrtl: remove `module::steps`. (breaking change) This approach to tracking simulation time was a mistake that I did not catch in review. It has several issues: 1. There is absolutely no requirement to call `step()`, as it is a convenience function. In particular, `steps` will not be incremented in submodules if `-noflatten` is used. 2. The semantics of `steps` does not match that of the Verilog `$time` construct. 3. There is no way to make the semantics of `%t` match that of Verilog. 4. The `module` interface is intentionally very barebones. It is little more than a container for three method pointers, `reset`, `eval`, and `commit`. Adding ancillary data to it goes against this. If similar functionality is introduced again it should probably be a variable that is global per toplevel design using some object that is unique for an entire hierarchy of modules, and ideally exposed via the C API. For now, it is being removed (in this commit) and (in next commit) the capability is being reintroduced through a context object that can be specified for `eval()`.	2024-01-16 16:35:51 +00:00
..
cxxrtl	cxxrtl: remove `module::steps`. (breaking change)	2024-01-16 16:35:51 +00:00
README.txt	cxxrtl: reorganize runtime component files.	2023-11-28 15:32:36 +00:00

Catherine 02e3d508fa cxxrtl: remove module::steps. (breaking change)

This approach to tracking simulation time was a mistake that I did not
catch in review. It has several issues:
1. There is absolutely no requirement to call `step()`, as it is
   a convenience function. In particular, `steps` will not be
   incremented in submodules if `-noflatten` is used.
2. The semantics of `steps` does not match that of the Verilog `$time`
   construct.
3. There is no way to make the semantics of `%t` match that of Verilog.
4. The `module` interface is intentionally very barebones. It is little
   more than a container for three method pointers, `reset`, `eval`,
   and `commit`. Adding ancillary data to it goes against this.

If similar functionality is introduced again it should probably be
a variable that is global per toplevel design using some object that is
unique for an entire hierarchy of modules, and ideally exposed via
the C API. For now, it is being removed (in this commit) and (in next
commit) the capability is being reintroduced through a context object
that can be specified for `eval()`.

2024-01-16 16:35:51 +00:00

cxxrtl cxxrtl: remove module::steps. (breaking change) 2024-01-16 16:35:51 +00:00

README.txt cxxrtl: reorganize runtime component files. 2023-11-28 15:32:36 +00:00

README.txt

This directory contains the runtime components of CXXRTL and should be placed on the include path
when building the simulation using the `-I${YOSYS}/backends/cxxrtl/runtime` option. These components
are not used in the Yosys binary; they are only built as a part of the simulation binary.

The interfaces declared in `cxxrtl_capi*.h` contain the stable C API. These interfaces will not be
changed in backward-incompatible ways unless no other option is available, and any breaking changes
will be made in a way that causes the downstream code to fail in a visible way. The ABI of these
interfaces is considered stable as well, and it will not use features complicating its use via
libraries such as libffi or ctypes.

The implementations in `cxxrtl_capi*.cc` are considered private; they are still placed in the include
path to enable build-system-less builds (where the CXXRTL runtime component is included in the C++
file of the simulation toplevel).

The interfaces declared in `cxxrtl*.h` (without `capi`) are unstable and may change without notice.

For clarity, all of the files in this directory and its subdirectories have unique names regardless
of the directory where they are placed.