Are there any example for HDMI => VGA converter that VGA reasult stored on BRAM also

[tuan]

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,

[tuan]

8 hours ago, D@n said:

@tuan,

So, as long as you remember that I've never worked with a zynq chip, zybo or otherwise ...

First, /dev/mem doesn't give you access to user memory, but rather to physical memory.  The relationship between the two is usually controlled by the kernel, with the exception of any hardware memory maps within physical memory.  While user memory may be moved in and out of physical memory, device memory typically cannot be moved.

If you wish to work with the memory map, you need to understand memory-mapped I/O.  Indeed, when working with FPGA IP, it's often easiest to map that IP to various locations in memory.  Such memory maps make it easy/simple to have the CPU control your FPGA logic.  Indeed, nearly all of my designs use memory mapped I/O to communicate between the CPU and the FPGA logic.

As an example, I have a memory map that I have created for my peripherals on the Arty.  You can see the .h defining where things are here, and read about the plan for it in the specification here (Chapt 6).  Knowing how to access registers via /dev/mem starts with knowing where the registers for your peripherals are (such as I just listed above), and then knowing what the registers do when you read or write them.  For example, reading/writing an address in video memory will (usually) adjust a pixel on a screen.  To do this, though, requires that you know where the video memory is, the number of bytes per row, and the number of bits per pixel, how colors are stored in memory, etc.  In other words--you need to do a bit of reading through the specifications for the various peripherals.

Since none of my work (yet) uses an MMU, all memory references to hardware in the software I am working with typically work out to be references to variables.  For example, a statement such as sys->io_uart_tx = 'H'; might send an 'H' to the serial port---assuming that you had already verified that the port was idle. 

That said, I would highly discourage you from placing *anything* in the first page of memory.  That page should be reserved for NULL pointer protection.  Specifically, if your software ever tries to dereference a NULL pointer--it should generate an exception.  I made the mistake of not doing this with a design I made for the Basys3, and as a result a program I wrote once tried to start writing at the zero address (having not checked for a NULL), and reconfigured my hardware.  The worst of this is the fact that the flash memory on the Basys3 contains registers that, once written to, cannot be unwritten to.  I've since done more to protect them, but learned a strong lesson by it.  A sadder man but wiser now, I share this lesson with you.

Dan

 

@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

[miguel_rodrigues]

Dear tuan,

 

I would suggest you to follow the tutorial first with the Zybo Base System from Digilent first and only if you succeed, try to adapt the tutorial to Xillybus.

 

Regarding your question:

 

• "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. "

 

The user can read/write to all memory. But the OS kernel will only use the first half of the memory. You can not control which memory the OS kernel uses and thus, you need to make sure that the OS kernel only sees part of the memory. However, your programs will always be able to use the full memory space, which is what you want I believe.

 

Good luck

[tuan]

On 2/2/2017 at 7:50 PM, miguel_rodrigues said:

