AN4051 FX2LP GPIF Flow State Feature for UDMA.pdf

AN4051
FX2LP™ GPIF Flow State Feature for UDMA
Author: Rich Peng
Associated Project: No
Associated Part Family: CY7C68xxx
Software Version: NA
Related Application Notes: None
If you have a question, or need help with this application note, contact the author at
[email protected]
AN4051 introduces the FX2LPTM GPIF flow state feature, which extends GPIF to handle ATAPI UDMA. This application
note includes flow state definitions and related register functions. It concludes with an example of how to use the flow
state control in a UDMA transfer.
Contents
Introduction ....................................................................... 2
Flow State Definition ......................................................... 2
Register Summary............................................................. 3
Flow State Registers .................................................... 3
FSE .............................................................................. 3
FS[2:0] .......................................................................... 3
LFUNC[1:0] .................................................................. 4
TERMA/B[2:0] .............................................................. 4
CTLOE[3:0] .................................................................. 5
CTL[5:0]........................................................................ 5
SLAVE .......................................................................... 6
RDYASYNC ................................................................. 6
CTLTOGL ..................................................................... 6
SUSTAIN ...................................................................... 6
MSTB[2:0] .................................................................... 7
HOPERIOD[3:0] ........................................................... 7
HOSTATE .................................................................... 7
HOCTL[2:0] .................................................................. 7
FALLING ...................................................................... 8
RISING ......................................................................... 8
D[7:0] ............................................................................ 8
General GPIF Registers ............................................... 9
HOLDTIME[1:0] ............................................................ 9
UDMA CRC Registers .................................................. 9
QENABLE .................................................................. 11
QSTATE ..................................................................... 11
QSIGNAL ................................................................... 11
Waveform Descriptor Enhancements ......................... 11
SGL ............................................................................ 11
SGLCRC .................................................................... 11
www.cypress.com
Summary ......................................................................... 12
Appendix A: Example UDMA Waveform Descriptors ...... 13
UDMA IN Waveform Descriptors ................................ 13
UDMA OUT Waveform Descriptors ............................ 14
Worldwide Sales and Design Support ............................. 17
Document No. 001-15284 Rev. *C
1
FX2LP™ GPIF Flow State Feature for UDMA
Introduction
Although the FX2LPTM GPIF flow state feature was
created for UDMA, it is not limited to that interface. The
GPIF flow state can capture other bus protocols, which
gives it a value and lifetime that extends beyond UDMA.
This is in keeping with the basic philosophy of GPIF.
In particular, the flow state was designed for UDMA mode
4 (66 MB/s) and mode 5 (100 MB/s). UDMA is an
aggressive protocol in general, and these modes give the
added difficulty of speed on top of that. Some of the
features of the UDMA protocol include (note, host means
GPIF and device means, for example, a disk drive):







asynchronous
The idea behind a flow state is to use one GPIF state to
throttle data on the bus. The user sets up a flow logic
register (FLOWLOGIC), similar to the RDY logic opcode in
a waveform descriptor, to decide when to allow data to
flow and when to cause it to temporarily halt. The flow
logic can consider up to two flow logic sources including
internal FIFO flags, the transaction count expiration flag,
any of the six RDY pins, and an 8051 RDY signal.
The flow state feature allows the GPIF to be set up as a
master or as a slave on the bus. The GPIF can be the one
creating the read and write signals, or an external master
can perform those functions. For example, for UDMA OUT
transactions, the GPIF is the master of the data transfer.
For UDMA IN, the device is the master and the GPIF is
the slave.
double-edge data strobes
In the case where the GPIF is the master, the data flow
will work in the following way:
host masters the data phase of OUTs (host-to-device)

The user will pick one of the CTL[5:0] pins to be the
master strobe signal that controls data transfer.

The user will program how fast the master strobe can
toggle and whether data is transferred between the
internal FIFOs and the data bus on the rising, falling,
or double-edge of the master strobe.

The user will then program the flow logic to control
when the master strobe toggles or freezes, thus
controlling the flow of data without having to leave the
GPIF flow state.
device masters the data phase of INs
host or device data pausing
host or device burst termination
CRC calculation and reporting upon termination
Note The term “host” refers to GPIF, and “device” means,
for example, a disk drive
A very capable flow state feature was created thanks to
these requirements and therefore may be able to serve
other aggressive protocols encountered in a USB system.
Although the flow state feature will be efficient in handling
the more aggressive protocols, it can be used for more
mundane protocols as well.
In the case where the GPIF is a slave to an external
master, the data flow will work nearly the opposite way:

The user tells the GPIF which of the six RDY pins is
the master strobe from the external master.
Flow State Definition

The user will then program the flow logic to control the
behavior of the six CTL pins. This allows the user to
assert a ready signal to the external master when the
flow logic evaluates one way, and assert not ready
when the flow logic evaluates the opposite way. Once
again, this controls the flow of data without having to
leave the GPIF flow state.
A typical data transaction involves a setup phase, a data
phase, and a completion phase. The flow state feature is
highly efficient at handling the data phase, especially if the
data phase involves the transfer of multiple data samples.
A flow state can handle the entire data phase while using
up just one GPIF state. This leaves the other six states for
handling the setup and completion phases of the
transaction.
A flow state can be considered to be an extra layer on top
of the normal decision point or interval states of the GPIF.
The flow state does not replace these basic states; it only
enhances them. Although the flow state can be an interval
or a decision point, the most likely use would be as a
decision point. This allows the GPIF to sense when the
correct amount of data has been transferred so that it can
branch to the completion phase of the transaction. If a flow
state were set up as an interval, this would simply mean
that the data phase would have a predictable and
repeatable time duration and behavior. This is not likely in
most multi-sample transactions.
www.cypress.com
In either case, whether the GPIF is the master or the slave
during the flow state, the data flow mechanism will carry
on indefinitely until the decision point logic detects that it is
time to branch out to the completion phase of the
transaction. The decision point logic can use an entirely
different pair of ready sources and logic function than what
was used for the flow logic.
There are eight registers that define a flow state. Not all of
them need to be set up for any particular flow state. Five
of the eight registers must be set up:


