How is the block design utilizing a specific IP core supposed to be designed when using the IP C code examples in Vitis?

[arminb73]

When wanting to experiment with different IPs as an example the AXI UART16550 how is one supposed to design the block design in order to make the Xilinx C examples "correspond" well with the exported block design.

As an example. When wanting to experiment with this C code:
https://github.com/Xilinx/embeddeds.../uartns550/examples/xuartns550_intr_example.c

How am I supposed to do the block design connection in Vivado before exporting the hardware to be used in Vitis?

 

[dpaul]

Well I did not completely understand your question.

If you want some software to control your hardware IPs then your software(C code) should run on a microprocessor. It can be a ARM hard macro, or Microblaze or RISCV core and needs to be present within your hardware design. Up to this point, the hardware architecture is this CPU, UART IP, clocks and resets (I will not go in to the details here). After you have such a hardware design ready, you need to export the hardware so that using Xilinx SDK you can write the C code that will run on the targeted CPU.

I see that the .c you have posted above uses interrupts. You need to understand how to design it in hardware and how it is used by the software.

 

[arminb73]

Well I did not completely understand your question.

If you want some software to control your hardware IPs then your software(C code) should run on a microprocessor. It can be a ARM hard macro, or Microblaze or RISCV core and needs to be present within your hardware design. Up to this point, the hardware architecture is this CPU, UART IP, clocks and resets (I will not go in to the details here). After you have such a hardware design ready, you need to export the hardware so that using Xilinx SDK you can write the C code that will run on the targeted CPU.

Your point is well taken. The program does, in fact, need the use of four different IP addresses:

* CPU
* UART
* CLOCKS
* INTERCONNECT
* RESET

What I'm not sure about is how they're meant to be linked together. To ensure that the software code and the hardware design are in sync.

Regards,
Armin

 

[dpaul]

What I'm not sure about is how they're meant to be linked together. To ensure that the software code and the hardware design are in sync.

By "linked together" should I understand hardware connection?
If yes, then take a look at any Xilinx based "Hello World" design using AXI UART16550. All those IPs will be used and connected in such a design.

 

[arminb73]

By "linked together" should I understand hardware connection?
If yes, then take a look at any Xilinx based "Hello World" design using AXI UART16550. All those IPs will be used and connected in such a design.

Yes, indeed hardware connection. Where can I find these designs? Would really appreciate having that as a reference point.

 

[KlausST]

Hi,

maybe there is a misunderstanding about "IP".
IP- core means "Intellectual Property" (post #1)
IP- address means "Internet Prococol" (post #3)

These completely are different things.
An IP core does not need an IP address.

Klaus

 

[arminb73]

Hi,

maybe there is a misunderstanding about "IP".
IP- core means "Intellectual Property" (post #1)
IP- address means "Internet Prococol" (post #3)

These completely are different things.
An IP core does not need an IP address.

Klaus

Sorry, I was too quick on the keyboard. I am discussing the intellectual properties.

 

[FlyingDutch]

Your point is well taken. The program does, in fact, need the use of four different IP addresses:

* CPU
* UART
* CLOCKS
* INTERCONNECT
* RESET

What I'm not sure about is how they're meant to be linked together. To ensure that the software code and the hardware design are in sync.

Regards,
Armin

Hello @arminb73,

the key idea behind such block designs is AXI Bus - Memory-Mapped (with address lines) or Stream(only data - not address lines). Then in HARD-CPU (ARM) there are two parts PS and PL and these parts are comunicating each othert by AXI Busses. On each Block-design is "Adresses Editor" in which you have to map your intefaces into CPU space adresses. Then writting programs in C is writing and reading registers alocated by these adresses. It is difficult and one have to have big experience with doing this.
In this post on polish forum I gave many links to series of lectures related to the topics about you are asking:

https://forbot.pl/forum/topic/20717...-w-xilinx-vivado/?tab=comments#comment-173812

You can translate this WWW page to English with "goole Translate" in easy way.

Best regards

 

[dpaul]

Yes, indeed hardware connection. Where can I find these designs? Would really appreciate having that as a reference point

Look at this Zynq based design using a UART16550....

https://www.edaboard.com/threads/how-is-the-block-design-utilizing-a-specific-ip-core-supposed-to-be-designed-when-using-the-ip-c-code-examples-in-vitis.401690/#post-1730105

 

[niciki]

If I understand you correctly, you are looking for a so called "Vitis Platform Creation" - hardware created in Vivado and then exported to Vitis (a successor of Xilinx SDK).

Vivado example design:

Vitis-Tutorials/Vitis_Platform_Creation/Introduction/02-Edge-AI-ZCU104/ref_files/step1_vivado at 2021.2 · Xilinx/Vitis-Tutorials

Vitis In-Depth Tutorials. Contribute to Xilinx/Vitis-Tutorials development by creating an account on GitHub.

github.com

All you need to do is to run in Vivado the following command in the TCL Console:
source system_step1.tcl
Then the whole project will be generated (with an address map) ready to be exported to use in Vitis.

Reference:

Vitis-Tutorials/Vitis_Platform_Creation/Introduction/02-Edge-AI-ZCU104/step1.md at 2021.2 · Xilinx/Vitis-Tutorials

Vitis In-Depth Tutorials. Contribute to Xilinx/Vitis-Tutorials development by creating an account on GitHub.

github.com

You can search for repos/projects with an IP core of your interest - AXI UART16550.
Often only .tcl files are available in repos.

 

[arminb73]

Consider the following scenario: I want to run these sample applications. Given that these examples are aimed at the UART-lite, I know that the Vivado block design will include the AXI Uartlite IP. Also, because I am working with multiple applications, it is natural for me to assume that the block design must include the Processing system.

What I'm not sure about is how the connections between the IPs are supposed to be made so that the applications make sense.

Please if someone could give me any advice I would highly appreciate it.

The examples are found at the following website:

AXI UART Lite standalone driver - Xilinx Wiki - Confluence

xilinx-wiki.atlassian.net

 

[dpaul]

What you have posted above is the software which runs on a uProcessor that can control the design. But first you must create the hardware design itself before you proceed to write the software for it.

What I'm not sure about is how the connections between the IPs are supposed to be made so that the applications make sense.

If you do not know how to connect clocks, resets and bus in a digital design, then I am afraid you are having a very fundamental problem. Someone has posted vdo tutorials above, have you followed them?
To teach basic things such as port connections is in my opinion out of scope for this forum!

 

[arminb73]

What you have posted above is the software which runs on a uProcessor that can control the design. But first you must create the hardware design itself before you proceed to write the software for it.


If you do not know how to connect clocks, resets and bus in a digital design, then I am afraid you are having a very fundamental problem. Someone has posted vdo tutorials above, have you followed them?
To teach basic things such as port connections is in my opinion out of scope for this forum!

The issue is not connecting the IPs to one another. The issue is how the different IPs are supposed to be connected when the example software design is taken into account.

 

[dpaul]

The issue is how the different IPs are supposed to be connected when the example software design is taken into account.

This is hardware design! You must think about the hardware architecture first, design the hardware itself as the 2nd step and then comes the software part. The reverse sequence will not work.