Disabling yosys's synthesis #365
Comments
|
I would very much like to have cxxrtl support added so I'm happy to add this functionality. Implementation-wise I would like to be more explicit though than just assuming cxxrtl when there is no arch. I also think this would make more sense to have in the yosys class that belongs to the new Flow API https://github.com/olofk/edalize/blob/main/edalize/tools/yosys.py |
bwitherspoon
pushed a commit
to bwitherspoon/edalize
that referenced
this issue
Dec 17, 2023
Currently, generated cores (i.e. core files written by a `generator`) are inserted into the list of cores, but their dependencies are ignored. After this commit, cores are inserted into the list of available cores, and their dependencies are evaluated as with normal cores. The implementation is actually simple: - Generators produce files, including .core files, in a special directory, unique per generator run. - This directory is added as library to the core database. - All cores in this new library (i.e. all .core files) are added as dependency to the current project. With that in place, the normal dependency resolution process takes over. This new behavior is actually easier to understand for users, as generator-produced are no longer a special case, but handled exactly as other cores. NOTE: This commit also includes another behavior change: the `generate.*.position` attribute is no longer supported, files are always inserted according to the normal dependency resolution orders. The test is changed accordingly. This needs to be documented better and a deprecation warning issued. Fixes olofk#365
bwitherspoon
pushed a commit
to bwitherspoon/edalize
that referenced
this issue
Dec 17, 2023
Currently, generated cores (i.e. core files written by a `generator`) are inserted into the list of cores, but their dependencies are ignored. After this commit, cores are inserted into the list of available cores, and their dependencies are evaluated as with normal cores. The implementation is actually simple: - Generators produce files, including .core files, in a special directory, unique per generator run. - This directory is added as library to the core database. - All cores in this new library (i.e. all .core files) are added as dependency to the current project. With that in place, the normal dependency resolution process takes over. This new behavior is actually easier to understand for users, as generator-produced are no longer a special case, but handled exactly as other cores. NOTE: This commit also includes another behavior change: the `generate.*.position` attribute is no longer supported, files are always inserted according to the normal dependency resolution orders. The test is changed accordingly. This needs to be documented better and a deprecation warning issued. Fixes olofk#365
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The CXXRTL backend for Yosys allows the generation of C++ code that can simulate a digital design, similar to the Verilator. The
write_cxxrtlcommand is not usually used in combination with the synthesized version of the design, but theedalize_yosys_template.tclscript always runs thesynth_xxxcommand.I propose adding the ability to disable the synth command through the
tools_options. Currently, thearchfield, which is used to generate the synth command, is required. I'm suggesting that when thearchis not set, then the synth command is omitted. This would not need the introduction of a new field nor change the ABI, as the current implementation causes Edalize to crash if arch is set to None.I have drafted a PoC of the above. In addition, the PoC also introduces the
yosys_write_optionsfield, which allows for the passing of extra arguments to the write command, such as the optimization level for write_cxxrtl.Before creating a pull request, I would like to hear your thoughts on this proposal.
The text was updated successfully, but these errors were encountered: