VSI version problem? about visual-system-integrator

[MenezesM]

Hi Mrdwq,

I just tested the release from the web and vivado 2018.2 install and did not have any issue creating the platform. The warning you got was normal for the release and should not had prevented you from creating the platform.

If you could send me the entire tcl console I believe would be able to help you get past this issue.

Another option would be to download the preview release from our website, it is working with Vivado 2019.2 and has a lot of bug fixes and new features from the release that you have.

Thanks,

Matt

[Mrdwq]

Hi Matt,
I configured the cross-compile environment for gcc-linaro-arm-linux-gnueabihf and solved the problem.
There are still some questions I want to ask.

Since I installed VSI and Vivado in a vmware ubuntu16.04 virtual machine following the install instruction in https://systemviewinc.com/docs/2019.2/installation/linux.html. What else dependencies should I install except for gcc-linaro-arm-linux-gnueabihf. If so, are they alreaday in the VSI repository?

As you said, I downloaded VSI 2019.2. Is it ok to use VSI 2019.2 with Vivado 2018.2?

I used VSI 2019.2 with Vivado 2018.2 to create an example project following the guide in the link
https://github.com/systemviewinc/tutorials/blob/master/dfx_with_systemview/README.md.

In step 9 Open the Platform, there is a paragraph saying"The connections between execution context show how they communicate, and represent a communicate channel between two execution contexts. In this example platform, the ARM processor (u96_ps) communicates with the programmable logic (u96_pl) using a driver and the VSI common interface. The ARM processor also communicates with the r5 processor(u96_r5) using OpenAMP. The platform canvas is the workspace provided to develop a platform for an application."
So I connected M_AXI to PLAT_INTERFACE. The diagram is as follows. Is there any extra line should be added?

In step 11 Create the System, there is a tcl command:
vsi::import_yaml_system [current_bd_design] <<path_to>>system_hw_pr.yaml
but I didn't find the system_hw_pr.yaml.

In the end, Is there any plan that documentation about VSI be updated or added?

Thanks,
Mrdwq

[MenezesM]

HI Mrdwg,

Glad you could get past the first part.

VSI 2019.2 will not work with Vivado 2018.2, you will want matching versions due to IP versions / feature changes between releases.

On Step 9: The blocks u96_ps and u96_pl are hierarchies, the document talks about the blocks inside that are connected together. If you open up the hierarchies by pressing the plus on the top left corner you should see a block called "vsi_common_driver_0" and that should be connected to something called "vsi_common_interface". It should look like this after creating the example project already:

If you had to connect M_AXI to PLAT_INTERFACE on the top level I think something went wrong already (if you were using VSI 2019.2 with Vivado 2018.2 the IP versions don't match up anymore and will cause an issue I just tested it)

For step 11 you are right, I forgot to link the yaml file. If you look in that document now you can find a download link for it under "Prerequisites".

As far as any updates to documentation we are more than willing to update anything that is wrong, old, and also add anything that is missing.

If you would like to setup a meeting I can help you get started and answer any other questions you have.

Thanks,

Matt

[Mrdwq]

Hi Matt,
I've installed VSI 2019.2 and Vivado 2019.2. When following the guide in https://systemviewinc.com/docs/2019.2/usage/getting_started.html, I met a problem that building the executables for Software Contexts failed. And the tcl console is as follows.
sw_build.txt
It's a crosses initialization error which I think may be corresponding to gcc or g++ compiler. As I said before, I configured the cross-compile environment for gcc-linaro-arm-linux-gnueabihf-4.9 and installed cmake 3.5.1. I'm not sure if I set the environment right so I wonder if you can help me figure it out.
I also uploaded my example project, just in case.
project_1.tar.gz

[MenezesM]

Hi Mrdwg,

I just download the gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf from https://releases.linaro.org/components/toolchain/binaries/7.3-2018.05/arm-linux-gnueabihf/, the 4.9 version was having mismatches. But I was able to build your project with this version. I'm not sure why your compiler is behaving differently. I do see that the error you have is not always considered an error by different compilers.

Since you are using the newer version of VSI I recommend running the following commands to start VSI now:

source <>/settings.sh
source ${VSI_INSTALL}/settings.sh

Doing these commands should get your environment correct and make the process much easier.

Give that a try to see if it helps.

Thanks,

Matt

[Mrdwq]

Hi Matt,
Here is my steps:

1. environment variables in ~/.bashrc

2) source $VSI_INSTALL/settings.sh 3) launch vsi