FLOWSTATE
FLOWLOGIC
Document No. 001-15284 Rev. *C
2
FX2LP™ GPIF Flow State Feature for UDMA



waveform descriptor, which carries extra meaning if the
SUSTAIN bit (FLOWSTB.4) is set. See the FLOWSTB
register discussion for further explanation of these two
new enhancements.
FLOWEQ0CTL
FLOWEQ1CTL
FLOWSTB
For example waveform descriptors that can handle Mode
4 or Mode 5 UDMA IN or OUT transactions, see the
Appendix.
The other three registers are programmed only if the
situation calls for it and typically only once if so:
FLOWHOLDOFF,
FLOWSTBEDGE,
and
FLOWSTBHPERIOD. See the “GPIF Flow State
Registers” section of the FX2LP Technical Reference
Manual for further explanation of these registers.
Register Summary
The Register Summary is broken into four subsections:
Flow State Registers, General GPIF Registers, UDMA
CRC Registers, and Waveform Descriptor Enhancements.
This section summarizes all of the registers and waveform
descriptors that are associated with the flow state feature.
In addition to these core eight registers, a general GPIF
register called GPIFHOLDAMOUNT has been added as
well as three UDMA CRC related registers: UDMACRCH,
UDMACRCL, and UDMACRCQUALIFIER. The CRC
registers typically do not need attention from the 8051
since this calculation is handled automatically by the
GPIF. See the FX2LP Technical Reference Manual for
further explanation of these registers.
Each register has its own table consisting of eight rows
showing the register name and address in the first row, the
name of the bits in the second row, the default values in
the third row, and the suggested settings for UDMA mode
4 IN, mode 4 OUT, mode 5 IN, and mode 5 OUT in rows
4-7, respectively. The eighth and final row shows the
8051's Read/Write accessibility to the individual bits in the
register.
The final enhancements associated with the new flow
state are in the waveform descriptor itself. A bit was added
to the ACTION opcode that allows the GPIF to do a single
(as in SGLDATH/L) transaction within a FIFO waveform.
An additional enhancement is in the CTL opcode of the
Flow State Registers
FLOWSTATE
E6C6
Bits 7:0
FSE
0
0
0
0
FS[2:0]
Default
0
0
0
0
0
M4IN
1
0
0
0
0
depends on waveform
M4OUT
1
0
0
0
0
depends on waveform
M5IN
1
0
0
0
0
depends on waveform
M5OUT
1
0
0
0
0
depends on waveform
Access
RW
R
R
R
R
0
RW
0
RW
0
RW
Any one (and only one) of the seven GPIF states in a waveform can be programmed to be the flow state. This register defines
which state, if any, in the next invoked GPIF waveform will be the flow state.
FSE
FS[2:0]
Global enable for the flow state. When it is disabled, all
flow state registers are set to “don’t care”, and the next
waveform invocation will not cause a flow state to be used.
Defines which GPIF state is the flow state. Valid values
are 0-6.
www.cypress.com
Document No. 001-15284 Rev. *C
3
FX2LP™ GPIF Flow State Feature for UDMA
FLOWLOGIC
Bits 7:0
E6C7
LFUNC[1:0]
TERMA[2:0]
0
TERMB[2:0]
Default
0
0
0
0
0
0
M4IN
0
0
FIFO PF as an Almost Full
FIFO PF as an Almost Full
0
M4OUT
0
1
FIFO PF as an Almost Empty
RDY pin that is DDMARDY#
M5IN
0
0
FIFO PF as an Almost Full
FIFO PF as an Almost Full
M5OUT
0
1
FIFO PF as an Almost Empty
RDY pin that is DDMARDY#
Access
RW
RW
RW
The bit definitions for this register are analogous to the bit
definitions in the RDY LOGIC opcode in a waveform
descriptor. However, instead of controlling the branching
for a decision point, it controls the freezing or flowing of
data on the bus in a flow state.
The user defines the states of CTL[5:0] for when the flow
logic equals 0 and 1 (see FLOWEQ0CTL and
FLOWEQ1CTL). This is useful in activating or deactivating
protocol ready signals to hold off an external master
(where the GPIF is acting like a slave) in response to
It should be noted that this flow logic does not replace the
decision point logic defined in a waveform descriptor. The
decision point logic in a waveform descriptor is still used to
decide when to branch out of the flow state. The decision
point logic can use an entirely different pair of ready
signals than the flow logic in making its decisions.
LFUNC[1:0]
00
01
10
11
=
=
=
=
A AND B
A OR B
A XOR B
!A AND B
Because the flow logic decision can be based on the
output being a 1 or a 0, NAND, NOR, XNOR and !(!A AND
B) operations can be achieved as well. Note that !(!A AND
B) is the same as (A OR !B).
www.cypress.com
RW
RW
RW
RW
RW
internal FIFO flags warning of an impending underflow or
overflow situation.
In the case where the GPIF is the master, the user also
defines whether MSTB (a CTL pin in this case; see
FLOWSTB) toggles (reads or writes data on the bus)
when the flow logic evaluates to a 1 or a 0. This is useful
for the GPIF to consider protocol ready signals from the
slave as well as FIFO flags to decide when to clock data
out of or into the FIFOs and when to freeze the data flow
instead.
Note The logic function (!A AND B) has been added to the
list of choices for the RDY LOGIC opcode in a waveform
descriptor as well; previously, setting 11 was reserved.
TERMA/B[2:0]
0
1
2
3
4
5
= RDY[0]
= RDY[1]
= RDY[2]
= RDY[3]
= RDY[4]
= RDY[5] or TCXRDY5
(depending on GPIFREADYCFG.5)
6 = FIFO Flag (PF, EF, or FF depending on
GPIFEPxFLAGSEL)
7 = 8051 RDY (GPIFREADYCFG.7)
Document No. 001-15284 Rev. *C
4
FX2LP™ GPIF Flow State Feature for UDMA
FLOWEQ0CTL
Bits 7:0
CTLOE3
Default
M4IN
0
CTLOE2
0
E6C8
CTLOE1 /
CTLOE0 /
CTL5
CTL4
0
0
CTL3
0
CTL2
CTL1
CTL0
0
0
RW
RW
CTL1
CTL0
0
0
RW
RW
0
CTL pin that is HDMARDY# is 0 (based on suggested FLOWLOGIC settings)
CTL pin that is STOP is 0; CTL pin that is DMACK# is 0
M4OUT
CTL pin that is HSTROBE is don't care (taken care of in the 3 FLOWSTB registers)
CTL pin that is STOP is 0; CTL pin that is DMACK# is 0
M5IN
CTL pin that is HDMARDY# is 0 (based on suggested FLOWLOGIC settings)
CTL pin that is STOP is 0; CTL pin that is DMACK# is 0
M5OUT
CTL pin that is HSTROBE is don't care (taken care of in the 3 FLOWSTB registers)
CTL pin that is STOP is 0; CTL pin that is DMACK# is 0
Access
RW
RW
RW
RW
RW
RW
FLOWEQ1CTL
Bits 7:0
CTLOE3
Default
M4IN
0
CTLOE2
0
E6C9
CTLOE1 /
CTLOE0 /
CTL5
CTL4
0
0
CTL3
0
CTL2
0
CTL pin that is HDMARDY# is 1 (based on suggested FLOWLOGIC settings
CTL pin that is STOP is 0; CTL pin that is DMACK# is 0
M4OUT
CTL pin that is HSTROBE is don't care (taken care of in the 3 FLOWSTB registers)
CTL pin that is STOP is 0; CTL pin that is DMACK# is 0
M5IN
CTL pin that is HDMARDY# is 1 (based on suggested FLOWLOGIC settings)
CTL pin that is STOP is 0; CTL pin that is DMACK# is 0
M5OUT
CTL pin that is HSTROBE is don't care (taken care of in the 3 FLOWSTB registers)
CTL pin that is STOP is 0; CTL pin that is DMACK# is 0
Access
RW
RW
RW
These two registers define the state of CTL[5:0] when the
output of the flow logic (see FLOWLOGIC) equals 0 and
when it equals 1. Their definition is analogous to the CTL
opcode in a waveform descriptor. During a flow state, the
CTL opcode in the waveform descriptor is completely
ignored and the behavior of the CTL[5:0] pins are defined
by these two registers instead.
RW
RW
CTL[5:0]
If GPIFCTLOUTCFG.7 = 1 then:

