GPIF voltage issue

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
fcancli
Level 1
Level 1
5 sign-ins First solution authored First reply posted

Hi,

I am using the CYUSB3KIT-003 EZ-USB™ FX3 SuperSpeed Explorer Kit connected to an FPGA through the GPIF interface.

The transmission from FPGA to the FX3 works fine, whereas in the other direction I have some issues.

15 out of 32 data signals are driven high properly, i.e. they reach more or less the 3.3V value; the other 17 instead can only reach a value of 2V. In addition, there is a voltage drop on the 22-ohm series resistors of these 17 signals, meaning that there is a current flowing somewhere (about 20-30mA, but still I am wondering how is it possible, since it is connected to an FPGA pin, that is high Z).

Dually, the above 15 data signals are not driven down to 0V, as they reach 1V (and there is the same voltage drop across the series resistors), whereas the other 17 can go down to 0V. All 32 signals are connected to the same FPGA bank.

I have tried everything possible downstream of the FX3 pins, so it seems that the culprit of this cumbersome behavior is the FX3. The firmware code is taken from an example provided and slightly adapted. The GPIF designer was used to generate the .h file to include. 

So my question is if I am missing a pin setting or something else in the configuration process. But the strange thing is that half of the pins behave in the opposite manner with respect to the other half.

Thank you

0 Likes
1 Solution

Because I am using the evaluation kit which has the 22 ohm already soldered on it. The workaround adopted has been to remove all of them. In this way, the analog value reached is not correct but their logical value is recognized correctly by the FPGA. Still, this behavior remains a mystery to me,  but anyway, since I don't need high performances when writing to the FPGA, it's fine.

View solution in original post

0 Likes
4 Replies
AliAsgar
Moderator
Moderator
Moderator
1000 replies posted 250 solutions authored 750 replies posted

Hi,

I have some questions to ask in order to understand the issue better.

1. If there is nothing connected to the GPIF of FX3 and if you try to drive the pins, is the issue seen there as well?

2. Are the 15 pins in a continuous manner, i.e DQ[0:14] or are the pins distributed randomly?

3. How is it concluded that FX3 is behind the issue?

4. Which firmware example is used to program the FX3?

Best Regards,
AliAsgar

0 Likes

Hi AliAsgar,

I answer all your points:

1. Without the 22-ohm series resistors the GPIF pins reach the nominal value since they are floating.

2. The pins are distributed randomly

3. I have tried using different FPGAs, checking that their pins were set as inputs. They were inputs indeed since I was able to pull them up to 3.3V using an external resistor, whereas the cypress was not able to pull them up. The FPGA firmware only contains the essential block needed to provide the clock, OE, and RD signals reading the control flags. I have also tried leaving DQ pins unused, setting them to pull-none. Along the signal path, there is nothing but the 22-ohm resistors. We are driving the DQ bus with the same value so that there are no transitions: it is a DC problem, so traces routing should not be a problem. The only thing remaining is the FX3, which I cannot replace since I have just one.

4. I used the GPIF_example_8 and 9 that are provided with John Hyde's book adding a socket in order to make them bidirectional (GPIF to USB and vice-versa). Also, I used the sync_slave_fifo_2bit example in the GPIF designer, adding two more flags and the 32 bit bus width.

Regards,

fcancli

0 Likes
AliAsgar
Moderator
Moderator
Moderator
1000 replies posted 250 solutions authored 750 replies posted

Hi fcancli,

Why are 22 ohm series resistors connect on the GPIF lines externally?

Best Regards,
AliAsgar

0 Likes

Because I am using the evaluation kit which has the 22 ohm already soldered on it. The workaround adopted has been to remove all of them. In this way, the analog value reached is not correct but their logical value is recognized correctly by the FPGA. Still, this behavior remains a mystery to me,  but anyway, since I don't need high performances when writing to the FPGA, it's fine.

0 Likes