reference material:

https://forums.xilinx.com/t5/Embedded-Development-Tools/Drivers-and-Makefiles-problems-in-Vitis-2020-2/td-p/1188742

https://forums.xilinx.com/t5/Embedded-Development-Tools/Vitis-2019-2-LWIP-Echo-Server-Template-Build-Error/td-p/1124509

Working environment:

2020.2vitis

Main contents:

1. Out of date problem in platform

2. Platform adds a custom IP core, and makefile appears   Error, use version 1 makefile to solve the problem

3. After using version 1 makefile to solve the platform compilation problem, the undefined reference error appears in the application, and version 2 makefile is used

(therefore, if you need to change Makefile, please modify it according to different versions of Vitis. Mine is version 2 of Vitis 2020.2.)

Problem 1. The platform has an out of date problem

After vivado exports the hardware platform xsa, we add it to the platform project of Vitis. We need to check whether the platform version is out of date. If it is out of date, we need to update it.

If out of date occurs, the direct way is to clean the platform and compile the build project. Generally speaking, as long as the compilation passes, the out of data flag will disappear, and you can add an application project for writing.

Problem 2. The platform failed to compile, resulting in makefile error

After many times of clean and build operations on platform project, the following problems are prompted: makefile error. All the problems point to makefile.

(the following part is about my own hard journey to solve the problem, which ended in failure. The final solution is at the end, please drag it to the end by yourself)

  Possible solutions for online search:

1. As Xilinx forum said, modify the make file

2. It may be due to the system. Win10 will report an error. Therefore, it can be implemented with Vitis on Linux

3. Version mismatch vivado hls2018 should be more Vitis hls2020

Try (to find out the problem by comparison)

1. The vivado provided by elder martial brother directly exports the hardware, and there is corresponding driver in the driver (see desktop, Fuxian), successful!!!!

2. Using the simplest HLS generated in 2018_ Color IP, export hardware. There is a corresponding driver in the driver, (desktop, my) report an error

3、（my_ treshold_ Vivado folder) uses the HLS generated in 2018_ color,hls_ Threshold: export the hardware, and the corresponding driver (desktop, my) in the driver reports an error. Therefore, it is not the difficulty of IP core writing.

4. Use the gravity method IP core written by myself to report black box and error in vivado part.

We are still investigating the causes.

5. Updata folder: updata try to use the effect of updating xsa file directly in senior brother’s Vitis project. Failure.

Update method website:
0 https://forums.xilinx.com/t5/Design-and-Debug-Techniques-Blog/Step-By-Step-Guide-To-Xilinx-SDK-Project-Migration-To-Vitis/ba-p/1050061

6. Find a simple Vitis project, interface two streams, simple addition and subtraction assignment in the middle. The IP core (my) is derived from 2020.2 Vitis HLS and 2018.3 vivado HLS_ 2018duizaho_ Vivado: the vivado project with the 2018vivado example core; my_ 2020vitis_ Vivado: the vivado project of the 2020 Vitis core, which contains the xsa of the + CVT core       vitis_ Xsa of the example core exports the hardware platforms of these two projects to Vitis, all through..

This part is to explore whether using different versions of HLS implementation is the cause of the problem.

(compared with vivado project, the program used for the first time is too simple to generate driver in Vitis, and both of them pass the test.)

Set up the control group picture

Results and summary of the control experiment

Finally, it ended in failure. It is mainly suggested that Vitis HLS after calling the vision library, call the function to generate driver for comparison, and we can see the effect, because of time, about Vitis.   After HLS vision, we are trying.

The final solution:

Special thanks to the author of this post, will show the details, thank you!!!

reference: https://forums.xilinx.com/t5/Embedded-Development-Tools/Drivers-and-Makefiles-problems-in-Vitis-2020-2/td-p/1188742

reason:

In vivado 2020.2, 2018.3 vivado is added   HLS custom IP core. In 2020, the content of makefile has changed, resulting in an error when compiling the makefile of this IP. The makefile file in the IP file needs to be modified manually.

resolvent:

Varas’s method on Xilinx forum solved this problem. Thank you very much.

To ensure that the corrected makefile is replaced in the three directories of the platform:

