BMiller

Euphoniously, I just got notified about this paper, which purports to give an algorithm for multipliers that use fewer resources than others. Perhaps it will help? https://www.nature.com/articles/s41598-023-49913-5

Thanks; I don't actually need this IP for my application(s), but thought I had done something wrong (or something important was missing) for the "Design Linking" license to fail!

@JColvin, thanks for your response. I was under the impression that the patch you refer to was not needed for 2022 or later versions of Vivado/Vitis, based on the text on the referenced page, specifically: "This patch will be applied for Vivado and Vitis (including HLS) versions 2014.x through 2021.2." Note that the issue reported there is not related to the license issue above but seems to be related to an overflow when the calendar rolled past 12-31-21, so my expectation would be that the later products already integrated a solution for this problem!

I recently updated my toolset to 2023.1 after realizing there was no OOB version that supported 2022.1 for my new Genesys ZU 5ev (gotta love those black friday sales). After installing Genesys-ZU-HW branch ev/oob/next (which purports to be for 2023.1), and trying to generate a bitstream, I had a couple warnings about clocks (likely benign but I can probably track them down) and the following licensing-related errors: WARNING: [IP_Flow 19-650] IP license key 'v_hdmi@2017.10' is enabled with a Design_Linking license ... [Common 17-69] Command failed: This design contains one or more cells for which bitstream generation is not permitted: system_i/v_hdmi_tx_ss_0/U0/v_hdmi_tx/inst (<encrypted cellview>) system_i/v_hdmi_rx_ss_0/U0/v_hdmi_rx/inst (<encrypted cellview>) If a new IP Core license was added, in order for the new license to be picked up, the current netlist needs to be updated by resetting and re-generating the IP output products before bitstream generation. Other than investing in my own license for this IP which seems like overkill, any suggestions on how best to proceed?

Hey I still have a G5 Mac... not that I use it for much anymore. I still think it's a better architecture than x86, but well, the Lisp Machines were better than anything else at their time too (early to late 80s) and possibly even today if they were commercially viable. Market and scaling kept piston engines from being replaced by the Wankel as well. (I miss my Rx7 too in case you want to detect a trend here.) The Apple commercials for PowerPC were kind of hilarious though. I still remember the tanks defending the G4. But if AMD really wants to insist on the superiority of x86 for hard problems, why isn't there yet a version of Zynq with x86 cores? I think we all know the answer to that. @D@n might have the right idea: build open source tools. At least for smaller FPGAs the fancy algorithms needed to address the fundamental NP-Hard problems of route and place aren't as critical. Sadly, I can only work on a few (one?) research problems at a time. I'll just spec smaller and more power dense batteries (utilizing fusion or maybe zero point energy) to make everything "practical" once it's tossed over the wall for commercialization. 😁

Yes, I agree. I wasn't trying to diss the GUI use case, only that with just the scripts a lot of interesting stuff can be done by an autonomous system (which is my end-point use case) or essentially using the lab tools and remote (in my case, tethered) development. But looking ahead, how much longer will x86 be around? It's the IBM 360 in the age of VAX.

It would be very nice, though, if the (TcL-only?) version of Vivado ran on the Zybo. And if it ran there, it would run on any ARM including macs! I understand that would require AMD/Xilinx to port it, but I don't think it's a crazy idea. The world is moving away from x86... and more advanced apps would rather not have to lug around (in, say, a robot) an energy-sucking x86 co-processor with their Zynq just to (re)configure a bitstream for DFX (or rely on cloud processing when typically in an RF-denied environment for that matter).

It's optimized for the manufacturer, not the customer.

Good point, I misread your question. Really, if one doesn't have access to the GTP pins, is there any advantage to Artix over Spartan? I mean the Digilent boards are different, but at the chip level I only see minor differences between the two other than GTP support. What am I missing?

The following conversation might help answer your second question. In short, while the chip has the GTPs, they are not bonded to any pins in that package. However, a SelectIO pin is probably good enough for most purposes. https://support.xilinx.com/s/question/0D52E00007FSfYpSAL/xc7a100tcsg324a-gtp-pinout?language=en_US

I can't speak to the sample program specifically, but when malloc fails it usually returns NULL. So try if (flash_env == NULL) { return XST_FAILURE; ... Note, you probably have to include stdio.h to get the definition of NULL. Disclaimer: It's been 40+ years since I regularly programmed in C.

You might try following the QuickStart guide here: https://architechboards-zedboard.readthedocs.io/en/latest/quick.html While they don't point you to a consolidated BSP (at least as far as I could see), they do seem to have you download the contents and build it up separately on your host machine using bitbake.

According to UG909 (I looked at 2021.1): NB: "Dynamic Function eXchange" is what Xilinx is calling the feature they used to call "Partial Reconfiguration". B/R

Some of us can't handle the high glycemic index beverages...

I strongly agree with this in general; what's the customer going to do, take the HDL and run off to build their own PMOD? Plus with the HDL (open sourced) it would be relatively easy for customers who are still using old(er) PMODs to keep them working (perhaps creating pull requests for modified versions so others can benefit too).