Q1: What is the function of the Vcc5V pins on certain link layer devices (TSB12LV31, TSB12LV41)?

The Vcc5V pins only provide 5V-interface compatibility. They clamp the PHY/link interface pins on the link to 5V via a diode. The 3.3V supply pins supply all operating current.

TSB12C01A

Q1: When connecting the TSB12C01A to a micro-controller, is pin 7 the MSB and pin 0 the LSB? (For ADDR[7:0] and DATA[31:0])

The MSB/LSB depends on the micro-controller. IEEE 1394 is Big Endian in both a bit and byte sense. The most significant bit is bit 0 and the most significant byte is byte 0. The correct approach for addressing is to connect the most significant bit of the micro-controller to the most significant bit of the TSB12C01A. This is true for both addresses and data. The most significant DATA bit of the TSB12C01A is DATA [0]. The most significant address bit of TSB12C01A is ADDR [0]. To do data invariant endianness matching between a Little Endian processor and the Big Endian TSB12C01A, the most significant bit of the micro-controller is connected to the most significant bit of the TSB12C01A. However, the byte addressing will be lost. Address invariant endianness matching will require external circuitry and will preserve the byte addressing but lose the 32 bit data sequence.

Q2: Since the TSB12C01A internal registers are 32 bit wide, should the 2 LSBs of the address be grounded at all time?

Yes, per the data sheet (Table 1-1) the 2 least significant bits (ADDR [6,7] at pins 29 and 30) should be grounded.

TSB12LV21A

Q1: What is the value of pin 136, which is labeled LINK_ISO on the TSBKPCI schematic? Should it be pulled up/down with resistors?

Pin 136 on the TSB12LV21A was a provisional input terminal to support Annex J isolation. Since this feature was not implemented, this input is required to be strapped to Vcc for normal operation. Pin 136 is labeled Vcc on the data sheet. A pull-up resistor can be used but is not mandatory since pin 136 is input only. It may be tied directly to Vcc.

Q2: If the PCI clock is reduced from 33.33MHz to 16.67MHz what effect does this have on the Link and 1394 communications through it? What if the PCI clock was changed from 16.67MHz to 33.33MHz?

The PCILynx should function correctly while the PCI clock is operating at 16.67MHz. The problem will be that data rates through the PCI port will be cut by slightly more than half. This means that the PCI side of the internal PCILynx FIFO will be emptied at half the rate it was before, while it is being filled on receiving from 1394 at the same rate. If you are "on-the-edge" now with your FIFO buffering you will need more FIFO allocated to buffer incoming packets to ensure there is not an over-run of the receive FIFO. The timing on the 1394 bus side is controlled by the SCLK that must be run at 49.152MHz. There is a limitation of approximately a factor of 6 between SCLK and PCI clock (BCLK). With SCLK at 49.152MHz we have been recommending a minimum of 9MHz for BCLK.

Q3: What effect does a stopped PCI clock have on the Lynx?

What effect does a stopped PCI clock have on the Lynx? This may hang up the PCI bus. There must be a PCI clock available to the PCILynx at all times during normal operation to function correctly. However, you may be able to turn off the PCI clock if the PCI bus is off or during a bus idle. Note: The PHY clock must run continuously.

Q4: When restarting a stopped clock will the Lynx pick up where it left off or does it need to be reset?

It will need to be reset.

Q5: When the TSB12LV21 is only running on the PHY clock can it toggle the GPIO pins when it receives a message addressed to it?

No. Receiving data from the 1394 bus into the PCI clock domain requires an active PCI clock. Note however that there is a hardware "link-on" signal available out of the PHY that does not require the link to be active. This could be used to wake up a powered off link or other hardware using a link-on packet from the 1394 cable.

Q6: What is TSB12LV21A pin 125 function in the original design?

Pin 125 is gpio_data0. This GPIO is used by software to set the IRM and BM contender bit on the PHY.

Q7: What is the power consumption of a TSB12LV21A?

Measurements from the TSBKPCI EVM indicate power consumption of 0.35W for the PCILynx and support pull-ups. Total power consumption including the 3.3V regulator and serial EEPROM is approximately 0.55W.

Q8: Do pins 126, 127, 131 and 132 on the TSB12LV21A need pull up resistors?

If the ZV (Zoom Port) signals (pins 126, 127, 131, 132) are not used in the design, then pull-up resistors are required. Since these signals are implemented as I/Os for internal test purposes, they must be driven to a known state to prevent floating inputs which can cause excessive power consumption.

Q9: Can the 5V-pins directly connect to 5V-power supply on the TSB12LV21A? Can the 3V-pins directly connect to 3V-power supply? Can the GND-pins directly connect to GND?

The PCILynx power supply and ground pins can be directly connected to the available power supplies and ground planes. Following good design practices, bypass capacitors are recommended for both the 3V and 5V supply pins. Typically a mix of 0.001uF and 0.1uF low-inductance ceramic chip capacitors will work. The above answer assumes no galvanic isolation. If galvanic isolation is being implemented then there are other considerations, which must be addressed with respect to the PHY-link interface that may affect the power distribution design. See the TI Galvanic Isolation App Note.

