UTIA - Prague - Demonstration Packages for Zynq
Posted: Fri Jul 22, 2016 4:38 pm
by Flemming_Christensen
UTIA have released four application notes and evaluation packages designed with
http://www.artemis-emc2.eu/ support:
(1) HDMII-HDMIO HW accelerated video processing on Sundance EMC2-DP V2 HW platform with Zynq xc7z030-1I part + SW projects
(2) Peta Linux for Sundance EMC2-DP V2 HW platform with Zynq xc7z030-1I part, with released Vivado 2015.4 HW project and video processing IP-cores.
(3) Low cost Zynq + EdkDSP accelerator + Full HD Toshiba video sensor + SW projects
(4) Automotive Zynq + EdkDSP accelerator + Full HD Toshiba video sensor + SW prokects
Where to download:(0)
http://sp.utia.cz/index.php?ids=projects/emc2(1)
http://sp.utia.cz/index.php?ids=results&id=s30i1h1(2)
http://sp.utia.cz/index.php?ids=results&id=emc2-dp-platform(3)
http://sp.utia.cz/index.php?ids=results&id=t20c1tm1(4)
http://sp.utia.cz/index.php?ids=results&id=t20q1tm1Thanks to Zdenek Pohl and Lukas Kohout from UTIA and to Flemming and his team from Sundance for their help and support.
Best regards
Jiri
Jiri Kadlec
UTIA
Department of signal processing
Prague
Czech Republic
http://zs.utia.cas.cz/kadlec@utia.cas.cz
Re: UTIA - Prague - Demonstration Packages for Zynq
Posted: Fri Aug 12, 2016 10:41 am
by Flemming_Christensen
Re: UTIA - Prague - Demonstration Packages for Zynq
Posted: Fri Sep 09, 2016 1:28 pm
by Carl_Ehrenstrahle
Hi,
I have an issue with the VDMA used in the package. The VDMA write doesn't work after the first frame. More specifically this condition is never met:
writingFrame == XAxiVdma_CurrFrameStore(&fb.vdma_hdmi, XAXIVDMA_WRITE) resulting in an endless busy wait.
Any ideas to fix this or what the cause might be?
Thanks,
Carl
Re: UTIA - Prague - Demonstration Packages for Zynq
Posted: Mon Sep 12, 2016 11:29 am
by Flemming_Christensen
From: Jiri Kadlec
Sent: 10 September 2016 08:14
Subject: Re: Issue with demonstrator projects for EMC2-DP-V2
Dear Carl,
The board has to be connected to the Full HD HDMI source signal.
This is (usually) the HDMI (digital) output from laptop, redirecting the laptop display to the
external display. Or providing exteded top area.
It is importatnt, that the laptip source generates HDMI oputput with resolution 1920x1080p60.
(it is clocked with the 148,5 MHz clock generated by the laptop, and this drives the HDMII VDMA input chain of IPs)
The source can be tested by connecting directly the source (laptop) to the display capable of 1920x1080p60.
(Read the parameters on the display and read setup of the laptop)
The designs depend on the presence of the FULL HD HDMI inutput with resolution 1920x1080p60
because it drives the clock and it is pushing the data in.
-----------
-- Questions to your design: SDSoC 2015.4 or 2016.2 ???
-- If you use SDSoC 2015.4 and Vivado 2015.4 there is no reason why it does not work
-- If you have made port of the released SDSoC 2015.4 design to the SDSoC 2016.2,
problem canhave multiple sources:
(1) Xilinx tools starting from 2016.1 and 2016.2 use different compiler tools and meed recompilation of all libraries with rhe new tool chain.
If you try to link with library taen from the BSP created in 2015.4 the utcomes are unpredicable and most likely does not work.
(do not link or link but possibly uncompatible drivers with updated 2016.2 cores).
(2) SDSoC 2016.1 and 2016.2 is compiling the IP cores (in Vivado 2016.1 and 2016.2) with the incremental compilation
This is done to accelerate the HW compilation time and reuse cached, allready compiled IP cores.
From our experience, this does not create problems for SDSoC 2016.1 and 2016.2 auto-generated new IPs but it can create
problems for the "standard" Vivado 2016.1 amd Vivado 2016.2 IP cores present in the user defined BSP
These IP cores (comming from the Vivado 2015.4 flow) are not ready (in some cases) for the Incremental flow and some
GENERIC statments can be wrongly propagated.
This happens only if incremental compilation is ON (and this is the case of SDSoC 2016.1 and SDSoC 2016.2 flow)
The incrementally compiled IP core might be compiled with GENERIC which is not set properly, because it was (in a standard flow) redefined on upper hierarchy of the HDL design setup.
That is (probably) the explanation why there can be a difference of a working Vivado 2016.2 design (no incremental compilation) and problém with identical BSP in the SDSoC 2016.2 flow, which is calling the Vivado 2016.2 but in the incremental compilation mode.
---------
We in UTIA have isues with this incremental compilation side effects in SDSoC 2016.1 and SDSoC 2016.2 and investigate
easy work arrounds.
That is why we do not have not the SDSoC 2016.2 demos yet.
Best regards,
Jiri