Tag Archives: fpga

HLS ERROR: [IMPL 213-28] Failed to generate IP. [How to Solve]

Problem Description:

The following problems occur when using HLS to synthesize or package IP
error: [impl 213-28] failed to generate IP
command ‘ap_ Source ‘returned error code

has been tested in HLS of three versions (2018.3, 2020.1 and 2020.2) successively, and all errors are reported. The existing solutions (modifying the file name) do not work

Solution:

Adjust the system time of window to be less than or equal to 2021
this problem can be solved

[Solved] PYNQ load bit error: KeyError: ‘interrupts‘

Problem Description:

In the BD diagram of vivado, the interrupted direct connection between my IP and PS Core

An error occurs when loading the bit file generated by vivado in pynq

Solution:

Add a concat block in the connection between PS and our own IP interrupt line, as shown in the figure below

finally, the bit file can be successfully loaded in pynq

and the final program can output correct results

After vivado joined ILA, the [DRC lutlp-1] problem of error problem was solved

        This article is a summary of my study. If there are copyright or knowledge errors or problems, please contact me directly. Please leave a message
         PS: Based on the principle of knowledge sharing, this blog can be reproduced, but please indicate the source!

catalogue

1. Problem description

2. Cause analysis:

  3. Problem solving:

1. Problem description

         When I debug the project, in order to capture the signal value to observe the timing, I added ILA, and then encountered vivado error when generating bitstream. The warning is as follows:

  The specific error contents are as follows:

[DRC LUTLP-1] Combinatorial Loop Alert: 2 LUT cells form a combinatorial loop. 
This can create a race condition. Timing analysis may not be accurate. The preferred resolution is to modify the design to remove combinatorial logic loops. If the loop is known and understood, this DRC can be bypassed by acknowledging the condition and setting the following XDC constraint on any one of the nets in the loop: 'set_property ALLOW_COMBINATORIAL_LOOPS TRUE [get_nets <myHier/myNet>]'. One net in the loop is u_DdrRdData/NxtRdState[0]. Please evaluate your design. The cells in the loop are: u_DdrRdData/NxtRdState_inferred_i_3, and u_DdrRdData/NxtRdState_inferred_i_8.

2. Cause analysis:

        As shown in the code segment below, the combinational loop is combinational logic, which feeds back to itself without registers. The simplest example is an inverter whose output is fed back to the input to produce an oscillator.

         Therefore, the combined logic signal nxtrdstate for the state machine cannot be used for ILA grabbing!!!

  At the same time, the error can be prompted in the warning message of vivado tool:

This warning is described in ug901 as follows:

  3. Problem solving:

         Do not use ILA to grab the signal value assigned in the combinatorial logic of the state machine!!!

[DRC nstd-1] problem solving of vivado error problem

        This article is a summary of my study. If there are copyright or knowledge errors or problems, please contact me directly. Please leave a message
         PS: Based on the principle of knowledge sharing, this blog can be reproduced, but please indicate the source!

1. Problem description

The vivado error problem warning is as follows:

[DRC NSTD-1] Unspecified I/O Standard: 1 out of 9 logical ports use I/O standard (IOSTANDARD) value 'DEFAULT', instead of a user assigned specific value. 
This may cause I/O contention or incompatibility with the board power or connectivity affecting performance, signal integrity or in extreme cases cause damage to the device or the components to which it is connected. To correct this violation, specify all I/O standards. This design will fail to generate a bitstream unless all logical ports have a user specified I/O standard value defined. To allow bitstream creation with unspecified I/O standard values (not recommended), use this command: set_property SEVERITY {Warning} [get_drc_checks NSTD-1].  NOTE: When using the Vivado Runs infrastructure (e.g. launch_runs Tcl command), add this command to a .tcl file and add that file as a pre-hook for write_bitstream step for the implementation run. Problem ports: SYS_CLK.

  The IO setting interface is as follows:

  The IO working voltage is not clearly defined, so the following operations are required;

2. Solution:

Create a new. TCL file and write the following contents:

set_property SEVERITY {Warning} [get_drc_checks NSTD-1]

set_property SEVERITY {Warning} [get_drc_checks UCIO-1]

set_property SEVERITY {Warning} [get_drc_checks RTSTAT-1]

Add in vivado setting:

  The error warning disappears after recompilation!

Error (12153): Can‘t elaborate top-level user hierarchy

This error message appears when quartus is integrating
find the corresponding code:

from the sensitive list, the register in the always block is asynchronously reset, so during synthesis, the reset end of the register must only be connected with the reset signal, but the code is connected with the synchronization signal other than the reset signal
modification method:
1. Change to synchronization

always@(posedge clk) begin
	if(!rst_n || first_tu_flag) begin
		...
	end

2. Standard writing

always@(posedge clk or negedge rst_n) begin
	if(!rst_n) begin
		...
	end
	else if(first_tu_flag) begin
		...
	end

AR# 57595 – Vivado Synthesis – ERROR: [Synth 8-4169] error in use clause: package ‘xxx‘ not found in

AR# 57595
Vivado Synthesis – ERROR: [Synth 8-4169] error in use clause: package ‘xxx’ not found in library ‘yyy’
Description
I am encountering the following error when running Synthesis in Vivado. How can I resolve it?
ERROR: [Synth 8-4169] error in use clause: package ‘xxx’ not found in library ‘yyy’
Solution
This error occurs because the package file ‘xxx’ is not compiled into library ‘yyy’.
This can happen when the package file is not added into project sources at all or is compiled into a different library, for example xil_defaultlib.
To resolve this error, make sure that the package file is added into design sources and set its Library name to ‘yyy’.
Right click on file ‘xxx’ in the “Sources” window -> Select “Set Library…” -> Change the Library name to ‘yyy’

Vitis: platform out of date, makefile error at compile time; The modified application compiles to undefined reference

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

Ubuntu starts Xilinx vivado

1, if you are the current user is hadoop , enter the directory is /home/hadoop
/ code>
3, the end of the file with source/opt/Xilinx/Vivado/2016.4/settings64. Sh
4. If not, start the file source.bashrc