How should the bus configuration in the vexii litex integration be handled?

[cklarhorst]

Hi @Dolu1990

currently, in litex the pbus addr_width are effectively hard-coded to 32 bits.
This breaks for configurations like: --vexii-args "--physical-width=38 --xlen=64".
All in all, many more bus options are currenlty affected:

• dma addr width is forced to 32bit (which results in a width converter placed by litex for other main bus configurations)
• all id sizes are hardcoded
• pbus data and addr width
• mbus addr width

I’d like to make a PR to fix this, but I’m not sure what approach you would prefer.

Options I see:

1. Parse the generated verilog and extract the final interface width (e.g. PBUS address width / data width).
2. Extend the existing Python config flow (PythonArgsGen) to export these additional values.
3. Recompute/guess them from the CLI args (e.g. from the Vexii args + LiteX options).

Is there a direction you would prefer?
My personal preference would be a single source of truth.
I think Options 2 and 3 tend to duplicate logic and can drift over time.
But option 1 also feels not ideal.

Question about the current 2-step integration (PythonArgsGen)
May I ask what the original design goal was behind generating an additional python file?
Downsides I see:

• It limits refactoring of the python vexii core file, because it constrains the naming/placement of things that the generated Python file overrides.
• It wasn't immediately clear to me which parameters are overridden during the process (I initially tried to set with_rvcbom = True in core.py without realizing most of those values would not survive^^)
• In the long term, PythonArgsGen may also end up duplicating scala-side logic. For example, for pBusDataWidth it would need to mimic the design logic (32 if axiLiteForce32 else xlen)

So my related idea/question is why not create the resolved config during cpu generation?
For example as an extra meta module in verilog containing only constants: (although I would hate to parse that^^)

module vexii_soc_meta;
  localparam MBUS_WIDTH  = 64;
  localparam PBUS_AW     = 38;
  localparam PBUS_DW     = 64;
  localparam L2_WAYS     = 8;
endmodule

Or as a machine-readable header with (JSON or YAML) one-liner or block:
// DESIGN-META: {"mBusWidth":64,"pBusAddrWidth":38,"pBusDataWidth":64,"l2Ways":8}
Or maybe there's an even better approach.
Maybe a plugin could do that?

[Dolu1990]

Hi,

--physical-width=38

Prefer --physical-width=36 for extra safety in a first time ^^, as --physical-width=38 has some extra corner cases, let's stay safe in a first time.

Extend the existing Python config flow (PythonArgsGen) to export these additional values.

This is the way <3 Looks like you already spoted it, here is what i wrotte in this comment before noticing you already know :

If you look into pythondata-cpu-vexiiriscv/pythondata_cpu_vexiiriscv/verilog after having generated a VexiiRiscv SoC, you can see some xxxxxxxxxxx.py For instance ex c76383e3f37245ab4e68adbe5a66dbd8.py :

VexiiRiscv.xlen = 32
VexiiRiscv.with_rvm = 1
VexiiRiscv.with_rva = 1
VexiiRiscv.with_rvf = 0
VexiiRiscv.with_rvd = 0
VexiiRiscv.with_rvc = 0
VexiiRiscv.with_rvcbom = 1
VexiiRiscv.with_lsu_software_prefetch = 0
VexiiRiscv.with_lsu_hardware_prefetch = "none"
VexiiRiscv.internal_bus_width = 64

This is how the scala give back some parameters to litex python.
This is generated from here :
https://github.com/SpinalHDL/VexiiRiscv/blob/dev/src/main/scala/vexiiriscv/soc/litex/Soc.scala#L591

And could be extended with stuff like physical width and so on.

I think Options 2 and 3 tend to duplicate logic and can drift over time.

I would say, Option 2 <3

May I ask what the original design goal was behind generating an additional python file?

So, the idea was to support 1:1 all the "native" VexiiRiscv options, by relying on the "native" scala implementation of argument parsing (There are a lot) : https://github.com/SpinalHDL/VexiiRiscv/blob/5deff894552c5a15b0363c911e215a220533d7af/src/main/scala/vexiiriscv/Param.scala#L545

And so avoid trying to reproduce that in python. Instead just exporting what was necessary from scala to python by generating that .py file.

It could also carry additional information as plic mapping clint mapping and so on (endless scope)

For example, for pBusDataWidth it would need to mimic the design logic (32 if axiLiteForce32 else xlen)

Paine <3
Yes, not an ultimate solution

So my related idea/question is why not create the resolved config during cpu generation?

Overall, i think one of the "challange" i had with the integration with litex <> SoC is that some parameters are needed before being able to get other parameters, so things need to be "staged" or else you get into snake eating its own tail kinda situation.

For example as an extra meta module in verilog containing only constants: (although I would hate to parse that^^)

That is why i went with a generated .py file :D
No parsing <3

Maybe a plugin could do that?

A VexiiRiscv plugin ? Yes it could, but only for the VexiiRiscv parameters itself, not the scala SoC around it.

[inochisa]

May I ask what the original design goal was behind generating an additional python file?

