Jump to content

tommienator

Members
  • Posts

    6
  • Joined

  • Last visited

Recent Profile Visitors

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

tommienator's Achievements

  1. Could resolve it by splitting up the DDR memory in different regions: * 1 region for the heap/stack and all other things for core0 * 1 region for the heap/stack and all other things for core1 * 1 region that is common between both regions and can be accessed from the different CPU-cores. Using semaphores to lock certain resources so that overwriting can't occur.
  2. Hey All, So I have an application running on both ARM cores with each their specific available memory region (split in half): ARM core 0 base address: 0x100000 and size 0xFF800000 ARM core 1 base address: 0x10080000 and size 0xFF800000 Now I have a data acquisition system running on core 0 which receives data from another system and stores the received data in DDR memory and holds a pointer + length (in bytes) of the data. This pointer and length is passed to core 1 which needs to access the data in DDR for further processing and offload it to accelerators which are controlled and sequenced by core 1. Since this memory region that holds the data is mapped to core 0, how can I access it via core 1? Since it's quite a large quantity of data transferring the data from 1 region towards another one would be an expensive operation. Can an direct access be issued in this case from core 1 towards the memory mapped region of core 0? Thanks && kind regards.
  3. Hey @JColvin, In the end I've could fix the problem with the tutorial given by Digilent (https://zedboardupgrade.s3.us-east-2.amazonaws.com/ZedBoard+Rev+E+project+update+procedure.pdf?_ga=2.236277057.1100890869.1622904314-1810490008.1617456326). On the other hand I don't see any things considering REV E of the Zedboard on the website of Avnet (https://www.avnet.com/wps/portal/us/products/avnet-boards/avnet-board-families/zedboard/).
  4. Hey @JColvin, Thanks for the response. Considering the board file, indeed I've taken the one from Digilent (assumed this was the maintained one since Avnet didn't provide support anymore but Digilent does (read this on a certain forum post). Nevertheless, first followed your advise and installed the board file directly from Avnets Github page (bdf/zedboard/1.4 at master · Avnet/bdf · GitHub), which should, accordantly to the commit messages, support Vivado 2020.2. But this is for revision D I've noticed. Nevertheless, this didn't resolve the problem. Just double checked the revision, and the board is revision E. Considering the SD card project, there was an SD card delivered with the Zedboard which contained a Linux image. If you go on the Digilent website and search for the images that are present then you'll see the SD card being delivered with the board (https://store.digilentinc.com/zedboard-zynq-7000-arm-fpga-soc-development-board/). Just double checked if nothing was wrong with the Zedboard so I've thrown on an custom IP for the UFMT600X board that is connected via the FMC header and using that as a data streamer (via USB30.) towards the PC (without any Zynq instantiation, so the data generator + FIFO USB3.0 bridge where implemented as custom logic) and that worked just fine so I guess there is nothing wrong with the FPGA itself. I came across another post where the person had the same problem with revision E boards (https://forum.digilentinc.com/topic/20531-zedboard-rev-e/), so is there a possibility to get an revision E board file and test it? // Edit --> SOLUTION Just founded this document from a previous thread here on the forum and since the memory parts on the Zedboard are of 4Gb (https://zedboardupgrade.s3.us-east-2.amazonaws.com/ZedBoard+Rev+E+project+update+procedure.pdf?_ga=2.197137327.1072668274.1623081646-1457440089.1620987456). This resolved the problem, thus is there a board file for revision E available or are the memory components not instantiated via the board design and this wouldn't resolve anything? A permanent fix would be nice for this :-)?
  5. Hey all, I've got a small and probably stupid problem. Upgraded my Vivado to version 2020.2 and setup the basic Zynq hello world tutorial but it seems nothing comes out of the UART side. Little summary with print screens to make it as clear as possible... So first of all, I've downloaded the latest board files from Digilent (Github) and installed them accordantly. Next created a rudimentary board design with the Zynq processing system instantiated and UART 1 strapped to MIO 48 - 49 as is required (see print screen below). Board design check completes without any problem. Within the platform project, double checked that ps7_uart_1 is used for stdin/stdout Then the default hello world application is used and programmed correctly to the FPGA (blue led is on after programming the FPGA) but is seems the "hello world" via the UART is not coming trough (put the "print("Hello World\n\r");" in a while(true) loop to make sure I didn't miss it). Drivers are correctly installed and the COM port (5) is recognized correctly as well as the USB Serial Convertor / USB to UART Adapter. Jumpers JP7-JP11 are in the JTAG position so configuration wise this should be oké. Interesting thing, if I load in via the SD card the default image that is provided with the Zedboard, UART is working just fine so I'm wondering where the problem is hidden here? Looking forward to some input :).
×
×
  • Create New...