Part Number Hot Search : 
164245 LC503 254976 SD820 1N5187 10050 02727 CY2077SC
Product Description
Full Text Search
 

To Download NHIXP435AD Datasheet File

  If you can't view the Datasheet, Please click here to try to view without PDF Reader .  
 
 


  Datasheet File OCR Text:
  order number: 316847 ; revision: 005us intel ? ixp43x product line of network processors specification update december 2008
intel ? ixp43x product line of network processors specification update december 2008 2 order number: 316847 ; revision: 005us information in this document is provided in connection with in tel products. no license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted by th is document. except as provided in intel's terms and conditions of sale for such products, intel assumes no liability whatsoever and intel disclaims any express or implied warranty, relating to sale and/or use of intel products including liability or warranties relating to fitness for a particular purpose, merchantability, or infringement of any patent , copyright or other intellectual property right. unless otherwise agreed in writing by intel, the intel products are not designed nor intended for any application in which the failure of the intel product could create a situation where personal injury or death may occur. intel may make changes to specifications and product descriptions at any time, without notice. designers must not rely on the a bsence or characteristics of any features or instructions marked ?reserved? or ?undefined.? intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to th em. the information here is subject to change without notice. d o not finalize a design with this information. intel processor numbers are not a measure of performance. processor numbers differentiate features within each processor family , not across different processor families. see http://www.intel.com/products/processor_number for details. contact your local intel sales office or your distributor to obtain the latest specifications and before placing your product o rder. copies of documents which have an order number and are referenced in this document, or other intel literature, may be obtained by calling 1-800-548- 4725, or by visiting intel?s web site . bunnypeople, celeron, celeron inside, centrino, centrino logo, core inside, flashfile, i960, instantip, intel, intel logo, inte l386, intel486, intel740, inteldx2, inteldx4, intelsx2, intel core, intel inside, intel inside logo, intel. leap ahead., intel. leap ahead. logo, intel n etburst, intel netmerge, intel netstructure, intel singledriver, intel speedstep, intel strataflash, intel viiv, intel vpro, intel xscale, itanium, itanium in side, mcs, mmx, oplus, overdrive, pdcharm, pentium, pentium inside, skoool, sound mark, the journey inside, vtune, xeon, and xeon inside are trademark s of intel corporation in the u.s. and other countries. *other names and brands may be claimed as the property of others. copyright ? 2008, intel corporation. all rights reserved.
intel ? ixp43x product line of network processors december 2008 specification update order number: 316847 ; revision: 005us 3 contents contents 1.0 preface ...................................................................................................................... 5 1.1 affected documents/related documents .............. .................................................. 5 1.2 nomenclature ..................................................................................................... 5 2.0 summary table of changes ....................................................................................... 6 2.1 codes used in summary tables............................................................................. 6 2.1.1 stepping ................................................................................................. 6 2.1.2 page....................................................................................................... 6 2.1.3 status .................................................................................................... 6 2.1.4 row ....................................................................................................... 6 2.2 non-intel xscale ? technology errata..................................................................... 7 2.3 intel xscale ? technology errata ........................................................................... 8 2.4 specification changes .......................................................................................... 8 3.0 identification information ......................................................................................... 9 3.1 markings ............................................................................................................ 9 3.2 part numbers (lead free packaging) .................................................................... 10 3.2.1 intel ? ixp43x product line of network processors ...................................... 10 4.0 non-intel xscale ? technology errata descriptions .................................................. 11 5.0 intel xscale ? technology errata descriptions ......................................................... 18 6.0 specification changes .............................................................................................. 22 figures 1 package markings: intel ? ixp43x product line of network processors ? commercial / extended temperature, lead-fr ee / compliant with standard for restriction on the use of hazardous substances (rohs) ................................................................. 9 2 define ddr_dcalcsr and ddr_dcaladdr registers .................................................. 23 3 emrs code example................................................................................................. 23 tables 1 part numbers for the intel ? ixp43x product line of network processors.......................... 10 2part numbers for the intel ? ixp435 multi-service residential gateway reference platform 10 3 tested devices that pass on the intel ? ixp43x product line of network processors .......... 16
revision history intel ? ixp43x product line of network processors specification update december 2008 4 order number: 316847 ; revision: 005us revision history date revision description december 2008 005 ? added specification change no. 6 - updates to ddr2 setup/hold timing values ? moved non-intel xscale? technology no. 23 and 24 from section 5.0 to section 4.0 note: updated ixp43x documents affected by the march 2008 specification update (316847- 004); the affect ed ixp 43x documents include: - inte l? ixp43x product line of network processors datasheet (316842) - intel? ixp43x product line of network processors developer's manual (316843) - intel? ixp43x product line of ne twork processors design guidelines (316844) - intel? ixp43x product line of network processors design checklist (316849) march 2008 004 ?updated figure 1 ? added non-intel xscale? technology errata 22 under section 2.2 ? updated 4, 5, 6, and 7 spec ification clarifications (see section 6.0, ?specification changes? on page 22 ) ? added 8-18 specification clarifications (see section 2.4, ?specification changes? on page 8 ) december 2007 003 ? added non-intel xscale? technology errata 21 under section 2.2 ? added intel xscale? technology errata 9 and 10 under section 2.3 ?added ?specification changes? on page 22 ?added ta b l e 2 under section 3.2.1 september 2007 002 added non-intel xscale? technology errata 19 and 20 under section 2.2 april 2007 001 initial release of the document ? the first spec ification update combinin g errata for the intel ? ixp43x product line of network processors
intel ? ixp43x product line of network processors december 2008 specification update order number: 316847 ; revision: 005us 5 1.0 preface 1.0 preface this document is an update to the specific ations contained in the affected documents/ related documents table below. this document is a compilation of device and documentation errata, specification clarifications and changes. it is intended for hardware system manufacturers and software developers of applications, operating systems, or tools. information types defined in the nomenclature section are consolidated into this specification update and are no longer published in other documents. this document may contain information that was not previously published. refer to the intel ? ixp43x product line of network processors datasheet for detailed information on various features listed by processor. 1.1 affected document s/related documents 1.2 nomenclature errata are design defects or errors. these may cause the behavior of intel ? ixp43x product line of network processors? to de viate from the published specifications. hardware and software designed to be used with any given stepping must assume that all errata documented for that stepping are present on all devices. specification changes are modifications to the current published specifications. these changes will be incorporated in an y new release of the specification. specification clarifications describe a specific ation in greater detail or further highlight the impact of a specification to a complex de sign situation. these clarifications will be incorporated in any new release of the specification. documentation changes include typos, errors, or omissions from the current published specifications. these will be in corporated in any new release of the specification. note: errata remain in the specification update th roughout the lifecycle of the product, or until a particular stepping is no longer commercially available. under these circumstances, errata removed from the specification update are archived and available upon request. specification changes, specification clarifications and documentation changes are removed from the specification update when the chan ges are made to the appropriate product specification or user documentation such as datasheets, manuals, and so on. title document number intel ? ixp43x product line of network processors datasheet 316842 intel ? ixp43x product line of network processors developer?s manual 316843 intel? ixp43x product line of network processors hardware design guidelines 316844 intel? ixp43x product line of network processors design checklist 316849 intel ? ixp43x product line of network processors : migrating from the intel? ixp42x product line application note 316845
2.0 summary table of changes intel ? ixp43x product line of network processors specification update december 2008 6 order number: 316847 ; revision: 005us 2.0 summary table of changes the following tables indicate the errata , specification changes, specification clarifications, or documentation changes that apply to the intel ? ixp43x product line of network processors. intel may fix some of the errata in a future stepping of the component, and account for the other outstanding issues through documentation or specification changes as noted. the summary tables use the following notations: 2.1 codes used in summary tables 2.1.1 stepping x: this erratum exists in the stepping indicated. specification change or clarification that applies to this stepping. (no mark) or (blank box): this erratum is fixed in listed stepping or specification change does not apply to listed stepping. n/a this erratum or document update is not applicable to this stepping of the silicon 2.1.2 page (page): page location of the item in this document. 2.1.3 status doc: document change or update will be implemented. fix: this erratum is intended to be fixed in a future stepping of the component. fixed: this erratum has been fixed fo r all steppings that are still being shipped. no fix: this erratum has no plans of being fixed. plan fix: this erratum may be fixed in a future stepping of the product. varies: this erratum applies to multiple steppings or devices and the erratum status varies between all steppings that are still being shipped . 2.1.4 row change bar to left of table row indicates this erratum is either new or modified from the previous version of the document.
intel ? ixp43x product line of network processors december 2008 specification update order number: 316847 ; revision: 005us 7 2.0 summary table of changes 2.2 non-intel xscale ? technology errata errata no. steppings page status errata intel ? ixp43x product line of network processors a0 intel ? ixp43x product line of network processors a1 1 xx 11 no fix hdlc coprocessor is unable to capture the alignment error on a specific frame pattern 2 xx 11 no fix pci accesses to the queue manager during queue and sram mode 3 xx 11 no fix ethernet control protocol frames transmit-defer status bit error 4 xx 11 no fix pci doorbell register lock-up condition when using two products together that have intel? ixp4xx product line of network processors 5 xx 12 no fix intel xscale? processor non-branch instruction in vector ta b l e 6 xx 12 no fix ex_iowait_n timing 7 xx 12 no fix ethernet coprocessors ? ethernet pad enable overrides append fcs 8 xx 12 no fix ethernet coprocessors ? length errors on received frames 9 xx 13 no fix false pci dma completion notification causing data corruption 10 xx 13 no fix pci hangs with a multiple inbound error condition 11 xx 13 no fix uart ? break condition asserted too early if two stop bits are used 12 xx 14 no fix ethernet coprocessors ? address filtering logic ignores the second to last nibble of the destination address 13 xx 14 no fix ethernet macs detect la te collision earlier than ethernet 802.3 specifications 14 xx 14 no fix read of pci controllers bar 32'h xxff_fffc rd[n] corrupts subsequent rd[n+1] 15 xx 14 no fix uart operating in non-fifo mode can falsely receive overrun error 16 xx 15 no fix ethernet mac does not detect transmit fifo under-runs reliably 17 x 15 fixed expansion bus bootup failure 18 x 15 fixed incorrect reset value of gp io_inr[0] and gpio_isr[0] 19 xx 15 no fix usb under-run errors when both usb ports perform interrupt out transfers. 20 xx 16 no fix incorrect inter-packet delay on usb interface. 21 xx 16 no fix usb 2.0 device reset during bulk out transaction 22 xx 16 no fix rx fifo overflow condition not properly captured in the rx status register 23 xx 17 no fix incorrect strapping configuration during bootup 24 xx 17 no fix strong pull-up resistor attached to the jtg_trst_n
2.0 summary table of changes intel ? ixp43x product line of network processors specification update december 2008 8 order number: 316847 ; revision: 005us 2.3 intel xscale ? technology errata errata no. steppings page status errata intel ? ixp43x product line of network processors a0 intel ? ixp43x product line of network processors a1 1 xx 18 no fix abort is missed when lock command is outstanding 2 xx 18 no fix aborted store that hits the data cache may mark write- back data as ?dirty? 3 xx 18 no fix performance monitor unit event 0x1 can be incremented erroneously by unrelated events 4 xx 19 no fix in special debug state, back -to-back memory operations ? where the first instruction aborts ? may cause a hang 5 xx 19 no fix accesses to the cp15 id register with opcode2 > 0b001 returns unpredictable values 6 xx 20 no fix disabling and re-enabling the mmu can hang the processor or cause it to execute the wrong code 7 xx 20 no fix updating the jtag parallel registers requires an extra tck rising edge 8 xx 20 no fix non-branch instruction in vector table may execute twice after a thumb mode exception 2.4 specification changes errata no. steppings page status errata intel ? ixp43x product line of network processors a0 intel ? ixp43x product line of network processors a1 1 xx 22 doc updates to pull-down strapping resistor value 2 xx 22 doc updates to pull-down resistor value on jtg_trst_n 3 xx 22 doc ieee* 1588 hardware assistance support 4 xx 22 doc turbo-mii mode support 5 xx 22 doc add procedure to issue emrs ocd command during ddr sdram initialization 6 xx 23 doc updates to ddr2 setup/hold timing values
intel ? ixp43x product line of network processors december 2008 specification update order number: 316847 ; revision: 005us 9 3.0 identification information 3.0 identification information 3.1 markings figure 1. package markings: intel ? ixp43x product line of network processors ? commercial / extended temperature, lead-free / compliant with standard for restriction on the use of hazardous substances (rohs) 1 1. further information regarding rohs and lead-fr ee components can be obtained from your local intel representative; for general information, see http://www.intel.com/technology/silicon/ leadfree.htm . notes: 1. part number field ? for different part numbers of the intel ? ixp43x product line of network processors, see ta b l e 1 . 2. package ball counts ? intel ? ixp43x product line of network processors has a ball count of 460. 3. drawing is not to scale. marking content is an example. part number finish site traceability code intel copyright assembly site traceability code pin # 1 intel? ixp 43x product line of network processors part # fpo# '04 atpo# yww korea i m c e1 lead-free designator (e1) b 4916- 004 assembly year (y) and work week (ww) and country of origin
3.0 identification information intel ? ixp43x product line of network processors specification update december 2008 10 order number: 316847 ; revision: 005us 3.2 part numbers (lead free packaging) 3.2.1 intel ? ixp43x product line of network processors table 1. part numbers for the intel ? ixp43x product line of network processors device stepping speed (mhz) part number temperature offering intel ? ixp435 network processor a1 667 nhixp435ae commercial intel ? ixp435 network processor a1 667 nhixp435aet extended intel ? ixp435 network processor a 1 533 NHIXP435AD commercial intel ? ixp435 network processor a1 533 NHIXP435ADt extended intel ? ixp435 network processor a1 400 nhixp435ac commercial intel ? ixp435 network processor a1 400 nhixp435act extended intel ? ixp433 network processor a 1 533 nhixp433ad commercial intel ? ixp432 network processor a1 400 nhixp432ac commercial intel ? ixp431 network processor a1 400 nhixp431ac commercial intel ? ixp430 network processor a1 667 nhixp430ae commercial intel ? ixp430 network processor a1 533 nhixp430ad commercial intel ? ixp430 network processor a1 400 nhixp430ac commercial intel ? ixp430 network processor a1 400 nhixp430act extended table 2. part numbers for the intel ? ixp435 multi-servic e residential gateway reference platform platform revision speed (mhz) part number mm# intel ? ixp435 multi-service residential gateway reference platform 1.21 667 kixrp435 884168
intel ? ixp43x product line of network processors december 2008 specification update order number: 316847 ; revision: 005us 11 4.0 non-intel xscale ? technology errata descriptions 4.0 non-intel xscale ? technology errata descriptions 1. hdlc coprocessor is unable to capture the alignment error on a specific frame pattern problem: based on itu-t q.921, during transmission, a bit stuffing ?0? is inserted after five consecutive ?1? bits (including the fcs fiel d) and then removed at the receiving end. the bit stuffing ensures that the data does not appear as the ?end of frame? flag (01111110). if five ?1?s are received without a bit stuffing ?0?, a ?byte alignment error? will be issued. the hdlc controller of th e ixp43x product line of network processors will not issue a ?byte alignment error? when the following boundary condition occurs: 1. the receiving frame ends with five ?1?s (fcs) followed by an ?end of frame? flag: ?xx011111 01111110? and 2. the ?end of frame? flag received is byte aligned. implication: an hdlc frame received by the ixp43x product line of network processors hdlc controller from a q.921 compliant hdlc controller with the same pattern described above will not generate a ?byte alignment er ror?; an fcs error will be issued by the hdlc controller. workaround: none status: no fix. 2. pci accesses to the queue mana ger during queue and sram mode problem: under certain data traffic, the pci controller may generate spurious write transfers and may return incorrect data on reads while accessing the queue manager in sram mode. additionally, if the queue manager is being used in the queue mode, pci accesses must not use memory-mapped registers bar0-3 as these accesses cause pre-fetches during reads. implication: pre-fetches will cause loss of queue data. workaround: do not use the queue manager's sram mode during pci accesses. instead use the ddrii/ddri sdram memory space while generating pci accesses to the memory space of the ixp43x network processors. an external pci master must use pci bar5 while accessing the queue manager in queue mode. status: no fix. 3. ethernet control protocol frames transmit-defer status bit error problem: ethernet control protocol transmit frames of size 64 or less result in the transmit-defer status bit being set regardless of the gap between the frames. implication: the transmit-defer status bit in the ixp43x network processors is unusable. workaround: none. status: no fix. 4. pci doorbell register lock-up co ndition when using two products together that have intel ? ixp4xx product line of network processors problem: it is possible that the pci bus can get in a locked condition when multiple products using the ixp4xx product line processors are connected in a system and these systems are using the pci doorbell registers of the ix p4xx product line processors. this lockup occurs only when both the ixp4xx produc t line processors attempt to access each other?s pci doorbell register at a particular instance. this error occurs only on reads of the of the doorbell register. implication: when using two products that use the ixp4xx product line processors and their pci doorbell registers, pci doorbell register reads cannot be implemented. workaround: perform doorbell register write from pci bu s to generate interrupt, and use regular memory to pass information. status: no fix.
4.0 non-intel xscale ? technology errata descriptions intel ? ixp43x product line of network processors specification update december 2008 12 order number: 316847 ; revision: 005us 5. intel xscale ? processor non-branch instruction in vector table problem: if an exception occurs in thumb mode and a non-branch instruction is executed at the corresponding exception vector, that instruction may execute twice. instructions located at exception vectors must be branch instructions that go to the appropriate handler, but the arm architecture allows the fiq handler to be placed directly at the fiq vector (0x0000001c/0xffff001c) with out requiring a branch. because of this condition, the first instruction of such an fi q handler may be executed twice if it is not a branch instruction. implication: instructions may be executed twice if an exception occurs in thumb mode and if it is a non-branch instruction. workaround: if a no-op is placed at the beginning of the fiq handler, the no-op will execute twice and there will not be any incorrect behavior. if a branch instruction is placed at the beginning of the handler, it will not be executed twice. status: no fix. 6. ex_iowait_n timing problem: there are two problems with the functionality of the expansion bus iowait protocol. if both t2 and t3 are programmed to be 0 (n ormal timing), the expansion bus controller will not extend the t3 data state as described in section 12.4.1.5 ?using i/o wait? on page 572, of the intel ? ixp43x product line of network processors developer?s manual - rev. 001 (april 2007). this occurs because there is a synchronizer on the ex_iowait_n signal that causes the expans ion bus controller to transition to the t4 state before the ex_iowait_n is detected. additionally, the intel ? ixp43x product line of network processors developer?s manual states that the expansion bus controller will transition to the t4 state upon the de- assertion of ex_iowait_n. the expansion bus controller does not do this ? instead it waits for the t3 count to expire before proceeding to t4. implication: the expansion bus will not extend the t3 data state as shown in figure 141 of the intel ? ixp43x product line of network processors developer?s manual - rev. 001 (april 2007). workaround: to avoid unexpected timing issues, t2 or t3 must be programmed to non-zero values and assurances made that ex_iowait_n is a sserted at least three cycles before the deasserting edge of ex_rd_n. additiona lly, the extended wait states will not be changed after the deasse rtion of ex_iowait_n. status: no fix. 7. ethernet coprocessors ? ethernet pad enable overrides append fcs problem: the intel ? ixp43x product line of network processors has an ethernet coprocessor that is configured by the intel ? ixp400 software. the coprocessor can be programmed via the ethernet transmit control registers to either append or not append the fcs on the transmitted ethernet frames. when the frame payload size is less than 60 bytes, the pad enable control bit has priority over the append fcs control bit on whether or not the fcs is appended on a frame. implication: when the frame payload size is less than 60 bytes, the fcs will be appended to the transmit frames even though the append fcs control bit is not set because the pad enable control bit overrides the append fcs control bit. workaround: none. status: no fix. 8. ethernet coprocessors ? length errors on received frames workaround: the intel ? ixp43x product line of network processors has an ethernet coprocessor that is configured by the intel ? ixp400 software. the ethernet coprocessor can indicate length error on received frames only when stripping of pad bytes from the received frame is enabled. implication: length errors on received frames when pad stripping (receive control 1 register, bit-1) is disabled will not be indicated to the npe software when it reads the receive status. when pad stripping is enabled, length error indicates that the packet length is
intel ? ixp43x product line of network processors december 2008 specification update order number: 316847 ; revision: 005us 13 4.0 non-intel xscale ? technology errata descriptions not equal to 64 bytes, and the entry in the le ngth field is less than 46, but not zero. workaround: none. status: no fix. 9. false pci dma completion notifi cation causing data corruption problem: the padc1, padc0, apdc1, and apdc0 comple te bits in the pci_dmactrl register will not be cleared under certain conditions when the intel xscale ? processor performs a write-1-to-clear (w1c) to the appropriate bit. if another pci dma transfer is initiated after the clear to the pci_dmactrl register, an indication of complete will occur before the dma transfer has been finished (bec ause the complete bit may not have been cleared). implication: dma data will not be transferred as programmed in the pci dma registers. workaround: following two workarounds are available: ? mask the padc/apdc enables in the pci_inten register and use software to poll the en (bit 31) of the appropriate pci_atpdma0_length, pci_ptadma0_length and pci_atpdma1_length, pci_ptadma1_len gth register to indicate whether the dma transfer was completed. ? if interrupts are preferred, after writing a 1 to clear the appropriate complete bit in the pci_dmactrl register, read the pci_dmactrl register back and ensure the appropriate complete bit was cleared. if not cleared, repeat this step until the appropriate complete bit is cleared. status: no fix. 10. pci hangs with a multip le inbound error condition problem: the pci controller may lock up if there are multiple errors occurring around two different inbound pci transactions. a lock-up will occur when: 1. an inbound pci read that targets an internal slave such as the expansion bus or queue manager results in an ahb error that occurs due to the pci controller generating an illegal ahb transfer type on the target. and 2. a second inbound pci transfer is started while the first pci read is still pending and the second pci transfer detects a pci address or data parity error. implication: the pci controller will continue to retry all inbound transactions, and the pci bus will lock up. workaround: when the pci controller has an ahb error logged (pci_isr.ahbe = 1), a pci parity error is logged (pci_srcr.dpe = 1), and the pci controller retries every inbound transaction; the system board must reset the ixp43x network processors. status: no fix. 11. uart ? break condition asserted too early if two stop bits are used problem: the break condition is asserted after the time of the first stop bit, even if two stop bits are used. implication: in the following scenario, a break condition will be raised on valid data: 1. a byte consisting only zeros is received. 2. the first stop bit sampling is missed, and only the second one is sampled. workaround: do not use two stop bits. status: no fix.
4.0 non-intel xscale ? technology errata descriptions intel ? ixp43x product line of network processors specification update december 2008 14 order number: 316847 ; revision: 005us 12. ethernet coprocessors ? address filtering logic ignores the second to last nibble of th e destination address problem: the intel ? ixp43x product line of network processors has an ethernet coprocessor configured by the intel ? ixp400 software. the ethernet coprocessor logic ignores the second last nibble of the destination address regardless of the packet type (unicast, multicast, broadcast), that is, destination address: 11 22 33 44 55 x6. the reason it is the second last is that the address is tran smitted on the line with high nibble first and then the low nibble. implication: some ethernet frames with wrong destination address can get through the address filter. workaround: a software workaround is possible using the ixethdb filtering capabilities. status: no fix. 13. ethernet macs detect late co llision earlier than ethernet 802.3 specifications problem: on an improperly designed network, when a collision occurs on the threshold of the smallest valid ethernet frame, it is detected as a late collision rather than an early collision. implication: the collided frame will not be retried up to the programmed retry count and will be dropped. workaround: cable lengths, number of repeaters, and other parameters that affect the network design must be planned not to operate on the boundary of the ethernet specifications. status: no fix. 14. read of pci controllers bar 32'h xxff_fffc rd[n] corrupts subsequent rd[n+1] problem: if specifically reading the ?last word? address of a bar register, read(n), and if that bar register is set up adjacent to undefined me mory space (that is, not adjacent to another bar register), this read(n) will complete co rrectly, but will cause data corruption in the subsequent read (n+1). implication: upon the next subsequent external pci master read rd[n+1], the pci controller returns incorrect read data of rd[n]. workaround: avoid reading the last word of the bar or avoid reading this one bar entirely. the setup could be changed such that the bar registers are adjacent to each other in memory space and place the config bar 4 on top of the final bar so that no ?last word? address in each memory address bar0-3 is adjacent to undefined memory space. for example: status: no fix. 15. uart operating in non-fifo mode can falsely receive overrun error problem: if the uart is operating in non-fifo mode, there is a possibility of falsely receiving an overrun error under certain conditions even though an overrun did not occur. implication: an erroneous interrupt to the intel xscale processor may occur indicating that data was lost in the uart. workaround: using the uart in fifo mode or in non-fifo mode, the data should be rejected and resent. bar4 - config bar: highest address bar3 bar2 bar1 bar0 - lowest address
intel ? ixp43x product line of network processors december 2008 specification update order number: 316847 ; revision: 005us 15 4.0 non-intel xscale ? technology errata descriptions status: no fix. 16. ethernet mac does not detect tr ansmit fifo under-runs reliably problem: there is a transmit race condition in the 10/100 ethernet mac. the race condition happens when the 10/100 ethernet macs tran smit fifo is filled on the same transmit clock as the transmit fifo under-run occurs on the line side. if the race condition were to happen, the 10/100 mac may end up appe nding four more bytes of indeterminate data to the ethernet frame that is transmitted on the line. the fcs will be generated on the frame that includes the four extra bytes so the receiver will not detect any problem with the frame. currently no customers have experienced this problem or a problem with similar symptoms with years of testing and millions of units productized and deployed. implication: this problem can potentially occur in situat ions of intense npe load (vlan/qos, fire wall, header conversion) resulting in the transmission of corrupt frames. this problem is detectable in applications that run any upper-layer protocol. for example, layer 3/4 in the network application stack will detect th is problem (because of ip checksum error) and drop the packet before it reaches the app lication. this error is undetectable by the receiver. workaround: none. status: no fix. 17. expansion bus bootup failure problem: ex_data is switching between input and output during bootup sequence. as the output buffer is always enabled, the bootup co de cannot be driven into the intel xscale processor successfully. implication: after reset, the intel ? ixp43x product line of network processors performs read transaction through expansion bus. the ixp43x product line of network processors continues to drive the ex_data[15:0] even when ex_rd_n is asserted. this causes a bus contention with the target device on the expansion bus. the ixp43x product line of network processors also drives the ex_data[15:0] with values from ex_addr[15:0] appearing as if it is attempting to perform a multiplexed mode read transaction. however, the ex_ale were not asserted, an d it does not release the ex_data for the target device. workaround: none. status: fixed. 18. incorrect reset value of gpio_inr[0] and gpio_isr[0] problem: gpio[0] has a weak pull-up to 3.3v, if the gpio0 is configured as input. the weak pull-up will appear internally and propagate al l the way to the interrupt status register, intr_st. it will interrupt only the inte l xscale processor via either irq or fiq (intr_en bit 6) that corresponds to the enabled gpio0. implication: the value of the gpio_inr[15:0] and gpio_i sr[15:0] should be zero when configured as input; though the value read back from the intel ? ixp43x product line of network processors does not indicate all zero. the read back value of the gpio_inr[15:1] and gpio_isr[15:1] are zeros, while the gpio_inr[0] and gpio_isr[0] are ones. workaround: none. status: fixed. 19. usb under-run errors when both usb ports perform interrupt out transfers. problem: under-run errors are noticed on usb ports when both the ports are performing interrupt out transfers. single port will not report any error. the under-run error notifies that the host is ready to transmit, but the data is not available in transmit buffer. implication: interrupt out transfer is not supported on both the usb ports simultaneously. workaround: do not perform interrupt out transfer on both ports simultaneously. use single port instead. the interrupt out pipe is optional . if no interrupt out endpoint is declared
4.0 non-intel xscale ? technology errata descriptions intel ? ixp43x product line of network processors specification update december 2008 16 order number: 316847 ; revision: 005us then output reports are transmitted to a device through the control endpoint. status: no fix. 20. incorrect inter-packet delay on usb interface. problem: the inter-packet delay (ipd) between two consecutive high-speed transmit packets from the usb ports does not meet the usb2.0 compliant test specification of minimum 88 to maximum 192 bit time. as a result, unable to pass and obtain usb2.0 compliant logo. the ipd is the time between the end of one packet to the start of the subsequent packet. implication: devices that connect to the usb interface may not be recognized when using high speed mode. workaround: none. status: no fix. 21. usb 2.0 device reset during bulk out transaction problem: in high speed mode, the bit stuffing mechanism fails to insert a zero on the seventh bit position followed by six consecutive ones. as a result, the usb host fails to send the entire maxpacketsize, and illegal packets ar e detected at the device (for example mdata and split token in bulk out transfer). the device will be reset and packets are re-transmitted. implication: failure signature is intermittent. the usb device will be reset in between the transmission cycles. eventually the entire da ta size (or file) will successfully get to the device. meaning that the data could be delayed and cause a performance impact. workaround: none. status: no fix. 22. rx fifo overflow condition not pr operly captured in the rx status register problem: whenever rx fifo overflows, it generates a rx_fifo_error signal to the receive state machine (rsm). the rsm will transit to a state where it will report a status valid for npe to read the rx status register (via ecp_rdrxsts instruction). during this state, the state machine fails to capture the rx_fifo_erro r signal properly and transits back to idle state. this results in the rx fifo overflow condition not properly captured in the rx status register. implication: causes no further packets to be received in the rx fifo. the issue is observed only when tmii co-exist with hss interface. w ill not happen when the npe runs in standard mii mode. workaround: workaround has been implemented in the intel ? ixp400 software version 3.0.1. the ethernet npe measures the rx idle time , and issues ethernet mac coprocessor instruction (ecp_clearrxerror) to flush mac rx engine fifo to correct the lock-up table 3. tested devices that pass on the intel ? ixp43x product line of network processors device capacity external vendor note storage: usb2.0 flash disk 512 mb sandisk* - storage: usb2.0 flash disk 1 gb kingston* - storage: usb2.0 flash disk 128 mb transcend* - storage: usb1.1 flash disk 128 mb hp* - storage: usb2.0 2.5? hdd 80 gb samsung* usb enclosure: polar storage: usb2.0 3.5? hdd 80 gb seagate* usb enclosure: polar printer: usb2.0 hp photosmart d5160 - hewlett packard* - printer: usb1.1 epson color photo stylus 790 - epson* - webcam: usb2.0 creative webcam live - creative*
intel ? ixp43x product line of network processors december 2008 specification update order number: 316847 ; revision: 005us 17 4.0 non-intel xscale ? technology errata descriptions condition. in addition, the et hernet npe uses internal control state to prevent repetitive flushing of the mac rx engine fifo. status: no fix. 23. incorrect strapping co nfiguration during bootup problem: the ex_addr[23:0] has a strong pull-up resi stor attached internally. during bootup, the strapping value will be read incorrectly when the ex_addr[23:0] is attached to 1k ohm pull-down resistor. implication: incorrect strapping configuration will be read during bootup. workaround: a 470 ohm pull-down is required to override the internal pull-up resistor. status: no fix. 24. strong pull-up resistor attached to the jtg_trst_n problem: the jtg_rst_n has a strong pull-up resistor attached internally. during bootup, the ieee 1149.1 jtag interface is unable to detect a ?low? at the jtg_trst_n pin when it is attached to a 10k ohm pull-down resistor. implication: intermittent bootup problem. workaround: a 100 ohm pull-down is required to override the internal pull-up resistor. status: no fix.
5.0 intel xscale ? technology errata descriptions intel ? ixp43x product line of network processors specification update december 2008 18 order number: 316847 ; revision: 005us 5.0 intel xscale ? technology errata descriptions 1. abort is missed when lo ck command is outstanding problem: a bus abort occurs on a code fetch while an instruction tlb or i-cache lock move to coprocessor from intel xscale processor register (mcr) command is outstanding. the processor fails to abort and instead executes the instruction returned on the aborting transaction. parity errors are not affected. the bus abort may be due to an abort pin assertion. workaround: branch flush after every i-tlb or i-cache lock. for example, the following instruction does this: sub pc, pc #4;flush the pipe. status: no fix. 2. aborted store that hits the data cache may mark write-back data as ?dirty? problem: when there is an aborted store that hits clean data in the data cache (data in an aligned 4-word range that has not been modified from the processor since it was last loaded from memory or cleaned), the data in the array is not modified (the store is blocked), but the ?dirty? bit is set. when the line is then aged out of the data cache or explicitly cleaned, the data in that four-w ord range is evicted to external memory, even though it has never been changed. in norm al operation this is nothing more than an extra store on the bus that writes the same data to memory that is already there. the boundary condition where this might occur: 1. a cache line is loaded into the cache at address a. 2. another master externally modifies address a. 3. a processor store instruction attempts to modify a, hits the ca che, aborts because of mmu permissions, and is backed out of the cache. that line normally is not marked dirty, but because of this errata, is marked as dirty. 4. the cache line at a then ages out or is exp licitly cleaned. the original data from the location a is evicted to external memory, overwriting the data written by the external master. this happens only when soft ware is allowing an external master to modify memory, that is, write-back or write-allocate in the processor page tables, and, depending on the fact that the data is not dirty in the cache, to preclude the cached version from overwriting the extern al memory version. when there are any semaphores or any other handshaking to pr event collisions on shared memory, this is not a problem. workaround: for this shared memory region, mark it as write-through memory in the processor page table. this prevents the data from ever being written out as dirty. status: no fix. 3. performance monitor unit ev ent 0x1 can be incremented erroneously by unrelated events problem: event 0x1 in the performance monitor unit (pmu ) can be used to count cycles in which the instruction cache cannot deliver an instruction. the cycles counted should be only those due to an instruction cache miss or an instruction tlb miss. the following unrelated events in the processor also causes the corresponding count to increment when event number 0x1 is being monitored: ? any architectural event (for example, irq, data abort) ? msr instructions that alter the cpsr control bits ? some branch instructions, including indirect branches and those mispredicted by the btb ? cp15 mcr instructions to registers 7, 8, 9, or 10 that involve the instruction cache or the instruction tlb
intel ? ixp43x product line of network processors december 2008 specification update order number: 316847 ; revision: 005us 19 5.0 intel xscale ? technology errata descriptions each of the preceding items may cause the performance monitoring count to increment several times. the resulting performance monitoring count may be higher than expected when the preceding items occur, but should never be lower than expected. workaround: there is no way to obtain the correct number of cycles stalled due to instruction cache misses and instruction tlb misses. extra counts due to branch instructions mispredicted by the btb may be one component of the unwanted count that can be filtered out. the number of mispredicted branches can also be monitored using performance monitoring event 0x6 during the same time period as event 0x1. to obtain a value closer to the correct one, the mispredicted branch number can then be subtracted from the instruction cache stall number generated by the performance monitor. this workaround only addresses counts contribute d by branches that the btb is able to predict. all the items in the preceding bulleted lis t still affect the count. depending on the nature of the code being monitored, th is workaround may have limited value. status: no fix. 4. in special debug state, back-to-back memory operations ? where the first instruction aborts ? may cause a hang problem: when back-to-back memory operations occu r in the special debug state (sds, used by ice and debug vendors) and the first memory operation gets a precise data abort, the first memory operation is correctly cance lled and no abort occurs. depending on the timing, however, the second memory operation may not work correctly. the data cache may internally cancel the second operation, but the register file may have score- boarded registers for that second memory op eration. the effect is that the processor may hang (due to a permanently score-boarded register) or that a store operation may be incorrectly cancelled. workaround: in special debug state, any memory operation that may cause a precise data abort should be followed by a write-buffer drain operation. this precludes further memory operations from being in the pipe when th e abort occurs. load mu ltiple/store multiple that may cause precise data aborts should not be used. status: no fix. 5. accesses to the cp15 id register with op code2 > 0b001 returns unpredictable values problem: the arm architecture reference manual (arm ddi 0100e) states the following in chapter b-2, section 2.3: when an value corresponding to an unimplemented or reserved id register is encountered, the system contro l processor returns the value of the main id register. id registers other than the main id register are defined so that when implemented, their value cannot be equal to that of the main id register. software can therefore determine whether they exist by reading both the main id register and the desired register and comparing th eir values. when the two values are not equal, the desired register exists. the intel xscale processor does not implement any cp15 id code registers other than the main id register (opcode2 = 0b000) and the cache type register (opcode2 = 0b001). when any of the unimplemented registers are accessed by software (for example, mrc p15, 0, r3, c15, c15, 2), the value of the main id register was to be returned. instead, an unpredictable value is returned. workaround: none. status: no fix.
5.0 intel xscale ? technology errata descriptions intel ? ixp43x product line of network processors specification update december 2008 20 order number: 316847 ; revision: 005us 6. disabling and re-enabling the mmu can hang the processor or cause it to execute the wrong code problem: when the mmu is disabled via the cp15 control register (cp15, cr1, opcode_2 = 0, bit 0) after being enabled, certain timing cases can cause the processor to hang. in addition to this, re-enabling the mmu after disabling it can cause the processor to fetch and execute code from the wrong physical a ddress. to avoid these issues, the following code sequence must be used whenever disa bling the mmu or re-enabling it afterwards. workaround: the following code sequence can be used to disable and/or re-enable the mmu safely. the alignment of the mcr instruction that disables or re-enables the mmu must be controlled carefully so that it resides in the first word of an instruction cache line. status: no fix. 7. updating the jtag parallel regist ers requires an extra tck rising edge problem: the ieee 1149.1 specification states that the effect of updating all parallel jtag registers should be seen on the falling edge of tck in the update-dr state. the intel xscale processor parallel jtag registers require an extra tck rising edge to make the update visible. therefore, operations like hold-reset, jtag break, and vector traps require either an extra tck cycle by going to run-test-idle or by cycling through the state machine again in order to trigger the expected hardware behavior. workaround: when the jtag interface is polled continuously, this erratum has no effect. if not, an extra tck cycle can be caused by going to run-test-idle after writing a parallel jtag register. status: no fix. 8. non-branch instruction in vector table may execute twice after a thumb mode exception problem: when an exception occurs in thumb mode and a non-branch instruction is executed at the corresponding exception vector, that instruction may execute twice. the instructions located at exception vectors must be branch instructions that go to the appropriate handler, but the arm architectu re allows the fiq handler to be placed directly at the fiq vector (0x0000001c/0xf fff001c) without requiring a branch. due to @ the following code sequence takes r0 as a parameter. the value of r0 will be @written to the cp15 control register to either enable or disable the mmu. mcr p15, 0, r0, c10, c4, 1 @ unlock i-tlb mcr p15, 0, r0, c8, c5, 0 @ invalidate i-tlb mrc p15, 0, r0, c2, c0, 0 @ cpwait mov r0, r0 sub pc, pc, #4 b 1f @ branch to aligned code .align 5 1: mcr p15, 0, r0, c1, c0, 0 @ enable/disable mmu, caches mrc p15, 0, r0, c2, c0, 0 @ cpwait mov r0, r0 sub pc, pc, #4
intel ? ixp43x product line of network processors december 2008 specification update order number: 316847 ; revision: 005us 21 5.0 intel xscale ? technology errata descriptions this bug, the first instruction of such an fiq handler may be executed twice when it is not a branch instruction. workaround: when an nop is placed at the beginning of the fiq handler, the nop executes twice and there is no incorrect behavior. when a branch instruction is placed at the beginning of the handler, it does not execute twice. status: no fix.
6.0 specification changes intel ? ixp43x product line of network processors specification update december 2008 22 order number: 316847 ; revision: 005us 6.0 specification changes 1. updates to pull-down strapping resistor value issue: the ex_addr[23:0] has a strong pull-up resistor attached internally. a 470 ohm pull-down is required to override these pull-up resistors. affected docs: intel ? ixp43x product line of network processors datasheet , intel? ixp43x product line of network processors hardware design guidelines and intel? ixdp435 multi- service residential gateway reference platform schematics . 2. updates to pull-down resi stor value on jtg_trst_n issue: the jtg_trst_n has a strong pull-up resistor attached internally. a 100 ohm pull-down is required to override this pull-up resistor. affected docs: intel ? ixp43x product line of network processors datasheet , intel? ixp43x product line of network processors hardware design guidelines and intel? ixdp435 multi- service residential gateway reference platform schematics . 3. ieee* 1588 hardware assistance support issue: the ieee* 1588 standard defines a precision clock synchronization protocol for networked measurement and control system s. it provides a kind of correction mechanism by implementing several me ssage exchange timing information to synchronize individual clocks of the multiple systems. the intel ? ixp43x product line of network processors provides hardware assist block to achieve this purpose. the hardware assist block is called ?time synchr onization hardware assist? (tsync). refer to the enabling time synchronization (ieee1588) hardware on intel ? ixp43x network processors application notes . the logic also supports one non-mii ?aux iliary? interface via gpio[8:7] pins. the gpio[8:7] must be tied with a 10k-ohm pull-down while using the ieee* 1588. affected docs: intel ? ixp43x product line of network processors developer?s manual and intel ? ixp43x product line of network processors datasheet . 4. turbo-mii mode support issue: added new feature. the intel ? ixp43x product line of network processors support turbo mii (tmii) mode of operation. it is the standard mii supporting over clock up to 50 mhz (instead of 25 mhz) to provide throughput of 200 mbps full-duplex. for details, see the latest version of the intel ? ixp43x product line of network processors datasheet . affected docs: intel ? ixp43x product line of network processors datasheet . 5. add procedure to issue emrs ocd command during ddr sdram initialization issue: the intel ? ixp43x product line does not support ocd calib ration. according to the jedec standard for ddr2 sdram specificat ion, when ocd calibration is not used, emrs ocd default command (a9=a8=a7=1) followed by emrs ocd calibration mode exit command (a9=a8=a7=0) must be issu ed with other operating parameters of emrs. add the following procedures as step 16 in section 11.2.2.10 ddr sdram initialization of the intel ? ixp43x product line of network processors developer?s manual : emrs ocd default command (a9=a8=a7=1) followed by emrs ocd calibration mode exit command (a9=a8=a7=0) must be issued . the ?ocd program? field is mapped to dcaladdr register bit[9:7]. 1) configure the dcalcsr register (hex offset: cc00 f500) with bit[2:0]=?011? 2) configure the dcaladdr register (hex offset: cc00 f504) with bit[1:0]=?01?, and bit[9:7]=?111? to issue a ocd default command
intel ? ixp43x product line of network processors december 2008 specification update order number: 316847 ; revision: 005us 23 6.0 specification changes 3) software must wait for at least 2 cycles. then configure the dcaladdr register (hex offset: cc00 f504) with bit[1:0]=?01 ?, and bit[9:7]=?111?. (to issue a ocd exit command) note: other fields in the dcalcsr and dcaladdr registers should be left as ?zero? (default value after reset). the ?qoff?, ?rdqs?, and ?dqs? fields are mapped to dcaladdr register bit[12:10] respectively. the dll enabled is configured through writin g ?0100? to the sdir register. the rtt is configured by writing to sdcr0 register bit[5:4]. procedure to modify the bootload er (for emrs ocd instruction): solution for redboot* platform (packages/hal/arm/xscale/ixdp435/current/include/ hal_ixp425.h) as illustrated in figure 2 . solution for redboot* platform (packages/hal/arm/xscale/ixdp435/current/include/ hal_platform_setup.h). add in the emrs code (bold) in between step 14 and step 15, as illustrated in figure 3 . affected docs: intel ? ixp43x product line of network processors developer?s manual . figure 2. define ddr_dcalcsr and ddr_dcaladdr registers figure 3. emrs code example // step 14. issue mode register set w/o dll reset mov r1, #ddr_sdir_mode_set_no_reset str r1, [r0, #ixp_ddr_sdir] delay 0x100000, r1 //*********added steps:emrs ocd calibration default******** ldr r2, [r0, #ixp_ddr_dcaladdr] //save dcaladdr value in r2 before modifying ldr r1, = 0x01000003 //set bit24=1 for sdram enable //set bits[0:1] for emrs ocd default str r1, [r0, #ixp_ddr_dcalcsr] ldr r1, =0x00000381 //set bits [9:7] and bit 0 for emrs ocd default str r1, [r0, #ixp_ddr_dcaladdr] delay 0x100000, r1 //*********added steps:emrs ocd calibration mode exit****** ldr r1, =0x00000001 //set bit 0 only for exit str r1, [r0, #ixp_ddr_dcaladdr] delay 0x100000, r1 str r2, [r0, #ixp_ddr_dcaladdr] //restore original dcaladdr value // step 15. start normal operation
6.0 specification changes intel ? ixp43x product line of network processors specification update december 2008 24 order number: 316847 ; revision: 005us guidelines , the tva4 timing specification shows a minimum time of 2020 ps. the minimum timing for tva4 should be 1650 ps . the tables will be replaced as below. affected docs: intel ? ixp43x product line of network processors datasheet and intel? ixp43x product line of network processo rs hardware design guidelines . table: ddrii-400mhz interface - signal timings symbol parameter min. nominal max. units notes t vb4 dq, cb, and dm read input valid time before dqs rising or falling edges -480 ps ps 2 t va4 dq, cb, and dm read input valid time after dqs rising or falling edges 1650 ps ps 2


▲Up To Search▲   

 
Price & Availability of NHIXP435AD

All Rights Reserved © IC-ON-LINE 2003 - 2022  

[Add Bookmark] [Contact Us] [Link exchange] [Privacy policy]
Mirror Sites :  [www.datasheet.hk]   [www.maxim4u.com]  [www.ic-on-line.cn] [www.ic-on-line.com] [www.ic-on-line.net] [www.alldatasheet.com.cn] [www.gdcy.com]  [www.gdcy.net]


 . . . . .
  We use cookies to deliver the best possible web experience and assist with our advertising efforts. By continuing to use this site, you consent to the use of cookies. For more information on cookies, please take a look at our Privacy Policy. X