In this way, building hls and sw is ok. But when I built hw, the tcl console is as follows.
tcl_console.txt
this part
vsi_hw: WARNING: [Vivado 12-8222] Failed run(s) : 'zynq_pl_mm2s_vsi_gen_ip_0_in_arr_0_synth_1'
vsi_hw: wait_on_run: Time (s): cpu = 00:00:01 ; elapsed = 00:15:43 . Memory (MB): peak = 2207.473 ; gain = 0.000 ; free physical = 2915 ; free virtual = 5119
vsi_hw: progress: 0%
vsi_hw: ERROR: Run did not finish. Check runme.log.

I think error occurred.
so I open the runme.log in /home/dwq/Documents/Workspace/project_1/vsi_auto_gen/hw/system_1/build/zynq_pl/zynq_pl.runs/zynq_pl_mm2s_vsi_gen_ip_0_in_arr_0_synth_1
runme.log

and the error goes like this:

ERROR: [Synth 8-5826] no such design unit 'fifo_generator_v13_2_3' in library 'fifo_generator_v13_2_3'

design unit 'fifo_generator_v13_2_3' seems not in library. Is it a error about PATH setting?

.

[MenezesM]

Hi Mrdwg,

It looks like you ran all the step correctly.

Could you tell me the file name for the download you got from our website? It looks like you will want the systemview_vsi_20200229_080834.tar.bz2, any earlier releases will still be for vivado 2019.1

The libray error comes from the version of vivado and version of the version of libraries used in our IPS. If they do not match up there will be issues.

If you didn't get the 20200229 version of VSI you can download it here: https://s3.amazonaws.com/systemview/files/latest/systemview_vsi_20200229_080834.tar.bz2

Thanks,

Matt

[Mrdwq]

It's systemview_vsi_20200220_002620.tar.bz2

[MenezesM]

You will need to try the link I pointed you to. The fix was put in place after the version you download.

[Mrdwq]

Hi Matt,
1.
I tried to build simulation following the guide in vsi_manual.pdf(in VSI install package).

Here is the tcl console:
tcl_console.txt
It is like"Cannot find the top function 'process_data' in the design. Possible causes are: (1) the top function name is misspelled; (2) the top function is nonexistent or declared as static."
The process_data is chosen as the picture shows.

I wonder if there are some other steps needed?
Here is the project, just in case.
simulation_example.tar.gz

I reading the documentation in https://systemviewinc.com/docs/2019.2/usage/user_guide.html, there are some staffs inconsistent with 2019.2 VSI.

Is packed data and variable length the same thing?

I tried to use java and python support following the documentation in https://systemviewinc.com/docs/2019.2/usage/python_java.html. I failed to connect process_tcp1 to process_stream because process_stream doesn't has any port as the following picture shows.

project was alse uploaded.
project_2.tar.gz

Thanks,
mrdwq

[MenezesM]

Hi Mrdwq,

1. For "build hls" error you are going to have to go to the source code a move the function:
   void process_data(hls::stream<int> & in_s, hls::stream<int> & out_s)
   below the bottom of the:

#ifndef __VSI_HLS_SYN__
...
#endif

#ifndef VSI_HLS_SYN is used to excluded non synthesizable code from a file so that HLS can parse the rest of it. I will fix this for the next release.

2. Packed data is for data input/output that is in a struct, by selecting packed data it will bundle each element of the struct together. For the simulation section you will not want to use it.

3. This looks like another issue we need to fix for the next release. To work around this issue you can select the block with the problems and type the following command in the tcl window:

set_property CONFIG.P01_param_type 1 [get_selected_objects ]
set_property CONFIG.P00_param_type 1 [get_selected_objects ]

That should get you going again.

Thanks,

Matt

[Mrdwq]

Hi Matt,
Thanks for your reply. Please excuse me for bothering since I still have some questions to be answered.
1.
I tried to builed vsi_dfx project following the tutorial in https://github.com/systemviewinc/tutorials/blob/master/dfx_with_systemview/README.md.
My VSI version is 2019.2 now and vsi::import_yaml_system failed to import system_hw_pr.yaml you uploaded before, so I build the system diagram on my own. The picture is as follows(screenshot only since the project is too big to be uploaded).

System was generated and HLS was built successfully. But building software context failed and the error info is as follows.

I tried to solve most of them by creating soft link but can't figure out what RLAgent and RLOta mean.