Platform/hw/drivers/< CustomIP_ name>/ src/MakefilePlatform/ps7_ cortex_ a9_ 0/standalone_ domain/bsp/ps7_ cortex_ a9_ 0/libsrc/< CustomIP_ name>/ src/Makefile Platform/zynq_ fsbl/zynq_ fsbl_ bsp/ps7_ cortex_ a9_ 0/libsrc/< CustomIP_ name>/ src/Makefile

In addition, there are two different makefiles according to different versions of Vitis.

Version 1:

I only changed two of the lines: the content of. O changed to the following two lines. Other locations such as the clean section have not been changed.

OBJECTS = $(addsuffix .o, $(basename $(wildcard *.c)))
ASSEMBLY_OBJECTS = $(addsuffix .o, $(basename $(wildcard *.S)))

After these three major changes, your project will be built correctly and your custom IP will work!

The following is the makefile file required, you can modify it according to the original code.

COMPILER=
ARCHIVER=
CP=cp
COMPILER_FLAGS=
EXTRA_COMPILER_FLAGS=
LIB=libxil.a

RELEASEDIR=../../../lib
INCLUDEDIR=../../../include
INCLUDES=-I./. -I${INCLUDEDIR}

INCLUDEFILES=*.h
LIBSOURCES=*.c
OBJECTS = $(addsuffix .o, $(basename $(wildcard *.c)))
ASSEMBLY_OBJECTS = $(addsuffix .o, $(basename $(wildcard *.S)))

libs:
	echo "<CustomIP_name>..."
	$(COMPILER) $(COMPILER_FLAGS) $(EXTRA_COMPILER_FLAGS) $(INCLUDES) $(LIBSOURCES)
	$(ARCHIVER) -r ${RELEASEDIR}/${LIB} ${OBJECTS} ${ASSEMBLY_OBJECTS}
	make clean

include:
	${CP} $(INCLUDEFILES) $(INCLUDEDIR)

clean:
	rm -rf ${OBJECTS} ${ASSEMBLY_OBJECTS}

Problems with this version:

In the later application compilation, if the new IP core function is not used, there will be no problem. However, once the new IP kernel function is used, an error will be reported:

Compile small, error message for the following figure 1, 2

If the compilation is large, the error is:

The reasons are as follows:

https://forums.xilinx.com/t5/Embedded-Development-Tools/Vitis-2019-2-LWIP-Echo-Server-Template-Build-Error/td-p/1124509

The main reason is:

If you prompt that the missing functions have been compiled in the BSP file, you can see them in the. O file. If it’s compiled correctly, the only reason for missing function errors in the linker is that the correct libxil. A file is not linked.

The core problem is that makefile is not written correctly.

So do I have to use the makefile of version 2 (copied from the makefile of other functions) or change the three parts mentioned above

DRIVER_LIB_VERSION = 1.0
COMPILER=
ARCHIVER=
CP=cp
COMPILER_FLAGS=
EXTRA_COMPILER_FLAGS=
LIB=libxil.a

CC_FLAGS = $(COMPILER_FLAGS)
ECC_FLAGS = $(EXTRA_COMPILER_FLAGS)

RELEASEDIR=../../../lib/
INCLUDEDIR=../../../include/
INCLUDES=-I./. -I$(INCLUDEDIR)

SRCFILES:=$(wildcard *.c)

OBJECTS = $(addprefix $(RELEASEDIR), $(addsuffix .o, $(basename $(wildcard *.c))))

libs: $(OBJECTS)

DEPFILES := $(SRCFILES:%.c=$(RELEASEDIR)%.d)

include $(wildcard $(DEPFILES))

include $(wildcard ../../../../dep.mk)

$(RELEASEDIR)%.o: %.c
	${COMPILER} $(CC_FLAGS) $(ECC_FLAGS) $(INCLUDES) $(DEPENDENCY_FLAGS) $< -o $@

.PHONY: include
include: $(addprefix $(INCLUDEDIR),$(wildcard *.h))

$(INCLUDEDIR)%.h: %.h
	$(CP) $< $@

clean:
	rm -rf ${OBJECTS}
	rm -rf $(DEPFILES)

Using this version to compile, platform and application do not report errors