04-04-2018 06:01 PM
I am using the AXI TPG to generate test patterns for frame storage using the AXI VDMA. All TPG test patterns are working with the exception of the ramp in motion which has a frame misalignment about 20% of the times the system is powered up.
The failure symptom is that the bottom part of the frame look like lines from the old frame and the top part of the frame looks like lines from the new frame. It appears as if the VSYNC was occurring in the middle of the frame instead of the start of the frame.
I tried to isolate the framing error by checking the TUSER frame sync to the VDMA to make sure the VDMA was not producing the framing error. In the failed state, I saw that the VDMA was getting a valid TUSER input pulse for start of frame. Additionally I saw the s2mm write address of the VDMA change to a 0x0 value as a result of the frame sync. This makes me think the framing error is more likely in the TPG.
Note that the TPG slave AXI4-streaming interface is disabled, so the TPG is free-running. The TPG is clocked at a rate of 89.75MHz as is the VDMA streaming AXI port.
Thanks for your support!
04-05-2018 04:35 AM
When in a failed state, does this behavior happen every frame, or only on one frame occasionally?
I would suspect the VDMA configuration here. Sounds like maybe the fsync modes are misconfigured or maybe the genlock setup. Can you post your VDMA hardware configuration and also dump the registers?
Do you see any errors in the VDMA status registers?
Have you tried any other test data that is changing in time? If not, it could be getting masked when you try the other test patterns since the data being written to memory isn't changing. One interesting test would be to try another static test pattern, but enable the bouncing box so there is also some change in time.
04-11-2018 06:36 PM
Sorry for the delayed reply, i forget to subscribe to updates and I didn't get notified about your post.
In the failed state, every frame is misaligned.
Below are the VDMA IPI settings and the register values.
I ran the static pattern with the bouncing box. The box treats the misaligned frame boundary that is in the middle of the display frame and never passes through it but always bounces off of it.
Setting OL VMDA
Basic tab *******************
Address Width 32
Frame Buffers 3
Write Channel: **************
Memory Map Data Width 128
Write Burst Size 16
Stream Data Width 16
Line Buffer Depth 4096
Read Channel: **************
Memory Map Data Width 128
Read Burst Size 16
Stream Data Width 32
Line Buffer Depth 512
Advanced tab ****************
Write Channel Options
Fsync Options s2mm tuser
Genlock Mode Dynamic-Master
Allow Unaligned xfer unchecked
Read Channel Options
Fsync Options None
Genlock Mode Dynamic-Slave
Allow Unaligned xfer unchecked
04-13-2018 01:07 AM
How do you make sure you are not reading the same frame buffer you are writting into?
As this is a pattern in motion, I feel like you are reading the memory while the TPG is writting into it.
04-13-2018 05:25 AM
The settings look okay to me.
Is the mis-aligned frame boundary always at the same location (i.e. after multiple power cycles, resets,etc) ? Or does it change with each time?
If it's static, make sure you're setting HSIZE and STRIDE registers in bytes per line, not pixels per line.
If it's changing, then it is probably a fsync issue. In this case, can you post screenshots of your hardware connections between TPG and VDMA and also dump the register values of the VDMA.
Do you get any frame size errors in the VDMA S2MM side? Make sure to clear them first before reading them to avoid any startup issues.
04-13-2018 06:36 PM
Hi Florent and bwiec,
I think I see where the frame misalignment problem is. It looks like the TPG is driving the H lines out of the streaming AXI TDATA that are not aligned with the start of frame pulse TUSER.
I captured on an ILA that the VDMA S2MM MM write address WADDR gets reset to 0x0 when the TUSER start of frame pulse happens at the output of the TPG. However the data for H line #1 does not exit the TPG until the WADDR is a value equating to H line 278 of the TPG. I can tell which H line because I set the crosshair to be at H line=0 and it made it easy to spot that data in the middle of the ramp pattern in the WDATA of the S2MM MM bus.
I am going to record the streaming AXI TDATA at the output of the TPG relative to the start of frame TUSER, then I can isolate the frame misalignment 100% to the TPG. I'll update you with the test results.
04-16-2018 06:33 PM
I have some results to share with you that I think is convincing evidence that the frame misalignment is an issue in the TPG.
I added an ILA to the output data of the TPG. Using the TPG control registers, I place a cross-hair on line 1. In a healthy state, I should be able to easily see this data pattern in the ILA immediately following the start of frame pulse TUSER and contrast the 0xF0 fixed value of the cross-hair with the other H lines that are ramp data.
I triggered on the start of frame in the failed state, and the cross-hair data was not found on line 1 where it should have been on the streaming AXI data output TDATA. I had to trigger the ILA 678 more H lines later until I finally saw the cross-hair appear on the TDATA bus on line number 679. This was clearly a case of the TPG incorrectly marking a line in the frame as line 1 with the TUSER pulse.
I am convinced that this resolves the question about whether the frame misalignment occurs in the TPG or the VDMA/MIG.
The version of the TPG I am using is the one that comes bundled along with Vivado 2016.1.
04-17-2018 01:14 AM
Could you share a test case and the ILAs?
Could you try with a newer version of vivado?
04-17-2018 03:19 PM
I am not at liberty to share the design as a test case, but I can summarize how I was able to reproduce the frame misalignment problem in the TPG.
1. Clock and reset are the only inputs into the TPG (other that the AXI-lite bus)
2. Set the TPG control registers for generating a ramp with a motion speed of 32 pixels/frame - 20% of the time the frame misalignment will happen and be readily visible in the output display.
3. Generate a cross-hair pattern and set the line number for the cross-hair to cover line #1 entirely.
4. Trigger the ILA on start of frame (TUSER) and count lines using a trigger state machine until the fixed-value cross-hair pattern data appears instead of the ramp pattern data.
As for using a later version of TPG, I need to stick with an older version of Vivado because one of the IP blocks is no longer available in later versions. I do not need to fix this TPG issue because it is only used for testing and will not be included in the final FPGA design.