A while ago I created this tutorial that is somewhat related to parts of this (http://www.instructables.com/id/Zybo-AXI-DMA-Inside-Embedded-Linux/).

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

[tuan]

5 hours ago, JColvin said:

Hi Tuan,

I don't know the answers to most of your questions, but I do know that you can find the Base System Design for the Zybo on it's Resource Center on our Wiki; it's in the box on the right hand side underneath "Design Resources".

Thanks,
JColvin

Hi JColvin

Thank you. It is completely my checking problem on the page.

Tuan

[JColvin]

Hi Tuan,

I don't know the answers to most of your questions, but I do know that you can find the Base System Design for the Zybo on it's Resource Center on our Wiki; it's in the box on the right hand side underneath "Design Resources".

Thanks,
JColvin

[tuan]

On 2017/2/4 at 1:55 AM, miguel_rodrigues said:

• echo $PATH
• source /opt/Xilinx/Vivado/2015.4/settings64.sh
• echo $PATH

 

It should give you different outputs between the first and the second time you echo. If it doesn't. ensure that the file (settings64.sh) is executable. If it is not:

• chmod +x /opt/Xilinx/Vivado/2015.4/settings64.sh

 

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

[miguel_rodrigues]

58 minutes ago, tuan said:

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

Hello Tuan,

 

I was able to reproduce your error if I skipped this line: " source /opt/Xilinx/Vivado/2015.4/settings64.sh ".

 

• echo $PATH
• source /opt/Xilinx/Vivado/2015.4/settings64.sh
• echo $PATH

 

It should give you different outputs between the first and the second time you echo. If it doesn't. ensure that the file (settings64.sh) is executable. If it is not:

• chmod +x /opt/Xilinx/Vivado/2015.4/settings64.sh

 

and retry.

 

Hope this helps

[tuan]

23 hours ago, miguel_rodrigues said:

Sorry tuan, I have no answer for your question about some HDMI devices working and others not. My experiences with HDMI here were only connecting the output of a laptop into the Zybo and it worked, never tried with other devices.

 

If you want to understand why some work and why some don't, you would need to debug the HDMI IP and understand the details of the HDMI protocol. You will have better luck asking the developers of the HDMI IP (Digilent guys) on why. A possible answer (note I am only guessing) is that your display can read HDMI inputs with variable resolutions while the HDMI IP is expecting a fixed resolution, which is the same of your first 2 devices.

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

[miguel_rodrigues]

Sorry tuan, I have no answer for your question about some HDMI devices working and others not. My experiences with HDMI here were only connecting the output of a laptop into the Zybo and it worked, never tried with other devices.

 

If you want to understand why some work and why some don't, you would need to debug the HDMI IP and understand the details of the HDMI protocol. You will have better luck asking the developers of the HDMI IP (Digilent guys) on why. A possible answer (note I am only guessing) is that your display can read HDMI inputs with variable resolutions while the HDMI IP is expecting a fixed resolution, which is the same of your first 2 devices.

[tuan]

16 minutes ago, miguel_rodrigues said:

No problem. I know this is all can be a bit overwhelming but you will get there with patience From your post, I believe everything works in bare-metal, the problem is integrating with Linux OS. Is this correct?

Feel free to ask more questions
 

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

[miguel_rodrigues]

19 minutes ago, tuan said:

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).

To write data to memory, you use the AXI Stream protocol. The AXI Stream will then be converted by an AXI Interconnect IP which will convert the AXI Stream into an AXI4, which connects to the S_AXI_HP0 of the PS, as you say. With the ILA's, can you confirm that data is being written to the memory AND from the memory correctly?

19 minutes ago, tuan said:

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).

By default, the OS will occupy the whole DDR (512MB). You will need to explicitly tell the OS to just use half of this memory (0x00000000 to 0x0FFFFFFF). The memory zone where the frames will be stored needs to be outside the OS memory zone, i.e., above 0x10000000. For instance, it may be 0x10000000 to 0x100FFFFF for 1MB frame.

19 minutes ago, tuan said:

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)

 Yes, you will need to build the OS by yourself in order to restrict the OS to only use the first 256MB of the DDR. You will need to modify the zynq_zybo.h file, as explained in the tutorial.

19 minutes ago, tuan said:

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.

The problem is that you are writing to the OS memory zone. Since the OS may also write into it, not only corruption of data may occur but worst, you may write on top of important system data and cause problems. That is why you should separate memory zones, into OS and shared data.

19 minutes ago, tuan said:

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. (I am not sure if your no. 2 is this approach or not and I will need to check available IPs related to DDR).

You don't need to ask. As above, the problem is you are trying to write into the OS memory zone and you shouldn't. If you separate things, the AXI interface will behave without influence of the OS.

19 minutes ago, tuan said:

2. How can I ask OS directly read those data from DDR (the above read mentions on A.1. is use for confirmation / debug).

For the OS to read data from the DDR you may use /dev/mem (which is not good as the whole physical memory is available to a buggy application) or you can use generic uio drivers. This implies modifying the system device tree, and is explained in the tutorial.

19 minutes ago, tuan said:

PS. Thank you for the link. I will check it now.

Best Regards,

Tuan

 

No problem. I know this is all can be a bit overwhelming but you will get there with patience From your post, I believe everything works in bare-metal, the problem is integrating with Linux OS. Is this correct?

 

Feel free to ask more questions

[tuan]

3 hours ago, miguel_rodrigues said:

Dear tuan,

 

I have done something similar as what you want to achieve. I will give you some general recommendations and if you have more specific questions, feel free to ask

