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.
29 lines
936 B
Text
29 lines
936 B
Text
// Copyright lowRISC contributors.
|
|
// Licensed under the Apache License, Version 2.0, see LICENSE for details.
|
|
// SPDX-License-Identifier: Apache-2.0
|
|
{
|
|
name: "lowrisc_ip",
|
|
target_dir: "lowrisc_ip",
|
|
|
|
upstream: {
|
|
url: "https://github.com/lowRISC/opentitan"
|
|
rev: "master"
|
|
}
|
|
|
|
mapping: [
|
|
{from: "hw/dv/sv/common_ifs", to: "common_ifs"},
|
|
{from: "hw/dv/sv/csr_utils", to: "csr_utils"},
|
|
{from: "hw/dv/sv/dv_lib", to: "dv_lib"},
|
|
{from: "hw/dv/sv/dv_utils", to: "dv_utils"},
|
|
{from: "hw/dv/verilator", to: "dv_verilator"},
|
|
|
|
{from: "hw/ip/prim", to: "prim"},
|
|
{from: "hw/ip/prim_generic", to: "prim_generic"},
|
|
{from: "hw/ip/prim_xilinx", to: "prim_xilinx"},
|
|
|
|
{from: "hw/lint", to: "lint"},
|
|
|
|
{from: "util/dvsim", to: "dvsim"},
|
|
{from: "util/uvmdvgen", to: "uvmdvgen"},
|
|
]
|
|
}
|