No Devices Detected with Vivado Hardware Manager

Hello. I have created a simple Vivado blinky project targeting the Alchitry Au+ (brand new out of the box), and would like to test it out. I did the usual thing of opening the Vivado Hardware Manager and trying “Open Target” but I got the error message “No devices detected on target”. I thought maybe this was a driver issue, so I connected the “FT Prog” tool and I can indeed see a product description of “Alchitry Au+”, so I believe the FTDI chip is setup correctly. The drivers in Windows show up as “USB Serial Converter A” and “USB Serial Converter B” and I get a COM port instantiated.

I should be able to detect the FPGA device in the Vivado Hardware manager with just the USB cable attached, correct? Any suggestions?

Alchitry has gone “off reservation” and is not an official Xilinx dev board, so it will not show up under hardware manager. You have to either load files from Alchitry Labs or the dedicated loader app.

As prebys said, the Au isn’t an official Xilinx board so you need to use the Alchitry Loader to program it. You could hook up an external JTAG programmer to the pins on bank D then program it through Vivado but that’s not really worth it unless you need to do some debugging or something special.

In theory, the FT2232 (USB->JTAG chip we use) could be made to show up in Xilinx’s tools but that’s against their ToS.

The loader is part of Alchitry Labs.

I noticed that the recent releases of Vivado includes a command-line tool that can reprogram any FTDI2232 chip to be used with Vivado.

So it looks like they are giving us an “official” way to do it without fiddling with the FTDI tools.

Does this means the ToS have changed and we are now allowed to do this?

Would using this official tool void the warranty of the board?

Oh that’s interesting I’ll have to look into this.

Re-flashing the FT2232 won’t void your warranty but it might cause the Alchitry Loader to stop recognizing it unless you flash it back to the defaults.

EDIT: I just tried it out and you can make it work with both Vivado and Alchitry Labs.

./program_ftdi -write -f FT2232H -v "Alchitry" -b "Alchitry Au" -d "Alchitry Au" -s 000000

Use “Alchitry Au+” if you have an Au+. The serial number isn’t used by Alchitry Labs so you can set it to anything.

Hello,

I just tried it and it works perfectly!
I copied the existing serial just in case but the board if detected by Labs, Loader and Vivado.

It looks like the only changed in EEPROM are the manufacturer beeing set to “Xilinx” and some magic numbers in the user region.

I don’t know if this is intended from Xilinx/AMD to allow this, but if it is then it’s a pretty cool gift!

It used to be copying the magic numbers wasn’t allowed but I don’t see why they’d care. Especially now that they have a utility that does it for you. Last I looked into this way years ago.

Probably because they used to scandalously overprice the programming cables, but since there is now many alternative ways to do JTAG and unofficial clones everywhere, maybe they started to focus on chips and boards and makes them more accessible?

I don’t even know if we are actually allowed to use this utility, but it’s bundled with Vivado so… :smiley:

For anyone who comes here looking for answers. I got this to work on Debian using two steps.

I exclusively got it to work on with the Vivado 2022.2 version of “program_ftdi”.
And I needed to apply the following fix first:
xsct, xsdb, xmd, and tclsh segfault

How does one flash it back to the defaults, if one wanted to? It sounds like the above incantation with program_ftdi will make it work for either platform, so in theory one wouldn’t need to? I’m asking out of an abundance of caution before I go doing anything that might be tricky to undo. I am hoping to graduate to direct Vivado relatively quickly because I can see my project getting complicated enough that I’ll be wanting to work within Vivado for things like unit tests et cetera.

This is not a slight on the Alchitry gui! The gui was so incredibly simple to use that I got my project off the ground all the way to a demo-ready state in just a couple weeks! I’m getting ready to take the training wheels off but I’m very glad that they were there.

You can use FT_PROG to make backup of the settings before flashing.

I’m planning to bake Vivado compatibility into the V2 boards.

1 Like

