AXI DMAC: Add Framelock, AutoRun, fsync, tlast

[gastmaier]

PR Description

General

Adds option for a port default value on adi_if_ports

AXI DMAC features

Framelock

Operates in two modes:

• Writer mode - available in s2mm configuration, the writer DMAC will always skip the current in use reader buffer
• Reader mode - available in mm2s configuration, the reader DMAC will try to stay behind the writer buffer by either repeating or skipping buffers according to the speed relationship of the two cores.
  In summary, allows to lock a framerate, by either skipping or repeating frames, depending on the rate of the incoming data (e.g. AXI HDMI RX, VTPG) and how fast it is consumed (e.g. AXI HDMI TX).
  The MSB of the framelock interface indicates if the [MSB-1:0] frame is valid.

TLast

In 2D mode, the assertion of TLAST on the AXI Stream source interface signalizes the end of frame, but Xilinx IP cores use this to signalize then end of line.
Allow to select TLAST to signalize End of Frame and End of Line.

FSync

A transfer will start only after the assertion of the external sync signal.
The sync signal can be either in source or destination clock domain or both.
This feature does not ensures fixed latency from the assertion of external sync signal and the availability of the data at the destination interface.

AutoRun

In cases where software is not available, the autorun feature can be used to set up a single transfer that will be executed after reset deassertion. This is mostly useful together with the CYCLIC mode.

How was this tested?

Last tested commit: 9d44ba3
Test projects are available at branch dmac_framelock.
The tested carrier is ZedBoard.
The project instantiates a video test pattern generator (VTPG), which feeds the AXI DMACs in framelock configuration.
The reader side outputs AXI-Stream to the AXI HDMI TX.
The VTPG, AXI CLKGEN, SYNC Generator (AXI TMR) and AXI HDMI TX were configured directly:

# AXI HDMI CLKGEN
busybox devmem 0x79000040 32 3

# ADI AXI HDMI TX
# https://wiki.analog.com/resources/fpga/docs/axi_hdmi_tx
busybox devmem 0x70E00040 32 1 # Enable core
busybox devmem 0x70E00400 32 $((16#07800898)) # 1920,2200
busybox devmem 0x70E00404 32 44
busybox devmem 0x70E00408 32 $((16#084000C0)) # 2112,192
busybox devmem 0x70E00440 32 $((16#04380465)) # 1080,1125
busybox devmem 0x70E00444 32 5 # 5
busybox devmem 0x70E00448 32 $((16#04610029)) # 1121,41
busybox devmem 0x70E00048 32 1 # Input
busybox devmem 0x70E00054 32 # REG_CLK_FREQ RO

# XILINX VTPG
# https://docs.amd.com/r/en-US/pg103-v-tpg/Register-Space
busybox devmem 0x43C00000 32 # Control
busybox devmem 0x43C00010 32 1080 # Height
busybox devmem 0x43C00018 32 1920 # Width
busybox devmem 0x43C00020 32 1 # Background Pattern
busybox devmem 0x43C00000 32  $((16#81)) # Control Start with Auto restart

# AXI TMR (For TPG DMA src ext sync)
# PWM of 10 clocks with 5 high and 5 low
# https://docs.amd.com/v/u/en-US/pg079-axi-timer
busybox devmem 0x43C10004 32 $((16#8))   # TRL0
busybox devmem 0x43C10014 32 $((16#3))   # TRL1
busybox devmem 0x43C10000 32 $((16#206)) # TCSR0
busybox devmem 0x43C10010 32 $((16#606)) # TCSR1

For the DMACs, I used adi-axi-fb.c as a module, with updated register addresses.
Instead of using devmem, devicetree bindings for each IP could have been used;
also, to init the ADV7511, the qv4l2 tool seem to used;
I didn't test the HDMI output in a display, I only sampled the stream with ILAs, *framelock* bus signals.

Testbenches are available at branch axi_dmac_flock.

The original hw tests (5 years ago) were done using an FMC-IMAGEON board.

Resource usage

Resource usage for the Framelock module, followed by the percentile of the total used by the DMA.

Writer

LUTs: 91 (13.2%)
Registers: 35 (3.3%)
Slice: 32 (9.6%)

Reader

LUTs: 57 (9.5%)
Registers: 41 (5.4%)
Slice: 25 (10.54%)

Notes for reviewers

Check if the used registers are adequate, since it collided with the Scather-Gather at rebase.
See if the test in hw suffice or if some other test is required.

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)

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

[bia1708]

RetriggerCI

[IuliaCMoldovan]

Just non-functional changes: