7df14341ef
Before this patch, running the Makefile's default target deleted everything and then ran the whole flow. This sometimes does unnecessary work (if I've just changed the design, there's no need to rebuild and re-run the instruction generator). It also definitely won't work with Make's -j flag, since it depends on the targets being built in order. This patch keeps the same stages in the Makefile, but makes each stage generate a stamp file, adding dependencies between the stages. This way, you can make a small change to the design and re-run the simulation without having to generate the random inputs again. This doesn't make much difference if you're running lots of tests with no LSF (since VCS is very slow, its runtime for simulation completely dominates), but it can make a significant difference if you're debugging a single test, have made a change to the design and want to re-run. One significant change is that running 'make' doesn't automatically delete existing files any more. To make this possible (and useful!), we generate random data and test results in a directory keyed by the seed. For example make SEED=123 will generate results in out/seed-123/regr.log (rather than out/regr.log as before). To make sure we rebuild things properly if you change something like the number of iterations or the tests to run, we dump some variables describing the mode in which we were running. If these don't match the nnext time around, we'll rebuild stuff if necessary. Advanced (or hurried) users of the existing Makefile might have done things like change the design and then run make SEED=123 compile rtl_sim Now, the rtl_sim target depends on its logical dependencies. On the plus side, this means that you won't accidentally simulate out-of-date code. On the minus side, cunning tricks to avoid having to re-run stuff after touching a design file won't work. (If you're feeling really determined to do something like that, it's still possible with make -t). The seed-specific stamp files and dumped Make variables go into $(OUT-SEED)/.metadata directory, rather than $(OUT-SEED)/instr_gen or $(OUT-SEED)/rtl_sim. This is because of a review comment (to avoid extra clutter in the output directories). |
||
|---|---|---|
| doc | ||
| dv | ||
| examples | ||
| lint | ||
| rtl | ||
| shared | ||
| syn | ||
| util | ||
| vendor | ||
| .clang-format | ||
| .gitignore | ||
| azure-pipelines.yml | ||
| check_tool_requirements.core | ||
| CONTRIBUTING.md | ||
| CREDITS.md | ||
| ibex_core.core | ||
| ibex_core_tracing.core | ||
| ibex_tracer.core | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| src_files.yml | ||
| tool_requirements.py | ||
Ibex RISC-V Core
Ibex is a small and efficient, 32-bit, in-order RISC-V core with a 2-stage pipeline that implements the RV32IMC instruction set architecture.
Ibex offers several configuration parameters to meet the needs of various application scenarios. The options include two different choices for the architecture of the multiplier and divider unit, as well as the possibility to drop the support for the "M" extension completely. In addition, the "E" extension can be enabled when opting for a minimum-area configuration.
This core was initially developed as part of the PULP platform under the name "Zero-riscy" [1], and has been contributed to lowRISC who maintains it and develops it further. It is under active development, with further code cleanups, feature additions, and test and verification planned for the future.
Documentation
The Ibex user manual can be
read online at ReadTheDocs. It is also contained in
the doc folder of this repository.
Contributing
We highly appreciate community contributions. To ease our work of reviewing your contributions, please:
- Create your own branch to commit your changes and then open a Pull Request.
- Split large contributions into smaller commits addressing individual changes or bug fixes. Do not mix unrelated changes into the same commit!
- Write meaningful commit messages. For more information, please check out the contribution guide.
- If asked to modify your changes, do fixup your commits and rebase your branch to maintain a clean history.
When contributing SystemVerilog source code, please try to be consistent and adhere to our Verilog coding style guide.
When contributing C or C++ source code, please try to adhere to the OpenTitan C++ coding style
guide.
All C and C++ code should be formatted with clang-format before committing.
Either run clang-format -i filename.cc or git clang-format on added files.
To get started, please check out the "Good First Issue" list.
Issues and Troubleshooting
If you find any problems or issues with Ibex or the documentation, please check out the issue tracker and create a new issue if your problem is not yet tracked.
Questions?
Do not hesitate to contact us, e.g., on our public Ibex channel on Zulip!
License
Unless otherwise noted, everything in this repository is covered by the Apache License, Version 2.0 (see LICENSE for full text).
Credits
Many people have contributed to Ibex through the years. Please have a look at the credits file and the commit history for more information.