I have seen a certain amount of success with the Au v2 already. Even though I ported to using Vivado instead of Alchitry Labs, I was able to make some basic sample projects in Labs to get it to generate constraint files which told me what the new pins were for everything.
I am able to connect the Au v2, using the v2->v1 converter, to a Ft v1, and my target board, and everything is functional. I initially tried to use the Ft v2 which I ordered, but it fails because apparently the Ft v2 brings in new ft_wakeup and ft_reset pins, which I don’t know what to do with yet, and furthermore I am using the pins those are mapped to in my design! This is not a hard block, because I can keep using my Ft v1. But it would be useful to know what those pins are supposed to do so that I can handle them properly when I design a new version of my board that directly supports the new connectors. I can shuffle my pin assignments around to remove the conflict.
Actually I looked at the FT60x datasheet and figured out what those pins do, I don’t need an explanation. And it does explain why I saw the behavior I did. Because I’m using the ft_reset pin for something else, as soon as that “something else” started asserting the line, the FT chip stopped responding, because the chip was continuously being reset.
Although access to a reset for the FT chip will be handy in the long run. I was seeing situations where the FT would get into a bad state, and I would need to completely power down my FPGA to recover, and hopefully access to a reset will let me recover from those states programmatically. Pretty sure I don’t need to use the wakeup pin for anything, but that’s fine, I can just tie it appropriately and move on.
Glad you got it working. The Ft demo projects tie the lines to their “working” values for reference.
The old Ft had a minor issue with the USB multiplexer (needed for handling the orientation of the USB C port) that I think lead to the Ft not always enumerating when plugged in if the board was already powered (via the Au/Cu). This was fixed on the new ones.
What bad states were you seeing/do you know what caused them?
I never fully characterized the problem, but it sounds similar to what you describe. Sometimes while testing, particularly when reflashing, the USB connection would break and not come back until I fully power cycled the FPGA board. Didn’t dig into specifics, I was always focused on other stuff when it happened and didn’t want to get distracted at the time.
Currently doing a major refactor, changing the code to SystemVerilog, and rewriting a lot of stuff now that I’m starting to get a better idea about FPGA development. I’d never touched FPGAs before July last year. While I got things working pretty fast, my code was absolutely amateur-hour stuff.