ETHERNET-110_技术文档

TECHNICAL

MANUAL

Ethernet-110 Core

F e b r u a r y 2 0 0 1

®

R14004.B

Document Number DB14-000014-02, Second Edition (February 2001)

This document describes LSI Logic Corporation’s Ethernet-110 Core and will

remain the ofﬁcial reference source for all revisions/releases of this product until

rescinded by an update.

To receive product literature, visit us at http://www.lsilogic.com.

LSI Logic Corporation reserves the right to make changes to any products herein

at any time without notice. LSI Logic does not assume any responsibility or

liability arising out of the application or use of any product described herein,

except as expressly agreed to in writing by LSI Logic; nor does the purchase or

use of a product from LSI Logic convey a license under any patent rights,

copyrights, trademark rights, or any other of the intellectual property rights of LSI

Logic or third parties.

TRADEMARK ACKNOWLEDGMENT

LSI Logic logo design, CoreWare, and Right-First-Time are registered

trademarks or trademarks of LSI Logic Corporation. All other brand and product

names may be trademarks of their respective companies.

MT

ii

Preface

This manual is the primary reference for the Ethernet-110 (E-110) core,

which includes the media access controller (MAC) core, the optional

MAC control module core, the optional media independent interface

management (MIIM) core, and the optional serial media independent

interface (SMII) core. It contains a complete functional description for the

E-110 core and includes complete physical and electrical speciﬁcations.

The E-110 core is capable of operating at 10 or 100 Mbit/s for Ethernet

and Fast Ethernet applications.

Audience

This manual assumes that you have some familiarity with Ethernet

protocols and related support devices. It also assumes some familiarity

with IEEE standards 802.3/802.3u and all applicable clauses describing

10 and 100 Mbit/s Ethernet operation. The people who beneﬁt from this

technical manual are:

•

Engineers and managers who are evaluating the E-110 core for use

in an ASIC application

Engineers who are designing the E-110 core into an ASIC

Organization

This document has the following chapters:

•

Chapter 1, Introduction, provides an introduction to LSI Logic

Corporation’s E-110 core.

Chapter 2, Signal Descriptions, provides a detailed description of

each of the signals associated with the core.

Preface

iii

•

Chapter 3, Core Descriptions, describes the operation of the E-110

core.

Chapter 4, Functional Timing, provides timing diagrams for the

core.

Chapter 5, Speciﬁcations, describes the AC timing and core inputs

and outputs.

Appendix A, Glossary, provides a list of terms used in this manual.

Related Publications

IEEE Standard 802.3, 10 Mbit/s Ethernet Speciﬁcation

IEEE Standard 802.3u, 100BASE-T Fast Ethernet Speciﬁcation

IEEE Standard 802.3x, 802.3 Full Duplex Operation Speciﬁcation

Ethernet-10 (E-10) Core Technical Manual, LSI Logic Corporation, Order

Number R14006

Conventions Used in This Manual

The ﬁrst time a word or phrase is deﬁned in this manual, it is italicized.

See the glossary at the end of this manual for deﬁnitions of italicized

words.

The word assert means to drive a signal true or active. The word

deassert means to drive a signal false or inactive.

The following signal naming conventions are used throughout this

manual:

•

A level-signiﬁcant signal that is true or valid when the signal is LOW

always has a sufﬁx of _L attached to its name.

An edge-signiﬁcant signal that initiates actions on a HIGH-to-LOW

transition always has a sufﬁx of _L attached to its name.

Hexadecimal numbers are indicated by the preﬁx “0x” before the

number—for example, 0x32CF. Binary numbers are indicated by the

preﬁx “0b,” for example, 0b0011.0010.1100.1111.

iv

Preface

Contents

Chapter 1

Introduction

®

1.1

1.2

CoreWare Program

1-1

1-3

Fast Ethernet (100 Mbit/s)

1.2.1

1.2.2

1.2.3

1.2.4

1.2.5

Fast Ethernet Overview

1-3

Fast Ethernet Features

1-4

E-110 MAC Core and the OSI Model

Fast Ethernet Hubs

1-6

1-7

Fast Ethernet Network Interface Cards

1-10

1-11

1-12

1-13

1-18

1-19

1-21

1-23

1-24

1-25

1-26

1.3

1.4

1.5

VLAN Support

E-110 Core

E-110 MAC Core

1.5.1

1.5.2

1.5.3

1.5.4

1.5.5

1.5.6

MAC Core Host System Connection

MAC Multiple Channel Operation

MAC External Interfaces

MAC SMII/MII

MAC Backoff Operation

MAC Backpressure Feature

1.6

1.7

1.8

MAC Control Module Core

MIIM Core

SMII Core

Chapter 2

Signal Descriptions

2.1 MAC Core Signals

2-1

2-3

2.1.1

2.1.2

2.1.3

2.1.4

2.1.5

2.1.6

Transmit Function to Host Signals

Receive Function to Host Signals

MAC Control Module Signals (Optional)

SMII/MII to PHY Signals

2-5

2-9

2-12

2-15

2-24

Host Control Signals

Statistics Vector to Host Signals

Contents

v

2.1.7

2.1.8

Random Number Generator to Host Signals

Scan Test Signals

2-30

2-31

2-32

2-35

2-39

2-43

2-45

2-47

2-49

2-50

2-51

2.2

MAC Control Module Signals

2.2.1

2.2.2

2.2.3

MAC Control Module to E-110 Core Signals

MAC Control Module to PHY Signals

MAC Control Module to Host Signals

2.3

2.4

MIIM Core Signals

2.3.1

2.3.2

MIIM Core to Host Signals

MIIM Core to PHY Signals

SMII Core Signals

2.4.1

2.4.2

2.4.3

2.4.4

2.4.5

SMII Core to Host Signals

SMII Core to MAC Signals

SMII Core to PHY Signals for MII Operation

SMII Core to PHY Signals for SMII Operation

SMII Core to Clock Sources for SMII Operation

Chapter 3

Core Descriptions

3.1

Clock Operation

3-1

3.1.1

3.1.2

3.1.3

MTXC and MRXC

HCLK

MDC

3-3

3.2

E-110 Core Operation

3-3

3.2.1

3.2.2

3.2.3

3.2.4

MAC Core Operation

3-5

MAC Control Module Core Operation

MIIM Core Operation

3-17

3-18

3-25

SMII Core Operation

Chapter 4

Functional Timing

4.1

4.2

4.3

MAC Functional Timing

4-1

4.1.1

4.1.2

MAC Receive Packet Timing

MAC Transmit Packet Timing

4-4

MIIM Core Functional Timing

4-7

4.2.1

4.2.2

MIIM Write Operation

4-7

MAC MIIM Read Operation

4-9

Transmit Collision Functional Timing

4-10

vi

Contents

Chapter 5

Speciﬁcations

5.1

5.2

5.3

5.4

5.5

5.6

5.7

Derivation of AC Timing and Loading

5-1

5-2

MAC Core AC Timing

MAC Core Pin Summary

5-4

MAC Control Module Core AC Timing

MAC Control Module Core Pin Summary

MIIM Core AC Timing

5-6

5-8

5-10

5-11

MIIM Core Pin Summary

Appendix A

Figures

Glossary

Customer Feedback

1.1

1.2

1.3

1.4

1.5

1.6

1.7

1.8

1.9

100BASE-T Media Speciﬁcations

1-6

1-7

E-110 MAC Relationship to the OSI Model

Hub Examples

1-8

Switched Hub Example

1-10

1-11

1-12

1-14

1-16

1-19

1-20

1-22

1-23

1-25

1-26

2-2

Network Interface Card Block Diagram

E-110 ASIC Environment

E-110 MAC Host System Connection

Centralized Statistics Updater

Multiple Channel Application

1.10 External Connections to the E-110 MAC

1.11 MII Function

1.12 SMII Core (Optional)

1.13 MIIM Core

1.14 SMII Core

2.1

2.2

2.3

2.4

3.1

3.2

3.3

3.4

E-110 MAC Core Interface Diagram

MAC Control Module Core Interface Diagram

MIIM Core Interface Diagram

2-32

2-39

2-45

3-4

SMII Core Interface Diagram

Overall Block Diagram

Transmit and Receive Functions

Transmit Function Interface

3-5

Half-Duplex Back-to-Back IPG Operation

3-8

Contents

vii

3.5

3.6

3.7

3.8

3.9

Half-Duplex Non-Back-to-Back IPG Operation

Full-Duplex Back-to-Back IPG Operation

Full-Duplex Non-Back-to-Back IPG Operation

Receive Function Interface

3-8

3-9

3-14

3-26

3-27

3-28

3-30

4-2

Typical SMII Block Diagram

3.10 Source Synchronous Block Diagram

3.11 Typical SMII Receive Data Timing

3.12 Typical SMII Transmit Data Timing

4.1

4.2

4.3

4.4

4.5

4.6

5.1

5.2

E-110 MAC Receive Packet Timing

Packet Preamble and SFD

4-3

E-110 MAC Transmit Packet Timing

MIIM Write Operation

4-5

4-7

MIIM Read Operation

4-9

Transmit Collision Functional Timing

MAC Core Setup, Hold, and Delay Timing Diagram

MAC Control Module Setup, Hold, and Delay

Timing Diagram

4-11

5-2

5-7

5.3

MIIM Core Setup, Hold, and Delay Timing Diagram

5-10

Tables

1.1

2.1

10BASE-T Ethernet vs. 100BASE-T Fast Ethernet

Transmission Retry Algorithm for BKOFF_LIMIT[1:0]

(Maximum k = 10, 8, 4, 1)

1-5

2-18

3-19

3-20

3-23

3-26

3-28

3-31

5-3

3.1

3.2

3.3

3.4

3.5

3.6

5.1

5.2

5.3

5.4

5.5

5.6

MIIM Register Set for 10/100/1000 Mbit/s PHYs

PHY Control Register Bit Deﬁnitions

PHY Status Register Bit Deﬁnitions

Source Synchronous Clock and Synchronization

SMII_RXD[7:0] Meaning

SMII_TXD[7:0] Meaning

MAC Core AC Timing Parameters

MAC Core Pin Summary

5-4

MAC Control Module AC Timing Parameters

MAC Control Module Pin Summary

MIIM Core AC Timing Parameters

MIIM Core Pin Summary

5-7

5-8

5-10

5-11

viii

Contents

Chapter 1

Introduction

This chapter describes the overall functions of the E-110 core. It contains

the following sections:

•

Section 1.1, “CoreWare® Program,” page 1-1

Section 1.2, “Fast Ethernet (100 Mbit/s),” page 1-3

Section 1.3, “VLAN Support,” page 1-11

Section 1.4, “E-110 Core,” page 1-12

Section 1.5, “E-110 MAC Core,” page 1-13

Section 1.6, “MAC Control Module Core,” page 1-24

Section 1.7, “MIIM Core,” page 1-25

Section 1.8, “SMII Core,” page 1-26

1.1 CoreWare^®Program

An LSI Logic core is a fully deﬁned and reusable block of logic. It

supports industry-standard functions, and has predeﬁned timing and

layout. Every core possesses signiﬁcant intellectual property value that

comes from the construction, optimization, and productization of a

particular function.

Through the CoreWare program, you can create systems on a chip

uniquely suited to your applications. The CoreWare library contains a

wide range of complex cores targeting the communications, consumer,

and computer markets. The library consists of MIPS microprocessor

cores, high-speed interconnect cores, MPEG-2 decoder cores, PCI

cores, and many more.

The CoreWare library also includes megafunctions and building blocks,

which provide useful functions for developing a system on a chip.

Ethernet-110 Core Technical Manual

1-1

Each core has an associated set of deliverables, including:

•

RTL simulation models for the Verilog HDL environment

Structural simulation models for Verilog HDL and VHDL

environments

1

•

A system veriﬁcation environment (SVE) for RTL-based Verilog

simulation

A test vector suite

Because your design requirements are unique, LSI Logic is ﬂexible in

working with you to develop your system-on-a-chip CoreWare design.

Three different working relationships are available:

•

You provide LSI Logic with a detailed speciﬁcation and LSI Logic

does all of the design.

You design some functions while LSI Logic provides you with the

cores and megafunctions, and LSI Logic completes the integration.

LSI Logic provides you with the cores, megafunctions, and

development tools for you to do the entire design and integration.

Whatever the work relationship, the LSI Logic advanced CoreWare

methodology and ASIC process technologies consistently produce

Right-First-Time™ silicon.

1. The SVE provides a software environment for verifying core functionality.

Introduction

1-2

1.2 Fast Ethernet (100 Mbit/s)

The E-110 core is a 100BASE-T Fast Ethernet solution. 100BASE-T is

one of a number of technologies that provide greater bandwidth and

improved client/server response times. The 100BASE-T standard is

designed to provide a smooth evolution from 10BASE-T Ethernet–the

dominant 10 Mbit/s network used today–to high-speed 100 Mbit/s

performance.

1.2.1 Fast Ethernet Overview

The Fast Ethernet standard for 100BASE-T has been established by the

IEEE 802.3 committee, the same committee that developed the original

Ethernet standard. The 100BASE-T standard is found in the IEEE 802.3u

speciﬁcation, which serves as a supplement to the 802.3 standard and

extends the operating speed to 100 Mbit/s.

100BASE-T Fast Ethernet is an extension of 10BASE-T technology. This

technology uses the existing 802.3 media access control (MAC) layer

(layer 2), connected through a media-independent interface (MII) or serial

media-independent interface (SMII) to a physical layer device (PHY).

The SMII/MII speciﬁcation is analogous to the 10 Mbit/s Ethernet

attachment unit interface (AUI)—it provides a single interface that can

support external transceivers for any of the 100BASE-T media

speciﬁcations. In the Fast Ethernet MAC, the bit time (the time to transmit

one bit of data) has been reduced by a factor of 10, thereby increasing

packet speed to ten times that of 10BASE-T, while packet format and

length, error control, and management information remain identical to

10BASE-T.

The 100BASE-T standard supports three PHY layers:

•

100BASE-TX (see IEEE 802.3u, clauses 24 and 25)

100BASE-T4 (see IEEE 802.3u, clause 23)

100BASE-FX (see IEEE 802.3u, clauses 24 and 26)

The 100BASE-X standard outlined in the IEEE 802.3u speciﬁcation

embodies the 100BASE-TX and 100BASE-FX standards. The term

100BASE-X is used when referring to the physical coding sublayer (PCS)

Fast Ethernet (100 Mbit/s)

1-3

and physical medium attachment (PMA), which are common to both

100BASE-TX and 100BASE-FX. See Figure 1.2 on page 1-7.

The physical medium dependent (PMD) issues are different for

100BASE-TX and 100BASE-FX, and are described in separate sections

of the IEEE 802.3u speciﬁcation. The 100BASE-T4 standard is unique

from 100BASE-TX and 100BASE-FX and is described in its own section

of the IEEE 802.3u speciﬁcation.

The 100BASE-T standard also deﬁnes a universal hub interface and a

management interface.

The cable and ﬁber types currently used in 100BASE-T networks are:

•

100BASE-TX— a two-pair system for data grade (EIA 568

Category 5) unshielded twisted-pair (UTP) and 150 Ω shielded

twisted-pair (STP) cabling

•

100BASE-T4—a four-pair system for both voice and data grade

(Category 3, 4, or 5) UTP cabling

100BASE-FX— two multimode ﬁbers

Additionally, the 100BASE-TX, 100BASE-T4, and 100BASE-FX systems

can be mixed and interconnected through a hub.

1.2.2 Fast Ethernet Features

The key advantages of Fast Ethernet:

•

Proven technology with speed increased by a factor of 10

Simple migration from 10 Mbit/s to 100 Mbit/s networks

Extensive multivendor support

1.2.2.1 10BASE-T to 100BASE-T Comparison

Fast Ethernet, in the form of 100BASE-T technology, is really very similar

to 10BASE-T, but is ten times faster. Unlike other high-speed

technologies, Ethernet has been installed for over 20 years in business,

government, and educational networks. Table 1.1 is a comparison

between 10BASE-T and 100BASE-T.

1-4

Introduction

Table 1.1

Function

10BASE-T Ethernet vs. 100BASE-T Fast Ethernet

Ethernet

Fast Ethernet

Speed

10 Mbit/s

100 Mbit/s

802.3u

IEEE Standard

Media Access Protocol

Topology

802.3

CSMA/CD

Star

Bus or Star

Coax, UTP, Fiber

Category 3, 4, or 5

100 Meters

500 Meters

Cable Support

UTP, Fiber

Category 3, 4, or 5

100 Meters

205 Meters

UTP¹Cable Support

UTP Link Distance (max)

Collision Domain Diameter

(maximum with all UTP)

Maximum Network Diameter

(using switches/routers)

Unlimited

Media Independent Interface

Full Duplex Capable

Yes (AUI)²

Yes

Yes (SMII/MII)³

Yes

1. UTP = unshielded twisted pair

2. AUI = auxiliary unit interface

3. SMII = serial media independent interface, MII = media independent interface

1.2.2.2 CSMA/CD Transmission Protocol

Ethernet’s fundamental transmission protocol is Carrier Sense Multiple

Access with Collision Detection (CSMA/CD). Fast Ethernet maintains this

protocol, which allows it to move data between 10BASE-T and

100BASE-T stations on a local area network (LAN) without requiring

protocol translation. A simple, low-cost switching hub or bridge is all that

is required for connection. Because it is the same technology (but faster),

100BASE-T can be successfully integrated into 10BASE-T networks to

form a reliable migration path to 100BASE-T networks.

1.2.2.3 Media Speciﬁcations

A major advantage of Fast Ethernet over other high-performance

technologies is that it can be deployed as a switching or shared

technology. 100BASE-T networks are based on a combination of

Fast Ethernet (100 Mbit/s)

1-5

switching and shared hubs in order to maintain existing 10BASE-T

infrastructures. 100BASE-T networks are capable of full-duplex

operation.

100BASE-T combines the scaled MAC with a variety of media

speciﬁcations to provide users with the maximum possible wiring

ﬂexibility, as shown in Figure 1.1. The media speciﬁcations (100BASE-

TX, 100BASE-T4, and 100BASE-FX) are collectively referred to as

100BASE-T and enable users to retain their existing cabling

infrastructure while migrating to Fast Ethernet.

Figure 1.1 100BASE-T Media Speciﬁcations

10 Mbit/s Ethernet

100 Mbit/s Fast Ethernet

CSMA/CD

MAC

CSMA/CD

MAC

Scaled by 10X

Two-Pair

UTP, STP

(100BASE-TX)

Thick Coax

(10BASE5)

Thin Coax

(10BASE2)

Fiber

(100BASE-FX)

Four-Pair UTP

(100BASE-T4)

Fiber

(10BASE-F)

Twisted-Pair

(10BASE-T)

100BASE-T

1.2.3 E-110 MAC Core and the OSI Model

Figure 1.2 shows how the E-110 MAC ﬁts into the ISO Open Systems

Interconnection (OSI) Reference model. The OSI model deﬁnes a data

communications protocol consisting of seven distinct layers.

1-6

Introduction

Figure 1.2 E-110 MAC Relationship to the OSI Model

OSI

Reference

Model

LAN

CSMA/CD

Layers

Higher Layers

LLC

Application (7)

Presentation (6)

E-110

MAC

Core

MAC

Session (5)

Reconciliation

Transport (4)

MII

Network (3)

PCS

PMA

PHY

Data Link (2)

PMD

Physical (1)

MDI

Medium

LLC = logical link control

MAC = media access control

PCS = physical coding sublayer

PHY = physical layer device

MDI = media-dependent interface PMA = physical medium attachment

MII = media-independent interface PMD = physical medium dependent

Overviews of the operation of the MAC core, MAC control module core,

and the MIIM core are found later in this chapter.

1.2.4 Fast Ethernet Hubs

A hub is a common wiring point for star-topology networks, and can

perform various functions, such as switching, statistics gathering, and

signal retiming.

The E-110 core provides a high-integration solution to hub design

because several cores may be placed on a single ASIC. Figure 1.3

illustrates how hubs might be conﬁgured using the E-110 core.

Fast Ethernet (100 Mbit/s)

1-7

Figure 1.3 Hub Examples

a

100 Mbit/s

Switching Hub

E-110

Core

E-110

Core

E-110

Core

100 Mbit/s

10/100 Mbit/s

Multiport

Switching Hub

E-110

Core

E-110

Core

10 Mbit/s

Multiport

Switching Hub

100 Mbit/s

10 Mbit/s

E-110

Core

E-110

Core

E-110

Core

Workstation

10 Mbit/s

PC

10 Mbit/s

100 Mbit/s

Multiport

Switching Hub

E-110

Core

PC

E-110

Core

PC

E-110

Core

PC

100 Mbit/s

PC

100 Mbit/s

Workstation

A switching hub facilitates packet switching. Each port of a packet

switching hub provides a connection to an Ethernet media system that

operates as a separate Ethernet LAN. Unlike a repeater hub whose

individual ports combine segments together to create a single large LAN,

a switching hub makes it possible to divide a set of Ethernet media

systems into multiple LANs that are linked together by way of the packet

switching electronics in the hub. The round trip timing rules for each LAN

stop at the switching hub port, allowing you to link a large number of

1-8

Introduction

individual Ethernet LANs together. A given Ethernet LAN can consist of

a single cable segment linking some number of computers, or it may

consist of a repeater hub linking several such media segments together.

Whole Ethernet LANs can themselves be linked together to form

extended network systems using packet switching hubs. While an

individual Ethernet LAN may typically support anywhere from a few up

to several dozen computers, the total system of Ethernet LANs linked

with packet switches at a given site may support many hundreds or

thousands of machines.

A switching hub can be designed with an intelligent switching fabric and

multiple E-110 cores. The switching may be done in any of the following

manners:

•

Cut-Through–the head of the frame leaves the switch before the tail

has arrived. You use an address compare buffer to decode the

destination address.

•

Store and Forward–the entire frame is received and buffered before

being forwarded to an output port.

Adaptive Cut-Through–the hub looks at collision statistics. If too

many collisions occur, the hub changes from cut-through operation

to store and forward operation.

Figure 1.4 shows where the E-110 core ﬁts in a switched hub.

Fast Ethernet (100 Mbit/s)

1-9

Figure 1.4 Switched Hub Example

2

3

4

5

1

6

Port 1 connected to port 3

Port 4 connected to port 2

Port 6 connected to port 5

Switching Fabric (ASIC)

Switched Hub

Switching Fabric Details

MII

E-110

Core

E-110

Core

E-110

Core

Switching Intelligence, Buffering, Store and Forward

1.2.5 Fast Ethernet Network Interface Cards

Network cards can be designed with the E-110 core that will run at

speeds of 10 or 100 Mbits/s. Figure 1.5 shows how the E-110 core ﬁts

into a network interface card (NIC). The E-110 core provides the MAC

function and interfaces with 10 Mbit/s or 100 Mbit/s PHYs for single- or

multipoint server solutions.

1-10

Introduction

Figure 1.5 Network Interface Card Block Diagram

Customer ASIC

PHY

E-110 Core–MAC and MIIM

10 or 100 Mbits/s

Twisted-Pair or

Fiber-Optic

Media

Host Interface

Edge Connector to PC

1.3 VLAN Support

The E-110 core supports Virtual Local Area Network (VLAN) operation.

It is compatible with the provisions of the IEEE 802.3ac-1998

speciﬁcation, which deﬁnes the MAC frame extensions for virtual bridged

local area network (VLAN) tagging on 802.3 networks. The

