PNX1302EH NXP Semiconductors, PNX1302EH Datasheet - Page 279

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
Philips Semiconductors
20.5
The PNX1300 arbiter accepts programmable bandwidth
weights to directly control the percentage of bandwidth
allocated to each unit. In the worst case all bandwidth is
used. If not all of the bandwidth is used, then all units
eventually get their desired bandwidth (as the bus be-
comes free) regardless of the weights. However, the
weights still indirectly guarantee each unit a worst-case
latency, which is important for the real-time behavior.
There are two basic types of PNX1300 coprocessor and
peripheral units. The first type is units which have hard
real-time constraints, i.e. VO, VI, AO and AI. To ensure
multimedia functionality, these units must be able to ac-
quire the bus within a fixed amount of time in order to fill
or empty a buffer before it over- or underflows.
The second type, the CPU, PCI, ICP, VLD and DVDD
units, can absorb long latencies but performance is en-
hanced (there are fewer stall cycles or waiting cycles) if
latency is short. The bandwidth requirement is usually
known and depends on the application. It is especially
well known that ICP and VLD or DVDD have a fixed
bandwidth requirements in multimedia applications.
For the PNX1300 DSPCPU, latency is of prime impor-
tance. CPU performance reduces as average latency in-
creases. The design of the arbiter guarantees that the
DSPCPU gets all unused bus bandwidth with lowest pos-
sible latency. Optimal operation is achieved if the arbiter
is set in such a way that the DSPCPU has the best pos-
sible latency given the required latency and bandwidth of
units active in the application.
To pick programmable weights and priority raising de-
lays, the following procedure is recommended:
1. Try to keep CPU weight as high as possible through
2. Pick weights sufficient to guarantee latency to hard
3. Pick weights for remaining peripherals in order to give
4. If latency and bandwidth slack remains, increase pri-
20.5.1
In the following, ceil(X) is the least integral value greater
than or equal to X.
Latency is defined in each real-time unit chapter through
this databook. Refer to the related sections to find out the
latency requirement according to the mode and clock
speed at which the unit is operating.
This latency value has to be larger than the maximum la-
tency L
For a unit x the arbiter guarantees a latency of:
L
x
= L
the remaining steps.
real-time peripherals (see
enough bandwidth to each (see
2 above has priority, because bandwidth can be ac-
quired as the bus becomes free and because the hard
real-time units use a known amount of bandwidth.
ority raise delays in order to improve average CPU la-
tency.
x,sc
x
ARBITER PROGRAMMING
(in nanoseconds) guaranteed by the arbiter.
* (SDRAM cycle time in ns)
Latency Analysis
Section
Section
20.5.1).
20.5.2). Step
where
L
is the latency in SDRAM clock cycles.
Latency in CPU clock cycles is defined by:
L
The symbols are defined as follows:
T = 20 cycles (transaction length, assuming worst case
pattern alternating reads and writes).
E = 10 cycles (extra delay in case the first transaction
made by the CPU requires a different bank order to sat-
isfy the critical word first.
K = 19 cycles (refresh transaction length).
K
on page
C is the CPU/SDRAM ratio (i.e. 5/4, 4/3, 3/2, 2/1 or 1 as
explained in
R
register ARB_RAISE (see
R
D
allows before the request from unit x goes through.
D
needs the data) as well as the internal implementation
delays that occur in the transaction.
D
PRELIMINARY SPECIFICATION
D
D
D
D
D
D
D
D
D
D
x,sc
x,cc
d
x
x
x
x
x
VLD
AI
AO
DVDD
SPDO
ICP
CPU
VI
PCI
is the programmed refresh interval (see
= 0 for units other than VO, VI, PCI or VLD.
is derived from the arbiter settings as follows:
VO
is the priority raise delay of unit x as stored in MMIO
is the worst case number of requests that the arbiter
includes the transaction from unit x (the unit which
= (D
= ceil(L
=
=
=
=
=
=
=
=
ceil
ceil
12-6).
ceil
=
x
=
ceil
ceil
ceil
ceil
ceil
* T) + E + ceil(D
ceil
ceil
x,sc
Section 12.6.2 on page
2
-------------------------------------------------
VI
----------------------------------------------- -
2
-------------------------------------------------
VO
------------------------------------------------- -
ICP
--------------------------------------------------- -
PCI
--------------------------------------------------- -
+ + + + +
2
-------------------------------------------------
CPU
----------------------------------------------------- -
* C)
+ + + + +
weight
2
-------------------------------------------------
+ + + + +
1
2
-------------------------------------------------
1
weight
+ + + + +
+ + + + +
1
weight
VI
weight
VO
ICP
PCI
1
weight
1
1
CPU
weight
1
+
1
1
1
weight
1
L5
1
+
weight
weight
2
0
0
Section
+
+
x
1
weight
0
1
L3
weight
+
L4
* T / K
L6
0
1
0
L2
1
weight
weight
weight
1
1
weight
1
1
1
20.2).
d
1
) * K + ceil(16*R
×
12-4).
×
1
×
1
D
×
×
D
×
×
D
4
×
D
6
×
D
D
D
6
+
D
Section 12.11
+
2
D
6
+
3
5
1
+
6
+
1
6
+
+
1
+
1
+
1
1
1
Arbiter
1
1
20-5
x
/C)

Related parts for PNX1302EH