uPD98405 (ATM Integrated SAR Controller)

The bug in the transmit multi-cell transfer function that existed in V3.0 (VER register = 0102H) has been fixed in V3.1 (VER register = 0103H), but what kind of things did this bug cause?

This bug caused transmit cell data to become corrupted (resulting in the transmission of data different from the data that was set), but nothing further, such as transmission stopping, occurs.

Since reception is performed in raw cells, 1 cell corresponds to 1 packet.
In the case of raw cells, I believe that only this configuration is possible, but does this mean that 155 Mbps reception is difficult with raw cells?

Raw cell reception at the full rate (155 Mbps) is not possible due to the architecture of this LSI.
The worst reception pool configuration is that of one buffer per batch, and in order to reduce overhead processing, a configuration where a number of buffers are allocated to each batch is effective.
However, in this case too, the reception performance is only up to approximately half the rate of 155 Mbps.

Transmission at the fastest possible speed (155 Mbps) is aimed for with the following conditions.

Method

PCI mode Single buffer mode 49152-byte buffer size allocated to 1-packet descriptor raw cells Bus master DMA

The maximum speed can be achieved without problem when using a Pentium 200 MHz as the CPU of the host, but this speed cannot be achieved when using a slower CPU. (A speed of approximately two-thirds is achieved.)

What is your advice for handling this matter?
DMA seems to occur intermittently, but what is the processing unit?

The processing time for 1 cell in the uPD98405 is constant, and the uPD98405 operates based on this 1-cell processing time.
When SCLK = 25 MHz, 1-cell processing time = 1.44 us.

Basically, a transmit data read request of the uPD98405 is executed in this 1-cell time unit, and data read is requested at 1.44-us intervals. Per the internal specifications, DMA requests are not possible at lesser intervals. (However, since the 1-cell time in the case of 155 Mbps is 2.7 us, this is a sufficient interval for 155 Mbps transmission.)

The transmission read request interval differs according to the following settings.
 (1) Multi-cell transfer enable (MBL field in the transmission VC table)
 (2) Multi-cell transfer disable

In the case of (1)(for example setting of 5-cell transfer), data read is requested in 5-cell units.
Therefore, the operation consists in reading the data of 5 cells, followed by an interval of idle time, followed by reading of the data of 5 cells, and so on.
The interval of idle time is 1.44 us * 5 = 7.2 us.

In the case of (2), data read is requested in 1-cell units.

When multi-cell transfer enable is set, a DMA interval becomes longer.
When this type of setting occurs, disable multi-cell transfer and then try again.
When multiple devices are connected to the PCI bus during multi-cell transfer, the uPD98405 performs all data transfer at one time, which has the merit of allowing other devices to use the bus during the idle time.

However, if only the uPD98405 is connected to the PCI bus, the performance may on the contrary drop depending on the CPU response.

Concerning the transmit queue buffer with 64-cell cycles, it is difficult to imagine that transmission cannot be done in time, even though there are idle intervals.
There is a STOP signal that operates for the CPU I plan to use, and I wonder if this may be the cause.
I assume that it is the host side that outputs this STOP signal. Am I correct?

Yes, this is plausible. Since the CPU side is the target, the CPU asserts STOP.

Transmission is performed from the optical module to the analyzer in the PHY mode in the uPD98405, but 155 Mbps STM-1 frames are not received on the analyzer side
(An idle pattern is output. Measured with a power meter, the optical module outputs an adequate amount of light.)

At power-on, the uPD98405 outputs an idle cell (A6 pattern), but is it transmitted in the STM-1 frame?
Also, will the idle cell not get sent out with the STM-1 frame unless some setting is performed?

Idle cells are transmitted in the STM-1 frame.
The connection circuit for the uPD98405 and optical module may be defective, so please check it.

Regarding the transmission of multiple packets of the same VC, I plan to issue the Tx_Ready command once after the information of each packet has been set in the consecutive packet descriptor areas, in order to perform batch transmission.

Regarding the operation of the CD bit on the VC table in this case, is the CD bit cleared every time transmission of 1 packet ends?
Or is the CD bit cleared only once after all the packets have been transmitted?

The CD bit is cleared when the channel can be closed, after transmission of all consecutive packets has been completed.
The CD bit is not cleared for each packet.

If JTAG reset is not performed at power-on, what kinds of problems occur?
Could you describe the various phenomena and their causes?

The reason why a problem occurs is that JTAG does not enter the reset state and JTAG operation is performed as a result.
The phenomenon associated with this problem is that normal operation of the UPD98405 is completely impossible because the pin state becomes undefined owing to the JTAG operation.

When the PCI bus is used, how should I perform the burst size setting?