IEEE P802.1Q speciﬁcation is the full VLAN document.

VLAN Support

1-11

1.4 E-110 Core

As shown in Figure 1.6, the E-110 core contains the following cores:

•

MAC

MAC Control Module (optional)

MIIM (optional)

SMII (optional)

Figure 1.6 E-110 ASIC Environment

SMSIMI- II-

E-110 Core

oroMrIMI- II-

Supported

CoCreore

1

MII/SMII

Transmit

Data

MAC Core

Transmit

Logic

Transmit

Function

MAC

SMII

Core

SMII

Core

Control

Module

100BASE-T

Media

4

3

Core

Host

MII/SMII

Receive

Data

Receive

Function

Receive

Logic

MIIM

Data

Control/Status

= optional

2

MIIM Core

1. The MAC is capable of 10 or 100 Mbit/s operation.

2. An optional MIIM core reads PHY status registers and writes PHY control registers.

3. An optional MAC control module core provides the ﬂow control functions.

4. An optional SMII module provides a serial MII interface to a PHY with a compatible interface.

1-12

Introduction

1

The MAC core operates at 10 or 100 Mbits/s using an external PHY. An

optional MAC control module core located external to the E-110 core

allows the host to perform the ﬂow control functions given in the

IEEE 802.3/802.3u standard. An optional MIIM core allows a host to

communicate with the control and status registers within an

MII-supported PHY.

1.5 E-110 MAC Core

The E-110 MAC core consists of the transmit and receive functions.

The transmit and receive functions transport data between the MAC

function’s host interface and the SMII/MII. Data consists of bytes on the

host side and nibbles on the MII side. The host provides some data

buffering and logic to manage properly the receive and transmit data

streams. The SMII/MII is a logical data interface only. The user must

provide line drivers and receivers to meet cable interface or attachment

unit interface requirements.

1.5.1 MAC Core Host System Connection

The E-110 MAC core is connected to a host system as shown in

Figure 1.7. The following host connections are explained in this section:

•

System Data Flow

Statistics Vectors Interface

Host Processor Interface

1. The MAC function meets the requirements of the IEEE 802.3u speciﬁcation.

E-110 MAC Core

1-13

Figure 1.7 E-110 MAC Host System Connection

E-110 MAC Function

Host Processor Statistics Vectors

Interface

Receive

Byte Stream

Transmit

Byte Stream

and Control

Address

Recognition

Logic

Receive

Logic

Transmit

Logic

Data/Control

Data

Host System

User-Speciﬁc Functions

1.5.1.1 System Data Flow

The E-110 MAC operates at either 10 or 100 Mbits/s between an

SMII/MII on one side and a host on the other. The receive and transmit

data streams are independent from each other on both sides of the MAC.

The receive byte stream from the E-110 MAC operates on the SMII/MII

receive clock. Another element of the overall system may assemble bytes

from the receive byte stream into words for storage in a buffer memory

or transmission to a system bus. Alternatively, the receive byte stream

might enter directly into a FIFO. The output of the FIFO could then be

interfaced into the overall system in a variety of ways, possibly using a

common system clock.

The transmit byte stream for the E-110 MAC operates on the SMII/MII

transmit clock. Another element of the overall system may disassemble

words read from a buffer memory or received from a system bus into

bytes for the transmit byte stream. Alternatively, the transmit byte stream

might exit directly from a FIFO. The input of the FIFO could then be fed

1-14

Introduction

from the overall system in a variety of ways, possibly using a common

system clock.

Logic associated with the transmit and receive byte streams handles the

packet and data ﬂow control between the overall system and the E-110

MAC. Speciﬁcally, a device external to the E-110 MAC must monitor the

receive byte stream to perform receive address recognition.

Details of the receive byte stream interface can be found in

Section 3.2.1.2, “MAC Receive Function,” on page 3-13. An explanation

of the transmit byte stream interface can be found in Section 3.2.1.1,

“MAC Transmit Function,” on page 3-5. E-110 MAC behavior can be

altered with external control signals. A description of the control signals

is given in Chapter 2.

1.5.1.2 Statistics Vectors Interface

The E-110 MAC collects packet-by-packet statistics, but does not include

statistics event counters or accumulating byte counters. Statistics for

management purposes are collected outside the E-110 MAC for either

end station or multiple channel applications.

Figure 1.8 shows how a centralized statistics collector for use with

multiple E-110 MACs might be constructed.

E-110 MAC Core

1-15

Figure 1.8 Centralized Statistics Updater

Channel 1

User-Speciﬁc

Functions

Transmit

Statistics

Vector

Transmit Statistics

Vector Latch

E-110

MAC

Receive

Statistics

Vector

Receive Statistics

Vector Latch

•

Statistics

Updater

Synchronizer

Statistics

Storage

Arbiter

Channel N

User-Speciﬁc

Functions

Transmit

Statistics

Vector

Transmit Statistics

Vector Latch

E-110

MAC

Receive

Statistics

Vector

Receive Statistics

Vector Latch

Host System

Processor Interface

Host System

Processor

Whenever the E-110 MAC receive and transmit functions complete the

processing of a packet, the MAC creates a transmit or a receive statistics

vector that may be latched external to the MAC function for use by the

statistics updating process. Because the vector is latched, the receive

and transmit functions do not hold the statistics vectors indeﬁnitely. It

then becomes the responsibility of the host to free up enough statistics

storage space before the MAC overwrites the vectors with those for the

next processed packet.

When the MAC latches the receive and transmit statistics vectors, the

MAC provides synchronized latching signals for each of the transmit and

receive vectors. The vectors include Packet Length bits that specify the

length of the packet in bytes. In the example block diagram of Figure 1.8,

the Statistics Updater Synchronizer feeds the Arbiter, which schedules

the updating of statistics in the Statistics Storage. The statistics

subsystem usually operates on the host system microprocessor clock,

1-16

Introduction

which means that accesses to the statistics storage by the host are

automatically synchronized. However, the transmit and receive statistics

vector latch pulse must be synchronized to the host system clock

because the transmit and receive functions operate on their own clocks.

1.5.1.3 Host Processor Interface

The host system processor has the following connections to the E-110

MAC:

•

MII Data Interface (or optional SMII Data Interface)

Random Number Generator Interface

Control Interface

Statistics Interface

MII Data Interface – The E-110 MAC sends and receives data to the

MII-supported PHY by means of the MII or optional SMII Transmit Data

and Receive Data signal lines, over which the MAC passes transmit and

receive nibbles.

Random Number Generator Interface – The E-110 MAC contains a

random number generator that is used for transmit backoff in the event

of a collision. The host may optionally load an 11-bit seed value into the

random number generator. By loading different seed values into each

E-110 MAC in a multiple-MAC system, you can guarantee that the

backoff timers in each MAC are not synchronized to each other, which

avoids the problem of two or more MACs colliding repeatedly while

attempting to transmit. If you do not load a seed value in the random

number generator, there is a chance that two MACs might have the same

backoff timer value.

Control Interface – The host control interface allows the host to directly

control the operation of the E-110 MAC. The host must provide either a

25 or 33 MHz clock (HCLK) to the core. The core uses the clock select

(CLKS) input signal from the host to determine how to divide HCLK to

create the MIIM Data Clock (MDC) signal. The host provides a variety of

control signals to the MAC function to control the following:

•

Interpacket gaps (see Section 3.2.1.1, “MAC Transmit Function,” and

the signal descriptions for IPGR1[6:0], IPGR2[6:0], and IPGT[6:0] in

Chapter 2).

E-110 MAC Core

1-17

•

Padding of packets (see the subsection entitled “IPG Full-Duplex

Operation” and the signal descriptions for NOPRE and PADEN in

Chapter 2).

•

Preamble (see the subsection entitled “IPG Full-Duplex Operation”

and the signal description for NOPRE in Chapter 2).

Full duplex operation (see the subsection entitled “IPG Full-Duplex

Operation” the signal description for FULLD under Section 2.1.4,

“SMII/MII to PHY Signals,” and the signal description for FULLD in

Chapter 2).

•

Frame check sequence (FCS) checking (see the subsection entitled

“IPG Full-Duplex Operation” Section 3.2.1.2, “MAC Receive

Function,” the subsection entitled “Receive Function to Host

Interface” and the signal descriptions for CRCO[9:1], CRCG,

CRCEN, and NOPRE in Chapter 2).

•

Maximum packet length (see the subsection entitled “IPG Full-Duplex

Operation” Section 3.2.1.2, “MAC Receive Function,” and the signal

description for HUGEN in Chapter 2).

Late collisions (see the subsection entitled “IPG Full-Duplex

Operation” and the signal description for TPAB and RTRYL in

Chapter 2).

10 or 100 Mbit/s operation (see Table 3.2).

Statistics Interface – The E-110 MAC function provides receive and

transmit statistics data that can be latched by a device external to the

function and then read by the host. The MAC function provides the

information on a parallel interface along with strobe signals.

1.5.2 MAC Multiple Channel Operation

While the E-110 MAC function can be used in a single-channel

environment as shown in Figure 1.6, the same design can also be used

for multiple channel applications as shown in Figure 1.9.

1-18

Introduction

Figure 1.9 Multiple Channel Application

MII

E-110 MAC

PHY

MII

Common

1

Functions

Common Host Interface

1. Data transport, address recognition, and statistics collection.

The exact nature of the common sections in Figure 1.9 is highly

application dependent. The SMII/MII signal lines are only logical

implementations without the line driving capability.

1.5.3 MAC External Interfaces

The E-110 MAC operates at either 10 Mbits/s or 100 Mbits/s between an

SMII/MII on one side and a system data transport on the other. The

system designer can design the E-110 MAC into both end station, switch,

and hub environments. For system efﬁciency in multiple MAC situations,

you may provide a module external to the MAC function to collect

statistics on MAC events and perform receive packet address

recognition. Statistics collection and receive packet address recognition

are customer deﬁned for use with the E-110 MAC. Figure 1.10 illustrates

the connections to the E-110 MAC function.

E-110 MAC Core

1-19

Figure 1.10 External Connections to the E-110 MAC

Statistics Collection

Address Recognition

Host

System Data Transport

MII

E-110 MAC

MII Control

For simplicity of application, all per packet interactions (for example, start

of frame and end of frame) between the E-110 MAC and the system take

place through the system data transport. Using the system data transport

eliminates the need for involvement of a processor at 100 Mbits/s

because the E-110 MAC takes over the per packet data transfer

responsibility.

The E-110 MAC conforms to existing IEEE 802.3 standards for 10 Mbit/s

operation and IEEE 802.3u standards for 100 Mbit/s operation. It is

expected that a common application of the E-110 MAC will be as a part

of a larger system in user-speciﬁc ASICs. The E-110 MAC therefore

imposes very little system personality regarding word size, byte order,

data ﬂow methodology, or management conventions. Alternatively, the

E-110 MAC can be combined with a minimum of logic circuitry connected

to off-chip interfaces to conﬁgure a unique MAC device.

To allow for a variety of network media types and methods of connection

to the media, the SMII/MII standard has been adopted for the E-110

MAC. The E-110 MAC uses the SMII/MII on a logical basis only. Any

implementation of the E-110 MAC can be used to connect copper wire or

fiber media by means of a PHY. The PHY can reside either within the

same ASIC as the E-110 MAC or external to the ASIC, as long as the

PHY interface to the E-110 MAC is SMII/MII-compatible.

The E-110 MAC function transmits and receives nibbles of data to and

from the media over the SMII/MII signal lines. The function handles

independent receive and transmit byte streams between SMII/MII

devices and the host. On the host side of the E-110 MAC, the byte

streams can be directed into a system memory or bus structure in a

variety of ways, such as shared or separate DMA channels or direct

access to multiple port memories and FIFOs. The byte streams can also

be assembled into system words as desired.

1-20

Introduction

Management statistics collection is not included in the E-110 MAC. To

facilitate statistics collection, the MAC function incorporates statistics

vector circuitry to simplify the accumulation of event statistics. If statistics

collection logic is desired, internal or external to the ASIC, it must be

designed and implemented by the end user.

To allow for simple end station and complex switching hub environments,

you may add receive packet address recognition logic external to the

MAC function. LSI Logic does not supply the address recognition logic.

For end station applications, a simple single station address comparison

module can be attached to the receive byte stream. A hashing multicast

capability can also be included in this module to detect sets of

destination addresses. For switching hub applications, a central source

and destination address ﬁlter block is often the preferred solution. The

E-110 MAC function transmit and receive byte streams can interact with

such a block.

1.5.4 MAC SMII/MII

The E-110 MAC operates with the MII or optional SMII signal lines

connecting to physical media interface (PHY) devices. The SMII/MII is a

logical data interface only. The designer must provide line drivers and

receivers to meet cable interface or AUI requirements.

Figure 1.11 shows that a processor can control a PHY through an E-110

MAC that incorporates an MII function.

E-110 MAC Core

1-21

Figure 1.11 MII Function

E-110 Core

MII

Signals

1

8

Transmit

Function

4-bits/25 MHz or

2

4-bits/2.5 MHz

External

PHY

(MII or PMD)

MAC

MII

Signals

1

8

4-bits/25 MHz or

Receive

Function

2

4-bits/2.5 MHz

Notes:

1. 4-bits/25 MHz means that the data path is 4-bits wide (a nibble) and that

the clock rate is 25 MHz, which yields 100 Mbits/s

2. 4-bits/2.5 MHz means that the data path is 4-bits wide (a nibble) and that the clock

rate is 2.5 MHz, which yields 10 Mbits/s

As new MII PHYs become available, they can be attached to the E-110

MAC, providing increased capability at both 10 Mbits/s and 100 Mbits/s.

You can continue to interface to the PHYs by means of the E-110 MAC’s

built-in MII function.

Figure 1.12 shows that a processor can control a PHY through an E-110

MAC that incorporates an optional SMII core.

1-22

Introduction

Figure 1.12 SMII Core (Optional)

E-110 Core

MII

Signals

MII

Signals

1

1-bit/125 MHz

8

Transmit

Function

SMII

Interface

SMII

Core

SMII

Core

External

PHY

(MII/SMII)

MAC

(optional)

MII

Signals

MII

Signals

1

8

1-bit/125 MHz

Receive

Function

Notes:

1. The SMII interface operates at a clock rate of 125 MHz for both the 10 Mbit/s and 100 Mbit/s

modes. Transmit and receive operations consist of 10-bit segments (2 control bits and 8 data bits).

In 10 Mbit/s mode, each 10-bit segment repeats 10 times and the MAC can sample any of the

10 segments. In 100 Mbit/s mode, there is a single 10-bit segment transferred.

1.5.5 MAC Backoff Operation

When a data collision occurs, the MAC must perform a backoff operation,

which causes the MAC to wait for a time and then try retransmitting. The

MAC implements two selectable backoff methods:

•

Stop Backoff

Truncate Backoff

1.5.5.1 Stop Backoff

The Stop Backoff feature is implemented with the TBOFF_SEL input pin.

The TBOFF_SEL input, driven by the host, controls whether the E-110

core uses the Binary Exponential Backoff algorithm during collisions. See

Chapter 2 for a detailed signal description.

The stop backoff implementation does not conform to the

IEEE 802.3/802.3u standard, but may be useful for test purposes.

E-110 MAC Core

1-23

1.5.5.2 Truncate Backoff

The truncate backoff feature is implemented with the BKOFF_LIMIT[1:0]

input pins, which are driven by the host. The truncate backoff feature

gives the user some ﬂexibility in achieving a performance advantage in

some native applications. With the truncate backoff feature, the E-110

core can be conﬁgured for either more or less aggressive backoff

behavior, depending on the user’s choice. See Chapter 2, for a detailed

signal description.

1.5.6 MAC Backpressure Feature

The MAC core implements a backpressure feature, which is implemented

with the False Carrier Sense (FLS_CRS) input pin. The pin is driven by

the host, and is applicable when the E-110 MAC core is used in a

half-duplex switched port design.

When using a switch (rather than a repeater) as the hub for an Ethernet

LAN, it is possible for trafﬁc to arrive at a switched port faster than the

switch is able to transmit the trafﬁc out to the target destination port.

Making the channel appear busy to the transmitter is an effective and

efﬁcient way of stopping the transmitter from ﬂooding the receiver’s

buffers. The use of the FLS_CRS signal is especially clean when only

one end station is connected to each switch port—in these cases,

FLS_CRS throttles the end station as needed.

See Chapter 2, for a detailed signal description of the FLS_CRS signal.

1.6 MAC Control Module Core

The MAC control module is an optional core that interfaces the E-110

core to the host and implements full-duplex ﬂow control.

In full-duplex Ethernet, neither False Carrier Sense nor forced collision

algorithms solve congestion control problems. A full-duplex Ethernet

station does not implement collision detection and ignores Carrier Sense

for deferring transmissions. A full-duplex Ethernet implementation

therefore requires an explicit ﬂow control mechanism to allow a switch to

throttle a congesting end station. Clause 31 in the IEEE 802.3/802.3u

standard deﬁnes the frame-based ﬂow control scheme implemented in

the MAC control module core.

1-24

Introduction

1.7 MIIM Core

For 10 Mbit/s and 100 Mbit/s operation, the optional MIIM core allows the

host to write control data to and read status information from any of 32

registers in any of 32 PHYs using the MIIM interface. Only one register

in one PHY can be addressed at the same time.

For 10 Gbit/s operation, the MIIM core allows the host to write control

data to and read status information from 10 Gbit/s PHYS. The MIIM core

can select up to 32 ports with up to 32 unique PHY devices per port.

1

There can also be up to 64 K registers per PHY.

The MIIM interface is a 16-bit parallel interface on the MIIM core’s host

side and a serial interface on the core’s MII side. The MIIM Interface

allows the host to send control data and receive status information from

PHYs over the MAC MIIM interface.

For more details on the communication from the host to the PHYs, refer

to the “Reconciliation Sublayer and Media Independent Interface

Speciﬁcations” section of the IEEE 802.3u speciﬁcation, 100BASE-T

Fast Ethernet. The host sends control data to the PHY and receives

status information from the PHY through the optional MIIM module, as

shown in Figure 1.13.

Figure 1.13 MIIM Core

MIIM-Supported

MII

Management

Data

PHY

Host Control

and Status Lines

MII

Management

(MIIM)

Host

Registers

Core

1. At the time of this writing, the 10 Gbit PHY register deﬁnitions have not been ﬁnalized.

MIIM Core

1-25

1.8 SMII Core

The optional Serial Media Independent Interface (SMII) core is designed

to satisfy the following requirements:

•

Convey complete standard MII information between a 10/100 PHY

and MAC with two pins per port

•

Allow a multiport MAC/PHY communication with one system clock.

Operate in both half- and full-duplex

Per packet switching between 10 Mbits and 100 Mbits/s data rates.

Allow direct MAC to MAC communication

Optional source synchronous mode

The MAC sends and receives data and control to and from the SMII core.

The SMII core uses a single Tx Data line to send 10-bit data segments

to the PHY. The Tx Data segment includes 8 bits of data and two MII

control bits (TX_ER and TX_EN). The core also uses a single Rx Data

line to receive 10-bit data segments from the PHY. The Rx Data segment

includes 8 bits of data and two MII status bits (CRS and RX_DV). An

external clock provides 125 MHz clock signals to the SMII core and to

the PHY. Figure 1.14 shows how the SMII core interfaces to the MAC and

PHY devices.

Figure 1.14 SMII Core

Serial Tx Data

Serial Rx Data

Control/Data

MAC

SMII

Core

(optional)

PHY

Control

125 MHz

Clock

Source

Host

1-26

Introduction

Chapter 2

Signal Descriptions

This chapter provides detailed descriptions of the signals for the E-110

core. These signal descriptions are useful for designers who will be

interfacing the E-110 core with other core logic or external logic. This

chapter contains the following sections:

•

Section 2.1, “MAC Core Signals,” page 2-1

Section 2.2, “MAC Control Module Signals,” page 2-31

Section 2.3, “MIIM Core Signals,” page 2-39

Section 2.4, “SMII Core Signals,” page 2-45

Please see the subsection entitled “Conventions Used in This Manual”

on page iv of this manual for a description of how signals are named.

2.1 MAC Core Signals

The interface diagram for the E-110 MAC core is shown in Figure 2.1.

The MAC signals fall into the following groups:

•

Transmit Function to Host

Receive Function to Host

MAC Control Module

SMII/MII to PHY

Host Control

Statistics Vector to Host

Random Number Generator to Host

Scan Test

Ethernet-110 Core Technical Manual

2-1

Figure 2.1 E-110 MAC Core Interface Diagram

TPD[7:0]

TPEF

MCOL

MCRS

TPRT

MRXC

TPUD

MRXD[3:0]

MRXDV

MRXER

MTXC

Transmit

Function to

Host Signals

1

SMII/MII to

PHY SIgnals

TPSF

TPUR

1

TRST_L

MTXD[3:0]

MTXEN

MTXER

1

TPDN

1

TPAB

RSV[27:0]

TSV[30:0]

TSVP_L

Statistics

Vectors to

Host Signals

BCO

BYTE7

Random Number

Generator to

Host Signals

HWD[10:0]

LRNG

CFI

CRCG

CRCO[9:1]

MCO

E-110

MAC Core

TMODE

PRIORITY[2:0]

TEST_SE

TEST_SI

TEST_SO

Scan Test

Signals

1

RPD[7:0]

Receive

Function to

Host Signals

1

RPDV

1

RPEF

1

RPSF

BKOFF_LIMIT[1:0]

CRCEN

RPVID[11:0]

1

RRST_L

FLS_CRS

FULLD

RSVP_L

1

RSV_GOOD

HRST_L

HUGEN

VLAN_PKT

HUGE_SIZE[15:0]

IPGR1[6:0]

IPGR2[6:0]

IPGT[6:0]

NOPRE

Host Control

Signals

PADEN

RTRYL

TBOFF_SEL

VLAN_EN

1. These signals are also connected to the optional MAC control module core, if it is used.

2-2

Signal Descriptions

2.1.1 Transmit Function to Host Signals

Below is a list of the signals between the E-110 MAC transmit function

and the host transmit buffer. All signals are active HIGH unless otherwise

noted. All signals are synchronous with the rising edge of the MII PHY

transmit clock (MTXC). Signal direction is with respect to the transmit

function block. See Section 3.2.1.1, “MAC Transmit Function,” on

page 3-5 for further details on transmit buffer and transmit function

interaction.

TPAB

Transmit Packet Abort

Output

When asserted, the TPAB signal indicates that the

transmission was discontinued. TPAB remains asserted

until the E-110 MAC function receives a request to

transmit, which is indicated when the MAC control

module asserts TPSF. When deasserted, TPAB indicates

that the transmission was not aborted. The following

circumstances cause the transmission to be halted:

•

Excess deferrals, which occur when the media is busy

longer than twice the maximum frame length (greater

1

than 24,288 bits when the HUGEN signal is

2

deasserted or greater than 524,288 bits when

HUGEN is asserted)

•

Late collision (use RTRYL to avoid aborting)

Multiple collisions (greater than 15)

Transmit underrun

Larger than normal packet, which is 1518 bytes (see

also the HUGEN signal description)

The TPAB signal is also connected to the optional MAC

control module core.

TPD[7:0]

Transmit Packet Data

Input

The TPD[7:0] signals are the transmit data bus. The host

must hold the TPD[7:0] signals valid for exactly two

MTXC clock cycles.

1. 24,288 bits = 1518 bytes x 8 bits/byte x 2 (242.88 µs for 100 Mbit/s operation or 2.4288 ms

for 10 Mbit/s operation)

