Is it possible to build the gateware on Windows or is required to use a Linux install of Libero? I’ve tried both main and tag BVF-0.4.0 with the same results. The tcl script crunches along for a while then throws the following errors:
Error: SDCTRL02: Port name ‘ADC_MCLK’ already exists.
Error: The command ‘sd_connect_pin_to_port’ failed.
Error: Failure when executing Tcl script. [ Line 195 ]
Error: The Execute Script command failed.
I’ve tried running with no arguments and with ONLY_CREATE_DESIGN M2_OPTION:NONE with the same results.
OK, both Windows and Linux work if I use the arguments ONLY_CREATE_DESIGN M2_OPTION:NONE CAPE_OPTION:NONE but both fail if I don’t pass any arguments. It looks like it’s the CAPE_OPTION:NONE that made things work, but I haven’t yet tested with just that option.
Hmm…interesting results across Windows/Linux, with all instances passing the script option ONLY_CREATE_DESIGN . Below, “unmodified” means directly from git (BVF-0.4.0-7-gcf5dd2e), and “modified” replaces the sd_connect_pin_to_port with sd_connect_pins command:
Linux unmodified: Succeeds (I’m not sure if this behavior is new or if i didn’t try this specific combination of script arguments previously)
Linux modified: Also succeeds
Windows unmodified: This fails with the same error reported initially
Windows modified: Succeeds
Are community FPGA contributions expected to use this “automatically make my project for me” framework? I typically keep the actual FPGA projects under revision control as my experience with the “build my project for me” tcl scripts tend to be VERY fragile.
I’m looking to make a daughtercard and gateware to support 4Kp60 video via 12G SDI connected to a video encode/decode core I maintain for DayJob to stream NDI video via Ethernet (https://ndi.video/).
ah no @cdsteinkuehler it’s not a requirement… From your previous experience, you understand the fun it is to install/etc FPGA toolchains.
The Goal of our Gateware project is to help lower the barrier for new users, especially those with no FPGA knowledge… Part of that is a git repo users can fork, and then push back to git.beagleboard.org and get a working FPGA object from ci ready to use…
I’m also working on the apt/repo backend, so when new users do these changes, they can easily update a fleet of boards in the field. (along with merge back if they choose into the main git repo…)
I like the idea having CI setup so users can do builds and get working bitstream files w/o having to go through the hassle of tool installation & licensing. Let me know if there’s anything I can do to help, the holidays are coming up and I usually try to tackle something open-source that also somewhat applies to DayJob over the break. Last year I crafted a Buildroot system using RAUC for updates with fallback if anything went sideways, atomic boot-loader updates, and a squashfs rescue partition if things get seriously out of wack: br2rauc
I could do with some Verilog IP for moving data from the FPGA fabric to DDR memory using the AXI4 interface on the PolarFire SoC microprocessor subsystem. Something that could be used/re-used by others for their gateware for the camera interface or the SYZYGY interface. There could be something with a suitably open license that already exists.
While it’s not all that hard to “speak AXI”, it isn’t exactly the simplest protocol either. I already have logic that streams pixels into SDRAM via AXI (for Xilinx/Altera), but it doesn’t handle scatter-gather DMA (requires buffers allocated from the CMA if you’re using Linux/gstreamer/v4l2, or setting aside a reserved region of memory if you’re working outside Linux). It shouldn’t be too hard to get working for the PolarFire and I already plan to do this in order to get my NDI video streaming project working.
Is there a “standard” camera intended to be used with the Fire? Microchip seems to have pretty good IP available for talking various video formats (MIPI, HDMI, SDI), so I think all you’d need is the DMA logic to stream pixels to/from SDRAM. IIRC there are a few open-source DMA cores available and some of them might even do scatter-gather…the problem is then you’re forced into writing kernel mode drivers (there’s no support for SGL in things like UIO).
I think we are first looking at the Sony IMX219 (same as Raspberri Pi). These camera modules seem to only use 2 MIPI lanes. However, all 4 MIPI lanes on the camera connector are connected to FPGA high-speed IOs so we could used other, I assume, higher end cameras.
Good point about the scatter-gather DMA requirements. Any recommendations on existing IP would be welcome.
I thought I had an IMX219 lying around, but couldn’t find it (I ordered another one, and the required 0.5mm adapter cable). I haven’t fully crawled through the code, but it looks like the write logic for the video streaming example is pretty simple but uses a custom kernel driver to handle DMA memory allocations and cache coherency. As a background project, I’ll see if I can get the camera up and streaming pixels into memory, which will give me a video source before I get an SDI SYZYGY daughterboard designed.