_FIRMWARE problem

[rejay015]

Hi dgschwend: I'm trying to port zynqnet on a ZC706 board. I've successfully generated HLS IP using codes under _HLS_CODE, and creat a BD project and generate a ZC706 bit in vivado. Next I create a SDK project and import sources from _FIRMWARE folder. But when I add all the source files under _FIRMWARE folder into Xilinx SDK for embeded arm develop, I met lots of errors, should source files such as processing_element.cpp which is oriented in generating logic be added into SDK project?

Thanks!

[dgschwend]

Hi rejay

Yes these files should also be included, as they allow running the "golden model" on the ARM CPU and thus allow checking the FPGA implementation. What errors do you get?

Regards David

–– David Gschwend • +41 79 552 74 00 • Winkelriedstr. 56 • 6003 Luzern

Am 03.03.2017 um 07:54 schrieb rejay015 notifications@github.com:

Hi dgschwend: I'm trying to port zynqnet on a ZC706 board. I've successfully generated HLS IP using codes under _HLS_CODE, and creat a BD project and generate a ZC706 bit in vivado. Next I create a SDK project and import sources from _FIRMWARE folder. But when I add all the source files under _FIRMWARE folder into Xilinx SDK for embeded arm develop, I met lots of errors, should source files such as processing_element.cpp which is oriented in generating logic be added into SDK project?

Thanks!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[rejay015]

Thanks for answering so quick.

I compile the _FIRMWARE folder with the origin makefile on a PC, the errors disappear. But the "./test CPU indata" works well on PC, not on ARM(./test: cannot execute binary file: Exec format error).

Did you compile the makefile under Debian Linux running on zynq arm ? Or maybe I made some mistake with compile environment settings.

[dgschwend]

You cannot just copy the binary from PC to the ARM, it will not run (it's compiled for a different CPU architecture). You have 2 choices: 1) cross-compile on your PC for ARM architecture 2) compile directly on Zynq (need to have gcc or clang installed)

I had a Linux system with a compiler running on the Zynqbox, so I used 2) for my thesis. Actually, Xilinx SDK should allow you to cross-compile for the Zynq CPU cores if I'm not mistaken...

–– David Gschwend • +41 79 552 74 00 • Winkelriedstr. 56 • 6003 Luzern

Am 07.03.2017 um 13:30 schrieb rejay015 notifications@github.com:

Thanks for answering so quick.

I compile the _FIRMWARE folder with the origin makefile on a PC, the errors disappear. But the "./test CPU indata" works well on PC, not on ARM(./test: cannot execute binary file: Exec format error).

Did you compile the makefile under Debian Linux running on zynq arm ? Or maybe I made some mistake with compile environment settings.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[rejay015]

Danke！ SCS-ZYNQ-BOX is great ! Zynqnet is great too!

[divyapraneetha]

The _FIRMWARE part is compiled and tested on X86 Machine. I tried to run the same code using PS part of ZC702, for which the ZedBoard hang up at booting. I hope that there shouldnt be any problem to run the same _FIRMWARE code using PS part. Correct me if I am wrong.

[divyapraneetha]

Hi David,

I am trying to run _FIRMWARE code on PS part of ZedBoard. When I compiled and ran _FIRMWARE only code on PC, the results are produced. But when ported the same code onto ZedBoard using SDSoC generated sd_card content, the ZedBoard booting was hung. I hope that there shouldnt be any problem to run the same _FIRMWARE code using PS part. Correct me if I am wrong.

Thanks Divya

[dgschwend]

The firmware code should run on almost any processor without causing hangs. It does not influence the booting process, should not even be run during system boot. It's just a plain C program with some memory accesses. You probably have a different problem. What error messages do you get?

[divyapraneetha]

Hi David,

Thanks for reply.

I overlooked this error while building. SDSoC compiling gave the following error for _FIRMWARE code.

src/ZynqNet_Accelerator_HW_DEF/ps7_init.c:7536:10: fatal error: 'xil_io.h' file not found

include "xil_io.h"

     ^

ERROR: [SDSoC 0-0] clang exited with non-zero code processing

I am still figuring out on what could be issue. I have included vivado_include directory in the include directories path for SDSoC.

Divya

[dgschwend]

You do not need to compile the files in "ZynqNet_Accelerator_HW_DEF". Please read the Makefile in the _FIRMWARE directory.

[divyapraneetha]

Hi David,

All the required files in _FIRMWARE are placed in src folder of SDSoC. So the path is like that.

I found that xil_io.h is created after SDK run.

Thanks Divya

[divyapraneetha]

Hi David,

Below is the screenshot of HLS runs. Please ensure the files in TestBench and src are correctly placed. When I tried for C/RTL Cosimulation, I got error message attached below.

What could be wrong in the case. suggest me.

Thanks Divya

[dgschwend]

https://en.m.wikipedia.org/wiki/Segmentation_fault

[divyapraneetha]

Hi David,

I am working on co-simulation using Vivado HLS. I have chosen Verilog for co-simualtion. After the TestBench gave its result, critical warnings are being displayed and they are in a loop (I am running for 24 hours to see if it gets fixed looking after some suggestion in Community Forum)

Warning: OPMODE Input Warning : The OPMODE 0110X0X with CARRYINSEL 000 to DSP48E1 instance is invalid.

While looking for solutions, some one suggested to look after depth.

Warning : [COSIM 212-369] AXI_master port 'memorybus' has a depth of '5932576'. Insufficient depth may result in simulation mismatch or freeze.

Is this not an issue while running co-simulation.

If you have encountered any such problem, kindly suggest.

Looking forward for your suggestion.

Thanks Divya

[dgschwend]

The "problems" are mentioned in the project report. I assume you did read that carefully?

• COSIM 212-369 is a warning, not a problem, everything is safe with the memory depth.
• OPMODE Input Warning "The OPMODE 0110X0X with CARRYINSEL 000 to DSP48E1 instance is invalid." is related to a bug in Vivado HLS, as Xilinx confirmed by email (the OPMODE input to the DSP48 slice contains unknown inputs "X", which are functionally irrelevant, but cause this warning to be displayed). The problem is that this warning slows down co-simulation so much that it's completely unusable (simulation takes days without finishing). I suggest you go on with compilation, bitstream generation, and test the implementation on the target.

–– David Gschwend • +41 79 552 74 00 • Winkelriedstr. 56 • 6003 Luzern

Am 12.04.2017 um 20:44 schrieb divyapraneetha notifications@github.com:

Hi David,

I am working on co-simulation using Vivado HLS. I have chosen Verilog for co-simualtion. After the TestBench gave its result, critical warnings are being displayed and they are in a loop (I am running for 24 hours to see if it gets fixed looking after some suggestion in Community Forum)

Warning: OPMODE Input Warning : The OPMODE 0110X0X with CARRYINSEL 000 to DSP48E1 instance is invalid.

While looking for solutions, some one suggested to look after depth.

Warning : [COSIM 212-369] AXI_master port 'memorybus' has a depth of '5932576'. Insufficient depth may result in simulation mismatch or freeze.

Is this not an issue while running co-simulation.

If you have encountered any such problem, kindly suggest.

Looking forward for your suggestion.

Thanks Divya

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.