2. 524,288 bits = 32 Kbytes x 8 bits/byte x 2 (5242.88 µs for 100 Mbit/s operation or 52.43 ms

for 10 Mbit/s operation)

MAC Core Signals

2-3

TPDN

Transmit Packet Done

Output

When asserted, the TPDN signal indicates successful

completion of the packet transmit process. The MAC

keeps TPDN asserted until the MAC receives a fresh

request to transmit, which is indicated when the MAC

control module asserts the TPSF signal. The TPDN

signal is also connected to the optional MAC control

module core.

TPEF

TPRT

Transmit Packet End of Frame

Input

The host asserts the TPEF signal to indicate the last byte

of the transmit packet is available from the host. TPEF

must be valid for two MTXC clock periods before it is

deasserted.

Transmit Packet Retry

Output

The MAC asserts the TPRT signal to indicate that the

MAC function encountered at least one collision during a

transmit attempt. The MAC asserts TPRT until the MAC

receives a fresh request to transmit, which is indicated

when the MAC control module asserts TPSF.

TPSF

Transmit Packet Start Of Frame

Input

The MAC control module, if implemented, asserts the

TPSF signal to request the E-110 core to transmit a new

packet. If the MAC control module is not implemented,

the host must assert the TPSF signal.

This paragraph describes how the host must control the

TPSF signal. The host interface asserts the TPSF signal

to request the MAC to transmit a new packet. The host

must keep the TPSF signal asserted for one transmit

clock period after the E-110 core asserts the TPUD

signal. The TPSF signal is synchronous to MTXC.

For a description of how the MAC control module controls

the TPSF signal, see Section 2.1.3, “MAC Control

Module Signals (Optional)” on page 2-9.

TPUD

Transmit Packet Data Used

Output

The E-110 MAC function asserts the TPUD signal to

indicate that the preamble has been transmitted. Every

two clocks thereafter, the host must place the TPD[7:0]

signals on the bus for the MAC. The MAC keeps TPUD

asserted until the MAC accepts all the data bytes in the

transmit packet from the host.

2-4

Signal Descriptions

TPUR

Transmit Packet Data Underrun

Input

When the TPUR signal is asserted, the E-110 MAC

function discontinues transmission. If the host is unable

to supply transmit packet data bytes in a timely manner

to the E-110 core (an underrun condition), the host must

assert TPUR.

The host must assert TPUR for at least two MTXC clock

cycles. The MAC asserts TPAB and MTXER in the very

next clock cycle and deasserts MTXEN one cycle after

TPAB and MTXER are asserted. MTXEN deasserted

indicates the end of transmission.

TRST_L

Transmit Reset

Output

Other modules in an ASIC can use the TRST_L signal as

a host reset synchronized to the transmit clock (MTXC).

Because the MTXC clock can be slow with respect to a

host reset pulse, or even stopped, the host reset signal

(HRST_L) is captured in the E-110 MAC transmit

function. The transmit function asserts TRST_L

asynchronously to MTXC when the HRST_L signal

occurs and deasserts TRST_L synchronously on the

positive transition of MTXC. Modules can use TRST_L to

initialize transmit logic. The TRST_L signal is also

connected to the optional MAC control module core.

2.1.2 Receive Function to Host Signals

Below is a list of the signals between the E-110 MAC receive function

and the host receive logic. All signals are active HIGH unless otherwise

noted. All signals are synchronous with the MRXC rising edge. Signal

direction is with respect to the receive function block. See

Section 3.2.1.2, “MAC Receive Function,” on page 3-13 for further details

on receive buffer and receive function interaction by means of these

signals.

BCO

Broadcast Out

Output

When asserted, the BCO signal indicates that the

received packet is a broadcast packet. A broadcast

packet has the destination address ﬁeld set to all ones,

which indicates it is being sent to all destinations on the

network. When deasserted, BCO indicates that the

received packet is not a broadcast packet. BYTE7 must

be asserted for this output to be valid.

MAC Core Signals

2-5

BYTE7

CFI

Byte 7

Output

When asserted, the BYTE7 signal indicates that the BCO

and MCO bits are valid. When deasserted, the BYTE7

signal indicates that the BCO and MCO signals are not

valid.

Canonical Format Indicator

Output

The CFI signal, when asserted, indicates that the RIF

ﬁeld is present in the tag header. When the CFI signal is

asserted, the NCFI bit in the RIF ﬁeld determines

whether any MAC address information in the MAC

header is in noncanonical or canonical format.

VLAN_PKT must be asserted for CFI to be valid.

When deasserted, the CFI signal indicates that the RIF

ﬁeld is not present in the tag header, and that all MAC

address information in the MAC header is in canonical

format.

The CFI signal is extracted from the TCI ﬁeld of the

current received packet.

For more information regarding the RIF ﬁeld in the tag

header and the NCFI bit in that ﬁeld, see the

IEEE P802.1Q document.

CRCG

CRC Good

Output

The CRCG signal, when asserted, indicates that the

CRCO[9:1] signals are valid. The CRCG signal, when

deasserted, indicates that the CRCO[9:1] signals are not

valid.

CRCO[9:1]

CRC Out

Output

The CRCO[9:1] signals reﬂect the state of the receive

function FCS register after the ﬁrst six bytes of the

receive packet have been received. When the destination

address bits that are received in the frame contain a

multicast address, the E-110 core uses its built-in FCS

generator to compute a nine-bit polynomial (the nine

MSBs of the 32-bit FCS generator) from the incoming

address. The value of this polynomial can be used as an

index into an external multicast ﬁlter hash table. External

logic can decide to either accept or reject the incoming

frame.

2-6

Signal Descriptions

MCO

Multicast Out

Output

When asserted, the MCO signal indicates that the

received packet is a multicast packet (a packet that is

being sent to selected stations on the network). When

deasserted, MCO indicates that the received packet is

not a multicast packet, which means that it could be an

individual or broadcast packet. BYTE7 must be asserted

for MCO to be valid.

PRIORITY[2:0]

User Priority

Output

This ﬁeld contains the user priority of the current received

packet, extracted from the tag control information (TCI)

ﬁeld. VLAN_PKT must be asserted for PRIORITY[2:0] to

be valid.

RPD[7:0]

RPDV

Receive Packet Data

Output

The RPD[7:0] signals are the receive data bus. The

signals hold the received data byte for two MRXC clock

cycles. The RPD[7:0] signals are also connected to the

optional MAC control module core.

Receive Packet Data Valid

Output

A packet transmission from the receive function to the

host receive control logic (see Figure 1.6 on page 1-12)

begins when the receive function asserts the RPSF and

RPDV signals at the ﬁrst byte of received packet data on

RPD[7:0] after removing the preamble and SFD. For

subsequent data bytes, the receive function asserts only

the RPDV signal until the last byte, when it asserts both

RPDV and RPEF. See Figure 4.1 on page 4-2 for receive

packet timing. The RPDV signal is also connected to the

optional MAC control module core.

RPEF

RPSF

Receive Packet End of Frame

Output

The MAC asserts the RPEF signal for one MRXC clock

cycle to indicate that the last byte of the receive packet

is available to the MAC control module on RPD[7:0]. The

RPEF signal is also connected to the optional MAC

control module core.

Receive Packet Start of Frame

Output

The MAC asserts the RPSF signal for one MRXC clock

cycle to indicate that the ﬁrst byte of a receive packet is

MAC Core Signals

2-7

available to the host on RPD[7:0]. The RPSF signal is

also connected to the optional MAC control module core.

RRST_L

Receive Reset

Output

Other modules in an ASIC can use the RRST_L signal

as a host reset synchronized to the receive clock

(MRXC). Because the MRXC clock can be slow with

respect to a host reset pulse, or even stopped, the host

reset signal (HRST_L) is captured in the E-110 MAC

receive function, which asserts RRST_L asynchronously

to MRXC when HRST_L occurs and deasserts RRST_L

synchronously on the positive transition of MRXC. The

RRST_L signal is also connected to the optional MAC

control module core.

RPVID[11:0] Received Packet VLAN ID

Output

This ﬁeld contains the VLAN identiﬁer extracted from the

tag control information (TCI) ﬁeld of the current received

packet. If RPVID[11:0] is 0 and VLAN_PKT is asserted,

the current received packet is a priority-tagged frame.

VLAN_PKT must be asserted for RPVID[11:0] to be valid.

RSVP_L

Receive Statistics Vector Pulse

Output

The RSVP_L signal is active LOW. When the MAC

asserts RSVP_L, it indicates that the RSV[27:0] signals

have been updated with a new receive statistics vector.

When deasserted, it indicates that there has been no

update. The RSVP_L signal is also connected to the

optional MAC control module core.

VLAN_PKT

VLAN Packet

Output

The MAC asserts the VLAN_PKT signal to indicate that

the current received packet has a valid Ethernet-encoded

Tag Protocol Identiﬁer (TPID). The encoded TPID for the

MAC is 81-00. Assertion of VLAN_PKT also indicates

that the CFI, PRIORITY[2:0], and RPVID[11:0] signals

are valid. The MAC deasserts VLAN_PKT at the

beginning of the next packet.

2-8

Signal Descriptions

2.1.3 MAC Control Module Signals (Optional)

Below is a list of the signals that interface between the E-110 core and

the optional MAC control module core. (See also Section 2.2, “MAC

Control Module Signals,” on page 2-31.) All signals are active HIGH

unless otherwise noted. Signal direction is with respect to the

E-110 core.

RPD[7:0]

Receive Packet Data

Output

The RPD[7:0] signals are the receive data bus. The

signals hold the received data byte for two MRXC clock

cycles. The RPD[7:0] signals are also connected to the

host.

RPDV

Receive Packet Data Valid

Output

A packet transmission from the receive function to the

host receive control logic (see Figure 1.6 on page 1-12)

begins when the receive function asserts the RPSF and

RPDV signals at the ﬁrst byte of received packet data on

RPD[7:0] after removing the preamble and SFD. For

subsequent data bytes, the receive function asserts only

the RPDV signal until the last byte, when it asserts both

RPDV and RPEF. See Figure 4.1 on page 4-2 for receive

packet timing. The RPDV signal is also connected to the

host.

RPEF

Receive Packet End of Frame

Output

The MAC asserts the RPEF signal for one MRXC clock

cycle to indicate that the last byte of the receive packet

is available to the MAC control module on RPD[7:0]. The

RPEF signal is also connected to the host.

RPSF

Receive Packet Start of Frame

Output

The MAC asserts the RPSF signal for one MRXC clock

cycle to indicate that the ﬁrst byte of a receive packet is

available to the host on RPD[7:0]. The RPSF signal is

also connected to the host.

RRST_L

Receive Reset

Output

Other modules in an ASIC can use the RRST_L signal

as a host reset synchronized to the receive clock

(MRXC). Because the MRXC clock can be slow with

respect to a host reset pulse, or even stopped, the host

reset signal (HRST_L) is captured in the E-110 MAC

receive function, which asserts RRST_L asynchronously

MAC Core Signals

2-9

to MRXC when HRST_L occurs and deasserts RRST_L

synchronously on the positive transition of MRXC. The

RRST_L signal is also connected to the host.

RSV_GOOD Receive Statistics Vector Good

Output

At the end of a receive frame, the MAC updates the

Receive Statistics Vector (RSV[27:0]). The MAC asserts

the RSV_GOOD signal, which reﬂects the RSV24 bit, if

the received frame has no errors. The MAC deasserts the

signal if the received frame contains errors.

TPAB

Transmit Packet Abort

Output

When asserted, the TPAB signal indicates that the

transmission was discontinued. TPAB remains asserted

until the E-110 MAC function receives a request to

transmit, which is indicated when the MAC control

module asserts TPSF. When deasserted, TPAB indicates

that the transmission was not aborted. The following

circumstances cause the transmission to be halted:

•

Excess deferrals, which occur when the media is busy

longer than twice the maximum frame length (greater

1

than 24,288 bits when the HUGEN signal is

2

deasserted or greater than 524,288 bits when

HUGEN is asserted)

•

Late collision (use RTRYL to avoid aborting)

Multiple collisions (greater than 15)

Transmit underrun

Larger than normal packet, which is 1518 bytes (see

also see the HUGEN signal description)

The TPAB signal is also connected to the host.

TPDN

Transmit Packet Done

Output

When asserted, the TPDN signal indicates successful

completion of the packet transmit process. The MAC

keeps TPDN asserted until the MAC receives a fresh

request to transmit, which is indicated when the MAC

1. 24,288 bits = 1518 bytes x 8 bits/byte x 2 (242.88 µs for 100 Mbit/s operation or 2.4288 ms

for 10 Mbit/s operation)

2. 524,288 bits = 32 Kbytes x 8 bits/byte x 2 (5242.88 µs for 100 Mbit/s operation or 52.43 ms

for 10 Mbit/s operation)

2-10

Signal Descriptions

control module asserts the TPSF signal. The TPDN

signal is also connected to the host.

TPSF

Transmit Packet Start Of Frame

Input

The MAC control module asserts the TPSF signal to

request the E-110 Core to transmit a new packet. Once

asserted, TPSF is kept asserted as long as the

HST_TPSF signal from the host is asserted. On a data

packet transmit request from the host (HST_TPSF

asserted and CTLP deasserted), TPSF is asserted by the

MAC control module only if PAUSE_ACTIVE is

deasserted. The MAC control module does not enter the

pause state because either the pause counter has

counted down to zero or the counter is currently loaded

with a zero value. If the PAUSE_ACTIVE signal is

asserted, TPSF is not asserted until PAUSE_ACTIVE is

deasserted.

If the FLOWCON_EN signal is deasserted, the MAC

control module does not assert the TPSF signal for host

control packet transmit requests. If the FLOWCON_EN

signal is deasserted, the TPSF signal is asserted for host

data packet transmit requests. When FLOWCON_EN is

asserted, TPSF is asserted one clock after HST_TPSF is

asserted for a data or a control packet transmit request.

When FLOWCON_EN is deasserted, TPSF is asserted

at the same clock as when HST_TPSF is asserted for a

data packet request. The MAC control module does not

interpret the transmit data in any way and transmit data

is routed from the host to the E-110 MAC directly.

TRST_L

Transmit Reset

Output

Other modules in an ASIC can use the TRST_L signal as

a host reset synchronized to the transmit clock (MTXC).

Because the MTXC clock can be slow with respect to a

host reset pulse, or even stopped, the host reset signal

(HRST_L) is captured in the E-110 MAC transmit

function. The transmit function asserts TRST_L

asynchronously to MTXC when the HRST_L signal

occurs and deasserts TRST_L synchronously on the

positive transition of MTXC. Modules can use TRST_L to

initialize transmit logic. The TRST_L signal is also

connected to the host.

MAC Core Signals

2-11

2.1.4 SMII/MII to PHY Signals

The signals that interface the MAC MII to the PHY (not including the

MIIM interface) are listed below. All signals are active HIGH. Signal

direction is with respect to the MAC MII function. See IEEE 802.3u

standard documentation for further information. The standard IEEE MII

signal name references are shown in brackets.

MCOL

MCRS

Collision Detected

Input

The PHY asserts the MCOL [COL] signal asynchronously

with minimum delay from the start of a collision on the

media. The PHY deasserts MCOL to indicate no collision.

MCOL is internally synchronized to the MTXC clock and

in the worst case may take up to two clock cycles to be

detected by the MAC transmit function.

Carrier Sense

Input

The PHY asserts the MCRS [CRS] signal

asynchronously with minimum propagation delay from the

detection of a nonidle medium. The PHY deasserts

MCRS when it detects an idle medium. The PHY also

asserts MCRS with minimum propagation delay in

response to MTXEN [TX_EN].

The PHY ensures that MCRS remains asserted

throughout the duration of a collision condition.

MRXC

Receive Nibble or Symbol Clock

Input

The MRXC [RX_CLK] signal is a continuous clock that

provides a timing reference for transfer of the MRXDV

[RX_DV], MRXD[3:0] [RXD], and MRXER [RX_ER]

signals from the PHY to the E-110 MAC. MRXC is an

input from the PHY.

As long as the PHY is receiving a continuous signal from

the medium and can recover the MRXC clock reference

and supply MRXC, the PHY does not need to make a

switch from the recovered clock reference to a nominal

clock reference (for example, the MTXC [TX_CLK]

continuous clock signal from the PHY). However, if the

loss of a receive signal causes the PHY to lose the

recovered clock reference, the PHY must source MXRC

from a nominal clock reference.

If the PHY needs to make a switch from recovered clock

to nominal clock, it deasserts the MRXDV signal. During

2-12

Signal Descriptions

the interval between MCRS and the assertion of MRXDV

at the beginning of a frame, the PHY may extend a cycle

of the MRXC clock by holding it in either the HIGH or

LOW condition until the PHY has successfully locked

onto the recovered clock. Successive cycles of MRXC

must meet the duty cycle requirement.

While MRXDV is asserted, the PHY recovers MRXC from

the received data. MRXC has a frequency equal to 25%

of the data rate of the received signal and is synchronous

to recovered data. The duty cycle is between 35% and

60% and is nominally 50%. For 100 Mbit/s operation,

MRXC is nominally 25 MHz ±100 ppm, and the minimum

MRXC HIGH and LOW times are 14 ns. For 10 Mbit/s

operation, MRXC is nominally 2.5 MHz ± 100 ppm, and

the minimum MRXC HIGH and LOW times are 140 ns.

When the MCRS signal is deasserted, the PHY provides

MRXC at the PHY’s nominal clock rate (for example, the

MTXC clock signal) and with nominal duty cycle. The

minimum HIGH and LOW times are each 35% of the

nominal MRXC period except for the transition between

recovered clock frequency and nominal clock frequency,

which occurs while MRXDV is deasserted. Following the

transition from MRXDV asserted to MRXDV deasserted,

the PHY can keep MRXC in either the HIGH or LOW

condition to extend the MRXC clock by one cycle until the

PHY is ready to provide MRXC from a nominal clock

source. The maximum HIGH or LOW time for MRXC

during this transition is two times the nominal clock period

(a total of 80 ns for 25 MHz operation or 800 ns for

2.5 MHz operation).

MRXD[3:0]

Receive Nibble Data

Input

MRXD[3:0] [RXD] consists of four data signals that the

PHY drives synchronously to the rising edge of the

MRXC clock. For each MRXC period in which MRXDV is

asserted, the PHY transfers four bits of data over the

MRXD[3:0] signals to the E-110 MAC. MRXD[0] is the

least signiﬁcant bit. When MRXDV is deasserted, the

MRXD[3:0] signals have no effect on the E-110 MAC.

For a frame to be correctly interpreted by the E-110 MAC,

a completely formed SFD must be passed across the

interface. A completely formed SFD is the octet

MAC Core Signals

2-13

0b1010.1011, which follows seven identical octets of

preamble (0b1010.1010).

MRXDV

Receive Data Valid

Input

The PHY asserts the MRXDV [RX_DV] signal to indicate

that the PHY is presenting recovered and decoded

nibbles on the MRXD[3:0] [RXD[3:0]] signals and that

MRXC is synchronous to the recovered data. The PHY

asserts MRXDV synchronously to the rising edge of

MRXC. The PHY keeps MRXDV asserted from the ﬁrst

recovered nibble of the frame through the ﬁnal recovered

nibble and deasserts it prior to the ﬁrst MRXC that follows

the ﬁnal nibble. MRXDV encompasses the frame, starting

no later than the SFD and excluding any end of frame

delimiter. The PHY may also assert MRXDV for

transferring a validly decoded preamble.

MRXER

Receive Error

Input

The PHY asserts the MRXER [RX_ER] signal to indicate

to the E-110 MAC that a media error (for example, a

coding error) was detected somewhere in the frame

presently being transferred from the PHY to the E-110

MAC. The PHY asserts MRXER synchronously to the

rising edge of MRXC for one or more MRXC periods and

then deasserts it. The PHY must assert MRXER for at

least one MRXC clock period during the frame.

MTXC

Transmit Nibble or Symbol Clock

Input

The MTXC [TX_CLK] signal operates at a frequency of

25 or 2.5 MHz. MTXC is a continuous clock that provides

a timing reference for transfer of the MTXEN [TX_EN],

MTXD[3:0] [TXD[3:0]], and MTXER [TX_ER] signals from

the E-110 MAC to the PHY. The PHY provides MTXC.

The MTXC frequency is 25% of the transmit data rate. A

PHY operating at 100 Mbits/s provides an MTXC

frequency of 25 MHz ± 100 ppm. A PHY operating at

10 Mbits/s provides a TX_CLK frequency of 2.5 MHz

± 100 ppm. The duty cycle of the TX_CLK signal is

between 35% and 60%, inclusively.

MTXD[3:0]

Transmit Nibble Data

Output

The MTXD[3:0] signals are synchronous to the rising

edge of MTXC.

2-14

Signal Descriptions

MTXD[3:0] [TXD[3:0]] consists of four data signals that

are synchronous to MTXC. For each MTXC period in

which MTXEN is asserted, the PHY accepts the

MTXD[3:0] signals for transmission. MTXD[0] is the least

signiﬁcant bit. When MTXEN is deasserted, the

MTXD[3:0] signals have no effect on the PHY.

MTXEN

Transmit Enable

Output

The MTXEN [TX_EN] signal indicates that the E-110

MAC is presenting MTXD[3:0] nibbles on the MII for

transmission. The MAC asserts MTXEN synchronously

with the ﬁrst nibble of the preamble. MTXEN remains

asserted while all nibbles to be transmitted are presented

to the MII. The MAC deasserts MTXEN prior to the ﬁrst

MTXC following the ﬁnal nibble of a frame. MTXEN is

synchronous to the rising edge of MTXC, and the PHY

samples MTXEN synchronously.

MTXER

Transmit Coding Error

Output

The E-110 MAC function asserts the MTXER [TX_ER]

signal synchronously to the rising edge of MTXC, and the

PHY samples MTXER synchronously. When the MAC

asserts MTXER for one MTXC clock period while MTXEN

is also asserted, MTXER causes the PHY to transmit one

or more symbols that are not part of the valid data or

delimiter set somewhere in the frame being transmitted to

indicate that there has been a transmit coding error. If the

MAC asserts the MTXER signal when a PHY is operating

at 10 Mbits/s or when MTXEN is deasserted, the PHY

must not allow the transmission of data to be affected.

2.1.5 Host Control Signals

The control lines from the host to the MAC core are listed below. All

signals are active HIGH unless otherwise indicated. Signal direction is

with respect to the MAC function. These signals are not synchronized on

a packet boundary within the E-110 MAC. That is, any change in these

signals is immediate, and changing the state of the signals during a

packet can cause unexpected results.

BKOFF_LIMIT[1:0]

Backoff Limit

Input

The BKOFF_LIMIT[1:0] signals determine the number of

transmission attempts the E-110 MAC core makes after

MAC Core Signals

2-15

1

a collision and the integer number of slot times the core

waits before rescheduling a transmission attempt (during

retries after a collision).

When a transmission attempt has terminated due to a

collision, the MAC core retries until either the

transmission is successful or the maximum number of

attempts (16) have been made and all have terminated

due to collisions.The MAC core waits an integer number

of slot times (backoff) before each attempt to retransmit.

The backoff delay, r, before each retransmission attempt

is chosen as a uniformly distributed random integer in the

range:

0 ≤ r < 2^k

The variable k is the retry counter value and is calculated

as follows:

k = min n, 10

The variable n is the current number of retransmissions.

The retry counter value is held to the lesser of the current

