Datasheets and Specifications

Comments about the FM2000 in the FM4000 datasheet

Comments in the pinout table

Pin Name
Type
Type
Usage
COB C08 Notes
DTACK_INV/GPIO[0]
In/Out
LVTTL, 6mA

Defines polarity of DTACK_N. If connected to ground, then
DTACK_N is active low. If connected to VDD33, then
DTACK_N is active high.


On FM2000, this pin is permanently used for this function.


On FM3000/FM4000, this pin is sampled at reset to
determine DTACK polarity and can be used as a general
purpose I/O after reset (input by default).

DTACK_INV is pulled down to GND by a 4.7kOhm resistor. 

The PLX doesn't connect to the DTACK_INV pin.

Conclusion:

Statically pulled down.  So this is probably not related to the issue we are dealing with.

RW_INV/GPIO[1]
In/Out
LVTTL, 6mA

Defines polarity of RW_N pin when in EBI mode. When
connected to ground, then read is active high while write is
active low. Conversely, when connected to VDD33, read is
active low while write is active high.
 

On FM2000, this pin is permanently used for this function
 

On FM3000/FM4000, this pin is sampled at reset and can
be used as a general purpose I/O after reset (input by
default).

RW_INV is pulled up to VDD by a 4.7kOhm resistor. 

The PLX doesn't connect to the RW_INV pin.

Conclusion:

Statically pulled up.  So this is probably not related to the issue we are dealing with.
IGNORE_PARITY/GPIO[2]
In/Out
LVTTL, 6mA

Setting this pin to VDD33 will disable parity checking on
incoming write data.
 

On FM2000, this pin is permanently used for this function.
 

On FFM3000/FM4000, this pin is sampled at reset and can
be used as a general purpose I/O after reset (input by
default).

A.K.A. IGN_PAR

 

IGN_PAR is pulled down to GND by a 4.7kOhm resistor. 

 

The PLX doesn't connect to the IGN_PAR pin.

 

Conclusion:

Statically pulled down.  So this is probably not related to the issue we are dealing with.

SPI_CLK/GPIO[3]
SPI_CS_N/GPIO[4]
SPI_MOSI/GPIO[5]
SPI_MISO/GPIO[6]
In/Out
In/Out
In/Out
In/Out
LVTTL, 2mA

Used for either SPI or general purpose I/O pins.
 

These pins are used as SPI when the switch retrieves its
configuration from an external SPI EEPROM (if this enabled)
and as GPIO after.


The pin directions when the interface is used as SPI are:
• SPI_CLK: Out
• SPI_CS_N: Out
• SPI_MOSI: Out
• SPI_MISO: In
 

Note: The pin SPI_MOSI was previously called SPI_SO in
the FM2000 and the pin SPI_MISO was called SPI_SI.

At bootup, these pins are GPIO inputs by default (see page 70 of FM4000 datasheet).

The PLX doesn't connect to the any of these   pins.  They are accessible via the debug J8 connector.

Conclusion:

This is only a name change.  Pinout has not changed.  So this is probably not related to the issue we are dealing with.

PARITY_EVEN/GPIO[10]
In/Out
LVTTL, 6mA

General purpose I/O pin.


This pin is also latched at reset to determine the parity mode
on the data bus after reset (high=even, low=odd). This pin
must be pulled up or pulled down and cannot be left
unconnected. Pull up for compatibility with FM2000 series
devices.

PARITY_EVEN is pulled up to VDD by a 4.7kOhm resistor.  However, the loading options for this resistor is NL (no load).

From the data sheet "This pin must be pulled up or pulled down and cannot be left unconnected"

Conclusion:

This could be causing our problem.  We should install the 4.7kOhm resistor and see if it solve our problem.

 

DATA_HOLD/GPIO[14]
In/out
LVTTL, 6mA

General purpose I/O pin.


This pin is latched at reset to define DTACK and DATA
behavior. If this pin is pulled up, then DTACK and DATA (if
read) are asserted when needed and remain asserted until
CS is de-asserted. If this pin is pulled down, then DTACK
and DATA are asserted (if read) for one cycle, then DTACK
gets actively de-asserted for one cycle and tri-stated after
that. For compatibility with FM2000 devices, this pin should
be pulled down. It should not be left unconnected.

DATA_HOLD is pulled up to VDD by a 4.7kOhm resistor.  However, the loading options for this resistor is NL (no load).

 

From the data sheet "It should not be left unconnected"

 

Conclusion:

This could be causing our problem.  We should install the 4.7kOhm resistor and see if it solve our problem.

Comments in the text


 

  • Page 46:
    • "The FM2000 series devices support those two methods. The first method is supported by setting the PCS_CFG_1[DE] to 0. The second method is is supported by setting the PCS_CFG_1[DE] to 1."
  • Page 76:
    • "Differences with FM2000 family:
      • The FM2XXX samples write data on the same cycle as CS, AS, ADDR and RW_N. Because of that, CS and AS had to be delayed on multiplex buses by one cycle to allow ADDR to be latched and DATA to be driven on the bus. This is addressed in FocalPoint by sampling data on the next clock edge allowing CS and AS to be driven along with the address cycle.
      • The FM2XXX waits for CS to fully deassert for one cycle before starting a new cycle. This restriction has been removed.
      • FocalPoint is designed to be clocked at up to 133MHZ versus 66MHZ for the FM2000 family
      • The combination of those 3 modifications could allow the system designer to quadruple the throughput on the CPU bus."
  • Page 151:
    • "Binning of the selected hash value is performed using division for ECMP and modulo for link aggregation. Division (also known as Hash Threshold) has the advantage of providing better stability of the bin mappings when the number of bins is changed ( cf RFC 2992). This property is only important for ECMP however, so in the interest of maintaining backwards compatibility with FM2000 devices, link aggregation continues to employ modulo binning. Both functions provide equally balanced hash binning."
  • Page 156:
    • "Note: The EtherType included in the hash is the layer 2 header's first non-VLAN EtherType. In constrast, Tahoe (FM2000) includes the first EtherType in its frame hashing. Thus, if backwards compatibility with Tahoe is required, UseType should be set to zero."
  • Page 156:
    • "10.4 Tahoe (FM2000) Compatibility

      • Multi-chip systems using both Tahoe and Bali devices may, depending on the hardware learning configuration,
        require consistent frame hashing across the two generations of switches. For example, in a fat tree with
        learning enabled in the spine chips, it is important that (a) the hash function be symmetric and (b) all edge
        switches use the same hash function. The following table summarizes the configuration requirements that
        are necessary in order to achieve consistent hashing between Bali and Tahoe devices.
        Table 25: Summary of Hash Configuration Requirements for Tahoe Compatibility"

        Bali Requirement
        		Tahoe Requirement
        		Motivation
        TahoeCompatible == 1
        UseSMAC == 0, UseDMAC == 0
        		-Select Tahoe Compatibility mode.
        UseType == 0
        		IncludeTypeAndSource == 0
        		See note above about differences
        between Bali & Tahoe in their handling
        of EtherType.

  • Page 351:

Name
Bit
Description
Type
Default
FloodGlort
(was GlortFlood)
15: 0
 Defines the glort to use when flooding.

RW
0x0
XcastGlort
(was GlortBroadcast)
31: 16
Defines the glort used for broadcast and
multicast. Note that multicast in this case is
defined as MAC addresses that resolve to a
destination mask instead of a glort, which is
how multicast is implemented in FM2000, but
is deprecated in FM4000
RW
0x0

 

 

 

 

 

  • No labels