433 lines
23 KiB
HTML
433 lines
23 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
|
|
"http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
|
|
<html lang="en">
|
|
<head>
|
|
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
|
|
<title>GPIF</title>
|
|
<meta name="generator" content="BBEdit 6.0">
|
|
<script language="Javascript">
|
|
<!--
|
|
function changeFX2(html)
|
|
{
|
|
descriptionFX2.innerHTML=html
|
|
}
|
|
function changeGPIF(html)
|
|
{
|
|
descriptionGPIF.innerHTML='<font face="Verdana" size="1">'+html+'</font>'
|
|
}
|
|
//-->
|
|
</script>
|
|
</head>
|
|
<body bgcolor="#FFFFFF">
|
|
|
|
|
|
<table border="0" cellpadding="0" cellspacing="0" width="90%" align="center">
|
|
<tr valign="top">
|
|
<td align="center">
|
|
<font face="Verdana" size="2"><b><a name="Overview"></a>GPIF Overview</b></font><font face="Verdana" size="1"><b><br> </b></font>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td align="left">
|
|
|
|
<p>
|
|
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">This section introduces the GPIF feature from a hardware standpoint and discusses how to design with GPIF from the ground up.
|
|
As the name suggests, the physical connection or interface to the external peripheral is highly configurable. This allows FX2 to become the solution
|
|
for 99.9 percent of the parallel interfaces that exist. With the ability to run the physical interface at a maximum rate of 48MHz in 16-bit mode, the
|
|
bottleneck in a USB 2.0 system should never be the actual GPIF interconnect itself. One of the objectives of this primer is to guide users down a path
|
|
to get the most out of their GPIF designs in terms of performance over the physical interface. Thus, the general thought process for implementing
|
|
successful GPIF designs is also discussed, allowing the user to understand and use a design flow methodology for current and future GPIF
|
|
implementations. Debugging strategies are provided in Appendix A to guide the user on what the best approaches are for tackling GPIF design problems.<br>
|
|
<br>The GPIF (General Programmable InterFace) is a key feature of FX2 used to master an external peripheral without any external
|
|
glue logic. The GPIF is basically a controllable state machine that allows the user to generate waveforms required by external peripheral read/write
|
|
cycle timing. The CPU's role is minimal; as it basically only has to load the micro code that defines the waveform behaviors into designated FX2 on-chip
|
|
RAM space, and manages how they are executed in the application firmware.<br>
|
|
</font>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="left">
|
|
<p> </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="Physical"></a>Physical Interconnect</B><br></font> </td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td colspan="1" align="left">
|
|
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><br>
|
|
The GPIF has an interconnect which features a configurable 8- or 16-bit data bus, control outputs, and ready inputs.
|
|
Figure 5 shows what signals are available to users when they are trying to figure out how to "connect the dots" to their external peripheral.<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"><br> <img src="images/connect.gif" align="center" width="460" height="220" border="0" ismap usemap="#ic_map"><br>
|
|
Figure 5. GPIF Interconnect Diagram</font> </td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td colspan="1" align="left" height="18">
|
|
|
|
<p><font face="Verdana" size="1"><b>IFCLK (bi-directional)</b><br>IFCLK
|
|
can be either an input or output signal and is determined by what
|
|
the system requirements are. As an output signal, IFCLK can be driven
|
|
by the FX2 at either 30 MHz or 48 MHz. As an input signal, its range
|
|
is from 5-48MHz. If an external IFCLK is used in the design, it
|
|
becomes the reference clock for all GPIF operations. Note that the
|
|
GPIF can also run on an internal 30 or 48 MHz clock.<br> </font></p>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="1" align="left" height="18">
|
|
|
|
<p><font size="1" face="Verdana"><b>GPIFADR[8:0] (output only)</b><br>GPIF
|
|
can use GPIFADR[8:0] to provide address lines for peripherals that
|
|
need them. These are output only signals and the value presented
|
|
on this bus can be auto-incremented.<br> </font></p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="1" align="left" height="18">
|
|
|
|
<p><font size="1" face="Verdana"><b>FD[15:0] (bi-directional)</b><br>This
|
|
is the data bus used by GPIF operations and is the conduit for payload
|
|
data transferred between FX2 and the external peripheral. It can
|
|
be configured to operate as an 8- or 16-bit interface and can be
|
|
tri-stated if the system requires it. FD[7:0] represents the least
|
|
significant byte (LSB) and FD[15:8] represents the most significant
|
|
byte (MSB).<br> </font></p>
|
|
</td>
|
|
</tr>
|
|
<tr valign="top">
|
|
<td colspan="1" align="left" height="18">
|
|
|
|
<p><font size="1" face="Verdana"><b>CTL[5:0] (output only)</b><br>These
|
|
are control output signals that can be used to provide signals required
|
|
by the external peripheral such as read/write strobes, enables,
|
|
etc.<br> </font></p>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="1" align="left">
|
|
|
|
<p><font size="1" face="Verdana"><b>RDY[5:0] (input only)</b><br>These
|
|
are ready input signals that can be used to monitor status outputs
|
|
from the external peripheral such as FIFO status flags, data available,
|
|
etc. GPIF has the ability to use these signals as decision point
|
|
qualifiers for wait-state generation.<br> </font></p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="1" align="left">
|
|
|
|
<p><font face="Verdana" size="1"><b>GSTATE[2:0] (output only)</b><br>These
|
|
are debug output signals that represent the states executed in a
|
|
GPIF waveform. These are typically connected to a debug port such
|
|
as a logic analyzer.<br></font></p>
|
|
<p><font face="Verdana" size="1"> </font></p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="1" align="left">
|
|
|
|
<font face="verdana, arial, helvetica, sans-serif" size="2" color="#000000"><B><a name="ADFM"></a>Application Design Flow Methodology (ADFM)</B></font> </td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="1" align="left">
|
|
|
|
<p>
|
|
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">The following section presents a design flow methodology for GPIF developers wishing to maximize their "first time success"
|
|
experience. Although following this methodology may not completely guarantee a 100 per cent success rate, it will definitely give developers the
|
|
right tools for embarking on a systematic GPIF design approach, which more often than not translates into eventual success. The design examples
|
|
that are discussed later on in this primer will often refer back to these design principles.<br>
|
|
</font><font face="Verdana" size="1"><br> </font> </td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="1" align="left">
|
|
|
|
<ul>
|
|
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><b><a name="Interconnect"></a>Design GPIF Interconnect</b><br></font>
|
|
</ul>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="1" align="left">
|
|
|
|
<ul>
|
|
|
|
<p>
|
|
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">Using section 3.2, you should have a pretty good basis for determining how FX2 is going to be connected up to your peripheral
|
|
device using GPIF. This is also a good time to start collecting the FX2 datasheet and Technical Reference Manual, as well as the peripheral's datasheet
|
|
as a minimum. You can then start by asking yourself the following questions:<br></font>
|
|
</ul>
|
|
|
|
<blockquote>
|
|
<ul>
|
|
<li><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">Is the data path going to be 8- or 16-bit?</font>
|
|
<ul>
|
|
<li><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">This decision is often dictated by what size data path the peripheral offers. If it has a 16-bit data path, use it to maximize the bandwidth over the physical interface.</font>
|
|
<li><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">Endianness and bit nomenclature may also come into play here so watch how those lines are wired.</font>
|
|
</ul>
|
|
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><br></font>
|
|
<li><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">Will an external IFCLK be used or an internal 30 or 48 MHz clock source?</font>
|
|
<ul>
|
|
<li><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">This decision is often made based on how flexible the peripheral is in terms of its own operating modes. For example, if it can accept a 30 or 48
|
|
MHz clock input then there's a good chance the internal 30 or 48 MHz clock source can be used to serve as the clock input for the slave device.</font><font face="Verdana" size="1"><br> </font><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">Does the peripheral require any address lines during its read/write cycles?</font>
|
|
</ul>
|
|
|
|
|
|
|
|
<ul>
|
|
<li><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">If the peripheral requires any lines to be addressed during a read/write cycle operation, then GPIFADR[8:0] can be used.</font>
|
|
</ul>
|
|
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><br></font>
|
|
|
|
<li><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">How many control lines does the peripheral need?</font>
|
|
<ul>
|
|
<li><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">Designate GPIF control outputs from your choice of CTL[5:0]. The peripheral may require read/write signals, chip selects, among other control
|
|
inputs during a read/write cycle. Determine what they are and allocate CTL[5:0] appropriately.</font>
|
|
</ul>
|
|
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><br></font>
|
|
|
|
<li><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">How many inputs does the GPIF need to monitor from the peripheral?</font>
|
|
<ul>
|
|
<li><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">Determining how many status signals need to be monitored during a read/write cycle usually makes this decision. Determine what they are and allocate RDY[5:0] appropriately.<br> </font>
|
|
</ul>
|
|
</ul>
|
|
</blockquote>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="1" align="left">
|
|
|
|
<ul>
|
|
<ul>
|
|
<p><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">Note: Not all FX2 package types have the complete set of GPIF signals available so the designer has to be mindful of this when determining the GPIF
|
|
interconnect. The designer also needs to consider what other signals may be used (such as port I/O) to interface the FX2 to the peripheral (e.g. reset
|
|
signals, other address lines, etc.). For instance, the 56-pin package type does not bring out GPIFADR[8:0]. Therefore, if the peripheral needs some sort
|
|
of address scheme before a GPIF read/write cycle is initiated, port I/O pins must be used instead (See TI-DSP example for more details).<br>
|
|
<br> </font></p>
|
|
</ul>
|
|
</ul>
|
|
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="1" align="left">
|
|
|
|
<ul>
|
|
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><b><a name="FW"></a>Use Firmware Frameworks</b></font><font face="Verdana" size="1"> </font>
|
|
</ul>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="1" align="left">
|
|
|
|
<ul>
|
|
<p><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">Before embarking on any firmware project, let alone a GPIF one, it is recommended to start with a firmware frameworks based Keil
|
|
uVision2 project. Not only will this ensure that the integration and test phase will be smoother, it will also help USB applications support know that
|
|
you're starting from a well-known and well-tested firmware base. Any of our firmware examples will be frameworks based so you can start with one of
|
|
those, or start by copying the contents of C:\Cypress\Usb\Target\Fw\FX2 to a new sub-directory. This will allow you to start with a "clean" firmware
|
|
base. Starting with a firmware frameworks project also allows you to concentrate on the user application code as the USB protocol servicing has been
|
|
handled already (see the file called fw.c and the development kit documentation for more details).<br>
|
|
</font></p>
|
|
</ul>
|
|
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="1" align="left">
|
|
|
|
<ul>
|
|
|
|
<p>
|
|
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">There are basically two major portions to a complete GPIF applications solution:</font>
|
|
<p><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">a)
|
|
The higher-level firmware that configures the GPIF and launches the transfers (including the rest of the user application code).
|
|
<br><br>b) The GPIF waveform descriptors that implement the physical bus timing.<br><br>Part a) normally consists of five main files (fw.c, periph.c (user can rename this file), dscr.a51, ezusb.lib, usbjmptb.obj) which makes up the Keil
|
|
uVision 2 firmware frameworks project. <br><br>Part b) is typically a self-contained source file that contains the GPIF waveform descriptors and is added to the
|
|
Keil project. The GPIF Designer a user mode application supplied with the development kit software, exports
|
|
this "C" language source file.<br>
|
|
</font><font face="Verdana" size="1"> </font></p>
|
|
</ul>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="1" align="left" height="11">
|
|
|
|
<ul>
|
|
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><b><a name="Wvform Descriptors"></a>Implement GPIF Waveforms Descriptors using GPIF Designer</b><br></font>
|
|
</ul>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="1" align="left">
|
|
|
|
<ul>
|
|
<p><font face="Verdana" size="1"><br></font><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">As mentioned above, GPIF Designer generates the GPIF waveform descriptors that implement the physical bus timing. GPIF Designer
|
|
can implement any of four waveform types: Single Write, Single Read, FIFO Write, and FIFO Read. Each descriptor is 32 bytes long and resides in a
|
|
special GPIF waveform descriptor area in on-chip memory space, once loaded by the CPU.<br><br>It is ultimately the developer's responsibility to create these GPIF waveform descriptors that will, in turn, trigger single or FIFO read/write transactions
|
|
to the peripheral. The developer has seven states or intervals (S0-S6) to work with before having to terminate the transaction naturally by branching to a
|
|
"special" IDLE state (S7) (Figure 6 shows an example of a simple waveform broken down into the GPIF state transitions). Once the GPIF waveforms are ready
|
|
to be exercised by the CPU, the reading or writing of specific GPIF "trigger" registers determine at any one time which of the four waveform types get
|
|
executed by the GPIF engine.<br>
|
|
|
|
</font></p>
|
|
</ul>
|
|
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="1" align="left">
|
|
|
|
<ul>
|
|
<p><br> <font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><img src="images/waveform.gif" align="center" width="480" height="175" border="0"><br>
|
|
Figure 6. Illustrating a simple waveform broken down into GPIF states<br>
|
|
</font></p>
|
|
</ul>
|
|
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="1" align="left">
|
|
|
|
<ul>
|
|
<p><font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">The usage details of the GPIF Designer
|
|
tool will become clear in the discussion of the two design examples. It is important to note at
|
|
this point that the first set of waveforms the user should implement is the single read/write transaction waveforms. This will allow the user to flesh-out the physical interconnect and get data moving back and forth between the USB host, FX2, the peripheral, and back. It's always wise to start by
|
|
implementing single read/write waveforms before leaping into the more conceptually difficult FIFO read/write transactions, because getting comfortable
|
|
with GPIF and that first confidence booster is essential to a successful design. It may sound like starting with single transactions is a waste of time,
|
|
but taking the time to absorb the learning curve up front will pay large dividends in the end.<br> </font></p>
|
|
</ul>
|
|
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="1" align="left">
|
|
|
|
<ul>
|
|
<p>
|
|
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000"><b><a name="SingleRd/Wr"></a>Implement Single Read/Write transactions</b></font>
|
|
</ul>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="1" align="left">
|
|
|
|
<ul>
|
|
|
|
<p>
|
|
<font face="verdana, arial, helvetica, sans-serif" size="1" color="#000000">The main goal of implementing single read/write transactions is to be able to confirm that the physical interconnect is sound
|
|
between GPIF and the peripheral, and that basic data movement can be achieved in the final system. It is possible to get an entire design working even
|
|
if only single transactions are utilized. Another advantage of performing this stage first in the GPIF development cycle is that all areas of the system
|
|
(hardware, firmware, software) can be verified within a relatively short period of time (compared to jumping into FIFO transactions first). Especially
|
|
for first time users learning about the GPIF, this is a heavily recommended development stage to go through.
|
|
<br><br>Even though single transactions are the easiest of GPIF waveforms to implement, it may take several iterations of integration
|
|
and test of the GAS project before the user is happy with the initial design, since this stage can be also considered as the "fleshing out" stage. There
|
|
may be hardware-timing issues that pop up, hardware connection issues, firmware code flow issues, driver issues, etc., but this is the right time to
|
|
become aware of these types of issues in order not to get burned too much later on if a problem arises.<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><a name="FIFORd/Wr"></a>Implement FIFO Read/Write Transactions</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">Once the user is satisfied with the single transaction implementation, the next logical step is to implement GPIF FIFO
|
|
Read/Write transactions to achieve higher bandwidth numbers. This development stage is a two-phase process in itself because it is highly recommended
|
|
that the FIFO Write waveforms be implemented and tested first. FIFO Write transactions are always the easier to implement out of the two types. The
|
|
user can perform a FIFO Write transaction and verify the integrity of the data on the peripheral side, and if the data looks good then implementing
|
|
FIFO Reads is the next step. This is an important accomplishment because it will rule out the FIFO Write code as the culprit if problems arise with
|
|
the FIFO Read waveform. Otherwise, you will never know which side is truly at fault if each operation is not implemented and tested independently.<br><br>At
|
|
this development stage, there may be also several iterations of integration and test before the user is happy with the
|
|
overall performance of the design. Issues such as meeting setup and hold time arise, especially for synchronous applications where the main reference
|
|
for GPIF operations becomes the external IFCLK or the internal 30/48MHz clock source.<br>
|
|
<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"><b>Optimize if Necessary</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">In generating the GPIF waveforms, the user may initially decide to be generous with the physical bus timing. So, there may
|
|
be room for improvement to cut down the cycle time for each GPIF transaction and still meet the timing parameters required by the peripheral. The
|
|
design may also be revised to improve firmware code efficiency and overall firmware code flow at this stage.<br>
|
|
<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"><b>Summary</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">This section has discussed a GPIF application development flow that uses a systematic approach to help ensure a successful GPIF
|
|
design the first time around. Although it has been touched on at somewhat of a macro level, it gives the user a good feel for the amount of effort
|
|
involved and an approach to tackle a GPIF design from start to finish, no matter the skill level possessed. Figure 7 summarizes this section in an
|
|
ADFM Flow Diagram. The sections ahead discuss the two design examples that will dive into the hardware, firmware, and software necessary to implement
|
|
them.<br>
|
|
<br>
|
|
</font>
|
|
</ul>
|
|
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="1" align="left">
|
|
|
|
<p> </p>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
</body>
|
|
</html>
|