chcollin

Members
  • Content count

    20
  • Joined

  • Last visited

About chcollin

  • Rank
    Member

Recent Profile Visitors

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

  1. chcollin

    Atlys USB JTAG problem with VirtualBox

    Hi @jpeyron Thanks a lot for the link. Whatever I tried, I never managed to solve the problem. I finally ended up setting a new linux native partition on which I installed Centos 6.9. It's been a very hard time making Xilinx EDK work flawlessly (I had to install i686 libs, update cairo libs, recompile usb cable drivers, change serial port access libs ...), but I finally have a fully working ISE 14.7 setup, no SDK crashes, JTAG and UART via USB working Happy !
  2. chcollin

    Atlys USB JTAG problem with VirtualBox

    Hi FPGA gurus ! I am facing trouble while trying to attach my Atlys USB JTAG device to a Centos 6 virtualbox VM. I recently had no choice but to upgrade my computer from Windows 7 to Windows 10. As a Windows 10 version of ISE 14.7 was available, I decided I could do the upgrade before realizing that ISE 14.7 for Windows 10 was indeed ISE 14.7 for Linux running a VirtualBox... Nevermind. The problem is that it seems I can't attach Digilent USB JTAG to the VirtualBox. Here is my configuration : Windows 10 Pro VirtualBox 5.2.8 (I upgraded it so that I could install Extensions to enable USB 2 and USB 3 support) Adept2 is installed on Windows 10 and works fine, Atlys board is recognized and I can run the test application OK. Now, here is my problem : Let's turn on the computer first and do a fresh test ! Atlys Board is attached to USB ports (JTAG and UART) but is turned off. VirtualBox USB configuration is configured as shown in USB_parameters.jpg Now, let's turn VM on, Atlys board still off. The attachable USB device list in VB is shown in USB_devices_atlys_off.jpg As you can see, neither JTAG nor UART devices are listed, which is expected as Atlys board is off. Now, let's turn the Atlys board on and see if the listing has changed... It has ! as shown in USB_devices_atlys_on_1.jpg Also, you can see in Device_mgr.jpg that Windows has no driver problem with JTAG and UART devices. You may notice UART device is automatically attached. Looking at /dev/tty* shows that the UART device is now available through /dev/ttyACM0 as shown in TTY_devices.jpg Let's have a look at the JTAG device status (USB_devices_atlys_on_2.jpg), it reads "captured", whatever that means ... Now, let's try attaching it... It raises an error with message shown in Digilent_USB_JTAG_attachment_error.jpg "USB device is busy with a previous request" :/ This is sad ... Of course, no other device appears in /dev/tty* Greping dmesg for FTDI pattern returns Nothing. Only UART USB devices appears in dmesg log... I've tried the same test with USB 3 (xHCI) configuration selected. Do any of you have an idea on how I could attach the USB Digilent JTAG device to my Centos 6 VirtualBox machine ? Any help will be highly appreciated. Thanx a lot. Cheers
  3. chcollin

    AXI4 HDMI demo for Atlys

    Thank you @jpeyron, I'll have a look at the VmodCam example, it should bring me some good start. Cheers
  4. chcollin

    AXI4 HDMI demo for Atlys

    Hi, Does anyone know if/where I can find an AXI4 example running on Atlys similar in functionnality to the HDMI PLB demo ? The example would show how to read frames from HDMI in, store to memory via AXI4 VDMA core, and read from memory to HDMI out. Thanx !
  5. chcollin

    My noobish questions on Atlys HDMI demo

    Thank you so much @sbobrowicz ! I've been away from my project and this forum for a while. Your explanation makes it so clear now. Thank you very much and happy new year. Cheers
  6. chcollin

    VFBC max clock frequency for Atlys

    Thx @jpeyron, i'm going to ask Xilinx as you advice. I'll post back here if I ever get any answer from Xilinx. Cheers
  7. chcollin

    VFBC max clock frequency for Atlys

    Hi everyone, I've been reading Xilinx's DS643 pdf on MPMC configuration (v6.06.a). Table 91 page 170 lists the maximum frequency that can be used for the VFBC interface clocks, VFBC_Cmd_Clk, VFBC_Wd_Clk and VFBC_Rd_Clk. Only Spartan-3A DSP, Virtex-4 and Virtex-5 devices are listed. Where can I find the maximum frequency that can be used to clock VFBC on Atlys spartan-6 ? Thanx a lot, cheers.
  8. chcollin

    My noobish questions on Atlys HDMI demo

    Thank you very much @sbobrowicz, your explanation makes it a lot clearer to me. Especially the offset from the DDR starting address so that the code can be safely stored without overlapping data. However, I might disagree about the 0xD1000000 value, or my comprehension is completely mistaken (which is highly possible as I really am beginner) Looking at project/pcores/hdmi_out_v1_00_a/hdl/vhdl/hdmi_out.vhd, we can see that : constant vfbc_cmd1 : std_logic_vector(31 downto 0) := "0" & FRAME_BASE_ADDR(30 downto 7) & "0000000"; --Frame base address must be 128 byte alligned and MSB used as WNR File ./project/pcores/hdmi_out_v1_00_a/data/hdmi_out_v2_1_0.mpd reads : PARAMETER FRAME_BASE_ADDR = 0x00000000, DT = std_logic_vector, ASSIGNMENT = REQUIRE, DESC="FRAME BASE ADDRESS", LONG_DESC="Select the physical address of the framebuffer in memory. This address must be 128 byte alligned (bits 6-0=0) and designate a region within the MPMC space large enough for the frame. And finaly, in ./project/system.mhs, the paramater is set : PARAMETER FRAME_BASE_ADDR = 0xD1000000 So, to my comprehension, 0xD1000000 is the very address in memory from which the hdmi_out vfbc pim reads the frame. However bit 31 is excluded in the address used in vfbc_cmd1, so 0xD1000000 "turns into" 0x51000000. It's getting closer ... yet not 0x4900000 ! Where am I mistaken ?
  9. chcollin

    My noobish questions on Atlys HDMI demo

    Hi FPGA Gurus ! This thread is dedicated to the (probably numerous) questions I might have about the Atlys HDMI demo. It will be edited each time a question is answered or another question pops up ! =) Question 1: I dont understand the calculation of the Frame Base Address in hdmi_demo.h. The code reads : /* * These constants refer to the configuration of the hdmi_out core parameters. */ #define pFrame 0x49000000 //frame base address #define xcoFrameMax 1280 //frame width #define ycoFrameMax 720 //frame height #define lLineStride 0x800 //line stride Now, if I look at the hdmi_out core, i'm ok about frame width and height and also about the line stride. However, the core FRAME BASE ADDRESS parameter is set to 0xD1000000. If I look at the MPMC configuration, its base address parameter is set to 0x48000000. I'm a bit confused. Could someone explain how this 0x49000000 value is obtained out of 0x48000000 and 0xD1000000 ? Thank you very much for your help
  10. chcollin

    Atlys HDMI Demo : Rotating VFBC. Need Help !

    Thank you @jpeyron Any help is greatly appreciated.
  11. chcollin

    Atlys HDMI Demo : Rotating VFBC. Need Help !

    OK, OK, i might need to redesign the entire thing because of the 128 byte alignment constraint. As the width and start_address need to be multiple of 128 bytes, then the minimum value for width is 64, which means i need to rotate 64 lines at a time and then do 7 write commands to the VFBC to render the entire rotated frame. The following picture shows how data should be wirtten to the frame buffer so that the 128 byte constraint is respected : F[480][1] … F[417][1] F[416][1] … F[128][1] … F[66][1] F[65][1] F[64][1] … F[2][1] F[1][1] F[480][2] … F[417][2] F[416][2] … F[128][2] … F[66][2] F[65][2] F[64][2] … F[2][2] F[1][2] F[480][3] … F[417][3] F[416][3] … F[128][3] … F[66][3] F[65][3] F[64][3] … F[2][3] F[1][3] … … … … … … … … … … … … … … … … … … … … … … … … … … … F[480][639] … F[417][639] F[416][639] … F[128][639] … F[66][639] F[65][639] F[64][639] … F[2][639] F[1][639] F[480][640] … F[417][640] F[416][640] … F[128][640] … F[66][640] F[65][640] F[64][640] … F[2][640] F[1][640] So the data FIFO for the VFBC write command should look like this : F[1][640] F[2][640] … F[64][640] F[1][639] F[2][639] … F[64][639] .. F[1][3] F[2][3] … F[64][3] F[1][2] F[2][2] … F[64][2] F[1][1] F[2][1] … F[64][1] which means pixels must be reorderd before being pushed to the FIFO. 64 lines need to be stored before processing reordering. Each line is 640*16 = 10Kb long, which means I need 64 * 18Kb BRAMs to store 64 lines. BRAM 1 F[n*64+1][640] F[n*64+1][639] … F[n*64+1][3] F[n*64+1][2] F[n*64+1][1] BRAM 2 F[n*64+2][640] F[n*64+2][639] … F[n*64+2][3] F[n*64+2][2] F[n*64+2][1] BRAM 3 F[n*64+3][640] F[n*64+3][639] … F[n*64+3][3] F[n*64+3][2] F[n*64+3][1] … BRAM 63 F[n*64+63][640] F[n*64+63][639] … F[n*64+63][3] F[n*64+63][2] F[n*64+63][1] BRAM 64 F[n*64+64][640] F[n*64+64][639] … F[n*64+64][3] F[n*64+64][2] F[n*64+64][1] pixel data is then poped cyclically from those BRAMs and pushed to the VFBC data FIFO : Is this design more appropriate ? Looks like it is. However, I do not have a single idea on how to implement it !!!
  12. chcollin

    Atlys HDMI Demo : Rotating VFBC. Need Help !

    I might be concerned with the 128 byte alignement constraint, concerning the "line_base_addr" and width ...
  13. Hi FPGA gurus ! I'm trying to achieve video processing with Atlys board. My goal is to real-time rotate some VGA Stream (640x480@60) form hdmi input to 720p hdmi output. Rotation is 90° clockwise. The attached picture sketches what i'm aiming at. I've been thinking of using HDMI Demo project for this. I am a total noob to all this FPGA thing, i'm slowy trying to learn but it's not that simple when you don't know anything about electronics =) From what I have understood, in the HDMI demo the frame in written to DDR2 memory with a single call to the VFBC. TMDS data is pushed in the FIFO and when a new frame is detected, then the Write Command is emitted and stores the whole frame to memory. I thouht a good design for my project would be to store line by line, configuring the VFBC command with X=1, Y=639 and BaseAdress = [(40*lineStride)+(1160-lineCnt)] * 2. This way : line 1 (blue) is stored in the frame buffer as a 1 pixel wide column starting at pixel (1159,40) line 2 (green) is stored in the frame buffer as a 1 pixel wide column starting at pixel (1158,40) ... line 640 (orange) is stored in the frame buffer as a 1 pixel wide column starting at pixel (680,40) My understanding of the HDMI Demo is that modifying user_logic.vhd in hdmi_in is all i have to do, so that instead of writing the whole frame in one vfbc command, the frame should be written line by line with 640 VFBC commands, one for each line, with constant width = 1, constant height = 639 and baseAdress computed as shown above. Is this correct ? Any Suggestion, hint, advice or help will be highly appreciated as I quite lost with this !! Cheers
  14. chcollin

    Atlys + ISE 14.7 : HDMI demo problem

    Many thx @jpeyron, you got it right at first try ! Much respect. This was exactly my problem : copying the lscript.ld from source instead of keeping the one created by SDK. Now everything works perfectly. One again, many thanx. </topic>
  15. chcollin

    Atlys + ISE 14.7 : HDMI demo problem

    Hi @jpeyron, Yes, I followed the setup and connection process described in HDMI_Demo_Project pdf. In XPS I was aked to migrate the project, and did so. As said, I managed to build the ELF, program the FPGA and run it from SDK. Some things work (if I had xil_printf calls in main(), they print in the SDK terminal), also i can draw on the screen. Some others don't. Especially push button interrupts (if I put xil_printf calls int he PushBtnHandler() function, nothing prints whichever button I press). Also, I don't really understand your request about tera term. Attached is a screenshot of the SDK Terminal connected to Atlys and program running. As you can see, the program outputs when in main(). However whichever button I press, nothing prints in the terminal (I added a xil_printf at the start of the PushBtnHandler() function. Is this what you requested ? As said, I'm totally noob...