Initial check in
This commit is contained in:
@@ -0,0 +1,24 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>Index</title>
|
||||
<base target="contents"></head>
|
||||
|
||||
<body bgcolor="white" text="black" link="blue" vlink="purple" alink="red">
|
||||
<table cellpadding="0" cellspacing="0" width="100%" align="center">
|
||||
<tr>
|
||||
<td width="198" height="26">
|
||||
<p align="center"><span style="font-size:12pt;"><font face="Verdana"> </font></span></p>
|
||||
</td>
|
||||
<td width="441" height="26">
|
||||
<p align="center"><strong><samp><font color="black" face="Verdana"><span style="font-size:12pt;"><b>FIFO
|
||||
DESIGN EXAMPLE</b></span></font></samp></strong></p>
|
||||
</td>
|
||||
<td width="189" height="26">
|
||||
<p align="right"><strong><samp><font color="#0000CC" face="Verdana"><span style="font-size:12pt;"><img src="images/smalllogo.gif" width="95" height="30" border="0"> </span></font></samp></strong></p>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr></body>
|
||||
|
||||
</html>
|
||||
@@ -0,0 +1,602 @@
|
||||
<!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>
|
||||
@@ -0,0 +1,846 @@
|
||||
<!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-01.gif', 'images/cp-02.gif', 'images/cp-03.gif');">
|
||||
|
||||
|
||||
<table border="0" cellpadding="0" cellspacing="0" width="90%" align="center">
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="left" width="744">
|
||||
|
||||
<p align="center"><font face="verdana, arial, helvetica, sans-serif" size="2" color="#000000"><B><a name="SingleXactions"></a>Implementing Single Transactions</B></font>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="left" width="744">
|
||||
|
||||
<p>
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">As previously mentioned, the simplest GPIF waveforms to produce are the single read and single
|
||||
write waveforms. Performing this
|
||||
function first not only enhances the initial user experience with the design, but also allows the design to be in fairly good shape, fairly quickly. Of
|
||||
course, for high bandwidth applications the natural migration is then to create FIFO read and write transactions.
|
||||
But, the implementation of single
|
||||
transactions is the right place to start. The
|
||||
first section discusses the single transaction waveforms implemented using GPIF Designer and the next section
|
||||
covers the firmware that triggers them.<br>
|
||||
|
||||
</font><font face="Verdana,Arial" size="1" color="#000000"><br></font> <p align="center"><font face="Verdana" size="1"><img src="images/SingleBlkDiag.gif" width="432" height="327" border="0"> <br>Figure
|
||||
12. GPIF Designer Block Diagram</font></p>
|
||||
<p>
|
||||
<font face="Verdana" size="1">The GPIF Designer makes creating GPIF waveform
|
||||
descriptors easy. Rather than having to know each bit of the waveform
|
||||
descriptor opcode bytes in detail to create a waveform, the GPIF
|
||||
Designer allows you to “draw” each waveform and export the waveform
|
||||
descriptors to a self-contained file, typically called gpif.c. When
|
||||
you open GPIF Designer, it will present you with a block diagram
|
||||
view of the physical interconnect as shown in <i>Figure 12</i>. You can
|
||||
then use the block diagram view to name the individual</font><font face="Verdana,Arial" size="1" color="#000000">
|
||||
</font><font face="Verdana" size="1">CTLx lines and
|
||||
RDYn signals. These names propagate into the waveform tabs, allowing
|
||||
you to personalize each waveform and determine which signals are
|
||||
being manipulated. You can also use the block diagram to configure
|
||||
the clock properties of IFCLK, select different package types, and
|
||||
label the external slave device.<br><br><b><a name="WaveformDescriptors"></a></b>We
|
||||
can see that the naming conventions are consistent with the hardware
|
||||
set-up. The single write waveform (waveform 1) is shown below in
|
||||
<i>Figure 13</i>.<br></font>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="387" width="744">
|
||||
<p align="center"><font face="Verdana" size="1"><img src="images/singlewr.gif" width="432" height="327" border="0"><br> Figure
|
||||
13. Single Write waveform in GPIF Designer<br></font></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center" width="744">
|
||||
<p align="left"><font face="Verdana" size="1">For the single write
|
||||
waveform, data is written to the external FIFO in S0 by making CTL0
|
||||
a logic LOW (WEN is asserted) and placing data on the bus (Activate
|
||||
Data) for one IFCLK cycle (Wait 1). At 48 MHz, one IFCLK cycle is
|
||||
20.83 ns. With the IFCLK output inverted, this provides enough set-up
|
||||
and hold time for the data.</font></p>
|
||||
<p align="left"><font face="Verdana" size="1">S1 is a decision-point
|
||||
state that forces an unconditional branch to the IDLE state, which
|
||||
terminates the waveform (no activity occurs in the IDLE state).
|
||||
A decision point state allows you to pick, at most, two terms to
|
||||
evaluate a logical expression. Based on the results of that evaluation,
|
||||
you can control the next state the waveform goes to. See the FX2
|
||||
Technical Reference Manual for more information on decision point
|
||||
states. Also in S1, CTL0 is a logic HIGH (WEN is de-asserted), and
|
||||
the data bus is tri-stated (De-activate Data).</font></p>
|
||||
<p align="left"><font face="Verdana" size="1">Every time a single
|
||||
write waveform is initiated, the GPIF engine will cycle through
|
||||
S0, S1, and then IDLE (S7).<br><br>The single read waveform (waveform 0)
|
||||
is very similar to the single write waveform. The single read waveform
|
||||
is shown in <i>Figure 14</i>.<br></font></p>
|
||||
<p align="left"><font face="Verdana" size="1"> </font></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center" width="744">
|
||||
<p align="center"><font face="Verdana" size="1"><img src="images/singlerd.gif" width="432" height="327" border="0"><br>Figure
|
||||
14. Single Read waveform in GPIF Designer</font></p>
|
||||
<p align="left"><font size="1" face="Verdana">For the single read
|
||||
waveform, CTL1 starts off as a logic LOW in S0 (REN asserted) for
|
||||
one IFCLK cycle. This is to account for a t ENS set-up time for
|
||||
the external FIFO before OE (CTL2) is asserted. S1 then asserts
|
||||
OE, and in S2 the data bus is sampled (Activate Data) and an unconditional
|
||||
branch to the IDLE state is taken to terminate the waveform (no
|
||||
activity occurs in the IDLE state).</font></p>
|
||||
<p align="left"><font size="1" face="Verdana">Note that the data
|
||||
bus is sampled in S2 when it would be tempting to sample it in S1.
|
||||
At the beginning of S1, the data is not yet available from the external
|
||||
FIFO, therefore the GPIF has to “catch” the data at the beginning
|
||||
of S2. This is why the data bus is sampled in S2 instead of S1.</font></p>
|
||||
<p align="left"><font size="1" face="Verdana">Every time a single
|
||||
read waveform is initiated, the GPIF engine will cycle through S0,
|
||||
S1, S2, and then IDLE (S7). Notice that waveforms 2 and 3 are unused
|
||||
for the single transaction example, but will be used later for the
|
||||
FIFO transaction example.<br></font></p>
|
||||
<p align="left"><font size="1" face="Verdana"> </font></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="13" width="744">
|
||||
<p align="left"><font face="Verdana" size="1"><b><a name="FW"></a>Single Transaction
|
||||
Firmware</b></font></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="left" width="744">
|
||||
<p>
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">After the single transaction waveforms were implemented in the GPIF Designer, the next step was to integrate the USB portion of the
|
||||
overlying firmware with the GPIF Designer output to perform write and read operations to and from the external FIFO. To do this a firmware frameworks project
|
||||
was copied and the code that performed the external FIFO operations was added to the TD_Poll() function within FX2_extsyncfifo.c (note that periph.c was
|
||||
renamed to something more meaningful here). Endpoint and GPIF register initialization is performed in the TD_Init() function, which is also within
|
||||
FX2_extsyncfifo.c.<br><br><a name="Files"></a>When the user opens up the Keil uVision2 project for the FIFO example, the following should be the list of files shown in the Project Window: </font> </td>
|
||||
</tr>
|
||||
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="center" width="744">
|
||||
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">
|
||||
<img src="images/keil.gif" width="253" height="140" align="center" border="0" ismap usemap="#keil_map"><br>
|
||||
</font>
|
||||
<ul>
|
||||
<p align="left"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">The
|
||||
contents of these files is as follows: <br>
|
||||
</font></p>
|
||||
</ul>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="15" width="744">
|
||||
<ul>
|
||||
<p align="left"><font face="Verdana" size="1"><b>fw.c</b><br>Firmware
|
||||
frameworks which handles USB requests and calls the task dispatcher
|
||||
TD_Poll(). </font></p>
|
||||
</ul>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="15" width="744">
|
||||
<ul>
|
||||
<p align="left"><font face="Verdana" size="1"><b>Ezusb.lib</b><br>Collection
|
||||
of functions that handle suspend, resume, I2C operations, etc. </font></p>
|
||||
</ul>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="15" width="744">
|
||||
<ul>
|
||||
<p align="left"><font face="Verdana" size="1"><b>USBJmpTb.OBJ</b><br>Interrupt
|
||||
vector jump table for USB (INT2) and GPIF/Slave FIFO (INT4)
|
||||
interrupt sources. </font></p>
|
||||
</ul>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="15" width="744">
|
||||
<ul>
|
||||
<p align="left"><font face="Verdana" size="1"><b>dscr.a51</b><br>Device
|
||||
descriptor tables for the FIFO example which report EP2OUT and
|
||||
EP6IN as the available endpoints for the FX2 device. </font></p>
|
||||
</ul>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="15" width="744">
|
||||
<ul>
|
||||
<p align="left"><font face="Verdana" size="1"><b>FX2_to_extsyncFIFO.c</b><br>Main
|
||||
user application code where TD_Poll() and TD_Init() can be found.
|
||||
The user will mainly be modifying this particular file and will
|
||||
not need to touch fw.c. </font></p>
|
||||
</ul>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="15" width="744">
|
||||
<ul>
|
||||
<p align="left"><font face="Verdana" size="1"><b>gpif.c</b><br>File
|
||||
that contains the GPIF waveform descriptor tables that implement
|
||||
the Single/FIFO GPIF transaction waveform behavior.<br> </font></p>
|
||||
</ul>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="left" width="744">
|
||||
|
||||
<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" width="744">
|
||||
<ul>
|
||||
|
||||
<p>
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">The first task at hand was to setup the endpoints appropriately for this example. The following code switches the CPU clock
|
||||
speed to 48MHz (since at power-on default it is 12MHz), and sets up EP2 as an OUT endpoint, 4x buffered of size 512, and EP6 as an IN endpoint, also
|
||||
4x buffered of size 512. This setup utilizes the maximum allotted 4KB FIFO space. It also sets up the FIFOs for manual mode, word wide operation and
|
||||
goes through a FIFO reset and arming sequence to ensure that they are ready for data operations.<br>
|
||||
</font>
|
||||
</ul>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="left" width="744">
|
||||
<blockquote>
|
||||
<ul>
|
||||
<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>
|
||||
EP4CFG = <font color="#0000CC">0x00</font>; <font color="#339933">// EP4 not valid</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>
|
||||
EP8CFG = <font color="#0000CC">0x00</font>; <font color="#339933">// EP8 not valid</font><br>
|
||||
<font color="#666666">SYNCDELAY</font>;<br>
|
||||
<br>
|
||||
EP2FIFOCFG = <font color="#0000CC">0x01</font>; <font color="#339933">// manual mode, disable PKTEND zero length send, word ops</font><br>
|
||||
<font color="#666666">SYNCDELAY</font>;<br>
|
||||
EP6FIFOCFG = <font color="#0000CC">0x01</font>; <font color="#339933">// manual mode, disable PKTEND zero length send, word ops</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>
|
||||
<font color="#339933">// out endpoints do not come up armed</font><br>
|
||||
<font color="#339933">// since EP2OUT is quad buffered we must write dummy byte counts four times</font><br>
|
||||
<br>
|
||||
EP2BCL = <font color="#0000CC">0x80</font>; <font color="#339933">// arm EP2OUT by writing byte count w/skip.</font><br>
|
||||
<font color="#666666">SYNCDELAY</font>;<br>
|
||||
EP2BCL = <font color="#0000CC">0x80</font>;<br>
|
||||
<font color="#666666">SYNCDELAY</font>;<br>
|
||||
EP2BCL = <font color="#0000CC">0x80</font>;<br>
|
||||
<font color="#666666">SYNCDELAY</font>;<br>
|
||||
EP2BCL = <font color="#0000CC">0x80</font>;<br>
|
||||
<font color="#666666">SYNCDELAY</font>;<br>
|
||||
<br>
|
||||
GpifInit (); <font color="#339933">// initialize GPIF registers</font><br>
|
||||
<br></font>
|
||||
</ul>
|
||||
|
||||
</blockquote>
|
||||
</font>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="left" width="744">
|
||||
|
||||
<ul>
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><B><a name="IFCONFIG"></a>IFCONFIG Register</B><br>
|
||||
|
||||
</font>
|
||||
</ul>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="left" width="744">
|
||||
<ul>
|
||||
|
||||
<p>
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">TD_Init then calls the function GPIFInit() that resides in gpif.c. GPIFInit() is where the loading of the GPIF waveform
|
||||
descriptor table into on-chip memory takes place and other GPIF registers get setup. An important register, IFCONFIG, also gets setup here to define
|
||||
how the physical interface operates. Table 2 goes through the reasoning behind the setup of the IFCONFIG register for this example.
|
||||
Note that all these bit assignments were made, automatically
|
||||
by GPIF Designer as a consequence of the Block Diagram configuration.<br><br>
|
||||
</font>
|
||||
</ul>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="center" width="744">
|
||||
<table align="center" border="1" cellspacing="0" width="90%" bordercolordark="white" bordercolorlight="black">
|
||||
<tr>
|
||||
<td width="38" height="15">
|
||||
<p align="center"><font face="Verdana" size="1"><b>Bit
|
||||
#</b></font></p>
|
||||
</td>
|
||||
<td width="79" height="15">
|
||||
<p align="center"><font face="Verdana" size="1"><b>Bit
|
||||
Label</b></font></p>
|
||||
</td>
|
||||
<td width="547" height="15">
|
||||
<p align="center"><font face="Verdana" size="1"><b>Contents
|
||||
/ Description</b></font></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="38" height="13">
|
||||
<p align="center"><font face="Verdana" size="1">7</font></p>
|
||||
</td>
|
||||
<td width="79" height="13">
|
||||
<p align="center"><font face="Verdana" size="1">IFCLKSRC</font></p>
|
||||
</td>
|
||||
<td width="547" height="13"> <p align="left"><font face="Verdana" size="1">Set
|
||||
to 1 to run the GPIF using the internal clock source</font></p>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="38">
|
||||
<p align="center"><font face="Verdana" size="1">6</font></p>
|
||||
</td>
|
||||
<td width="79">
|
||||
<p align="center"><font face="Verdana" size="1">3048MHz</font></p>
|
||||
</td>
|
||||
<td width="547">
|
||||
<p><font face="Verdana" size="1">Set to 1 to run the
|
||||
internal clock source for the GPIF at 48MHz.</font></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="38">
|
||||
<p align="center"><font face="Verdana" size="1">5</font></p>
|
||||
</td>
|
||||
<td width="79">
|
||||
<p align="center"><font face="Verdana" size="1">IFCLKOE</font></p>
|
||||
</td>
|
||||
<td width="547">
|
||||
<p><font face="Verdana" size="1">Set to 1 to turn on
|
||||
the IFCLK output to drive the WCLK and RCLK inputs of
|
||||
the external FIFO.</font></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="38">
|
||||
<p align="center"><font face="Verdana" size="1">4</font></p>
|
||||
</td>
|
||||
<td width="79">
|
||||
<p align="center"><font face="Verdana" size="1">IFCLPOL</font></p>
|
||||
</td>
|
||||
<td width="547">
|
||||
<p><font face="Verdana" size="1">Set to 1 to invert
|
||||
the IFCLK output to the external FIFO. This allows enough
|
||||
setup time for the external FIFO.</font></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="38">
|
||||
<p align="center"><font face="Verdana" size="1">3</font></p>
|
||||
</td>
|
||||
<td width="79">
|
||||
<p align="center"><font face="Verdana" size="1">ASYNC</font></p>
|
||||
</td>
|
||||
<td width="547">
|
||||
<p><font face="Verdana" size="1">Set to 0 to operate
|
||||
the GPIF at the highest rate (sync mode).</font></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="38">
|
||||
<p align="center"><font face="Verdana" size="1">2</font></p>
|
||||
</td>
|
||||
<td width="79">
|
||||
<p align="center"><font face="Verdana" size="1">GSTATE</font></p>
|
||||
</td>
|
||||
<td width="547">
|
||||
<p><font face="Verdana" size="1">Set to 1 to turn on
|
||||
the debug outputs of the state machine. PE[2:0] displays
|
||||
the states the GPIF engine cycles through during each
|
||||
transaction (Note: PE[2:0] are only available on the
|
||||
100- and 128-pin packages).</font></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="38">
|
||||
<p align="center"><font face="Verdana" size="1">1</font></p>
|
||||
</td>
|
||||
<td width="79">
|
||||
<p align="center"><font face="Verdana" size="1">IFCFG1</font></p>
|
||||
</td>
|
||||
<td width="547">
|
||||
<p><font face="Verdana" size="1">Set to 1 to put the
|
||||
FX2 part into GPIF mode (internal master).</font></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td width="38">
|
||||
<p align="center"><font face="Verdana" size="1">0</font></p>
|
||||
</td>
|
||||
<td width="79">
|
||||
<p align="center"><font face="Verdana" size="1">IFCFG0</font></p>
|
||||
</td>
|
||||
<td width="547">
|
||||
<p><font face="Verdana" size="1">Set to 0 to put
|
||||
the FX2 part into GPIF mode (internal master).</font></p>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
<p><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">Table 2. IFCONFIG register bit settings for FIFO example<br>
|
||||
<br>
|
||||
</font></p>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="left" width="744">
|
||||
<ul>
|
||||
|
||||
<p>
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">The next thing TD_Init() does is it resets the external FIFO by pulsing PA2. This ensures that the external FIFO is at a
|
||||
ground-zero state before commencing data operations. The following code does the trick:<br>
|
||||
|
||||
</font>
|
||||
</ul>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="left" width="744">
|
||||
|
||||
<p>
|
||||
<blockquote>
|
||||
<ul>
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><font color="#339933">// reset the external FIFO</font><br>
|
||||
<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>
|
||||
<font color="#666666">EZUSB_Delay (<font color="#0000CC">1</font>)</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>
|
||||
</font>
|
||||
</ul>
|
||||
|
||||
</blockquote>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="15" width="744">
|
||||
<ul>
|
||||
|
||||
<p align="left">
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">A vendor command was also setup in the DR_VendorCmnd() function so that the user could reset the external FIFO at any time by
|
||||
performing a vendor request of 0xB2 from the EZ-USB Control Panel. </font>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="15" width="744">
|
||||
|
||||
<ul>
|
||||
<p align="left"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><B><a name="Triggering"></a>Triggering GPIF Single Transactions</B><br></font>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="left" width="744">
|
||||
<ul>
|
||||
|
||||
<p>
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">In order for the data transfers to occur across the physical interface, the CPU needs to trigger the GPIF waveforms by accessing
|
||||
the registers XGPIFSGLDATH, XGPIFSGLDATLX, and XGPIFSGLDATLNOX.<br><br> In order to trigger a GPIF Single Word Write transaction, the user writes to the XGPIFSGLDATAH< and XGPIFSGLDATLX in the following manner:<br><br>
|
||||
XGPIFSGLDATH = <font color="#999999"><</font>word_value<font color="#999999">></font> >> <font color="#0000CC">8</font>;<br>
|
||||
XGPIFSGLDATLX = <font color="#999999"><</font>word_value<font color="#999999">></font> <font color="#339933">// trigger GPIF<br><br></font>This effectively setups the MSB and LSB of the word value to be transferred, and the sheer act of writing to the XGPIFSGLDATLX register fires
|
||||
off the Single Word Write transaction. To make things a little neater to follow in TD_Poll(), the following function was defined which basically
|
||||
accepts a word value as an input argument and performs the GPIF Single Word Write transaction:<br></font>
|
||||
<ul>
|
||||
<p> <font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><font color="#339933">// reset the external FIFO</font><br>
|
||||
<font color="#990000">void</font> GPIF_SingleWordWrite( WORD gdata )<br>
|
||||
{<br>
|
||||
<font color="#990000">while</font>( !( GPIFTRIG & <font color="#0000CC">0x80</font> ) ) <font color="#339933">// poll GPIFTRIG.7 Done bit</font><br>
|
||||
{<br>
|
||||
;<br>
|
||||
}<br>
|
||||
|
||||
<font color="#339933">// using registers in XDATA space</font><br>
|
||||
XGPIFSGLDATH = gdata;<br>
|
||||
XGPIFSGLDATLX = gdata >> <font color="#0000CC">8</font>; <font color="#339933">// trigger GPIF Single Word Write transaction</font><br>
|
||||
}</font></p>
|
||||
</ul>
|
||||
<p><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">This function also checks to see if the GPIF is in the IDLE state (GPIFTRIG.7 is set if GPIF is IDLE) before it launches the transaction. This is
|
||||
something that is necessary before launching any GPIF transaction. Note that the access to the single transaction registers is swapped here because
|
||||
the endpoint buffer is organized as a FIFO. The swapping ensures that the first byte in the endpoint buffer is written out FD[7:0], and the second
|
||||
byte is written out FD[15:8].<br>
|
||||
<br>
|
||||
In order to trigger a GPIF Single Word Read transaction, the user performs a dummy read from the XGPIFSGLDATX register. The word value just read will
|
||||
be contained in the registers XGPIFSGLDATH and XGPIFSGLDATLNOX. <br><br>To make things a little neater to follow in TD_Poll(), the following function was defined which basically accepts a word pointer for the
|
||||
destination variable as an input argument and performs the GPIF Single Word Read transaction:</font></p>
|
||||
<ul>
|
||||
<p><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><font color="#990000">void</font> GPIF_SingleWordRead( WORD xdata *gdata )<br>
|
||||
{<br>
|
||||
<font color="#990000">static</font> BYTE g_data = <font color="#0000CC">0x00</font>; <font color="#339933">// dummy variable</font><br>
|
||||
<br>
|
||||
<font color="#990000">while</font>( !( GPIFTRIG & <font color="#0000CC">0x80</font> ) ) <font color="#339933">// poll GPIFTRIG.7 Done bit</font><br>
|
||||
{<br>
|
||||
;<br>
|
||||
}<br>
|
||||
<br>
|
||||
<font color="#339933">// using register in XDATA space</font><br>
|
||||
g_data = XGPIFSGLDATLX; <font color="#339933">// dummy read to trigger GPIF Single Word Read transaction</font><br>
|
||||
<br>
|
||||
<font color="#990000">while</font>( !( GPIFTRIG & <font color="#0000CC">0x80</font> ) ) <font color="#339933">// poll GPIFTRIG.7 Done bit</font><br>
|
||||
{<br>
|
||||
;<br>
|
||||
}<br>
|
||||
<br>
|
||||
<font color="#339933">// using register(s) in XDATA space, retrieve word just read from external FIFO</font><br>
|
||||
*gdata = ( ( WORD )XGPIFSGLDATLNOX << <font color="#0000CC">8</font> ) | ( WORD )XGPIFSGLDATH;<br>
|
||||
}</font></p>
|
||||
</ul>
|
||||
<p><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">This function first checks to see if the GPIF is IDLE and then performs a dummy read from XGPIFSGLDATLX to fire off the GPIF Single Word Read
|
||||
transaction. Then, another check is performed before accessing the registers that contain the word value.<br>
|
||||
<font color="#339933"> </font></font></p>
|
||||
|
||||
</ul>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="left" width="744">
|
||||
|
||||
<p>
|
||||
|
||||
<ul>
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><B><a name="TD_Poll()"></a>TD_Poll()</B><br>
|
||||
</font>
|
||||
</ul>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="15" width="744">
|
||||
<ul>
|
||||
|
||||
<p align="left">
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">The TD_Poll() function is where the main application code resides. The firmware here calls the functions GPIF_SingleWordWrite() and
|
||||
GPIF_SingleWordRead to send and receive data from EP2OUT and EP6IN, respectively.<br><br>Code that handles USB OUT transfers</font>
|
||||
<ul>
|
||||
<p align="left"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><font color="#990000">if</font>(!(EP2468STAT & bmEP2EMPTY) && (EXTFIFONOTFULL))<br>
|
||||
{<br>
|
||||
<font color="#339933">// if host sent data to EP2OUT AND external FIFO is not full</font><br>
|
||||
<br>
|
||||
Tcount = (EP2BCH << <font color="#0000CC">8</font>) + EP2BCL; <font color="#339933">// load transaction count with EP2 byte count</font><br>
|
||||
Tcount /= <font color="#0000CC">2</font>; <font color="#339933">// divide by 2 for word wide transaction</font><br>
|
||||
Source = (WORD *)(&EP2FIFOBUF);<br>
|
||||
<font color="#990000">for</font>( i = <font color="#0000CC">0x0000</font>; i < Tcount; i++ )<br>
|
||||
{<br>
|
||||
<font color="#339933">// transfer data from EP2OUT buffer to external FIFO</font><br>
|
||||
GPIF_SingleWordWrite (*Source);<br>
|
||||
Source++;<br>
|
||||
}<br>
|
||||
EP2BCL = <font color="#0000CC">0x80</font>; <font color="#339933">// re-arm EP2OUT</font><br>
|
||||
}</font></p>
|
||||
</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 host sent data to EP2OUT, and if the external FIFO is not full by accessing the
|
||||
GPIFREADYSTAT register (EXTFIFONOTEMPTY is a macro for GPIFREADYSTAT & bmBIT0).<br><br>If both conditions are met, the word variable Tcount is setup appropriately. Since each GPIF Single Word Write transaction sends an entire word to
|
||||
the external FIFO, the number of transactions is always half the number of bytes actually contained within the endpoint buffer.<br><br>A for loop then calls the GPIF_SingleWordWrite function and indexes through the endpoint buffer values, sending a word out to the external FIFO
|
||||
at a time. The last step then is to re-arm the endpoint buffer so that the next USB data packet can be accepted</font><font face="Verdana" size="1">.</font></p>
|
||||
|
||||
<p align="left">
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">Code that handles USB IN transfers </font>
|
||||
<ul>
|
||||
|
||||
|
||||
<p align="left"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><font color="#990000">if</font>(in_enable) <font color="#339933">// if IN transfers are enabled</font><br>
|
||||
{<br>
|
||||
<font color="#990000">if</font>(!(EP2468STAT & bmEP6FULL) && (EXTFIFONOTEMPTY))<br>
|
||||
{<br>
|
||||
<font color="#339933">// if EP6IN is not full AND there is data in the external FIFO</font><br>
|
||||
<br>
|
||||
Destination = (WORD *)(&EP6FIFOBUF);<br>
|
||||
<font color="#990000">for</font>( i = <font color="#0000CC">0x0000</font>; i < Tcount; i++ )<br>
|
||||
{<br>
|
||||
<font color="#339933">// transfer data from external FIFO to EP6IN buffer</font><br>
|
||||
GPIF_SingleWordRead (Destination);<br>
|
||||
Destination++;<br>
|
||||
}<br>
|
||||
Tcount *= <font color="#0000CC">2</font>; <font color="#339933">// multiply by 2 to obtain byte count value</font><br>
|
||||
EP6BCH = MSB(Tcount);<br>
|
||||
<font color="#666666">SYNCDELAY</font>;<br>
|
||||
EP6BCL = LSB(Tcount); <font color="#339933">// arm EP6IN to send data to the host</font><br>
|
||||
<font color="#666666">SYNCDELAY</font>;<br>
|
||||
}<br>
|
||||
}</font>
|
||||
</ul>
|
||||
<p align="left"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">Another vendor command (0xB3) is setup to enable the IN transfers to occur. Otherwise, the code will just sit there and not process the INs. The
|
||||
reason for the in_enable flag is so that the user can test each read and write operation independently. Otherwise, after the OUT handling code, the
|
||||
IN is processed immediately. This is also useful for debugging purposes with the logic analyzer. It allows the user to capture each read/write
|
||||
operation relatively easily.<br><br>If the in_enable flag is set, the code will fall through and check if the EP6IN endpoint buffer is not full, and if the external FIFO is not empty
|
||||
(The CPU can check the status of the RDY signals by accessing the GPIFREADYSTAT register, so EXTFIFONOTEMPTY is a macro for GPIFREADYSTAT & bmBIT1).<br><br>If both conditions are met, a for loop then calls the GPIF_SingleWordRead function and indexes through the endpoint buffer values, receiving a word from
|
||||
the external FIFO at a time. The last step then is to re-arm the endpoint buffer so that the next USB data packet can be accepted. Since each GPIF
|
||||
Single Word Read transaction receives an entire word from the external FIFO, the number of transactions is always half the number of bytes actually
|
||||
contained within the endpoint buffer.<br><br> </font></p>
|
||||
|
||||
</ul>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="15" width="744">
|
||||
|
||||
<p align="left"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><B><a name="Running"></a>Running the example for GPIF Single Transactions<br> </B></font> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="15" width="744">
|
||||
|
||||
<p align="left">
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">Now that the user understands how this FIFO example works, the bulk loop back function can be exercised by performing the steps discussed in this section.<br><br>Step 1: Download the firmware using the EZ-USB Control Panel</font>
|
||||
<ul>
|
||||
<p align="left"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">a)
|
||||
Unzip the "FX2_extsyncFIFO GPIF Single Transactions.zip" package in the C:\Cypress\Usb\Examples\FX2 directory.<br></font></p>
|
||||
<p align="left"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">b)
|
||||
After the user plugs-in the FX2 board, launch the EZ-USB Control Panel and ensure that the selected target is FX2.<br></font></p>
|
||||
<p align="left"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">c)
|
||||
Then, press the "Download" button and select the FX2_extsyncFIFO.hex file. The FX2 board renumerates as a Cypress EZ-USB Sample Device and LED0 should come up flashing.<br></font></p>
|
||||
<p align="left"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">d)
|
||||
Perform a "Get Pipes" and "Get Dev" to verify one more time that the firmware is up and running. The user should then see the following screen shown below:</font></p>
|
||||
</ul>
|
||||
|
||||
|
||||
<ul>
|
||||
<p align="left"><A onClick="na_change_img_src('image2', 'document', 'images/cp-01.gif', true);"><img src="images/cp-01.gif" width="488" height="400" align="center" border="0" name="image2"></A> </ul>
|
||||
|
||||
|
||||
<p><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><br> </font></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="15" width="744">
|
||||
|
||||
<p align="left">
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><a name="Step2"></a>Step 2: Setup bulk IN transfer and send 512 bytes to the external FIFO<br></font>
|
||||
<ul>
|
||||
<p align="left"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">a)
|
||||
On the same line as the "BulkTrans" button, select Endpoint 6 IN as the "Pipe" and specify a "Length" of 512 bytes. Then click the
|
||||
"BulkTrans" button. This will setup a bulk IN transfer of 512 bytes to read that amount from the external FIFO. Select View -> Pending Ops to
|
||||
see the pending bulk IN transfer.<br></font></p>
|
||||
<p align="left"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">b)
|
||||
On the same line as the "FileTrans.." button, select Endpoint 2 OUT as the "Pipe". Press the "FileTrans.." button and select the 512_count.hex
|
||||
file. Click on "Open" and this action will send out 512 bytes out to the external FIFO (the data stream is a ramp). <br></font></p>
|
||||
<p align="left"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">c)
|
||||
Even though 512 bytes have been written into the external FIFO the IN transfer is not processed. This is because the in_enable flag in the firmware has not yet been set to TRUE.<br></font></p>
|
||||
</ul>
|
||||
|
||||
|
||||
<ul>
|
||||
<p align="left"><A onClick="na_change_img_src('image1', 'document', 'images/cp-02.gif', true);"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><img src="images/cp-02.gif" width="441" height="400" align="center" border="0" name="image1"></font></A> </ul>
|
||||
|
||||
|
||||
<p> </p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="15" width="744">
|
||||
|
||||
<p align="left">
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><a name="Step3"></a>Step 3: Complete IN transfer to read back 512 bytes from the external FIFO<br>
|
||||
<br>
|
||||
In order to complete the pending IN transfer and read back 512 bytes from the external FIFO, the in_enable flag must be set to TRUE (remember that
|
||||
this allows the INs to be processed in the TD_Poll routine). To set the flag, on the same line as the "Vend Req" button, enter a value of 0xb3 in the
|
||||
"Req" field. Then click the "Vend Req" button. The user should now see the 512 bytes read back from the external FIFO displayed in the window.<br></font>
|
||||
<ul>
|
||||
|
||||
<p align="left"><A onClick="na_change_img_src('image3', 'document', 'images/cp-03.gif', true);"><img src="images/cp-03.gif" width="449" height="400" border="0" name="image3"></A></p>
|
||||
</ul>
|
||||
<p align="center"> </p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="15" width="744">
|
||||
|
||||
<p align="left">
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">The bulk loop back function can also be exercised by running the bulkloop.exe utility supplied with the EZ-USB development kit software. After
|
||||
downloading the firmware, launch the bulkloop.exe utility found in the C:\Cypress\Usb\Bin sub-directory. The user should setup the parameters
|
||||
according to the following screen:</font>
|
||||
<p align="left"><img src="images/bulkexe.gif" width="544" height="361" border="0"></p>
|
||||
|
||||
<p align="left">
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">Prior to clicking the "Start" button to commence the bulk loop back transfers, the user should perform the 0xb3 vendor request to set the in_enable flag
|
||||
to TRUE. By clicking the "Start" button, the user should see the "Pass" counter increment as each loop back transfer is exercised. Clicking on the "Stop"
|
||||
button will end the loop back transfers. The data values are also checked by the bulkloop utility on each pass, so the user should see the "Error" count
|
||||
increment if any data value does not match. The application will also stop on any error if the "Stop on Error" checkbox is selected.<br>
|
||||
<br>
|
||||
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#666666"><b>Debug Tip: </b><br>
|
||||
While running this example and at any time during GPIF development, the user is strongly encouraged to connect a logic analyzer to the relevant signals
|
||||
on the development kit headers. Monitoring the GPIF bus transactions aids debug sessions tremendously, and is essential for anyone seriously interested
|
||||
in writing GPIF firmware. The next topic presents the waveforms the user should see on the logic analyzer as the example is run. An HP1660C Logic
|
||||
Analyzer was used to capture the waveforms.<br></font></font>
|
||||
<p align="left"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#666666"> </font></font></p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="15" width="744">
|
||||
|
||||
<p align="left"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><B><a name="AnalyzerWaves"></a>Logic Analyzer Waveforms<br> </B></font> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="15" width="744">
|
||||
|
||||
<ul>
|
||||
<p align="left"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><B><a name="SingleWr"></a>Single Write Waveform<br></B></font>
|
||||
<ul>
|
||||
<p align="left"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><img name="law" src="images/sWrite.gif" width="432" height="290" align="center" border="0"></font> </p>
|
||||
</ul>
|
||||
|
||||
</ul>
|
||||
<ul>
|
||||
|
||||
<p align="left">
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">The waveform above shows the timing generated by the GPIF engine for the Single Write waveform as defined by the GPIF tool. All the essential signals
|
||||
are presented here, including GSTATE[2:0], which displays the states the GPIF engine cycles through as it performs the Single Write transaction.<br><br></font><font face="verdana, arial, helvetica, sans-serif" size="1" color="#666666"><b>Debug Tip: </b><br>
|
||||
<br>
|
||||
Bringing out the GSTATE signals to the logic analyzer headers allows the user to correlate between the waveforms generated by the GPIF tool, and
|
||||
the actual waveforms generated on the physical interface. This also aids the debugging process because the user can see the immediate effect of
|
||||
changing the waveform behavior in the GPIF tool</font><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">.</font><font face="verdana, arial, helvetica, sans-serif" size="1" color="#666666"><br><br></font><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">As expected from the GPIF tool output, S0 places the data on the bus (PORTB is FD[7:0] and PORTD is FD[15:8]), and asserts CTL0 (connected to the
|
||||
external FIFO's WEN/ line). This effectively writes the 16-bit data value into the external FIFO. Note here that enough data setup time to the
|
||||
rising edge of IFCLK is provided, since the minimum data setup time for the external FIFO is 4 ns (see CY4265 datasheet). S1 is a decision point
|
||||
state that unconditionally branches to the IDLE state to terminate the transaction. Without the unconditional branch, the GPIF engine would
|
||||
sequentially move through the remaining states until the IDLE state (S7) is reached. <br>
|
||||
<br>
|
||||
For every word written out in a bulk OUT transfer, the user should see the GPIF engine cycle through S0, S1, and S7. To capture the waveform, the
|
||||
user should trigger the logic analyzer on the falling edge of CTL0. A sampling rate of 4 ns will give the user the same resolution shown in the
|
||||
waveform above.<br>
|
||||
</font><font face="verdana, arial, helvetica, sans-serif" size="1" color="#666666"> </font>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="15" width="744">
|
||||
|
||||
<ul>
|
||||
<p align="left"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><B><a name="SingleRd"></a>Single Read Waveform<br><br> </B></font>
|
||||
<ul>
|
||||
<p align="left"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><img name="law" src="images/sRead.gif" width="432" height="290" align="center" border="0"><B> <br></B></font>
|
||||
</ul>
|
||||
<p align="left">
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">The waveform above shows the timing generated by the GPIF engine for the Single Read waveform as defined by the GPIF tool. All the essential signals
|
||||
are presented here, including GSTATE[2:0], which displays the states the GPIF engine cycles through as it performs the Single Read transaction<B>.</B><br><br>As expected from the GPIF tool output, S0 asserts CTL1 (connected to the external FIFO's REN/ line), S1 asserts CTL2 (connected to the external
|
||||
FIFO's OE/ line), and S2 samples the data bus (PORTB is FD[7:0] and PORTD is FD[15:8]). This effectively reads the 16-bit data value into the
|
||||
external FIFO. Note here that enough data setup time to the rising edge of IFCLK is provided, since the minimum data setup time for the external
|
||||
FIFO is 4 ns (see CY4265 datasheet). S2 is a decision point state that unconditionally branches to the IDLE state to terminate the transaction.
|
||||
Without the unconditional branch, the GPIF engine would sequentially move through the remaining states until the IDLE state (S7) is reached. <br>
|
||||
<br>
|
||||
For every word read out from the external FIFO in a bulk IN transfer, the user should see the GPIF engine cycle through S0, S1, S2, and S7. To
|
||||
capture the waveform, the user should trigger the logic analyzer on the falling edge of CTL1. A sampling rate of 4 ns will give the user the same
|
||||
resolution shown in the waveform above.<br>
|
||||
</font>
|
||||
</ul>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="15" width="744">
|
||||
<p> </p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="15" width="744">
|
||||
<p> </p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="15" width="744">
|
||||
<p> </p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="15" width="744">
|
||||
<p> </p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="15" width="744">
|
||||
<p> </p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center" height="15" width="744">
|
||||
<p> </p>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
</font>
|
||||
</body>
|
||||
</html>
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 29 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 17 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 34 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 127 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 64 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 133 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 27 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 16 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 30 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 13 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 12 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 2.0 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.4 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.7 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 8.8 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 7.0 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.0 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.8 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 8.6 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 9.6 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 17 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 67 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 30 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 30 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.6 KiB |
@@ -0,0 +1,314 @@
|
||||
<!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 changeGPIF(html)
|
||||
{
|
||||
descriptionGPIF.innerHTML=html
|
||||
}
|
||||
//-->
|
||||
</script>
|
||||
</head>
|
||||
<body bgcolor="#FFFFFF">
|
||||
|
||||
|
||||
<table border="0" cellpadding="0" cellspacing="0" width="98%" align="center">
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="left">
|
||||
<p align="center"><font face="Verdana,Arial" size="2" color="#000000"><B><a name="Overview"></a>16-bit Interface to External Synchronous Cypress FIFO CY7C4625-15AC</B><br></font><font size="2" face="Verdana">
|
||||
<br></font>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="left">
|
||||
<font face="Verdana,Arial" size="2" color="#000000"><B>Overview</B> </font>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="left">
|
||||
|
||||
<p>
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">The end objective of this example is to be able to perform a bulk loop back function with the external FIFO. The FX2 will write data
|
||||
out FD[15:0] to the external FIFO and read data back from FD[15:0] (the outputs from the external FIFO Q[15:0] are also connected to FD[15:0]). The bulk
|
||||
transfers can be exercised by using the EZ-USB Control Panel or bulkloop.exe utility supplied with the EZ-USB development kit software.<br>
|
||||
<br>
|
||||
</font>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="left">
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="2" color="#000000"><B><a name="Physical"></a>Hardware
|
||||
Connections</B></font>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="left">
|
||||
|
||||
<p>
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">This section discusses the definition of the GPIF interconnect which is shown below in Figure 4-1.<br>
|
||||
</font>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="center">
|
||||
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><br>
|
||||
<img src="images/fifo-ic.gif" align="center" width="525" height="240" border="0" ismap usemap="#ic_map"><br>
|
||||
Figure 4-1. GPIF Interconnect Diagram<br>
|
||||
<br>
|
||||
</font>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="left">
|
||||
<ul>
|
||||
<p><font face="Verdana" size="1"><b>IFCLK ----> WCLK, RCLK</b>
|
||||
<br>IFCLK is connected to the write and read clock inputs (WCLK,
|
||||
RCLK) of the external FIFO. Data is clocked into the external FIFO
|
||||
on every rising edge of WCLK while WEN/ is asserted. Likewise, new
|
||||
data is presented on Q[15:0] on every rising edge of RCLK while
|
||||
REN/ and OE/ are asserted. The external FIFO can accept an input
|
||||
clock frequency of up to 66.7Mhz so it can handle the incoming IFCLK
|
||||
frequency (either 30MHz or 48MHz).</font><font face="Verdana,Arial" size="1" color="#000000"> <br> </font><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">
|
||||
</font></p>
|
||||
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="1" align="left">
|
||||
<ul>
|
||||
<p><font face="Verdana" size="1"><b>FD[15:0] <----> D[15:0]
|
||||
Q[15:0]</b><br>The GPIF data bus (FD[15:0]) is connected to the
|
||||
external FIFO&rsquo;s input data bus (D[15:0]) to allow for
|
||||
word wide operations. The output data bus of the external FIFO (Q[15:0])
|
||||
is also connected to the GPIF data bus to allow the FX2 to read
|
||||
back the data contents. In order to ensure that bus contention will
|
||||
never occur, the OE/ signal must be manipulated appropriately.<br> </font></p>
|
||||
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="left">
|
||||
<ul>
|
||||
<p><font face="Verdana" size="1"><b>CTL0 ----> WEN</b><br>CTL0
|
||||
is connected to the write enable line (WEN/) of the external FIFO.
|
||||
While WEN/ is held low, data is written into the external FIFO on
|
||||
every rising edge of WCLK.<br> </font></p>
|
||||
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="left">
|
||||
<ul>
|
||||
<p><font face="Verdana" size="1"><b>CTL1 ----> REN</b><br>CTL1
|
||||
is connected to the read enable line (REN/) of the external FIFO.
|
||||
While REN/ and OE/ are held low, new data is presented on Q[15:0]
|
||||
on every rising edge of RCLK.<br> </font></p>
|
||||
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="left">
|
||||
<ul>
|
||||
<p><font face="Verdana" size="1"><b>CTL2 ----> OE</b><br>CTL2
|
||||
is connected to the output enable line (OE/) of the external FIFO.
|
||||
While REN/ and OE/ are held low, new data is presented on Q[15:0]
|
||||
on every rising edge of RCLK.<br> </font></p>
|
||||
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="left">
|
||||
<ul>
|
||||
<p><font face="Verdana" size="1"><b>RDY0 <---- EF</b><br>RDY0
|
||||
is connected to the empty flag (EF/) of the external FIFO. EF/ is
|
||||
asserted low if the external FIFO is empty. The GPIF can use this
|
||||
to regulate data transfers when reading from the external FIFO.<br> </font></p>
|
||||
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="left">
|
||||
<ul>
|
||||
<p><font face="Verdana" size="1"><b>RDY1 <---- FF</b><br>RDY1
|
||||
is connected to the full flag (FF/) of the external FIFO. FF/ is
|
||||
asserted low if the external FIFO is full. The GPIF can use this
|
||||
to regulate data transfers when writing to the external FIFO.<br> </font></p>
|
||||
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="left">
|
||||
<ul>
|
||||
<p><font face="Verdana" size="1"><b>PA2 ----> RS</b><br>PA2 is
|
||||
connected to the reset signal of the external FIFO. PA2 is not part
|
||||
of the GPIF interconnect but is still part of the overall system
|
||||
design. PA2 is used as an I/O pin to reset the external FIFO to
|
||||
a known state before GPIF data transfers commence.<br><br></font></p>
|
||||
|
||||
<p align="left"><font face="Verdana" size="1">The GPIF Designer
|
||||
block diagram for the single transaction portion of the FIFO design example is shown below.</font></p>
|
||||
<p align="center"> <img src="images/SingleBlkDiag.gif" width="432" height="327" border="0"></p>
|
||||
</ul>
|
||||
|
||||
|
||||
<p align="center"> </p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="left">
|
||||
<p><font face="Verdana" size="1">The assignment of CTLx and RDYn
|
||||
lines is optimized for the FX2 56-pin package. The CTLx lines are
|
||||
used as input strobes into the external FIFO, and the status outputs
|
||||
from the external FIFO (EF and FF) are used to monitor under run
|
||||
and over run conditions. The basic rule of thumb is: one should
|
||||
never read from an empty FIFO or write to a full FIFO.<br></font><font face="Verdana,Arial" size="1" color="#000000"><br>T</font><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">he external FIFO was mounted onto an FX2 development board by using the prototype board supplied with the development
|
||||
kit. The external FIFO was placed on a 64-pin TQFP package surface mount adapter (available from Twin Industries at
|
||||
<A href="http://www.twinhunter.com" target="resource window">www.twinhunter.com</A>) and piggybacked on top of the prototype board. Figure 9 shows a snapshot of the actual hardware setup.
|
||||
For full hardware specifications on the external FIFO, its datasheet can be downloaded from the Cypress website. For a pin-out
|
||||
list for the prototype board connection to the FX2 development board and a full schematic for the external FIFO prototype board,
|
||||
see the software contents available with this primer.<br>
|
||||
</font></p>
|
||||
<p align="center">
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><br><img src="images/setup.jpg" align="center" width="298" height="200" border="0"><br>Figure 9. Shot of Actual Hardware Setup<br><br> </font></p>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="left">
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="2" color="#000000"><B><a name="DataFlow"></a>Application-specific Data Flow</B><br>
|
||||
|
||||
</font>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="left">
|
||||
|
||||
<p>
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">Now that the GPIF interconnect has been presented, it's important to understand the overall data flow for this design example.
|
||||
Endpoint 2 OUT (EP2OUT) is used as the source endpoint for GPIF writes to the external FIFO, and Endpoint 6 IN (EP6IN) is used as the sink endpoint for
|
||||
GPIF reads from the external FIFO. Remember that the IN and OUT directions are USB host-centric, therefore EP2OUT contains the data packets sent by the
|
||||
USB host (in this case the PC) and EP6IN contains the data packets sent to the USB host. Figures 4-2 and 4-3 show the data flow models for this
|
||||
particular example.<br>
|
||||
<br>
|
||||
</font>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="center">
|
||||
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><br>
|
||||
<img src="images/flow-out.gif" width="300" height="110" align="center" border="0"><br>
|
||||
Figure 4-2. Data Flow Model in the <B>OUT</B> direction
|
||||
<br>
|
||||
<br>
|
||||
<img src="images/flow-in.gif" width="300" height="110" align="center" border="0"><br>
|
||||
Figure 4-3. Data Flow Model in the <B>IN</B> direction
|
||||
</font>
|
||||
<p> </p>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr valign="top">
|
||||
<td colspan="1" align="left">
|
||||
<ul>
|
||||
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><B>Manual mode versus Auto mode</B><br></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">FX2 endpoints can basically operate in two modes, Manual (AUTOIN/AUTOOUT=0) or Auto (AUTOIN/AUTOOUT=1). In short, manual mode
|
||||
makes the CPU responsible for committing the USB packet to the peripheral domain and vice versa. In order to maximize the USB 2.0 bandwidth, auto mode
|
||||
should be used. This allows USB packets to be committed automatically to the peripheral domain and vice versa by removing the CPU from the data path.
|
||||
This example demonstrates the use of auto mode.<br><br> </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>Two examples in one</B><br></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 FIFO example is really two examples in one because two versions of the firmware are discussed. Sections 4.1.4-4.1.6 present
|
||||
a version that uses GPIF single transactions to read and write to the external FIFO, which then sets the stage for Sections 4.1.7-4.1.9. Sections
|
||||
4.1.7-4.1.9 discuss a version that uses GPIF FIFO transactions and the endpoints in auto mode, thus maximizing the USB 2.0 bandwidth. This two-phased
|
||||
approach is in line with the methodology presented in section 3.3, and by understanding the two approaches, the user should be able to discern what it
|
||||
takes to move from a simple working example to an example that utilizes the full USB 2.0 bandwidth capabilities of the FX2.<br><br> </font>
|
||||
</ul>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center">
|
||||
<p align="left"><font face="Verdana" size="1"> </font></p>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center">
|
||||
<ul>
|
||||
<p align="center"><font face="Verdana" size="1"> </font></p>
|
||||
</ul>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center">
|
||||
<p align="left"><font face="Verdana" size="1"> </font></p>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center">
|
||||
<p align="left"><font face="Verdana" size="1"> </font></p>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan="1" align="center">
|
||||
<p align="left"><font face="Verdana" size="1"> </font></p>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
</body>
|
||||
@@ -0,0 +1,41 @@
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<title>Contents</title>
|
||||
<base target="detail"></head>
|
||||
|
||||
<body bgcolor="#CCCCCC" text="black" link="blue" vlink="purple" alink="red">
|
||||
<p align="left"><font face="Verdana" size="1"><b><a href="intro.htm#Overview">Overview</a><br>
|
||||
</b><a href="intro.htm#Physical">Hardware Connections</a><br> <a href="intro.htm#DataFlow">App-specific
|
||||
Data Flow</a><br><br> <b><a href="SingleXactions.htm#SingleXactions">Single
|
||||
Transactions<br></a> </b> <a href="SingleXactions.htm#WaveformDescriptors">Waveform Descriptors<br></a> <a href="SingleXactions.htm#FW">Firmware</a><br>
|
||||
<a href="SingleXactions.htm#Files">FW
|
||||
Files<br></a> <a href="SingleXactions.htm#TD_Init(">TD_Init()
|
||||
function</a><br> <a href="SingleXactions.htm#IFCONFIG">IFCONFIG
|
||||
Register</a><br> <a href="SingleXactions.htm#Triggering">Trigger
|
||||
Transaction</a><br> <a href="SingleXactions.htm#TD_Poll()">TD_Poll()
|
||||
function</a><br> <a href="SingleXactions.htm#Running">Running the example</a><b><br>
|
||||
</b> <a href="SingleXactions.htm#Running">Step
|
||||
1: Download FW</a><br> <a href="SingleXactions.htm#Step2">Step
|
||||
2: Initiate Bulk IN</a><br> <a href="SingleXactions.htm#Step3">Step
|
||||
3: Finish Bulk IN</a><br> <a href="SingleXactions.htm#AnalyzerWaves">Logic
|
||||
Analyzer Traces</a><br><br><b><a href="FifoXactions.htm#SingleXactions">FIFO
|
||||
(multi) Transactions<br></a> </b> <a href="FifoXactions.htm#FlowStates">Flow
|
||||
States</a><br> <b> </b><a href="FifoXactions.htm#WaveformDescriptors">Waveform
|
||||
Descriptors<br></a> <a href="FifoXactions.htm#FW">Firmware<br></a> <a href="FifoXactions.htm#Triggering">Trigger
|
||||
Transaction</a><br> <a href="FifoXactions.htm#TD_Init(">TD_Init()
|
||||
function</a><br> <a href="FifoXactions.htm#TD_Poll()">TD_Poll()
|
||||
function</a><br> <a href="FifoXactions.htm#Running">Running the
|
||||
example</a> <br> <a href="FifoXactions.htm#Traces">Logic
|
||||
Analyzer Traces</a><br> <a href="FifoXactions.htm#WriteTrace1">FIFO
|
||||
WR: Front Porch</a><br> <a href="FifoXactions.htm#WriteTrace2">FIFO
|
||||
WR: Back Porch</a><br> <a href="FifoXactions.htm#WriteTrace3">FIFO
|
||||
WR: 512 Xfer time<br></a> <a href="FifoXactions.htm#WriteTrace4">FIFO
|
||||
WR: Pkt Xfer time</a> <a href="FifoXactions.htm#ReadTrace1">FIFO
|
||||
RD: Front Porch</a><br> <a href="FifoXactions.htm#ReadTrace2">FIFO
|
||||
RD: Back Porch</a><br> <a href="FifoXactions.htm#ReadTrace3">FIFO
|
||||
RD: 512 Xfer time</a><br> <a href="FifoXactions.htm#ReadTrace4">FIFO
|
||||
RD: Pkt Xfer time</a><br> <a href="FifoXactions.htm#BulkTrace">Bulk
|
||||
Loopback</a></font></p>
|
||||
</body>
|
||||
|
||||
Reference in New Issue
Block a user