This PR adds a new two-level BHT predictor with private history. The new BPType parameters allow choosing between the original BHT and the new one.
Co-authored-by: Gianmarco Ottavi <ottavig91@gmail.com>
is_rvc is redundant with riscv::OpcodeC1, riscv::OpcodeC2
Signed-off-by: André Sintzoff <andre.sintzoff@thalesgroup.com>
Co-authored-by: JeanRochCoulon <jean-roch.coulon@thalesgroup.com>
The second optimization for Altera FPGA is to move the BHT to LUTRAM. Same as before, the reason why the optimization previously done for Xilinx is not working, is that in that case asynchronous RAM primitives are used, and Altera does not support asynchronous RAM. Therefore, this optimization consists in using synchronous RAM for the BHT.
The main changes to the existing code are:
New RAM module to infer synchronous RAM in altera with 2 independent read ports and one write port (SyncThreePortRam.sv)
Changes in the frontend.sv file: modify input to vpc_i port of BHT, by advancing the address to read, in order to compensate for the delay of synchronous RAM.
Changes in the bht.sv file: This case is more complex because of the logic operations that need to be performed inside the BHT. First, the pc pointed by bht_update_i is read from the memory, modified according to the saturation counter and valid bit, and finally written again in the memory. The prediction output is given based on the vpc_i. With asynchronous memory, the new data written via update_i is available one clock cycle after writing it. So, if vpc_i tries to read the address that was previously written by update_i, everything is fine. However, in the case of synchronous memory there are three clock cycles of latency (one for reading the pc content (read port 1), another one for writing it, and another one for reading in the other port (read port 0)). For this reason, there is the need to adapt the design to these new latency constraints:
First, there is the need for a delay on the address write of the synchronous RAM, to wait for the previous pc read and store the right modified data.
Once this is solved, similarly to the FIFO case, there is the need for an auxiliary buffer that will store the data written in the FIFO, allowing to have it available 2 clock cycles after the update_i was valid. This is because after having the correct data, the RAM takes 2 clock cycles until data can be available in the output (one clock cycle for writing and one for reading).
Finally, there is a multiplexer in the output that permits to deliver the correct prediction providing the data from the update logic (1 cycle of delay), the auxiliary register (2 cycles of delay), or the RAM (3 or more cycles of delay), depending on the delay since the update_i was valid (i.e. written to the memory).
The first optimization for Altera FPGA is to move the instruction queue to LUTRAM. The reason why the optimization previously done for Xilinx is not working, is that in that case asynchronous RAM primitives are used, and Altera does not support asynchronous RAM. Therefore, this optimization consists in using synchronous RAM for the instruction queue and FIFOs inside wt axi adapter.
The main changes to the existing code are:
New RAM module to infer synchronous RAM in altera with independent read and write ports (SyncDpRam_ind_r_w.sv)
Changes inside cva6_fifo_v3 to adapt to the use of synchronous RAM instead of asynchronous:
When the FIFO is not empty, next data is always read and available at the output hiding the reading latency introduced by synchronous RAM (similar to fall-through approach). This is a simplification that is possible because in a FIFO we always know what is the next address to be read.
When data is read right after write, we can’t use the previous method because there is a latency to first write the data in the FIFO, and then to read it. For this reason, in the new design there is an auxiliary register used to hide this latency. This is used only if the FIFO is empty, so we detect when the word written is first word, and keep it in this register. If the next cycle comes a read, the data out is taken from the aux register. Afterwards the data is already available in the RAM and can be read continuously as in the first case.
All this is only used inf FpgaAlteraEn parameter is enabled, otherwise the previous implementation with asynchronous RAM applies (when FpgaEn is set), or the register based implementation (when FpgaEn is not set).
- FIX: Replace riscv_pkg:VLEN by CVA6Cfg.VLEN
- Declare VLEN as new CVA6 parameter
- smoke-hwconfig: run with vcs-uvm and use return0 tests to speed-up CI light stage timing execution
- Use dedicated linker scripts for 65x configuration.
- Use dedicated spike.yaml for 65x configuration.
- Set BHTEntries=128, cache=WT, scoreboard entries=8 to improve Coremark and Dhrystone results
- Run 4 iterations of coremark to improve results
using verible-v0.0-3422-g520ca4b9/bin/verible-verilog-format
with default configuration
Note: two files are not correctly handled by verible
- core/include/std_cache_pkg.sv
- core/cache_subsystem/cva6_hpdcache_if_adapter.sv
* Clean-up README.md and top-level directory
This removes the duplicate `scripts` and `util` directories. Furthermore
the README is condensed by collapsing the citation and adding the
CITATION file to the repository.
Signed-off-by: Florian Zaruba <florian@openhwgroup.org>
* Re-name icache req/rsp structs
The structs used to communicate with the icache have contained the
direction, which makes no sense for structs since they inherently don't
have any direction.
Signed-off-by: Florian Zaruba <florian@openhwgroup.org>
---------
Signed-off-by: Florian Zaruba <florian@openhwgroup.org>
* [lsu] Add external store buffer pending stall signal
* [controller] Add external acc request pipeline flush signal
* [frontend] Do not increment commit pc on flush if commit stage is halted
* [acc_dispatcher] Add new store buffer stall and flush pipeline ctrl signals
* [acc_dispatcher] Add top module passable config type and parameter
* [cva6] Pass on missing CVA6Cfg parameter to acc_dispatcher
It counts and saves the saturation bits in D flip-flops for
the ASIC version and in a three-port asynchronous read memory
for the FPGA version.
FPGA flushing is not supported because the frontend module
flushing signal is not connected.
