readme.txt

The purpose of this code is to demonstrate how to utilize EZUSB FX GPIF interface.

This directory contains 8051 firmware for the EZ-USB FX chip.

The purpose of this code is to demonstrate how to utilize EZUSB FX GPIF 
interface.

The code is written in C and uses both the EZ-USB FX library and the FrameWorks.

This example is for illustrative purpose(s) and unless you have a slave that 
emulates the testing environment this example won't actually produce expected 
results when downloaded via Control Panel.  The slave in this case is another
CY3671 DK running in slave fifo mode (afifo8a example).



In this implementation the master to slave pin assignments are as follows:

master(FX GPIF mode)      slave(FX Slave FIFO mode)       
====================      =========================       
RDY2                      AOUTFLAG(ef)                    
RDY4                      AINFULL                         
CTL0                      ASEL                            
CTL2                      AOE                             
CTL5                      SLRD                            
CTL4                      SLWR                            
PORTB[7:0]                PORTB[7:0]                      
PC3                       PC2(shortpkt)                   
PC2                       PC3(zerolenpkt)                 



The Control Panel Application may be used to drive this example as described in 
the tutorials.

The gfbrds.hex file loads into internal memory.

...issue "build -i" at the command prompt, or
...launch fgbrds.uv2 project file and build from within Keil IDE


In addition to typical Control Panel usage... 
issue the following to sequence the start of xfr(s):

Steps:
- do a "GetPipes"...
- do a "View|PendingOps", if not already selected...

- type "0xB2" into "REQ" dialog box, to "xfrvia_TD_Poll"...
- type "1" into "LENGTH" dialog box...
- select "DIR: 1 IN", if not already selected...
- hit "VENDREQ" button...the "text box" last line should show "0000 B2"


...the code is ready to xfr data via EP2OUT and EP2IN...



"gpifafifo8a" firmware pseudo code:
 FX scheme for handling OUT data via GPIF - (3x buffering)
 =========================================================
 if endp not empty or fifo buffer not empty
   if buffer available
   	 -- pass-on pkt to master --
   	 dmalen=bc
   	 trigger dma xfr
   	 wait for dma xfr to complete
   	 re-arm endp
   else
     if gpif idle
       ** address slave **
       if slave not full
         tc=fifobc
         trigger FIFO write transaction
         if shortpkt
           wait for gpif xfr to complete
           signal shortpkt to slave

 FX scheme for handling IN data via GPIF
 ========================================
 if gpif idle
   ** address slave **
   if slave not empty or fifo buffer not empty
     if fifo buffer available
       trigger gpif FIFO read transaction
     else
       if endp buffer available
         dmalen=fifobc
         trigger dma xfr
         wait for dma xfr to complete
         pass-on buffer to host


"gpif_afifo8a", assumes: 
 01).  peripheral is a slave...
 02).  EP2OUT endp for OUT data and EP2IN endp for IN data....
 03).  only the A-FIFO is being utilized...
 04).  8-bit peripheral data bus...
 05).  EZUSB FX is only used to xfr data to and from peripheral and host...



some additional thoughts:
 ...to "favor" OUT data... (max USB bandwidth)
 The "gpif_afifo8a" firmware does this:
 ======================================
 if host sent data and aoutfifo empty then dma to aoutfifo...
 if peripheral bus not busy then....
  if aoutfifo has data and slave not full then gpif data into slave...
   else if slave has data and ainfifo empty then gpif data into ainfifo...
 if ainfifo has data and endp available then dma to host...


 ...to "favor" IN data... (fast slave)
 The "gpif_afifo8a" firmware does this:
 ======================================
 if peripheral bus not busy then....
  if slave has data and ainfifo empty then gpif data into ainfifo...
   else if aoutfifo has data and slave not full then gpif data into slave...
 if ainfifo has data and endp available then dma to host...
 if host sent data and aoutfifo empty then dma to aoutfifo...

 Generally, a couple of "corner" cases exist:
 ============================================
 if host sends zerolen OUT pkt...
 ...
 if slave sends zerolen IN pkt...

 ...perphaps more "corner" cases exist in your application specific 
 implementaion....
 
 
 
some measured results: (the current code base achieve max usb bandwidth)
 host xfr 64 bytes at ~50usec
 master writes/reads "async" byte at ~500ns

 measured async results:  wrote 4096 bytes in 11.3msec
 measured async results:  wrote 8192 bytes in 23msec
 ... don't forget that's really 2x, because slave had to read it too...
 ... master wrote ~1byte/1.4usec -> approx. 357bytes/SOF EP2OUT
 ... slave read ~1byte/1.4usec -> approx. 357bytes/SOF EP2IN
 ... so, ~714bytes sustained end-to-end 8-bit data rate/SOF ...
 ... ~11 packets/SOF, roughly 4 OUT TOKENs NAK'd

 it may be worth mentioning here that best case is ~1byte/1usec

 measured async results:  read 8192 bytes in 18.96msec
 ... don't forget that's really 2x, because slave had to write it too...
 ... slave wrote ~1byte/1.15usec -> 434bytes/SOF EP2IN
 ... master read ~1byte/1.15usec -> 434bytes/SOF EP2OUT
 ... so, ~869bytes sustained end-to-end 8-bit data rate/SOF ...
 ... ~13 packets/SOF, roughly 2 OUT TOKENs NAK'd

 using 19 bulk xfr's every 1msec, gives the 8051 ~52usec (~600 i/c)
 ... to keep the host happy, without getting NAK's

 a couple of ways to implement IN tokens:
 a). use IBN as the event trigger, ~2usec latency 
 b). always make data available to the host, zero latency (below)



additional vend_ax information:
 Core uses bRequest value 0xA0 for Anchor downloads/uploads...
 Cypress Semiconductor reserves bRequest values 0xA1 through 0xAF...
 Your implementation should not use the above bRequest values...
 Also, previous fw.c versions trap all bRequest values 0x00 through 0x0F...

   bRequest value: SETUPDAT[1]
   standard, 0x00 through 0x0F

   bmRequest value: SETUPDAT[0]
   standard,  0x80 IN   Token
   vendor,    0xC0 IN   Token
   class,     0xA0 IN   Token
   standard,  0x00 OUT  Token
   vendor,    0x40 OUT  Token
   class,     0x60 OUT  Token