Part Number Hot Search : 
AMS6211 65308 NE734 1024C 11N50 LUS11D 1N4386 LM119
Product Description
Full Text Search
 

To Download SLLS280 Datasheet File

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


  Datasheet File OCR Text:
 ERRATA TO THE TSB14C01 1394 BACKPLANE PHYSICAL LAYER DATA SHEET
(TEXAS INSTRUMENTS LITERATURE NO. SLLS231B, MAY 1997)
This document contains corrections and additions to information in the TSB14C01 data sheet (TI Literature Number SLLS231B, May 1997), also included in IEEE 1394 Circuits Data Book, 1997 (TI Literature Number SLLD004). The TSB14C01 can improperly process an immediate-type link request (LREQ) under certain conditions. If an immediate-type LREQ is received by the 14C01 before it has processed a previous fair-type LREQ or a previous priority-type LREQ, the 14C01 may not process the immediate-type LREQ. This problem has been corrected in the production release revision A device -- TSB14C01A If a system implements randomly occurring async (fair or priority) requests, there exists the possibly that a link will make an async LREQ at the same moment that another link is sending it a small async packet. The receiving link will then send an immediate request (acknowledge) LREQ as soon as the header is confirmed. Instead of clearing the fair request and processing the immediate request, the TSB14C01 at the receiving node ignores the immediate request and processes the fair request. At this point the phy is processing a fair request but the link is processing an immediate request. This means that the link is expecting its next communication to be a grant or deny of the bus. The phy, however, is waiting until a fair gap occurs to arbitrate to send an async packet. When the fair gap occurs on the bus, the phy sends a status to the link and then arbitrates for the bus. If it wins the bus, it will send a transmit grant back to the link layer. Sending a status at this point when the link is expecting a grant or deny is an error condition for the link layer. Depending on the link layer used, this may cause different problems.
Symptoms
If any of the following symptoms are observed, the error is likely occurring. a. Symptoms on the sending node - The sending node does not receive an acknowledge from the receiving node. An acknowledge may be sensed by loading all but the final quadlet into the ATF, clearing the TXRdy interrupt before finishing loading the ATF in the sending node, finishing loading the ATF to send the packet, and then waiting for the TXRdy to be set on receipt of the acknowledge. After TXRdy is sensed, the acknowledge sent may be read from the ATAck field. b. Symptoms on the receiving node - The time between LREQ occurrences will be less than approximately 10 s, but more than approximately 140 ns at 100 Mbps with 7 bit bus requests. At 50 Mbps, bus requests will be more than approximately 280 ns apart. A status will be sent from the TSB14C01 to the link layer controller before the 14C01 grants the phy-link interface to the link to send an acknowledge packet. After the status is sent, the TSB14C01 arbitrates for the bus to send an async packet. If it wins it sends a grant back to the link layer controller, all happening instead of an ack being sent.
- -
1
Printed in U.S.A.
POST OFFICE BOX 655303
* DALLAS, TEXAS 75265
SLLS280 - SEPTEMBER 1997
SLL
Workarounds
The appropriate workaround depends on the link layer being used. c. If the system can tolerate 1 isochronous period latency and only needs to queue up 1 async packet per isoc cycle per node, then this workaround is recommended. Sync up all Async requests to the start (or end) of the isochronous cycle. This may be done using the cyst (or cydne) interrupt (or terminal) and will effectively cause the async LREQs to occur at appropriate times to avoid the error. Use the following steps: 1. Write quadlet 1 to n-1 of a packet to the ATF 2. Clear all interrupts (if using interrupts) 3. Wait until isoc cycle start (or cycle done) 4. Write final quadlet to ATF d. If the receiving node is a TSB12LV31 or TSB12LV21 device, the receiving node link will just go into an idle state when the error occurs. In this case, the sending node just needs to retry the async packet send. e. If the receiving node is a TSB12C01A device, it will not handle the error condition gracefully. The symptoms of the error condition are similar, however the receiving node will be hung-up and not able to receive packets until the receiver is reset. The following procedure should detect a TSB12C01A node that has locked up and then reset the hung link: 1. When queuing up an async packet, load all but the final quadlet into the ATF 2. Clear the interrupt register (RxDta and TxRdy will be used in this sequence) 3. Write the final quadlet into the ATF 4. Monitor the RxDta interrupt and TxRdy interrupt If the RxDta interrupt occurs (a packet is being received into the GRF) before the TxRdy interrupt (the ATF packet was transmitted and the acknowledge was received), then the node is hung up and needs to be reset. The node may read the packet from the GRF, it was probably received correctly but the ACK was never sent 5. The node may then reset the receiver (control register bit 11) to free up the node The packet in the ATF should not need to be reloaded, the TSB12C01A should issue another fair request LREQ to the TSB14C01.
2
Printed in U.S.A.
POST OFFICE BOX 655303
* DALLAS, TEXAS 75265
SLLS280 - SEPTEMBER 1997
SLLS180
IMPORTANT NOTICE Texas Instruments (TI) reserves the right to make changes to its products or to discontinue any semiconductor product or service without notice, and advises its customers to obtain the latest version of relevant information to verify, before placing orders, that the information being relied on is current and complete. TI warrants performance of its semiconductor products and related software to the specifications applicable at the time of sale in accordance with TI's standard warranty. Testing and other quality control techniques are utilized to the extent TI deems necessary to support this warranty. Specific testing of all parameters of each device is not necessarily performed, except those mandated by government requirements. Certain applications using semiconductor products may involve potential risks of death, personal injury, or severe property or environmental damage ("Critical Applications"). TI SEMICONDUCTOR PRODUCTS ARE NOT DESIGNED, INTENDED, AUTHORIZED, OR WARRANTED TO BE SUITABLE FOR USE IN LIFE-SUPPORT APPLICATIONS, DEVICES OR SYSTEMS OR OTHER CRITICAL APPLICATIONS. Inclusion of TI products in such applications is understood to be fully at the risk of the customer. Use of TI products in such applications requires the written approval of an appropriate TI officer. Questions concerning potential risk applications should be directed to TI through a local SC sales office. In order to minimize risks associated with the customer's applications, adequate design and operating safeguards should be provided by the customer to minimize inherent or procedural hazards. TI assumes no liability for applications assistance, customer product design, software performance, or infringement of patents or services described herein. Nor does TI warrant or represent that any license, either express or implied, is granted under any patent right, copyright, mask work right, or other intellectual property right of TI covering or relating to any combination, machine, or process in which such semiconductor products or services might be or are used.
Copyright (c) 1998, Texas Instruments Incorporated


▲Up To Search▲   

 
Price & Availability of SLLS280

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