[prim] Remove primgen and replace with virtual cores #23555

a-will · 2024-06-07T06:31:26Z

Add back prim_pkg enum for legacy support, and mention that it is deprecated. Some IPs reference the enums directly.

a-will · 2024-06-09T23:53:09Z

Interesting, it looks like mixing with a newer fusesoc might require at least Python 3.9 to work with the other dependencies.

ERROR: Ignored the following versions that require a different python version: 1.0.0 Requires-Python >=3.9,<4.0; 1.1.0 Requires-Python >=3.9
ERROR: Could not find a version that satisfies the requirement jsonschema2md==1.1.0 (from versions: 0.1.0, 0.1.1, 0.2.0.post1, 0.2.1, 0.3.0, 0.4.0, 0.9.0)
ERROR: No matching distribution found for jsonschema2md==1.1.0

a-will · 2024-06-10T06:15:28Z

Newer fusesoc also has a different directory layout compared to the OT fork. This was the OT fork's layout:

{--build-root}/
- sim-vcs/
  - fusesoc-created metadata, Makefile, and file list
- src/
  - Exported source files

But newer fusesoc has this directory layout:

{--work-root}/
- Contains fusesoc-created metadata, Makefile, and file list
- src/
  - Exported source files

Accommodating the new tree needed fixes to various paths, including CFLAGS definitions in hjson files. In the current example, {work-root} is set to dvsim's {build_dir}/fusesoc-work.

In addition, for ralgen, the position field was needed to be set to prepend for generated cores, else the files would come after the *_env_pkg.sv that would depend on them.

Now, some simulations work, but there is still a gap...

a-will · 2024-10-31T18:58:32Z

This PR is way out of date now, but since @olofk has released fusesoc 2.4, I think we don't need my random development tag anymore. 2.4 should be able to handle virtual cores as needed.

olofk · 2024-10-31T20:17:23Z

@a-will I think that depends on the OT requirements. If you are fine with pulling in cores from one vendor during a build, then virtual cores should do the trick.

However, as I understand it, OT wants to be able to select implementation at compile-time, and in that case you still need something like primgen.

With that said, I believe FuseSoC 2.4 should have all the functionality needed to implement what you need. I have done some experimenting implementing the equivalent to primgen as a FuseSoC filter instead of a generator and it looks promising.

Happy to discuss this further.

a-will · 2024-10-31T23:32:46Z

@a-will I think that depends on the OT requirements. If you are fine with pulling in cores from one vendor during a build, then virtual cores should do the trick.

However, as I understand it, OT wants to be able to select implementation at compile-time, and in that case you still need something like primgen.

With that said, I believe FuseSoC 2.4 should have all the functionality needed to implement what you need. I have done some experimenting implementing the equivalent to primgen as a FuseSoC filter instead of a generator and it looks promising.

Happy to discuss this further.

It's unclear to me if OT actually needs that, though. All of our in-tree top-level fusesoc cores end up binding a specific prim library, and an out-of-tree integrator would almost certainly do the same for their actual chip. The build recipes for synthesis often can't be reused across technologies, and across integrations for the same opentitan IP, the top-level generally uses different RTL, so we end up with independent top-level cores anyway. We'd end up with different YAML for each real target, so sharing that core file across implementations doesn't seem to provide a benefit.

There may be a bit of a rub with gate-level simulation applications, though, especially if you just want to redo the existing block-level simulations with your own prim library. I'd guess that the full integration level still uses its own core file for GLS, but is doing block-level simulation with a different prim library a supported activity? I'm not sure.

We'd probably achieve the original setup's capabilities if only we could provide fusesoc (as a parameter to its invocation) which implementations of virtual cores to include for the specified top-level core file. For example, it could be arguments to provide additional VLNVs to add to the build (using their default target). Then the top-level core file wouldn't need to explicitly pull them in.

a-will · 2024-11-01T00:33:38Z

For example, it could be arguments to provide additional VLNVs to add to the build (using their default target). Then the top-level core file wouldn't need to explicitly pull them in.

@olofk If that bit above is interesting, the specifying of additional VLNVs would be akin to how hierarchical synthesis flows work. The top-level (and other sub-cores) may have dangling references, but the missing netlists would get specified as additional sources, then linked in during the build. For fusesoc, ~~this would mean writing in a "depends" arrow from the top-level VLNV to the additional VLNVs, and the solver should handle them as though they were written in the core file~~ Edit: Actually, this might be just additional cores thrown into the Requirement, with no need to modify the dependency graph.

a-will · 2024-11-26T06:23:42Z

Looks like fusesoc 2.4 isn't being used in the sim runs in CI, and something broke with the CI file changes. I guess the API is a bit different for github actions. Maybe s/parameters/inputs?