So, the idea was to support 1:1 all the "native" VexiiRiscv options, by relying on the "native" scala implementation of argument parsing (There are a lot) : https://github.com/SpinalHDL/VexiiRiscv/blob/5deff894552c5a15b0363c911e215a220533d7af/src/main/scala/vexiiriscv/Param.scala#L545

And so avoid trying to reproduce that in python. Instead just exporting what was necessary from scala to python by generating that .py file.

It could also carry additional information as plic mapping clint mapping and so on (endless scope)

I like the way for carrying additional information for python generation, it will simplify the build and make custom layout easier, which is important for my team (For example, I have a big fpga and needs to move the ram base to other address to use a big ram).

In addition, how about something like yaml and json as a unify configuration? The scala code can get parameters by perform deserialization and python can directly import the configuration and got all the thing it wants.

[cklarhorst]

Ah, I have one more idea, @Dolu1990

For CPU options, we have SimpleParam and PythonArgsGen to tell LiteX what the final CPU configuration is.
Could we adopt the rule that SoC parameters must be strictly WYSIWYG?
In other words: no parameters with "changing meaning" + if a requested parameter can't be satisfied, building the SoC should fail with an error.

Example: forbid --axiLiteForce32 and replace it with --pbus-data-width.
Then --pbus-data-width 64 would mean:
- with --xlen 32 -> Vexii build fails
- with --xlen 64 -> fine

I think this is the best option because:

• We don't need to query SoC parameters back from the Vexii build, since we can be sure they're enforced.
• No need to change the current PythonArgsGen, and no duplicated decision logic.
• In python (your core.py), SoC parameters are already treated specially (they are passed as direct arguments, not as --vexii-args).

If you don't like that, then since you voted for "extend PythonArgsGen", I could make a PR that changes PythonArgsGen to parse the SoC args instead of VexiiParam, so it can see axiLiteForce32 (to calculate pbus width for the cpu.py file).

[Dolu1990]

@cklarhorst

For CPU options, we have SimpleParam and PythonArgsGen to tell LiteX what the final CPU configuration is.
Could we adopt the rule that SoC parameters must be strictly WYSIWYG?

The issue with WYSIWYG is that it prevent abstraction from taking place, leading the user to handle all corner cases.

Example: forbid --axiLiteForce32 and replace it with --pbus-data-width.

With no default value ? or the default being 32 bits ? or the default following XLEN implicitly ? or something else ?

[cklarhorst]

@Dolu1990

The issue with WYSIWYG is that it prevent abstraction from taking place, leading the user to handle all corner cases.

Example: forbid --axiLiteForce32 and replace it with --pbus-data-width.
With no default value ? or the default being 32 bits ? or the default following XLEN implicitly ? or something else ?

ah can we maybe have WYSIWYG and abstraction when the definition is:

• default case -> do what is best from a vexii point of view, so for --pbus-data-width that is XLEN
• user explicitly sets a value -> do what the user wants or fail

But how would litex use that? Litex allows a main bus width range between 32 and 512bit.

xlen, litex main data width, my understanding about what the best --pbus-data-width would be
32, 32, 32
64, 32, 32
32, 64, 32
64, 64, 64
32, 128, 32
64, 128, 64

-> looks like the best --pbus-data-width from a litex point of view would always be min(xlen, litex main data width)
My feeling is that for vexii interface parameters, it is always the litex side that has the most knowledge about what the best default parameter should be. So I would vote to have:
for vexxi: --pbus-data-width {32, 64} and a default of XLEN, which would not be used by litex
for litex: --vexii-pbus-data-width {32, 64} with a default of min(xlen, main data width)
and litex always forwarding --vexii-pbus-data-width to vexii
I would guess from a user standpoint, it would also be cool to have a litex default value for physical width, something like min(xlen, log2(end of highest mem-layout region)) clamped to the next higher supported vexii value.

[Dolu1990]

@cklarhorst Hi ^^

ah can we maybe have WYSIWYG and abstraction when the definition is:

Yes, that is the current intend

xlen, litex main data width, my understanding about what the best --pbus-data-width would be
32, 32, 32
64, 32, 32
32, 64, 32
64, 64, 64
32, 128, 32
64, 128, 64

Yes by default it follow xlen. the reason is that some software drivers assume that if xlen=64, some peripherals can be accessed in a single transaction using 64 bits memory accesses (for instance the CLINT which has a 64 bits counter, if you split the 64 bits memory access, you can get corrupted values). So, the idea was to always have XLEN pbus width

The reason of the axiLiteForce32 existance was that there was some bugs somewere i don't remember exactly.

for vexxi: --pbus-data-width {32, 64} and a default of XLEN, which would not be used by litex

Sure sound good.

for litex: --vexii-pbus-data-width {32, 64} with a default of min(xlen, main data width)

How is the litex main data width specified / calculated ?

I would guess from a user standpoint, it would also be cool to have a litex default value for physical width, something like min(xlen, log2(end of highest mem-layout region)) clamped to the next higher supported vexii value.

Yes ^^