1. Capture the HDMI input using the IPs provided by Digilent, as in HDMI => VGA converter on ZYBO
2. Use AXI Stream to send such amount of data to the DDR, triggering such DMA transaction using your own custom DMA controller (IP that writes to AXI DMA registers)
3. Every time the DMA transaction ends, trigger a new one, always writing to the same DDR memory location.
4. Use ANOTHER DMA transaction (AXI Stream) to read from the DDR memory location where the frames are being written, using another custom DMA controller.
5. Every time this new DMA transaction ends, trigger a new one, always reading from the same DDR memory location.
6. Have Linux installed on the PS, with the DDR divided in 2 (half for Linux and half for shared PS/PL data).
7. Create device drives in order to access the memory zone where the frames are.
8. Have a program always reading such memory zone and send the frames over the Ethernet.

 

A while ago I created this tutorial that is somewhat related to parts of this (http://www.instructables.com/id/Zybo-AXI-DMA-Inside-Embedded-Linux/).

In the end, it has some reference links that should help you better understand some of the things involved in the process.

 

PS: I have this system implemented on Zybo but instead of capturing frames via HDMI, I capture them using an ov7670 image sensor. The flow is exactly the same however

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

[miguel_rodrigues]

Dear tuan,

 

I have done something similar as what you want to achieve. I will give you some general recommendations and if you have more specific questions, feel free to ask

1. Capture the HDMI input using the IPs provided by Digilent, as in HDMI => VGA converter on ZYBO
2. Use AXI Stream to send such amount of data to the DDR, triggering such DMA transaction using your own custom DMA controller (IP that writes to AXI DMA registers)
3. Every time the DMA transaction ends, trigger a new one, always writing to the same DDR memory location.
4. Use ANOTHER DMA transaction (AXI Stream) to read from the DDR memory location where the frames are being written, using another custom DMA controller.
5. Every time this new DMA transaction ends, trigger a new one, always reading from the same DDR memory location.
6. Have Linux installed on the PS, with the DDR divided in 2 (half for Linux and half for shared PS/PL data).
7. Create device drives in order to access the memory zone where the frames are.
8. Have a program always reading such memory zone and send the frames over the Ethernet.

 

A while ago I created this tutorial that is somewhat related to parts of this (http://www.instructables.com/id/Zybo-AXI-DMA-Inside-Embedded-Linux/).

In the end, it has some reference links that should help you better understand some of the things involved in the process.

 

PS: I have this system implemented on Zybo but instead of capturing frames via HDMI, I capture them using an ov7670 image sensor. The flow is exactly the same however

[tuan]

5 hours ago, jpeyron said:

Hi tuan,

I have moved this thread to the embedded sub-section where more experienced embedded forum members typically look! I am able to help with more basic embedded questions but i am still learning. In this case I have reached out to our embedded expert @sbobrowicz about your forum question as well as email. Sam is out of the office today but should be able to get you a response when he is back in the office. 

cheers,

Jon

Dear Jon

Thank you very much for your help in finding expert on this issue.

Best Wishes,

Tuan

[jpeyron]

Hi tuan,

I have moved this thread to the embedded sub-section where more experienced embedded forum members typically look! I am able to help with more basic embedded questions but i am still learning. In this case I have reached out to our embedded expert @sbobrowicz about your forum question as well as email. Sam is out of the office today but should be able to get you a response when he is back in the office. 

cheers,

Jon

[D@n]

@tuan,

So, as long as you remember that I've never worked with a zynq chip, zybo or otherwise ...

First, /dev/mem doesn't give you access to user memory, but rather to physical memory.  The relationship between the two is usually controlled by the kernel, with the exception of any hardware memory maps within physical memory.  While user memory may be moved in and out of physical memory, device memory typically cannot be moved.

If you wish to work with the memory map, you need to understand memory-mapped I/O.  Indeed, when working with FPGA IP, it's often easiest to map that IP to various locations in memory.  Such memory maps make it easy/simple to have the CPU control your FPGA logic.  Indeed, nearly all of my designs use memory mapped I/O to communicate between the CPU and the FPGA logic.

As an example, I have a memory map that I have created for my peripherals on the Arty.  You can see the .h defining where things are here, and read about the plan for it in the specification here (Chapt 6).  Knowing how to access registers via /dev/mem starts with knowing where the registers for your peripherals are (such as I just listed above), and then knowing what the registers do when you read or write them.  For example, reading/writing an address in video memory will (usually) adjust a pixel on a screen.  To do this, though, requires that you know where the video memory is, the number of bytes per row, and the number of bits per pixel, how colors are stored in memory, etc.  In other words--you need to do a bit of reading through the specifications for the various peripherals.

Since none of my work (yet) uses an MMU, all memory references to hardware in the software I am working with typically work out to be references to variables.  For example, a statement such as sys->io_uart_tx = 'H'; might send an 'H' to the serial port---assuming that you had already verified that the port was idle. 

That said, I would highly discourage you from placing *anything* in the first page of memory.  That page should be reserved for NULL pointer protection.  Specifically, if your software ever tries to dereference a NULL pointer--it should generate an exception.  I made the mistake of not doing this with a design I made for the Basys3, and as a result a program I wrote once tried to start writing at the zero address (having not checked for a NULL), and reconfigured my hardware.  The worst of this is the fact that the flash memory on the Basys3 contains registers that, once written to, cannot be unwritten to.  I've since done more to protect them, but learned a strong lesson by it.  A sadder man but wiser now, I share this lesson with you.

Dan

 

[tuan]

3 hours ago, D@n said:

Hmm ... looks like I misspoke about /dev/kmem, based on this article it sounds like /dev/mem is what you really want,

Dan

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

[D@n]

Hmm ... looks like I misspoke about /dev/kmem, based on this article it sounds like /dev/mem is what you really want,

Dan

[D@n]

@tuan,

I'm really not that familiar with the embedded Linux aspects of FPGA programming.  I'm getting there, but ... I have yet to fire up any Zynq chips.  I think @jpeyron might be a better person to ask.

That said, isn't the Xillybus designed for communicating with FPGAs attached on a common external bus structure, such as PCIe?  It seems to me that you shouldn't need this solution at all, but rather should be able to set yourself up to simple read/write SDRAM memory from your O/S program.  I know that, on some Linux distributions I've worked with that this process is as simple as opening /dev/kmem and mapping it to your process via mmap.  Reading and writing memory is then just as simple as, well, as simple as reading and writing memory.  Why make it more difficult?

Dan

[tuan]

On 12/1/2016 at 11:15 PM, D@n said:

@tuan,

It's easier than you are making it to be.  Create a single wire that goes high when a half of a FIFO is available to be read.  Let that wire cross time domains.  Then you know you can read at least that much from the FIFO.  Further, by the time you've read even half of that half of a FIFO, the line will have cleared.

Keep it simple, the task is hard enough as it is. 

Dan

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

[D@n]

@tuan,

It's easier than you are making it to be.  Create a single wire that goes high when a half of a FIFO is available to be read.  Let that wire cross time domains.  Then you know you can read at least that much from the FIFO.  Further, by the time you've read even half of that half of a FIFO, the line will have cleared.

Keep it simple, the task is hard enough as it is. 

Dan

[tuan]

11 hours ago, D@n said:

@tuan,

Welcome to one of the more difficult problems in FPGA design! 

I think you will find that Cliff Cummings wrote an excellent article on how to move from one clock domain to another.  He not only describes the problem of metastability, but also provides many strategies for handling it.  In your case, I think you will find that writing to a FIFO with one clock, and then reading it out with the other clock once half the FIFO has filled might be just the thing you are looking for.

Dan

@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.

[D@n]

@tuan,

Welcome to one of the more difficult problems in FPGA design! 

I think you will find that Cliff Cummings wrote an excellent article on how to move from one clock domain to another.  He not only describes the problem of metastability, but also provides many strategies for handling it.  In your case, I think you will find that writing to a FIFO with one clock, and then reading it out with the other clock once half the FIFO has filled might be just the thing you are looking for.

Dan

[tuan]

On 11/8/2016 at 11:00 PM, jamey.hicks said:

Zybo only has 230KB of BRAM. If the images fit in BRAM you should be able to use it.

There is also 256KB of OCM, but there are not many reference designs out there that use it.

Most likely, you will need to capture frames in DRAM.

 

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,

 

 

[jamey.hicks]

Zybo only has 230KB of BRAM. If the images fit in BRAM you should be able to use it.

There is also 256KB of OCM, but there are not many reference designs out there that use it.

Most likely, you will need to capture frames in DRAM.