TSB12LV31

Q1: Does special care have to be taken if the isochronous port is not being used?

Since the Isochronous port is I/O, it is recommended that the port I/O’s be pulled down through resistors.

Q2: Will the TSB12LV31 link chip resolve any setup or hold violations or is there a danger of latch up?

The TSB12LV31 link chip will not resolve setup and hold violations. Latch up is possible.

Q3: Which pins are CMOS, 5V, or TTL tolerant?

All inputs on the TSB12LV31 are 5V tolerant and TTL compatible. The compatibility is engaged by connecting the Vcc5V pins (pins 12, 37, 62, 87) to 5V. All outputs are CMOS. Please insure that the interface logic that you use meets the VOH, VOL, VIH, and VIL requirements in section 6.2 and 6.3 of the TSB12LV31 data book.

Q4: Which clock cycle is the data strobed in when the TSB12LV31 is in handshake mode with the micro-controller?

It could be several BCLK’s before the data is latched by the TSB12LV31, due to speed differences between BCLK and SCLK. The important thing is that the micro-controller holds the data until /MCA is set low by the TSB12LV31.

Q5: What are the characteristics of CYCLEIN?

CYCLEIN should be an 8KHz clock with a 50% duty cycle. It can be a free running clock. CYCLEIN is only used if the node is Cycle Master and must synchronize the isochronous cycles to an external clock.

Q6: What is the difference in TSB12LV31 operation in 200/100 Mbps modes?

When operating at 200Mbps, TSB12LV31 will request new bytes on every 25MHz ISOCK clock. The ISORW stays high for the entire packet. When operating at 100Mbps, TSB12LV31 will request 1 byte on every ISOCK clock for 4 consecutive clocks (1 quadlet) and then wait for 4 ISOCK clocks before requesting the next 4 consecutive bytes. You should make the data available on every ISOCK clock at 100Mbps operation. The ISORW goes low between quadlets.

Q7: Is the 16-bit micro-controller Handshake Mode a standard asynchronous interface?

It is not completely asynchronous. Some of the registers in the TSB12LV31 are accessed via SCLK while others are accessed via BCLK. Therefore, BCLK must be used for micro-controller write and read operations.

Q8: What is Icc max for TSB12LV31?

Icc max is 54.3 mA when loaded. This is with high speed switching on all 4 data lines, 3.6V Vcc, and low temp.

Q9: Can the TSB12LV31 link layer device perform the function of Isochronous Resource Manager?

Yes, the TSB12LV31 can perform the functions of Isochronous Resource Manager (IRM). The IRM is typically part of the "firmware" or software of the 1394 serial bus. The software allocates bandwidth and channels. (Please sees section 8.3.1.5 of the IEEE 1394-1995 standard for more explanation.) However, the TSB12LV31 can accelerate the IRM’s processes by receiving and checking self-id packets in hardware.

Q10: Can the TSB12LV31 link layer device perform the function of Bus Manager?

Yes, it can. However, the TSB12LV31 is not typically suitable for Bus Manager. Like the IRM, the Bus Manager is also a function of 1394 software. However, unlike the IRM, the Bus Manager is required to hold all self-id packets. This may require a large FIFO. The GPLynx FIFO is small and limits the number of Self-ID packets it can hold. This typically makes it an unsuitable bus manager.

Q11: Can the TSB12LV31 link layer device perform the function of Cycle Master?

Yes, the TSB12LV31 can perform the functions of cycle master. No additional resources are needed. Turn on the cycle timer and enable the cycle start packets when root, or use the CMOK (Cycle Master Candidate) and CM Auto (Auto Set Cycle Master) bits at the Control Register (address 08h) to do this automatically.

Q12: What is the concept of packets and blocks relating to isochronous data for TSB12LV31? Why are they important?

This can be understood by thinking of using the GP Lynx for a 1394 camera. It is primarily concerned with transporting data by frames. Each line of the frame may be known as a "packet." The entire frame may be considered to be a "block". Thus a certain number of packets will constitute a block. The concept of blocks and packets is important for TSB12LV31 bus negotiations. The device will only negotiate for the bus when data has to be sent. Once it has sent a packet during a single isochronous cycle it releases the bus for other nodes to use. The TSB12LV31 will keep negotiating for the bus every isochronous period until the entire block is sent.

Q13: What is the difference between the Isochronous Header Register field “Packet Data Length” (at address 5Ch bits 0-15) and the Isochronous Control Register field “Quads per Packet” (at address 54h bits 22-31)? Does the TSB12LV31 need both of these?

Yes, the device needs both "Packet Data Length" and "Quads per Packet". The "Packet Data Length" is used in the creation of the transmitted isochronous packet header. The packet header tells how much data is sent. The "Quads per Packet" indicates the number of quadlets per packet being transmitted out on the Iso port. “Quads per Packet” sets up the isochronous port for transmitting data. Both of the numbers must represent the same amount of data, with the Packet Data Length being four times the Quads per Packet (1 Quad = 4 bytes).

Q14: How is isochronous data sent on 1394 via TSB12LV31?

