tuan

Members
  • Content Count

    14
  • Joined

  • Last visited

About tuan

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Dear all I need to make a 1080p60Hz SDI to RGB system, then sending the RGB data to PC via Ethernet. I use a SDI to HDMI converter and ZYBO board to do so. On ZYBO board, I used Xilinx DVI Receiver (SelectIO Interface as shown in the attached image) IP to receive TMDS signal before decoding to RGB image and write it to 2nd half of DDR memory (256MB from address 1000_0000). Xilibus core and the corresponding provided embedded linux are used for other control (SD card, Ethernet) and communication. OS is located in the first half of the DDR memory (256MB from address 0000_0000) and is able to read RGB data from the second half. Since the Zynq 7000 FPGA supports up to 600MHz IO, which is lower than the frequency used for HDMI 1080p60Hz (742.5MHz), I use a SDI to HDMI converter with ability to change frequency from 60Hz to 30Hz so that I can receive 1080p30Hz HDMI as input to the FPGA. OS will read images from 2nd half of memory and send to Ethernet when necessary. My system works now but I face the instability problem, that is: - Received image is slightly different with the original one (this issue may related to the converter and/or the verification system), hence I emphasis to the stability here. - Received images are stable at 720p60Hz (DVI clock is 74.25MHz and serial clock is 371.25MHz), that is there is no different among those images themselves when still image is given to HDMI input. However, when the HDMI input is 1080p30Hz (same DVI and serial clocks as above), there are some different pixels in the blue channel among the received images themselves, especially at the left edge. There is no different in the green and red channel among the received images on my design. Verification (using 3rd party devices) on the SDI and HDMI of the converter shows that the images at SDI and HDMI ports are stable. It means that the instability occurs in my design on FPGA. Report Timing Summary shows that there are some no input/output delay to some ports, setup time violation on xilibus core and reset signal from PS as shown in the attached figures. Clock setting: - ARM PLL: 650MHz - DDR PLL: 525MHz - Clock to my modules for AXI bus control (write to DDR) and other operations: 200MHz - "set_false_path -from [get_clocks clk_fpga_1] -to [get_clocks clk_out1_dvi_dec_clk_wiz_0_0]" and vise versa are used. Do you have any idea on the instability problem, suggestions for a solution as well as timing constrain I should use ? Best regards, Anh Tuan Hoang
  2. Dear miguel In your tutorial, you said that the code modified during OS preparation will divide the DDR memory into 2, a half for OS, and the other half for DDR. "What this does is make Linux see only 256MB of DDR memory (instead of all the 512MB capacity that the DDR has). This is required in order to have a chunk of memory (in this case, 512-256=256MB) reserved for using the AXI DMA engine.". It seems that OS will not touch to the second half. Are there any possibility to make OS reads the second half of memory but still allows user HW writes to it. Problem of read during write might occur but can be controlled if I divide the user HW memory to several banks and swapping them for read and write purpose. Problem on rebuild SDK project: After replacing the user SDK generated fsbl_hocks.c file by the one taken from the zybo_base_system for mac address setting, I have problems with the include of "xiicps.h" and "xiicps_hw.h". I found them on internet and added to the user SDK project but now it has 'XPAR_PS7_I2C_0_DEVICE_ID' undeclared (first use in this function) error occurs in fsbl_hocks.c. I am not sure which I2C this is related to but in my HW design, I replaced the control of PS on I2C of HDMI by a HW version (simply by changing the pins connection) to prevent OS from making HDMI to be output. ==========> I found out that the problem is the difference between the based system I used (xillydemo) and the zybo_base_system. I think I will need some elements generated for xillydemo project by xillybus. I am sorry for many questions. Yours, Tuan
  3. Hi JColvin Thank you. It is completely my checking problem on the page. Tuan
  4. Hello miguel Thank you for your instructions The problem is not there since setting64.sh is executable. I found the problem related to a 32bit library, which must be installed manually: la32-libs. However, I have a problem that is the Vivado on Ubuntu generated error during optimization for implementation as attached file. [DRC 23-20] Rule violation (INBB-3) Black Box Instances - Cell 'xillybus_ins/system_i/vivado_system_i/xillyvga_0/inst/xillyvga_core_ins' of type 'xillybus_ins/system_i/vivado_system_i/xillyvga_0/inst/xillyvga_core_ins/xillyvga_core' has undefined contents and is considered a black box. The contents of this cell must be defined for opt_design to complete successfully. I am not sure why this happen now and will check it and solution latter. I will use the compiled .bit file and export on windows Vivado version for the Step 4: First Stage Boot Loader of Booting Linux on ZYBO (remove Step 3: Building the base design). I have to back to step 1, in which I have to "1) Download the zybo base system from the Digilnets ZYBO product page.". The page shows product, prices and documents for ZYBO but nothing related to design can be found. Do you know where can I download those product? =====> Sorry for this question. It is my mistake in checking the page and being answered by JColvin below. Do you have some comments? Thank you very much. PS. I start my project with this demo file "xillinux-eval-zybo-1.3c.zip" found here http://xillybus.com/xillinux when click to ZyBo at " Download the boot partition kit for your board: Zedboard, ZyBo or MicroZed." (but the current version on that site is is 2.0). Image file for SD card is also received from there. Yours, Tuan vivado_opt_error.txt
  5. Hi miguel I am following your instruction and also the link you gave on how to booting linux on zybo (http://www.dbrss.org/zybo/tutorial4.html). I clean install Ubuntu14.04.5LTS and Xilinx2015.4 on Virtual Box for this purpose. At step 2, after "make zynq_zybo_config", make command gives error as shown in the attached error.txt file. The first path with "No such file or directory" error is confirmed that it is available as shown in the "path_available_confirmed.txt" It is noted on the tutorial: "If you get an error during this step your $PATH environment variable most likely can not find the tools necessary to compile the u-boot." but I have no idea how it can happen and how to solve. Did you meet the same problem and do you have any solution? Yours, Tuan error.txt path_available_confirmed.txt
  6. Dear miguel_rodrigues I just look through your tutorial and related links. I think they can help me to solve the problem of integrating with Linux OS. I will ask you if I have problem during that process. I still have some problems related to input devices. My design will be used with some device with 1080p output (it is said so). For my testing, I have a sony handycam HDR-CX180 with HDMI out, a blackmagic microConverter from SDI to HDMI, a 3G SDI to HDMI from BLUPOW, a multi format converter XC 1 so. All of them show on display as HDMI 1080p. However, signal from the former 2 cannot be recognized in my design (and also cannot be recognized on the HDMI_in project of digillent). The latter 2 have no problems at all. It makes me confused about the 1080p output. Do you have any opinion on that issue? Thank you very much. Tuan
  7. Dear miguel_rodrigues Thank you very much for your solution. I also have some advances in the project but some how in a different manner and would like to ask your experience on some problems that I will need to solve. A. Related to implementation: 1. How to write data to memory: I have a HDMI => RGB converter (with some additional processing will be required from now on) and I also have an interface for writing the generated data to DDR via PS. My AXI interface connects with S_AXI_HP0 of PS (I include my design into the block design of the xillydemo project), so that it can write to DDR. Confirmation on ILA (no OS) shows that the data are written to DDR. Using the same manner (ILA), I can verify that those data can be read back (no OS boot). 2. Physical address map: My AXI interface is set to address 0x10000000~0x1FFFFFFF (256MB). I also modify the address map inside Block Design so that things related to xillybus and xillyvga are assigned to address 0x00000000~0x0FFFFFFF (256MB). 3. OS: I use the original OS image downloaded with the xillydemo project (I think I will need to build it myself to solve the problem but I am not yet know how to) B. Problem when OS boot: after OS booted, data from HDMI still coming but OS blocks my result data from writing to memory. I confirmed this by counting the number of vsync of RGB, number of memory write request and number of memory write acknowledge. Those number are written to registers that can be read back by OS with "hexdump". Confirmation shows the number of vsync gradually increase but number of write_ack and write_req stop after nearly 140000 times. It implies that conversion still continue after OS booted but memory write stopped. C. What I would like to ask for your experience (I think it will relate to building OS kernel but I know just a little on Linux / Ubuntu): 1. How can I ask OS to allow my AXI interface continue writing data to DDR via S_AXI_HP0. The two manners are difference but if writing to DDR via S_AXI_HP0 is acceptable, I prefer it. I am not really experience on this. Could you please give me your comments? 2. How can I ask OS directly read those data from DDR (the above read mentions on A.1. is use for confirmation / debug). PS. Thank you for the link. It contains tons of knowledge for me. Best Regards, Tuan
  8. Dear Jon Thank you very much for your help in finding expert on this issue. Best Wishes, Tuan
  9. @Dan Thank you for many links and comments on location of user memory. I understand the problem of locating my HW data at physical location 00000000 and that is why I mention that it is unreasonable since it will cause conflict with OS. My design writes data to memory using AXI bus and via AXI_HP0 port of PS. Since ILA (without OS operated) shows changes in address generated for AXI writing (to that memory space start from 00000000), and in other testing case, OS starts and normally operates (without ILA monitoring), I suppose that when OS operates, it prevent my design from writing to physical memory space starts from 00000000 (high probability) or OS does not touch to this memory location (low probability) during its operation. And so, I would like to know how to check the memory map and really read data back for verification as well as modify the base address of my AXI interface to available memory space. I am not yet experienced in this, so now, I allow both xillybus and my design access to all the memory space from 00000000 to 1FFFFFFF (attached excel file). I think about (e.g) allowing xillybus (and xillyvga also) accesses to the upper half of the memory (00000000~0FFFFFFF) and my design accesses to lower half (10000000~1FFFFFFF). Since ARM core has a dedicated bus to access DDR (without using AMBA interconnect), I expected that it can access to both of them (it may be normal or stupid thinking but I am not yet having any experience). I confuse that in that case, will OS use the upper half of the memory only (as the use of xillybus) or it still freely use the whole memory (as the use of dedicated bus) and what should I do to make change in device tree, making new /dev/map and mmap. This is also the reason why I think about making a reading mechanism via stream_read, in which memory space issue can be concerned (if using physical memory read - and it will help me to save a a lot of time) or set aside (if using stream_read). I am sorry for many stupid questions. Additional information for my case: Speed is also a problem that I have to face with. In the worst case in terms of speed (speed starving), I have to take FHD image at 30fps from the input, make some simple operations, then write the operated image result (also FHD = 8MB per frame or 240MB/second in my case) to some memory locations so that OS can read them, write to files (if asked) for accessing from outside via ftp. Down sampling (in terms of number of images, not in terms of number of pixels per image) some how acceptable. Now, the processing applied to input images is simple and ZYBO can be used. Later, ZCU 102 will be used since the processing will be image recognition with machine learning. Thank you very much for many links that will help me understand my current problem and finding solution. Tuan AddressEditor.xlsx
  10. Dear jpeyron

    I am Tuan. Dan said that you are expert on embedded Linux aspects of FPGA programming and I have some questions to ask.

    I am developing a design based on xillydemo for ZYBO board, in which my hardware will write image to DDR on ZYBO, then OS (Ubuntu) will read those data and write to file. Current situation is the writing HW (my part) can write data to memory without OS work (I check that the generated address for AXI bus has change via ILA, so PS works but not OS). I assign my design to address 00000000, which I think that OS will over taken when it works (but I don't know where is a good space for my data). The combined design (my HW and xllydemo) shows that OS are normally working but I cannot check if my design successfully write data to memory or not.

    Do you have any suggestion about how can I manage the physical memory? or which physical memory space should I consider as user allocated space by Ubuntu? I find some pages say about directly assess to physical memory from OS using /dev/mem and mmap. Do you know how can I check information on /dev/mem and mmap to know which physical memory are assigned to which device as well as which spaces are assigned to user and also how can I make a physical memory reading from OS in this case (mass reading about 6 MB each time)

    My email is tuanbcvt@yahoo.com.

    The related thread can be found in the link below.

    Thank you very much

    Tuan

     

  11. Thanks Dan I search for the direct reading solution and also found some how similar information you provide, which said that we can direct read and write to physic memory using /dev/map via mmap but my problem is I cannot find how can I check the information about various devices available inside (I develop current design from the xillydemo project). My knowledge on Linux is low, and so I am confused in checking the correct way to use and understand the mmap as well as how Linux control the user memory. Now, I temporary assign my design (HW) to physical memory from address 0. Big image will be written from address 0 but it also sound unreasonable since OS might take this memory for its operation. Thank you for introduce jpeyron. I will write him asking for his suggestion. Tuan
  12. Hi D@n Thank you for your reply. I try so max delay and min delay setting to solve the hold time violation problem and it works. Data transfer from the slower clock domain (74.25MHz) to faster clock domain (200MHz). The min time delay is set to a half the time of the faster clock (2.5ns) and max time delay is equal to 1 faster clock (5ns). With that, I thrown away 1 clock of the faster. This seems not a really good solution because situation may be changed if difference frequencies are used. Your solution is completely good but I have to strictly control the amount and time of data transfer. Hence, in the next time I may try some internal counter inside FIFO IP as your suggestion. Now I turn to an improved version, that is OS (Ubuntu) will be start on ARM and communication occurs via xillybus. The above data will be written to memory (with the design I mention above) and I will need to read those data by OS and write it to file (when needed). I thought about a reading FIFO via AXI bus (in the same manner with the write), then send to OS as a stream (using stream_read command available with xillybus, the mem_read, which access some small dedicated registers will be used for handshaking). Do you know any other better method? like directly read physical memory from OS? Thank you very much. Tuan
  13. @D@n Thank you for valuable document. Concerning to the FIFO, the problem does not happen with the FIFO itself but happen with user designed registers, which are used to communicate about the maximum number of data should be read from FIFO before stop and waiting for the next line. I am trying on this and will report if I found some possible solution. Best Regards.
  14. Dear everybody Dear jameu.hicks Thank you very much for your reply and sorry for my late feedback. I have a mistake in my first post. We need to read RGB data generated from HDMI input, and so DRAM is also good to me. I found a design in Japan which write RGB data to vram via AXI bus so that other module can read and show on display while PS also can access to this data. However I have timing violation problem in synthesis and implementation, that is hold time and setup time violation occur between registers belong to different clock domain (74.25MHz for DVI and 200MHz for PS and also AXI bus for writing converted RGB data to vram). Also, setup time problem occurs inside AXI interconnect module (working at 200MHz). Setting false path among those clock domain causes data enable signal between those 2 domains takes 0 in all the time, and so no data is written into vram. This problem does not happen in reading module (via the AXI interconnect working at 200MHz above). I also tried to make register among different domain locates close to the other by using plan ahead, setting the ASYNC_REG attribute on the flip-flops in the synchronize but non of them works. Do you have any way to solve the timing violation in this case? Best Regards,
  15. Dear everybody. Thanks DIGILENT for their very nice demo on HDMI => VGA converter on ZYBO. I would like to use ZYBO to convert input HDMI image to VGA output and also write result to BRAM for later use. PS should also work in parallel reading those result out (from memory) and written to somewhere via Ethernet. As my understanding, the demo given by DIGILENT for HDMI => VGA converter uses no BRAM. I would like to know if some similar (to my purpose) demo is available and where on the design should I modify to achieve the above purpose. Best Regards,