Support.Tulipp.eu

Ariel wrote:> Dear Timoteo,
>
> I am writing to see if you have successfully created an SDSoC platform for the HDMI board on SDSoC 2017.4. So far, I managed to create a simple one without any issues. Now, I took Sundace's hdmi input/output from hackaday for the zynq, which is on 2017.2 and adapted it to 2017.4 plus our new fmc-hdmi board. I was able to generate the bitstream without any issues and I followed the pfm_config.tcl but adapted it as the changed the workflow to create custom SDSoC platforms for 2017.4. The issue I am facing now is when I want to compile a simple application I get the following to errors:
>
> * No M_AXI_GP port found in the platform
> * Failed scheduling data transfer graph.
>
> Your pfm_config script looks like this:
>
> source -notrace c:/Xilinx/SDx/2017.2/scripts/vivado/sdsoc_pfm.tcl
> set pfm [sdsoc::create_pfm emc2_hdmii_hdmio.hpfm] sdsoc::pfm_name $pfm
> "sundance.com" "xd" "emc2_hdmii_hdmio" "1.0"
> sdsoc::pfm_description $pfm "emc2 hdmii to hdmio for the zynq 7030"
> sdsoc::pfm_clock $pfm FCLK_CLK0 processing_system7_0 0 true
> proc_sys_reset sdsoc::pfm_clock $pfm FCLK_CLK1 processing_system7_0 1
> false rst_processing_system7_0_142M sdsoc::pfm_axi_port $pfm M_AXI_GP1
> processing_system7_0 M_AXI_GP sdsoc::pfm_axi_port $pfm S_AXI_ACP
> processing_system7_0 S_AXI_ACP sdsoc::pfm_axi_port $pfm S_AXI_HP2
> processing_system7_0 S_AXI_HP sdsoc::pfm_axi_port $pfm S_AXI_HP3
> processing_system7_0 S_AXI_HP for {set i 5} {$i < 16} {incr i} {
> sdsoc::pfm_irq $pfm In$i xlconcat_0 } sdsoc::generate_hw_pfm $pfm
>
> An the one I used for the new workflow looks like this:
>
> set_property PFM_NAME "TUD:xd:tulipp_7z30_fmc_hdmi:1.0"\
> [get_files [get_property FILE_NAME [get_bd_designs]]]
>
>
> set_property PFM.CLOCK { \
> FCLK_CLK0 {id "0" is_default "true" proc_sys_reset
> "proc_sys_reset" } \
> FCLK_CLK1 {id "1" is_default "false" proc_sys_reset
> "rst_processing_system7_0_142M" } \
> } [get_bd_cells /processing_system7_0]
>
> set_property PFM.AXI_PORT { \
> M_AXI_GP1 {memport "M_AXI_GP"} \
> S_AXI_ACP {memport "S_AXI_ACP" sptag "ACP" memory
> "processing_system7_0 ACP_DDR_LOWOCM"} \
> S_AXI_HP0 {memport "S_AXI_HP" sptag "HP0" memory
> "processing_system7_0 HP0_DDR_LOWOCM"} \
> S_AXI_HP1 {memport "S_AXI_HP" sptag "HP1" memory
> "processing_system7_0 HP1_DDR_LOWOCM"} \
> S_AXI_HP2 {memport "S_AXI_HP" sptag "HP2" memory
> "processing_system7_0 HP2_DDR_LOWOCM"} \
> S_AXI_HP3 {memport "S_AXI_HP" sptag "HP3" memory
> "processing_system7_0 HP3_DDR_LOWOCM"} \
> } [get_bd_cells /processing_system7_0]
>
> set intVar []
> for {set i 0} {$i < 16} {incr i} {
> lappend intVar In$i {}
> }
> set_property PFM.IRQ $intVar [get_bd_cells /xlconcat_0]
>
> Have you faced some similar issues? I was not able to find something on xilinx's forum that's why I am asking you.
>
> Thank you.
> Best regards,
> Ariel.

Timoteo wrote:> Hi Ariel,
>
> I haven't worked with SDSoC since 16.2, and it changed a lot in these little things.
> I'm sure Emilie or Yannick can help, they both worked in 17.4 (or Emilie at least 17.2).
>
> For what I can see, you declare in the hardware platform the M_AXI_GP port, and I assume you've included it in the Zynq IP in the Vivado design? I know it sounds like a stupid question, but just in case.
> Also, I can see that what you show as "our script", is the proper definition of a hardware platform (at least in 16.2), whereas what you show me as "yours", is a bunch of "set_property" commands, which is what you have to set in the tcl console in Vivado, in order to generate the script for the hardware platform (at least it was like that in 16.2). Basically, the commands you are using (page 27 of: https://www.xilinx.com/support/document ... torial.pdf are in order to generate the script, or at least it was like that before. Does this help?
> Out of that, no idea, I don't even have SDSoC installed to give it a go, I'm sorry.
>
> Docs I would use:
> https://www.xilinx.com/support/document ... nx2017_4/u
> g1236-sdsoc-platform-tutorial.pdf
> https://www.xilinx.com/support/document ... nx2017_4/u
> g1146-sdsoc-platform-development.pdf
>
> I add Emilie and Yannick, they might help more.
>
> Best regards,
> Timoteo

Yannick wrote:> Hello Ariel,
>
> I have had similar issues about AXI peripherals while creating a SDSoC platform, and solved it thanks to a xilinx's forum post where an example was given. Unfortunately I am not at the office today so I don't have access to that file - I'll send it to you tomorrow.
> Have you had a look at the following wiki pages? Those helped me a lot
> in the process.
> https://www.xilinx.com/html_docs/xilinx ... 5173563647
> 23.html
>
> Best regards,
>
> Yannick

Ariel wrote:Dear Timoteo and Yannick,

First of all, thank you very much for your quick reply.

@Timoteo: On the UG1236 it says that you have to identify and tag the AXI Ports with the Platform properties so the hw functions can use these ports to move data to and from the hw functions (page 27). This is done with the property PFM.AXI_PORT. With this version, if I understood correctly (Yannick will correct me if I am wrong), there is no more need to source the pfm.tcl shipped with vivado as you set all the properties like I did it. Then, I did not included them in the Zynq IP.
Otherwise, I would have to connect them to something as they cannot remain unconnected, right? To proof this, I did a simple design with nothing but a clock wizard and their respective reset system ips and followed the same steps that I said. With that custom platform, I was able to move functions to hw without that error.

@Yannick: I have seen the wiki, it shows the same as the UG1236 regarding the definition of the axi ports. As I said, I managed to make it work with a simple design and I just adapted how I set the properties as M_AXI_GP0 and S_AXI_HP0 are used on the fmc-hdmi design. Therefore, I just removed their lines. I'm looking forward for that example

Thank both of you for your help.
Best regards,
Ariel.

Yannick wrote:Hello Ariel,

I have just found the script I talked about yesterday, but I can't see any significant difference between yours and this one... Nevertheless, I had a similar issue and I managed to make it work by replacing parts of this script into mine, even though I could not figure out what the actual problem was.

Hope it will help you,

Yannick

Giacomo_Valente wrote:Ariel,
which board are you using?

Thanks,
Giacomo