PNX1302EH NXP Semiconductors, PNX1302EH Datasheet - Page 134

PNX1302EH

Manufacturer Part Number
PNX1302EH
Description
Manufacturer
NXP Semiconductors
Datasheet

Specifications of PNX1302EH

Lead Free Status / RoHS Status
Not Compliant

Available stocks

Company
Part Number
Manufacturer
Quantity
Price
Part Number:
PNX1302EH
Manufacturer:
NXP
Quantity:
201
Part Number:
PNX1302EH
Manufacturer:
XILINX
0
Part Number:
PNX1302EH
Manufacturer:
PHILIPS/飞利浦
Quantity:
20 000
Part Number:
PNX1302EH,557
Manufacturer:
NXP Semiconductors
Quantity:
10 000
Part Number:
PNX1302EH/G
Manufacturer:
NXP
Quantity:
5 510
Part Number:
PNX1302EH/G
Manufacturer:
NXP/恩智浦
Quantity:
20 000
PNX1300/01/02/11 Data Book
BFR2_EMPTY interrupt before the EVO required the
next buffer. In this case, the EVO uses the old address
pointer value and continues image or data transfer.
When the DSPCPU updates the pointer, the new pointer
value will be used at the start of the next frame or buffer
transfer. Therefore, the URUN flag can be interpreted as
indicating to the DSPCPU that the EVO is using its old
pointer values because it did not receive the new ones in
time.
Note: The actual buffer pointer write operation to the
MMIO registers is not seen by the hardware—only writ-
ing a ’1’ to the appropriate BFR1_ACK or BFR2_ACK
bits signals buffer availability.
The Hardware Bandwidth Error (HBE) flag indicates that
the EVO did not get data from SDRAM via the
PNX1300’s internal data highway in time to continue
data transfer or video refresh. Data or video refresh will
continue using whatever data is in the EVO internal data
buffers. The address counter for the failing buffer(s) will
continue to count, and the EVO will continue to request
data from the SDRAM over the highway.
The EVO is a read-only device, transferring data from
SDRAM to the EVO output port. Unlike Video In, the EVO
does not modify SDRAM data. URUN and HBE are the
only EVO error conditions that can arise. In the case of
URUN or HBE, a scrambled image may be temporarily
displayed or incorrect data may be temporarily sent. The
EVO can cause no other system hardware error condi-
tions.
Even changing operating modes can not cause system
hardware error conditions to arise. For example, chang-
ing the MODE bits, the OL_EN and format bits, or the
LTL_END bit while the EVO is running may cause wrong
data to be displayed or transferred. However, the EVO
does not detect this or stop for it.
In normal operation, the user should not change the
mode or transfer-control bits while the EVO is enabled.
The EVO should be disabled before changing bits such
as the MODE bits, the OL_EN bit, or the LTL_END bit.
However if these bits are changed while the EVO is run-
ning, they will take effect at the beginning of the next field
or buffer.
7.18.4
In order to avoid Hardware Bandwidth Error (HBE) con-
ditions, the internal highway bus arbiter (see
“Arbiter”) must be programmed according to the latency
requirements of the EVO unit described in this section. In
the following discussion, it is assumed that data for video
lines (in Y, U, V and overlay planar memory format) is
stored in memory aligned on 64-byte boundaries. In oth-
er words, it means that the {OL,Y,U,V}_OFFSET fields
are multiples of 64 bytes. Otherwise internal EVO arbitra-
tion for OL, Y, U and V requests will be different than de-
scribed here, and the following latencies would not be
guaranteed. The EVO uses internal 64-byte buffers.
1. Latency requirements for the EVO in image mode
7-24
4:2:2 or 4:2:0 co-sited or interspersed without upscal-
ing and with overlay disabled is expressed as follows.
Latency and Bandwidth Requirements
PRELIMINARY SPECIFICATION
Chapter 20,
2. In the same modes but with overlay enabled, the la-
• During the first 64 EVO clock cycles at least one
• During 128 EVO clock cycles, the EVO unit must
3. When the EVO is set to image mode with 2× upscal-
4. Latency for data-streaming mode or message-pass-
7.18.5
The EVO block enters in power down state whenever
PNX1300 is put in global power down mode, except if the
SLEEPLESS bit in VO_CTL is set. In the latter case, the
block continues DMA operation and will wake up the
DSPCPU whenever an interrupt is generated.
During 128 EVO clock cycles, the EVO block must
have 2 requests acknowledged, that is, ([2Ys, 1U and
1V] / 2). For example, if the EVO clock is 27 MHz,
then the EVO must get two requests (128 bytes) from
SDRAM in 128 / 027 = 4740 ns.
The byte bandwidth B
tive image for this case is:
where ceil(X) is a function returning the least integral
value greater than or equal to X, and W is the
IMAGE_WIDTH field value.
tency is as follows:
request must be acknowledged for the OL data.
have 4 requests acknowledged ([4 OLs, 2 Ys, 1 V
and 1 U] / 2).
For example, if the EVO clock runs at 54 MHz then
the EVO must get the first request from SDRAM in
64/. 054 = 1185 ns and must average a bandwidth la-
tency of 4 requests in 128/.054 = 2370 ns.
Byte bandwidth B
image is then as follows:
ing, the latency requirements are multiplied by a fac-
tor of 2. For example, if 1× mode called for one re-
quest per 64 EVO clock cycles, the latency becomes
one request per 128 EVO clock cycles. Bandwidth is
roughly divided by 2:
B
B
ing mode is as follows:
During 64 EVO clock cycles, the EVO unit must get
one request from SDRAM. For example, if the EVO
clock runs at 38 MHz, then the latency is 64/.038 =
1684 ns and bandwidth is 38 MB/s.
B
B
2x
2xOL
1xOL
1x
=
=
Power Down and Sleepless
=
=
ceil
ceil
B
B
1x
2x
(
( )
-------- -
128
----- -
64
W
W
+
+
1x,OL
)
ceil
ceil
+
+
ceil
ceil
( )
1x
( )
per video line within the active
----- -
32
----- -
64
W
W
Philips Semiconductors
(
per video line within the ac-
(
-------- -
128
W
-------- -
256
+
W
+
)
4
4
)
×
×
×
×
2
2
64
64
+
+
4
4
×
×
64
64

Related parts for PNX1302EH