number of retransmissions or the value 10.

The following table illustrates the relationship between

the backoff delay and the maximum retry counter value.

Maximum

Backoff

Delay in Slot Retry Counter (k)

BKOFF_LIMIT

1

0

1

0

1

0

1

Times

Maximum Value

0–1023

0–255

0–15

10

8

4

0–3

2

As an example, if the BKOFF_LIMIT[1:0] value is 0b10,

the maximum retry counter value is 4. The E-110 MAC

core retry counter value is zero before any collisions

occur. When a collision occurs, the retry counter

increments to one, and the backoff delay is set to a value

between 0 and 1 slot times. When the backoff delay

1. One slot time equals 512-bit times.

2-16

Signal Descriptions

expires, another transmission attempt is made. If a

collision occurs again, the retry counter goes to two and

the backoff delay is set to between 0 and 3. Assuming a

collision at each attempt, the process continues until the

retry counter reaches four, at which time the backoff

delay is set to between 0 and 15, and the retry counter

rolls over to zero. If the next attempt also encounters a

collision, the retry counter increments to one, and the

backoff value is set to between 0 and 1. If collisions keep

occurring, the MAC core keeps retrying for a total of

16 retransmission attempts and then stops retrying. The

following table summarizes the transmission retry

algorithm for all four cases of BKOFF_LIMIT[1:0].

MAC Core Signals

2-17

The host must assert the BKOFF_LIMIT[1:0] signals

synchronously with the rising edge of MTXC clock. The

effect of these signals is not synchronized on a packet

boundary within the E-110 core and changing the state

of the signals during a packet transmission can cause

unexpected results.

CRCEN

CRC Append Enable

Input

The host asserts the CRCEN signal to instruct the

transmit function to append the FCS calculated by the

MAC to the end of the transmitted data. When the host

deasserts CRCEN, the E-110 core still calculates the

FCS of the transmitted packet data, but allows the FCS

that comes from the host to be transmitted with the

packet. The E-110 core checks the host-generated FCS

to see if it is valid except when the host asserts the

NOPRE signal (see the “NOPRE No Preamble Input”

signal description on page 2-23). If the FCS is not valid,

the E-110 core asserts the FCS error signal (TSV21) in

the Transmit Statistics Vector. CRCEN is synchronous

with the rising edge of the MTXC clock and may be

changed when the transmit engine is idle (either during

reset or when no packet is being transmitted).

FLS_CRS

False Carrier Sense (Backpressure Control)

Input

The host may use the E-110 core FLS_CRS input pin to

implement backpressure (see Section 1.5.6, “MAC

Backpressure Feature,” on page 1-24). Backpressure

makes the medium look busy to other stations on the

network who wish to send data to the E-110 core. The

host asserts the FLS_CRS input when a congestion

threshold for the port’s input buffer is reached. The host

should select the congestion threshold in such a way that

it leaves enough room in the buffer for the frame in

progress. When the FLS_CRS pin is asserted, the E-110

core waits until 44 bit times after the medium becomes

inactive (CRS deasserted) and then starts sending out a

false carrier data pattern (alternate ones and zeroes).

The E-110 core continues sending this data pattern as

long as the host continues to assert the FLS_CRS signal.

If the E-110 core is already sending out normal packet

data on the MII, assertion of the FLS_CRS pin only goes

into effect after the current transmission is completed. If

the E-110 core is already sending out a false carrier data

MAC Core Signals

2-19

pattern on the MII, any transmit requests from the host

are kept pending until the FLS_CRS pin is deasserted. It

is the responsibility of the host to disable the jabber timer

if the E-110 core is being used in the 10BASE-T mode

and if the FLS_CRS pin is asserted for more than 20 ms.

The E-110 core ignores collisions during transmission of

data while the FLS_CRS pin is asserted. Standard

management information related to the Ethernet interface

is not affected by the FLS_CRS signal.

FULLD

Full-Duplex Control

Input

When the host asserts the FULLD signal, the transmit

function operates in full-duplex mode, does not defer to

the CRS signal, and does not respond to the COL signal.

When FULLD is deasserted, the transmit function

operates in half-duplex mode. In half-duplex mode, the

E-110 core defers to CRS and responds to COL. FULLD

may be changed when the system is idle (either during

reset or when both transmit and receive engines are idle).

The host must assert FULLD synchronously to the rising

edge of MTXC.

HRST_L

Host Reset

Input

The HRST_L signal is an active LOW signal that

initializes the MAC function and the MIIM function when

the host asserts it. When HRST_L is asserted, the MAC

asserts the synchronized transmit and receive reset

signals, TRST_L and RRST_L, which are inputs to the

MAC transmit function and receive function, respectively.

Other modules in an ASIC may use these signals for

initialization. Both TRST_L and RRST_L are asserted

LOW asynchronously when HRST_L occurs and are

deasserted synchronously with their respective clocks

(TRST_L with MTXC and RRST_L with MRXC).

The MAC assumes that HRST_L is asynchronous to all

clocks. The minimum reset width is 400 ns for the

100 Mbit/s mode of operation and 4000 ns for the

10 Mbit/s mode.

HUGEN

Huge Packet Enable

Input

A packet consists of the following ﬁelds: Destination

Address (6 bytes), Source Address (6 bytes), Data

Length (two bytes), Data (the 802.3 standard stipulates a

maximum of 1500 bytes), and Frame Check Sequence

2-20

Signal Descriptions

(4 bytes). A packet can therefore be up to 1518 bytes and

meet the 802.3 standard requirements.

However, as applications have evolved over a period of

time, it is required that MAC controllers have the ﬂexibility

to transmit and receive packets of various sizes (in

addition to supporting the conventional maximum packet

sizes speciﬁed by the 802.3 standard).

When asserted, the HUGEN signal indicates to the

transmit function in the E-110 core to allow transmission

of packets up to 32 Kbytes. The E-110 core truncates any

data packet larger than 32 Kbytes. Assertion of the

HUGEN signal also instructs the receive function to

receive packets up to 32 Kbytes. When HUGEN is

asserted, the excess deferral value is changed to

131,072 nibble clocks (524,288 bit times, or two times the

maximum packet size bit times). TSV[15:0] and

RSV[15:0] reﬂect the count of number of bytes

transmitted or received. When HUGEN is deasserted, the

maximum size packet supported by the E-110 core is

1518 bytes. (Note that excess deferral is different this

time as the packet size changes.)

When the MAC transmits a packet, the MAC truncates

any data beyond 1536 bytes (when HUGEN is

deasserted) or 32 Kbytes (when HUGEN is asserted)

and asserts the TSV26 signal (see Section 2.1.6,

“Statistics Vector to Host Signals,” on page 2-24), which

indicates that the packet was aborted because of exces-

sive length. Note that the MAC does not begin truncating

the data immediately after 1518 bytes.

When the MAC receives a packet longer than 1518 bytes

(with HUGEN deasserted), or 32 Kbytes (with HUGEN

asserted), the MAC asserts the RSV23 signal (see

Section 2.1.6, “Statistics Vector to Host Signals”), which

indicates that a bad packet has been received. However,

the MAC continues to accept bytes until 1536 bytes or

32 Kbytes, beyond which it stops accepting bytes.

MAC Core Signals

2-21

HUGE_SIZE[15:0]

Huge Mode Packet Size

Input

The HUGE_SIZE[15:0] signal contains the huge mode

packet size in byte count. Maximum size is 32 Kbytes.

The encoding is shown in the table below.

Packet Size

(Bytes)

HUGE_SIZE[15:0]

0b0000.0000.0000.0000

0

0b0000.0000.0000.0001

1

0b0000.0000.0000.0010

2

0b0000.0000.0000.0011

3

.

0b1000.0000.0000.0000

32 K

IPGR1[6:0]

Non-Back-to-Back IPG (Part 1)

Input

The IPGR1[6:0] signals contain the programmable

transmit interpacket gap (IPG) for non-back-to-back

transmits, Part 1. Non-back-to-back transmits allow a

receive to occur between transmits. The MAC core

samples the IPGR1[6:0] signals synchronously with the

rising edge of the MTXC clock during reset. For a

detailed discussion of the IPGR1[6:0] signals, see “IPG

Half-Duplex Operation” on page 3-7.

IPGR2[6:0]

Non-Back-to-Back IPG (Part 2)

Input

The IPGR2[6:0] signals contain the programmable

transmit IPG for non-back-to-back transmits, Part 2. The

MAC core samples the IPGR2[6:0] signals synchronously

with the rising edge of the MTXC clock during reset. For

a detailed discussion of IPGR2[6:0], see “IPG

Half-Duplex Operation” on page 3-7 and “IPG Full-Duplex

Operation” on page 3-8.

IPGT[6:0]

Back-to-Back IPG

Input

The IPGT[6:0] signals contain the programmable transmit

IPG for back-to-back transmits. Nominal operation

requires that IPGT[6:0] have a value of 18. For a detailed

discussion of IPGT[6:0], see “IPG Half-Duplex Operation”

on page 3-7.

2-22

Signal Descriptions

The MAC core samples the IPGT[6:0] signals

synchronously with the rising edge of the MTXC clock

during reset. For a detailed discussion of IPGT[6:0], see

“IPG Half-Duplex Operation” on page 3-7 and “IPG

Full-Duplex Operation” on page 3-8.

NOPRE

No Preamble

Input

When asserted, the NOPRE signal instructs the transmit

function to disable the addition of the preamble. Padding

and FCS appending are also disabled when NOPRE is

asserted. NOPRE is synchronous with the rising edge of

the MTXC clock and may be changed when the transmit

engine is idle (either during reset or when no packet is

being transmitted). When deasserted, the NOPRE signal

allows the transmit function to add the preamble, perform

byte padding, and do FCS appending.

PADEN

Pad Enable

Input

The PADEN signal, when asserted, instructs the transmit

function to pad packets of fewer than 60 bytes with a

sufﬁcient number of bytes of zero such that the minimum

packet size (64 bytes, including data plus an FCS of

4 bytes) speciﬁed by IEEE 802.3 is maintained. When

deasserted, PADEN disables the padding of packets. For

padding to take place, both PADEN and CRCEN must be

asserted. PADEN is synchronous with the rising edge of

the MTXC clock and may be asserted or deasserted

when the transmit engine is idle (either during reset or

when no packet is being transmitted).

RTRYL

Retry Late Collision

Input

The RTRYL signal, when asserted, instructs the transmit

function to retry transmission after a late collision (a

collision that occurs after 512 bit times into the packet)

instead of aborting it. When deasserted, RETRYL

instructs the E-110 core not to retry a transmission after

a late collision, to reset the retry counter, and to abort the

transmit attempt.

For normal collisions (a collision that occurs fewer than

512 bit times into the packet) the transmit function retries

the transmission up to 15 times before aborting. If late

collisions occur frequently, it may indicate that there is a

problem with the network cabling or equipment. The

TSV29 signal (see Section 2.1.6, “Statistics Vector to

Host Signals,” on page 2-24) in the Transmit Statistics

MAC Core Signals

2-23

Vector, when asserted, indicates the transmission was

dropped because of a late collision.

RTRYL is synchronous with the rising edge of MTXC and

may be asserted or deasserted when the transmit engine

is idle (either during reset or when no packet is being

transmitted).

TBOFF_SEL Stop Backoff

Input

The TBOFF_SEL input signal controls whether or not the

E-110 core uses the binary exponential backoff algorithm

during collisions. If the TBOFF_SEL signal is asserted,

the E-110 core transmits a jam pattern after a collision

and tries to retransmit after timing out for the IPG value.

In this case, the binary exponential backoff algorithm is

not used.

If the TBOFF_SEL signal is deasserted, the E-110 core

implements the binary exponential backoff algorithm. The

E-110 core stops sending packet data, sends a jam

pattern, and tries to transmit again. The amount of time

the E-110 core waits between successive retries is

1

512-bit times x R, where R is a random integer between

k

0 and 2 − 1. K is the retry counter value, which can

range from 1 to 10.

The host must change the TBOFF_SEL signal

synchronously with the rising edge of MTXC clock. The

effect of this signal is not synchronized on a packet

boundary within the E-110 core, so changing the state of

the signal during a packet transmission can cause

unexpected results.

VLAN_EN

VLAN Enable

Input

This signal, when asserted, activates the VLAN features

of the E110 core.

2.1.6 Statistics Vector to Host Signals

The statistics vector signal lines from the MAC are listed below. All

signals are active HIGH unless otherwise indicated. Signal direction is

with respect to the MAC.

1. 51-bit times equals one slot time.

2-24

Signal Descriptions

RSV[27:0]

Receive Statistics Vector

Output

The RSV[27:0] signals contain the receive statistics

vector and are updated on the falling edge of RSVP_L.

The statistics vector is issued at the end of any minimally

qualiﬁed receive event. A minimally qualiﬁed receive

event occurs when the MAC receives at least one nibble

of data beyond a valid preamble and SFD.

The RSV[27:0] signals are stable until the subsequent

RSVP_L pulse. The condition associated with each signal

is valid when the signal is HIGH.

The receive statistics provided by the MAC function can

be used for RMON (remote monitoring) and SNMP

(simple network management protocol). However, the

MAC does not collect the statistics speciﬁcally mentioned

in the RMON and SNMP speciﬁcations. The MAC

provides basic per packet information that can be

collected by an application built on top of the MAC. The

collected information can then be used for RMON and

SNMP.

The signals in RSV[27:0] have the following functions:

RSV27

Oversize packet received. This signal is asserted

when the MAC receives a packet larger than

1518 bytes, or 1522 bytes when VLAN_EN is

asserted in normal mode. When HUGEN is

asserted, RSV27 is asserted if the packet received

is larger than HUGE_SIZE[15:0].

RSV26

RSV25

Receive false carrier sense status. When the

MRXDV signal is deasserted, the MRXER signal is

asserted, and MRXD[3:0] is 0b1110, this bit is set

and reported with the next received packets.

Carrier event previously seen. When the MAC

asserts the RSV25 signal, it indicates that at some

time since the last receive vector a carrier was

detected, noted, and reported with this vector. The

carrier event is not associated with this packet. A

carrier event is deﬁned as activity on the receive

channel that does not result in a packet receive

attempt. An example would be receiving a preamble

but no SFD, or receiving more than seven octets of

preamble. A carrier event can occur in either full- or

half-duplex modes. If RSV25 is deasserted, a carrier

was not detected.

MAC Core Signals

2-25

RSV24

Good packet received. For 100 Mbit/s operation, a

good packet has no 4B/5B receive code-group

violations, no dribble nibbles, a valid FCS, and a

proper packet length (at least 64 bytes but not more

than 1518 bytes or 32 Kbytes). 4B/5B code-group

violations include the following: 0b00100, 0b00000,

0b00001, 0b00010, 0b00011, 0b00101, 0b00110,

0b01000, 0b01100, 0b10000, and 0b11001.

For 10-Mbit/s operation, a good packet has no

dribble nibbles, a valid FCS, and a proper packet

length (at least 64 bytes but not more than

1518 bytes or 32 Kbytes).

RSV23

Bad packet received. For 100-Mbit/s operation, a bad

packet contains at least one of the following

problems: 4B/5B code violations, bad FCS, less than

64 bytes (short packet), or more than 1518 bytes or

32 Kbytes (long packet).

For 10 Mbit/s operation, a bad packet contains at

least one of the following problems: A bad FCS, less

than 64 bytes (short packet), or more than

1518 bytes or 32 Kbytes (long packet).

RSV22

Long event previously seen. When the MAC asserts

the RSV22 signal, it indicates that at some time

since the last receive vector a long event was

detected, noted, and reported with this vector. The

long event is not associated with this packet. A long

event is activity on the network in excess of

50,000 bit times. A long event is not detected in

full-duplex mode. If RSV22 is deasserted, it indicates

that a long event was not seen.

RSV21

RSV20

RSV19

Invalid preamble content (not 55H) or code

(0x50555) seen in the last reception.

Broadcast packet received (all ones in the

destination address ﬁeld).

Multicast packet received. (The ﬁrst bit in the

destination address ﬁeld, which is also the least

signiﬁcant bit, is equal to a one–the least signiﬁcant

bit is transmitted ﬁrst.)

RSV18

FCS error detected in the received packet. The FCS

bytes in the received packet do not match those the

MAC calculates at the destination while the packet is

being received.

2-26

Signal Descriptions

RSV17

RSV16

Dribble nibble seen in the received packet. Each byte

consists of two nibbles, so the number of received

nibbles should always be even. If there is an odd

number of nibbles, the last nibble is the dribble

nibble.

Receive code violation detected. There is a 4B/5B

code violation. See the RSV24 signal description for

a deﬁnition of code-group violations. The PHY

asserts MRXER whenever a receive code-group

violation occurs.

RSV15

(msb)

Packet length bit 15. If the host asserts the HUGEN

signal, the Packet Length (Source Address,

Destination Address, Data Length, Data, and FCS

ﬁelds) as indicated by the Packet Length bits can be

up to 32 Kbytes. Bits 15 through 0 form a 16-bit

binary counter, with the least signiﬁcant bit (RSV0) =

1 byte.

RSV14

RSV13

RSV12

RSV11

RSV10

RSV9

RSV8

RSV7

RSV6

RSV5

RSV4

RSV3

RSV2

RSV1

Packet length bit 14.

Packet length bit 13.

Packet length bit 12.

Packet length bit 11.

Packet length bit 10.

Packet length bit 9.

Packet length bit 8.

Packet length bit 7.

Packet length bit 6.

Packet length bit 5.

Packet length bit 4.

Packet length bit 3.

Packet length bit 2.

Packet length bit 1.

Packet length bit 0.

RSV0

(lsb)

MAC Core Signals

2-27

TSV[30:0]

Transmit Statistics Vector

Output

The TSV[30:0] signals contain the transmit statistics

information. The MAC function updates the TSV[30:0]

signals on the falling edge of the TSVP_L signal. The

MAC issues the statistics vector at the end of the ﬁnal or

only attempt to transmit each packet, whether the packet

is transmitted or not. The TSV[30:0] signals are stable

until the subsequent TSVP_L pulse. The condition

associated with each signal is valid when the signal is

HIGH.

The MAC function provides transmit statistics that can be

used for RMON and SNMP. However, the MAC does not

collect the statistics speciﬁcally mentioned in the RMON

and SNMP speciﬁcations. The MAC provides basic per

packet information that can be collected by an application

built on top of the MAC. The collected information can

then be used for RMON and SNMP.

The signals in TSV[30:0] have the following functions:

TSV30

Transmit canceled because of excess deferral.

Excess deferrals occur when the network is

constantly busy (greater than 24,288 bit times

when HUGEN is deasserted or greater than

524,288 bit times when HUGEN is asserted).

TSV29

Transmit dropped because of late collision. A late

collision is one that occurs greater than 512-bit

times into packet transmission.

TSV28

TSV27

Transmit dropped because of excessive collisions

(15 transmit retries).

Transmit aborted because of underrun. If the host

is unable to supply transmit packet data bytes in

a timely manner to the E-110 core an underrun

condition exists.

TSV26

Transmit aborted because of excessive length.

The transmission is aborted if the packet exceeds

1518 bytes with the HUGEN signal LOW, or

32 Kbytes with the HUGEN signal HIGH.

TSV25

TSV24

Packet transmitted successfully.

Packet deferred on transmission attempt. A packet

is deferred when the network is busy.

TSV23

Broadcast packet transmitted or attempted.

2-28

Signal Descriptions

TSV22

TSV21

Multicast packet transmitted or attempted.

FCS error seen on transmission attempt. When

the host deasserts CRCEN, indicating that the

host provides the FCS ﬁeld in transmitted packets,

the MAC veriﬁes the host FCS against its

internally computed FCS. The E-110 core asserts

the TSV21 signal to indicate a mismatch in the

two FCSs. If the host asserts the CRCEN signal,

the MAC both calculates and provides the FCS in

transmitted packets. In this case, the MAC does

not assert the TSV21 signal.

TSV20

Late collision (a collision that occurs more than

512-bit times into the packet) seen on

transmission attempt.

TSV19

(msb)

Collision count bit 3. The collision count can range

from 0 to 15 for a packet ultimately transmitted,

but can never be 16. After 15 retries, the packet

is dropped because of excessive collisions.

Collision count bits 3 through 0 (TSV19 through

TSV16) form a 4-bit binary counter, with the least

signiﬁcant bit = 1 collision.

TSV18

TSV17

Collision count bit 2.

Collision count bit 1.

TSV16 (lsb) Collision count bit 0.

TSV15

(msb)

Packet length bit 15. The Packet Length bits

indicate the length of the packet in bytes. The

packet includes the Source Address, Destination

Address, Data Length, Data, and FCS fields.

Bits 15 through 0 form a 16-bit binary counter, with

the least significant bit (TSV0) = 1 byte.

TSV14

TSV13

TSV12

TSV11

TSV10

TSV9

Packet length bit 14.

Packet length bit 13.

Packet length bit 12.

Packet length bit 11.

Packet length bit 10.

Packet length bit 9.

Packet length bit 8.

Packet length bit 7.

TSV8

TSV7

MAC Core Signals

2-29

TSV6

TSV5

TSV4

TSV3

TSV2

TSV1

Packet length bit 6.

Packet length bit 5.

Packet length bit 4.

Packet length bit 3.

Packet length bit 2.

Packet length bit 1.

TSV0 (lsb) Packet length bit 0.

TSVP_L

Transmit Statistics Vector Pulse

Output

The TSVP_L signal is active LOW. When asserted, it

indicates that the TSV[30:0] signals have been updated

with a new transmit statistics vector. When deasserted, it

indicates that there has been no update.

2.1.7 Random Number Generator to Host Signals

Below is a list of the signals that interface the E-110 MAC random

number generator function to the host. All signals are active HIGH unless

otherwise noted. Signal direction is with respect to the random number

generator.

HWD[10:0]

Host Write Data [10:0]

Input

The HWD[10:0] signals contain the value of the random

number that the host loads into the MAC’s Linear

Feedback Shift Register (LFSR) to generate the random

number sequence used in collision backoff timing.

HWD[10:0] must remain stable for two MTXC cycles after

LRNG is asserted.

LRNG

Load Random Number Generator

Input

The host asserts the LRNG signal to indicate that the

HWD[10:0] signals are valid and the MAC function should

latch them. When the host deasserts LRNG, the

HWD[10:0] signals are not valid. LRNG must be

synchronous to the MTXC clock and at least one MTXC

clock cycle wide, which is 40 ns for 100 MHz operation

and 400 ns for 10 MHz operation (see the description of

the MTXC signal on page 2-14). The HWD[10:0] signals

must be stable when the host pulses LRNG.

2-30

Signal Descriptions

2.1.8 Scan Test Signals

The MAC design uses full scan test methodology, which consists of a

single scan chain and appropriate scan signals. The scan signals are

described below.

TMODE

Test Mode

Input

When the TMODE signal is asserted, the MAC switches

to test mode. When TMODE is deasserted, the MAC

resumes normal functional operation.

TEST_SE

Scan Enable

Input

When the TEST_SE signal is asserted, all of the registers

in the MAC accept data from their test inputs instead of

from their normal inputs. When TEST_SE is asserted, the

scan data can be shifted in on the TEST_SI pin. TEST_SE

must be kept deasserted during normal operation.

TEST_SI

Scan Input

Input

The TEST_SI signal is the serial scan chain input pin.

When the TMODE and TEST_SE signals are asserted,

test data can be presented to the MAC on the TEST_SI

pin.

TEST_SO

Scan Output

Output