marnovandermaas

Amazing PR! Left a few comments from looking at the code.

marnovandermaas · 2024-11-26T17:12:45Z

hw/ip_templates/flash_ctrl/dv/env/flash_ctrl_env.core

+      # TODO: prim_pkg_legacy is deprecated
+      - lowrisc:prim:prim_pkg_legacy


Maybe good to put this in a separate commit, just to separate it from the prepend changes.

hw/ip/otbn/dv/uvm/env/otbn_env.core

marnovandermaas · 2024-11-26T17:17:21Z

hw/ip/otp_ctrl/otp_ctrl.core

+      # TODO: prim_pkg is deprecated
+      - lowrisc:prim:prim_pkg


Will we create an issue to track this?

hw/ip/prim_generic/rtl/prim_generic_flash_bank.sv

marnovandermaas · 2024-11-26T17:22:07Z

hw/ip_templates/flash_ctrl/flash_ctrl.core.tpl

+      # TODO: prim_pkg_legacy is deprecated
+      - lowrisc:prim:prim_pkg_legacy


This change is similar to a change made in an earlier commit.

marnovandermaas · 2024-11-26T17:22:59Z

hw/top_earlgrey/cdc/cdc_waivers.data.tcl

Are these CDC waivers tested in CI? If not, have we tested this ourselves?

marnovandermaas · 2024-11-26T17:24:07Z

hw/top_earlgrey/chip_earlgrey_asic.core

@@ -14,6 +14,8 @@ filesets:
      - "fileset_partner ? (partner:systems:scan_role_pkg)"
      - "!fileset_partner ? (lowrisc:systems:ast)"
      - "!fileset_partner ? (lowrisc:systems:scan_role_pkg)"
+      - "!fileset_partner ? (lowrisc:prim:prim_pkg_legacy)"


Should this have a todo that this will be removed in the future?

Also true for other core files in top_earlgrey

marnovandermaas · 2024-11-26T17:25:42Z

hw/top_englishbreakfast/chip_englishbreakfast_cw305.core

@@ -12,6 +12,8 @@ filesets:
      - lowrisc:systems:ast
      - lowrisc:systems:topgen
      - lowrisc:systems:padring
+      - lowrisc:prim:prim_pkg_legacy


olofk · 2024-11-26T19:21:45Z

Regarding paths, I haven't checked exactly what the problem is, but I would recommend using --work-root instead of --build-root since that gives you more deterministic behaviour. You might also want to use --system-name to get a fixed name for the build artifacts.

a-will · 2024-11-26T19:26:45Z

Regarding paths, I haven't checked exactly what the problem is, but I would recommend using --work-root instead of --build-root since that gives you more deterministic behaviour.

That is what I did in this PR: https://github.com/lowRISC/opentitan/pull/23555/files#diff-8ed9c1256f9282d31ab3a7f150e2e95eaae62a546151c7203117aaa70451129e

Signed-off-by: Andreas Kurth <[email protected]>

This reverts commit 2c749f9. Signed-off-by: Hugo McNally <[email protected]>

Signed-off-by: Hugo McNally <[email protected]>

Some core old files were left after pulling otp out of the prims. Signed-off-by: Hugo McNally <[email protected]>

Signed-off-by: Hugo McNally <[email protected]>

…tants Signed-off-by: Hugo McNally <[email protected]>

This allows a configuration to inject a FuseSoC argument before the name of the core to invoke. This is useful because argument placement matters with FuseSoC. Signed-off-by: Hugo McNally <[email protected]>

Signed-off-by: Hugo McNally <[email protected]>

lowrisc:dv:chip_sim isn't being used anywhere and it is triggering a warning in FuseSoC. Signed-off-by: Hugo McNally <[email protected]>

Signed-off-by: Hugo McNally <[email protected]>

Providers of `lowrisc:prim:rom` should have the module name `prim_rom`. This primitive was missed in a previous commit. Signed-off-by: Hugo McNally <[email protected]>

rswarbrick

If I understand correctly, the "Replace primgen with virtual prim cores" commit has to appear at the same time as the "Update fusesoc to 2.4.3" commit (because it reflects the change to the build directory layout).

Is it easy to split the "virtual prim cores" commit so that the build directory layout change is separate? If so, that bit could be merged into the "update fusesoc" commit?

rswarbrick

Hi there!

This all looks rather sensible, but it looks like there are lots of changes that could land before switching tool version. The result would be that the "big switch" moment would be smaller.

Please feel free to tag me on the split versions!

rswarbrick · 2025-05-21T10:02:57Z

