Identifying the C80 Device Revision
The revision number for each C80 device may be determined by
the device symbolization located in the upper right hand
corner on the top of the device package. The device
revision is identified by the first two numbers in the third
line of the device symbolization. The example device symbol
shown here indicates a Rev 3.0 device.
TMS
320C80GF
E30-56CETET
\
Revision Code
Device Speeds:
- Revision 1.x devices are limited to 25 MHz operation (50 MHz CLKIN).
Parameter tc(CKI) must be at least 20 nS minimum.
- Revision 2.x devices are limited to 25 MHz operation (50 MHz CLKIN).
Parameter tc(CKI) must be at least 20 nS minimum.
- Revision 3.x and later devices: Refer to data sheet.
The following errata exists on silicon version 3.x devices.
- 3.1 No Synchronizer on LINT4:
-
The level-sensitive interrupt (LINT4) on the MP is not
passed through a synchronizer before being sampled by INTPEN.
If a bad level is sampled due to the signal changing as the sample is taken,
this can cause unpredictable behavior.
-
Work Around:
Synchronize the interrupt externally or don't use this interrupt.
-
Problem exists for silicon revisions: 1.0, 1.1, 1.2, 2.0, 3.0 and 3.1
-
Fix proposed for silicon revision: 4.0 and later.
- 3.2 HTOTAL Greater Than Line Length:
-
If a Frame Timer(FT) within the Video Controller(VC) is configured for
external synchronization and its
HTOTAL register is programmed to a value which is longer
than the line length of the external signal, then the MP interrupt will
NOT occur. MP interrupt refers to bit f0 or f1
of the MP's INTPEN register, as appropriate.
Currently the interrupt signal waits for the
HCOUNT=HTOTAL condition to
activate the interrupt signal to the MP, which doesn't occur in this case.
HCOUNT=HTOTAL
END OF --+ | Interrupt would occur here,
EXTERNAL | | but this condition
LINE V V doesn't occur!
_________________________
| X |
| SCREEN X |
| X |
|________________X________|
-
Work Around:
Program the horizontal line length (HTOTAL register) of the FT to be
the same as the externally applied source line length.
-
Problem exists for silicon revisions: 1.0, 1.1, 1.2, 2.0, 3.0 and 3.1
-
Fix proposed for silicon revision: 4.0 and later.
- 3.3 d0[F]/sr[R] bug in PP:
-
The problem occurs when using d0[F] to switch an EALU instruction
from being "maskgen" (%) to "mf spreading" (@mf).
If there is NOT a "multiple" function modifier, then the value written back
to the mf register should be rotated according to the R bit/Msize combination.
The problem is that the mf register is NOT being rotated in this case, even when R=1.
-
Work Around:
Do NOT try to rotate the mf register using the R bit when using d0[F] to
switch an EALU instruction from being "maskgen" (%) to
"mf spreading" (@mf). Use a function modifier to do rotation.
-
Problem exists for silicon revision: 3.0 and 3.1
d0[F] bit did not exist in earlier versions.
-
Fix proposed for silicon revision: 4.0 and later.
- 3.4 Variable Patch Guided Packet Transfer Problem:
-
The following packet transfers will not execute correctly: variable patch
guided for either src or dst where the penultimate guide table entry has Acount
and Bcount both equal to zero, in systems where the caches are being serviced
from either 2 or 3 cycle per column memory. Src packet transfers of this type
will additionally generate a bad packet interrupt.
-
Work Around:
Remove the guide table entry completely
OR change the Bcount to 1 if the Acount is 0.
-
Problem exists for silicon revisions: 1.0, 1.1, 1.2 and 2.0
for Dst packet transfers of this type.
-
Verified fixed for silicon revision: 3.0 and later
for Dst packet transfers of this type.
-
Problem exists for silicon revisions: 1.0, 1.1, 1.2, 2.0, 3.0 and 3.1
for Src packet transfers of this type.
-
Fix proposed for silicon revision: 4.0 and later
for Src packet transfers of this type.
- 3.5 Late TRG^ and W^ Active
During RETRY^:
-
If RETRY^ is asserted to generate multiple MRS cycles,
the TRG^ and W^ signals in the MRS cycles
during which RETRY^ is active will go active later than
expected. The inactive going edges are unaffected. This
is only going to affect systems in which multiple banks of SDRAM
are present.
The following is the corrected timings for the data sheet to be used
only for those silicon revisions which have the errata.
| Item number |
Datasheet Specification |
40MHz |
50MHz |
| 23 |
th(OUTV-CKOL) |
ntH-13.0 ns |
ntH-10.0 ns |
| 24 |
th(OUTV-CKOL) |
ntH-13.0 ns |
ntH-10.1 ns |
| 27 |
th(OUTV-OUTV) |
ntH-13.0 ns |
ntH-11.0 ns |
| 28 |
td(CKOH-OUTV) |
ntH+13.0 ns |
ntH+11.0 ns |
| 29 |
td(CKOL-OUTV) |
ntH+13.0 ns |
ntH+11.0 ns |
| 32 |
td(OUTV-OUTV) |
ntH+13.0 ns |
ntH+11.0 ns |
| 33 |
tw(OUTV) |
ntH-13.0 ns |
ntH-11.0 ns |
-
Work Around: None.
-
Problem exists for silicon revision: 3.0 and 3.1
There are no SDRAM cycles for previous revisions.
-
Fix proposed for silicon revision: 4.0 and later.
- 3.6 Power-up DCAB cycles sensitive to RETRY^:
-
If RETRY^ is sampled active during the power-up DCAB
cycle, another DCAB cycle will be performed subsequently (as per MRS).
It is probable that neither the C80 nor the user's system will be affected
by more than one power-up DCAB cycle.
However, if the user's decode logic asserts RETRY^ during the
power-up DCAB cycle, the chances are it will continue to do so during the
subsequent DCAB cycles erroneously generated by the RETRY^, and
the system will perform power-up DCAB cycles ad infinitum.
-
Work Around:
Ensure RETRY^ is not low at the sample point for power-up
DCAB cycles.
-
Problem exists for silicon revision: 3.0 and 3.1
-
Fix proposed for silicon revision: 4.0 and later.
- 3.7 Low Level Switching Noise Seen on C80 Output Pins:
-
Under certain conditions associated with multiple output drivers switching
from a logic one to a logic zero, low level glitches can occur.
Figure 35 in the device datasheet (titled 'TTL Level Outputs') shows
0.6v as the absolute VOL level and 0.8v as the value used to guarantee
output pin timing. Instead of testing to 0.6v & 0.8v, the following
table describes the guaranteed values (tested in manufacturing test):
VCC Tc (Case Temperature) VOL (Max)
================================================
< = 3.3V > = 25 ° C 0.98V
VOL performance degrades as VCC exceeds 3.3v and/or temperature
goes below 25 Degrees C. Manufacturing test checks for VOL values above
0.98v under these test conditions.
-
Work Around:none
-
Problem exists for silicon revision: 3.0
-
Fix proposed for silicon revision: Revision 3.1 is expected to improve
performance of this parameter.
- 3.8 Sampling RETRY^ at column time:
-
The sampling of RETRY^ during the column
time pipeline will not force the C80 to relinquish control
of the address and data buses. The pipeline IS flushed.
The sampling of RETRY^ during column accesses is
supposed to force
the memory interface back to the r1 state. However, the memory
interface will not return to the r1 state until the next access
starts. Occasionally, this may be some considerable time later.
-
Work Around:
This is normally only a problem for systems during debug, when long periods
of bus inactivity are frequent, or in systems which turn off the refresh
controller. Systems which use shared resources without refreshes or those
which need to force the C80 to relinquish control of the address and data
buses immediately can use the HREQ^ pin instead.
-
Problem exists for silicon revisions: 1.0, 1.1, 1.2, 2.0, 3.0 and 3.1
-
Fix proposed for silicon revision: 4.0 and later.
- 3.9 DBEN^ not driven inactive:
-
It is possible that DBEN^ will not be driven inactive in
the first r1 in a sequence of r1 states. DBEN^ may be driven
inactive in any r1 state in a sequence of r1 states, but at the very least
it will be driven inactive in the last r1 state of that sequence.
In addition, that sequence of r1 states may be interrupted by the
activation of HREQ^. In this case DBEN^ may
not be driven inactive until the r1 sequence completes i.e after the deactivation of
HREQ^. DBEN^ still goes to a high impedance
state during a Host Request.
-
Work Around: Not needed.
-
Problem exists for silicon revisions: 2.0, 3.0 and 3.1
-
Fix proposed for silicon revision: 4.0 and later.
- 3.10 READY sampled during column cycles with no
CAS^ signals active:
-
The C80 can perform column accesses in which none of the CAS^
signals are active. During such cycles the C80 samples READY
in the normal way. This may cause problems if the external control of
READY is not qualified with CAS^ active.
i.e If READY is being held inactive waiting for a count of
CAS^ active cycles, the memory interface can then become locked
as there could be no CAS^ active cycles. This applies to 2 and 3
cycles per column memory timings (Those which support column time Wait-States).
-
Work Around:
Don't assert READY during column accesses until CAS^
is active. If this is not possible for 2 cycle/column memory timings, then use
three cycle/column memory timings with one less waitstate.
-
Problem exists for silicon revisions: 1.0, 1.1, 1.2, 2.0, 3.0 and 3.1
-
Fix proposed for silicon revision: 4.0 and later.
- 3.11 MP Data Cache Control Register Access:
-
A hazard exists when reading or writing to/from an MP Data cache control
register(16 TAG Registers and the LRU register) while the Data cache is
being serviced(such as a cache miss or cache flush). Erroneous values
could be retrieved.
-
Work Around:
The user can ensure that any cache service completes before accessing
the Cache control registers by using a 'dummy' load before
the rdcr/wrcr instruction.
(save value of global interrupt first)
(disable global interrupt)
ld r0(r0),r0 ; dummy load to stall MP's pipeline
(restore global interrupt afterwards)
rdcr/wrcr instruction
-
Problem exists for silicon revisions: 1.0, 1.1, 1.2, 2.0, 3.0 and 3.1
-
Fix proposed for silicon revision: 4.0 and later.
-
See also: errata 2.7 and 2.8
- 3.12 External to External Packet Transfers:
-
If a packet transfer(PT) with a source address that is off-chip has a
destination address which changes from off-chip to on-chip and the off-chip
source data is greater than 120 bytes, erroneous behavior will occur.
-
If the destination address changes from on-chip to off-chip OR if the source
address is on-chip the device works correctly.
-
Work Around:
Packet transfers in which the source address is off-chip and the destination address
changes from being off-chip to being on-chip should be avoided unless
the off-chip source data is less than 120 bytes.
OR: The PT can be separated into two or more PTs so that the off-chip to on-chip change
does not occur within a single PT or until the off-chip source data is less that 120 bytes.
-
Problem exists for silicon revisions: 1.0, 1.1, 1.2, 2.0, 3.0 and 3.1
-
Fix proposed for silicon revision: 4.0 and later.
- 3.13 Peripheral Device Packet Transfers:
-
For peripheral device packet transfers(PDPT), if Acount is not set to 0
in the source parameters for writes or in the destination parameters
for reads, unknown behavior will occur for the transfer. This parameter
is listed as "unused" in the TC User's Guide.
-
Work Around:
For PDPTs, set Acount = 0 in the source parameters for writes or in the
destination parameters for reads.
-
Problem exists for silicon revisions: 2.0, 3.0 and 3.1
PDPTs did not exist for silicon revisions earlier than 2.0.
-
Fix proposed for silicon revision: 4.0 and later.
- 3.14 Peripheral Device Packet Transfers:
-
The TC User's guide states that when setting up a Peripheral Device Packet Transfer(PDPT),
the unused machine (source for writes and destination for reads) should be set up
so that its start address is 0 with Bcount and Ccount listed as "unused".
This is supposed to be sufficient to ensure that the unused machine is inactive.
In fact, if Bcount or Ccount is non-zero the unused machine will NOT be inactive.
-
Work Around:
When setting up the parameters for a PDPT, one should set
Bcount = Ccount = Start Address = 0 in the source parameters for writes or in the
destination parameters for reads.
-
Condition exists for silicon revisions: 2.0 and later
PDPTs did not exist for silicon revisions earlier than 2.0.
-
Fix proposed for TC User's guide.
The TC user's guide will be changed to indicate that Bcount, Ccount and the
Start Address for the unused machine MUST be 0.
- 3.15 Data corruption when mixing long and short read latencies:
-
The problem can occur in systems which utilize both the 3 cycle read
latency synchronous DRAM AND unpipelined one cycle per column memory
timings. Furthermore, both types must be read from within an external
to internal packet transfer which has guided transfer destination
parameters. Under certain circumstances too complicated to go into in
detail, the transition from the SDRAM to the unpipelined 1 cycle per
column timings can cause one byte of the data to get corrupted.
-
Work Around:
Don't read from both memory types from within a packet transfer of
the type described above.
-
Problem exists for silicon revisions: 3.0 and 3.1
Synchronous DRAM support did not exist for previous revisions.
-
Fix proposed for silicon revision: 4.0 and later.
- (NEW)
- 3.16 Address validity checked at wrong time:
-
When performing either an offset or delta-guided packet
transfer, the TC incorrectly checks the validity of the
base address before the offset or delta is added. If the
base address (src or dst) is invalid, the packet transfer
terminates with a fault.
-
Work Around:
Ensure that the base address(es) for offset and delta-guided
transfers are valid before issuing the transfer.
-
Problem exists for silicon revisions: 1.0, 1.1, 1.2, 2.0, 3.0 and 3.1
-
Fix proposed for silicon revision: 4.0 and later.
- (NEW)
- 3.17 Error in Packet Transfer Status (PTS) Reporting:
-
PTS is generated with a raw dst fault signal, unqualified with whether the
dst address is on-chip or off-chip. On-chip or off-chip addresses are determined
by the 7 MSBs of the address. Because of this, when performing a PT, a problem will
arise when:
- an on-chip src address produces a fault AND
- the dst address is off-chip AND
- the 25 LSBs of the dst address (assuming the 7 MSBs are 0s) point to an
illegal on-chip address. For example, a dst address of 0x80004000 is interpreted
by the fault detection logic as the illegal on-chip address of 0x00004000.
-
PTS incorrectly reports that a dst fault has occured when in fact a src fault
has occurred.
-
Work Around: None.
-
Problem exists for silicon revisions: 1.0, 1.1, 1.2, 2.0, 3.0 and 3.1
-
Fix proposed for silicon revision: 4.0 and later.
- (NEW)
- 3.18 XPT input Synchronzation Problem:
-
The Transfer Controller User's Guide indicates that the XPT
lines are internally synchronized within the C80. This would indicate that
externally, the XPT lines can be asserted asynchronously with respect to the clock.
However, the synchronizer within the C80 for the XPT lines is not operating correctly.
Because of this, signal skew between the XPT inputs can cause an invalid level to
be recognized.
For example, a waveform such as the following, can cause XPT2 (coding 101) to
submitted instead of XPT3 (coding 100).
_____ _____
CLKOUT / \_____/ \_
____________________
XPT[2] is HI
_________
XPT[1] \__________
: :
___________:
XPT[0] : \________
: :
--: :--skew
-
Work Around:
Synchronize the XPT inputs externally to the rising edge of CLKOUT.
-
Problem exists for silicon revisions: 1.0, 1.1, 1.2, 2.0, 3.0 and 3.1
-
Fix proposed for silicon revision: 4.0 and later.
- (NEW)
- 3.19 mf status being set even when EALU operation is discarded
-
A typical method of doing an MPY-only instruction on a PP is to
code an EALU instruction in parallel with the MPY instruction
making the destination of the EALU instruction the same as the
destination of the MPY instruction. In this way, the EALU result is
discarded. Neither the status register (sr) nor the multiple flags (mf)
register is supposed to be updated by this EALU instruction since it is
purposely being discarded.
An errata exists such that the mf register is being updated based
on the EALU instruction when it is not suppose to be updated
at all.
-
Work Around:
If your code is relying on no mf status setting when the EALU
operation is discarded, then you can work around this
by setting up the EALU operation (which will be discarded) to
produce ALU status setting identical to that already present.
-
Problem exists for silicon revisions: 1.0, 1.1, 1.2, 2.0, 3.0 and 3.1
-
Fix proposed for silicon revision: 4.0 and later.
The following errata exists on silicon version 2.x devices.
- 2.1 TDI, TMS,
TCK Pins:
-
The bias point of the TDI, TMS, and TCK
input pins for the JTAG scan interface is incorrect. Inputs
will be recognized as high at 0.65 Volts instead of 2.0 Volts.
-
Work Around:
A low-noise path between the Emulator Header
connector and the C80 JTAG pins should be provided to
prevent noise from causing low level inputs to be
interpreted as logical high inputs.
-
Problem exists for silicon revisions: 1.0, 1.1, 1.2 and 2.0
-
Problem verified fixed for silicon revision: 3.0 and later.
- 2.2 Hardware Reset During Active Host Request:
-
If the HREQ^ is
active low when the RESET^ input is driven active low, the
C80's external memory interface will remain in high-impedance
for several cycles after the completion of the
hardware reset (behaving as though HREQ^ were still active).
DRAM refresh cycles will not occur and the TC will not fetch
the MP reset vector until the TC has determined that no host
request is pending.
-
Work Around: Not needed.
-
Problem exists for silicon revisions: 1.0, 1.1, 1.2 and 2.0
-
Problem verified fixed for silicon revision: 3.0 and later.
- 2.3 Peripheral Device Transfers:
-
During Peripheral Device Packet Transfers, the DBEN^ signal
is not driven high to disable C80 data transceivers. This will result in a drive
conflict during Peripheral Device write cycles when both the
C80 transceivers and the peripheral attempt to drive data
-
Work Around:
In systems that do not use transceivers on the
C80 data bus, no work around is required as the C80's data
bus will be placed in high impedance. Systems using C80
data bus transceivers can qualify DBEN^ to the transceivers
with the row-time status code on STATUS[4:0] to disable DBEN^
during peripheral device PT cycles (STATUS[4:0] = 0010x).
-
Problem exists for silicon revisions: 1.0, 1.1, 1.2 and 2.0
-
Problem verified fixed for silicon revision: 3.0 and later.
- 2.4 Packet Transfer Crossbar Priority:
-
When accessing crossbar
RAMs, both high priority and low priority packet transfers
are given the low priority packet transfer priority. This
causes both priority levels to operate below the priority of
the PPs on the crossbar and may delay service of high
priority packet transfers if contention occurs.
-
Work Around:
This condition may be avoided by careful
programming to prevent processor and packet transfer
contention. MP packet transfers submitted as urgent
priority will correctly operate at the urgent PT level on
the crossbar.
-
Problem exists for silicon revisions: 1.0, 1.1, 1.2 and 2.0
-
Problem verified fixed for silicon revision: 3.0 and later.
- 2.5 PP Loop Reload Register:
-
If one of the PP loop reload registers is updated using a loop reload register,
(via a write to lrn, lrsn, or
lrsen) while a cache miss is occurring, the
register will be corrupted. For example:
lrse0 = lr0 - 1
causes lr0 to be corrupted.
-
Work Around:
Avoid updating the loop reload registers with their own contents.
(Copy to an intermediate register first.)
-
Problem exists for silicon revisions: 1.0, 1.1, 1.2 and 2.0
-
Problem verified fixed for silicon revision: 3.0 and later.
- 2.6 Faulted PP Cache Services:
-
When a memory fault occurs
during a PP instruction cache service the TC is supposed to
write the address of the faulted location to the PP's
parameter RAM. However if the TC was in the process of
reading in a packet transfer parameter table when the cache
service is begun then the incorrect address will be written
to the parameter RAM if the memory fault occurs. This will
prevent the MP from determining the faulting address.
-
Work Around:
Problem can be avoided by not storing PP
instructions in faultable memory.
-
Problem exists for silicon revisions: 1.0, 1.1, 1.2 and 2.0
-
Problem verified fixed for silicon revision: 3.0 and later.
- 2.7 MP Data Cache Flush:
-
The dcache(c/f) instructions may write
back data cache subblocks that are present and not dirty or
that are not present.
-
Work Around:
A subblock should be checked to make sure both
its present and dirty bits are set before issuing a
dcache(c/f) command to it.
-
Problem exists for silicon revisions: 1.0, 1.1, 1.2 and 2.0
-
Problem verified fixed for silicon revision: 3.0 and later.
-
See also: errata 2.8 and 3.11
- 2.8 MP Data Cache Flush:
-
The dcachef command does not clear a
subblock's present (p) bits unless the dirty (d) bit is set.
-
Work Around:
If the entire data cache is being flushed,
then a cmnd 0x08000100 may be used to clear all the present
bits. If only part of the cache is to be flushed, then the
TAG registers can be examined to find the appropriate TAG
and the P bit cleared by hand using rdcr and wrcr commands
(after ensuring that the cache controller is idle using a ld r0(r0),r0
command). Alternatively, a "dummy" write to a
location within the subblock (ld location to a register and
then st it back) may be performed to ensure that the dirty
bit is set prior to issuing the dcachef command.
-
Problem exists for silicon revisions: 1.0, 1.1, 1.2 and 2.0
-
Problem verified fixed for silicon revision: 3.0 and later.
-
See also: errata 2.7 and 3.11
- 2.9 Extra Wait States for READY from
FAULT^ or RETRY^:
-
This applies to all one cycle per column memory waveforms except refresh.
When RETRY^ or FAULT^ are sampled LOW just
after RL FALL (r3 state) the C80 returns to the RL HIGH state (r1 state). In
this case READY is then sampled when it should not be, in the r1
state, one cycle after RETRY^ and FAULT^ were
sampled (r3 state). If READY were LOW at this point,
it would have the effect of extending RL HIGH until READY is
sampled HIGH.
This bug means that occasionally wait states may be inserted during RL
HIGH when they are not needed. These wait states should be harmless as
the C80 will appear as if it were idling in the r1 state. These wait
states will cease to be inserted once READY becomes HIGH.
-
Work Around:
The bug can be avoided by ensuring READY is not LOW, in the r1 state,
one cycle after RETRY^ and FAULT^ are sampled LOW when
using one cycle per column memory waveforms.
-
Problem exists for silicon revisions: 1.0, 1.1, 1.2 and 2.0
-
Problem verified fixed for silicon revision: 3.0 and later.
- 2.10 READY incorrectly prioritized with respect to
FAULT^ or RETRY^:
-
If READY and RETRY^ or READY and
FAULT^ are active together then READY is
disabled within the C80. This does not have any effect on the
resampling of READY once it is active.
-
Work Around: None.
-
Problem exists for silicon revisions: 1.0, 1.1, 1.2 and 2.0
-
Problem verified fixed for silicon revision: 3.0 and later.
The following errata exists on silicon version 1.x devices.
- 1.1 Packet Transfer Using Fill with Value:
-
When a packet transfer using the Fill with Value Src operation
(bits 14-12 of PT Options field set to 001) is performed, the TC
incorrectly checks the validity of the Src Start Address.
An invalid Src Start Address will cause the packet transfer
to terminate with a fault.
-
Work Around:
This problem may be avoided by
ensuring that the Src Start Address field in the PT
Parameter Table has been programmed to 0x00000000 or some
other valid address before submitting the packet transfer.
-
Problem exists for silicon revisions: 1.0, 1.1 and 1.2
-
Problem verified fixed for silicon revision: 2.0 and later.
- 1.2 Host Request During SRT Cycle:
-
If a Host Request occurs
(HREQ^ goes active low) during an SRT cycle, the tap point of
the SRT cycle (output on A[31:0] at column time) may get corrupted.
-
Work Around:
For a display buffer the error will cause
incorrect data to be displayed for the portion of the frame
generated by the SRT cycle. This will merely result in a
brief flicker on the display so no work around may be
required. For capture and merge/capture buffers, incorrect
data will be placed in the VRAM array. This problem may be
avoided by monitoring the REQ[1:0] outputs and not
generating a Host Request when an SRT is pending (REQ[1:0] = 11).
-
Problem exists for silicon revisions: 1.0, 1.1 and 1.2
-
Problem verified fixed for silicon revision: 2.0 and later.
- 1.3 Packet Transfer Retries:
-
If a retry occurs during a packet
transfer and another transfer request of equal priority is
pending, the retried transfer will be always be suspended.
The retried packet transfer should only be suspended if it
has been serviced for PTMIN number of cycles.
-
Work Around: None.
This condition can only occur if RETRY^ is
asserted during a packet transfer's off-chip memory access.
-
Problem exists for silicon revisions: 1.0, 1.1 and 1.2
-
Problem verified fixed for silicon revision: 2.0 and later.
- 1.4 Reset Halt:
-
The MP should halt after reset if HREQ^ is high
at the rising edge of RESET^. However, if the MP has already
been reset once in halt mode it will come out of reset
running if HREQ^ is held high during RESET^.
-
Work Around:
The MP reset halt operation can be achieved by
generating a rising edge of HREQ^ while RESET^ is active low
and maintaining HREQ^ high until RESET^ is driven inactive.
-
Problem exists for silicon revisions: 1.0, 1.1 and 1.2
-
Problem verified fixed for silicon revision: 2.0 and later.
- 1.5 Transfer Controller Request Priorities:
-
The Transfer
Controller does not correctly reevaluate request priorities
during crossbar contention. If a high priority request
(such as an SRT request) occurs, then the request of the
current operation is raised to that of the higher priority
request so that the current operation can complete as soon
as possible. If the current operation is stalled due to
crossbar contention, the crossbar priority level is not
raised as it should be. This can result in extended
contention and delay in completion of the current operation.
-
Work Around:
This condition is most likely to occur when
a packet transfer is contending for a RAM with a PP which is
accessing the RAM every cycle. This can be avoided by
careful programming to avoid processor and packet transfer
contention.
-
Problem exists for silicon revisions: 1.0, 1.1 and 1.2
-
Problem verified fixed for silicon revision: 2.0 and later.
- 1.6 Column Time Address Signals:
-
The User's Guide specifies that
address lines A[2:0] will always output the current byte
address (address bits A(2:0)) at column time regardless of
the address shift. On Rev 1.x devices, A[2:0] are valid at
column time only for an address shift of 000.
-
Work Around:
Column time byte addresses must be taken from
their shifted position on the address bus (somewhere within
A[17:8], depending on the shift amount) for cycles with a
non-zero address shift.
-
Problem exists for silicon revisions: 1.0, 1.1 and 1.2
-
Problem verified fixed for silicon revision: 2.0 and later.
- 1.7 FPU Accumulator "collision":
-
A collision occurs when the
FPU multiplier and the FPU adder (ALU) both have an
instruction in their last stages at the same time. When the
result of an FPU ALU instruction is being written to a FPU
accumulator at the same time the FPU multiplier tries to
write its result to the register file (or to the FPU ALU in the
case of an output denormal), a collision occurs, and the FPU
accumulator is not updated with the FPU ALU result.
-
Work Around:
Arrange code so that a collision does not
occur when the FPU ALU result is to an accumulator.
-
Problem exists for silicon revisions: 1.0, 1.1 and 1.2
-
Problem verified fixed for silicon revision: 2.0 and later.
|
|