Bits 7:4 become CTLOE[3:0] and the CTL[5:4] pins
are unused.

Bits 3:0 define the CMOS levels of the CTL[3:0] pins if
the corresponding CTLOE bit is 1, else they will be
tristate.
CTLOE[3:0]
If GPIFCTLOUTCFG.7 = 1, then these bits become the
tristate enables for CTL[3:0], and CTL[5:4] are ignored.
Else,

www.cypress.com
RW
Bits 5:0 become the CMOS levels of the CTL[5:0] pins
unless the corresponding bits in
GPIFCTLOUTCFG[5:0] cause these pins to be opendrain; in which case, a 1 means tristate and a 0
means drive 0.
Document No. 001-15284 Rev. *C
5
FX2LP™ GPIF Flow State Feature for UDMA
FLOWSTB
E6CB
Bits 7:0
SLAVE
RDYASYNC
CTLTOGL
SUSTAIN
0
MSTB[2:0]
Default
0
0
1
0
0
M4IN
1
1
don't care
don't care
0
M4OUT
0
don't care
0*
1
0
CTL pin that is HSTROBE
M5IN
1
1
don't care
don't care
0
RDY pin that is DSTROBE
M5OUT
0
don't care
0*
1
0
CTL pin that is HSTROBE
Access
RW
RW
RW
RW
R
0
0
0
RDY pin that is DSTROBE
RW
RW
RW
* - based on suggested FLOWLOGIC settings
This register defines the master signal, called MSTB that
causes data to be read or written during a flow state.
For transactions where GPIF is the slave on the bus,
MSTB will be one of the RDY[5:0] pins. This includes
external masters that can either write data into GPIF (for
example, UDMA IN) or read data out of GPIF.
For transactions where GPIF is the master on the bus,
MSTB will be one of the CTL[5:0] pins. This includes
cases where the GPIF writes data out to a slave (for
example, UDMA OUT) or reads data from a slave.
If MSTB is a CTL pin, the user must also define the rate at
which the CTL pin toggles (see FLOWSTBHPERIOD).
The CTL pin will toggle only when the output of the flow
logic equals the value defined in the CTLTOGL bit.
Otherwise, the CTL pin will freeze. During a flow state, the
behavior of the CTL pins is normally defined by the
FLOWEQ0/1CTL registers, not the CTL opcode of the
waveform descriptor. The exception to this is the MSTB
CTL pin (which only exists if the GPIF is the master on the
bus for the transaction) whose behavior is described by
the following four registers: FLOWLOGIC, FLOWSTB,
FLOWSTBEDGE, and FLOWSTBHPERIOD.
It should be noted that in the case where MSTB is a CTL
pin, the GPIF will produce at most one extra active edge
on MSTB in response to a not ready indication from the
slave. This is regardless of whether the RDY pin is
asynchronous. Also, this is critical to UDMA OUT, which
requires that no more than three extra words be written by
the host (the GPIF) in response to the deactivation of
DDMARDY#.
An additional consideration if
whether it is used to write data
case, the user must define how
respect to the activating
GPIFHOLDAMOUNT).
MSTB is a CTL pin, is
into a slave. If this is the
long to hold the data with
CTL pin edge (see
Regardless of whether MSTB is a CTL or a RDY pin, the
user must define which edge — rising, falling, or doubleedge — will cause a data read or write (see
FLOWSTBEDGE).
www.cypress.com
SLAVE
0: GPIF is the master of the bus transaction. This means
that one of the CTL[5:0] pins will be the MSTB and the
particular one is selected by MSTB[2:0].
1: GPIF is the slave of the bus transaction. This means
that one of the RDY[5:0] pins will be the MSTB and the
particular one is selected by MSTB[2:0].
RDYASYNC
If SLAVE is 0 then this bit is ignored, otherwise:
0: MSTB (which is a RDY pin in this case) is
asynchronous to IFCLK
1: MSTB (which is a RDY pin in this case) is synchronous
to IFCLK
CTLTOGL
If SLAVE is 1, this bit is ignored. Otherwise, this bit defines
which state of the flow logic (see FLOWLOGIC) causes
MSTB (which will be a CTL pin in this case) to toggle. For
example, if this bit is set to 1, then if the output of the flow
logic equals 1, then MSTB will toggle, which causes data
to flow on the bus. If in the same example the output of the
flow logic equals 0, then MSTB will freeze, which causes
data flow to halt on the bus.
SUSTAIN
If SLAVE is 1, this bit is ignored. Although this bit has a
very specific value to UDMA, it is described here in
general terms in the unlikely scenario that another protocol
could use its capability.
Upon exiting a flow state in which SLAVE is 0, MSTB
(which is a CTL pin in this case) will normally go back to
adhering to the CTL opcodes defined in the waveform
descriptor. However, for some protocols (UDMA), it is
necessary to freeze MSTB at the value it was when the
flow state exited. Furthermore, it may be desirable at
some point later in the protocol (UDMA) to return MSTB to
a 1 regardless of what it had been frozen to.
Document No. 001-15284 Rev. *C
6
FX2LP™ GPIF Flow State Feature for UDMA
value of MSTB. If the waveform bit is 1 then it means
return MSTB to a 1 regardless of its prior state. After the
waveform bit is set to1, then the sustain feature is
released and the CTL opcode bit returns to its normal
definition for the remaining states in the waveform.
It may be impossible for the waveform designer to predict
what state MSTB will be in when the flow state exits (due
to not knowing how many pieces of data will be transferred
a priori in a double-edge system for example; UDMA), and
thus may not be able to accurately describe the desired
states of MSTB upon completing the waveform.
MSTB[2:0]
This bit will relieve the user from having to make this
prediction. With this bit set, the bit in the CTL opcode that
corresponds to the MSTB signal will take on the following
new meaning. For states immediately following a flow
state, if the waveform bit is 0, then it means sustain the
If SLAVE is 0, these bits will select which CTL[5:0] pin is
the MSTB. If SLAVE is 1, these bits will select which
RDY[5:0] pin is the MSTB.
FLOWHOLDOFF
Bits 7:0
E6CA
HOPERIOD[3:0]
Default
HOSTATE
HOCTL[2:0]
0
0
0
0
0
0
0
0
M4IN
don't care
don't care
don't care
don't care
don't care
don't care
don't care
don't care
M4OUT
don't care
don't care
don't care
don't care
don't care
don't care
don't care
don't care
0
0
1
0
1
M5OUT
don't care
don't care
don't care
don't care
don't care
don't care
don't care
don't care
Access
RW
RW
RW
RW
RW
RW
RW
RW
M5IN
CTL pin that is HDMARDY#
1.
The interface is asynchronous
example, the disk drive) supports mode 5 UDMA but does
not source data faster than 96 MB/s, then this register can
be ignored.
2.
GPIF is acting like a slave (FLOWSTB.7 = 1), and
thus MSTB is a RDY pin
HOPERIOD[3:0]
For flow state transactions that meet the following criteria:
3.
Data is being written into the GPIF
4.
The rate at which data is being written in exceeds 96
MB/s for a word-wide data bus or 48 MB/s for a bytewide data bus
This register is programmed to protect the synchronization
interface from overflowing (micro-level). This is not to be
confused with protecting the endpoint FIFOs from
overflowing (macro-level), which is managed by the
FLOWLOGIC register. If a transaction does not meet the
above criteria, this register can be ignored because
FX2LP is capable of synchronizing data rates up to 96
MB/s without getting backed up.
An example transaction that meets the above criteria
would be mode 5 UDMA IN which can be as fast as
105 MB/s. Note, however, that if the UDMA device (for
www.cypress.com
Defines how many IFCLK cycles to assert not ready
(HOCTL) to the external master in order to allow the
synchronization interface to catch up.
HOSTATE
Defines what the state of the HOCTL signal should be in
to assert not ready.
HOCTL[2:0]
Defines which of the six CTL[5:0] pins will be the HOCTL
signal which asserts not ready to the external master
when the synchronization detects a potential overflow
coming. It should coincide with the CTL[5:0] pin that is
picked as the “not ready” signal for the (macro-level)
endpoint FIFO overflow protection.
Document No. 001-15284 Rev. *C
7
FX2LP™ GPIF Flow State Feature for UDMA
FLOWSTBEDGE
E6CC
Bits 7:0
0
0
0
0
0
0
FALLING
RISING
Default
0
0
0
0
0
0
0
1
M4IN
0
0
0
0
0
0
1
1
M4OUT
0
0
0
0
0
0
1
1
M5IN
0
0
0
0
0
0
1
1
M5OUT
0
0
0
0
0
0
1
1
Access
R
R
R
R
R
R
RW
RW
This register defines whether MSTB (see FLOWSTB)
causes data to read or be written on either the falling
edge, the rising edge, or both (double-edge).
RISING
0: data is not transferred on the rising edge of MSTB
1: data is transferred on the rising edge of MSTB
FALLING
Note To cause data to transfer on both edges of MSTB,
set both bits to 1.
0: data is not transferred on the falling edge of MSTB
1: data is transferred on the falling edge of MSTB
FLOWSTBHPERIOD
E6CD
Bits 7:0
D[7:0]
Default
0
0
0
0
0
0
1
0
M4IN
0
0
0
0
0
0
don't care
don't care
M4OUT
0
0
0
0
0
0
1
1
M5IN
0
0
0
0
0
0
don't care
don't care
M5OUT
0
0
0
0
0
0
1
0
Access
RW
RW
RW
RW
RW
RW
RW
RW
If the flow state is such that the GPIF is the master on the
bus (FLOWSTB.7 = 0), then MSTB will be one of the
CTL[5:0] pins (see FLOWSTB). While in the flow state, if
the flow logic (see FLOWLOGIC) evaluates in such a way
that MSTB should toggle (see FLOWSTB.5), then this
register defines the frequency at which it will toggle.
More precisely, the user defines the half period of the
MSTB toggling frequency. Further, to give the user a high
degree of resolution this MSTB half period is defined in
terms of half IFCLK periods. Therefore, if IFCLK is running
at 48 MHz this gives the user a resolution of 10.415 ns.
www.cypress.com
For example, mode 4 UDMA OUT transactions suggest
that the half period of MSTB is 30 ns (to get 66 MB/s).
Therefore, the user would write a 3 to this register
(assuming 48 MHz IFCLK), thus obtaining a half period of
31.245 ns. This will give a transfer rate of 62.49 MB/s.
D[7:0]
Number of half IFCLK periods that define the half period of
MSTB (if it is a CTL pin). The value must be at least 2,
meaning that the minimum half period for MSTB is one full
IFCLK cycle.
Document No. 001-15284 Rev. *C
8
FX2LP™ GPIF Flow State Feature for UDMA
General GPIF Registers
GPIFHOLDAMOUNT
E60C
Bits 7:0
0
0
0
0
0
0
HOLDTIME[1:0]
Default
0
0
0
0
0
0
0
0
M4IN
0
0
0
0
0
0
don't care
don't care
M4OUT
0
0
0
0
0
0
0
1
M5IN
0
0
0
0
0
0
don't care
don't care
M5OUT
0
0
0
0
0
0
0
1
Access
RW
RW
RW
RW
RW
RW
RW
RW
For any transaction where the GPIF writes data onto
FD[15:0], this register determines how long the data is
held. Valid choices are 0, ½, or 1 IFCLK cycle. This
register applies to any data written by the GPIF to
FD[15:0], whether through a flow state or not.
activating edge of MSTB (which will be a RDY pin in this
case). Note the hold amount is not directly with respect to
the activating edge of MSTB in this case. It is with respect
to when the data would normally come out in response to
MSTB including any latency to synchronize MSTB.
For non-flow states, the hold amount is really just a delay
of the normal (non-held) presentation of FD[15:0] by the
amount specified in HOLDTIME[1:0].
In all cases, the data will be held for the desired amount
even if the ensuing GPIF state calls for the data bus to be
tristated. In other words, the FD[15:0] output enable will be
held by the same amount as the data itself.
For flow states in which the GPIF is the master on the bus
(FLOWSTB.7 = 0), the hold amount is with respect to the
activating edge (see FLOWSTBEDGE) of MSTB (which
will be a CTL pin in this case).
HOLDTIME[1:0]
00
01
10
11
For flow states in which the GPIF is the slave on the bus
(FLOWSTB.7 = 1), the hold amount is really just a delay of
the normal (non-held) presentation of FD[15:0] by the
amount specified in HOLDTIME[1:0] in reaction to the
=
=
=
=
0 IFCLK cycles
½ IFCLK cycle
1 IFCLK cycle
reserved
UDMA CRC Registers
UDMACRCH
E67D
Bits 7:0
CRC[15:8]
Default
0
1
0
0
1
0
1
0
M4IN
don't write
don't write
don't write
don't write
don't write
don't write
don't write
don't write
M4OUT
don't write
don't write
don't write
don't write
don't write
don't write
don't write
don't write
M5IN
don't write
don't write
don't write
don't write
don't write
don't write
don't write
don't write
M5OUT
don't write
don't write
don't write
don't write
don't write
don't write
don't write
don't write
Access
RW
RW
RW
RW
RW
RW
RW
RW
www.cypress.com
Document No. 001-15284 Rev. *C
9
FX2LP™ GPIF Flow State Feature for UDMA
UDMACRCL
E67E
Bits 7:0
CRC[7:0]
Default
1
0
1
1
1
0
1
0
M4IN
don't write
don't write
don't write
don't write
don't write
don't write
don't write
don't write
M4OUT
don't write
don't write
don't write
don't write
don't write
don't write
don't write
don't write
M5IN
don't write
don't write
don't write
don't write
don't write
don't write
don't write
don't write
M5OUT
don't write
don't write
don't write
don't write
don't write
don't write
don't write
don't write
Access
RW
RW
RW
RW
RW
RW
RW
RW
These two registers are strictly for debug purposes. The
CRC represented by these registers is calculated based
on the rules defined in the ATAPI specification for UDMA
transfers. It is calculated automatically by the GPIF as
data is transferred on FD[15:0].
value of 0x4ABA upon the GPIF entering the IDLE state.
These registers are writeable by the 8051 and thus the
currently calculated CRC including the seed value can be
overwritten at any time. For modes 4 and 5, the 8051
should not write to these registers.
These registers will return the live calculation of the CRC
at any point in the transfer, but will be reset to the seed
UDMACRCQUALIFIER
E67F
Bits 7:0
QENABLE
0
0
0
QSTATE
Default
0
0
0
0
0
1 if host
0
0
0
0
0
0
0
0
don't care
1 if host
0
0
0
0
M4IN
QSIGNAL
0
0
0
CTL pin that is STOP
terminated
M4OUT
M5IN
don't care
don't care
don't care
CTL pin that is STOP
terminated
M5OUT
0
0
0
0
don't care
don't care
don't care
don't care
Access
RW
RW
RW
RW
RW
RW
RW
RW
This register only applies to UDMA IN transactions that
are host terminated. Otherwise, this register can be
completely ignored.
This register covers a very specific and potentially
nonexistent (from a typical system implementation
standpoint*) UDMA CRC situation. However rare the
situation may be, it is still allowed by the ATAPI
specification and thus must be considered and solved by
this register.
The ATAPI specification says that if the host (in this case
the GPIF) terminates a UDMA IN transaction, that the
device (for example, the disk drive) is allowed to send up
to three more words after the host deactivates the
HDMARDY signal. These “dribble” words may not be of
interest to the host and thus may be discarded. However,
CRC must still be calculated on them, because the host
www.cypress.com
and the device must compare and match the CRC at the
end of the transaction to consider the transfer error-free.
The GPIF normally only calculates CRC on words that are
written into the FIFO (and not discarded). This poses a
problem because in this case some words will be
discarded but still must be included in the CRC
calculation. This register gives a way to have the GPIF
calculate CRC on the extra discarded words as well.
The user would program this register in the following way.
The QENABLE bit would be set to 1. The QSIGNAL field
would be programmed to select the CTL pin that coincides
with the UDMA STOP signal. The QSTATE bit would be
programmed to be 0. This would tell the GPIF to calculate
CRC on any DSTROBE edges from the device when
STOP=0, which solves the problem.
Document No. 001-15284 Rev. *C
10
FX2LP™ GPIF Flow State Feature for UDMA
* - A typical UDMA system will have the device, instead of
the host, terminate UDMA IN transfers thus completely
avoiding this situation.
QSTATE
This bit says what state the CRC qualifier signal (selected
by QSIGNAL below) must be in to allow CRC to be
calculated on words being written into the GPIF.
QENABLE
This bit enables the CRC qualifier feature, and thus the
other bits in this register.
QSIGNAL
These bits select which of the CTL[5:0] pins is the CRC
qualifier signal.
Waveform Descriptor Enhancements
ACTION OPCODE
Bits 7:0
0
0
Waveform Descriptor Offset Bytes 8-14
SGL
GINT
INCAD
NEXT /
DATA
DP
SGLCRC
Default
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
M4IN
0
0
1*
0
0
1
1
0
M4OUT
0
0
1*
0
0
1
1
0
M5IN
0
0
1*
0
0
1
1
0
M5OUT
0
0
1*
0
0
1
1
0
Access
RW
RW
RW
RW
RW
RW
RW
RW
* - These settings only apply to the states in which the CRC will be driven on the bus.
The SGL bit allows the GPIF to present data from or
sample data into the GPIFSGLDATH/LX registers during a
FIFO type waveform. Or, alternatively the contents of the
UDMACRCH/L registers can be presented on the bus.
Any state can be programmed to do a single data
transaction.
If the SGL bit is 1 then NEXT takes on new meaning
(because NEXT has no use in a state where a single data
transaction is occurring). The NEXT bit becomes redefined
as the SGLCRC bit. If the SGLCRC bit is 1 then the
contents of the UDMACRCH/L registers are presented on
the bus (provided the DATA bit is 1 as well, which in this
case means drive the data bus).
If, on the other hand, the SGLCRC bit is 0 then the
GPIFSGLDATAH/L registers will be used in the
transaction instead of the UDMACRCH/L registers. If
DATA is 1, the contents of the GPIFSGLDATH/LX
registers will be driven on the bus. If DATA is 0, then the
bus is sampled and the results are placed in the
GPIFSGLDATH/LX registers for the 8051 to read.
data type waveform invocations (such as GPIFSGLDATLX
invocations), this feature does not apply because the
transfer of the GPIFSGLDATH/LX registers is taken care
of by the fact that it was a single data invocation in the first
place.
SGL
0: This particular state is not a single data transaction
within a FIFO waveform
1: This particular state is a single data transaction within a
FIFO waveform; NEXT becomes redefined as SGLCRC
SGLCRC
This bit only has meaning if SGL = 1.
0: The data that gets driven onto the bus (DATA = 1) or
sampled from the bus (DATA = 0) will come from/go to the
GPIFSGLDATH/LX registers
1: The data that gets driven onto the bus (DATA must be
1) will come from the UDMACRCH/L registers.
This feature only applies to FIFO type waveform
invocations (such as GPIFTRIG invocations). For single
www.cypress.com
Document No. 001-15284 Rev. *C
11
FX2LP™ GPIF Flow State Feature for UDMA
CTL OPCODE
Bits 7:0
CTLOE3
Default
M4IN
N/A
CTLOE2
N/A
Waveform Descriptor Offset Bytes 16-22
CTLOE1 /
CTLOE0 /
CTL5
CTL4
N/A
N/A
CTL3
CTL2
CTL1
CTL0
N/A
N/A
N/A
N/A
RW
RW
RW
RW
normal definition
M4OUT
normal definition except for the CTL pin that is HSTROBE
M5IN
normal definition
M5OUT
normal definition except for the CTL pin that is HSTROBE
Access
RW
RW
RW
If a waveform involves a flow state (FLOWSTATE.7 = 1),
and the GPIF is the master on the bus (FLOWSTB.7 = 0),
and the SUSTAIN bit is set (FLOWSTB.4 = 1) then the
CTL bit of this OPCODE that corresponds to the MSTB
CTL pin (FLOWSTB2:0) is redefined from its normal
function.
For states immediately following a flow state, if the
specified CTL bit is 0, it means sustain the value of MSTB.
If the specified CTL bit is 1, it means return MSTB to a 1
regardless of its prior state. After the specified CTL bit is 1,
then the sustain feature is released and the CTL opcode
bit returns to its normal definition for the remaining states
in the waveform.
For more information on this feature, see the definition of
the SUSTAIN bit for the FLOWSTB register.
Summary
RW
application needs to use ATAPI UDMA mode to enhance
the speed then this example exactly address what you
need. If the application in your design is not for the APATI
UDMA control then this document still able to give you an
example how to enable the GPIF Flow State Feature. In
this document, it gives the details in each register usage
and how to handle the flow state in each data transition. It
also gives the detail about UDMA waveform setup in
Appendix A which is a real example to make you able to
completely understand the usage of GPIF Flow State
Feature.
About the Author
Name:
Rich Peng
Title:
Product Apps Group Lead
Contact:
[email protected]
This document gives the details on how to enable GPIF
Flow State Feature with ATAPI UDMA control. If your
www.cypress.com
Document No. 001-15284 Rev. *C
12
FX2LP™ GPIF Flow State Feature for UDMA
Appendix A: Example UDMA Waveform Descriptors
The following section shows example waveform
descriptors for various UDMA scenarios. These waveform
descriptors have been tested and proven in simulation.
There are six different waveforms descriptors broken into
two main categories: UDMA IN and UDMA out. Within
each category there are three different waveforms
representing whether the descriptor handles: host
termination, device termination, or both host and device
termination. The most generic descriptors are those that
handle both host and device termination, but all three are
shown for completeness.
The waveforms were designed to handle Mode 4. The
exact same waveforms handle Mode 5 as well. The
difference comes in how the flow state registers described
in the Register Summary are set up. See that section for
the suggested settings for Mode 4 and Mode 5, IN or
OUT.
The bold state in each table denotes the flow state for that
descriptor.
UDMA IN Waveform Descriptors
UDMA IN Supporting Host Termination
LENGTH / BRANCH
OPCODE
OUTPUT
LOGIC FUNCTION
Offset 0-6
val
Offset 8-14
val
Offset 16-22
val
Offset 24-30
val
State 0
08
State 0
01
State 0
07
State 0
00
State 1
01
State 1
00
State 1
06
State 1
00
State 2
13
State 2
01
State 2
00
State 2
E8
State 3
05
State 3
00
State 3
02
State 3
00
State 4
25
State 4
01
State 4
06
State 4
00
State 5
01
State 5
26
State 5
06
State 5
00
State 6
01
State 6
26
State 6
07
State 6
00
UDMA IN Supporting Device Termination
LENGTH / BRANCH
OPCODE
OUTPUT
LOGIC FUNCTION
Offset 0-6
val
Offset 8-14
val
Offset 16-22
val
Offset 24-30
val
State 0
08
State 0
01
State 0
07
State 0
00
State 1
01
State 1
00
State 1
06
State 1
00
State 2
13
State 2
01
State 2
00
State 2
00
State 3
01
State 3
26
State 3
06
State 3
00
State 4
3F
State 4
27
State 4
07
State 4
3F
State 5
00
State 5
00
State 5
FF
State 5
00
State 6
00
State 6
00
State 6
FF
State 6
00
www.cypress.com
Document No. 001-15284 Rev. *C
13
FX2LP™ GPIF Flow State Feature for UDMA
UDMA IN Supporting both Host and Device Termination*
LENGTH / BRANCH
OPCODE
OUTPUT
LOGIC FUNCTION
Offset 0-6
val
Offset 8-14
val
Offset 16-22
val
Offset 24-30
val
State 0
08
State 0
01
State 0
07
State 0
00
State 1
01
State 1
00
State 1
06
State 1
00
State 2
13
State 2
01
State 2
00
State 2
E8
State 3
05
State 3
00
State 3
02
State 3
00
State 4
25
State 4
01
State 4
06
State 4
00
State 5
01
State 5
26
State 5
06
State 5
00
State 6
01
State 6
26
State 6
07
State 6
00
* - This waveform descriptor is exactly the same as the “UDMA IN Supporting Host Termination” descriptor above. It is duplicated here
for completeness.
UDMA OUT Waveform Descriptors
UDMA OUT Supporting Host Termination
LENGTH / BRANCH
OPCODE
OUTPUT
LOGIC FUNCTION
Offset 0-6
val
Offset 8-14
val
Offset 16-22
val
Offset 24-30
val
State 0
08
State 0
01
State 0
07
State 0
00
State 1
01
State 1
00
State 1
06
State 1
00
State 2
05
State 2
02
State 2
02
State 2
00
State 3
23
State 3
03
State 3
02
State 3
2D
State 4
03
State 4
02
State 4
00
State 4
00
State 5
2E
State 5
03
State 5
04
State 5
00
State 6
01
State 6
26
State 6
06
State 6
00
UDMA OUT Supporting Device Termination
LENGTH / BRANCH
OPCODE
OUTPUT
LOGIC FUNCTION
Offset 0-6
val
Offset 8-14
val
Offset 16-22
val
Offset 24-30
val
State 0
08
State 0
01
State 0
07
State 0
00
State 1
01
State 1
00
State 1
06
State 1
00
State 2
05
State 2
02
State 2
02
State 2
00
State 3
1C
State 3
03
State 3
02
State 3
00
State 4
02
State 4
26
State 4
06
State 4
00
State 5
3F
State 5
27
State 5
07
State 5
3F
State 6
00
State 6
00
State 6
00
State 6
00
www.cypress.com
Document No. 001-15284 Rev. *C
14
FX2LP™ GPIF Flow State Feature for UDMA
UDMA OUT Supporting both Host and Device Termination*
LENGTH / BRANCH
OPCODE
OUTPUT
LOGIC FUNCTION
Offset 0-6
val
Offset 8-14
val
Offset 16-22
val
Offset 24-30
val
State 0
08
State 0
01
State 0
07
State 0
00
State 1
01
State 1
00
State 1
06
State 1
00
State 2
05
State 2
02
State 2
02
State 2
00
State 3
1C
State 3
03
State 3
02
State 3
E8
State 4
03
State 4
02
State 4
00
State 4
00
State 5
2E
State 5
03
State 5
04
State 5
00
State 6
01
State 6
26
State 6
06
State 6
00
* - This waveform descriptor is exactly the same as the “UDMA OUT Supporting Host Termination” descriptor above with the exception
of the two italicized bytes.
www.cypress.com
Document No. 001-15284 Rev. *C
15
FX2LP™ GPIF Flow State Feature for UDMA
Document History
Document Title: FX2LP™ GPIF Flow State Feature for UDMA - AN4051
Document Number: 001-15284
Revision
ECN
Orig. of
Change
Submission
Date
Description of Change
**
1736163
KUH
11/13/2007
Obtained spec # to add to the spec system.
*A
3177111
LIP
02/18/2011
Updated links and replaced FX2 with FX2LP.
*B
3252242
LIP
05/08/2011
Updated Abstract and removed obsolete links.
*C
3719073
LIP
08/21/2012
Added Summary.
Updated in new template.
www.cypress.com
Document No. 001-15284 Rev. *C
16
FX2LP™ GPIF Flow State Feature for UDMA
Worldwide Sales and Design Support
Cypress maintains a worldwide network of offices, solution centers, manufacturer’s representatives, and distributors. To find
the office closest to you, visit us at Cypress Locations.
PSoC® Solutions
Products
Automotive
cypress.com/go/automotive
psoc.cypress.com/solutions
Clocks & Buffers
cypress.com/go/clocks
PSoC 1 | PSoC 3 | PSoC 5
Interface
cypress.com/go/interface
Lighting & Power Control
cypress.com/go/powerpsoc
cypress.com/go/plc
Memory
cypress.com/go/memory
Optical Navigation Sensors
cypress.com/go/ons
PSoC
cypress.com/go/psoc
Touch Sensing
cypress.com/go/touch
USB Controllers
cypress.com/go/usb
Wireless/RF
cypress.com/go/wireless
Cypress Developer Community
Community | Forums | Blogs | Video | Training
Technical Support
cypress.com/go/support
xx and xx are registered trademarks of Cypress Semiconductor Corp. All other trademarks or registered trademarks referenced herein are the property
of their respective owners.
Cypress Semiconductor
198 Champion Court
San Jose, CA 95134-1709
Phone
Fax
Website
: 408-943-2600
: 408-943-4730
: www.cypress.com
© Cypress Semiconductor Corporation, 2007-2012. The information contained herein is subject to change without notice. Cypress Semiconductor
Corporation assumes no responsibility for the use of any circuitry other than circuitry embodied in a Cypress product. Nor does it convey or imply any
license under patent or other rights. Cypress products are not warranted nor intended to be used for medical, life support, life saving, critical control or
safety applications, unless pursuant to an express written agreement with Cypress. Furthermore, Cypress does not authorize its products for use as
critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The
inclusion of Cypress products in life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies
Cypress against all charges.
This Source Code (software and/or firmware) is owned by Cypress Semiconductor Corporation (Cypress) and is protected by and subject to worldwide
patent protection (United States and foreign), United States copyright laws and international treaty provisions. Cypress hereby grants to licensee a
personal, non-exclusive, non-transferable license to copy, use, modify, create derivative works of, and compile the Cypress Source Code and derivative
works for the sole purpose of creating custom software and or firmware in support of licensee product to be used only in conjunction with a Cypress
integrated circuit as specified in the applicable agreement. Any reproduction, modification, translation, compilation, or representation of this Source
Code except as specified above is prohibited without the express written permission of Cypress.
Disclaimer: CYPRESS MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Cypress reserves the
right to make changes without further notice to the materials described herein. Cypress does not assume any liability arising out of the application or
use of any product or circuit described herein. Cypress does not authorize its products for use as critical components in life-support systems where a
malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress’ product in a life-support systems
application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges.
Use may be limited by and subject to the applicable Cypress software license agreement.
www.cypress.com
Document No. 001-15284 Rev. *C
17