145 lines
6.7 KiB
HTML
145 lines
6.7 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
|
|
"http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
|
|
<html lang="en">
|
|
<head>
|
|
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
|
|
<title>GPIF</title>
|
|
<meta name="generator" content="BBEdit 6.0">
|
|
</head>
|
|
<body bgcolor="#FFFFFF">
|
|
|
|
|
|
<table border="0" cellpadding="0" cellspacing="0" width="90%" align="center">
|
|
<tr valign="top">
|
|
<td align="left" height="36">
|
|
<p align="center"><font face="verdana, arial, helvetica, sans-serif" size="2" color="#000000"><B>FX2
|
|
</B></font><font face="Verdana,Arial" size="2" color="black"><B>Introduction/Overview</B></font><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><b><br> </b></font>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="left">
|
|
<p align="left"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">EZ-USB FX2 offers a highly flexible and configurable Full Speed and High Speed USB peripheral function that's designed
|
|
to achieve the maximum USB 2.0 High Speed bandwidth. FX2 accomplishes this through its auto-transfer and peripheral interface architecture.
|
|
The GPIF (General Programmable InterFace) engine is one of the vehicles for the auto-transfer architecture, and is used to gluelessly move data
|
|
between FX2, your external slave device, and the USB host. The following sections briefly touch upon the silicon architecture and implementation
|
|
of FX2, and will lay the groundwork for understanding GPIF concepts discussed later on.<br></font>
|
|
<p align="left"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"> </font></p>
|
|
|
|
|
|
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="left">
|
|
<font face="verdana, arial, helvetica, sans-serif" size="2" color="#000000"><B>Why an Auto-Transfer Architecture?<br></B> </font>
|
|
|
|
|
|
</td>
|
|
</tr>
|
|
<tr valign="top">
|
|
<td colspan="1" align="left">
|
|
|
|
<p>
|
|
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">In order to achieve the maximum USB 2.0 High Speed bandwidth, it was proven that the CPU (in this case an enhanced 8051 core)
|
|
should never be directly involved in moving the payload data from the external slave device to the USB host (and vice versa). The CPU would clearly be
|
|
the largest bottleneck in a High Speed design. So instead an Auto-Transfer mode was invented, whereby the payload data is "auto-committed" from the USB
|
|
host to the external slave device and likewise in the other direction. The GPIF engine uses this Auto-Transfer mode to move data to and from the external
|
|
slave device. Figures 1 and 2 show a system level view of the data flow for both the IN and OUT directions.<br><br> </font>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td colspan="1" align="center">
|
|
|
|
<p align="center"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><img src="images/dataout1.gif" width="524" height="130" align="center" border="0"><br>
|
|
Figure 1. System Level View of Data Flow in the <b>OUT</b> Direction<br>
|
|
<br>
|
|
<br>
|
|
</font>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td colspan="1" align="center">
|
|
|
|
<p align="center"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><img src="images/datain1.gif" width="524" height="130" align="center" border="0"><br>
|
|
Figure 2. System Level View of Data Flow in the <b>IN</b> Direction</font>
|
|
<p> </p>
|
|
<p><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"> </font></p>
|
|
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="left">
|
|
|
|
<font face="verdana, arial, helvetica, sans-serif" size="2" color="#000000"><B>Silicon features that facilitate the Auto-Transfer Architecture<br></B> </font>
|
|
|
|
|
|
</td>
|
|
</tr>
|
|
<tr valign="top">
|
|
<td colspan="1" align="left">
|
|
<ul>
|
|
|
|
<p>
|
|
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><b>Endpoint FIFOs</b><br>
|
|
<br>In FX2 the USB endpoints share the same physical memory as the FIFO buffers. This is the very backbone of what allows
|
|
the Auto-Transfer mechanism to work. Anytime the USB host sends a packet of data the packet is stuffed into an available Endpoint FIFO buffer
|
|
(the multiple buffering schemes available allows FX2 to accept up to 4 packets before NAKing the host). The data packet is then ready to be
|
|
distributed to the external device. Conversely, a data packet read from the external device can be automatically made available to the USB host.
|
|
FX2 can be configured to allow the CPU to manually "commit" the data packets (called Manual Mode) or allow the data packets to be committed
|
|
automatically (called Auto Mode) to either the USB or peripheral domain. Figures 3 and 4 show the maximum buffering scheme (4x) in relation to
|
|
the overall data path the data packets follow.<br> </font>
|
|
</ul>
|
|
|
|
</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td colspan="1" align="center">
|
|
|
|
<p align="center"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><br>
|
|
<img src="images/atout.gif" width="550" height="130" align="center" border="0"><br>
|
|
Figure 3. Auto-Transfer Dataflow in the <b>OUT</b> direction<br>
|
|
</font> <p><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><br><br> </font></p>
|
|
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="left">
|
|
|
|
<p align="center"><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><img src="images/atin.gif" width="550" height="130" align="center" border="0"><br>
|
|
Figure 4. Auto-Transfer Dataflow in the <b>IN</b> direction<br></font> <p align="center"> </p>
|
|
|
|
|
|
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="left">
|
|
<ul>
|
|
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><b>The CPU is the Traffic Cop<br><br></b>The CPU in FX2 has a minor role in the Auto-Transfer architecture as it does not participate in moving the payload data,
|
|
but it does play a very important role nonetheless. The CPU configures and defines how the physical interface operates, sets up the endpoint
|
|
configurations, triggers GPIF transfers, and can be allowed to manually commit the data packets to either the USB or peripheral domain. It
|
|
can also monitor the status of the external world, thus giving it the capability of regulating GPIF transfers.<br> </font>
|
|
</ul>
|
|
|
|
|
|
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="left">
|
|
<p> </p>
|
|
|
|
|
|
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
</font>
|
|
</body>
|
|
</html>
|