mirror of
https://github.com/lowRISC/ibex.git
synced 2025-06-27 17:00:41 -04:00
8b42024cd5
Instead of using copies of primitives from OpenTitan, vendor the files in directly from OpenTitan, and use them. Benefits: - Less potential for diverging code between OpenTitan and Ibex, causing problems when importing Ibex into OT. - Use of the abstract primitives instead of the generic ones. The abstract primitives are replaced during synthesis time with target-dependent implementations. For simulation, nothing changes. For synthesis for a given target technology (e.g. a specific ASIC or FPGA technology), the primitives system can be instructed to choose optimized versions (if available). This is most relevant for the icache, which hard-coded the generic SRAM primitive before. This primitive is always implemented as registers. By using the abstract primitive (prim_ram_1p) instead, the RAMs can be replaced with memory-compiler-generated ones if necessary. There are no real draw-backs, but a couple points to be aware of: - Our ram_1p and ram_2p implementations are kept as wrapper around the primitives, since their interface deviates slightly from the one in prim_ram*. This also includes a rather unfortunate naming confusion around rvalid, which means "read data valid" in the OpenTitan advanced RAM primitives (prim_ram_1p_adv for example), but means "ack" in PULP-derived IP and in our bus implementation. - The core_ibex UVM DV doesn't use FuseSoC to generate its file list, but uses a hard-coded list in `ibex_files.f` instead. Since the dynamic primitives system requires the use of FuseSoC we need to provide a stop-gap until this file is removed. Issue #893 tracks progress on that. - Dynamic primitives depend no a not-yet-merged feature of FuseSoC (https://github.com/olofk/fusesoc/pull/391). We depend on the same functionality in OpenTitan and have instructed users to use a patched branch of FuseSoC for a long time through `python-requirements.txt`, so no action is needed for users which are either successfully interacting with the OpenTitan source code, or have followed our instructions. All other users will see a reasonably descriptive error message during a FuseSoC run. - This commit is massive, but there are no good ways to split it into bisectable, yet small, chunks. I'm sorry. Reviewers can safely ignore all code in `vendor/lowrisc_ip`, it's an import from OpenTitan. - The check_tool_requirements tooling isn't easily vendor-able from OpenTitan at the moment. I've filed https://github.com/lowRISC/opentitan/issues/2309 to get that sorted. - The LFSR primitive doesn't have a own core file, forcing us to include the catch-all `lowrisc:prim:all` core. I've filed https://github.com/lowRISC/opentitan/issues/2310 to get that sorted.
41 lines
910 B
Makefile
41 lines
910 B
Makefile
# Copyright lowRISC contributors.
|
|
# Licensed under the Apache License, Version 2.0, see LICENSE for details.
|
|
# SPDX-License-Identifier: Apache-2.0
|
|
.DEFAULT_GOAL := all
|
|
|
|
all: build
|
|
|
|
###################
|
|
## build targets ##
|
|
###################
|
|
build: compile_result
|
|
|
|
pre_compile:
|
|
@echo "[make]: pre_compile"
|
|
mkdir -p ${build_dir} && env | sort > ${build_dir}/env_vars
|
|
mkdir -p ${tool_srcs_dir}
|
|
-cp -Ru ${tool_srcs} ${tool_srcs_dir}
|
|
|
|
compile: pre_compile
|
|
@echo "[make]: compile"
|
|
# we check the status in the parse script below
|
|
-cd ${build_dir} && ${build_cmd} ${build_opts} 2>&1 | tee ${build_log}
|
|
|
|
post_compile: compile
|
|
@echo "[make]: post_compile"
|
|
|
|
# Parse out result
|
|
compile_result: post_compile
|
|
@echo "[make]: compile_result"
|
|
${report_cmd} ${report_opts}
|
|
|
|
clean:
|
|
echo "[make]: clean"
|
|
rm -rf ${scratch_root}/${dut}/*
|
|
|
|
.PHONY: build \
|
|
run \
|
|
pre_compile \
|
|
compile \
|
|
post_compile \
|
|
compile_result
|