The burst size is automatically determined by the uPD98405 using the 1-cell size (12 words) as the basic unit.
For details, refer to "4.2.5 Burst size" in the User's Manual.

Can a 5 V crystal oscillator be used for the REFCLK (reference clock) pin?

Yes, a 5 V crystal oscillator can be used.

Does the PHTALM pin outputs a 5 V level signal? Or is it a 3.3 V level signal?

It outputs a 5 V level signal.

Is the AVDD3 power supply pin the power supply for PECL control?

Internally, the AVDD3 is the power supply pin for the transmission PLL.

When the SE and RE bits of the GMR register are set to 1 at the startup of the uPD98405 to start transmission/reception, is it possible to clear the SE and RE bits of the GMR register to break transmission/reception, in order to erase or newly register VC registered to the receive lookup table?

The SE and RE bits of the GMR register can be cleared during transmission/reception.
Transmission stops while the SE and RE bits are cleared, and the receiving side internally discards the cells received during this time.

This question is about how the uPD98405 performs indication processing. If MSH (0x1234):MSL (0xFFF0) is used and the mailbox size is set to 64 Kbytes, and actual address calculation is performed, MSH becomes 0x1234 or 0x1235, but does the uPD98405 operate without problems in this case?

Or must the circuit be designed so that MSH is always a fixed value when actual address calculation is performed when the mailbox is secured?

The circuit must be designed so that MSH becomes fixed when the mailbox is secured.
In other words, it is not possible to set the mailbox overlapping the 64-Kbyte boundary.
To use the maximum mailbox size, it is necessary to set for example MSH = 0x1234, MSL = 0x0000.

What is the value of the version register for the uPD98405 lot?

The first alphabetic character (rank classification) following the 4-digit lot number indicates the version number. Example of lot number: 0108Kxxxxx: K rank

Product Name	Version	Rank	VER Value
uPD98405GL-PMU	3.0	K, P	0x 0000 0102
	3.1	E, X	0x 0000 0103
	4.0	M	0x 0000 0104
uPD98405S1-6C	3.1	K	0x 0000 0103
	4.0	E	0x 0000 0104

Scheduler registers I, M, X, Y, Pri&Status, and other registers related to the scheduler return only "0" when read.
Even when I check that A = 0 and write this, the written value cannot be read.

Or are there other conditions besides the A bit for reading and writing?
The same occurs when the SE and RE bits of the GMR register are both "0". Moreover, VC is not in the open state.

Scheduler register read is possible.
No special conditions apply to read/write.

Scheduler register read and write are done using the Indirect_Access command, so please check again this command as well as the read/write method.

This question is about the Open Channel command.
The Open Channel command is issued using a procedure such as the one described below, but sometimes the indication (VCNumber) cannot be obtained.

Following power-on, the indication can almost never be obtained when the first Open Channel is output, but it can be obtained without problem using the same routine from the second and subsequent Open Channel.

Moreover, even with the first Open Channel command following power-on, the indication can be obtained without problem if execution is performed manually 1 step at a time.
Is there any restriction such as of issuance timing for the first channel open command? (execution with Pentium 200 MHz equivalent)

 _outpd(CMR,0x20000000);
 while ( _inpd(CMR) & 0x80000000 != 0)
     ;
 VCNumber = _inpd(CMR);

It is possible that this problem is related to access timing restrictions of the uPD98405 following power-on.
The Open_Channel command, etc., cannot be output for 20 clocks (SCLK input) after reset or for 32 K clocks (SCLK input) during control memory initialization.
Please check whether access is performed during these times.

After performing loopback setting (setting 08 to PHY register 04H) for the uPD98405 and transmitting/ receiving 155 Mbps frames from the analyzer, nothing went through.

Does this loopback loop back all frames or does it loop back ATM cells (payload)?
In the case of all-frame loopback, why can't the STM1 overhead transmitted from the analyzer be received?

The loopback is executed in the STM-1 frame type.
The connection circuit between the uPD98405 and optical module may be defective, so please check it.

In the case of use in the ALL5 mode, is it possible to perform testing by returning the data transmitted from this device?

Checking data transmission and reception is possible during external loopback via the optical cable.
Moreover, since the uPD98405 has an internal loopback mode (LP bit of GMR register), data transmission and reception is also possible with this loopback.

I executed Tx_Ready after setting transmission VC to open, setting VC, packet descriptor, and transmit data, but transmission failed.

I first checked the A and CD bits of VC, and they were both "1". (Thus I judged that VC is recognized and that Tx_Ready was received.)

Next, I monitored the part where the VC transmission descriptor address is written to see whether it would change, but there were no changes. (Thus I judged that the uPD98405 did not perform transmission.)

