Honored Contributor
Honored ContributorI had the same problem with those hideous setup-times of FT2232, even with forcing the register to be in the I/O-pad. The clock-delay is too long if you route the incoming clock to the registers.
I had to recreate an 1:1 copy of the incoming USB clock with a PLL in Normal compensation mode. This automatically shifts the PLL outclock to compensate for the bulk of the delay in the clocktree. After this, you still have no time to do any logic, but all inputs and outputs from the FT2232 have to be registered. Yes, inputs too - the FT2232 has up to 7.15 ns delay in the fifo signals RXF and TXE leaving little margin inside the FPGA for anything except a register. I'm still struggling with the write-state machine though, where I have to monitor the external fifo-full signal (TXF), which is registred and thus delayed 1 cycle, to see if a write "didn't take". Unfortunately it's not very simple, as by the time you detect this, you will have acked *two* bytes from the fifo in the FPGA, leaving you to juggle around up to two bytes (one if the internal FIFO got empty), causing a real MESS when trying to resend them :/ You could conceivably even run into the situation where bytes are read out-of-order by the FT2232. If anybody has any ideas: writes occurs through pin-based FPGA-registers data_out_r and wr_n_r, and the FT2232 fifo-full is from the registred input txe_n_r. If we have data to write, and load 0 in wr_n_r and data in data_out_r, the cycle it shows on the output the FT2232 might inactivate txe_n. We won't see this until the cycle after, when we need to have yet another byte out on the bus to get the full throughput. So at that point, we have the byte we lost completely, and we have the byte currently on the data_out_r. I tried adding another register that keeps the last byte from data_out_r. But then I got into the mess with trying to resend them both after txe_n_r activates again in a clean way preferably not going into a special state where they are both completely transmitted before starting reading from the internal FIFO. I don't know if the FT2232 is designed so it can end up in a state toggling txe for every byte, which would cause a huge loss in performance with the above solution :/ Huaarhh.
