FPGA CLK when designing an EZ-USB FX3 SlaveFifo Interface

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

cross mob
Anonymous
Not applicable

Hello everyone,

   

I'm currently working with the Superspeed Explorer Kit (CYUSB3KIT-003) to communicate with an FPGA ( type Altera Cyclone IV ). I'm following what's written on the application note AN65974 in which it is specified that the FPGA is functioning at 100 MHz with 32-bit data and that the FX3 master clock must be set to a little more than 400 Mhz.

   

- What does that exactly mean : why does the FX3 have to be 4 times faster than the FPGA?

   

- Does changing both FPGA and FX3 clocks is possible ? I'm obliged to work with only 50 MHz' FPGA : Can I communicate with my Superspeed Explorer Kit with this frequency knowing that I only want a 16-bit data bus ???

   

- Does changing the clocks affects the transfer rate of the USB 3.0 ?

   

Thanks in advance for your answers, I really really need them

0 Likes
6 Replies
Anonymous
Not applicable

Hi,

   

The FX3 master clock that you are referring to is the System clock(SYS_CLK) of the FX3. This passes through different dividers to generate clock for different blocks of FX3. This system clock depends on the crystal/clock connected to FX3. In the Superspeed explorer kit we have connected a 19.2 MHz crystal, so the  SYS_CLK defaults to 384 MHz. The GPIF II interface that the FX3 uses to communicate with the FPGA can run at maximum 100 MHz. This GPIF_CLK is taken from the pibclock, which is derived from this SYS_CLK. To get this maximum 100 MHz clock on the GPIF, we set the SYS_CLK to 403.2 MHz (using clkCfg.setSysClk400 = CyTrue; ) and set the pib divider as 4 ( using pibClock.clkDiv = 4;). This will make the GPIF_CLK as about 100 MHz (which is the maximum, the interface can work at).

   

You can change the GPIF interface clock by changing the divider which i just mentioned. If you want to work with a 50 MHz clock change this divider to 8(make necessary changes on the FPGA side also).

   

Yes, it will surely affect the transfer rate.As an example if you use the complete GPIF BW (say 32 bits * 100 MHz), you can achieve a theoretical max throughput of 3.2Gbps on the USB side. Similarly if you  use a 50 MHz and 16 bit GPIF interface, you can achieve a maximum of 0.8 Gbps on the USB side. 

   

You can refer to the FX3 Technical reference manual for more details.

   

Regards

   

Dhritiman

0 Likes
Anonymous
Not applicable

Thank you very very much, I really appreciate it

   

Regards

   

Sameh

0 Likes
Anonymous
Not applicable

Hello again,

   

I've changed pibClock.clkDiv to 8 ( it defaults to 2 in the AN65974 example and not to 4 like you told me ) and changed my FPGA PLL to 50Mhz. However, I can't communicate because I have the 997 error message

   

Could you please help me ?

0 Likes
Anonymous
Not applicable

Right Click on the project >> Select Index >> Do Freshen all Files  in the EZ USB suite  and then try building .

   

Regards

   

Dhritiman

0 Likes
Anonymous
Not applicable

Hello,

   

I have another question regarding this issue: I changed the FPGA clock to 50 MHz ( 54MHz exactly ) and left the GPIF clock to 100MHz. Knowing that I'm testing the streamIN program in the FPGA, everything seems to work fine and I get the information I send from the FPGA to my USB Host ( the C++ streamer application shows no failures ).

   

How can we explain this ? Is it logical that my FPGA and my FX3 communicate without errors even though their clocks are not even ? and what does that physically means : the buffers are filled faster than they are being read or what ?

   

Thank you for the explanation

0 Likes
Anonymous
Not applicable

In your case, the clock is coming from the external master. So the interface clock is 50 MHz (or whatever is coming IN from the master).In this case the GPIF state machine is running at 50 MHz. All the buffer filling will be done based on this clock.

   

 

   

The 100 MHz clock will not be used for this. It will be used for some other internal tasks of the GPIF block. 

0 Likes