603 lines
48 KiB
HTML
603 lines
48 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
|
||
"http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
|
||
<html lang="en">
|
||
<head>
|
||
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
|
||
<title>GPIF</title>
|
||
<meta name="generator" content="BBEdit 6.0">
|
||
<script language="JavaScript">
|
||
<!--
|
||
function na_preload_img()
|
||
{
|
||
var img_list = na_preload_img.arguments;
|
||
if (document.preloadlist == null)
|
||
document.preloadlist = new Array();
|
||
var top = document.preloadlist.length;
|
||
for (var i=0; i < img_list.length; i++) {
|
||
document.preloadlist[top+i] = new Image;
|
||
document.preloadlist[top+i].src = img_list[i+1];
|
||
}
|
||
}
|
||
|
||
function na_change_img_src(name, nsdoc, rpath, preload)
|
||
{
|
||
var img = eval((navigator.appName.indexOf('Netscape', 0) != -1) ? nsdoc+'.'+name : 'document.all.'+name);
|
||
if (name == '')
|
||
return;
|
||
if (img) {
|
||
img.altsrc = img.src;
|
||
img.src = rpath;
|
||
}
|
||
}
|
||
|
||
// -->
|
||
</script>
|
||
</head>
|
||
<body bgcolor="#FFFFFF" OnLoad="na_preload_img(false, 'images/cp-04.gif');">
|
||
|
||
|
||
<table border="0" cellpadding="0" cellspacing="0" width="90%" align="center">
|
||
<tr valign="top">
|
||
<td colspan="1" align="left">
|
||
|
||
<p align="center"><font face="verdana, arial, helvetica, sans-serif" size="2" color="#000000"><B><a name="SingleXactions"></a>Implementing FIFO
|
||
(multiple) Transactions</B></font>
|
||
</td>
|
||
</tr>
|
||
|
||
<tr valign="top">
|
||
<td colspan="1" align="left">
|
||
|
||
<p>
|
||
<font face="Verdana,Arial" size="1" color="#000000">A fully working external FIFO example using GPIF Single transactions has already been discussed, but the bandwidth achieved is miniscule.
|
||
This is because there is a lot of firmware overhead involved in launching GPIF Single transactions. With GPIF FIFO transactions, the GPIF engine
|
||
directly handles bursts of data, so a higher bandwidth over the physical interface is achievable.<br>
|
||
<br><a name="FlowStates"></a></font><font face="Verdana" size="1"><b>Introducing
|
||
the Flow State Feature of the GPIF<br><br> </b>In order to efficiently
|
||
handle bursts of data and meet burst access timing to the external
|
||
FIFO, the flow state feature of the GPIF was utilized for the FIFO
|
||
transaction example. The flow state feature makes its debut in the
|
||
FX2 GPIF and is a mechanism that allows the GPIF to efficiently
|
||
throttle data on and off the bus by using an independent set of
|
||
RDYn logic (flow logic) that is separate from the decision point
|
||
RDYn logic. Since the flow state feature is an advanced mode of
|
||
the GPIF, not every application will need to use the flow state.
|
||
However, handling bursts of data to and from an external FIFO shows
|
||
the simplest application of the flow state. One very advanced application
|
||
of the flow state is in the generation of UDMA waveforms for the
|
||
FX2 mass storage reference design firmware.</font>
|
||
<p><font face="Verdana" size="1">In any GPIF waveform, there can
|
||
only be one flow state, but it can be any of the available non-idle
|
||
states (S0–S6). The flow state behavior is controlled by a set of
|
||
registers that are specific to the flow state feature (see the FX2
|
||
Technical Reference Manual for flow state register details). One
|
||
can think of the flow state as being “orthogonal” to one of the
|
||
GPIF waveform’s states, but it is still the regular decision point
|
||
logic that is responsible for determining when the flow state should
|
||
be exited and the normal GPIF waveform behavior continues.</font></p>
|
||
<p><font face="Verdana" size="1">Another property of the flow state
|
||
is that it can be programmed to perform a different set of CTLx
|
||
logic than what is described in the GPIF waveform descriptors themselves.
|
||
This brings the level of autonomy to another notch. The idea behind
|
||
the GPIF FIFO Read and Write descriptor programming is to have the
|
||
read and write control lines assert for the duration of the transaction,
|
||
thereby allowing data to be moved on every edge of IFCLK. Therefore,
|
||
a 16-bit interface running at 48 MHz would yield an effective burst
|
||
data rate of 96 MB/s over the GPIF interface.</font></p>
|
||
<p><font face="Verdana" size="1">The main difference between this
|
||
FIFO transaction version and the single transaction version is that
|
||
waveforms 2 and 3 are used (FIFORd and FIFOWr waveforms, respectively)
|
||
instead of waveforms 0 and 1. RDY5 is used as the GPIF transaction
|
||
count (GPIF TC) internal expiration flag (TCXpire). The GPIF TC
|
||
is what is used in the waveform’s decision point logic to determine
|
||
when to exit out of the flow state and terminate the waveform.<br></font></p>
|
||
<p align="center"><font face="Verdana" size="1"><img src="images/BlkDiag2.gif" width="432" height="327" border="0"><br>Figure
|
||
16. Block Diagram for FIFO Transactions</font><font face="Verdana,Arial" size="1" color="#000000">
|
||
</font></p>
|
||
<p><font face="Verdana" size="1"><b><a name="WaveformDescriptors"></a></b><i>Figure
|
||
16</i> shows the set-up of the block diagram and the naming conventions
|
||
of the CTLx and RDYn signals (same as the single transaction example).
|
||
<i>Figure 17</i> below shows waveform 3, which characterizes the behavior
|
||
of the FIFO Write waveform.<br><br></font></p>
|
||
<p align="center"><font face="Verdana" size="1"><img src="images/FifoWr.gif" width="432" height="327" border="0"><br>Figure
|
||
17. FIFO Write waveform in GPIF Designer<br></font></p>
|
||
<p><font face="Verdana" size="1">In this FIFO Write waveform (waveform
|
||
3) we see that S0 is a period of inactivity, followed by S1 which
|
||
is designated as the flow state. The decision point logic in S1
|
||
looks at the GPIF TC to determine when to terminate the waveform
|
||
by branching to the IDLE state. As previously mentioned, the flow
|
||
logic in S1 then takes over to throttle data on and off the bus
|
||
and manipulate the CTLx lines. The flow state registers are set
|
||
up by selecting the various flow state parameters, accessed by right
|
||
clicking on the S1 state trace.</font></p>
|
||
<p><font face="Verdana" size="1">In order to set up the flow state
|
||
for both FIFO reads and writes, a set of global GPIF and flow state
|
||
registers are first initialized. The values are taken from a FlowStates[36]
|
||
array in gpif.c, generated by GPIF Designer.<br></font></p>
|
||
<ul>
|
||
<p><font face="Verdana" size="1">(Note: <i>The FlowStates array,
|
||
in GPIF.c, could be re-declared as FlowStates[4][9], for simplicity.
|
||
The first 9 elements contain the FlowState register values
|
||
for waveform 0. The next 9 elements contain the FlowState
|
||
register values for waveform 1, etc. Therefore, FlowStates[19]
|
||
is the same element as FlowStates[2][1].</i>)</font></p>
|
||
<p><font face="Verdana" size="1">EP2GPIFFLGSEL = 0x01; </font><font face="Verdana" size="1" color="#009900">//
|
||
For EP2OUT, GPIF uses EF flag</font><font face="Verdana" size="1"><br>SYNCDELAY;<br>EP6GPIFFLGSEL
|
||
= 0x02; </font><font face="Verdana" size="1" color="#009900">//
|
||
For EP6IN, GPIF uses FF flag</font><font face="Verdana" size="1"><br>SYNCDELAY;<br><br>//
|
||
global flowstate register initializations<br>FLOWLOGIC = FlowStates[19];</font><font face="Verdana" size="1" color="#009900">
|
||
// 0011 0110b - LFUNC[1:0] = 00 (A AND B), TERMA/B[2:0]=110
|
||
(FIFO Flag)</font><font face="Verdana" size="1"><br>SYNCDELAY;<br>FLOWSTB
|
||
= FlowStates[22]; </font><font face="Verdana" size="1" color="#009900">//
|
||
0000 0100b - MSTB[2:0] = 100 (CTL4), not used as strobe</font><font face="Verdana" size="1"><br>SYNCDELAY;<br>GPIFHOLDAMOUNT
|
||
= FlowStates[26]; </font><font face="Verdana" size="1" color="#009900">//
|
||
hold data for one half clock (10ns) assuming 48MHz IFCLK</font><font face="Verdana" size="1"><br>SYNCDELAY;<br>FLOWSTBEDGE
|
||
= FlowStates[24]; </font><font face="Verdana" size="1" color="#009900">//
|
||
move data on both edges of clock</font><font face="Verdana" size="1"><br>SYNCDELAY;<br>FLOWSTBHPERIOD
|
||
= FlowStates[25]; </font><font face="Verdana" size="1" color="#009900">//
|
||
20.83ns half period</font><font face="Verdana" size="1"><br>SYNCDELAY;<br></font></p>
|
||
</ul>
|
||
<p><font face="Verdana" size="1">The set-up is such that when FIFO
|
||
Write transactions are launched from EP2OUT, the GPIF uses EP2’s
|
||
empty flag (EF) as the FIFO Flag, and when FIFO Read transactions
|
||
are launched into EP6IN, the GPIF uses EP6’s full flag (FF) as the
|
||
FIFO Flag.</font></p>
|
||
<p><font face="Verdana" size="1">Subsequently, the flow logic is
|
||
set up to use the FIFO Flag to throttle data on and off the bus,
|
||
so the flow state mechanism actually uses EP2EF and EP6FF status
|
||
to know when to keep writing to the data bus or keep reading from
|
||
the data bus, respectively.</font></p>
|
||
<p><font face="Verdana" size="1">Although CTL4 (unused) is not used
|
||
in the application, we take advantage of the fact that the flow
|
||
state can use any of the CTLx lines as a data strobe. At a 48-MHz
|
||
IFCLK, CTL4 is toggled at a half period of 20.83 ns. Since the flow
|
||
state is also programmed to move data on both edges of the data
|
||
strobe, this allows us to nicely align the data values with the
|
||
rising edge of IFCLK and achieve a 96-MB/s burst rate over the physical
|
||
interface. Note that although CTL4 is not physically exposed on
|
||
the 56-pin package, the flow state logic can still be set up to
|
||
use it as a data strobe.</font></p>
|
||
<p><font face="Verdana" size="1">Let’s also examine the flow state
|
||
register set-up that is specific to FIFO Writes:<br></font></p>
|
||
<ul>
|
||
<p><font face="Verdana" size="1">void Setup_FLOWSTATE_Write
|
||
( void )<br>{<br>FLOWSTATE = FlowStates[18];</font><font face="Verdana" size="1" color="#009900">
|
||
// 1000 0001b - FSE=1, FS[2:0]=001</font><font face="Verdana" size="1"><br>SYNCDELAY;<br>FLOWEQ0CTL
|
||
= FlowStates[20]; </font><font face="Verdana" size="1" color="#009900">//
|
||
CTL0 = 0 when flow condition equals zero (data flows)</font><font face="Verdana" size="1"><br>SYNCDELAY;<br>FLOWEQ1CTL
|
||
= FlowStates[21]; </font><font face="Verdana" size="1" color="#009900">//
|
||
CTL0 = 1 when flow condition equals one (data does not flow)</font><font face="Verdana" size="1"><br>SYNCDELAY;<br>}<br></font></p>
|
||
</ul>
|
||
<p><font face="Verdana" size="1">Here we designate S1 to be the
|
||
flow state and define the state of CTL0 when the flow condition
|
||
equals zero (data flows) and when the flow condition equals one
|
||
(data does not flow). Remember that the state of the flow condition
|
||
is determined by the state of EP2EF. So when the EP2 FIFO contains
|
||
data (EP2 is not empty) the flow condition equals zero, the flow
|
||
state drops CTL0 LOW (WEN# is asserted), and data is placed on FD[15:0].</font></p>
|
||
<p><font face="Verdana" size="1"><i>Figure 18</i> below shows waveform
|
||
2, which characterizes the behavior of the FIFO Read waveform.<br></font></p>
|
||
<p align="center"><font face="Verdana" size="1"><img src="images/fiforead.gif" width="432" height="327" border="0"><br>Figure
|
||
18. FIFO Read waveform in GPIF Designer<br></font></p>
|
||
<p><font face="Verdana" size="1">In this FIFO Read waveform (waveform
|
||
2) S0 is a period of inactivity, then S1 and S2 sets up the “front
|
||
porch” of the burst transfer, followed by S3 which is designated
|
||
as the flow state. The decision point logic in S3 looks at the GPIF
|
||
TC to determine when to terminate the waveform by branching to the
|
||
IDLE state. As previously mentioned, the flow logic in S3 then takes
|
||
over to throttle data reads from the bus and manipulate the CTLx
|
||
lines.</font></p>
|
||
<p><font face="Verdana" size="1">Let’s examine the flow state register
|
||
set-up that is specific to FIFO Reads:<br></font></p>
|
||
<ul>
|
||
<p><font face="Verdana" size="1">void Setup_FLOWSTATE_Read (
|
||
void )<br>{<br>FLOWSTATE = FlowStates[27]; </font><font face="Verdana" size="1" color="#009900">//
|
||
1000 0011b - FSE=1, FS[2:0]=003</font><font face="Verdana" size="1"><br>SYNCDELAY;<br>FLOWEQ0CTL
|
||
= FlowStates[29]; </font><font face="Verdana" size="1" color="#009900">//
|
||
CTL1/CTL2 = 0 when flow condition equals zero (data flows)</font><font face="Verdana" size="1"><br>SYNCDELAY;<br>FLOWEQ1CTL
|
||
= FlowStates[30]; </font><font face="Verdana" size="1" color="#009900">//
|
||
CTL1/CTL2 = 1 when flow condition equals one (data does not
|
||
flow)</font><font face="Verdana" size="1"><br>SYNCDELAY;<br>}<br></font></p>
|
||
</ul>
|
||
<p><font face="Verdana" size="1">Here we designate S3 to be the
|
||
flow state and define the state of CTL1 and CTL2 when the flow condition
|
||
equals zero (data flows) and when the flow condition equals one
|
||
(data does not flow). Remember that the state of the flow condition
|
||
is determined by the state of EP6FF. So when the EP6 FIFO has room
|
||
for data (EP6 is not full) the flow condition equals zero, the flow
|
||
state drops CTL1 and CTL2 LOW (REN and OE are asserted), and data
|
||
is read from FD[15:0].<br><br>Since there is a different flow state
|
||
register set-up for FIFO read and write operations, the firmware
|
||
has to call Setup_FLOWSTATE_Read() before launching a GPIF FIFO
|
||
read transaction, and call Setup_FLOWSTATE_Write() before launching
|
||
a GPIF FIFO write transaction.</font></p>
|
||
<p><font face="Verdana" size="1">Now that you understand how the
|
||
GPIF FIFO read and write waveforms were programmed and set up, the
|
||
firmware programming for GPIF FIFO transactions can be discussed. </font></p>
|
||
|
||
</td>
|
||
</tr>
|
||
|
||
<tr valign="top">
|
||
<td colspan="1" align="left" height="13">
|
||
<p> </p>
|
||
</td>
|
||
</tr>
|
||
<tr valign="top">
|
||
<td colspan="1" align="left">
|
||
|
||
<p align="center">
|
||
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td colspan="1" align="center" height="13">
|
||
<p align="left"><font face="Verdana" size="1"><b><a name="FW"></a>FIFO Transaction
|
||
Firmware<br> </b></font></p>
|
||
</td>
|
||
</tr>
|
||
<tr valign="top">
|
||
<td colspan="1" align="left">
|
||
<p>
|
||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">In moving from GPIF Single transactions to GPIF FIFO transactions, the only major difference really lies in the TD_Poll() code. The basic underlying
|
||
architecture of the example remains the same. In this section, the basic principles of launching a FIFO transaction are introduced. Following that
|
||
is a discussion of the TD_Poll() code that triggers the GPIF FIFO transactions.<br> </font> </td>
|
||
</tr>
|
||
|
||
<tr valign="top">
|
||
<td colspan="1" align="left">
|
||
|
||
|
||
<ul>
|
||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><B><a name="Triggering"></a>Triggering GPIF FIFO Transactions<br><br></B>For triggering GPIF FIFO transactions, we reiterate the concept of the GPIF transaction count (TC). Analogous to the Tcount variable in the single
|
||
transaction example, the TC is a value the GPIF engine uses to determine how many times to go through a FIFO waveform.<br><br>For example, if the user wished to burst out 512 bytes of data from the EP2OUT endpoint, the TC value would be set to 512 (for byte wide operation) or 256
|
||
(for word wide operation). The GPIF engine then decrements the TC value on every push or pop of the FIFO. When the TC value reaches zero, the waveform is
|
||
complete (a waveform completion is signified by the GPIFDONE being set in the GPIFIDLECS register). A decision point state can use the TC value as an
|
||
internal flag to determine whether or not to branch to the IDLE state. GPIFREADYCFG.5 must be set to allow the GPIF engine to use the RDY5 signal as an
|
||
internal TC expiration flag.<br>
|
||
<br>
|
||
The act of triggering a GPIF FIFO transaction is actually very simple. Writing to the R/W bit in the GPIFTRIG register sets the direction of the
|
||
transaction. If R/W=1, a FIFO Read transaction gets triggered when accessing the GPIFTRIG register. If R/W=0, a FIFO Write transaction get triggered
|
||
instead.<br><br>For example, to trigger a GPIF FIFO Read transaction to EP6IN use the following line of code:<br><br></font>
|
||
<p><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">GPIFTRIG = GPIFTRIGRD | GPIF_EP6; <font color="#339933">// launch GPIF FIFO Read transaction to EP6IN<br><br></font>To trigger a GPIF FIFO Write transaction from EP2OUT use the following line of code:<br></font>
|
||
<p><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">GPIFTRIG = GPIF_EP2; <font color="#339933">// launch GPIF FIFO Write transaction from EP2OUT<br><br></font>GPIFTRIGRD, GPIF_EP6, and GPIF_EP2 are bit masks to set the appropriate bits in the GPIFTRIG register. By setting the EP[1:0] bits in the GPIFTRIG
|
||
register to valid options of 0,1,2, or 3 (in order of the endpoints 2,4,6, and 8), this specifies which endpoint should be used in the transaction.
|
||
Source or sink direction is implied by whether the endpoint is an IN or and OUT endpoint. </font>
|
||
</ul>
|
||
|
||
|
||
|
||
|
||
</td>
|
||
</tr>
|
||
|
||
<tr valign="top">
|
||
<td colspan="1" align="left">
|
||
|
||
<ul>
|
||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><B><a name="TD_Init("></a>TD_Init( ) </B></font>
|
||
</ul>
|
||
|
||
</td>
|
||
</tr>
|
||
|
||
<tr valign="top">
|
||
<td colspan="1" align="left">
|
||
<ul>
|
||
|
||
<p>
|
||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">The initialization code in <B>TD_Init( )</B> remains pretty much the same as the single transaction version. The main differences lie in the setup of the FIFOCFG
|
||
registers. To maximize the USB 2.0 bandwidth, the endpoints are placed into auto mode (AUTOOUT/AUTOIN=1). Note that the bits 1 and 0 of the REVCTL
|
||
register are not set. Therefore, it is necessary to first set AUTOOUT=0, then set AUTOOUT=1. The FX2 needs to see a 0 to 1 transition of the AUTOOUT
|
||
bit to automatically arm the endpoint buffers. </font>
|
||
</ul>
|
||
</td>
|
||
</tr>
|
||
|
||
<tr valign="top">
|
||
<td colspan="1" align="left">
|
||
<ul>
|
||
<p>
|
||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><font color="#339933">// set the CPU clock to 48MHz</font><br>
|
||
CPUCS = ((CPUCS & ~bmCLKSPD) | bmCLKSPD1);<br>
|
||
<font color="#666666">SYNCDELAY</font>; <br>
|
||
<br>
|
||
EP2CFG = <font color="#0000CC">0xA0</font>; <font color="#339933">// EP2OUT, bulk, size 512, 4x buffered</font><br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
EP6CFG = <font color="#0000CC">0xE0</font>; <font color="#339933">// EP6IN, bulk, size 512, 4x buffered</font><br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
<br>
|
||
FIFORESET = <font color="#0000CC">0x80</font>; <font color="#339933">// set NAKALL bit to NAK all transfers from host</font><br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
FIFORESET = <font color="#0000CC">0x02</font>; <font color="#339933">// reset EP2 FIFO</font><br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
FIFORESET = <font color="#0000CC">0x06</font>; <font color="#339933">// reset EP6 FIFO</font><br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
FIFORESET = <font color="#0000CC">0x00</font>; <font color="#339933">// clear NAKALL bit to resume normal operation</font><br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
<br>
|
||
EP2FIFOCFG = <font color="#0000CC">0x01</font>;<br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
EP2FIFOCFG = <font color="#0000CC">0x11</font>; <font color="#339933">// auto out mode, disable PKTEND zero length send, word ops</font><br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
EP6FIFOCFG = <font color="#0000CC">0x09</font>; <font color="#339933">// auto in mode, disable PKTEND zero length send, word ops</font><br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
<br>
|
||
GpifInit (); <font color="#339933">// initialize GPIF registers</font><br>
|
||
<br>
|
||
<font color="#339933">// reset the external FIFO</font><br>
|
||
OEA |= <font color="#0000CC">0x04</font>; <font color="#339933">// turn on PA2 as output pin</font><br>
|
||
IOA |= <font color="#0000CC">0x04</font>; <font color="#339933">// pull PA2 high initially</font><br>
|
||
IOA &= <font color="#0000CC">0xFB</font> <font color="#339933">// bring PA2 low</font><br>
|
||
EZUSB_Delay (<font color="#0000CC">1</font>); <font color="#339933">// keep PA2 low for ~1ms, more than enough time</font><br>
|
||
IOA |= <font color="#0000CC">0x04</font>; <font color="#339933">// bring PA2 high</font><br>
|
||
<br></font> </ul>
|
||
</font>
|
||
</td>
|
||
</tr>
|
||
|
||
<tr valign="top">
|
||
<td colspan="1" align="left">
|
||
|
||
<p>
|
||
|
||
<ul>
|
||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><B><a name="TD_Poll()"></a>TD_Poll()</B> </font>
|
||
</ul>
|
||
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td colspan="1" align="center" height="15">
|
||
<ul>
|
||
|
||
<p align="left">
|
||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">The first thing the OUT handling code does is it checks to see if the GPIF is IDLE. If so, it checks to see if there is at least a packet in the
|
||
peripheral domain for EP2. Since EP2 is placed into auto mode, the firmware does not need to check if the host sent a USB packet. The USB packets are
|
||
automatically committed to be used by the GPIF engine. Therefore, the firmware's job is to check if at least one packet has been committed to the
|
||
peripheral domain.<br>
|
||
<br>
|
||
Then, if the external FIFO is not full, the TC value is setup for word wide operation (256). The TC value is a 32-bit register field, but for this
|
||
application only the lower 16-bit fields are necessary. Since each GPIF FIFO Write transaction sends 512 bytes to the external FIFO over a 16-bit
|
||
interface, the number of transactions is always half the number of bytes actually contained within the endpoint buffer. The appropriate TC value is
|
||
setup for either high speed or full speed operation.<br>
|
||
<br>
|
||
The appropriate flow state registers are then setup for the FIFO Write transaction, and a write to the GPIFTRIG register with the appropriate bits
|
||
triggers the transaction from EP2OUT. The code then waits for the transaction to complete before exiting out of the "if" nest.<br><br><font color="#339933">// code that handles USB OUT transfers<br></font><br>
|
||
<font color="#990000">if</font>( GPIFTRIG & <font color="#0000CC">0x80</font> ) <font color="#339933">// if GPIF interface IDLE</font><br>
|
||
{<br>
|
||
<font color="#990000">if</font> ( ! ( EP24FIFOFLGS & <font color="#0000CC">0x02</font> ) ) <font color="#339933">// if there's a packet in the peripheral domain for EP2</font><br>
|
||
{<br>
|
||
<font color="#990000">if</font> ( EXTFIFONOTFULL ) <font color="#339933">// if the external FIFO is not full</font><br>
|
||
{<br>
|
||
<font color="#990000">if</font>(enum_high_speed)<br>
|
||
{<br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
GPIFTCB1 = <font color="#0000CC">0x01</font>; <font color="#339933">// setup transaction count (512 bytes/2 for word wide -> 0x0100)</font><br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
GPIFTCB0 = 0<font color="#0000CC">x00</font>;<br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
}<br>
|
||
<font color="#990000">else</font><br>
|
||
{<br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
GPIFTCB1 = <font color="#0000CC">0x00</font>; <font color="#339933">// setup transaction count (64 bytes/2 for word wide -> 0x20)</font><br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
GPIFTCB0 = <font color="#0000CC">0x20</font>;<br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
}<br>
|
||
<br>
|
||
Setup_FLOWSTATE_Write(); <font color="#339933">// setup FLOWSTATE registers for FIFO Write operation</font><br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
GPIFTRIG = GPIF_EP2; <font color="#339933">// launch GPIF FIFO WRITE Transaction from EP2 FIFO</font><br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
<br>
|
||
<font color="#990000">while</font>( !( GPIFTRIG & <font color="#0000CC">0x80</font> ) ) <font color="#339933">// poll GPIFTRIG.7 GPIF Done bit</font><br>
|
||
{<br>
|
||
;<br>
|
||
}<br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
}<br>
|
||
}<br>
|
||
}<br><br>Just like the single transaction firmware, if the in_enable flag is not set, the code will just sit there and not process the INs.<br>
|
||
<br>
|
||
If the in_enable flag is set, the code will fall through and check if the GPIF interface is IDLE. It then goes on to check if the external FIFO is
|
||
not empty. If the external FIFO has data, the code then determines if EP6 has room for at least one more data packet.<br>
|
||
<br>
|
||
If EP6 has room for at least one more data packet, the TC value is setup for word wide operation (256). The appropriate TC value is setup for either
|
||
high speed or full speed operation. The flow state registers are then setup for the FIFO Read transaction, and a write to the GPIFTRIG register with
|
||
the appropriate bits triggers the transaction to fill the EP6 FIFO. The code then waits for the transaction to complete. Since EP6 is placed into auto
|
||
mode, there is no need to explicitly write a byte count value to indicate how many bytes to send to the host. FX2 uses the EP6AUTOINLENH/L register
|
||
values set at enumeration time in the DR_SetConfiguration() function for the auto commit size.<br><br><font color="#339933">// code that handles USB IN transfers<br><br></font><font color="#990000">if</font> (in_enable) <font color="#339933">// if IN transfers are enabled</font><br>
|
||
{<br>
|
||
<font color="#990000">if</font> ( GPIFTRIG & <font color="#0000CC">0x80</font> ) <font color="#339933">// if GPIF interface IDLE</font><br>
|
||
{ <br>
|
||
<font color="#990000">if</font> ( EXTFIFONOTEMPTY ) <font color="#339933">// if external FIFO is not empty</font><br>
|
||
{<br>
|
||
if ( !( EP68FIFOFLGS & <font color="#0000CC">0x01</font> ) ) <font color="#339933">// if EP6 FIFO is not full</font><br>
|
||
{ <br>
|
||
<font color="#990000">if</font> (enum_high_speed)<br>
|
||
{<br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
GPIFTCB1 = <font color="#0000CC">0x01</font>; <font color="#339933">// setup transaction count (512 bytes/2 for word wide -> 0x0100)</font><br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
GPIFTCB0 = <font color="#0000CC">0x00</font>;<br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
}<br>
|
||
<font color="#990000">else</font><br>
|
||
{<br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
GPIFTCB1 = <font color="#0000CC">0x00</font>; <font color="#339933">// setup transaction count (64 bytes/2 for word wide -> 0x20)</font><br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
GPIFTCB0 = <font color="#0000CC">0x20</font>;<br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
}<br>
|
||
<br>
|
||
Setup_FLOWSTATE_Read(); <font color="#339933">// setup FLOWSTATE registers for FIFO Read operation</font><br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
GPIFTRIG = GPIFTRIGRD | GPIF_EP6; <font color="#339933">// launch GPIF FIFO READ Transaction to EP6 FIFO</font><br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
<br>
|
||
<font color="#990000">while</font> ( !( GPIFTRIG & <font color="#0000CC">0x80</font> ) ) /<font color="#339933">/ poll GPIFTRIG.7 GPIF Done bit</font><br>
|
||
{<br>
|
||
;<br>
|
||
}<br>
|
||
<br>
|
||
<font color="#666666">SYNCDELAY</font>;<br>
|
||
}<br>
|
||
}<br>
|
||
}<br>
|
||
}<br><br> </font>
|
||
</ul>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td colspan="1" align="center" height="15">
|
||
|
||
<p align="left"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><B><a name="Running"></a>Running the example for GPIF FIFO Transactions<br><br></B>The procedure for running the FIFO transaction example is essentially the same as the Single transaction example. Going through steps 1 through 3 of
|
||
section 4.1.6 will allow the user to run the FIFO transaction example as well. For running this version of the example, unzip the "FX2_to_extsyncFIFO GPIF
|
||
FIFO Transactions Auto mode.zip" package instead.<br>
|
||
<br>
|
||
A couple of differences to note are that LED0 will no longer flash when the code is downloaded, and that a few more vendor commands were added for
|
||
debug purposes. The LED0 code was taken out of TD_Poll() to optimize the firmware execution for FIFO transactions.<br>
|
||
<br></font><font face="verdana, arial, helvetica, sans-serif" size="1" color="#666666"><b>Debug Tip:</b><br>
|
||
The use of vendor commands is a "cheap" way to add more debug functionality to the code without incurring unnecessary "printf" statements. With the use of
|
||
vendor commands, the Keil debugger is not necessary for peeking and poking register values after the fact, which is what most GPIF firmware developers will
|
||
end up doing. For example, the vendor command 0xb6 was added to the FIFO transaction firmware to read back the status of the GPIF engine. The vendor
|
||
command returns the 0xb6 request with the value of the GPIFTRIG register. If the GPIF engine has completed a FIFO read or write transaction, the GPIFDONE
|
||
bit is set, returning a value of 0x80. The screenshot below shows what the user should see in the EZ-USB Control Panel window.<br></font>
|
||
<ul>
|
||
<p align="left"><A onClick="na_change_img_src('image1', 'document', 'images/cp-04.gif', true);"><B><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><img src="images/cp-04.gif" width="450" height="400" border="0" name="image1"></font></B></A><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><B><br> </B></font></p>
|
||
</ul>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td colspan="1" align="center" height="15">
|
||
|
||
<p align="left"><font face="Verdana" size="1"><b><a name="Traces"></a>Logic
|
||
Analyzer Traces<br></b><br>These are the traces the user should
|
||
see on the logic analyzer as the FIFO transaction example runs.
|
||
The traces were captured using an HP1660C logic analyzer.<br><br><b> </b></font></p>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td colspan="1" align="center" height="15">
|
||
|
||
<p align="left"><font face="Verdana,Arial" size="1" color="black"><b><a name="WriteTrace1"></a>FIFO Write</b></font><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">: Close-up view of the front porch<br><br>This trace shows that the 4 ns data setup time for the external FIFO is satisfied using the X to 0 marker as an indicator. The word
|
||
consisting of data values 0x02 and 0x03 is written into the external FIFO on the rising edge of IFCLK (the external FIFO's WCLK).
|
||
While WEN/ is held low, consecutive words are written into the external FIFO on every rising edge of IFCLK. Notice that the
|
||
GSTATE bus reflects the state of the GPIF engine as it's progressing through the GPIF FIFO Write waveform. S0 is a period of
|
||
inactivity for 1 IFCLK cycle (20.83 ns) and S1 is the flow state and is active for the entire duration of the data burst phase.<br><br></font><img src="images/law1.gif" width="544" height="364" align="center" border="0" ismap usemap="#cancel_map">
|
||
<p> </p>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td colspan="1" align="center" height="19">
|
||
|
||
<p align="left"><font face="Verdana,Arial" size="1" color="black"><b><a name="WriteTrace2"></a>FIFO Write</b></font><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">:
|
||
Close-up view of the back porch<br><br>Here we see the back end of the 512 byte transfer at a zoomed in level. The last word in the packet consists of data values 0xFE
|
||
and 0xFF (the end of our ramp test data). Note that a repeated word at the end is not clocked in as the setup time for the WEN/
|
||
line is not met prior to the IFCLK edge.<br><br></font><img src="images/law3.gif" width="545" height="363" align="center" border="0" ismap usemap="#ImageMap1"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"> <br><br> </font> </td>
|
||
</tr>
|
||
<tr>
|
||
<td colspan="1" align="center" height="15">
|
||
|
||
<p align="left"><font face="Verdana,Arial" size="1" color="black"><b><a name="WriteTrace3"></a>FIFO Write</b></font><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">:
|
||
Time taken to transfer 512 bytes to the external FIFO<br><br>This trace shows how long it takes to write a burst of 512 bytes (256 words) into the external FIFO. At a burst rate of 96MB/s (one
|
||
word every IFCLK period), this results in a time of approximately 5.3 microseconds to transfer a payload of 512 bytes. This zoomed
|
||
out view allows us to see that indeed the GPIF FIFO Write waveform remains in the flowstate until it is done transferring 512
|
||
bytes, at which point it then transitions to the IDLE state (S7).<br><br></font><img src="images/law2.gif" width="543" height="362" align="center" border="0" ismap usemap="#ImageMap2"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"> <br><br> </font> </td>
|
||
</tr>
|
||
<tr>
|
||
<td colspan="1" align="center" height="15">
|
||
|
||
<p align="left"><font face="Verdana,Arial" size="1" color="black"><b><a name="WriteTrace4"></a>FIFO Write</b></font><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">:
|
||
Inter-packet transfer time<br><br>In this trace we examine the inter-packet transfer time between consecutive OUTs sent by the host. Notice that the FX2 has
|
||
approximately 20 microseconds to spare before it has to burst out the next OUT packet. This means that the host is behind.<br><br></font><img src="images/law4.gif" width="544" height="362" align="center" border="0" ismap usemap="#ImageMap3"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"> <br><br> </font> </td>
|
||
</tr>
|
||
<tr>
|
||
<td colspan="1" align="center" height="15">
|
||
|
||
<p align="left"><font face="Verdana,Arial" size="1" color="black"><b><a name="ReadTrace1"></a>FIFO Read</b></font><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">:
|
||
Close-up view of the front porch<br><br>This trace shows that the 9.2 ns data setup time for the GPIF is satisfied using the X to 0 marker as an indicator. The word
|
||
consisting of data values 0x00 and 0x01 is read from the external FIFO on the rising edge of IFCLK (the external FIFO's RCLK).
|
||
While REN/ is held low, consecutive words are read from the external FIFO on every rising edge of IFCLK. Notice that the GSTATE
|
||
bus reflects the state of the GPIF engine as it's progressing through the GPIF FIFO Read waveform. S0 is a period of inactivity
|
||
for 1 IFCLK cycle (20.83 ns). In S1, the REN/ is asserted since the external FIFO requires that the REN/ be setup t<sub>ENS</sub> before
|
||
the OE/ line is asserted. S2 asserts the OE/ line, and S3 is the flow state and is active for the entire duration of the data burst phase.<br><br></font><img src="images/law5.gif" width="546" height="364" align="center" border="0" ismap usemap="#ImageMap4"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"> <br><br> </font> </td>
|
||
</tr>
|
||
<tr>
|
||
<td colspan="1" align="center" height="15">
|
||
|
||
<p align="left"><font face="Verdana,Arial" size="1" color="black"><b><a name="ReadTrace2"></a>FIFO Read</b></font><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">:
|
||
Close-up view of the back porch<br><br>Here we see the back end of the 512 byte transfer at a zoomed in level. The last word in the packet consists of data values 0xFE
|
||
and 0xFF (the end of our ramp test data). Note that a repeated word at the end is not clocked in as the setup time for the REN/
|
||
line is not met prior to the IFCLK edge.<br><br></font><img src="images/law7.gif" width="545" height="363" align="center" border="0" ismap usemap="#ImageMap5"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"> <br><br> </font> </td>
|
||
</tr>
|
||
<tr>
|
||
<td colspan="1" align="center" height="15">
|
||
|
||
<p align="left"><font face="Verdana,Arial" size="1" color="black"><b><a name="ReadTrace3"></a>FIFO Read</b></font><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">:
|
||
Time taken to read 512 bytes from the external FIFO<br><br>This trace shows how long it takes to read a burst of 512 bytes from the external FIFO. At a burst rate of 96MB/s (one word every
|
||
IFCLK period), this results in a time of approximately 5.3 microseconds to transfer a payload of 512 bytes. This zoomed out view
|
||
allows us to see that indeed the GPIF FIFO Read waveform remains in the flowstate until it is done transferring 512 bytes, at
|
||
which point it then transitions to the IDLE state (S7).<br><br></font><img src="images/law6.gif" width="547" height="364" align="center" border="0" ismap usemap="#ImageMap6"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"> <br><br> </font> </td>
|
||
</tr>
|
||
<tr>
|
||
<td colspan="1" align="center" height="15">
|
||
|
||
<p align="left"><font face="Verdana,Arial" size="1" color="black"><b><a name="ReadTrace4"></a>FIFO Read</b></font><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">:
|
||
Inter-packet transfer time<br><br>In this trace we examine the inter-packet transfer time between consecutive INs requested by the host. Notice that the FX2 has
|
||
approximately 20 microseconds to spare before it has to fulfill the next IN request. This means that the host is behind.<br><br></font><img src="images/law8.gif" width="544" height="362" align="center" border="0" ismap usemap="#ImageMap7"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"> <br><br> </font> </td>
|
||
</tr>
|
||
<tr>
|
||
<td colspan="1" align="center" height="15">
|
||
|
||
<p align="left"><font face="Verdana,Arial" size="1" color="black"><b><a name="BulkTrace"></a>Bulk Loopback</b></font><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">:
|
||
FIFO Reads and Writes<br><br>The user will observe the above wavefrom when the bulkloop utility is exercised. This trace shows activity that includes both reads
|
||
and writes to the external FIFO. We notice here that the host judiciously schedules INs and OUTs. No favoritism is shown to either
|
||
type of transfer.<br><br></font><img src="images/law9.gif" width="543" height="362" align="center" border="0" ismap usemap="#ImageMap8"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"> </font>
|
||
<p align="left"> </p>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td colspan="1" align="center" height="15">
|
||
|
||
<P align="left"><font size="1" face="Verdana"><b><a name="Summary"></a>Summary<br></b></font></P>
|
||
<p align="left"><font size="1" face="Verdana">This design example of a 16-bit interface to an external synchronous FIFO has
|
||
brought to the forefront many GPIF programming fundamentals, such as determining
|
||
GPIF hardware connections, creating GPIF single and FIFO waveform descriptors
|
||
using the GPIF Tool, and how to launch GPIF single and FIFO transfers in
|
||
firmware. The user should now have a firm grasp of what it takes to create a
|
||
full featured GPIF applications solution, and how to go from a simple set of
|
||
firmware that utilizes GPIF single transactions, to a more complex and robust
|
||
application that uses GPIF FIFO transfers. Also, by now the user should be aware
|
||
that the logic analyzer is a GPIF programmer's best friend. Let's extend the
|
||
basic toolset the user should already have by presenting a more </font><A
|
||
href="../../dsp/app_note.htm" target=_top><font size="1" face="Verdana">complex design example using a TI
|
||
DSP</font></A><font face="Verdana" size="1">.<BR></font></p>
|
||
</td>
|
||
</tr>
|
||
</table>
|
||
|
||
<map name="cancel_map">
|
||
<area shape="rect" coords="381, 5, 435, 28" onClick="parent.frames[0].location='../cFifo106.htm'; parent.frames[1].location='../nFifo106.htm';">
|
||
</map><map name="ImageMap1">
|
||
<area shape="rect" coords="392, 4, 448, 26" onClick="parent.frames[0].location='../cFifo106.htm'; parent.frames[1].location='../nFifo106.htm';">
|
||
</map><map name="ImageMap2">
|
||
<area shape="rect" coords="390, 4, 447, 26" onClick="parent.frames[0].location='../cFifo106.htm'; parent.frames[1].location='../nFifo106.htm';">
|
||
</map><map name="ImageMap3">
|
||
<area shape="rect" coords="391, 4, 448, 26" onClick="parent.frames[0].location='../cFifo106.htm'; parent.frames[1].location='../nFifo106.htm';">
|
||
</map><map name="ImageMap4">
|
||
<area shape="rect" coords="392, 4, 449, 27" onClick="parent.frames[0].location='../cFifo106.htm'; parent.frames[1].location='../nFifo106.htm';">
|
||
</map><map name="ImageMap5">
|
||
<area shape="rect" coords="392, 4, 448, 26" onClick="parent.frames[0].location='../cFifo106.htm'; parent.frames[1].location='../nFifo106.htm';">
|
||
</map><map name="ImageMap6">
|
||
<area shape="rect" coords="393, 4, 450, 27" onClick="parent.frames[0].location='../cFifo106.htm'; parent.frames[1].location='../nFifo106.htm';">
|
||
</map><map name="ImageMap7">
|
||
<area shape="rect" coords="391, 4, 448, 26" onClick="parent.frames[0].location='../cFifo106.htm'; parent.frames[1].location='../nFifo106.htm';">
|
||
</map><map name="ImageMap8">
|
||
<area shape="rect" coords="390, 4, 447, 26" onClick="parent.frames[0].location='../cFifo106.htm'; parent.frames[1].location='../nFifo106.htm';">
|
||
</map></body>
|
||
</html>
|