8a26111f40
This commit implements the Bit Manipulation Extension ZBB instruction
group: clz, ctz, pcnt, slo, sro, rol, ror, rev, rev8, orcb, pack
packu, packh, min, max, andn, orn, and xnor.
* Bit counting instructions clz, ctz and pcnt can be implemented to
share much of the architecture:
clz: Count Leading Zeros. Counts the number of 0 bits at the
MSB end of the argument.
ctz: Count Trailing Zeros. Counts the number of 0 bits at the
LSB end of the argument.
pcnt: Counts the number of set bits of the argument.
The implementation uses:
- 32 one bit adders, counting the set bits of a signal
bitcnt_bits, starting from the LSB end.
- For pcnt the argument is fed directly into bitcnt_bits.
- For clz, the operand is reversed such that leading zeros are
located at the LSB end of bitcnt_bits.
- For ctz and clz: counter enable signal for 1-bit counter i
is high, if the previous enable signal, and
its corresponting bitcnt_bit was high.
* Instructions sll[i], srl[i],slo[i], sro[i], rol, ror[i], rev, rev8
and orc.b are summarized as shifting instructions and related:
The following instructions are slight variations of the
existing base spec's sll, srl and sra instructions.
- slo[i] and sro[i]: shift left/right ones: similar to
shift-logical operations from base spec, but shifting
in ones instead of zeros.
- rol and ror[i]: rotate left/right ones: circular shift
operations. shifting in values from the oposite end
of the operand instead of zeros.
Those instructions can be implemented, sharing the base spec's
shifting structure. In order to support rotate operations, a
64-bit shifting structure is needed.
In the existing ALU, hardware is described only for right
shifts. For left shifts the operand is initially reversed,
right shifted and the result is reversed back. This gives rise
to an additional resource sharing oportunity for some more
zbb operations:
- rev: bitwise reversal.
- rev8: byte-order swap.
- orc.b: byte-wise reverse and or-combine.
* Instructions min, max:
For the B-extension's min/max instructions, we can share the
existing comparison operations. The result is obtained by
activating the comparison structure accordingly and
multiplexing the operands using the comparison result.
* Logic-with-negate instructions andn, orn, xnor:
For the B-extension's logic-with-negate instructions we can
share the structures of the base spec's logic structures
already present for 'xnor', 'or' and 'and' instructions as
well as the conditionally negated b operand generated for
subtraction operations.
* Instructions pack, packu, packh:
For the pack, packh and packu instructions I don't see any
opportunities for resource sharing. However, the architecture
is quite simple.
- pack: pack the lower halves of rs1 and rs2 into rd, with rs1
in the lower half and rs2 in the upper half.
- packu: pack the upper halves of rs1 and rs2 into rd, with
rs1 in the lower half and rs2 in the upper half.
- packh: pack the LSB bytes of rs1 and rs2 into rd, with rs1
in the lower half and rs2 in the upper half.
Signed-off-by: ganoam <gnoam@live.com>
|
||
|---|---|---|
| ci | ||
| doc | ||
| dv | ||
| examples | ||
| lint | ||
| rtl | ||
| shared | ||
| syn | ||
| util | ||
| vendor | ||
| .clang-format | ||
| .gitignore | ||
| azure-pipelines.yml | ||
| check_tool_requirements.core | ||
| CONTRIBUTING.md | ||
| CREDITS.md | ||
| ibex_configs.yaml | ||
| ibex_core.core | ||
| ibex_core_tracing.core | ||
| ibex_pkg.core | ||
| ibex_tracer.core | ||
| LICENSE | ||
| Makefile | ||
| python-requirements.txt | ||
| 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.