The TEST_SO signal is the serial scan chain output pin.

The data presented on TEST_SO is the output data that

results from the input stimulus on TEST_SI.

2.2 MAC Control Module Signals

The interface diagram for the optional MAC control module core is shown

in Figure 2.2. The signals fall into the following groups:

•

E-110 MAC core signals

PHY

Host Signals

MAC Control Module Signals

2-31

Figure 2.2 MAC Control Module Core Interface Diagram

RPD[7:0]

HST_TPSF

CTLP

TPSF

TRST_L

RRST_L

PAUSE_ACTIVE

E-110

MAC

RCVNG_PAUSE_FRAME

ADDR_MATCH

TPDN

RPSF

MAC

Control

Module

Core

Signals

XMT_PAUSEF

RPEF

Host

Signals

PAUSE_RSVP_L

RPDV

RSVD_PAUSEF

RSV_GOOD

TPAB

UNSUPP_OPCODE

PAUSE_TIME_IN[15:0]

RCV_LOAD_DLY[3:0]

PAUSE_MIRROR[23:0]

FLOWCON_EN

MTXC

MRXC

PHY

Signals

2.2.1 MAC Control Module to E-110 Core Signals

The signals that connect the optional MAC control module to the E-110

core are listed below (see also Section 2.1.3, “MAC Control Module

Signals (Optional),” on page 2-9). All signals are active HIGH unless

otherwise indicated. Signal direction is with respect to the MAC control

module.

RPD[7:0]

Receive Packet Data

Input

The RPD[7:0] signals are the receive data bus. The

signals hold the received data byte for two MRXC clock

cycles.

RPDV

Receive Packet Data Valid

Input

A packet transmission from the receive function begins

when the receive function asserts the RPSF and RPDV

signal at the ﬁrst byte of received packet data on

RPD[7:0] after removing the preamble and SFD. For

subsequent data bytes, the receive function asserts only

the RPDV signal until the last byte, when it asserts both

RPDV and RPEF.

2-32

Signal Descriptions

RPEF

Receive Packet End of Frame

Input

The MAC asserts the RPEF signal for one MRXC clock

cycle to indicate that the last byte of the receive packet

is available to the MAC control module on RPD[7:0].

RPSF

Receive Packet Start of Frame

Input

The MAC asserts the RPSF signal for one MRXC clock

cycle to indicate that the ﬁrst byte of a receive packet is

available to the MAC control module on RPD[7:0].

RRST_L

Receive Reset

Input

Other modules in an ASIC can use the RRST_L signal

as a host reset synchronized to the receive clock

(MRXC). Because the MRXC clock can be slow with

respect to a host reset pulse, or even stopped, the host

reset signal (HRST_L) is captured in the E-110 MAC

receive function, which asserts RRST_L asynchronously

to MRXC when HRST_L occurs and deasserts RRST_L

synchronously on the positive transition of MRXC.

RSV_GOOD Receive Statistics Vector Good

Input

At the end of a receive frame, the MAC updates the

Receive Statistics Vector (RSV[27:0]). The MAC asserts

the RSV_GOOD signal, which reﬂects the RSV24 bit, if

the received frame has no errors. The MAC deasserts the

signal if the received frame contains errors.

TPAB

Transmit Packet Abort

Input

When asserted, the TPAB signal indicates that the

transmission was discontinued. TPAB remains asserted

until the E-110 MAC function receives a request to

transmit, which is indicated when the MAC control

module asserts TPSF. When deasserted, TPAB indicates

that the transmission was not aborted. The following

circumstances cause the transmission to be halted:

•

Excess deferrals, which occur when the media is busy

longer than twice the maximum frame length (greater

1

than 24,288 bits when the HUGEN signal is

2

deasserted or greater than 524,288 bits when

HUGEN is asserted)

1. 24,288 bits = 1518 bytes x 8 bits/byte x 2 (242.88 µs for 100 Mbit/s operation or 2.4288 ms

for 10 Mbit/s operation)

2. 524,288 bits = 32 Kbytes x 8 bits/byte x 2 (5242.88 µs for 100 Mbit/s operation or 52.43 ms

for 10 Mbit/s operation)

MAC Control Module Signals

2-33

•

Late collision (use RTRYL to avoid aborting)

Multiple collisions (greater than 15)

Transmit underrun

Larger than normal packet, which is 1518 bytes (see

also see the HUGEN signal description)

TPDN

TPSF

Transmit Packet Done

Input

The E-110 core asserts the TPDN signal after successful

transmission of a packet. TPDN is asserted until a new

TPSF signal is asserted by the MAC control module.

When the E-110 asserts TPDN, the MAC control module

goes back to the idle state. The TPDN signal is

synchronous to MTXC.

Transmit Packet Start Of Frame

Output

The MAC control module asserts the TPSF signal to

request the E-110 core to transmit a new packet. Once

asserted, TPSF is kept asserted as long as the

HST_TPSF signal from the host is asserted. On a data

packet transmit request from the host (HST_TPSF

asserted and CTLP deasserted), TPSF is asserted by the

MAC control module only if PAUSE_ACTIVE is

deasserted. The MAC control module does not enter the

pause state because either the pause counter has

counted down to zero or the counter is currently loaded

with a zero value. If the PAUSE_ACTIVE signal is

asserted, TPSF is not generated until PAUSE_ACTIVE is

deasserted.

If the FLOWCON_EN signal is deasserted, the MAC

control module does not assert the TPSF signal for host

control packet transmit requests. If the FLOWCON_EN

signal is deasserted, the TPSF signal is asserted for host

data packet transmit requests. When FLOWCON_EN is

asserted, TPSF is asserted one clock after HST_TPSF is

asserted for a data or a control packet transmit request.

When FLOWCON_EN is deasserted, TPSF is asserted

at the same clock as when HST_TPSF is asserted for a

data packet request. The MAC control module does not

interpret the transmit data in any way and transmit data

is routed from the host to the E-110 MAC directly.

2-34

Signal Descriptions

TRST_L

Transmit Reset

Input

Other modules in an ASIC can use the TRST_L signal as

a host reset synchronized to the transmit clock (MTXC).

Because the MTXC clock can be slow with respect to a

host reset pulse, or even stopped, the host reset signal

(HRST_L) is captured in the E-110 MAC transmit

function. The transmit function asserts TRST_L

asynchronously to MTXC when the HRST_L signal

occurs and deasserts TRST_L synchronously on the

positive transition of MTXC. Modules can use TRST_L to

initialize transmit logic.

2.2.2 MAC Control Module to PHY Signals

The signals between the PHY and the MAC control module are listed

below. Signal direction is with respect to the MAC control module.

MRXC

Receive Nibble or Symbol Clock

Input

The MRXC clock is a continuous clock signal that

operates at 25 MHz or 2.5 MHz and provides a timing

reference for data transfers from the E-110 core to the

MAC control module.

MTXC

Transmit Nibble or Symbol Clock

Input

The MTXC clock is a continuous clock signal that

operates at 25 MHz or 2.5 MHz and provides a timing

reference for data transfers from the MAC control module

to the E-110 core.

2.2.3 MAC Control Module to Host Signals

The signals that connect the MAC control module to the host are listed

below. All signals are active HIGH unless otherwise indicated. Signal

direction is with respect to the MAC control module.

ADDR_MATCH

Unicast Address Match

Input

When asserted the ADDR_MATCH signal indicates to the

MAC control module that the destination address of a

pause frame matched the unicast address of the E-110

MAC core. The ADDR_MATCH signal should be asserted

at least two clocks before the type ﬁeld is presented on

the host receive interface. This signal is synchronous to

MRXC.

MAC Control Module Signals

2-35

CTLP

Host Control Packet Transmit Request

Input

When asserted, the CTLP signal informs the MAC control

module to treat a host packet transmit request

(HST_TPSF asserted) as a pause frame transmit

request. When the CTLP signal is deasserted, the MAC

control module treats the host packet transmit request as

a data packet request. The CTLP signal is synchronous

to MTXC.

FLOWCON_EN

Flow Control Enable

Input

When this pin is deasserted:

No action is taken to load the pause time and the

PAUSE_TIMER is reset.

The Receive State Machine stays in the idle state.

If the host requests to transmit a control packet, the

request is ignored.

If the host requests to transmit a data packet, the TPSF

signal is asserted at the same clock as the HST_TPSF

signal and the MAC control module is transparent to the

host and E-110 MAC core.

The host must assert the FLOWCON_EN signal

synchronously with the rising edge of the MTXC clock

before transmission begins. The FLOWCON_EN signal is

static and must not be used to reconﬁgure the logic on

the ﬂy. The effect of this signal is not synchronized on a

packet boundary within the E-110 control module and

changing the state of this signal during a packet

transmission can cause unexpected results.

HST_TPSF

Host Packet Transmit Request

Input

The host interface asserts the HST_TPSF signal to

request the MAC control module to transmit a new

packet. The host must keep the HST_TPSF signal

asserted for one transmit clock period after the

E-110 core asserts the TPUD signal. The HST_TPSF

signal is synchronous to MTXC.

PAUSE_ACTIVE

Pause in Progress

Output

When asserted the PAUSE_ACTIVE signal indicates to

the host that the MAC control module is in the pause

2-36

Signal Descriptions

state and cannot transmit any data frames. The

PAUSE_ACTIVE signal is synchronous to MRXC.

PAUSE_MIRROR[23:0]

Mirror Counters Value

Output

The PAUSE_MIRROR[23:0] signals contain the counter

bits that reﬂect the value of the receiver’s pause timer.

The PAUSE_MIRROR[23:0] signals are valid after the

MAC control module core asserts the XMT_PAUSEF

signal.

PAUSE_RSVP_L

Comprehensive Receive Statistics

Vector Pulse

Output

On the falling edge of the PAUSE_RSVP_L signal, the

RSVD_PAUSEF and UNSUPP_OPCODE signals are

valid.

RCV_LOAD_DLY[3:0]

Receiver Delay in Loading Transmitted Pause Input

The 4-bit value contained in the RCV_LOAD_DLY[3:0]

signals are in terms of slot times and accounts for the

total time a receiver takes to load the transmitted pause

value into its own pause counter. The 4-bit value is

loaded into the mirror counter when the HST_TPSF and

CTLP signals are asserted. The MAC control module

adds the 4-bit value to the PAUSE_TIME_IN[15:0] value

in order to synchronize with a receiver’s pause timer.

The RCV_LOAD_DLY[3:0] signals must be stable before

the CTLP signal is asserted.

RCVNG_PAUSE_FRAME

Receiving Pause Frame

Output

This signal is asserted by the MAC control module to

indicate to the host that a pause frame has been

received. This helps the host to ﬁlter pause frames, if

required. The MAC control module asserts the

RCVNG_PAUSE_FRAME signal two clocks after the

opcode ﬁeld is presented on the receive data bus during

valid reception of a pause frame (provided that the

address, type, and opcode ﬁeld match ﬂags are set).

Once asserted, this signal is held asserted until the

completion of valid reception of a pause frame. This

signal is synchronous to MRXC.

MAC Control Module Signals

2-37

RSVD_PAUSEF

Received Pause Frame

Output

The RSVD_PAUSEF signal, when asserted, indicates

that the current packet received is a valid pause frame.

The MAC control module core deasserts the signal if a

data packet is received. This signal is valid on the falling

edge of PAUSE_RSVP_L.

PAUSE_TIME_IN[15:0]

Transmitted Pause Time

Input

The PAUSE_TIME_IN[15:0] signals constitute the 16-bit

pause time value (in slot times) sent in the transmit

control packet. The MAC control module loads the 16-bit

value into its mirror counter when the HST_TPSF and

CTLP signals are asserted. The PAUSE_TIME_IN[15:0]

signals must be stable before the CTLP signal is

asserted.

UNSUPP_OPCODE

Unsupported Opcode

Output

The MAC control module asserts the UNSUPP_OPCODE

signal if any opcode other than the pause opcode is

received in a valid control frame. This signal is valid on

the falling edge of PAUSE_RSVP_L.

XMT_PAUSEF

Transmitted Pause Frame

Output

The XMT_PAUSEF vector signal is asserted after the

transmission of a pause frame. It is deasserted if a data

packet is transmitted. This signal is valid on the falling

edge of the TSVP_L signal, which is asserted by the

E-110 core.

2-38

Signal Descriptions

2.3 MIIM Core Signals

The interface diagram for the optional MIIM core is shown in Figure 2.3.

Figure 2.3 MIIM Core Interface Diagram

BUSY

CLKS

CTLD_OR_ADD[15:0]