The first step in isochronous transmission is for IDATARDY (Iso Data Ready) to go high. IDATARDY is driven by an outside data source. It signals to the TSB12LV31 that the outside data source has a block of data ready to transmit. Next the ISORST (Iso Data Reset) is driven by the TSB12LV31. It can be asserted to reset address counters on the external interface, such as reseting the address of a camera to the top of a picture frame. Next IDMDONE (Iso Data Mover Done) is driven low by TSB12LV31. IDMDONE will go low to indicate that the TSB12LV31 sees IDATARDY high. TSB12LV31 will also preread a quadlet of the data, and will signal the PHY to arbitrate for the bus. IDMDONE does NOT indicate that the bus has been successfully arbitrated. IDMDONE will stay low until the whole block of data has been transmitted. Because of the "preread," byte 0 must be placed into the link before IDMDONE is low. Then the link will send a request for the PHY to arbitrate for the bus. Once the node gets the bus, the ISORW (ISO Read/Write) is driven by TSB12LV31. It indicates when a packet is being transmitted. Transmission of the data must be at full speed, since there are no buffers or FIFOs. Because of the "preread" a "dummy" quadlet must be transmitted at the end of each block. At 200 Mbps operation, ISORW will remain high during the transmission of each packet. At 100 Mbps operation, ISORW goes high for the first quadlet of data and then low for a quadlet period. It will then go high for the second quadlet and low for a second quadlet period. This continues until the entire packet is transmitted. When a complete block of data has been trasmitted, the TSB12LV31 will drive IDMDONE high. The external circuitry should drive IDATARDY low in response.

Q15: Which of the data book timing diagrams are suitable for isochronous data?

Refer to both Fig. 2-10 (for logical flow) and Figs. 6-3, 6-4, 6-5 (for transmit timing diagrams) for isochronous data transmission. Figure 6-3 is a transmit timing diagram for phase 1. Phase 1 is the “pre-read” start of data a block being sent. Figure 6-4 is a transmit timing diagram for phase 2. Phase 2 refers to timing while the data block is being sent. Figure 6-5 is a transmit timing diagram for phase 3. Phase 3 refers to timing diagrams at the end of the block of data (the last packet within a block.)

Q16: Can the R/W and CLK pins for the IsoPort (ISORW and ISOCLK) interface be configured as inputs?

No. The ISOCK and ISORW signals on the TSB12LV31 device can not be configured as inputs. The TSB12LV41 device has a more flexible data port that is designed to do this.

Q17: Are there any schematics showing the interface of a TSB12LV31 to one of the popular micro-controllers such as an Intel 8051 or a Motorola 68xxx?

The TSB12LV31 is general-purpose link layer. It is not designed to interface to a specific micro-controller. In our starter kit, it is connected to a TI TMS320C52 DSP. The TSB12LV31 will interface directly with Motorola 68000 processors and the Sony SPD700 processor (and other processors with similar timing). Other processors may require hardware and/or software adjustments in order to interface with the 12LV31.

Q18: Can I connect the PCILynx and GPLynx together through their 1394 ports to get packet transfer?

Yes, a connection between the PCILynx and GPLynx EVMs is a great way to get packet transfers. Having the 3A Bus Analyzer is the best way we have seen to watch the packet traffic on the 1394 bus. The GPLynx EVM has an RS-232 monitor program that will allow the sending/receiving of packets on the 1394 bus. You can have a PCILynx hooked up on the other end of the cable and it should be able to capture the packets sent and send packets to the GPLynx as well.

Q19: On the GPLynx, can I receive all iso data at the iso port and all asynchronous data into the GRF?

It is possible to receive Iso Data at the Iso Port and Async data at the GRF. However, when the IRCVALL bit is set (Receive All Iso Data), all isochronous data is sent to the Iso Port AND the GRF FIFO. There is a danger of overflowing the FIFO if the application does not pull data from the FIFO fast enough. To recieve all iso data at the iso port, the following bits must be set: Receive Enable (RxEn) at the control register (@08h) Isochronous Mode (IsoMode) at the Isochronous Mode Register (@58h) IRcvAll bit at the IsoPort Number Register (@18h) IRP1En or IRP2En at the Control Register must be turned OFF Note that asynchronous data is automatically sent to GRF.

TSB12LV41

Q1: What applications is the MPEG2Lynx designed for?

The MPEG2Lynx was designed for the Consumer Electronics environment with an emphasis on MPEG2 (DVB) or DSS data transmission and reception. It operates at speeds up to 200Mbps. Specifically, the MPEG2Lynx was designed to use with systems such as Set-Top Boxes, Digital TVs, and Digital VCRs. It automatically formats MPEG2 data for transport over 1394 according to the IEC61883 specification. The MPEG2Lynx also has several features which make it attractive to systems which don't require MPEG2 transport. The MPEG2Lynx transports asynchronous and isochronous data at speeds up to 200Mbps. Its large FIFOs (8Kbytes) are useful for any system that needs to buffer large asynchronous or isochronous packets due to system latencies. The MPEG2Lynx also has full duplex capability on its Bulky Data Interface. This is useful for any system that needs to support simultaneous transmit and receive of data.

