xvcd "works", but Vivado says "No devices detected on target"

[cshimmin]

I'm trying to get an artyboard a7 working; it shows up in lsusb as having the compatible device (vendor 0x0403, product 0x6010). xvcd starts up okay, doesn't complain about missing devices, and patiently begins to listen on 2542. When I open Vivado in the container, in the hardware manager, the auto-connect feature quickly finds a "target" at host.docker.internal:2542. However, I get an error saying no devices are detected, and hence I'm unable to flash my bitstream.

I saw that @james-kollross had this exact issue, in the somewhat unrelated thread https://github.com/ichi4096/vivado-on-silicon-mac/issues/20#issuecomment-1716804381. I don't know if it was ever resolved though?

Any help would be greatly appreciated! Thanks for the amazing project :)

[cshimmin]

Oh, also to add, I ran xvcd with extra verbosity, and from the moment I hit auto-connect in Vivado, I see a bunch of "shift" commands coming through to the xvcd server, with some inscrutable binary payload. It seems to be the same command(s) over and over. Maybe it's some kind of probe to determine what device is on the other end?

[ichi4096]

This is because the FT2232HQ USB bridge chip in your board is not supported by this version of xvcd, which only supports the FT2232C chip. Since I have a board with your FTDI chip, I may add support for it in the future.

[cshimmin]

Ah thanks, I did not realize there were different chips with the same VID/PID. I might be able to send a PR, will give it a go 👍

[cshimmin]

So, I was able to get xvcd working with my a7 board. After much experientation, it turns out all that needed to change was the value of PORT_MISC here: https://github.com/ichi4096/vivado-on-silicon-mac/blob/50f820f097ee3febf12be7931e13a9d595d05acf/scripts/xvcd/src/io_ftdi.c#L16

Setting this constant to 0x80 solved my issue. As far as I understand, this just toggles whether or not pin 4 (a.k.a. GPIOL0) is configured for bitbang output. If the 0x80 value works for the other board(s) you test on, perhaps we can set this as the default? Otherwise, we can use ftdi->type to determine whether the resolved peripheral is FT2232C or FT2232H, and automatically set the appropriate value.

Let me know which one you prefer, and I'd be happy to send a PR.

[ichi4096]

I'm actually not familiar with how FTDI chips work, so I can't really reason about which bitmask makes sense. But according to this document, the xvcd code follows neither the asynchronous nor the synchronous bitbang mode bitmasks. See this and the immediately following line of code and the relevant libftdi documentation. Since it all seems a bit inconsistent to me anyway, I'd be fine with changing the value to 0x80. I myself no longer have access to an FPGA with a FT2232C chip, so I can't test with it.

[cshimmin]

Yes, I saw that line setting initially all pins to CBUS, and then only select pins to SYNCBB. And after staring at the datasheets and the not-so-informative libftdi documentation, I don't really understand what's going on either.

I assume at some point you had tested this xvcd implementation on a FT2232C chip? If so, the existing value is a known-good-configuration for that board. So instead of potentially breaking compatibility, I will just send you a PR that automatically chooses between 0x90 and 0x80 based on the detected hardware. It might be helpful anyway for supporting any other chips people come across in the future.

[ichi4096]

I did originally have access to an FPGA with the FT2232C chip. Maybe I'll get around to testing it in a week or two, but I can't promise that since it's my universitiy's property.

I take some issue with introducing control flow into an application we don't fundamentally understand to support a device we can't test with. But if it's only minor changes and it works with the FT2232H chip, I'll accept your PR.