DEV_OR_REG_AD[4:0

MDC

MDOEN

MDI

MDO

MII

Management

Core

MII

Management

Core

FIAD[4:0]

to PHY

Signals

MII

Management

Core

HCLK

HRST_L

MIILF

to Host

Signals

MIIM_SCAN

MMD_REQ

NVALID

PRSD[15:0]

ST_OP[3:0]

2.3.1 MIIM Core to Host Signals

The signals that connect the MIIM core to the host are listed below. All

signals are active HIGH unless otherwise indicated. Signal direction is

with respect to the MIIM core.

BUSY

Busy

Output

The MIIM core asserts the BUSY signal to indicate to the

host that a read, write, or scan operation is in progress.

BUSY is deasserted when no MII operation is in

progress.

If a read, write, or scan command is issued while the

BUSY signal is asserted, the results are unpredictable.

CLKS

Clock Select

Input

The host asserts the CLKS signal to indicate that the

HCLK signal is 33 MHz. When deasserted, it informs the

MIIM that HCLK is 25 MHz. The MIIM uses CLKS to

determine how to divide down HCLK to create the MDC

signal (see the “HRST_L Host Reset Input” signal

description on page 2-20). The host must assert CLKS

MIIM Core Signals

2-39

synchronously to the rising edge of HCLK, because

CLKS is used in the clock divider circuit, which runs on

HCLK.

CTLD_OR_ADD[15:0]

Control Data or Address Data [15:0]

Input

When writing to a 10/100/1000 Mbit/s PHY, the host

places data to be written to the SMII/MII PHY on the

CTLD_OR_ADD[15:0] control data bus. The host then

sets the ST_OP[3:0] lines to 0b0101 for a write operation.

When the host asserts MMD_REQ, the host must

observe the BUSY signal and keep the

CTLD_OR_ADD[15:0] signals valid until the MIIM core

deasserts the BUSY signal. The host uses the

CTLD_OR_ADD[15:0] signals to write the Control register

of a 10/100/1000 Mbit/s PHY. For a definition of the Control

register, see the subsection entitled “Write PHY Control

Register (10/100/1000 Mbit/s PHYs)” on page 3-19.

When writing to a 10 Gbit/s PHY, the host must ﬁrst

places the 10 Gbit/s PHY register address to be

accessed on the CTLD_OR_ADD[15:0] control data bus.

The host then sets the ST_OP[3:0] lines to 0b0000 for a

write address operation. Then, when the host asserts

MMD_REQ, the host must observe the BUSY signal and

keep the CTLD_OR_ADD[15:0] signals valid until the MIIM

core deasserts the BUSY signal. The PHY stores the

address. After the register address has been written to a

10 Gbit/s PHY, the host uses the CTLD_OR_ADD[15:0]

bus along with ST_OP[3:0] to perform a data write to the

PHY address previously specified, or to do a postwrite

increment address or postread increment address

operation. After the MIIM core sends a postincrement

frame to the PHY for a postincrement operation, the PHY

increments the address location just accessed and stores

the new address value. If no postincrement operation is

received before the next data write operation, the PHY

uses the last stored address for that operation.

DEV_OR_REG_AD[4:0]

Device Address or Register Address [4:0]

When accessing 10/100/1000 Mbit/s PHYs, the

Input

DEV_OR_REG_AD[4:0] signals contain the address of

the register within the PHY the host has selected for

reading or writing.

2-40

Signal Descriptions

When writing to 10 Gbit/s PHYs, the

DEV_OR_REG_AD[4:0] signals contain the address of

the device the host has selected for reading or writing.

There may be up to 32 devices for each port, and there

may be up to 32 ports.

The host must not change the DEV_OR_REG_AD[4:0]

signals while the MIIM core is asserting the BUSY signal;

otherwise, the MIIM core may read the

DEV_OR_REG_AD[4:0] signals incorrectly.

FIAD[4:0]

PHY Address [4:0]

Input

When accessing 10/100/1000 Mbit/s PHYs, the FIAD[4:0]

signals contain the address of the PHY the host has

selected for reading or writing. The MIIM core can

support up to 32 PHYs.

When accessing 10 Gbit/s PHYs, the FIAD[4:0] signals

contain the address of the port the host has selected for

reading or writing. There may be up to 32 ports, with up

to 32 devices per port.

The host must not change the FIAD[4:0] signals while the

MIIM core is asserting the BUSY signal; otherwise, the

core may read the FIAD[4:0] signals incorrectly.

HCLK

Host Clock

Input

The host clock is either a 33 MHz or 25 MHz clock. The

CLKS signal indicates the HCLK frequency to the MIIM.

The host clock generates the MIIM Data Clock (MDC),

which has minimum HIGH and LOW times of 200 ns

each. A 33 MHz HCLK is divided by 14 to generate a

2.35 MHz MDC and a 25 MHz HCLK is divided by 10 to

generate a 2.5 MHz clock. To meet the minimum HIGH

and LOW times, the maximum frequency of MDC is

2.5 MHz.

HRST_L

MIILF

Host Reset

Input

The HRST_L signal is an active LOW signal that

initializes the MAC function and the MIIM function when

the host asserts it.

MII Link Failure

(only for 10/100/1000 Mbits/s)

Output

When the host uses the MIIM core to read a PHY’s status

register, the MIILF output signal from the MIIM core

reﬂects the state of the Link Status bit (bit 2) in the PHY’s

MIIM Core Signals

2-41

MII status register (see Table 3.3 on page 3-23); that is,

if the Link Status bit is one, MIILF is asserted, indicating

a link failure. If the bit is zero, MIILF is deasserted.

The MIIM core updates the MIILF signal whenever a

status read operation or a scan cycle has accessed the

PHY status register (register address 0x01). The MIIM

core does not interpret the Link Status bit in any way.

During a read operation, MIILF is valid after BUSY is

deasserted. During a scan operation, MIILF is valid after

NVALID is deasserted.

MIIM_SCAN Status Read Scan

(only for 10/100/1000 Mbits/s)

When the host asserts the MIIM_SCAN signal, the

Input

MIIM core causes continuous status read operations from

the addressed MII PHY. The host must ensure that

FIAD[4:0], and DEV_OR_REG_AD[4:0] are valid before it

asserts MIIM_SCAN and must not change the signals

during the entire scan operation. When the host

deasserts MIIM_SCAN, status read operations stop.

MIIM_SCAN must be at least one HCLK pulse wide and

must be asserted and deasserted synchronously with the

rising edge of HCLK.

MMD_REQ

NVALID

PHY Read or Write Request

Input

When the host asserts MMD_REQ, it indicates that the

FIAD[4:0], DEV_OR_REG_AD[4:0], CTLD_OR_AD[15:0],

and ST_OP[3:0] signals are valid. MMD_REQ must stay

asserted until the BUSY signal is deasserted. The host

must not assert MMD_REQ if BUSY is already asserted.

Invalid

Output

During a scan operation, the NVALID signal indicates the

validity of the MIILF and PRSD[15:0] signals. When

NVALID is asserted, it indicates that MIILF and

PRSD[15:0] are invalid. When NVALID is deasserted, it

indicates that MIILF and PRSD[15:0] are valid. The

meaning of NVALID is valid only during a MIIM_SCAN

operation.

PRSD[15:0] PHY Read Status Data

Output

The PRSD[15:0] signals contain the Status register data

that is read from the addressed MII PHY. The

PRSD[15:0] signals are valid after the MIIM core

2-42

Signal Descriptions

deasserts BUSY for a read operation and after the MIIM

core deasserts NVALID for a scan operation. See

Section 3.2.3.3, “Read PHY Status Register

(10/100/1000 Mbit/s PHYs),” on page 3-22 for a deﬁnition

of the PHY Status register.

ST_OP[3:0]

PHY Read Status Data

Input

The ST_OP[3:0] bits from the host indicate the type of

operation that is to take place, and are valid only when

MMD_REQ is asserted. The meaning of the bits is shown

in the table.

PHY Type

ST_OP[3:0] Meaning

10/100/1000 Mbit/s

0b0101

0b0110

Write

Read

10 Gbit/s

0b0000

0b0001

0b0010

Write address

Write data

Postread increment

address

0b0011

Postwrite increment

address

other values No action

2.3.2 MIIM Core to PHY Signals

The signals that connect the MIIM core to the PHY are listed below. All

signals are active HIGH unless otherwise indicated. Signal direction is

with respect to the MIIM core. The standard IEEE MII signal name

references are shown in brackets.

MDC

MIIM Data Clock

Output

The MDC [MDC] signal is sent by the MIIM block to the

PHY as a timing reference for transfer of information on

the MDI and MDO signal lines. MDC is an aperiodic

signal (HIGH-to-LOW and LOW-to-HIGH transitions do

not necessarily occur at regular intervals) that has no

maximum HIGH or LOW times. The minimum HIGH and

LOW times are 200 ns each.

MIIM Core Signals

2-43

MDI

MIIM Data In

Input

The PHY transfers status on the MDI signal to the MIIM

core. The PHY places status information on MDI

synchronously, and the MIIM block samples the

information synchronously.

MDI is driven through an open collector or open drain

circuit that enables either the MIIM block or the PHY to

deassert the signal. The PHY must provide a resistive

pull-up of 1.5 kΩ ± 5% to maintain the signal in a HIGH

value. The MIIM block must incorporate a weak pull-down

of 2 kΩ ± 5% on the MDI signal and thus may use the

quiescent state of MDI to determine if a PHY is

connected to the MII. If no PHY is present, the MDI signal

will be LOW. If a PHY is present, the MDI signal will be

HIGH.

The MDI and MDO signals are joined into one signal

[MDIO] outside the MIIM core before being connected to

the PHY. The MDOEN signal controls the direction of

data transfer on the MDIO signal and whether the MDI

signal or the MDO signal is active at a particular time.

MDO

MIIM Data Out

Output

The MIIM core transfers control information on the MDO

signal to the PHY. The MIIM block places control

information on MDO synchronously to HCLK, and the

PHY samples the information synchronously. MDO is

driven through an open collector or open drain circuit that

allows either the PHY or the MIIM core to deassert the

signal. The PHY must provide a resistive pull-up of

1.5 kΩ ± 5% to assert the signal.

The MDI and MDO signals are joined into one signal

[MDIO] outside the MIIM core before being connected to

the PHY. The MDOEN signal controls the direction of

data transfer on the MDIO signal and whether the MDI

signal or the MDO signal is active at a particular time.

MDOEN

MIIM Data 3-State Enable

Output

The MDOEN signal is a 3-state driver enable that

controls the open-drain MDO output data signal. The

MIIM core asserts MDOEN synchronously to HCLK

whenever the MDO signal contains valid data. The MIIM

core deasserts MDOEN to indicate that data is not valid.

2-44

Signal Descriptions

The MDI and MDO signals are joined into one signal

[MDIO] outside the MIIM core before being connected to

the PHY. The MDOEN signal controls the direction of

data transfer on the MDIO signal and whether the MDI

signal or the MDO signal is active at a particular time.

2.4 SMII Core Signals

The interface diagram for the optional SMII core is shown in Figure 2.4.

Figure 2.4 SMII Core Interface Diagram

ACTIVITY

DUPLEX

MCOL_TOP

MCRS_TOP

JABBER_SMII

LINK

SMII

Core to PHY

Signals for

MII Operation

MRXD_TOP[3:0]

MRXDV_TOP

MRXER_TOP

SMII

Core

to Host

Signals

LINK_M2M

MII_SEL

RXCLK

TXCLK

M2M_SEL

RESETN

SMII Core

SPEED

SMII

SMII_RXD

SMII_TXD

Core to PHY

Signals for

SMII Operation

MCOL_INT

MCRS_INT

MRXD_INT[3:0]

MRXC

RXCLK125

RXSYNC

SMII

Core to Clock Source

Signals for

SMII Operation

SMII

Core

to MAC

Signals

TXCLK125

TXSYNC

MRXDV_INT

MRXER_INT

MTXC

MTXD_INT[3:0]

MTXEN

MTXER

2.4.1 SMII Core to Host Signals

The signals that connect the SMII core to the host are listed below. All

signals are active HIGH unless otherwise indicated. Signal direction is

with respect to the SMII core.

SMII Core Signals

2-45

ACTIVITY

DUPLEX

Data Activity

Output

When asserted, the ACTIVITY signal indicates that either

MTXEN or MRXDV is asserted. When deasserted, it

indicates that neither MTXEN nor MRXDV is asserted.

Duplex State

Output

DUPLEX is valid when the MII_SEL signal from the host

is deasserted and the LINK signal is asserted.

DUPLEX

Meaning

0

1

Half duplex

Full duplex

JABBER_SMII Jabber

Output

JABBER_SMII is valid when the MII_SEL signal is

deasserted and LINK is asserted.

JABBER_SMII

Meaning

0

1

No jabber condition

Jabber condition

LINK

Link State

LINK is valid when MII_SEL is deasserted.

Output

LINK

Meaning

0

1

Link down

Link up

LINK_M2M

MAC-to-MAC Link State

Input

LINK_M2M is active-HIGH. The host asserts LINK_M2M

to indicate that the link is up in a direct MAC-to-MAC

connection arrangement. The host deasserts LINK_M2M

when it wants to bring the link down in direct

MAC-to-MAC connection mode.

MII_SEL

Select MII Mode

Input

The host asserts MII_SEL to put the SMII core into MII

mode. The host deasserts MII_SEL to put the SMII core

into the SMII mode.

M2M_SEL

Select Direct MAC-to-MAC Mode

Input

M2M_SEL is active-HIGH. The host asserts M2M_SEL to

select the direct MAC-to-MAC connection mode. It should

remain deasserted when MII_SEL is asserted.

2-46

Signal Descriptions

RESETN

SPEED

Reset

Input

RESETN is active-LOW. The host asserts RESETN to

asynchronously reset the SMII core.

10 Mbits/s, 100 Mbits/s Speed Indication

The SPEED signal is valid when the MII_SEL signal is

deasserted and LINK is asserted.

Output

SPEED

Meaning

0

1

10 Mbit/s operation

100 Mbit/s operation

2.4.2 SMII Core to MAC Signals

The signals that connect the SMII core to the MAC are listed below. All

signals are active HIGH unless otherwise indicated. Signal direction is

with respect to the SMII core.

MCOL_INT

Collision

Output

MCLO_INT is to be connected to the MCOL pin of the

MAC module.

MCOL_INT reﬂects the MCLO_TOP signal from the PHY.

See the subsection entitled “MCOL Collision Detected

Input” on page 2-12 for details on the MCOL signal.

MCRS_INT

Carrier Sense

Output

The MCRS_INT signal is to be connected to the MCRS

pin of the MAC module.

MCRS_INT reﬂects the MCRS_TOP signal from the PHY.

See the subsection entitled “MCRS Carrier Sense Input”

on page 2-12 for details on the MCRS signal.

MRXD_INT[3:0]

Receive Data

Output

The MRXD_INT[3:0] signals are to be connected to the

MRXD[3:0] signals of the MAC.

The MRXD_INT[3:0] signals reﬂect the MRXD_TOP[3:0]

signals from the PHY. See the subsection entitled

“MRXD[3:0] Receive Nibble Data Input” on page 2-12 for

details on the MRXD[3:0] signals.

SMII Core Signals

2-47

MRXC

Receive Clock

Output

The MRXC signal is to be connected to the MRXC signal

of the MAC.

See the subsection entitled “MRXC Receive Nibble or

Symbol Clock Input” on page 2-12 for details on the

MRXC signal.

MRXDV_INT Receive Data Valid

Output

The MRXDV_INT signal is to be connected to the

MRXDV signal of the MAC.

See the subsection entitled “MRXDV Receive Data Valid

Input” on page 2-12 for details on the MRXDV signal.

MRXER_INT Receive Error

Output

The MRXER_INT signal is to be connected to the

MRXER signal of the MAC.

See the subsection entitled “MRXER Receive Error Input”

on page 2-12 for details on the MRXER signal.

MTXC

Transmit Clock

Output

The MTXC signal is to be connected to the MTXC signal

of the MAC.

See the subsection entitled “MTXC Transmit Nibble or

Symbol Clock Input” on page 2-12 for details on the

MTXC signal.

MTXD_INT[3:0]

Transmit Data

Input

The MTXD_INT[3:0] signals are to be connected to the

MTXD[3:0] signals of the MAC.

See the subsection entitled “MTXD[3:0] Transmit Nibble

Data Output” on page 2-12 for details on the MTXD[3:0]

signals.

MTXEN

MTXER

Transmit Enable

The MTXEN signal is to be connected to the MTXEN

signal on the MAC.

Input

See the subsection entitled “MTXEN Transmit Enable

Output” on page 2-12 for details on the MTXEN signal.

Transmit Data Error

Input

The MTXER signal is to be connected to the MTXER

signal on the MAC.

2-48

Signal Descriptions

See the subsection entitled “MTXC Transmit Nibble or

Symbol Clock Input” on page 2-12 for details on the

MTXC signal.

2.4.3 SMII Core to PHY Signals for MII Operation

The signals that connect the SMII core to the PHY for MII operation are

listed below. All signals are used when the MII_SEL signal is asserted.

All signals are active HIGH unless otherwise indicated. Signal direction

is with respect to the SMII core.

MCOL_TOP Collision

Input

The MCOL_TOP signal is to be connected to the MCOL

pin of the PHY. This signal is used when the MII_SEL

signal is asserted.

See the subsection entitled “MCOL Collision Detected

Input” on page 2-12 for details on the MCOL signal.

MCRS_TOP Carrier Sense

Input

The MCRS_TOP signal is to be connected to the MCRS

pin of the PHY. This signal is used when the MII_SEL

signal is asserted.

See the subsection entitled “MCRS Carrier Sense Input”

on page 2-12 for details on the MCRS signal.

MRXD_TOP[3:0]

Receive Data

Input

The MRXD_TOP[3:0] signals are to be connected to the

MRXD[3:0] pins of the PHY. These signals are used

when the MII_SEL signal is asserted.

See the subsection entitled “MRXD[3:0] Receive Nibble

Data Input” on page 2-12 for details on the MRXD[3:0]

signals.

MRXDV_TOP Receive Data Valid

The MRXDV_TOP signal is to be connected to the

Input

MRXDV pin of the PHY. This signal is used when the

MII_SEL signal is asserted.

See the subsection entitled “MRXDV Receive Data Valid

Input” on page 2-12 for details on the MRXDV signal.

SMII Core Signals

2-49

MRXER_TOP Receive Data Error

The MRXER_TOP signal is to be connected to the

Input

MRXER pin of the PHY. This signal is used when the

MII_SEL signal is asserted.

See the subsection entitled “MRXER Receive Error Input”

on page 2-12 for details on the MRXER signal.

RXCLK

TXCLK

Receive Clock

Input

The RXCLK signal is to be connected to the MRXC pin

of the PHY. This signal is used when the MII_SEL

signal is asserted.

See the subsection entitled “MRXC Receive Nibble or

Symbol Clock Input” on page 2-12 for details on the

MRXC signal.

Transmit Clock

Input

The TXCLK signal is to be connected to the MTXC pin of

the PHY. This signal is used when the MII_SEL

signal is asserted.

See the subsection entitled “MTXC Transmit Nibble or

Symbol Clock Input” on page 2-12 for details on the

MTXC signal.

2.4.4 SMII Core to PHY Signals for SMII Operation

The signals that connect the SMII core to the PHY for SMII operation are

listed below. All signals are used when the MII_SEL signal is asserted.

All signals are active HIGH unless otherwise indicated. Signal direction

is with respect to the SMII core.

SMII_RXD

SMII_TXD

SMII Receive Data

Input

SMII_RXD is the receive data and control pin from the

PHY. The MAC receives data and control signals over the

SMII_RXD pin in a 10-bit segment (8-bits of receive data,

and the CRS and RX_DV control bits). The data in the

segment is valid while the SYNC signal is asserted for

10 RXCLK125 cycles.

SMII Transmit Data

Output

SMII_TXD is the transmit data and control pin from the

SMII core to the PHY. The MAC transmits data and

control signals over the SMII_TXD pin in a 10-bit

segment (8-bits of receive data, and the TX_ER and

2-50

Signal Descriptions

TX_EN control bits). The data in the segment is valid

while the TXSYNC signal is asserted for 10 TXCLK125

cycles.

2.4.5 SMII Core to Clock Sources for SMII Operation

The signals that connect the SMII core to the external or PHY clock

sources for SMII operation are listed below. All signals are used when

the MII_SEL signal is asserted. Signal direction is with respect to the

SMII core.

RXCLK125

125 MHz Receive Clock

Input

RXCLK125 is the 125 MHz receive reference clock for

both the MAC and PHY. The PHY provides RXCLK125 if

the source synchronous mode is used.

RXSYNC

Receive Sync

Input

RXSYNC is the receive synchronization signal to all

MACs and PHYs. RXSYNC is asserted every

10 RXCLK125 cycles for one clock period to deﬁne 10-bit

segment boundaries for receive data. The PHY provides

this signal if the source synchronous mode is used.

TXCLK125

TXSYNC

125 MHz Transmit Clock

Input

TXCLK125 is the 125 MHz transmit reference clock for

both the MAC and PHY. The PHY provides TXCLK125 if

the source synchronous mode is used.

Transmit Sync

Input

TXSYNC is the transmit synchronization signal to all

MACs and PHYs. TXSYNC is asserted for one clock

period every 10 TXCLK125 cycles to deﬁne 10-bit

segment boundaries for transmit data. The PHY provides

this signal if the source synchronous mode is used.

SMII Core Signals

2-51

2-52

Signal Descriptions

Chapter 3

Core Descriptions

This chapter describes the E-110 core functions and consists of the

following sections:

•

Section 3.1, “Clock Operation,” page 3-1

Section 3.2, “E-110 Core Operation,” page 3-3

Standard IEEE MII signal name references are shown in brackets.

3.1 Clock Operation

This section describes all of the clocks used in the E-110 core and their

operation. The clocks fall into the following categories:

•

Clocks from the PHY to the MAC core—MTXC and MRXC

Clock from the host to the MIIM core—HCLK

Clock from the MIIM core to the PHY—MDC

3.1.1 MTXC and MRXC

MTXC is the transmit nibble or symbol clock input from a PHY to the

MAC. The MTXC signal operates at a frequency of 25 MHz or 2.5 MHz.

MTXC is a continuous clock that provides a timing reference for transfer

of the MTXEN, MTXD[3:0], and MTXER signals from the E-110 MAC to

the PHY. The PHY generates MTXC.

The MTXC frequency is 25% of the transmit data rate. A PHY operating

at 100 Mbits/s provides an MTXC frequency of 25 MHz ± 100 ppm. A

PHY operating at 10 Mbits/s provides a TX_CLK frequency of 2.5 MHz

± 100 ppm. The duty cycle of the TX_CLK signal is between 35% and

60%.

Ethernet-110 Core Technical Manual

3-1

The MRXC [RX_CLK] signal is a continuous clock that provides a timing

reference for transfer of the MRXDV, MRXD[3:0], and MRXER signals

from the PHY to the E-110 MAC. MRXC is an input from the PHY.

As long as the PHY is receiving a continuous signal from the medium

and can recover the MRXC clock reference and supply MRXC, the PHY

does not need to make a switch from the recovered clock reference to a

nominal clock reference (for example, the MTXC continuous clock signal

from the PHY). However, if the loss of a receive signal causes the PHY

to lose the recovered clock reference, the PHY must source MXRC from

a nominal clock reference.

If the PHY needs to make a switch from recovered clock to nominal

clock, it deasserts the MRXDV signal. During the interval between MCRS

and the assertion of MRXDV at the beginning of a frame, the PHY may

extend a cycle of the MRXC clock by holding it in either the HIGH or

LOW condition until the PHY has successfully locked onto the recovered

clock. Successive cycles of MRXC must meet the duty cycle

requirement.

While MRXDV is asserted, the PHY recovers MRXC from the received

data. MRXC has a frequency equal to 25% of the data rate of the

received signal and is synchronous to recovered data. The duty cycle is

between 35% and 60% and is nominally 50%. For 100 Mbit/s operation,

MRXC is nominally 25 MHz ±100 ppm, and the minimum MRXC HIGH

and LOW times are 14 ns. For 10 Mbit/s operation, MRXC is nominally

2.5 MHz ± 100 ppm, and the minimum MRXC HIGH and LOW times are

140 ns.

When the MCRS signal is deasserted, the PHY provides MRXC at the

PHY’s nominal clock rate (for example, the MTXC clock signal) and with

nominal duty cycle. The minimum HIGH and LOW times are each 35%

of the nominal MRXC period except for the transition between recovered

clock frequency and nominal clock frequency, which occurs while

MRXDV is deasserted. Following the transition from MRXDV asserted to

MRXDV deasserted, the PHY can keep MRXC in either the HIGH or

LOW condition to extend the MRXC clock by one cycle until the PHY is

ready to provide MRXC from a nominal clock source. The maximum

HIGH or LOW time for MRXC during this transition is two times the

nominal clock period (a total of 80 ns for 25 MHz operation or 800 ns for

2.5 MHz operation).

3-2

Core Descriptions

3.1.2 HCLK

The host clock is either a 33 MHz or 25 MHz clock. The CLKS signal

indicates the HCLK frequency to the MIIM core. The host clock

generates the MIIM Data Clock (MDC), which has minimum HIGH and

LOW times of 200 ns each. A 33 MHz HCLK is divided by 14 to generate

a 2.35 MHz MDC and a 25 MHz HCLK is divided by 10 to generate a

2.5 MHz clock. To meet the minimum HIGH and LOW times, the

maximum frequency of MDC is 2.5 MHz.

3.1.3 MDC

The MDC signal is the MIIM core data clock output. The MDC [MDC]

signal is sent by the core to the PHY as a timing reference for transfer

of information on the MDI and MDO signal lines. MDC is an aperiodic

signal that has no maximum HIGH or LOW times. The minimum HIGH

and LOW times are 200 ns each.

3.2 E-110 Core Operation

The following subsections describe the operation of the E-110 core.

Figure 3.1 is an overall block diagram, showing how the MAC receive and

transmit functions, MIIM core, SMII core, and MAC control module core

interface to the host and the PHY.

E-110 Core Operation

3-3

3.2.1 MAC Core Operation

Figure 3.2 shows the E-110 MAC core transmit and receive function

blocks, along with customer-deﬁned transmit and receive logic blocks.

Figure 3.2 Transmit and Receive Functions

E-110 MAC Core

Transmit

Byte Stream

from Host

Transmit

Nibbles

to MII

Transmit

Logic

Transmit

Function

Receive

Byte Stream

to Host

Receive

Nibbles

from MII

Receive

Logic

Receive

Function

3.2.1.1 MAC Transmit Function

The normal E-110 MAC architecture includes an independent transmit

function between the transmit logic on the host side and the MII, which

is located on the PHY side. The transmit logic block is customer-deﬁned

and buffers data from the host. The E-110 MAC transmit function block

performs the E-110 MAC operations. Figure 3.3 shows how the transmit

function interfaces to the rest of the system.

Figure 3.3 Transmit Function Interface

E-110

Transmit

Byte Stream

MAC

Transmit

Logic

Control

Status

Host

Transmit

Function

Transmit Statistics

Statistics

Logic

MII or SMII

External MII PHY

E-110 Core Operation

3-5

The general ﬂow of transmit packet data is from the host through the

transmit control logic to the transmit function block and then into the

media PHY device. The transmit function block of the E-110 MAC

generates 100BASE-T transmit MII nibble data streams in response to

byte streams supplied from the transmit logic. The transmit function

performs the required deferral and backoff algorithms and reports per

packet statistics. The transmit function operates on the 25 or 2.5 MHz

MII transmit nibble clock.

The E-110 MAC core monitors the physical medium even when it has

nothing to transmit by tracking the Carrier Sense (CRS) signal from the

PHY. When the medium is busy, the MAC defers to the frame in progress

by delaying any pending transmission of its own. When the PHY

deasserts CRS, it indicates to the MAC that the last bit of the frame has

been transmitted onto the physical medium. The MAC then continues to

defer transmission for a period called the interpacket gap (IPG).

The purpose of deference is to ensure a minimum interframe spacing to

allow a station recovery time to process a received frame and for the

medium to recover. Deference applies to both 10 Mbits/s and 100 Mbits/s

operation.

There is an IPG counter inside the MAC that begins counting after a

deferral. You can specify three threshold values for the counter:

•

IPGR1[6:0]—Non-Back-to-Back IPG, Part 1

IPGR2[6:0]—Non-Back-to-Back IPG, Part 2

IPGT[6:0]—Back-to-Back Transmit IPG

To provide maximum ﬂexibility for the IPG in both full-duplex and half-

duplex operation, these thresholds are programmable. Due to possible

variations in PHY propagation delays, the programmable thresholds may

need to be adjusted to meet IEEE 802.3u deference requirements.

As soon as the CRS signal is deasserted, the MAC begins timing the

IPG with the IPG counter.

3-6

Core Descriptions

1

IPG Half-Duplex Operation – The IPGT[6:0] signals contain the

threshold value to be compared to the IPG counter. The threshold value

is used for back-to-back MAC transmissions. As soon as the MAC’s IPG

count is equal to IPGT[6:0], the MAC may begin transmission.

IPGR1[6:0] is the threshold value used to reset the MAC’s IPG counter

if CRS is detected within a short time after receiving a packet (see

Figure 3.5). If CRS is asserted before the IPG counter value reaches the

IPGR1[6:0] threshold, the MAC resets the IPG counter because the CRS

may have occurred due to a collision fragment (see Figure 3.5). If the

2

IPG counter makes it past the IPGR1[6:0] threshold, the MAC does not

reset the IPG counter so that the E-110 MAC is able to access to the

medium without being constantly deferred by other stations trying to gain

access.

3

IPGR2[6:0] is the threshold value for measuring the IPG if the MAC has

been receiving and the host wants the MAC to transmit. That is, when

the IPG counter has exceeded the value in IPGR1[6:0] and reaches the

value in IPGR2[6:0], the MAC can transmit.

Because IPGR1[6:0] and IPGR2[6:0] are programmable, IPGR1[6:0] may

be set to a threshold that is a fraction of IPGR2[6:0] to conform to the

4

IPG rules of the IEEE 802.3/802.3u speciﬁcations. Figure 3.4 and

Figure 3.5 illustrate half-duplex IPG operation.

1. A value of 18 (decimal) for IPGT[6:0] results in an IPG of 960 ns for 100-Mbit/s operation

(the value given in IEEE 802.3u, section 1.4.102) at the MII. When IPGT[6:0] is set to 18,

the IPG counter counts from 0 to 18 (19 clocks total) using the nibble clock. The nibble clock

runs at 25 MHz (40 ns) for 100 Mbit/s operation and 2.5 MHz (400 ns) for 10 Mbit/s

operation). The 19 clocks plus a 5-clock internal core delay results in 24 clocks, which yields

960 ns for 100 Mbit/s operation or 9.6 µs for 10 Mbit/s operation. Depending on PHY

propagation delays, the value for IPGT[6:0] may need to be adjusted to meet the IPG

requirement at the network interface.

2. The nominal value for IPGR1[6:0] is 11 (decimal).

3. A nominal value for IPGR2[6:0] is 18 (decimal). The PHY may have its own propagation de-

lay and the value of 18 (decimal) may or may not be the correct value for a particular PHY.

4. See IEEE 802.3 Sections 4.2.3.2.1 and 4.2.3.2.2. See also IEEE 802.3u Section1.4.102.

E-110 Core Operation

3-7

Figure 3.4 Half-Duplex Back-to-Back IPG Operation

CRS

IPG

Transmit

Frame

18 (IPGT[6:0])

0

IPG Counter

Figure 3.5 Half-Duplex Non-Back-to-Back IPG Operation

CRS

Collision Fragment

Receive

Frame

IPG

Transmit

Frame

18 (IPGR2[6:0])

11 (IPGR1[6:0])

0

IPG Counter

IPG Full-Duplex Operation – In full-duplex mode, the MAC never sees

the CRS signal asserted because CRS is disabled when the FULLD

signal is asserted. For this reason, in full-duplex mode the MAC does not

defer on CRS. In full-duplex mode, the MAC can begin to create the IPG

as soon as transmission is done, regardless of the state of CRS.

When the MAC has been receiving and the host wants the MAC to

transmit a packet, the MAC looks at the IPGR2[6:0] threshold. The MAC

compares the IPG counter to the IPGR2[6:0] threshold in situations

where a reception is followed by a transmission. When the host wants to

perform back-to-back transmit operations through the MAC, the MAC

compares the IPG counter to the IPGT[6:0] threshold. For full-duplex

operation, the IPGR2[6:0] threshold should normally be set equal to

1

IPGT[6:0]. Figure 3.6 and Figure 3.7 illustrate full-duplex IPG operation.

1. A value of 18 (decimal) for IPGR2[6:0] and IPGT[6:0] results in an IPG of 960 ns at the MII

for 100 Mbit/s operation and 960 µs for 10 Mbit/s operation.

3-8

Core Descriptions

Figure 3.6 Full-Duplex Back-to-Back IPG Operation

CRS

IPG

Transmit

Frame

18 (IPGT[6:0])

0

IPG Counter

Figure 3.7 Full-Duplex Non-Back-to-Back IPG Operation

CRS

Receive

Frame

IPG

Transmit

Frame

18 (IPGR2[6:0])

0

IPG Counter

When instructed, the transmit function adds a preamble and SFD to the

supplied packet data and, if requested, appends a generated FCS. The

E-110 MAC transmit function adds bytes of zero before the appended

FCS to pad packets with fewer than 60 data bytes. The transmit function

detects and enforces collisions with jams and manages transmission

retries.

The transmit function block operates on the 25 MHz (100 Mbit/s

operation) or 2.5 MHz (10 Mbit/s operation) transmit nibble or symbol

clock (MTXC) supplied by the PHY. The PHY clock must be a continuous

clock. The connecting interface to the transmit control logic also operates

on the same transmit nibble clock and communicates synchronously with

the transmit function.

The transmit data is supplied to the transmit function a byte at a time

from the transmit control logic on the TPD[7:0] signals and output to the

MII a nibble at a time as deﬁned in the MII speciﬁcation. Transmit data

bytes are transferred from the host at one-half the nibble clock rate. The

transmit data is also sent to the transmit function block FCS

generator/checker. The MII output nibbles (MTXD[3:0]) are only valid

E-110 Core Operation

3-9

when the MTXEN signal is asserted. The transmit function supplies