Q2: What kinds of data types does the MPEG2Lynx support?

The MPEG2Lynx supports MPEG2 (DVB) transport over 1394 according to the IEC61883-4 standard. The MPEG2Lynx also supports DSS transport over 1394 according to the 1394 Trade Association GuideLines for transporting DSS (Proposal by Sony). In addition, the MPEG2Lynx support asynchronous and isochronous transport.

Q3: What are the data interfaces for the MPEG2Lynx?

The MPEG2Lynx has three different data interfaces. Phy-Link Interface: The MPEG2Lynx interfaces seamlessly with the TSB21LV03A 200 Mbps physical layer device. It also interfaces with the TSB41LV0X family of 400Mbps physical layer devices. However, the MPEG2Lynx can only operate up to 200Mbps. Microprocessor Interface: The MPEG2Lynx is designed to interface seamlessly with three different types of microprocessors: Motorola 68000, Intel 8051, and the TI TMS320AV7000 family of ARM processors. This interface is used to setup registers in the link layer, respond to requests, and handle interrupts. It can also be used to transmit and receive MPEG2, isochronous, or asynchronous data. However, isochronous and MPEG2 transmission is not encouraged through this port due to the latency of microprocessor accesses. Bulky Data Interface: The MPEG2Lynx provides the Bulky Data Interface (BDIF) as a high-speed port for high bandwidth applications, such as video. It can handle data through-put rates of up to 20Mbytes/sec. The Bulky Data Interface (BDIF) is capable of transporting asynchronous, isochronous, and MPEG2 data simultaneously between the application and the link layer device

Q4: How do I setup the MPEG2Lynx for isolation?

