SDSoC 2017.4 issues creating platform

Available to be read by all.
User avatar
Timoteo
Posts: 130
Joined: Thu Jun 09, 2016 11:47 am

SDSoC 2017.4 issues creating platform

Postby Timoteo » Tue Aug 14, 2018 9:31 am

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

Ariel_Podlubne
Posts: 73
Joined: Wed Oct 04, 2017 4:41 pm

Re: SDSoC 2017.4 issues creating platform

Postby Ariel_Podlubne » Tue Aug 14, 2018 9:38 am

The issue comes when I adapt sundance's hdmi input-output in vivado 2017.2 to 2017.4 and I update avnet's hdmi IPs and some minor details to adapt them to the new aes fmc_hdmi boards. For this, the bitstream is generated correctly but the main issue appears on SDSoC.

I have just created a new design from scratch in vivado where I have the PS plus an axi dma and an axi4 fifo. Based on this, I use the same script to configure the pfm, create a new platform on SDSoC and successfully tested a very simple application. The design and the script are shown below:

Image

Code: Select all

set_property PFM_NAME tulipp_dma [get_files *.bd]

set_property PFM.CLOCK { \
    FCLK_CLK0 {id "0" is_default "true" proc_sys_reset
"rst_ps7_0_50M" } \
    FCLK_CLK1 {id "1" is_default "false" proc_sys_reset
"rst_ps7_0_100M" } \
    } [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_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]


I will try to create a new project and add the IPs manually following the the hdmi input-outpt that I merged sundance's design with our new aes fmc-hdmi board. Although, this approach is very error prone. Any suggestions? Is there a way to reset all pfm configurations, or something like that?

Ariel_Podlubne
Posts: 73
Joined: Wed Oct 04, 2017 4:41 pm

Re: SDSoC 2017.4 issues creating platform

Postby Ariel_Podlubne » Tue Aug 14, 2018 2:43 pm

That error is not showing anymore. I called the project name, set the dsa.name property plus the PFM_NAME all the same. Regardless, now after ~30 minutes building, I get this error:

Code: Select all

===>The following messages were generated while  Compiling (bitstream) accelerator binary: bin Log file: C:/TULIPP/SDSoC/tulipp_7z30_aes_fmc_hdmi/workspace/testApp/Debug/_sds/p0/_vpl/ipi/imp/imp.runs/impl_1/runme.log  :
ERROR: [VPL-4] Design failed to meet timing.
    Failed timing checks (paths):
   {design_1_i/fmc_imageon_hdmii_yuv422/avnet_hdmi_in_0/U0/spdif_r_reg/C --> design_1_i/fmc_imageon_hdmio_yuv422/avnet_hdmi_out_0/U0/hdmio_spdif_o_reg/D}

    Please check the routed checkpoint (dr_routed_timing.dcp) and timing summary report (dr_timing_summary.rpt) for more information.
ERROR: [VPL 60-704] Integration error, problem implementing dynamic region, route_design ERROR
ERROR: [VPL 60-806] Failed to finish platform linker
ERROR: [SdsCompiler 83-5019] Exiting sds++ : Error when calling 'C:/SdSoC/SDx/2017.4/bin/vpl  --iprepo C:/TULIPP/SDSoC/tulipp_7z30_aes_fmc_hdmi/workspace/testApp/Debug/_sds/iprepo/repo  --iprepo C:/SdSoC/SDx/2017.4/data/ip/xilinx  --platform C:/TULIPP/SDSoC/tulipp_7z30_aes_fmc_hdmi/workspace/tulipp_7z30_aes_fmc_hdmi/export/tulipp_7z30_aes_fmc_hdmi/tulipp_7z30_aes_fmc_hdmi.xpfm  --temp_dir C:/TULIPP/SDSoC/tulipp_7z30_aes_fmc_hdmi/workspace/testApp/Debug/_sds/p0  --output_dir C:/TULIPP/SDSoC/tulipp_7z30_aes_fmc_hdmi/workspace/testApp/Debug/_sds/p0/vpl  --input_file C:/TULIPP/SDSoC/tulipp_7z30_aes_fmc_hdmi/workspace/testApp/Debug/_sds/p0/.xsd/top.bd.tcl  --target hw   --save_temps  --kernels sum --webtalk_flag SDSoC  --remote_ip_cache C:/TULIPP/SDSoC/tulipp_7z30_aes_fmc_hdmi/workspace/ip_cache '
sds++ log file saved as C:/TULIPP/SDSoC/tulipp_7z30_aes_fmc_hdmi/workspace/testApp/Debug/_sds/reports/sds.log
ERROR: [SdsCompiler 83-5004] Build failed

make: *** [testApp.elf] Error 1

15:00:40 Build Finished (took 34m:11s.175ms)


Any ideas?

User avatar
Timoteo
Posts: 130
Joined: Thu Jun 09, 2016 11:47 am

Re: SDSoC 2017.4 issues creating platform

Postby Timoteo » Fri Aug 17, 2018 11:49 am

Does the Vivado project you've created for the platform build successfully, independently from SDSoC, generating a bitstream?

Ariel_Podlubne
Posts: 73
Joined: Wed Oct 04, 2017 4:41 pm

Re: SDSoC 2017.4 issues creating platform

Postby Ariel_Podlubne » Mon Aug 20, 2018 8:16 pm

I had some critical warnings in Vivado due to some errors on the xdc file. Solved that and now I managed to built the project in SDSoC. A simple hello world worked. The hdmi input/output compiled but I got an error that the output buffer could not be written.

I would say that we can close or delete this thread.

Giacomo_Valente
Posts: 12
Joined: Fri Nov 17, 2017 8:28 pm

Re: SDSoC 2017.4 issues creating platform

Postby Giacomo_Valente » Tue Aug 21, 2018 11:39 am

Ariel,
which board are you using?

Thanks,
Giacomo

Ariel_Podlubne
Posts: 73
Joined: Wed Oct 04, 2017 4:41 pm

Re: SDSoC 2017.4 issues creating platform

Postby Ariel_Podlubne » Tue Aug 21, 2018 4:12 pm

Giacomo_Valente wrote:Ariel,
which board are you using?

Thanks,
Giacomo


I am currently using the 7Z30.


Return to “FAQ about Tulipp Development Platform”

Who is online

Users browsing this forum: No registered users and 11 guests