hw/dv/sv/sec_cm/prim_sparse_fsm_flop_if.sv

@@ -23,7 +23,7 @@ interface prim_sparse_fsm_flop_if #(
  string msg_id = $sformatf("%m");

  string path = dv_utils_pkg::get_parent_hier($sformatf("%m"));
-  string signal_forced = $sformatf("%s.u_state_flop.q_o", path);
+  string signal_forced = $sformatf("%s.state_o", path);


To avoid having a "known broken state" in the history, should this commit be merged with the switch to virtual prim cores?

rswarbrick · 2025-05-21T10:04:24Z

.github/workflows/bitstream.yml

@@ -82,11 +82,21 @@ jobs:
        if: steps.strategy.outputs.bitstreamStrategy != 'cached'
        run: |
          . util/build_consts.sh
+


If I understand correctly, this commit is all to do with the change to the new FuseSoc version. Again, maybe we need to squash with that commit so that (we think) everything works at each commit?

hw/ip_templates/flash_ctrl/rtl/flash_ctrl_top_specific_pkg.sv.tpl

rswarbrick · 2025-05-21T10:06:32Z

hw/ip/hmac/dv/hmac_sim_cfg.hjson

@@ -109,14 +109,14 @@
    {
      name: hmac_test_sha384_vectors
      uvm_test_seq: hmac_test_vectors_sha_vseq
-      run_opts: ["+is_nist_test=1 +test_vectors_dir={build_dir}/src/lowrisc_dv_test_vectors_0 +test_timeout_ns=750_000_000 +sha2_digest_size=SHA2_384"]
+      run_opts: ["+is_nist_test=1 +test_vectors_dir={build_dir}/fusesoc-work/src/lowrisc_dv_test_vectors_0 +test_timeout_ns=750_000_000 +sha2_digest_size=SHA2_384"]


I think there are quite a lot of commits starting here that should probably be squashed with the fusesoc version bump?

hw/top_englishbreakfast/ip_autogen/flash_ctrl/rtl/flash_ctrl_top_specific_pkg.sv

rswarbrick · 2025-05-21T10:31:24Z

hw/lint/tools/dvsim/common_lint_cfg.hjson

@@ -27,7 +27,7 @@
               "--tool={tool}",
               "--work-root={build_dir}/fusesoc-work",
               "--mapping=lowrisc:prim_generic:all:0.1",
-               "--mapping=lowrisc:systems:top_earlgrey:0.1",
+               "{additional_fusesoc_argument}",


Hmm. I think this commit probably needs squashing with the next two?

hw/top_earlgrey/dv/chip_sim.core

hw/ip/prim_generic/prim_generic.core

hw/ip/otp_macro/dv/env/otp_macro_env.core

rswarbrick · 2025-05-21T10:36:11Z

hw/ip/prim_xilinx/rtl/prim_xilinx_rom.sv

@@ -4,7 +4,7 @@

 `include "prim_assert.sv"

-module prim_xilinx_rom import prim_rom_pkg::*; #(
+module prim_rom import prim_rom_pkg::*; #(


I think this needs squashing with an earlier one? But I think the filename also needs changing to match the module name?

a-will force-pushed the fusesoc-compat branch 2 times, most recently from 65eb0ec to 19af483 Compare June 7, 2024 07:04

a-will mentioned this pull request Jun 7, 2024

[hw/prim] Adapted primitives to no longer require primgen.py #23523

Closed

marnovandermaas requested review from marnovandermaas and HU90m June 7, 2024 09:56

marnovandermaas added the Type:Enhancement Feature requests, enhancements label Jun 7, 2024

a-will force-pushed the fusesoc-compat branch 2 times, most recently from 458c9e4 to 4009fe6 Compare June 9, 2024 23:45

a-will force-pushed the fusesoc-compat branch 2 times, most recently from e7dd88c to b2b9aab Compare June 10, 2024 06:02

a-will force-pushed the fusesoc-compat branch 4 times, most recently from 787aca8 to 5344016 Compare June 17, 2024 04:34

HU90m force-pushed the fusesoc-compat branch 2 times, most recently from 980f9e1 to 90f83e5 Compare November 25, 2024 18:19

HU90m force-pushed the fusesoc-compat branch 3 times, most recently from 27aac7f to 679942b Compare November 26, 2024 14:56

andreaskurth mentioned this pull request Nov 26, 2024

[WIP] Uniquify top-specific FuseSoC cores and remove Darjeeling's FUSESOC_IGNORE #25401

Draft

marnovandermaas reviewed Nov 26, 2024

View reviewed changes

andreaskurth and others added 18 commits May 20, 2025 16:25

[chip_darjeeling_asic.core] Add missing non-partner scan_role_pkg

8948ae9

Signed-off-by: Andreas Kurth <[email protected]>

[top_darjeeling/dv] Fix hierarchical paths to mem and otp

6e0c1ce

Signed-off-by: Andreas Kurth <[email protected]>

[dvsim] Map prims to prim_generic for linting

d7acec1

Signed-off-by: Andreas Kurth <[email protected]>

Revert "[dvsim] Map prims to prim_generic for linting"

a1b1362

This reverts commit 2c749f9. Signed-off-by: Hugo McNally <[email protected]>

[dvsim] Map prims to prim_generic for linting

ed9ef0f

Signed-off-by: Hugo McNally <[email protected]>

[top_earlgrey] Added mappings for top specific virtual ips and constants

a5a8a0b

Signed-off-by: Hugo McNally <[email protected]>

[dvsim] Use earlgrey mappings for linting

895a29b

Signed-off-by: Hugo McNally <[email protected]>

[otp_macro] Clean up straggling core

ef7950d

Some core old files were left after pulling otp out of the prims. Signed-off-by: Hugo McNally <[email protected]>

[bazel,fusesoc] A temporary fix for fusesoc caching error

93dc618

Signed-off-by: Hugo McNally <[email protected]>

[top_darjeeling] Added mappings for top specific virtual ips and cons…

a09cbc7

…tants Signed-off-by: Hugo McNally <[email protected]>

[dvsim] Added additional_fusesoc_argment to lint configuration.

417d599

This allows a configuration to inject a FuseSoC argument before the name of the core to invoke. This is useful because argument placement matters with FuseSoC. Signed-off-by: Hugo McNally <[email protected]>

[top_earlgrey,lint] Added Earl Grey specific mappings to the lints

23b6b2d

Signed-off-by: Hugo McNally <[email protected]>

[top_darjeeling,lint] Added darjeeling specific mappings to the lints

9c94224

Signed-off-by: Hugo McNally <[email protected]>

[earlgrey,dv] Remove lowrisc:dv:chip_sim virtual

ec22481

lowrisc:dv:chip_sim isn't being used anywhere and it is triggering a warning in FuseSoC. Signed-off-by: Hugo McNally <[email protected]>

[prim_xilinx] Switch to xilinx specific rom implementation in :all

22fc03b

Signed-off-by: Hugo McNally <[email protected]>

[prim_generic] Include flop_no_rst to :all core file

23ba6cf

Signed-off-by: Hugo McNally <[email protected]>

[dv,otp_macro] otp_macro_env was missing it's dependency on cip_lib

5c8362f

Signed-off-by: Hugo McNally <[email protected]>

[prim_xilinx] Renamed rom prim's module name to conform to interface

61d4312

Providers of `lowrisc:prim:rom` should have the module name `prim_rom`. This primitive was missed in a previous commit. Signed-off-by: Hugo McNally <[email protected]>

HU90m force-pushed the fusesoc-compat branch from b5a3e73 to 61d4312 Compare May 20, 2025 15:25

a-will marked this pull request as ready for review May 20, 2025 16:36

a-will requested review from rswarbrick, a team, msfschaffner, vogelpi and cfrantz as code owners May 20, 2025 16:36

rswarbrick reviewed May 21, 2025

View reviewed changes

rswarbrick approved these changes May 21, 2025

View reviewed changes

This was referenced May 22, 2025

[ralgen] Specified position ralgen files should be inserted. #27283

Open

Miscellaneous fixes found when transitioning away from primgen #27284

Open

		# TODO: prim_pkg_legacy is deprecated
		- lowrisc:prim:prim_pkg_legacy

[prim] Remove primgen and replace with virtual cores #23555

Are you sure you want to change the base?

[prim] Remove primgen and replace with virtual cores #23555

Uh oh!

Conversation

a-will commented Jun 7, 2024

Uh oh!

a-will commented Jun 9, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

a-will commented Jun 10, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

a-will commented Oct 31, 2024

Uh oh!

olofk commented Oct 31, 2024

Uh oh!

a-will commented Oct 31, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

a-will commented Nov 1, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

a-will commented Nov 26, 2024

Uh oh!

marnovandermaas left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

olofk commented Nov 26, 2024

Uh oh!

a-will commented Nov 26, 2024

Uh oh!

rswarbrick left a comment

Choose a reason for hiding this comment

Uh oh!

rswarbrick left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

a-will commented Jun 9, 2024 •

edited

Loading

a-will commented Jun 10, 2024 •

edited

Loading

a-will commented Oct 31, 2024 •

edited

Loading

a-will commented Nov 1, 2024 •

edited

Loading