library/scripts/adi_xilinx_device_info_enc.tcl: Add xcau (Artix UltraScale+) family

[CodeWarrior1241]

PR Description

Adds the ^xcau regex prefix to the FPGA_TECHNOLOGY part-family switch in
adi_device_spec, mapping Artix UltraScale+ parts (e.g. xcau15p) to
series_name 'ultrascale+', alongside the existing xczu/xcvu/xck26
ultrascale+ entries.

Motivation

Without this entry, xcau parts are matched by the more general ^xc.u
branch that follows in the same switch and are silently misclassified as
plain ultrascale. The returned FPGA_TECHNOLOGY then drives downstream
IP configuration — for example, IDELAY primitive selection in axi_ad9361 —
and the resulting attribute combination is rejected by Vivado's bitgen DRC
stage, which refuses to generate a bitfile for the design.

This change is consistent in shape and intent with prior single-line
additions to the same switch (e.g. K26 in 7112fbc, Versal in 4d12c4d,
VCU128 regex change in 9d94f21).

Test

Tested on xcau15p-ffvb676-2-e on the AUBoard-15P Development Kit,
building an axi_ad9361-based reference design: with this change,
adi_device_spec returns ultrascale+, downstream IP picks the correct
primitive variants, and bitgen completes successfully and the bitstream
runs on hardware.

PR Type

• Bug fix (change that fixes an issue)
• New feature (change that adds new functionality)
• Breaking change (has dependencies in other repos or will cause CI to fail)
• Documentation

PR Checklist

• I have followed the code style guidelines
• I have performed a self-review of changes
• I have compiled all hdl projects and libraries affected by this PR
• I have tested in hardware affected projects, at least on relevant boards
• I have commented my code, at least hard-to-understand parts
• I have signed off all commits from this PR
• I have updated the documentation (wiki pages, ReadMe files, Copyright etc)
• I have not introduced new Warnings/Critical Warnings on compilation
• I have added new hdl testbenches or updated existing ones

[CLAassistant]

All committers have signed the CLA.

[caosjr]

According to this list: https://docs.amd.com/v/u/en-US/ultrascale-plus-fpga-product-selection-guide the ultrascale+ models, assuming we are considering only the xc (xilinx commercial) models, will always something like xc<some_possible_part_version><some_letter_to_represent_device>u (see last page).

With that, I would suggest:

^xc\d*[vkaz]u

• ^xc — starts with "xc"
• \d* — zero or more digits (Gen 1 has none, Gen 2 has "2", future gens would have "3", etc.)
• [vkaz]u — family letter + "u"

What do you think? That would substitute the following regex:

^xczu {set series_name ultrascale+}
^xcvu.?.p {set series_name ultrascale+}
^xcau {set series_name ultrascale+}

[CodeWarrior1241]

Thanks for looking at this, @caosjr, makes sense to consolidate vs. add another line to the switch. One concern with ^xc\d*[vkaz]u though: it drops the trailing-p constraint that the existing ^xcvu.?.p entry relies on to distinguish Virtex UltraScale+ from plain Virtex UltraScale.

For the zu and au families the consolidation is safe as there's no non-plus Zynq UltraScale (7-series Zynq is 7-series xc7z) and no Artix UltraScale at all, so ^xczu and ^xcau can match unconditionally.

But for vu/ku, the p suffix is what separates plus from non-plus:

Part	Family	Current behavior	Under ^xc\d*[vkaz]u
xcvu9p	Virtex UltraScale+	ultrascale+	ultrascale+ ✓
xcvu440	Virtex UltraScale	ultrascale	ultrascale+ ✗
xcku040	Kintex UltraScale (KCU105)	ultrascale	ultrascale+ ✗
xcku115	Kintex UltraScale	ultrascale	ultrascale+ ✗

Since the first matching regex wins, the ^xc.u "plain ultrascale" fallback below would never be reached for those parts, and they'd get misclassified as ultrascale+. That would regress KCU105 among others.

Changing to two lines for clarity:

^xc(zu|au)       {set series_name ultrascale+}   ;# no non-plus variant
^xc\d*[vk]u\S*p  {set series_name ultrascale+}   ;# "+" requires trailing p

Could also go with a single line for brevity, but it seems more confusing:

^xc(zu|au|\d*[vk]u\S*p)   {set series_name ultrascale+}

What do you think about pushing the 2-line version?

[caosjr]

@CodeWarrior1241, I prefer the 2-line version due to its clarity.

[CodeWarrior1241]

I amended the PR to be the two-line option.

[CodeWarrior1241]

Hello,

Was wondering if there was any update on this?

Thanks!