When using TI's Bus Holder Phy/Link Isolation solution with the TSB12LV41, there are several issues that must be considered by the designer. TI's Bus Holder solution for isolation requires decoupling capacitors on all signal lines between the physical layer and link layer devices. (Please reference TI's Serial Bus Galvanic Isolation Application Report, Literature Number SLLA011 for more information on the topic of isolation.) To isolate the TSB12LV41 and physical layer device, the /ISOLAT (pin 29) is pulled low and the phy-link interface is capacitively coupled. Pin 29 (/ISOLAT) on the MPEG2Lynx is an input used to detect whether or not isolation is present. During power up this pin's logic level is sampled. If it is low, then the MPEG2Lynx enables the internal bus holders to be used when isolation is present between the Link and PHY. If it is high the internal bus holders are disabled and the PHY and Link should be directly connected (no isolation). The MPEG2Lynx must be reset in order to change the isolation mode. For more information on 1394 galvanic isolation, please consult the Galvanic Isolation Application Note, Literature Number SLLA011 and Appendix C of the TSB12LV41 data manual.

Q5: What types of microprocessor are supported?

The host is used to access the registers in the MPEG2Lynx, to transmit/receive control asynchronous packets, and access the on chip FIFOs. The MPEG2Lynx has a host port that is interfaces seamlessly with three different types of microprocessors: Motorola 68000, Intel 8051, and TMS320AV7100 (ARM processor). Other processors can be used with the MPEG2Lynx as long as they meet the timing specified by one of the above modes.

Q6: What is the relationship between CS and RDY on the microprocessor port?

The MPEG2Lynx will provide a RDY signal for each Chip Select (CS) from the microprocessor. The "RDY" signal form the MPEG2Lynx is the handshake signal used on the microprocessor port. It is interpreted as either "ready" or "wait" depending on the microprocessor mode selected. When the MPEG2Lynx is in Blind Access Mode there is no RDY signal generated. For TMS320AV7100 mode, the 12LV41 will only respond with a RDY to the LAST byte or doublet that fills up the buffer for a Write operation. In other words, if you are in Word access mode (16-bit wide data bus), then the second write cycle will receive a RDY acknowledge signal. If you are in byte access mode (8 bit data bus then the 4th write will receive a RDY acknowledge. The first three writes only require that the CSZ input be low for a minimum time (see attached timing diagrams). For TMS320AV7100 reads, the FIRST byte or doublet read cycle will receive an acknowledge. The other's will not receive an acknowledge. For Motorola 68000 mode EACH read or write cycle will be terminated with a RDY acknowledge. For the 8051 mode there is no acknowledge.

Q7: What interrupts are signaled on the INTZ pin? Can I leave this signal unconnected?

The interrupts in registers 10h and 18h can be output on the /INT line. Whenever a particular interrupt bit in either register 10h or 18h is unmasked (it's corresponding bit in the Interrupt Mask register is set to 1), the /INT will go low whenever that event occurs. These interrupts are used to signal the microprocessor that an event or error has happened. It is suggested that you connect this pin to your processor's interrupt input. For more information concerning how interrupts are output to the /INT pin, please see section 4.3.11 of the MPEG2Lynx datasheet (Literature Number SLLS276A).

Q8: If I am not using the TMS320AV7100 mode, what should I do with BCLK?

This depends on the version of MPEG2Lynx silicon that you have. If register 00h (Version Register) reads "0071 1018hex," they you should tie BCLK to SCLK when not in AV7100 mode. If register 00h (Version Register) reads "0071 1539hex", then you should tie BCLK to ground.

Q9: Is "Blind Access Mode" supported when interfacing TSB12LV41 with the Motorola 68000 microprocessor?

No. The Motorola 68xxx type processors MUST handshake. The 68xxx processor must see an acknowledge back from the Link to end a read or write cycle. The 68xxx interprets this acknowledge as "data on the bus is ready" and reads this data, or in the case of a write, interprets the acknowledge as "data has been written OK". In Blind Access mode, the TSB12LV41 provides no handshake signal. The RDY signal (interpreted as DTACKZ for 68xxx) stays high during Blind Access mode. If the 68xxx attempted to read from the TSB12LV41 when it had been setup for Blind Access mode then it would interpret the DTACKZ as "data is ready on the bus" and grab the wrong data.

Q10: How is the 12LV41 set up for the Intel 8051 8-bit processor?

The AD[0] pin on the 8051 port 2 should be connected to DATA [7] on the TSB12LV41. The host must have 9 bit address resolution to access all of the configuration registers (512) inside the TSB12LV41

Q12: What is the maximum write and read cycle latency when in 68000-handshake mode?

The write latencies are: 1st quadlet write = 5 BCLK cycles Consecutive writes to the same quadlet address = 17 BCLK cycles The read latencies are: 1st quadlet read = 17 BCLK cycles Consecutive reads from the same quadlet address = 5 BCLK cycles For example: When using Word access mode, you must do two actual writes on the microprocessor bus to do a complete write to a register in the TSB12LV41 (all internal registers are 32 bits wide). The 16 bit data from the first write is loaded in a holding register until the next 16 bit data value is loaded from the next write, then this 32 bit value is actually written into the appropriate register. The reverse is true for reads.

Q13: How should I use the Bulky Data Interface (BDIF)?

The Bulky Data Interface (BDIF) was designed to handle high-speed data. It is the "high speed port" of the device, and all MPEG2/DSS data should be routed through the BDIF and it's adjoining 8k byte FIFO. The BDIF is configurable to meet a variety of system requirements. Unidirectional Mode: The BDIF can be configured to have 2 unidirectional 8 bit interfaces. The BDIO[7-0] port is used to transmit data, and the BDO[7-0] port is used to receive data. The application must supply both the BDIO and BDO ports with clocks. Bi-directional Mode: The BDIF can be configured to have a bi-directional 8-bit interface. Data is both transmitted and received at the BDIO[7-0] port. A clock must be supplied to both the BDICLK and BDOCLK, but the frequencies of the two clocks must be the same. Asynchronous Mode: The BDIF can be configured to operate asynchronously from the application with 2 unidirectional 8-bit interface. A clock must be provided for BDICLK and BDOCLK, but this clock does not need to be synchronous with the data at the application interface. The system designer may use a clock from any source, but an NCLK ( 24.576 MHz) can be supplied from the STAT0 pin on the MPEG2Lynx device for convenience.

Q14: What are the BDIF control signals?

For the unidirectional and asynchronous modes, the BDIF control signals include BDIF[2-0], BDOF[2-0], BDIEN, BDOEN, BDOAVAIL, and BDIBUSY. Signal I/O Description BDIF[2-0] Input Format bus for data input on BDIO[7-0] BDOF[2-0] Output Format bus for data output on BDO[7-0] BDIEN Input Qualifies data on writes to Bulky Data Interface (BDIO bus enable) BDOEN Input Qualifies data on reads from Bulky Data Interface (BDO bus enable) (Not used in BDIF Mode B) BDOAVAIL Output BDO has data available for the application to read. Should be used to gate BDOEN. BDIBUSY Output Signals busy on the BDIO port for writes. The BDIO FIFO is full. For the bi-directional mode, the BDIF control signals include BDIF[2-0], BDIEN, BDOEN, BDOAVAIL, and BDIBUSY. BDIO has data available for the application to read. Should be used to gate BDIEN. Signal I/O Description BDIF[2-0] Input/Output Format bus for data input on BDIO[7-0] OR format bus for data output on BDIO[7-0] BDIEN Input Read/Write Enable. BDOEN Input Read/Write Control BDOAVAIL Output BDIBUSY Output Signals busy on the BDIO port for writes. The BDIO FIFO is full.

Q15: What clock rate should I use on the Bulky Data Interface (BDIF)?

The maximum through put of the BDIF is 20Mbytes/sec. This means for an application that is supplying data to the BDIF (transmit) OR reading data from the BDIF (receive) every clock cycle, the maximum clock frequency is 20MHz. It is possible to use higher clock rates, but data can not be read in on every clock cycle.

Q16: What does Full Duplex mean?

Full duplex means we have the capability of transmitting AND receiving data simultaneously. For example, you could be reading data out of the Bulky Data Iso Receive FIFO via the Bulky Data Interface Output port while at the same time transmitting data out of the Bulky Data Iso Transmit FIFO via the Bulky Data I/O port. Also, since there are separate receive and transmit FIFOs for asynchronous, isochronous, and MPEG2 data, the MPEG2Lynx can receive and transmit data over 1394 within one isochronous cycle.

Q17: Do I need an external FIFO for the Bulky Data Interface?

The MPEG2Lynx has an internal 8k Byte FIFO for the Bulky Data Interface. As long as the FIFO does not overflow, you will not need an external FIFO on the Bulky Data Interface.

Q18: For Asynchronous and Isochronous data received into the Bulky Data FIFO what is "an entire packet of data"?

An Asynchronous or Isochronous packet contains a data CRC at the end of the packet. The link determines if the packet is valid and confirms the packet into the FIFO. This is the definition of an "entire packet of data."

Q19: Do I need to format the data before I send it to the MPEG2Lynx Bulky Data FIFO for transmit?

No. The MPEG2Lynx can be configured to automatically add all the headers necessary to send MPEG2/DSS, isochronous, or asynchronous data across the 1394 bus whenever transmitting from the Bulky Data Interface. The MPEG2Lynx is designed to meet the IEC61883 standard for transmitting MPEG2 data across 1394 by automatically inserting CIP (Common Isochronous Packet) headers, timestamps, and the 1394 isochronous header. All of these can be programmed one time in internal MPEG2Lynx registers. The MPEG2Lynx will also automatically insert headers necessary for isochronous and asynchronous transmit. The MPEG2Lynx can also be programmed to allow the application to supply all 1394 transmit headers.

Q20: Will I need to process the data when I receive it from the MPEG2Lynx from the Bulky Data FIFO to remove the 1394 header information?

No. The MPEG2Lynx can be configured to receive either fully formatted data (data, headers, trailer) or stripped data (data only) to the application when receiving from the Bulky Data FIFO.

Q21: What is BDIBUSY used for?

BDIBUSY is an output from the TSB12LV41, which indicates that the Bulky Data FIFO being written to is full and cannot service a requested write operation. Once BDIBUSY goes active, no more data will be written into the full FIFO until data is removed either by transmitting via the phy-link interface or flushing the full FIFO.

Q22: If we are not going to use the BDO should BDOCLK be tied high or low?

The BDOCLK should be tied low if it is not used.

Q23: How much power does the TSB12LV41 consume?

Please reference section 7 in the TSB12LV41 Data Manual for information on power dissipation.

Q24: What are the pin capacitances on the MPEG2Lynx?

For the TSB12LV41, Input capacitance on input terminals ~1.65pF Input capacitance on bi-directional terminals ~7.2pF Output capacitance on output terminals ~4.9pF

Q25: What should I do with the JTAG test port?

MPEG2Lynx implements the three required commands for an IEEE 1149.1 JTAG interface: EXTEST, BYPASS, and SAMPLE/PRELOAD.) These signals are for testing the IC during system level production and should not be used for chip level debugging. If you are not using JTAG, then the only requirement for the JTAG port is that the pins (TRST, TMS, TCK, TDI, and SCKEN) are tied low through a 10Kohm resistor. If you are planning to implement JTAG, then you must include external pull-ups on the JTAG signals and correctly initialize the JTAG port.

Q26: What does pin 11 (CNTDR) do? How is pin 11 related to bits 5 and 6 in register Ch (CTDROUT and CTDRIN)?

Pin 11 on the 12LV41 (CNTNDR) is used to indicate contender status for 1394 bus manager. This pin will connect to the C/LKON pin of the attached Physical layer device to indicate to the Phy that the status of the "contender" bit in the Self-Id packet. The CNTNDR pin on the 12LV41 is both input and output. Upon reset the device will read the CNTNDR pin as an input and will load bit 05 of the Link Control Register (address 0Ch) with the value read. The host can then either overwrite this value at bit 05 or output the externally read value to the Phy. Bit 06 of register 0C is CNTNDR pin input/output status. If bit 06 is "1" then pin 11 is an input, if it a "0" then pin 11 is an output.

Q27: The MPEG2Lynx has VCC+5V pins for 5V tolerance. Do I need to use these if my system is 3.3V only?

The MPEG2Lynx has a Vcc+5V input which, when connected to a +5V supply, allows for 5V tolerance on its inputs. If you are not driving any MPEG2Lynx inputs with 5V logic then you can connect this pin to the 3.3V supply (VCC). The MPEG2Lynx output voltage levels are always LVTTL (3.3V).

Q28: What is the "automatic self id verification" of TI's TSB12LV41?

The 12LV41 checks the Self-Id Inverse field (2nd quadlet of a Self-Id packet) to verify that the self-id was received correctly. If the self-id was received correctly, the trailing acknowledge in the receive FIFO will have an ACK code of "0001b." The MPEG2Lynx also automatically determines the total number of nodes present on the 1394 bus, the node number of the IRM, and determines whether it is the root node. It stores all of this information in the Bus Reset Data Register (register 48h). If the self-id was received incorrectly, the trailing acknowledge in the receive FIFO will have an ACK code of "1101'b." In this case, a more detailed account of the error can be decoded from bits 01-02 BRERRCODE in register 4Ch.

Q29: Are the Isochronous Resource Manager and Bus Manager functions present in TSB12LV41?

The TSB12LV41 must have the appropriate software to be IRM or BM according to the IEEE 1394-1995 standard. However, the TSB12LV41 does offer some IRM and BM functionality in hardware to aid the software. Functions such as determining the number of nodes present and automatically determining if it is root are built into the TSB12LV41. The TSB12LV41 will also collect all Self-Id's in the Bulky Data Async Receive FIFO on power-up to aid with Bus Master functions.

Q30: Is the Cycle Master function present in the TSB12LV41?

Yes, the TSB12LV41 is capable of being cycle master. The cycle master function is set in register Ch. When the CYCMSTREN bit in register Ch is set to 1, the link layer functions as cycle master for the 1394 bus. This bit is automatically cleared to 0 at the when the link detects the start of a BUS_RESET. Software can write to this bit depending on the setting of the CMAUTO and CMSTR bits. The CMSTR bit is used in conjunction with the CMAUTO bit by the application software for enabling the cycle master auto select/deselect mode. When a sub-action gap occurs and the local phy is not root then CMSTR is cleared to 0. The following table shows the setting of the CYCMSTREN bit as a function of CMSTR and CMAUTO. CMSTR CMAUTO Autoselect/Deselect Mode 0 X CYCMSTREN can be set or cleared directly by software. 1 0 CYCMSTREN is held cleared to 0 1 1 Enabled. CYCMSTREN bit is set to 1 if local phy is root or else set to 0.

Q31: How does the MPEG2Lynx perform "timestamping" for MPEG2 transport over 1394?

The IEC61883 specification defines a method of compensating for the latency introduced in the transport stream by the 1394 transmit and receive functions. The way "timestamping" works is the transmit 1394 node will add a 25 bit timestamp to each 188byte MPEG2 cell prior to transmitting this MPEG2 cell onto the 1394 bus. This "timestamp" is equal to the local Cycle Timer Register value (CYCLE_TIME register as defined in IEEE1394-1995 section 8.3.2.3.1) plus an offset. The offset should be greater than the delay from the input of the TSP to the transmit 1394 node to the transport stream output from the receiving 1394 node. The receiving node will use this timestamp to determine when to output the MPEG2 cell to the application. For more information on timstamping, please see section 3.3 in the MPEG2Lynx Datasheet. (Literature number SLLS276A)

Q32: Explain 12LV41 "auto-packetization" for Asynchronous and Isochronous packets?

The 12LV41 has the capability to automatically insert the Async and Iso headers as defined by the 1394-1995 specification. Programming several registers using the microprocessor interface creates these headers. The Async or Iso packet will be sent automatically once the last quadlet is written into the transmit FIFO.

Q33: How is TSB12LV41 set up to autopacketize?

To autopacketize (for asynchronous and isochronous data only): Set up the 12LV41 header registers. For asynchronous data, set up registers 1B0h-1BCh. Use the block transmit format shown in section 3.4.2 of the Data Manual. For isochronous data, set up register 1C0h. Use the block transmit format shown in section 3.5.1. You may put data into FIFO continuously. For accesses to the Bulky FIFO from the MP/MC port: When using autopacketization, every quadlet of asynchronous data except the last should be put into the BATXFC (Asynchronous Transmit FIFO First and Continue) register at address 10Ch. The packet will be transmitted once the last quadlet is written into the FIFO using the BATXLS (Asynchronous Transmit FIFO Last and Send) at address 110h. Similarly, for isochronous data, all quadlets except the last should be placed into the BITXFS (Iso Transmit First and Continue) register at address 134h. The packet will be transmitted once the last quadlet is written to the BITXLS (Iso Transmit Last and Send) register at address 138h. Please see section 3.1.5 of the MPEG2Lynx Data Manual for more information. For accesses to the Bulky FIFO from the Bulky Data Interface: When using autopacketization, every quadlet of asynchronous data except the last should have a Bulky Data Format Code of "011'b." The packet will be transmitted once the last quadlet is written into the FIFO using a Bulky Data Format Code of "111'b". Similarly, for isochronous data, all quadlets except the last should be written to the Bulky Data FIFO with a Bulky Data Format of "010'b." . The packet will be transmitted once the last quadlet is written to the Bulky Data FIFO using a Bulky Data Format Code of "110'b." Please see section 3.1.5 and 4.1.1 of the MPEG2Lynx Data Manual for more information. Be sure to monitor the size of the FIFO to insure it is not over-run. The status for the amount of FIFO available for asynch is register BAAVAL (Bulky Asynchronous Available Register) at address 108h. The status for the amount of FIFO available for isoc is register BIAVAL (Bulky Isochronous Available Register) at address 130h. Make sure that the number of bytes in the transmit packet equals the number of bytes in the header quadlet. If they do not match, the packet will still be transmitted, but the receiving node will receive a data CRC error.

Q34: Does the MPEG2Lynx perform byte padding?

Since all packets on 1394 must be sized in multiples of four bytes (quadlets), the MPEG2Lynx will perform byte padding for asynchronous or isochronous transmit through the Bulky Data FIFO only. If the data needs to be quadlet aligned, then the last quadlet of the packet is padded with zereos and transmitted. Byte padding will only occur if the last quadlet is short 1, 2, or 3 bytes. For MPEG2/DSS data, the MPEG2Lynx will not perform byte padding. The MPEG2/DSS packet is sent whenever the amount of data in the Bulky Data FIFO reaches the programmed transmit class. The transmit class sizes range from ¼ of an MPEG2 cell per packet to 5 MPEG2 cells per packet. Otherwise an empty packet is sent every isochronous cycle until enough data is in the FIFO.

Q35: How can I setup the MPEG2Lynx to filter on specific isochronous streams?

The MPEG2Lynx has 2 methods by which it can filter incoming Iso packets to determine if they are received into either the MPEG2/DSS Receive FIFO or the Bulky Iso Receive FIFO. It can filter on either the Tag/Iso channel or just the Iso channel. Recall that the MPEG2Lynx has 8 separate Iso receive "ports". Each port can be programmed to filter on a different channel and/or tag. The receiving channel for these ports can be programmed in registers 20h and 24h. The comparator TAG values can be set in register 148h. Note that Port 0 is used to receive ONLY MPEG2/DSS packets. These packets MUST have a Tag = 1 to be received into the MPEG2/DSS receive FIFO.

Q36: In the data sheet, the ACTFS register at addr 44h has bits described as "almost full or almost empty." What does "almost full or almost empty" mean?

"Almost full" means that there is one quadlet of space left in the FIFO. Similarly, "almost empty" means that there is one quadlet in the FIFO.

Q37: Does the MPEG2Lynx support automatic retry for asynchronous packets that were busied off?

The MPEG2Lynx supports single phase automatic retry for asynchronous packets transmitted from the Bulky Asynchronous Data FIFO (BATX FIFO) only. The number of retries and number of wait states between retries can be programmed in the Bulky Asynchronous Retry Register (Addr 14Ch.)

Q38: How can I reset the MPEG2Lynx FIFOs?

FIFO Flush Bits ACTX -Asynchronous Control Transmit FIFO Bit 17 (ACTCLR) in register 44h ACRX -Asynchronous Control Receive FIFO Bit 17 (ACRCLR) in register 50h BWRX - Broadcast Write Receive FIFO Bit 17 (ACRCLR) in register 50h BATX -Bulky Asynchronous Transmit FIFO Bit 31 (AXFLSH) in register ECh BARX -Bulky Asynchronous Receive FIFO Bit 30 (ARFLSH) in register ECh BITX -Bulky Isochronous Transmit FIFO Bit 23 (IXFLSH) in register ECh BIRX -Bulky Isochronous Receive FIFO Bit 22 (IRFLSH) in register ECh BMTX - Bulky MPEG Transmit FIFO Bit 27 (MXFLSH) in register F0h BMRX - Bulky MPEG Receive FIFO Bit 26 (MRFLSH) in register F0h BDTX - Bulky DSS Transmit FIFO Bit 27 (DXFLSH) in register F4h BDRX - Bulky DSS Receive FIFO Bit 26 (DRFLSH) in register F4h

Q39: What should I check if I'm having trouble transmitting data?

Make sure the SCLK, BDICLK, BDOCLK, and BCLK(if used) are operational. Try to read/write registers in the MPEG2Lynx. A good register to try and read is the version register at offset 00h. If you are unable to read any registers within MPEG2Lynx, this may point to a micro port interface problem. Make sure there is a cyclemaster on the bus and the cycle timer in enabled within the MPEG2Lynx. The cycle timer enable bit (CYCTIMREN) is programmable in register Ch, bit 22. Make sure the part is setup to transmit correctly. Appendix A gives examples of how to setup the MPEG2Lynx for transmission. Check the interrupt registers at offset 10h and 18h. The interrupts may give clues if the transmitting node is experiencing an error. Examine the phy-link interface. Are any packets (such as cycle start, self-id) being properly transmitted? Are any MPEG2Lynx packets being transmitted at all? Are there errors within the transmitted MPEG2Lynx packet?

Q40: What should I check if I'm having trouble receiving data?

Make sure that SCLK, BDICLK, BDOCLK, and BCLK (if used) are operational. Try to read/write registers in the MPEG2Lynx. A good register to try and read is the version register at offset 00h. If you are unable to read any registers within MPEG2Lynx, this may point to a micro port interface problem. Make sure the MPEG2Lynx is setup to receive correctly. See Appendix B in the MEG2Lynx data sheet for assistance in setting up the part to receive. A common mistake is to not turn on Port 0 for receiving. This is done in register 20h. Check the interrupt registers at offset 10h and 18h. The interrupts may give clues if the receiving node is experiencing an error. Check the phy-link interface. Are packets being received into the MPEG2Lynx? If so, then there is a problem with the configuration of the device or with the interface setups. Make sure that the received data is correctly formatted from the other node. It should contain a valid 1394 timestamp, 2 quadlets of valid CIP headers, and a TAG value of 1. It is possible that either no timestamp was included with the data OR the timestamp did not have the correct offset value. A correctly formatted MPEG2 packet on 1394 will have a timestamp with each MPEG2 cell (every 188 bytes.)