Furthermore, as the packet descriptor contents during transmission should be copied to VC, I also checked whether they were correctly copied, but found out that they weren't (check of whether there is a problem with the scheduler register).

Setting of scheduler registers (0 to 15):
 I/M = 1/16
 X = 0
 Y = 0
P/C = 0/2
Pri = Priority (0 to 31)
And the enable bit is set to 1 while the other bits are 0. Transmission is performed via shaper 0.

There is an area in the transmission VC where the address information of the packet descriptor is stored, but are any addresses OK as long as they can be seen from the CPU?
How is the address space that can be recognized by the uPD98405 determined?

Also, are there address spaces that cannot be recognized?
Since the packet descriptor information is not copied to VC, does this mean that the uPD98405 has not recognized the packet descriptor addresses?
I set the static unsigned char descriptor to [4+1024]; (setting to word boundary) in the program.

Since the A bit in the VC table is 1, this means that the Tx_Ready command was received.
It may be considered that the shaper is not enabled because Word0 and Word6 in the VC table are not updated.
If the shaper set to the VC table is not enabled, bit A of the VC table continues to be set and Word 0 is not updated.

You indicate that bit E of the scheduler register is "1", but please check whether this differs from the shaper No. set to the VC table.
VC table Word 6 (Tx queue read pointer) is a field used to set the address of the packet descriptor, and there are no restrictions on the address space. It must be placed at the word boundary.

Based on the information you provide in your question, the SE bit of the GMR register may not be set.

The operation of the uPD98405 after issuing the Tx_Ready command is described below.
(1) Issue the Tx_Ready command
   ↓
(2) Set bits A and CD of VC table.
  Set bit A of shaper pointer entry.
  Set bit A of scheduler register.
   ↓
(3) Copy packet descriptor contents to Word0 in VC table

* The following are possible causes for why the processing goes not advance from (2) to (3).
 •E bit of scheduler register is not set.
 •Scheduler register's parameter C = 0
 •GMR register's SE = 0

Remark:
Bit A of the scheduler register is set by the Tx_Ready command regardless of whether the SE bit of the GMR register and the E bit of the scheduler register are disabled.
Please check the three above points.

DMA transfer of up to 12-word bursts should be possible for both transmission and reception, but currently only 4-word bursts are transferred. Which settings must be performed in order to transfer 12 words?
I set the MBL field to 111 (5 cells), but there hasn't been any change in particular.

The uPD98405 has a function to cut off burst transfer through setting of the cache line size.
The cache line size is probably set to 4 in your case.
Twelve-word burst transfer can be forcibly performed by setting AD of the GMR register to 1.
Burst transfer is also cut off before completion if a small value is set for the latency timer (dependent on the system, such as the TRDY response).

In conclusion, the following settings should be performed.
 PCI configuration register
  Cache line size = 4
  Latency timer = sufficient value
  GMR register, is AD = 1

How many VCs can be set?
In the lookup table configuration shown in Figure 5-37 of the User's Manual, the maximum number is indicated as "2^15 (lookup table address) × 2 (number of VCs that can be set in 1 address)", which I believe is 64 K, but in section "5.5.1 Reception processing flow", this number is indicated as just 32 K.
Which is correct?

In the case of the receive lookup table, there is a 64 K area for discriminating between 16-bit VPI/VCI.
A VC table is registered as VC for each respective channel, and since the area for this VC table can hold only 32 K, 32 K VCs are supported.

(Since 32 K VCs are shared for transmission and reception, 16 K VCs are supported when VCs are used in pair for transmission and reception.)
In other words, 64 K 16-bit reception VPI/VCI values can be discriminated, but of these, only 32 K can be used.

In the DC characteristics in the uPD98405 Data Sheet, the leak current for normal input is listed as MAX. ±10 uA, but the pins listed in Note 5 differ to such a large degree?

Yes, these are the characteristics for normal CMOS input.

Is it possible to perform data transmission/reception using only the UTOPIA interface and the PCI bus interface without the PMD interface, in other words input/output packets from the PCI bus and input/output ATM cells from UTOPIA?

Yes, the method you describe can be used.
When the uPD98405 is set to the external PHY mode, the UTOPIA interface can be used.

Regarding the two signals (TSOC, TENBL_B) output from the SAR chip using the UTOPIA interface line, under which conditions are enable signals output for each?

TSOC and TENBL_B become active when all the transmission settings have been completed, the host outputs the Tx_Ready command, and the time for cell output order is reached based on the shaper settings.

Regarding the TCLAV signal output from the PHY device with the UTOPIA interface, if 1-ms disable signal is input at 1 second intervals, is it possible for the SAR chip to become unable to execute cell transmission?

