cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Scholar
Scholar
1,960 Views
Registered: ‎08-24-2011

Vivado 2017.4 - VTC - strange instantiation in block designer

Jump to solution

Hi,

When I instantiate Video Timing Controler (ver. 6.1) in the Block Designer, certain inputs are marked as inverted.

What is strange, it is not correlated with the polarity described in table 2.5 in https://www.xilinx.com/support/documentation/ip_documentation/v_tc/v6_1/pg016_v_tc.pdf

 

vtc.png

For example pin "clken" is described as "active high" but in BD is marked as inverted and has attribute "active low".

When I tried to connect constant values to the enable signals to make the core working (considering the additional "negations").

 

I got the following error during the initialization of the VTC driver:

Unhandled fault: imprecise external abort (0x1406) at 0xf0a00000                
pgd = ecfe0000                                                                  
[f0a00000] *pgd=0742e811, *pte=00000000, *ppte=00000000                         
Internal error: Oops - BUG: 1406 [#1] PREEMPT SMP ARM                           
Modules linked in: xilinx_vtc(+) uio_pdrv_genirq                                
CPU: 1 PID: 737 Comm: udevd Not tainted 4.9.0-xilinx-v2017.4 #1                 
Hardware name: Xilinx Zynq Platform                                             
task: ef1b9440 task.stack: ecfda000                                             
PC is at xvtc_probe+0x88/0xf4 [xilinx_vtc]                                      
LR is at clk_core_enable_lock+0x24/0x2c                                         
pc : [<bf0041c8>]    lr : [<c0330484>]    psr: 600e0013                         
sp : ecfdbd70  ip : 00000000  fp : c0176440                                     
r10: c74317e4  r9 : 00000001  r8 : 00000001                                     
r7 : bf004658  r6 : ef7f4e7c  r5 : ef0f0e00  r4 : ecef8e10                      
r3 : f0a10000  r2 : 00000000  r1 : a00e0013  r0 : 00000000                      
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none               
Control: 18c5387d  Table: 2cfe004a  DAC: 00000051                               
Process udevd (pid: 737, stack limit = 0xecfda210)                              
Stack: (0xecfdbd70 to 0xecfdc000)                                               
bd60:                                     ef0f0e00 00000001 bf004140 ef0f0e10   
bd80: bf004658 c039df38 ef0f0e10 c0a5b248 00000000 c039c9d4 ef0f0e10 ef0f0e44   
bda0: bf004658 c0a19ca0 c74317c0 c039cb14 00000000 bf004658 c039ca98 c039b244   
bdc0: ef08ff5c ef1334b4 bf004658 ecf09d80 00000000 c039c134 bf0045db bf0045dc   
bde0: 00000000 bf004658 bf006000 00000000 bf004708 c039d230 ffffe000 bf006000   
be00: 00000000 c0101858 00000000 00000001 00000000 a00e0013 00000000 bf004708   
be20: c0a13b7c c0a13b7c ef2a40c0 ef2e801c ef8df540 c0a30180 c0a30180 0000742a   
be40: 00000000 00000000 c74317e4 a00e0013 ecf963c0 00000001 bf0046c0 ecfdbf54   
be60: ecf963c0 c74317c0 00000001 c01904e8 bf0046c0 ecf963c0 bf0046c0 ecfdbf54   
be80: 00000001 c0178e24 bf0046cc 00007fff bf0046c0 c0176588 ecfdbf48 f0a00000   
bea0: c01764b0 00000070 f0a022b4 bf00486c b6f57f84 00000012 00002304 c01d2a50   
bec0: 00002304 00000000 00000000 00000000 00000000 bf00439c 00000004 00000000   
bee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000   
bf00: 00000000 00000000 7fffffff 00000000 b6f57f84 00000007 0000017b c0106e24   
bf20: ecfda000 00000000 0005d040 c01795b8 7fffffff 00000000 00000003 00000000   
bf40: 00002304 f0a00000 00002304 00000000 becad8a4 f0a00000 00002304 f0a01d64   
bf60: f0a01be8 f0a01574 00000880 000009b0 00000000 00000000 00000000 00000b28   
bf80: 00000022 00000023 0000001c 00000019 00000016 00000000 000684d0 00000000   
bfa0: 00000000 c0106c60 000684d0 00000000 00000007 b6f57f84 00000000 0005d040   
bfc0: 000684d0 00000000 00000000 0000017b 000418d0 00041800 00000000 0005d040   
bfe0: becad8a8 becad898 b6f50c64 b6edaa60 600e0010 00000007 2fffd861 2fffdc61   
[<bf0041c8>] (xvtc_probe [xilinx_vtc]) from [<c039df38>] (platform_drv_probe+0x)
[<c039df38>] (platform_drv_probe) from [<c039c9d4>] (driver_probe_device+0x1b0/)
[<c039c9d4>] (driver_probe_device) from [<c039cb14>] (__driver_attach+0x7c/0xa8)
[<c039cb14>] (__driver_attach) from [<c039b244>] (bus_for_each_dev+0x7c/0x8c)   
[<c039b244>] (bus_for_each_dev) from [<c039c134>] (bus_add_driver+0x16c/0x1dc)  
[<c039c134>] (bus_add_driver) from [<c039d230>] (driver_register+0xa0/0xe0)     
[<c039d230>] (driver_register) from [<c0101858>] (do_one_initcall+0x100/0x120)  
[<c0101858>] (do_one_initcall) from [<c01904e8>] (do_init_module+0x54/0x1b0)    
[<c01904e8>] (do_init_module) from [<c0178e24>] (load_module+0x16d4/0x1cb8)     
[<c0178e24>] (load_module) from [<c01795b8>] (SyS_finit_module+0x88/0x90)       
[<c01795b8>] (SyS_finit_module) from [<c0106c60>] (ret_fast_syscall+0x0/0x3c)   
Code: e5854068 e59430c4 e5932010 f57ff04f (e59f505c)                            
---[ end trace 0a364e849b94c946 ]---           

So it looks like either reset is asserted or one of clocks is not enabled and the core does not respond to AXI request.

How should I understand those negation circles placed on pins that are "active high" according to description?

 

Regards,

Wojtek

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Scholar
Scholar
2,298 Views
Registered: ‎08-24-2011

It looks, like Vivado/Petalinux 2017.4 incorrectly assigns the interrupt number.

I have modified the design so that the interrupt line from frmbuf write goes to line IRQ0 (previously it was connected to IRQ1).

As the result it got remapped from line 29 (0x1d) to line 30 (0x1e).

It seems incorrect, so I have overwritten it in my system-user.dtsi file with:

   interrupts = <0 29 4>;

 

Now the procedure (based on description in https://developer.ridgerun.com/wiki/index.php?title=Zynq_Ultrascale%2B_Capture_settings_and_Gstreamer_pipelines ) works correctly:

 

media-ctl -d /dev/media0 -p
#For 720P
media-ctl -d /dev/media0 -V '"40020000.v_tpg":0 [fmt:UYVY/1280x720]'
yavta --no-query -l /dev/v4l-subdev0
yavta --no-query -w '0x0098c912 1' /dev/v4l-subdev0
#For 720P
v4l2-ctl -d /dev/video0 --set-fmt-video=width=1280,height=720,pixelformat='YUYV'
yavta -n 3 -c10 -f YUYV -s 1280x720 --skip 7 -Ftest.raw /dev/video0

and returns:

Device /dev/video0 opened.
Device `video_cap_tpg output 0' on `platform:video_cap_tpg:0' is a video output (without mplanes) device.
Video format set: YUYV (56595559) 1280x720 (stride 2560) field none buffer size 1843200
Video format: YUYV (56595559) 1280x720 (stride 2560) field none buffer size 1843200
3 buffers requested.
length: 1843200 offset: 0 timestamp type/source: mono/EoF
Buffer 0/0 mapped at address 0xb6bdf000.
length: 1843200 offset: 1843200 timestamp type/source: mono/EoF
Buffer 1/0 mapped at address 0xb6a1d000.
length: 1843200 offset: 3686400 timestamp type/source: mono/EoF
Buffer 2/0 mapped at address 0xb685b000.
0 (0) [-] none 0 1843200 B 948.720870 948.720909 47.074 fps ts mono/EoF
1 (1) [-] none 1 1843200 B 948.732187 948.732224 88.363 fps ts mono/EoF
2 (2) [-] none 2 1843200 B 948.743508 948.743545 88.331 fps ts mono/EoF
3 (0) [-] none 3 1843200 B 948.754823 948.754859 88.378 fps ts mono/EoF
4 (1) [-] none 4 1843200 B 948.766139 948.766174 88.370 fps ts mono/EoF
5 (2) [-] none 5 1843200 B 948.777455 948.777490 88.370 fps ts mono/EoF
6 (0) [-] none 6 1843200 B 948.788771 948.788806 88.370 fps ts mono/EoF
7 (1) [-] none 7 1843200 B 948.800087 948.800123 88.370 fps ts mono/EoF
8 (2) [-] none 8 1843200 B 948.811404 948.819023 88.363 fps ts mono/EoF
9 (0) [-] none 9 1843200 B 948.822719 948.837834 88.378 fps ts mono/EoF
Captured 10 frames in 0.138206 seconds (72.355480 fps, 133365621.242851 B/s).
3 buffers released.

So the source of the problem is the incorrect remapping of interrupts, that must be fixed in user dtsi file.

(Please note, that:

)

 

Regards,

Wojtek

 

View solution in original post

8 Replies
Highlighted
Teacher
Teacher
1,916 Views
Registered: ‎06-16-2013

Hi @wzab

 

Have you already done "Validate Design" ?

After "Validate Design", you can understand the meaning of circle.

 

Would you try it ?

 

Best regards,

 

0 Kudos
Highlighted
Moderator
Moderator
1,956 Views
Registered: ‎11-09-2015

Hi @wzab,

 

Yes always refer to the documentation.

Sometimes, IPI thinks is active low only because the pin name end by a "n".

 

Regards,

 


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
Highlighted
Scholar
Scholar
1,901 Views
Registered: ‎08-24-2011
The design gets correctly validated regardless of the logic level connected to those pins.
When I set the signals ignoring the circles, I got correct communication via AXI, however there are still problems with generation of video signal.
Highlighted
Moderator
Moderator
1,898 Views
Registered: ‎11-09-2015

HI @wzab,

 

however there are still problems with generation of video signal

> What do you mean? Could you give details?


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
Highlighted
Scholar
Scholar
1,884 Views
Registered: ‎08-24-2011

however there are still problems with generation of video signal

> What do you mean? Could you give details?

 

Unfortunately, currently I'm not at the system where I have my design. I can send more details, including the project in VEXTPROJ format (the standard archive generated by Vivado is too big) in a few hours.

I use standard configuration with VTC, TPG, Video in to Axis Stream and Framebuffer Write.

I've managed to configure TPG so that I do not get "broken pipe" neither "not negotiated" errors.

However after that, when I run yavta to receive video I get everything stopped (not frozen, I can break it with CTRL+C) after allocation of three video buffers. It looks like framebuffer write does not receive video data and does not generate interrupts.

I'll send more details in the evening (of the CET time).

 

Regards,

Wojtek

0 Kudos
Highlighted
Scholar
Scholar
1,859 Views
Registered: ‎08-24-2011

OK. So here is my project with debug switched on. I have reset output products (right-click bd design and select "reset output products" before creating the archive) to get archive of reasonable size.

I also attach the associated Petalinux project.

Tests with chipscope have shown, that in hardware everything works fine. Framebuffer write generates DMA accesses and interrupt line goes high. However Linux ignores those interrupts, even though the final device tree contains the correct line:

   interrupts = <0x0 0x1d 0x4>;

In GIC the interrupt is connected to line  61=0x1d+32 and so it is reported:

   50:          0          0     GIC-0  61 Level     xilinx_framebuffer

It looks, that the interrupt disappears somewhere...

Regards,

Wojtek

0 Kudos
Highlighted
Scholar
Scholar
2,299 Views
Registered: ‎08-24-2011

It looks, like Vivado/Petalinux 2017.4 incorrectly assigns the interrupt number.

I have modified the design so that the interrupt line from frmbuf write goes to line IRQ0 (previously it was connected to IRQ1).

As the result it got remapped from line 29 (0x1d) to line 30 (0x1e).

It seems incorrect, so I have overwritten it in my system-user.dtsi file with:

   interrupts = <0 29 4>;

 

Now the procedure (based on description in https://developer.ridgerun.com/wiki/index.php?title=Zynq_Ultrascale%2B_Capture_settings_and_Gstreamer_pipelines ) works correctly:

 

media-ctl -d /dev/media0 -p
#For 720P
media-ctl -d /dev/media0 -V '"40020000.v_tpg":0 [fmt:UYVY/1280x720]'
yavta --no-query -l /dev/v4l-subdev0
yavta --no-query -w '0x0098c912 1' /dev/v4l-subdev0
#For 720P
v4l2-ctl -d /dev/video0 --set-fmt-video=width=1280,height=720,pixelformat='YUYV'
yavta -n 3 -c10 -f YUYV -s 1280x720 --skip 7 -Ftest.raw /dev/video0

and returns:

Device /dev/video0 opened.
Device `video_cap_tpg output 0' on `platform:video_cap_tpg:0' is a video output (without mplanes) device.
Video format set: YUYV (56595559) 1280x720 (stride 2560) field none buffer size 1843200
Video format: YUYV (56595559) 1280x720 (stride 2560) field none buffer size 1843200
3 buffers requested.
length: 1843200 offset: 0 timestamp type/source: mono/EoF
Buffer 0/0 mapped at address 0xb6bdf000.
length: 1843200 offset: 1843200 timestamp type/source: mono/EoF
Buffer 1/0 mapped at address 0xb6a1d000.
length: 1843200 offset: 3686400 timestamp type/source: mono/EoF
Buffer 2/0 mapped at address 0xb685b000.
0 (0) [-] none 0 1843200 B 948.720870 948.720909 47.074 fps ts mono/EoF
1 (1) [-] none 1 1843200 B 948.732187 948.732224 88.363 fps ts mono/EoF
2 (2) [-] none 2 1843200 B 948.743508 948.743545 88.331 fps ts mono/EoF
3 (0) [-] none 3 1843200 B 948.754823 948.754859 88.378 fps ts mono/EoF
4 (1) [-] none 4 1843200 B 948.766139 948.766174 88.370 fps ts mono/EoF
5 (2) [-] none 5 1843200 B 948.777455 948.777490 88.370 fps ts mono/EoF
6 (0) [-] none 6 1843200 B 948.788771 948.788806 88.370 fps ts mono/EoF
7 (1) [-] none 7 1843200 B 948.800087 948.800123 88.370 fps ts mono/EoF
8 (2) [-] none 8 1843200 B 948.811404 948.819023 88.363 fps ts mono/EoF
9 (0) [-] none 9 1843200 B 948.822719 948.837834 88.378 fps ts mono/EoF
Captured 10 frames in 0.138206 seconds (72.355480 fps, 133365621.242851 B/s).
3 buffers released.

So the source of the problem is the incorrect remapping of interrupts, that must be fixed in user dtsi file.

(Please note, that:

)

 

Regards,

Wojtek

 

View solution in original post

Scholar
Scholar
1,804 Views
Registered: ‎08-24-2011

I have promised to send the HW design in the VEXTPROJ format.

Here it is attached. The archive allowing to reconstruct the design has only 240kB (less than 17kB if you remove the image of the board from the board files).

Regards,

Wojtek

 

0 Kudos