I thinks it’s the way to go, because an out-of-the-box compatibility with Vivado may bring companies interest into Alchitry boards for prototyping or design testing boards, because those only uses long established languages and tools, and because there are little to no competition to Alchitry with such prices :star_struck:

I remember reading a post on a forum of someone who bought a Cu and asked which language to learn first, and an hardware designer answering that a language that is exclusive to a single small company is an absolute no-go in professional environment.

So having official Vivado support may bring new users and at the same time should give visibility to Lucid because they will probably take a look out of curiosity and may give useful feedback :grinning:

Hi, could you help me with it, please? I have tried it in Vivado 2024.1 and got this error:


****** program_ftdi v2024.1
  **** Build date : May 22 2024-19:19:16
    ** Copyright 1986-2022 Xilinx, Inc. All Rights Reserved.
    ** Copyright 2022-2023 Advanced Micro Devices, Inc. All Rights Reserved.




couldn't load library "libtclftd2xx.dll": this library or a dependent library could not be found in library path
    while executing
"tcl::load libtclftd2xx.dll"
    invoked from within
"load $ftdi_lib"
    (file "C:/Xilinx/Vivado/2024.1/scripts/program_ftdi/ftd2xx.tcl" line 53)
    invoked from within
"source [file join [file dirname [info script]] ftd2xx.tcl]"
    (file "C:/Xilinx/Vivado/2024.1/scripts/program_ftdi/ftdieeprom.tcl" line 40)
    invoked from within
"source [file join [file dirname [info script]] ftdieeprom.tcl]"
    (file "C:/Xilinx/Vivado/2024.1/scripts/program_ftdi/program_ftdi.tcl" line 40)

I just had that problem myself. It’s actually broken in that version of Vivado. Upgrade to the newest one, 2024.2, and it will work.

Thanks a lot, It works with 2024.2 now. Is possible program configuration memory as well? SST26VF032 not listed.

As stated in the other topic, you still need to use Alchitry Loader to program the flash.

I guess we would need to write a new bridge design for this chip because Vivado don’t have one.

Unfortunately, I don’t think Vivado lets you add other flash chips to the hardware manager even though it’s likely compatible with one that’s already in the list except for having a different ID code.

The bridge bin is in in the Alchitry Labs files and I’d be happy to share the source for it if anyone thought it would be helpful.

I could change the flash chip on the new boards but I really like the current one because it is super fast to program. Most flash chips take 30-90 seconds to erase but the one we use takes a few milliseconds. I also just bought 2000 of them…

2 Likes

I found out that Vivado have a set of bridge files stored in Xilinx\Vivado\<version>\data\xicom\cfgmem\bitfile.zip.

In the hardware manager we can manually pick one of them, but it looks like it only allows us to tell which interface is used.

It seems the list of allowed flash chip may be hard-coded somewhere but I can’t find it so far.

What I was thinking is : if we can write a custom bridge that would be accepted by Vivado, then maybe we can spoof the flash ID to one that is in the Vivado’s list?

Now the question is, do we have what we need (specs, docs, etc. of what Vivado expect?, Is it standard?)

EDIT: I found something that looks like a configuration file that define how to handle various flash chips :
Xilinx\Vivado\<version>\data\xicom\spi.cfg
Maybe we just have to add our chip’s parameters in that?

And this one too :
Xilinx\Vivado\<version>\data\xicom\xicom_cfgmem_part_table.csv

I managed to add the chip to the list, but Vivado don’t have QSPI bridge file for Artix7, so I tried simple SPI instead but it looks like the built-in SPI bridge don’t get answers from the chip :
readback_hw_cfgmem -hw_cfgmem [get_property PROGRAM.HW_CFGMEM

[get_hw_devices xc7a35t_0 ]] -file F:/Xilinx/proj/System1/System1.runs/impl_1/test.rmcs -format MCS -force -all
Mfg ID : 0   Memory Type : 0   Memory Capacity : 0   Device ID 1 : 0   Device ID 2 : 0