| 1 |
What is the meaning of the "heartbeat fail" bit in the transmitter descriptor TDESO?
Heartbeat_Fail is actually SQE (signal_quality_error) message. This Resetting CSR06(NAR) bit 19 enables test-function(SQE). It is valid only for half-duplex mode 10Base-T.
Please check Clause 7.2.4.6 PLS-Carrier-Sense(CRS) Function, 7.2.2.2.4 of IEEE 802.3 spec. for more details. |
| 2 |
What parts of the MAC frame must be loaded in the transmit buffer?
Format of the transmit buffer inside chip is given below : DestinationAddress-SourceAddress-Type/Length_Field-Data-CRC32
However, this is taken care of by the software-driver (for STE10/100A), which does PCI-transactions - to load transmit buffer inside chip from packet in PC-memory. Please refer to STE10/100A datasheet for further information. |
| 3 |
Does the STE10/100A have an interface to the IDE/ATA bus used by hard disk drives?
STE10/100 is a PCI to 10/100Mbps Ethernet controller that does not have an interface to the IDE/ATA bus used by hard disk drives. |
| 4 |
Does the PCI interface operate below 20MHz? Is the PCI clock asynchronous to the Ethernet clock or some relation thereof?
ST specifies the PCI clock to operate between 20 - 33 MHz. Yes, the PCI clock is asynchronous to the Ethernet clock. |
| 5 |
Does the STE10/100A support Perfect Address capability?
Yes, it does only for one single address, not for a table of Physical Addresses. |
| 6 |
Is loopback capability supported on the MAC and on the PHY in the STE10/100A?
Yes, there is a separate loopback for both MAC and PHY. |
| 7 |
Is VLAN supported? If not, then will the chip allow pass the VLAN packets to pass without generating an error?
No, VLAN is not supported. However, the STE10/100A will indeed pass the VLAN packets without generating an error. For further info, please see the next question. |
| 8 |
The STE10/100A datasheet mentions the TL bit in the Receive Buffer Descriptor and states that the packet is Too Long (longer than 1518 bytes). Will these packets of frame size, say 1522 bytes, be rejected by the chip itself or will they reach the PCI interface and cause an error during reception? Can these errors then be masked or disabled so that these frames are received on our PCI side?
A packet that is Too Long (longer than 1518 bytes) will not be rejected by the STE10/100A itself. It will reach the PCI interface and cause a receive long frame error, but the PB (Pass Bad Packet) bit in the CSR can be set to allow reception of bad packets. It has been verified in our lab that with PB=1, packets of 1522 bytes can be received over the PCI bus into memory. However, most of the device drivers do not support passing frames greater that 1518 bytes up to the upper layers of software. |
| 9 |
Does the chip support the Ethernet MIB counters on the MAC side?
The STE10/100A does support on the MAC side all of the statistical counters as indicated in the Data Sheet, for support of Ethernet MIBs. |
| 10 |
Does the chip support Pause Frame generation?
Yes, the STE10/100A chip supports Pause Frame generation as well as acceptance/recognition of Pause Frames. |
| 11 |
Does it support both the IEEE 802.3 and Ethernet 2 DIX frames?
Yes, the STE10/100A supports both IEEE 802.3 and Ethernet II DIX frames. |
| 12 |
Does it support bridging tables? Can it construct bridging tables on it's own?
No, the STE10/100A does not directly support bridging tables and cannot construct bridging tables on its own. |
| 13 |
Does the STE10/100A
support multicast address filtering? How can we setup multicast
address table on STE10/100A?
The STE10/100A does indeed support multicast address filtering.
It does so through a hashing mechanism like that used by the
2114x family of devices. Setting bit 7 in CSR6 register allows
it to receive incoming frames with a multicast destination address
(first bit in the destination address field is 1). Incoming
frames with multicast destination addresses are subjected to
imperfect filtering. Frames with physical destination addresses
are checked against the single physical address in CSR25 &
CSR 26. CSR26 and CSR27 are used to contain the 64-bit hash
table used for imperfect multicast address filtering. Bit 10
of Receive Descriptor RDES0 is used to indicate that the received
frame has a multicast address.
For any incoming frame with a multicast destination address,
the STE10/100A applies the standard Ethernet cyclic redundancy
check (CRC) function and then it uses the most significant 6
bits of the result as a bit index into the table. If the indexed
bit is set, the frame is accepted. If the bit is cleared, the
frame is rejected. Below is sample C code of a hash index for
a given Ethernet address. This filtering mode is called imperfect
because multicast frames not addressed to this particular STE10/100A
may be received, but it does significantly decreases the number
of unwanted frames will be received.
Little Endian Architecture Hash C Routine:
#define CRC32_POLY 0xEDB88320UL /* CRC-32 Poly -- Little Endian*/
#define HASH_BITS 9 /*
Number of bits in hash */ unsigned crc32_mchash(unsigned char
*mca)
{
u_int idx, bit, data, crc = 0xFFFFFFFFUL; for (idx = 0; idx
< 6;
idx++)
for (data = *mca++, bit = 0; bit < 8; bit++, data >>=1)
crc = (crc >> 1) ^ (((crc ^ data) & 1) ? CRC32_POLY
: 0);
return crc & ((1 << HASH_BITS) - 1) /* return low
bits for hash */
} |
| 14 |
Is there any performance advantage to having TX and RX FIFO size of greater than the 2K bytes, which is what is used by the current STE10/100A?
The STE10/100A does indeed support multicast address filtering.
It does so through a hashing mechanism like that used by the 2114x
family of devices. For Multicast filtering, the MM bit (bit 7)
in CSR6 should be set to 0 (Note: Setting MM=1 (bit 7 in CSR6)
will cause the STE10/100A to receive all Multicast packets regardless
of the value in CSR27 & CSR28). Setting a value other than
0 in CSR27 and/or CSR28 allows the device to receive incoming
frames with a multicast destination address (first bit in the
destination address field is 1). Incoming frames with multicast
destination addresses are subjected to imperfect filtering. Frames
with physical destination addresses are checked against the single
physical address in CSR25 & CSR 26. CSR26 and CSR27 are used
to contain the 64-bit hash table used for imperfect multicast
address filtering. Bit 10 of Receive Descriptor RDES0 is used
to indicate that the received frame has a multicast address.
The process for accepting multicast frames in STE10/100 is given below:
 |
