library/spi_engine: SDO Extension upgrade

[caosjr]

PR Description

Upgrade SPI engine to support up to 8 lanes. For that, two new registers were inserted into Configuration Write Instruction, they are responsible for setting the SDI and SDO lane masks. Each bit represents a lane.
This PR also removes register 8'h3b from the SPI Engine regmap.
The testbench for this modification is here: analogdevicesinc/testbenches#240

PR Type

• Bug fix (change that fixes an issue)
• New feature (change that adds new functionality)
• Breaking change (has dependencies in other repos or will cause CI to fail)
• Documentation

PR Checklist

• I have followed the code style guidelines
• I have performed a self-review of changes
• I have compiled all hdl projects and libraries affected by this PR
• I have tested in hardware affected projects, at least on relevant boards
• I have commented my code, at least hard-to-understand parts
• I have signed off all commits from this PR
• I have updated the documentation (wiki pages, ReadMe files, Copyright etc)
• I have not introduced new Warnings/Critical Warnings on compilation
• I have added new hdl testbenches or updated existing ones

[LBFFilho]

Overall this seems headed in a nice direction, and thanks for also doing a lot of small fixes and improvements to the existing code along the way.

About the version: is this going to be a minor version or a major version bump? I understand that the removed register was not used anywhere (it was broken even), but technically we're breaking anything that relied on it. Also changing the behavior of the SDI & SDO FIFOs.

Also, please check timing on ad4052/de10nano just to be sure if it's all good.

[dlech]

I've tested this again today with the latest rebase. Seems to be working OK still.

So the only request from my side still remaining is bumping the SPI Engine IP version to 2.0.0.

[caosjr]

I have updated the version of the SPI Engine to 2.0 and solved the issues of the tcl scripts.

[dlech]

The SPI driver changes have been accepted upstream in the Linux kernel and included in kernel v7.0. So we can now backport those changes to the ADI kernel tree and get this merged.

[IstvanZsSzekely]

I was asked to check the util_axis_fifo_asym changes in this PR.
The suggested modification with an added AXI4Stream register slice kind of does and doesn't belong to it. It makes sense to add it to ensure better timing overall, but at the same time I can imagine it being used without knowing why. Helps timing? Yes. Then just add it and don't think about it. And I would like to avoid this if possible. If you want to add the slice to the SPI Engine to ease timing, I would suggest doing it outside of the FIFO, as it maintains the boundaries of the core.
I built the AD4630 with a couple of parameter options provided by @sarpadi without the util_axis_fifo_asym changes and I did not see a timing violation on the module. However, I did see some timing violations on in the SPI Engine. Built with Vivado version 2025.1
Here are the build parameters I used:
make CLK_MODE=1 NUM_OF_CHANNEL=2 LANES_PER_CHANNEL=4 CAPTURE_ZONE=2 DDR_EN=1
make CLK_MODE=1 NUM_OF_CHANNEL=2 LANES_PER_CHANNEL=4 CAPTURE_ZONE=2 DDR_EN=0
make CLK_MODE=0 NUM_OF_CHANNEL=2 LANES_PER_CHANNEL=4 CAPTURE_ZONE=2 DDR_EN=0

[caosjr]

I was asked to check the util_axis_fifo_asym changes in this PR. The suggested modification with an added AXI4Stream register slice kind of does and doesn't belong to it. It makes sense to add it to ensure better timing overall, but at the same time I can imagine it being used without knowing why. Helps timing? Yes. Then just add it and don't think about it. And I would like to avoid this if possible. If you want to add the slice to the SPI Engine to ease timing, I would suggest doing it outside of the FIFO, as it maintains the boundaries of the core. I built the AD4630 with a couple of parameter options provided by @sarpadi without the util_axis_fifo_asym changes and I did not see a timing violation on the module. However, I did see some timing violations on in the SPI Engine. Built with Vivado version 2025.1 Here are the build parameters I used: make CLK_MODE=1 NUM_OF_CHANNEL=2 LANES_PER_CHANNEL=4 CAPTURE_ZONE=2 DDR_EN=1 make CLK_MODE=1 NUM_OF_CHANNEL=2 LANES_PER_CHANNEL=4 CAPTURE_ZONE=2 DDR_EN=0 make CLK_MODE=0 NUM_OF_CHANNEL=2 LANES_PER_CHANNEL=4 CAPTURE_ZONE=2 DDR_EN=0

I already tried to put this register slice outside the "util_axis_fifo_asym", it does not work for timing issues. The issue is raised then there are several lanes, for example 2 channels with 4 sdi lanes each (8 sdi lanes in total). The problem does not happen everytime, our tests passed 30% of the time. The critical path involves the "util_axis_fifo_address_generator.v" (line 155) inside the "util_axis_fifo" and the "util_axis_fifo_asym" (for our case, line 169). We need to break this path inside the library, any external solution will not work.

Regarding the usage, I put a parameter SRC_REG_SLICE_EN that is disabled by default. So the other projects would not be using it unless it is required. I also updated the documentation for that in this PR: #2031. I just left the commit over here so the other could test the project without a timing failure.

[machschmitt]

I see there might still be HDL issues to discuss. Just for the record, the related Linux kernel updates have been merged into ADI Linux main branch (analogdevicesinc/linux#3158). So, we can now also test HDL updates with the main kernel from ADI, if needed.