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

[HU90m]

This change pulls in the previously generated primitive wrappers, so that the primgen.py generator is no longer needed.

With these changes, OpenTitan can be built with upstream FuseSoC (tested on version 2.2).

I think there is some reorganisation of the primatives that could be nice; these are simply the minimal changes to remove primgen.py.

Fixes: #20379 #6604

@rswarbrick This follows the initial plan without any additional changes needed.

[marnovandermaas]

Huge fan of being able to build with upstream FuseSoC!

I'm on board with the first commit so we don't depend on primgen in the build process. For the second commit, I wonder whether we should keep primgen around so that there is an automated way to update all the primitives through the templates. What do you think?

[jwnrt]

Apologies for my SystemVerilog ignorance, but does the "abstract" file for these prims contain any real logic, or is it solely selecting which tech-specific prim to use?

If the latter, would the following work?

• Change the tech-specific prim modules from prim_(generic|xilinx|xilinx_ultrascale)_NAME to prim_NAME (which would conflict).
• Have fusesoc select which *.sv file to use depending on the tool flow, and not include the others at all.

[HU90m]

I'm on board with the first commit so we don't depend on primgen in the build process. For the second commit, I wonder whether we should keep primgen around so that there is an automated way to update all the primitives through the templates. What do you think?

I think if primgen is no longer used for builds it will start to bitrot, which would cause future devs pain. For the use case you are suggesting, primgen would need to be adapted to generate files in there expected locations in the repository. It can always be revived from the history, if we wish to do this.

Going forward there is a lot of cruft that could be removed and re-organised.

For example prim_xilinx_ultrascale_xor2.sv and prim_xilinx_xor2.sv are duplicate modules. One could have one module that is used for both:

if ((Impl == prim_pkg::ImplXilinx) || (Impl == prim_pkg::ImplXilinx_ultrascale)) begin : gen_xilinx
    prim_xilinx_xor2 #(
      .Width(Width)
    ) u_impl_xilinx (
      .*
    );
end else begin : gen_generic
    prim_generic_xor2 #(
      .Width(Width)
    ) u_impl_generic (
      .*
    );
end

In fact, the only difference between prim_xilinx_xor2 and prim_generic_xor2 is an attribute, so these could potentially all be collapsed into one module. There is likely some directory restructuring we could do to make it more ergonomic for techlibs to share.

These sorts of changes would require further, significant changes to primgen.

[GregAC]

Thanks for this @HU90m this looks like good work, however we must hold off on merging for now to avoid any possible disruption to M4.

So marking a 'Request changes' to prevent an accidental merge. I think this would be better off as a draft PR for now to make it clear the intent is early visibility and review.

[HU90m]

Apologies for my SystemVerilog ignorance, but does the "abstract" file for these prims contain any real logic, or is it solely selecting which tech-specific prim to use?

If the latter, would the following work?

• Change the tech-specific prim modules from prim_(generic|xilinx|xilinx_ultrascale)_NAME to prim_NAME (which would conflict).
• Have fusesoc select which *.sv file to use depending on the tool flow, and not include the others at all.

I had considered this and we could still do this.

A reason not to do this now is that we want to make the changes to the prims to be reasonably small and incremental. This approach would require wider changes.

A reason not to do this ever is that the current approach is pure system verilog and easy to understand. Using FuseSoC would make it harder for people with less familiar with FuseSoC to understand what is going on and would make it harder for people injesting the RTL into a different build flow to swap at the technology library without re-injesting the RTL.

[a-will]

I think this misses the reason we have primgen. What is it about primgen that makes it incompatible with upstream fusesoc?

An alternative that might not break the model would be to turn the abstract cores that were generated into virtual cores. Each tech lib would implement their own providers, and the particular tech lib would be chosen at the top level. This idea might need massaging for dealing with the chip-level cores that already specify the tech lib to use, though maybe that could be the output of a simple fusesoc generator, where a simple VLNV string provides the tech lib to depend on.

[a-will]

This is what I would object to here. primgen's purpose is to allow out-of-tree primitives without modifying the upstream repo.

[a-will]

Explicit dependencies here is going to make this not scale.

[jwnrt]

A reason not to do this ever is that the current approach is pure system verilog and easy to understand. Using FuseSoC would make it harder for people with less familiar with FuseSoC to understand what is going on and would make it harder for people injesting the RTL into a different build flow to swap at the technology library without re-injesting the RTL.

I get what you mean. Just for the record, this is what I did when porting prims to Bender, so it's not necessarily FuseSoC specific, it just needs an equivalent in whatever system you're using to build hardware.

[a-will]

I haven't tested this beyond running fusesoc --setup on a few chip-level cores, but this might show what I was talking about with virtual cores: #23555

This won't work without a very recent commit of fusesoc, though: The fixes to how virtual cores work aren't in a fusesoc release yet. On top of that, a more recent fusesoc appears to change the build directory compared to what dvsim currently expects, so that'll need to be fixed up.

[HU90m]

Closing in favor of exploring a virtual core approach. See #23555 and olofk/fusesoc#524