nibbles of zero when MTXEN is not asserted. When MTXEN is asserted,

the transmit function supplies preamble, SFD, transmit data, FCS, jam,

or pad nibbles.

The operation of the E-110 MAC transmit function is affected by the

following control signals: no preamble (NOPRE), pad enable (PADEN),

full-duplex (FULLD), FCS enable (CRCEN), and huge packet enable

(HUGEN). The host must appropriately manage any transitions of these

signals and ensure that only valid combinations of controls signals are

used, as described below.

•

NOPRE. If no preamble is selected (the NOPRE signal is asserted),

the preamble and start of frame nibbles come directly from the host

and are not examined by the E-110 MAC transmit function. If NOPRE

is not asserted, the MAC encodes the preamble including the SFD

and outputs it at the beginning of the packet.

•

PADEN. When asserted, the PADEN signal instructs the transmit

function to pad packets of fewer than 60 bytes with bytes of zero. The

CRCEN signal must also be asserted because the MAC must

calculate the FCS when it inserts its own pad bytes. If PADEN is not

asserted, the host must ensure that packets contain at least 60

bytes; otherwise, the packet is invalid (too short).

•

FULLD. When asserted, the FULLD signal instructs the transmit

function to operate in full-duplex mode by not deferring to the CRS

signal and not responding to the COL signal.

CRCEN. If the CRCEN signal is deasserted, the last four data bytes

of a packet must be a valid FCS provided by the host and are

checked by the MAC’s transmit function. If the FCS is not valid, the

MAC asserts the FCS error signal (TSV21) in the Transmit Statistics

Vector. If CRCEN is asserted, the transmit function generates an

FCS from the transmit data bytes and pad bytes of the packet and

outputs it at the end of the packet. You can change CRCEN on a

packet-by-packet basis, but you must not change it during an active

transmission.

•

HUGEN. When asserted, the HUGEN signal instructs the MAC

transmit function to allow transmission of packets up to 32 Kbytes

rather than the normal limit of 1518. However, the MAC core does

not enforce the length of the maximum packet. Instead, the higher

3-10

Core Descriptions

layer protocols must assure that the packet size does not exceed

IEEE speciﬁcations.

For more information about these signals, refer to Chapter 2.

A packet transmission from the host to the transmit function begins when

the host asserts the TPSF signal. When the TPSF signal is asserted, the

host may also present the ﬁrst data byte of the packet on TPD[7:0]. The

host may also delay supplying the ﬁrst data byte on TPD[7:0] until the

transmit function has sent out the preamble.

Assuming the NOPRE signal is not asserted, the transmit function (after

any pending backoff and needed deference) begins to generate

preamble and start of frame nibbles. After generating the SFD, the

transmit function uses the contents of TPD[7:0] as the ﬁrst data byte and

asserts the TPUD signal to the host. If the host had not already supplied

the ﬁrst data byte, it must recognize an underrun condition and assert

TPUR, which causes the transmit function to abort the packet. The host

thus has at least eight byte times (the length of the preamble plus SFD)

to supply the ﬁrst data byte after asserting TPSF.

Conversely, the TPUD signal might not be asserted for over 500,000-bit

times in the case of a maximum backoff and deferral. After once seeing

TPUD asserted, the host must then deassert TPSF and supply new

transmit packet data bytes every other MTXC clock cycle. The host

continues supplying new data bytes up until the last data byte of the

packet, when it asserts the TPEF signal. If the host is unable to correctly

supply new transmit packet data bytes, the transmit function must assert

TPUR. When the host asserts the TPUR signal, the MAC asserts the

MTXER signal with the last nibble it transmits to indicate that this nibble

may not have valid information. Each data byte must be stable on the

TPD[7:0] signals for two transmit clock periods. The TPEF signal must

also be valid for two transmit clock periods. The TPSF signal and the ﬁrst

data byte must be kept asserted for one transmit clock period after the

TPUD signal is asserted.

Alternatively, if NOPRE is asserted, the host must supply a data byte as

soon as it asserts TPSF. The transmit function does not supply a

preamble when NOPRE is asserted, so the preamble must come from

the host. The host must supply the ﬁrst valid data byte on the TPD[7:0]

signals as soon as it asserts TPSF.

E-110 Core Operation

3-11

The packet is terminated when the host asserts the TPEF signal at the

end of the frame, which causes the transmit function to pad the packet

with bytes of zero if necessary (provided the PADEN signal is asserted)

and append the FCS (provided the CREN signal is asserted), then

terminate transmission. The transmit function asserts the TPDN signal

when the transmission is successfully completed. Packets longer than

1518 bytes (HUGEN signal deasserted) or 32 Kbytes (HUGEN signal

asserted) are truncated. Any collision causes the transmission to be

truncated and extended with jam bytes of zeroes to ensure that the entire

network sees the collision.

Collision detections other than a 16th collision without an intervening

non-colliding transmission cause the TPRT signal to be asserted, which

informs the host to restart the packet. Late collisions are treated just the

same as any other collisions if the RTRYL control input is asserted;

otherwise, a late collision causes an abort.

TPAB is asserted when any of the following conditions exists:

•

A 16th collision occurs without an intervening noncolliding

transmission.

A packet transmission attempt is made that has excessive deferrals

(greater than 6,072 transmit nibble clocks when the HUGEN signal

is deasserted or greater than 131,072 transmit nibble clocks when

HUGEN is asserted).

•

A transmission occurs with underﬂow. (The host did not supply new

transmit packet bytes fast enough to keep up with the MAC transmit

function.)

When the TPAB signal is asserted, the host must discard the packet and

try again with the next packet available.

A subsequent packet transmission, indicated by the assertion of the

TPSF signal, deasserts the TPDN), TPRT, and TPAB signals.

Transmit Function to Host Interface – The interface between the

E-110 MAC transmit function and the host consists of the following:

•

Transmit control logic

Transmit byte stream signals

Control signals between the MAC and host

3-12

Core Descriptions

The transmit control logic serves two basic purposes. It contains

temporary storage for transmit bytes from the host in the form of buffers

or FIFOs, and it translates host signals to transmit byte stream signals

that are compatible with the MAC transmit function signals. For details

on the MAC transmit function interface, see Section 2.1.1, “Transmit

Function to Host Signals,” on page 2-3.

The transmit byte stream from the host to the transmit function consists

of an eight-bit parallel data interface consisting of the TPD[7:0] signals.

The control signals from the host to the MAC’s transmit function are

TPSF, TPEF, and TPUR.

The control signals from the MAC’s transmit function to the host are

TPUD, TPDN, TPRT, TPAB, and TRST_L.

Transmit Function to Statistics Interface – The interface between the

transmit function and external statistics collection logic consists of the

TSV[30:0] and TSVP_L signals. For more details on these signals, see

Section 2.1.6, “Statistics Vector to Host Signals,” on page 2-24.

Transmit Function to MII Interface – The MII interface of the transmit

function allows the E-110 MAC to be compatible with MII-supported

PHYs. The MII interface signals conform to the IEEE 802.3u standard for

100 Mbits/s baseband networks.

The MII interface consists of a set of transmit signals and a set of receive

signals. The transmit signals are MTXD[3:0], MTXEN, MTXER, MCRS,

MCOL, and MTXC. For more details on these signals, see Section 2.1.4,

“SMII/MII to PHY Signals,” on page 2-12.

3.2.1.2 MAC Receive Function

The normal E-110 MAC architecture includes an independent receive

channel between the host and the MII, which is located on the PHY side.

The receive function block provides the Ethernet MAC operations

described in this section. Figure 3.8 shows how the receive function

interfaces to the rest of the system.

E-110 Core Operation

3-13

Figure 3.8 Receive Function Interface

E-110

ASIC

Receive

Byte Stream

MAC Function

Receive

Logic

Control

Host

Receive

Function

Status

Receive Statistics

Statistics

Logic

MII or SMII

External

MII PHY

The general ﬂow of receive packet data is a from a PHY into the receive

function block and out through the receive logic to the host system. The

receive function block of the E-110 MAC interprets 100BASE-T MII

receive data nibble streams and supplies correctly formed packet byte

1

streams to the host. The receive function searches for the SFD at the

beginning of the packet, veriﬁes the FCS, and detects any dribble nibbles

or receive code violations.

After any packet has been sent to the host from the receive function, the

MAC produces a receive statistics vector. A long event or a carrier event

is noted for a subsequent statistics vector. See the deﬁnition of the

RSV[27:0] signals in Chapter 2 for an explanation of long and carrier

events.

The receive function detects and removes the preamble and SFD bytes

at the beginning of the received packet. The E-110 MAC receive function

enforces a minimum IPG between the end of the data portion of one

packet, which contains the FCS, and the beginning of the data

(destination address) portion of the following packet. The IPG allows for

the stations and media to recover between transmissions.

1. See Section 1.2.1, “Fast Ethernet Overview,” on page 1-3 for an explanation of 100BASE-T.

3-14

Core Descriptions

The receive function block operates on the 25 MHz (100 Mbit/s

operation) or 2.5 MHz (10 Mbit/s operation) transmit nibble or symbol

clock (MRXC) supplied by the PHY. MRXC is considered to be a

continuous clock although it may have gaps as deﬁned in the IEEE

802.3u MII speciﬁcation. The connecting interface to the host also

operates on the same receive nibble clock and communicates

synchronously with the receive function. Refer to Section 2.1.2, “Receive

Function to Host Signals,” on page 2-5 for detailed requirements on how

the host interfaces to the receive function.

The receive function supplies the receive data a byte at a time to the host

on the RPD[7:0] signals and inputs the receive data from the PHY a

nibble at a time. Receive data bytes are transferred at one-half the nibble

clock rate. The receive nibble data is also sent to the receive function

FCS checker. MII input nibbles (MRXD[3:0]) are only valid when MRXDV

is asserted.

The FULLD and HUGEN control signals affect the operation of the E-110

MAC receive block. The host must appropriately manage any transitions

of these signals and ensure that only valid combinations of control

signals are used. The E-110 MAC receive function also responds to the

MTXEN signal from the transmit function when not in full-duplex mode.

If MTXEN is asserted, it indicates that a data packet is being transmitted.

If the MAC is in half-duplex mode, the receive function is disabled when

MTXEN is asserted and enabled when it is deasserted. In full-duplex

mode, the MTXEN signal does not affect the receive function.

A packet transfer to the host from the receive function begins when the

receive function asserts the RPSF and RPDV signals along with the ﬁrst

byte of received packet data after removing the preamble and SFD. For

subsequent data bytes, the receive function asserts only the RPDV

signal until the last byte, when it asserts both RPDV and RPEF. There is

no provision for ﬂow control feedback from the host to the receive

function, so the host must handle the receive packet data bytes as they

arrive.

The receive packet starts at the MII interface when the PHY asserts the

MRXDV signal and ends when the PHY deasserts the MRXDV signal.

The receive function passes packets less than or equal to 1518 bytes (or

less than or equal to 32 Kbytes with the HUGEN signal asserted). Longer

packets are truncated. Collision fragments and other carrier events (for

example, a preamble but no SFD) are received as packets if a valid

E-110 Core Operation

3-15

preamble is seen following a valid IPG. The MAC asserts the RSV25

signal, one of the bits of the Receive Statistics Vector, to indicate that a

carrier event occurred. The receive function notes a long event if the

MCRS signal is asserted for over 24,288-bit times if the HUGEN signal

is not asserted and over 524,288-bit times if HUGEN is asserted.

Other modules can use the RRST_L signal as a host reset synchronized

to the MRXC receive clock. Because the MRXC signal can be slow with

1

respect to a host reset pulse, or even stopped, the MAC latches the host

reset signal, HRST_L, without using MRXC and uses the HRST_L signal

to assert RRST_L asynchronously to MRXC. The MAC then deasserts

RRST_L synchronously on the transition of the MRXC clock.

Receive Function to Host Interface – The interface between the

E-110 MAC receive function and the host consists of the following:

•

Receive control logic

Receive byte stream signals

Status Signals

The receive control logic is a designer-speciﬁc implementation. It may

contain temporary storage in the form of buffers or FIFOs for receive

bytes from the MAC, and it may translate receive byte stream signals

from the receive function that are compatible with the host interface

signals.

The host receives the byte stream from the receive function over an

eight-bit parallel data interface consisting of the RPD[7:0] signals.

The status signals from the receive function to the host are RPDV, RPSF,

RPEF, RRST_L, CRCO[9:1], CRCG, BCO, MCO, and BYTE7. For more

details on these signals, see the subsection entitled “Receive Function

to Host Signals” on page 2-5.

Receive Function to Statistics Interface – The interface between the

receive function and external statistics collection logic consists of the

RSV[27:0] and RSVP_L signals. For more details on these signals, see

Section 2.1.6, “Statistics Vector to Host Signals,” on page 2-24.

1. MRXC from the PHY may be extended by a cycle when the PHY switches from recovered

clock to nominal clock. See the subsection entitled “MRXC Receive Nibble or Symbol Clock

Input” on page 2-12.

3-16

Core Descriptions

Receive Function to MII Interface – The MII of the receive function

allows the E-110 MAC to be compatible with MII PHYs. The MII interface

signals conform to the IEEE 802.3u standard for 100 Mbit/s baseband

networks.

The MII consists of a set of transmit signals and a set of receive signals.

The receive signals are MRXD[3:0], MRXDV, MRXER, and MRXC. For

more details on these signals, see Section 2.1.4, “SMII/MII to PHY

Signals,” on page 2-12.

3.2.2 MAC Control Module Core Operation

The optional MAC control module core implements full-duplex ﬂow

control for the E-110 core.

Control frames currently have one deﬁned opcode: pause. The pause

operation is used to inhibit transmission of data frames for a speciﬁed

period of time. Using the MAC control module core, a client wishing to

inhibit transmission of data frames from another station generates a

pause control frame. The pause control frame contains a reserved

multicast address of 01-80-C2-00-00-01, a pause opcode, and a pause

time ﬁeld, consisting of a 16-bit value expressed in slot times. The pause

operation does not inhibit the transmission of MAC control frames but it

does inhibit transmission of MAC data frames until the pause timer

expires. Pause frames, however, do not affect the E-110 core data

transmission until frames currently being transmitted are ﬁnished.

Upon receipt of a valid MAC control frame with the pause opcode and a

destination address equal to a multicast address of 01-80-C2-00-00-01

or its own unicast address, the MAC control module loads its pause timer

with the value sent in pause time ﬁeld. If the pause time ﬁeld is nonzero,

the E-110 core is said to be paused from transmitting data frames and

waits for pause time number of slot times to initiate transmission. New

pause frames override previous pause frames. The MAC control module

core does not update its pause timer value when it receives an invalid

control frame (one containing a bad FCS, code errors, or dribble nibbles

or a control packet less than minimum packet size).

The MAC control module reports statistics for management purposes.

Along with the RSV[27:0] and TSV[30:0] statistics vector signals, the

XMT_PAUSEF, RSVD_PAUSEF and UNSUPP_OPCODE signals are

available to the host to read for management purposes.

E-110 Core Operation

3-17

A mirror counter in the MAC control module core is loaded with a value

when a pause control packet is sent. The purpose of the mirror counter

is to roughly keep track of the other station’s pause timer. The mirror

value has to take into account the packet transmit time and the pause

value load time on the other end. The packet transmit time is the time it

takes for the station’s own control packet to be transmitted. The pause

value load time is the time it takes for the other station to decode the

packet, check the FCS, and load the pause time into its pause timer. The

station receiving the control packet loads X (pause time) into the pause

timer and the station transmitting the control packet loads X+ n (n is a

programmable value) into the mirror counter. The mirror counter allows

the transmitting station to send another pause control packet before the

receiving station’s pause timer expires if the receive buffer congestion

has not been alleviated.

3.2.3 MIIM Core Operation

The optional MIIM core is a 16-bit parallel interface on the host side and

a 4-signal interface (MDO, MDI, MDOEN, and MDC) on the MII side. The

MIIM controls a PHY and gathers status from it. The MIIM core is

compatible with 10/100/1000 Mbit/s PHYs as well as 10 Gbit/s PHYs.

The register layout for a 10/100/1000 Mbit/s PHY is shown in Table 3.1.

The 10 Gbit/s PHY register layout is not yet ﬁnalized.

3-18

Core Descriptions

All 10/100/1000 PHYs that incorporate an MII contain the basic register

set (registers 0 and 1). Registers 2 through 7 are part of the extended

register set.

Table 3.1

MIIM Register Set for 10/100/1000 Mbit/s PHYs

Register

Address

Register Name

Basic/Extended

0

Control

Basic

1

Status

Basic

2–3

PHY Identiﬁer

Extended

4

Autonegotiation Advertisement

Autonegotiation Link Partner Ability

Autonegotiation Expansion

Autonegotiation Next Page Transmit

Reserved

5

6

7

8–15

16–31

Vendor-Speciﬁc

3.2.3.1 Write PHY Control Register (10/100/1000 Mbit/s PHYs)

To write the Control Register in a 10/100/1000 Mbit/s PHY, the host

places the PHY address on the MIIM core’s FIAD[4:0] signals and the

address of the Control Register within the PHY on the core’s

DEV_OR_REG_AD[4:0] signals.

The host CTLD_OR_AD[15:0] signals contain the data that is sent to the

PHY Control Register and the host ST_OP[3:0] control signals must be

set to 0b0101 (10/100/1000 Mbit/s PHY write operation). When the host

asserts the MMD_REQ control signal, the data on the FIAD[4:0],

DEV_OR_REG_AD[4:0], and CTLD_OR_AD[15:0] buses is loaded into

the MIIM core, and the core asserts the BUSY signal. The MMD_REQ

signal should stay asserted until BUSY becomes asserted. The host

must not change any of the address, data, or control lines while BUSY

is asserted. During the time the MIIM core asserts BUSY, it uses the

MDO, MDC, and MDOEN signals to transport data to the Control

Register of the selected PHY, using the Management Frame Format

speciﬁed in the MII speciﬁcation. The MDO and MDI signals are normally

E-110 Core Operation

3-19

connected to a 3-state bidirectional transceiver on the PHY side of the

MIIM core. A single bidirectional data line from the transceiver, MDIO,

transfers control and status data to and from the PHY. The MDOEN

signal controls the transceiver direction.

The PHY Control Register (Register 0) layout is shown in Table 3.2.

Table 3.2

PHY Control Register Bit Deﬁnitions

Description

Bit

Name

Reset

Operation

15

1 = PHY reset

R/W,¹SC²

0 = Normal operation

14

13

12

11

10

9

Loopback

1 = Enable loopback³

0 = Disable loopback

R/W

Speed Selection 1 = 100 Mbit/s

0 = 10 Mbit/s

R/W

Autonegotiation

Enable

1 = Enable autonegotiation⁴

0 = Disable autonegotiation

R/W

Power Down

1 = Power down

0 = Normal operation

R/W

Isolate

1 = Electrically isolate PHY from MII

0 = Normal operation

R/W

Restart

Autonegotiation

1 = Restart autonegotiation process

0 = Normal operation

R/W, SC

R/W

8

Duplex Mode

Collision Test

Reserved

1 = Full duplex

0 = Half duplex

7

1 = Enable COL signal test

0 = Disable COL signal test

R/W

6–0

Write as 0, ignore on read

R/W

1. R/W = Read/Write.

2. SC = Self-Clearing. (After the bit is set to one, the operation takes place and

the PHY clears the bit back to zero.)

3. Loopback connects the PHY transmit signals to the PHY receive signals,

which allows network isolation and troubleshooting.

4. Autonegotiation is a signalling method described in clause 28 of the IEEE

802.3u speciﬁcation. It allows each node to deﬁne its own operating mode

(for example, 10 Mbits/s, 100 Mbits/s, 100BASE-TX, 100BASE-T4, or full

duplex) and to determine the operating mode of the node to which it is

connecting. Autonegotiation is conceptually similar to the signalling method

used with modems, where two nodes negotiate their capabilities and settle

on the highest common denominator.

3-20

Core Descriptions

3.2.3.2 Write PHY Control Register (10 Gbit/s PHYs)

Two frames must be sent to a PHY to initially write data to a Control

Register. First, the address of the Control Register must be sent to the

PHY, then the data is sent to the Control Register of that PHY. After the

address has been written, a write operation is used to write to the Control

Register whose address was previously written to the PHY. Subsequent

postwrite increment address operations are used to write to the next PHY

Control Register. The steps to write to the PHY are outlined below.

Write PHY Control Register Address – To write the address of a

Control Register to a 10 Gbit/s PHY, the host places the PHY Control

Register address within the PHY on the MIIM core’s CTLD_OR_AD[15:0]

lines. It also places the port address on FIAD[4:0] and the PHY device

address on the core’s DEV_OR_REG_AD[4:0] signals.

The host ST_OP[3:0] control signals must then be set to 0b0000

(10 Gbit/s PHY write address operation). When the host asserts the

MMD_REQ control signal, the data on the FIAD[4:0],

DEV_OR_REG_AD[4:0], and CTLD_OR_AD[15:0] buses is loaded into

the MIIM core, and the core asserts the BUSY signal. The MMD_REQ

signal should stay asserted until BUSY becomes asserted. During the

time the MIIM core asserts BUSY, it uses the MDO, MDC, and MDOEN

signals to transport the address to the selected PHY, using the

Management Frame Format speciﬁed in the MII speciﬁcation.

Write PHY Control Register Data – To write data to the Control

Register whose address was last written to the PHY through a write

address operation, a write data operation is performed. To perform a

write data operation, the host places the PHY Control Register data on

the MIIM core’s CTLD_OR_AD[15:0] lines. It also places the port

address on FIAD[4:0] and the PHY device address on the core’s

DEV_OR_REG_AD[4:0] signals.

The host ST_OP[3:0] control signals must then be set to 0b0001

(10 Gbit/s PHY write data operation). When the host asserts the

MMD_REQ control signal, the data on the FIAD[4:0],

DEV_OR_REG_AD[4:0], and CTLD_OR_AD[15:0] buses is loaded into

the MIIM core, and the core asserts the BUSY signal. The MMD_REQ

signal should stay asserted until BUSY becomes asserted. During the

time the MIIM core asserts BUSY, it uses the MDO, MDC, and MDOEN

E-110 Core Operation

3-21

signals to transport the data to the selected PHY’s Control Register,

using the Management Frame Format speciﬁed in the MII speciﬁcation.

To write data to the Control Register whose address was last written to

the PHY through a write address operation and automatically increment

the address in the PHY, a postwrite increment address operation is

performed. To perform a postwrite increment address operation, the host

places the PHY Control Register data on the MIIM core’s

CTLD_OR_AD[15:0] lines. It also places the port address on FIAD[4:0]

and the PHY device address on the core’s DEV_OR_REG_AD[4:0]

signals.

The host ST_OP[3:0] control signals must then be set to 0b0011

(10 Gbit/s PHY postwrite increment address operation). When the host

asserts the MMD_REQ control signal, the data on the FIAD[4:0],

DEV_OR_REG_AD[4:0], and CTLD_OR_AD[15:0] buses is loaded into

the MIIM core, and the core asserts the BUSY signal. The MMD_REQ

signal should stay asserted until BUSY becomes asserted. During the

time the MIIM core asserts BUSY, it uses the MDO, MDC, and MDOEN

signals to transport the data to the selected PHY’s Control Register,

using the Management Frame Format speciﬁed in the MII speciﬁcation.

3.2.3.3 Read PHY Status Register (10/100/1000 Mbit/s PHYs)