Even if the TCLAV signal is periodically disabled, SAR does not become unable to execute cell transmission.
(If the TCLAV signal is always disabled, cell transmission is not possible.)

Additionally, cell transmission is not possible with the following settings.
 - GMR register's SE bit = 0
 - Scheduler register's Pri&Status register's E bit = 0
 Also, settings under which I, M, P, C, etc., cannot be transmitted

There are also the following bus-related causes.
 - PCI bus is stuck (no response from target, etc.)
 - The ACK64_B and REQ64_B pins are not pulled up while using 32-bit PCI

In the case of the UTOPIA interface, is it possible that RCLK is not periodically output (logic fixed either to High or Low)?
Also, when does this occur?

The SCLK input is output as is as RCLK.
Therefore, unless SCLK input stops, RCLK output never stops.

Additionally, if the JTAG function is not reset, the pin state may become undefined, so RCLK may not be output.

A.3.1 section in the Q&A states that TCLAV signal should not be deasserted with H1, but if it is deasserted here, what kind of operation results?

When the TCLAV signal is deasserted at a timing (H1, P45 - P48) other than prescribed, the following malfunctions may occur, so that the operation cannot be guaranteed.
 - The TSOC and TENBL_B signals do not become active and cells are skipped.
 - The TSOC signal becomes High for an interval that exceeds 1 clock.

What is the relationship between RST (pin 289) and PHRST (pin 264)?

The PHRST signal falls at the falling edge of the RST signal.
Then, after the PHRST signal has maintained the Low level for 17 clocks (SCLK), it goes High.

Is TCLK (pin 253) output during reset (pin 289 = L and pin 264 = L)?

The TCLK signal is output regardless of reset.

How long is the reset interval (PHRST: pin 264)?

It is 17 clocks for SCLK.

What is the state of TCLK (pin 253) after reset (when PHRST: pin 264 has become H)?

Clock output continues.

During reset, the SEERN signal goes into high impedance, but is there a possibility that "L" is output?

During reset, SERR_B always goes into high impedance.
However, since the definition of "during reset" is not clear-cut, the following explanation is in order.
"During reset" means the period when the uPD98405 enters the reset state (and the RST_B signal remains "L") after the RST_B signal has become "L".

For the state to change to the reset state, RST_B = "L" must be maintained for 1 clock (CLK input). (Concretely, the uPD98405 perceives reset when 1 clock pulse is input to it after RST_B has become "L".)
Therefore, before the reset state is entered (1-clock interval at most), the SERR_B signal is undefined and "L" may be output.

The uPD98405 has this type of specifications, and before it enters the reset state, SERR_B = "L" may be output.

Does the uPD98405GL (version 4.0) support Hot Swap?

The uPD98405 does not support Host Swap, and thus cannot be connected and disconnected while it is powered.

When using AAL5, is the output unit of the interrupt request 1 cell (53 bytes), or is it the AAL5 layer (1 packet)?

In the case of transmission and reception of AAL5 packets, both transmit and receive interrupts are requested in packet units (and not cell units).

If data is transmitted on ATM, user data in the AAL5 format are prepared in memory, but are these data recognized as 1 packet even if they are not 1 packet of continuous addresses but consist of split addresses?

Yes, non-continuous data in memory can be transmitted as 1 AAL5 packet in the multi-buffer mode.
For details, refer to section "5.4.2 Transmit data structure" in the User's Manual.

Must the processing shown in Figure 3-1 in Chapter 3 "AAL-5 TRANSMISSION" in the Application Notes be executed every time 1 data is transmitted?

The entire processing flow need not be executed each time 1 data is transmitted.
When packets are transmitted a number of times for a given transmission VC, the processing flow from setting of transmit data and packet descriptor to transmission end processing is repeated.
Transmission VC open and setup are processing that should be executed only once for a new VC.

Transmission VC close is processing that can be executed only once when the VC use is discontinued.

In view of the above, can the transmission-related register settings and shaper settings be omitted if they are set during initialization?

Yes, these settings need not be performed every time if they are set during initialization.

During transmission from SAR, is it correct to assume that there are no errors related to the Tx_Ready command?

Regarding the output of the Tx_Ready command, no error in particular is notified.

In the command issuing procedure flow shown in Figure 10-5 in the Application Notes, busy is checked by reading CMR, but how long is the wait time?

The processing time for one command of the uPD98405 is 72 clocks max.
The term "clock" as used here refers to the SCLK input of the uPD98405. When SCLK = 25 MHz, the time interval is 2.88 us.
In other words, the wait time for busy check per command is 2.88 us.

However, in the command FIFO usage mode, when a given command is output while other commands have not yet been processed, these commands may remain in the command FIFO (up to 10 commands).
In such a case, the wait time for busy check from command output is 28.8 us max.