Generator instance that depends on other cores

[ivanvig]

Im using systemrdl to implement my cores CSRs, with a generator that consumes a rdl file and compiles it to systemverilog files and thats working fine.

Now lets say I have 3 cores: A, B and C. The C core rdl file includes A and B rdl files, in order to be able to compile the C core rdl file I need to provide the compiler the paths where it should search for the included files.

My first thought was using the generator's files_root and core_file fields to be able to find the core from which the generator is called and then use some internal fusesoc function to resolve all dependencies from the core and get all the files required. But in order to do that I need to create a new fusesoc instance with a config that I cant know from the generator scope.

So, is there a way to solve this problem where the generator instance requires files from other cores in order to produce source code?

[olofk]

Generators can't use information from other cores. For tasks that affect several cores I would recommend doing this as an Edalize frontend instead. Perhaps look at the sv2v tool class which receives SV files and produces Verilog files, but in your case it would consume rdl files and create SV files instead.

[ivanvig]

Great! I will look into it. Once I have it, are you interested in a pull request with that feature in the edalize repo? Otherwise I think I can use it as an external plugin.

[olofk]

That would be great. I'm likely to need something like that myself when I start some new project. But as you have noted, there is nothing preventing you from keeping it in an external plugin if you so wish. Btw, is this using @amykyta3's excellent PeakRDL tooling?

I also remembered that I did something similar to this but with IP-XACT not too long ago. Let me see if I can dig up an example of that for reference.

[jamesrbailey]

I started writing a edalize plugin for PeakRDL today.

Any suggestion on whether there should be 1) a separate edalize tool for every peakrdl backend, or 2) a single edalize tool where the user defines the backend via a tool option?

[amykyta3]

I would probably lean more towards option 2.

The main PeakRDL command-line interface is definitely the more "productized" and user-oriented workflow. As I develop the PeakRDL tools, I will be pushing users more towards that interface as the primary and preferred way to interact with the various PeakRDL sub-tools. This will inevitably be more familiar to users as well. This also has the benefit of implementing the user/org configuration mechanism described here: https://peakrdl.readthedocs.io/en/latest/configuring.html

Sub-tools will still always have their own documented and stable API for power-users.

[amykyta3]

Now lets say I have 3 cores: A, B and C. The C core rdl file includes A and B rdl files, in order to be able to compile the C core rdl file I need to provide the compiler the paths where it should search for the included files.

I would recommend treating RDL as distinct target filesets in the fusesoc file manifests. I usually discourage users from using `include directives in the source RDL, and instead use multi-file compilation. But even so, it probably makes sense to provide a mechanism for users to specify include search paths for the RDL preprocessor too.