To read the Status Register in the PHY, the host places the PHY address

on the MIIM core’s FIAD[4:0] signals and the address of the desired PHY

register on the DEV_OR_REG_AD[4:0] signals. The host must set

ST_OP[3:0] to 0b0110 (10/100/1000 Mbit/s PHY read operation).

When the host asserts the MMD_REQ control signal, the MIIM core

loads the FIAD[4:0] and DEV_OR_REG_AD[4:0] address information

into the core and the core asserts the BUSY signal. The MMD_REQ

signal should stay asserted until BUSY becomes asserted. The host

must not change any of the address or control lines while BUSY is

asserted. While the MIIM core asserts BUSY, it uses the MDO, MDC,

and MDOEN signals to read the PHY Status Register.

The PHY responds to the read request and sends data to the MIIM core

by means of the MDI signal. After the MIIM core has received all of the

data from the PHY Status Register, it deasserts the BUSY signal and

places the data on the PRSD[15:0] signals to the host. Data is

3-22

Core Descriptions

transferred to and from the PHY using the Management Frame Format

speciﬁed in the MII speciﬁcation.

The PHY Status Register (Register 1) layout is shown in Table 3.3.

Table 3.3

PHY Status Register Bit Deﬁnitions

Bit

Name

Description

Operation

15

100BASE-T4¹

1 = PHY able to perform 100BASE-T4

0 = PHY not able to perform 100BASE-T4

R/O²

14

13

12

11

100BASE-TX³

Full-Duplex

1 = PHY able to perform full-duplex 100BASE-TX

0 = PHY not able to perform full-duplex 100BASE-TX

R/O

100BASE-TX

Half-Duplex

1 = PHY able to perform half-duplex 100BASE-TX

0 = PHY not able to perform half-duplex 100BASE-TX

10 Mbits/s

Full-Duplex

1 = PHY able to operate at 10 Mbits/s in full-duplex mode

0 = PHY not able to operate at 10 Mbits/s in full-duplex mode

10 Mbits/s

Half-Duplex

1 = PHY able to operate at 10 Mbits/s in half-duplex mode

0 = PHY not able to operate at 10 Mbits/s in half-duplex mode

10–6 Reserved

Ignore when read

R/O

5

4

3

2

1

Autonegotiation

Complete

1 = Autonegotiation process completed

0 = Autonegotiation process not completed

Remote Fault

1 = Remote fault condition detected

0 = No remote fault condition detected

R/O, LH⁴

R/O

Autonegotiation

Ability

1 = PHY is able to perform autonegotiation

0 = PHY is not able to perform autonegotiation

Link Status

1 = Link is up

0 = Link is down

R/O, LL⁵

R/O, LH

Jabber Detect

1 = Jabber condition detected. Jabber is deﬁned as a

condition on an Ethernet network when a node transmits for

longer than the speciﬁed time.

0 = No jabber condition detected

0

Extended

Capability

1 = Extended register capabilities

0 = Basic register capabilities

R/O

1. 100BASE-T4 allows users to run 100BASE-T over four pairs of Category 3, 4, or 5 UTP cabling.

2. R/O = Read-Only.

3. 100BASE-TX allows users to run 100BASE-T over two pairs of Category 5 UTP and Type 1 STP.

4. LH = Latching High. When a fault condition occurs (remote fault or jabber), the bit is set. The bit

remains set until the PHY status register is read using the MIIM or the PHY is reset, at which time

the bit is cleared.

5. LL = Latching Low. When the link is not valid, the PHY clears the bit. It remains cleared until the

PHY status register is read using the MIIM. The bit is set when the PHY has determined that a valid

link has been established.

E-110 Core Operation

3-23

3.2.3.4 Read PHY Control Register (10 Gbit/s PHYs)

Two frames must be sent to a PHY to initially read status from a Control

Register. First, the address of the Control Register must be sent to the

PHY, then the status is read from the Control Register of that PHY. After

the address has been written, a read operation is used to read the

Control Register whose address was previously written to the PHY.

Subsequent postread increment address operations are used to read

from the next PHY Control Register. The steps to read from the PHY are

outlined below.

Write PHY Control Register Address – To write the address of a

Control register to a 10 Gbit/s PHY, the host places the PHY Control

register address within the PHY on the MIIM core’s CTLD_OR_AD[15:0]

lines. It also places the port address on FIAD[4:0] and the PHY device

address on the core’s DEV_OR_REG_AD[4:0] signals.

The host ST_OP[3:0] control signals must then be set to 0b0000

(10 Gbit/s PHY write address operation). When the host asserts the

MMD_REQ control signal, the data on the FIAD[4:0],

DEV_OR_REG_AD[4:0], and CTLD_OR_AD[15:0] buses is loaded into

the MIIM core, and the core asserts the BUSY signal. The MMD_REQ

signal should stay asserted until BUSY becomes asserted. During the

time the MIIM core asserts BUSY, it uses the MDO, MDC, and MDOEN

signals to transport the address to the selected PHY, using the

Management Frame Format speciﬁed in the MII speciﬁcation.

Read PHY Control Register Data – To read data from the Control

register whose address was last written to the PHY through a write

address operation, a postread increment address operation is performed.

To perform a postread increment address operation, the host places the

PHY port address on FIAD[4:0] and the PHY device address on the

core’s DEV_OR_REG_AD[4:0] signals.

The host ST_OP[3:0] control signals must then be set to 0b0010

(10 Gbit/s PHY postread increment address operation). When the host

asserts the MMD_REQ control signal, the data on the FIAD[4:0], and

DEV_OR_REG_AD[4:0] buses is loaded into the MIIM core, and the core

asserts the BUSY signal. The MMD_REQ signal should stay asserted

until BUSY becomes asserted. During the time the MIIM core asserts

BUSY, it uses the MDO, MDC, and MDOEN signals to read the status

from the selected PHY’s Control Register, using the Management Frame

3-24

Core Descriptions

Format speciﬁed in the MII speciﬁcation. The status is available on

PRSD[15:0] after the MIIM core deasserts the BUSY signal.

3.2.3.5 Scan Operation

When the host asserts the MIIM_SCAN signal, the MIIM core performs

a continuous read operation of the PHY register speciﬁed by the

FIAD[4:0] and DEV_OR_REG_AD[4:0] signals. The scan operation can

be used to poll the PHY Status register (address 0x001), which allows

the host to monitor the Link Status bit. The MIILF signal output reﬂects

the state of the Link Status bit in the PHY Status register.

During a scan operation, the MIIM core keeps the BUSY signal asserted

until the last read is ﬁnished. If the MIIM_SCAN signal is deasserted

before the end of the current read operation, the MIIM core completes

the current read operation and then deasserts the BUSY signal. For

every read performed during the scan operation, the PRSD[15:0] signals

are also updated. During the scan operation, the NVALID signal should

be used to qualify the validity of the PRSD[15:0] and MIILF signals.

When the MIIM_SCAN signal is asserted to perform a continuous scan,

the MMD_REQ signal must be deasserted.

3.2.4 SMII Core Operation

The SMII core allows communication with a PHY using just two pins per

port, a transmit data pin and a receive data pin. Complete MII information

between a MAC and PHY can communicated over these two pins at a

125 MHz rate. The SMII core can operate in two clock synchronization

modes:

•

Typical SMII

Source Synchronous SMII

3.2.4.1 Typical SMII Operation

In typical SMII operation, the SMII core’s RXCLK125 and TXCLK125

clock inputs may both be connected to the same externally provided

125 MHz clock. The PHY also receives this same clock. Similarly, the

SMII core’s TXSYNC and RXSYNC signals may be connected to the

same externally provided sync signal. The PHY also receives the same

sync signal. This arrangement assumes that the SMII core and PHY data

E-110 Core Operation

3-25

will both be slaved to the external 125 MHz clock and sync signals.

Figure 3.9 shows a typical SMII clock arrangement.

Figure 3.9 Typical SMII Block Diagram

SMII_RXD

SMII_TXD

SMII

Core

PHY

TXCLK125

RXCLK125

125 MHz

Clock

TXSYNC

RXSYNC

÷10

SYNC

Clock

3.2.4.2 Source Synchronous SMII Operation

In source synchronous mode, the receive data source (the PHY) and the

transmit data source (the SMII core) each have their own clock and sync

signals. In this case, the signals are connected as shown in Table 3.4.

Table 3.4

Source Synchronous Clock and Synchronization

SMII Core Signal Source

Destination

RXCLK125

RXSYNC

TXCLK125

TXSYNC

PHY

SMII Core

PHY

External 125 MHz clock

External sync generator

Figure 3.10 shows the source synchronous SMII clock arrangement.

3-26

Core Descriptions

Figure 3.10 Source Synchronous Block Diagram

SMII_RXD

SMII_TXD

RXCLK125

SMII

Core

PHY

RXSYNC

125 MHz

Clock

TXCLK125

÷10

SYNC

Clock

TXSYNC

For applications requiring more than 1 ns of trace delay, the core’s two

125 MHz clocks (TXCLK125 and RXCLK125) and two synchronization

signals (TXSYNC and RXSYNC) allow multiport MAC to PHY

communication in both full- and half-duplex modes. All signals are

synchronous to the 125 MHz clocks.

Direct MAC-to-MAC communication is also allowed as well as the source

synchronous mode.

3.2.4.3 SMII/MII Operation

The SMII core can operate in SMII mode as well as the MII mode. When

the MII_SEL signal from the host is asserted, the core operates in the

MII mode; when the signal is deasserted, the core operates in the SMII

mode.

3.2.4.4 Receive Data Operation

Receive data and control information are signalled in 10-bit segments. In

100 Mbit/s mode, each segment represents a new byte of data. In

10 Mbit/s mode, each segment is repeated ten times; therefore, every

10 segments represents a new byte of data. The MAC can sample any

one of every 10 segments in 10 Mbit/s mode.

Segment boundaries are delimited by RX_SYNC. The PHY continuously

generates a pulse on RX_SYNC every 10 125 MHz clocks. Figure 3.11

E-110 Core Operation

3-27

shows typical timing for a receive data operation from PHY to MAC using

SMII.

Figure 3.11 Typical SMII Receive Data Timing

RXCLOCK125

RXSYNC

CRS RX_DV RXD0 RXD1 RXD2 RXD3 RXD4

RXD5 RXD6

RXD7

SMII_RXD

As shown in Figure 3.11, the receive data frame contains two control bits

(CRS and RX_DV), followed by eight data bits, for a total of 10 bits. The

effective transfer rate of the data bits is 100 Mbits/s. The meaning of the

bits is:

•

CRS: Carrier Sense, identical to MII CRS, except that it is not an

asynchronous signal.

•

RX_DV: Receive Data Valid, identical to MII.

SMII_RXD[7:0]: Receive Data. See Table 3.5 for an interpretation of

the data bits.

Table 3.5

SMII_RXD[7:0] Meaning

Control Bit

Encoding

Data Bits

CRS RX_DV

RXD0

RX_ER SPEED DUPLEX

One data byte (two MII nibbles)

RXD1

RXD2

RXD3

RXD4

RXD5

RXD6

RXD7

1

X

0

1

LINK

JABBER UPPER FALSE

As shown in the table, the two control bits deﬁne the type of data in the

8 data bits of the frame. if RX_DV is 0, the data bits contain RX_ER and

PHY status. If RX_DV is 1, the data bits contain two MII nibbles. The bits

deﬁnitions follow.

RX_ER

Receive Error

0

RX_ER, when 1, indicates that the PHY detected an error

somewhere in the previous frame. This bit should be valid

in the segment immediately following a frame, and should

3-28

Core Descriptions

stay valid until the ﬁrst data segment of the next frame

begins.

SPEED

DUPLEX

LINK

Speed Mode

Indicates the speed mode.

1

2

3

4

5

SPEED

Meaning

0

1

10 Mbits/s

100 Mbits/s

Duplex Mode

Indicates the duplex mode.

DUPLEX

Meaning

0

1

Half-duplex

Full-duplex

Link Status

Indicates the link status.

LINK

Meaning

0

1

Link down

Link up

JABBER

UPPER

Jabber Status

Indicates the jabber status.

JABBER

Meaning

0

1

No jabber

Jabber condition

Upper Nibble Validity

Indicates the validity of the upper nibble of the last byte

of the previous frame. This bit should be valid in the

segment immediately following a frame, and should stay

valid until the ﬁrst data segment of the next frame begins.

UPPER

Meaning

0

1

No jabber

Jabber condition

E-110 Core Operation

3-29

FALSE

False Carrier

6

Indicates if a false carrier was detected.

FALSE

Meaning

0

1

No false carrier

False carrier

3.2.4.5 Transmit Data Operation

Transmit data and control information are signalled in 10-bit segments,

just like the receive path. In 100 Mbit/s mode, each segment represents

a new byte of data. In 10 Mbit/s mode, each segment is repeated ten

times; therefore, every 10 segments represents a new byte of data. The

PHY can sample any one of every 10 segments in 10 Mbit/s mode.

Segment boundaries are delimited by TX_SYNC. The PHY continuously

generates a pulse on TX_SYNC every ten 125 MHz clocks. Figure 3.12

shows typical timing for a transmit data operation from MAC to PHY

using SMII.

Figure 3.12 Typical SMII Transmit Data Timing

TXCLOCK125

TXSYNC

TX_ER TX_EN TXD0 TXD1

TXD2 TXD3 TXD4

TXD5 TXD6

TXD7

SMII_TXD

As shown in Figure 3.12, the transmit data frame contains two control

bits (TX_ER and TX_EN), followed by eight data bits, for a total of

10 bits. The effective transfer rate of the data bits is 100 Mbits/s. The

meaning of the bits is:

•

TX_EN: Transmit Enable, identical to MII TX_EN.

TX_ER: Transmit Error, identical to MII TX_ER.

SMII_TXD[7:0]: Transmit Data. See Table 3.6 for an interpretation of

the data bits.

3-30

Core Descriptions

Table 3.6

SMII_TXD[7:0] Meaning

Control Bit

Encoding

Data Bits

TX_ER TX_EN

TXD0

TXD1 TXD2

TXD3

LINK UP NO JABBER

One data byte (two MII nibbles)

TXD4

TXD5

TXD6

1

TXD7

X

0

1

FORCE

100 FD

As shown in the table, the two control bits deﬁne the type of data in the

8 data bits of the frame. If TX_EN is 0, the data bits contain PHY control

information. If TX_EN is 1, the data bits contain two MII nibbles. As far

as the PHY is concerned, the data bits are used to convey only packet

data. To allow a MAC-to-MAC connection, the MAC uses the data bits to

convey status between frames. The bits deﬁnitions follow.

FORCE

Force Error in MAC-to-MAC Connection

0

FORCE

Meaning

0

1

No forced error

Forced error

100

Speed Mode

1

Indicates the speed mode.

100

Meaning

0

1¹

10 Mbits/s

100 Mbits/s

1. Bit is ﬁxed at 1

FD

Duplex Mode

2

Indicates the duplex mode.

DUPLEX

Meaning

0

1¹

Half-duplex

Full-duplex

1. Bit is ﬁxed at 1

E-110 Core Operation

3-31

LINK UP

Link Status

Indicates the link status.

3

4

LINK

Meaning

0

1

Link down

Link up

NO JABBER Jabber Status

Indicates the jabber status.

JABBER

Meaning

0¹

1

No jabber

Jabber condition

1. Bit is ﬁxed at 0

3-32

Core Descriptions

Chapter 4

Functional Timing

This chapter examines various E-110 functional timing scenarios. The

key timing relationships are discussed. For details of the operation of

each of the signals discussed, refer to Chapter 2, “Signal Descriptions.”

This chapter contains the following sections:

•

Section 4.1, “MAC Functional Timing,” page 4-1

Section 4.2, “MIIM Core Functional Timing,” page 4-7

Section 4.3, “Transmit Collision Functional Timing,” page 4-10

4.1 MAC Functional Timing

The following subsections describe the functional timing for MAC

operations, including MAC receive and transmit packet timing.

4.1.1 MAC Receive Packet Timing

The timing for a typical receive packet is shown in Figure 4.1. Notice that

the PHY asserts the MCRS and MRXDV signals at the beginning of a

packet reception. The PHY asserts MCRS asynchronously as soon as it

detects a nonidle medium. The PHY also asserts MRXDV synchronously

to the rising edge of MRXC when it has decoded a valid preamble.

Ethernet-110 Core Technical Manual

4-1

Figure 4.1 E-110 MAC Receive Packet Timing

MRXC

MCRS

MRXDV

0

MRXD[3:0]

MRXER

CRCG

0

5

D

3

4

0

1

0

2

0

3

0

4

3

1

4

A

CRCO[9:1]

BYTE7

MCO

Valid FCS

Valid MCO

Valid BCO

BCO

RPSF

RPDV

RPD[7:0]

RPEF

00

43

04

00

01

20

03

40

13

A4

RRST_L

RSVP_L

RSV[27:0]

Valid

Note: RSVP_L is asserted one clock before RPEF.

4.1.1.1 Preamble

Every packet is preceded by a preamble consisting of seven octets

followed by a single SFD octet. The preamble and SFD are shown in

Figure 4.2.

4-2

Functional Timing

Figure 4.2 Packet Preamble and SFD

10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101011

Preamble

SFD

In Figure 4.2, the preamble and SFD are shown in the serial bit order of

reception. For each octet, the leftmost bit in each octet value represents

the least signiﬁcant bit of the octet and the rightmost bit represents the

most signiﬁcant bit of the octet. The preamble consists, then, of seven

octets of 0x55. The SFD octet (0xD5) indicates the start of frame and

follows the preamble. In Figure 4.1, the MRXD[3:0] data changes in the

beginning from 0x0 to 0x5 to 0xD, which represents the transition from

idle to preamble to SFD.

4.1.1.2 Nibble and Byte Assembly

Data is passed to the E-110 MAC from the PHY as nibbles on the

MRXD[3:0] lines. Because the data is received least signiﬁcant bit ﬁrst,

the low nibble is received, then the high nibble. Figure 4.1 shows that the

PHY transfers the MRXD[3:0] nibbles received after the SFD to the

E-110 MAC in the following order: 0x3, 0x4, 0x4, 0x0, 0x0, 0x0, 0x1, 0x0,

0x0, 0x2, 0x0, 0x0, 0x3, 0x0, 0x0, 0x4, and so on. The MAC then

assembles the nibbles into bytes with the nibbles in reverse position, so

that the high and low nibbles are in the proper order for the host on the

RPD[7:0] signals. The RPD[7:0] data in Figure 4.1 shows that the MAC

sends the bytes to the host in the following order: 0x43, 0x04, 0x00,

0x01, 0x20, 0x03, 0x40, and so on.

A packet transmission to the receive control logic from the receive

function begins when the receive function asserts the RPSF and RPDV

signals along with the ﬁrst byte of received packet data after removing

the preamble and SFD. For subsequent data bytes, the receive function

asserts only the RPDV signal until the last byte, when it asserts both the

RPDV and RPEF signals.

4.1.1.3 FCS Operation

The CRCO[9:1] lines reﬂect the state of the receive function FCS register

after the ﬁrst 48 bits (six bytes) of the receive packet. The CRCG signal,

when asserted, indicates that the CRCO[9:1] signals are valid. The

MAC Functional Timing

4-3

CRCO[9:1] signals contain the 9-bit hash function computed from the

destination address. The 9-bit hash function is generated after the ﬁnal

destination address bit is received.

The 9-bit value can be used as an index into an external multicast ﬁlter

hash table to determine if the frame should be received. External logic

can decide to either accept or reject the incoming frame.

4.1.1.4 End of Frame

When asserted, the RPEF signal marks the last byte of the receive

packet. At the end of the packet, the E-110 MAC asserts RSVP_L, an

active-LOW pulse that indicates the availability of a new receive statistics

vector on the RSV[27:0] lines.

4.1.2 MAC Transmit Packet Timing

The timing for a typical transmit packet is shown in Figure 4.3.

4-4

Functional Timing

Figure 4.3 E-110 MAC Transmit Packet Timing

MTXC

MTXEN

MTXD[3:0]

TPSF

0

5

D

9

A

8

3

4

0

1

0

1

0

4

6

F

FCS

0

TPUD

04

00

10

00

01

64

FF

CB

TPD[7:0]

TPEF

A9

38

TSVP_L

TSV[30:0]

TPDN

1

Valid

MTXER

TPAB

TPRT

TPUR

TRST_L

1. Transmit status vector valid.

4.1.2.1 Start of Transmission

When the MAC is ready to begin a packet transmission, it asserts the

MTXEN signal to the PHY to indicate that the MAC is presenting nibbles

on the MII for transmission.

4.1.2.2 Preamble

In the example shown in Figure 4.3, the MAC begins sending the

preamble to the PHY. The preamble consists of the value 0x5 on the

MAC Functional Timing

4-5

MTXD[3:0] lines (as soon as MTXEN is asserted). As an option, the host

may assert the NOPRE signal to instruct the MAC not to send a

preamble, in which case the host itself must supply the preamble. After

sending 15 nibbles of 0x5, the MAC sends a 0xD, which is the SFD. The

preamble and SFD add up to 16 nibbles (8 bytes).

4.1.2.3 Nibble and Byte Assembly

Data is passed from the E-110 MAC to the PHY as nibbles on the

MTXD[3:0] lines. The TPD[7:0] data in Figure 4.3 shows that the MAC

receives the bytes from the host in the following order: 0xA9, 0x38, 0x04,

0x00, 0x10, 0x00, 0x01, and so on. Because the data is sent to the PHY

least signiﬁcant bit ﬁrst, the low nibble is sent ﬁrst, followed by the high

nibble. The MAC must assemble the host bytes into nibbles with the

nibbles in reverse position, so that the low and high nibbles are in the

proper serial bit order for transmission to the PHY on TXD[3:0].

Figure 4.3 shows that the MAC transfers the MTXD[3:0] nibbles to the

PHY after the SFD in the following order: 0x9, 0xA, 0x8, 0x3, 0x4, 0x0,

0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x1, 0x0, and so on.

MTXD[3:0] nibbles are valid only when the MTXEN signal is asserted.

The transmit function supplies nibbles of zero when MTXEN is not

asserted. When MTXEN is asserted, the transmit function supplies

preamble, SFD, transmit data, FCS, jam, or pad nibbles.

4.1.2.4 End of Frame

When asserted, the TPEF signal marks the last byte of the transmit

packet and must be valid for two transmit clock periods. The MAC

appends the FCS bytes to the packet data from the host and then

asserts the TPDN signal to the host, indicating successful packet

completion. The MAC then asserts the TSVP_L signal to indicate the

availability of a new transmit statistics vector (TSV[30:0]).

4-6

Functional Timing

4.2 MIIM Core Functional Timing

The following subsections describe the functional timing for MIIM

operations, including MIIM write and read timing.

4.2.1 MIIM Write Operation

The timing for an MIIM write operation from the MIIM core to a PHY is

shown in Figure 4.4.

Figure 4.4 MIIM Write Operation

HCLK

ST_OP[3:0]

0x0101 (write 10/100/1000 Mbit/s PHY)

MMD_REQ

BUSY

CTL_OR_

AD[15:0]

0x55AA

0x0A

FIAD[4:0]

DEV_OR_

REG_AD[4:0]

0x15

MDOEN

MDC

MDO

ST WR PHY

Addr

REG TA

Addr

0xAA

0x55

(0x0A) (0x15)

PRSD[15:0]

Invalid

The timing shows the sequence of events to write to a PHY control

register. The values used for addresses and data are illustrative only.