[luca24balboni]

Summary

Ollivander needs to integrate MAGIA's compute part without the tile's NoC interface and router. So this PR splits the tile into a reusable island, magia_isle, and makes it configurable through TileCfg.
It also makes the tile address map consistent with the NoC, turns every unmapped access into an error, and extends the Verilator flow to the standalone tile and CV32E40X.

magia_isle:
The isle holds the control core, L1, iDMA, RedMulE, Spatz CC, PULP cluster, the Event Unit and FractalSync.
It exposes narrow and wide AXI ports towards the outside, FractalSync ports, and the control-core Event Unit interrupt, for an external controller.
magia_tile is now NoC interface + router + magia_isle.

Parametrization:
The isle and the mesh are configured through TileCfg: RedMulE, Spatz CC and PULP cluster can each be turned on or off and sized per tile.
This makes heterogeneous meshes possible.
MAGIA_TILE_PERIPH_BASE and MAGIA_TILE_WINDOW_BASE let an integrator move the peripheral window and the tile windows.

Unified control port:
All control registers sit behind a single OBI crossbar port and are split by the new ctrl_demux: RedMulE, iDMA, FractalSync, Spatz, cluster, collectives.
Disabled units have no port: their range, and every hole in the control window, gets an OBI error from an obi_err_sbr.
OBI compliance: the iDMA and FractalSync control slaves now return rvalid one cycle after gnt, so no obi_cut is needed.

Address map:
L2 moves to 0xC000_0000, as in the NoC SAM, and 0xB000_0000 + tile window is an explicit collectives region (only with EnCollective).
The tile AXI crossbar has no default port anymore: anything outside tile windows, own L1, collectives, L2 and Spatz bootrom gets a DECERR.
Traffic from the NoC cannot go back into the NoC, so a wrong address no longer loops between a tile and the NoC or lands on L2 slice 0.
Region bounds are exclusive, as addr_decode expects: stack at 0x1_0000, L1 at 0x2_0000 up to the end of the 1 MiB window.

Error reporting:
In simulation, an OBI error from ctrl_demux or an AXI DECERR stops the test with a $fatal, instead of hanging or passing silently.

FractalSync:
It's selected at build time with make fsync=1/0 (MAGIA_FSYNC define).

Event Unit:
CV32E40X fix: the core issued the next load while a blocking Event Unit wait was still pending
The busy and error events are removed, only the done events need to wake the core.
event_unit_flex is bumped to lb/eu-two-outstanding, Spatz is bumped too.

Verilator:
mesh_dv=0 builds the standalone tile (magia_tile_tb, flat), next to the hierarchical mesh.
CV32E40X is supported, with its own build directory and RVFI trace.
Assertions are on by default; Ctrl-C and +STOP_AT close the FST.
run_regression.py and tests.yml run the tile tests and CV32E40X on Verilator too.
The tile testbench has a real reset edge, as 2-state simulators need.

Misc
All assertions are wrapped in ifndef SYNTHESIS.
Lint cleanup of the tile RTL: widths, case defaults, undriven fields, dead parameters.
The PULP and Spatz flat binaries include .bss, so crt0 no longer clears the code linked after it.

[FrancescoConti]

Ciao @luca24balboni generally good, there are some small fixes to make mostly for cleanup (e.g., non-idiomatic always_ff and some wrong license headers: maybe generated by an AI with an hangover? 🤣)

[luca24balboni]

Ciao @FrancescoConti , thanks! Yeah, the headers were all messed up, AI (my bad) kept copy-pasting the same mistake everywhere. Now HW is under SolderPad and SW under Apache without mixtures. Fixed them all. Then I went through all your comments and fixed the same stuff wherever else it showed up. The few parameter types left really change per instance.

[yvantor]

Is it normal that this PR (the only one which is currently ready for review) has 129 files changes? Does it need a rebase or something?

[AlessandroNadalini]

Is it normal that this PR (the only one which is currently ready for review) has 129 files changes? Does it need a rebase or something?

The PR is huge but many files changed to fix the headers

[yvantor]

Is it normal that this PR (the only one which is currently ready for review) has 129 files changes? Does it need a rebase or something?

The PR is huge but many files changed to fix the headers

Indeed my point (that I already discussed with Luca) was to split in two PRs (one for the code and one for the header). In general we need a more systematic approach (annoying because it takes more effort and time, but is cleaner and easier to spot potential issues).

[FrancescoConti]

I agree... atomic changes are to be preferred.

[AlessandroNadalini]

Is it normal that this PR (the only one which is currently ready for review) has 129 files changes? Does it need a rebase or something?

The PR is huge but many files changed to fix the headers

Indeed my point (that I already discussed with Luca) was to split in two PRs (one for the code and one for the header). In general we need a more systematic approach (annoying because it takes more effort and time, but is cleaner and easier to spot potential issues).

I totally agree. So, should we (re-)convert this PR to draft?

[yvantor]

Is it normal that this PR (the only one which is currently ready for review) has 129 files changes? Does it need a rebase or something?

The PR is huge but many files changed to fix the headers

Indeed my point (that I already discussed with Luca) was to split in two PRs (one for the code and one for the header). In general we need a more systematic approach (annoying because it takes more effort and time, but is cleaner and easier to spot potential issues).

I totally agree. So, should we (re-)convert this PR to draft?

No I would not be this drastic, I think this one can be closed since it was kept on hold for long enough. Let's try to keep it in mind for the future (I will try to be more active on the PRs review for the project)