• Content Count

  • Joined

  • Last visited

  • Days Won


Mihaita last won the day on November 7 2014

Mihaita had the most liked content!

About Mihaita

  • Rank

Profile Information

  • Gender
  • Location

Recent Profile Visitors

938 profile views
  1. Mihaita

    Nexys4-ddr SD card

    You are right Syaoran74, you need license for the full spec of the Native SD. But if you're only interested in implementing the SPI mode, the simplified version of specifications contain enough information: https://www.sdcard.org/downloads/pls/index.html A simple google search will point to multiple software implementations of the SPI mode. If the SPI gives you enough band width that you can easily write the incoming stream than I'd stick with SPI rather than Native.
  2. From looking at the original linker script it seems like the software runs out of DDR2 so when regenerating the liker script make sure you place code, data, heap and stack into DDR2. Mihaita
  3. Try deleting the linker script file and generating it again by right clicking Atlys_Webser_Demo -> Generate Linker Script. Mihaita
  4. There is a pcore for the multiplexing a shared memory bus between three memories for Nexys3 board (you can find it here, and look inside Nexys3_AXI_BSB_Support/lib/Digilent/pcores/d_shared_mem_bus_v1_00_a). Now this core only presents to the system processor as a memory mapped slave device, meaning that besides having the virtual addresses with which you access virtual registers inside the core it also has a region of addresses that corresponds to the actual memory device. This was done for EDK and uses a module, from inside the axi_lite_ipif library, that did a translation from the AXI4-Lite interface into a more readable one (look into the source files of the Nexys3 BSB). You could use this as a starting point but the interface that you want to implement could be a bit complex if you want to support burst read/writes. If the design allows you I would suggest instantiating MIG and a DMA core that has for reading/writing into the memory streaming interfaces (AXI4-Stream). The implementation of such core is far easier. Mihaita
  5. Here's the git repository where we release some IP cores for Vivado. Inside the ip directory there's the dvi2rgb_v1_3 core that you can use for the second input of the your FMC-HDMI card, but also there's the dgl_dvi_edid.txt inside the src directory. That's the EDID that we use, you can use it as a starting point and by using this as a reference you can easily modify it to your needs. Or you could use Avnet's EDID as a starting point. There are heaps of EDID editing software on the web if you don't want to manually edit it.
  6. Hi Ramesh, The FMC-HDMI has two HDMI inputs: one with the ADV7611 decoder that outputs a 24-bit selectable color format video data bus, one that has the AD8195 buffer that only translates the 5 Volt HDMI signals into 3.3 Volt HDMI signals. Please note that the FMC-HDMI is an FMC Mezzanine board meaning that it is a peripheral board (add-on), so the controlling software (HDL, C/C++) resides on the ZC702 board making it dependent on the FPGA/processor present on the board. Here's a reference to the board: https://reference.digilentinc.com/fmc_hdmi:refmanual Regarding the decoder error make sure you: Set the correct EDID into ADV7611's internal RAM, that configures the link at 10 bits per component HDMI1_HPA signal of the FMC-HDMI board is asserted If all of the above steps are completed then measure the decoded pixel clock and compare it with the video resolution's pixel clock frequency Mihaita
  7. The design is made with Xilinx Platform Studio 14.4 (http://www.xilinx.com/tools/platform.htm), you can open it with that version an follow the instructions in the PDF document under doc folder. It does not work with ISE. The bsp, platform and library are part of the SDK needed to implement the lwip and the whole server application.
  8. Hello helmutforren, Are you sure you correctly mapped the FPGA RX/TX pins? What I do know is that pin U10 of the FPGA should be output on the FPGA, hence input for the FTDI; pin T10 set as input on the FPGA and output of the FTDI. That means that from the FPGA standpoint: Uart Tx = U10, Uart Rx = T10. - Mihaita
  9. Recently I had to make a standalone Zynq project that had multiple .ELF files all residing on an SD card. The board had to somehow know, while being powered off, which .ELF file to boot from. So how to do this? The answer is in the FSBL file. Currently, in Vivado's 2014.2 SDK, the FSBL can handle multiple "partitions" (that's how any Second Stage BootLoader is called, in our case the .ELF files) by executing the first one, when done returning to the FSBL that handoffs control to the second one and so on. But there is another way with the so called hooks: FsblHookBeforeBitstreamDload, FsblHookAfterBitstreamDload, FsblHookBeforeHandoff. With these handy functions you can halt the FSBL and do whatever (for example read the switches) before the bitstream file has been downloaded, after or right before the SSBL is being booted. Here's a simple usage example: let's you have three .ELF files on the SD card and you want to select which one to boot with the on-board switches. First of all you generate an FSBL project, then open the image_mover.c file from the src folder. Scroll down to line 440 and change the code as bellow: if (PLPartitionFlag) { if (PartitionAttr & ATTRIBUTE_PS_IMAGE_MASK) { Status = FsblHookBeforeBitstreamDload(); if (Status != XST_SUCCESS) { fsbl_printf(DEBUG_GENERAL,"FSBL_BEFORE_BSTREAM_HOOK_FAILrn"); OutputStatus(FSBL_BEFORE_BSTREAM_HOOK_FAIL); FsblFallback(); } else { HeaderPtr = &PartitionHeader[ExecutionAddress]; PartitionDataLength = HeaderPtr->DataWordLen; PartitionImageLength = HeaderPtr->ImageWordLen; PartitionExecAddr = HeaderPtr->ExecAddr; PartitionAttr = HeaderPtr->PartitionAttr; PartitionLoadAddr = HeaderPtr->LoadAddr; PartitionChecksumOffset = HeaderPtr->CheckSumOffset; PartitionStartAddr = HeaderPtr->PartitionStart; PartitionTotalSize = HeaderPtr->PartitionWordLen; ExecAddress = PartitionExecAddr; } } } Open the fsbl_hooks.c file and add the following global variable: extern u32 ExecutionAddress; Go to the FsblHookBeforeBitstreamDload function and change it: u32 FsblHookBeforeBitstreamDload(void) { u32 Status; u32 dwSws; Status = XST_SUCCESS; // The first partition would usually be the PL bitstream, so we're // skipping it. do { dwSws= Xil_In32(SWS_BASEADDRESS) & 0x03; } while(dwSws == 0x00); ExecutionAddress = dwSws; xil_printf("Selected partition %drn", swSws); /* * User logic to be added here. Errors to be stored in the status variable * and returned */ fsbl_printf(DEBUG_INFO,"In FsblHookBeforeBitstreamDload function rn"); return (Status); } ExecutionAddress will hold the value of the first two switches and point to the corresponding partition. And finally here's how the "Create Zynq Boot Image" SDK utility would look like when creating the BOOT.BIN that'll go onto the SD: That's it! Hope it helps someone (or even myself sometime in the future when I forget all this ).