To generate CRC the first 32 bits of Destination
Address (DA) are complemented and then fed to a LFSR which
uses the CRC polynomial as seed. However in the STE10/100A
implementation, generator polynomial is implemented as an
LFSR, which takes 8-bit parallel data (Rx Data starting
from DA). Initially (at reset) the LFSR flip flops are set
to all 1's (same effect as complementing the 32 bits of
DA). |
 |
After 6 cycles (DA is 48-bits and CRC is computed
in 8-bit chunks) the upper 6 bits of CRC are used as a hash-pointer
to address bits within CSR27 (32-bits) and CSR28 (32 bits),
making 64 hash entries in all. |
hash_pointer[5:0] = crc_gen[26:31]
If the hash value for a particular DA computes to 0x15(0d21),
then bit 0d21 in CSR27 is checked for a Binary 1. If it is 1,
then the packet is multicast. If all the 64 bits (CSR27 and CSR28)
are set to 1, all the multicast packets will be accepted.
So as described above, for any incoming frame with a multicast
destination address, the STE10/100A applies the standard Ethernet
cyclic redundancy check (CRC) function and then it uses the most
significant 6 bits of the result as a bit index into the table.
If the indexed bit is set, the frame is accepted. If the bit is
cleared, the frame is rejected. Below is sample C code of a hash
index for a given Ethernet address. This filtering mode is called
imperfect because multicast frames not addressed to this particular
STE10/100A may be received, but it does significantly decreases
the number of unwanted frames will be received.
Little Endian Architecture Hash C Routine:
#define CRC32_POLY 0xEDB88320UL /* CRC-32 Poly -- Little Endian*/
#define HASH_BITS 9 /* Number of bits in hash */ unsigned
crc32_mchash(unsigned char *mca)
{
u_int idx, bit, data, crc = 0xFFFFFFFFUL; for (idx = 0; idx < 6; idx++)
for (data = *mca++, bit = 0; bit < 8; bit++, data >>=1)
crc = (crc >> 1) ^ (((crc ^ data) & 1) ? CRC32_POLY : 0);
return crc & ((1 << HASH_BITS) - 1) /* return low bits for hash */
} |
| 15 |
Is there a JTAG port in the STE10/100A? Is there any scan in the PHY?
There is no JTAG port, but there is scan in the PHY reserved for ST use only. |
| 16 |
Where can I find info on how to program the Boot ROM pins as MII interface pins?
There are two methods that can be used to program the Boot ROM pins as MII interface pins. One method is from hardware configuration, the other is from software. Detailed info on this can be obtained from the STE10/100A application note. |
| 17 |
Can the STE10/100A be interfaced to a HPNA PHY?
The STE10/100A MII interface uses the TX clock to clock the transmit data out of the MAC and uses the Rx clock to clock received data into the MAC. Both clocks are to be generated by the PHY. Yes, the STE10/100A has been successfully interfaced to a HPNA PHY solution previously. |
| 18 |
Do you have Ethernet test conformance available?
Yes, please contact your local ST Sales rep for further information. |
| 19 |
What kind of EEPROM does the STE10/100A use? Can the application use current MLC flash and EEprom as bootprom/flash or is there a need for a separate flash/eeprom?
The STE10/100A uses a simple M93S46 1K EEPROM with microwire (not I2C)interface. The STE10/100A does not require a FLASH unless the application requires BootROM operation as in a diskless workstation or similar application. |
| 20 |
Is it possible to configure the devices, so that they are able the get their info via the PCI bus?
The device can be used with the default configuration set during power-up, and then after power-up, the device options and registers can be programmed via the PCI bus. So, the device can be used without EEPROM (and without FLASH), with a few considerations. The device driver will have to work with the default Device ID and Vendor ID. It is VID=0x104A and DID=0x981 on the current devices, but the DID may change to 0x2774 on future revisions, so this must be taken into account.
Also, the MAC address (Physical Address bytes) must be programmed into CSR25 and CSR26 each time the device is powered up. The remaining of the options that can set by the EEPROM at power-up could be using the defaults, or one can write directly to the registers from the PCI bus after each power-up. |
| 21 |
What can be done if an application has unused pinning of the ROM interfaces?
The unused pins of the ROM interface can just be left floating. |
| 22 |
Can interrupts be generated for the LinkUp cable plugged using Auto Negotiation?
The Auto Negotiation complete interrupt is probably the best option for getting an interrupt to indicate that the link is up. Even if the link partner does not support Auto Negotiation, the device will resolve the connection via parallel detection, and give an Auto Negotiation Complete interrupt. Otherwise polling the LINK bit of XR1 is the other option. The LS bit of XR8 is latching high and cleared by reading it. So it will only be read as 1 the first time the register is read immediately after a link down occurs. |
| 23 |
When the transmit jabber timeout occurs and the transmit underflow and the receive descriptor unavailable are set, is the Tx and Rx activity stopped? What is the way to restart the Rx and Tx?
When transmit jabber time-out or transmit underflow are set, the TX activity will stop. To restart the transmit activity, ST in CSR6 (bit 13) should be set to 1, and then write to CSR1 (Transmit Poll Demand) once a TX descriptor is available. When the Receive Descriptor Unavailable bit is set, the RX activity will stop until more RX descriptors are made available (by setting OWN bit of RDES0 for each descriptor available). Then you can write to CSR2 (Receive Poll Demand) to resume receive activity, or receive activity will resume automatically with the next incoming frame if receive descriptors are available. |
| 24 |
What is the purpose of the receive watchdog?
The receive watchdog timer is used to detect received packets that are too long. The receive watchdog timer will expire when a receive packet exceeds 2560 bytes. |
| 25 |
What is the purpose of the transmit threshold count in csr6 and store forward functionality?
The purpose of the Transmit Threshold control is to determine the number of bytes of a packet to be transmitted that must be in the TX FIFO before the device will start transmitting the packet. The main purpose is to avoid transmit FIFO underflows and to allow more efficient utilization of memory transfers from the transmit buffer to the TX FIFO in the chip. However, when the end of the packet to be transmitted is written into the TX FIFO, the packet will be transmitted regardless of whether or not the transmit threshold has been reached. The Store and Forward (SF bit in CSR6) is used to ignore the transmit threshold setting to not transmit the packet until the entire packet is in the TX FIFO. |
| 26 |
What is the purpose of the back off counter in csr6?
The Stop Back-off counter in CSR6 is used to cause the back off counter to stop whenever the device receives a non-idle signal during inter-packet gap time. The back-off counter is used to enforce the IEEE802.3 required minimum inter-packet gap time (9.6 uS for 10BaseT and 0.96 uS for 100BaseTx). |
| 27 |
What is the purpose of the receive threshold enable in csr18?
The purpose of the Receive Threshold control is to determine the number of bytes of an incoming packet that must be in the RX FIFO before the device will start transferring the packet into the receive buffer pointed to by the receive descriptor. The main purpose is to allow more efficient utilization of memory transfers from the RX FIFO to the receive buffer. However, when the end of the incoming packet is received into the RX FIFO, the packet will be transferred to the receive buffer regardless of whether or not the receive threshold has been reached. |
| 28 |
What is the relation between PB and PR bits of csr6? Could I disable PR and still enable PB?
Setting PR=1 allows reception of all packets regardless of the MAC destination address of the packet. Setting PB=1 allows reception of Bad Packets (typically those with bad CRC). Both bits can be set independently and will operate independently of each other. |
| 29 |
What is the difference between a longword as opposed to a double word as it is interchangeable used in the STE10/100A technical documentation while referring to the TX and RX descriptors?
For the STE10/100A, a longword is 32 bits, or 4 bytes. The term double word is also used to mean 4 bytes. The STE10/100A requires that TX and RX descriptors be aligned on 32 bit boundaries. The CLS settings for cache line do not affect these values. |
| 30 |
What is the purpose and function of pins 88 - VCC-DETECT and 89 - VAUX-DETECT , and how should they be connected if the Wake On LAN feature is not used, such that there is no power available to the device when the application is turned off?
Pin 88, Vcc Detect, is asserted to indicate to the STE10/100A that power is being supplied via the PCI Bus, and pin 89, Vaux Detect is asserted to indicate that power is being supplied via an auxiliary source such as the Wake On LAN (WOL) Connector. These pins are used to by the device to determine the Power State in which it is, for power management features and WOL operation. However, in the case where no WOL or power management features are used, it is suggested to connect Pin 88, Vcc Detect to 3.3V to indicate that power is being supplied by the PCI bus and connect pin 89, Vaux Detect low to indicate no auxiliary power supply (which would be the typical case without WOL support). |