mirror of
https://github.com/openhwgroup/cva5.git
synced 2025-04-20 20:18:42 -04:00
4efa1e2d03
* Support for atomic extension A * Support instruction fence extension Zifencei * Update CSRs to Version 20240411 and include compliant support for Zihpm, Sstc, and Smstateen extensions * Support address translation * Fixes interrupts and exception handling * Adds interrupt controllers * Support coherent multicore systems through a new data cache and arbiter * Multiple bugfixes * Adds new scripts for example systems in Vivado and LiteX * Removes legacy, unused, and broken scripts, examples, and files --------- Co-authored-by: Chris Keilbart <keilbartchris@gmail.com> Co-authored-by: msa417 <msa417@ensc-rcl-14.engineering.sfu.ca> Co-authored-by: Rajnesh Joshi <rajnesh.joshi28@gmail.com> Co-authored-by: Rajnesh Joshi <rajneshj@sfu.ca>
5 lines
1.2 KiB
Text
5 lines
1.2 KiB
Text
A list of possible future improvements to CVA5 are as follows:
|
|
- Support configurable RAM types (LUTRAM, BRAM, URAM) for each large memory (branch predictor, instruction cache tagbank, instruction cache databank, data cache tagbank, and data cache databank). This allows for better control over resources and frequency.
|
|
- Remove atomic memory operation support from peripheral busses and convert them into exceptions. This allows for a cleaner and more optimal implementation of atomic instructions inside of the data cache alone.
|
|
- Eliminate the forwarding in the load queue when no data TLB is configured. This load queue bypass is only necessary when the data TLB is present for frequency reasons, and its removal would save resources.
|
|
- Implement a more flexible scheme for handling atomic read-modify-write memory operations in the multicore arbiter. Currently, as soon as such an operation is accepted all further memory operations are delayed until the RMW is resolved. The main problem (and indeed the only - the data cache can handle snoops during a RMW) in implementing a different scheme is starvation; if one core is writing constantly to an address another core is trying to RMW to, then the RMW core must eventually be allowed to succeed.
|