2.
In https://github.com/systemviewinc/tutorials/blob/master/dfx_with_systemview/README.md, The example platform--ultra96_platform is comprised of two software contexts (the ARM processor and the r5 processor) and one hardware context (the programmable logic).
To my understanding, the number of context is corresponding to the hardware architechture, which means that if I have chosen the ultra96 board, I can create "only one software context" or "one software context and one hardware context".But the max number is limited to 3 which is consistent with the hardware architechture.
However, a phrase in https://systemviewinc.com/docs/2019.2/usage/concepts_workflow.html says" there are no restrictions to the number of “Execution Contexts” in the system." , which makes me confused.
3.
In example platforms of VSI 2019.2, ultra96_platform is consistent with its hardware architechture but ZCU104_platform isn't which should have comprised of 3 execution contexts--arm64, r5 and pl(or it's a bug to be fixed?). So what rules should I follow to design a new platform or to choose an example platform compilant with a board?
I find that there isn't a zcu102platform in example project. Am I expected to design a new platform or turn to similar platform in example platform, such as mpsoc?

Thanks,
mrdwq

[MenezesM]

Hi mrdwq,

1. For the first issue you could fix it with the following command:

`set_property -dict [list CONFIG.library_directories {} CONFIG.shared_libraries {}] [get_bd_cells u96_ps/vsi_context]'

there was some libraries put in the platform that should not had been, so by removing them it will solve your problem. This is something I will need to fix for future releases.

2. You are right, the number of context corresponds to your hardware architecture, but there is not limit for the number of contexts you can have in a platform. The platforms that you start with are example and if you would like to add more contexts, inputs/outputs, or may other things you are able to do so.

Most of the example platforms describe one board or one SOC, but when creating your project you can put multiple multiple boards into a single platform and VSI will handle that and output a binary executable for each software context and a bin file for each hardware context.

3. Like I said before the platforms that we give out are just examples, so for the ZCU104 if we didn't add a r5 context (or something else that you would like) you can add it yourself. But you raise a good point and the example for zcu104 should also have a r5 context.

If what I said above isn't clear feel free to ask more questions. And we think it is great that you are testing out VSI so don't feel bad for asking questions.

Thanks,

Matt

[Mrdwq]

Hi Matt,
I did what you had said but there are still some errors.

The errors correspond to opencv. I followed the instruction in https://github.com/systemviewinc/tutorials/blob/master/dfx_with_systemview/README.md and downloaded the rootfs in the above link, and the path was set as follows.
.
I wonder if there is something I miss. You can clone the project in https://github.com/Mrdwq/test if needed.

Thanks,
mrdwq

[MenezesM]

Hi Mrdwg,

It looks like when you are building the compiler is getting the xilinx opencv headers before the ones that we are linking in the library.

Can you make sure you in your VSI context that you have "$(SYSROOT)/../" included before the vivado includes?

It should look something like this under include directories:
$(SYSROOT)/../,/tools/Xilinx/Vivado/2019.2/include

A work around we did to get the right included to be selected first was we created a link to our opencv libraries in the "u96_image" folder. You should see a symbolic link called "opencv2" going to "./rootfs/usr/include/opencv2/". If changing the order of includes does not work could you make sure that that symbol link is correct and also make sure your sysroot environment variable points to "u96_image/rootfs" and not just "u96_image"

Thanks,

Matt

[Mrdwq]

Hi Matt,
Building Software Context succeeded after I switched the position of two paths. But building hardeware failed. Here is the tcl console.
tcl_console.txt
Is it an error corresponding to the pl settings in platform canvas inconsistent with hardware context in system canvas?

Thanks,
mrdwq

[MenezesM]

Hi Mrdwg,

There are a few bugs we found with the 19.2 vivado release regarding partial reconfiguration (PR) that we are trying to work around. Right now the preview doesn't have PR working.

If you would like to try to build the system without PR you could do delete the PR set blocks and ungroup the hierarchies. The following commands do the same:

delete_bd_objs [get_bd_cells u96_pl/pr_set_0_0/pr_set_0] [get_bd_cells u96_pl/pr_set_0_1/pr_set_0] ungroup_bd_cells [get_bd_cells u96_pl/pr_set_0_0] [get_bd_cells u96_pl/pr_set_0_1]

It should work the same, just without PR.

Thanks,

Matt

[Mrdwq]

Hi Matt,
1.
I canceled the load on demand in hardware context and building hardware succeeded.
Is the warnings in the tcl_console_part.txt corresponding to HLS programming and is there any method for optimizing provided by VSI?
2.
Is it better to place the IP that comes with Vivado in platform canvas rather than in system canvas?
I saw the videos in the VSI website and IPs like block memory generator are placed in platform whose interfaces are exposed in system canvas.
what are the element components to form a pl hardware context? I noticed most of the staffs in the following picture are needed such as VSI common interface and soc but some differ according to board.

Thanks,
mrdwq

[MenezesM]

Hi Mrdwq,

1 - Yes we do have some some optimizatioj for HLS, right now if you go to your <>/vsi_auto_gen/hls/<> you should see an folder for each HLS block you have. Here you can do
make explore
and it should build again a couple times attempting to optimize the HLS.

Then if you go back to the vsi auto gen IP and look at the HLS report tab you will be able to pick when version to use.

2 -The key concept of the platform is that is describes the "infrastructure" of your system. Meaning how different contexts communicate with each other. In most of the basic platforms we describe how the process communicates with the common interface, and that is mostly what you see in the picture above.

The platform canvas has direct access to external interfaces and pin, so there are times you will want to put IPs that talk to outside interfaces (like the UART in the image above) in the platform instead of the system.

Lastly there are times where the board has required IP for power up / clocks / resets or other uses that you are not really controlling with VSI and these types of IP will stay in the platform. For example there may be some slaves control on a I2C bus and the software control this I2C bus may be built into the linux kernel for the board. If you do not plan using VSI to control the I2C bus and instead leave it the kernel then it should be left in the platform.

[Mrdwq]

Hi Matt,
1.

According to the above picture, both state and key value will be transferred, how can I figure which data is for mode and which data for p_param?

Why 0x10 is chosen in the if phrase? And I searched for the internet, 0x52 and 0x54 represent R and T in keyboard respectively, right?

Thanks,
mrdwq

[sandeepdutta]

Hello Mrdwq, Yes you right this is not the best way to code this connection. We are essentially using the same “control” stream to send the “mode” and the “key_stroke” . We are encoding the mouse event (mode) between 0-1 , and the encoding the key_strokes to >= 0x10 .. so we check if > 0x10 then assume it is key_stroke else it is a mode. Hope that helps. Sandeep

…

On Mar 17, 2020, at 8:02 AM, Mrdwq ***@***.***> wrote: Hi Matt, <https://user-images.githubusercontent.com/49830883/76868796-62cfd600-68a2-11ea-88c2-240c069b0b14.PNG> According to the above picture, both state and key value will be transferred, how can I figure which data is for mode and which data for p_param? <https://user-images.githubusercontent.com/49830883/76869234-f7d2cf00-68a2-11ea-9703-4a0568e8d91e.PNG> Why 0x10 is chosen in the if phrase? Thanks, mrdwq — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#257 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2SPBZCNWI5HIUU7NPEYXDRH6GG5ANCNFSM4K34XILA>.

[Mrdwq]

Hi Matt,
I've editted the last post so that it was a post only corresponding to code and thank Sandeep for reply.
Here are some questions about VSI.
1.
According to https://systemviewinc.com/docs/2019.2/usage/user_guide.html, a phrase says "This field is not used when the “Type” is “Reference”". So why the Max Packet Size of arguments in system_hw_pr.yaml is set to -2 or 8?
2.
I didn't find variable length as an option in VSI 2019.2. So how are the following two wrapper actions described?

3.
How is a Vivado functional IP connected to a C++/C code block in Hardware Context? Typically a Vivado IP has clk, rst, enable, etc. I noticed that in all the tutorials there are only C++/C based blocks in Hardware Conetxt and more stress is laid on the data flow in system canvas. So is it expected that an IP be placed in platform and only its data interface be exposed to system canvas which a C++/C based block is connected to?
4.
To my understanding, VSI System(in system canvas) and Platform(in platform canvas) both can be considerred as a system and VSI system is a higher level one comparing to platform. VSI system compiler and VSI common interface act as important roles in building the bridge between VSI system and platform.
Please correct me if I get it wrong.
5.
Still the python support problem. I tried to build a project following https://systemviewinc.com/docs/2019.2/usage/python_java.html and create the input and output interface in the way you told me but there is an error. I tried to add python path in include directories of vsi_context but it didn't work.
console.txt
Project file is as follows.
project_2.tar.gz
6.When building software conetxt of a previous simulation project, an error occurred.
console_simulation.txt

I just did the common connection as usual so this error is confusing.
Here is the project.
simulation_example.tar.gz
7. How to extend the license by the way since I can't fill in the information in https://systemviewinc.com/license.html
Thanks,
mrdwq