1

Harasser and Packet Analysis for Gigabit Ethernet in Post Silicon Server Validation

Project Mid Semester Report Submitted to

By

G.SWAMY (134609)

MASTER OF TECHNOLOGY

(Advanced Communication Systems)

Department of Electronics and Communication Engineering

to

SRI.A.P.RAO

(Associate Professor)

Under the guidance of

Sri. K. Ravi Kishore Mr. Jeyaraj k Jeyabalan

Associate Professor System Validation Engineer

Department of ECE Intel Technology India Pvt Ltd

NIT Warangal Bangalore

NATIONAL INSTITUTE OF TECHNOLOGY, WARANGAL

(DEEMED UNIVERSITY)

Telangana-506004

2014-2015

2

Contents Page No

1. Abstract 3

2. Literature Survey 4

3. Problem Statement 6

4. Hardware and Software Details 7

5. Work Done So far

5.1 Auto Negotiation 8

5.1.1 Speed 10

5.1.2 Duplex 14

5.2 Interrupts 17

5.2.1 Introduction to MSI and Its Capabilities 19

5.2.2 MSI Types 20

5.3 Power States 22

6. Conclusion 27

3

Abstract

Validation remains an integral and crucial phase of todays microprocessor design and

manufacturing process. Due to sheer design complexity, it is nearly impossible to detect and fix

all bugs before manufacture. Post-silicon validation is used to detect and fix bugs in integrated

circuits and systems after manufacture. In this thesis, it is described a situation in which we

have to validate the Functionality of Ethernet Controller in Post Silicon Server Validation. The

main aim of the project is to introduce different types of harassers into the Giga Bit Ethernet

controller in Post silicon server validation and to stress the Gigabit Ethernet Controller and

validate the robustness of the controller by monitoring it's behavior under prolonged stressful

tests and analyze the drop in packets because of these harassers using packet analyzing tools

such as wire shark. The different types of harassers we can introduce are Reset, Speed Change,

Power States, Interrupts, Error Injection. The general usage of harassers in post-silicon

validation environment is to stress the Gigabit Ethernet Controller and validate the robustness

of the controller by monitoring its behavior under prolonged stressful tests.

4

2. Literature Survey

One of the challenging tasks in server validation is to check correctness of the product both

before and after the product is released to maintain quality of product shipped. Validation

remains an integral and crucial phase of todays microprocessor design and manufacturing

process. Due to sheer design complexity, it is nearly impossible to fix all bugs before

manufacture. Post-silicon validation is used to detect and fix bugs in integrated circuits and

systems after manufacture [1].

In general there are many components externally connected to the CPU in the present day

systems, some of the components to be noticed are Ethernet card connected to the PCI Express

protocol of the CPU [2]. This Ethernet card is controlled by Ethernet Controller.

In this thesis, it is described a situation in which we have to validate the Functionality of

Ethernet Controller. Once the Ethernet Controller is designed it is necessary to validate the

Ethernet Functionally as well as performance wise to confirm whether it is working in

conformance with the given specifications. For Validating the Functionality of Giga Bit Ethernet

we need to introduce different types of harassers into the Giga Bit Ethernet controller in Post

silicon server validation and to stress the Gigabit Ethernet Controller and validate the

robustness of the controller by monitoring it's behavior under prolonged stressful tests and

analyze the drop in packets because of these harassers using packet analyzing tools such as

wire shark. The different types of harassers we can introduce are such as Reset, Speed Change,

Power States, Interrupts, Error Injection and analyze the packets using packet analyzing tools

such as Wire shark.

In real time computers are connected to different range in speeds of Networks. So whenever

speed is changed computer should be able to connect to that speed by auto negotiating with

the Link partner. If we change the speed any number of times it should be able to connect. By

keeping that in view in post silicon validation after Ethernet controller is designed we are

harassing the controller by changing the speed number of times in combination with the auto

negotiation. In this process after changing speed every time we will check the speed by calling

5

Link speed function running. By using Iperf also we can verify the same. In this way we can

validate the robustness of the Ethernet Controller. Speed change is implemented as part of

Auto Negotiation.

The objective of the Auto-Negotiation function is to provide the means to exchange

information between two devices that share a link segment and to automatically configure both

devices to take maximum advantage of their abilities. We use the base page exchange

mechanism to achieve Auto-Negotiation up to 100 Mbps speeds only [3].

In real time we send and receive lot of data through Ethernet. Any time we want to send data

we need to get the attention of CPU. So in Post Silicon Validation After designing Ethernet

Controller we are trying to validate the robustness of the Ethernet Controller by sending some

traffic and manually setting interrupts from the Ethernet Controller. These interrupts enable

the CPU in processing the data efficiently. Legacy interrupts like INTx need Multi-step

communication to execute an interrupt [3].

In real time we switch ON and off the Ethernet Device by switching ON or OFF the Operating

System number of times. So every time we switch ON the Computer Ethernet Link should come

up. So in Post Silicon Validation After designing Ethernet Controller we are trying to manually

change the Ethernet Device to ON and OFF state repetitively and in each state by running some

link reliable tests such as Iperf we can validate the robustness of the controller. When the

operating system boots first Ethernet device is in D0 Active. So in this state Ethernet

communication link is up and it works normally. When Ethernet Device is D3 state Device is OFF

state. In this case Communication Link will go down. In case when the device is DO uninitialized

state Device wait for initialization by BIOS. In DOU state also communication link goes down [4].

6

3. Problem Statement

Validation remains an integral and crucial phase of todays microprocessor (Next Generation

Xeon Processors) design and manufacturing process. Due to sheer design complexity, it is nearly

impossible to detect and fix all bugs before manufacture. Post-silicon validation is used to

detect and fix bugs in integrated circuits and systems after manufacture. In this thesis, it is

described a situation in which we have to validate the Functionality of Ethernet Controller in

Post Silicon Server Validation.

The main aim of the project is to introduce different types of harassers into the Giga Bit

Ethernet controller in Post silicon server validation and to stress the Gigabit Ethernet Controller

and validate the robustness of the controller by monitoring it's behavior under prolonged

stressful tests and analyze the drop in packets because of these harassers using packet

analyzing tools such as wire shark. The different types of harassers we can introduce are Reset,

Speed Change, Power States, Interrupts, Error Injection. The general usage of harassers in post-

silicon validation environment is to stress the Gigabit Ethernet Controller and validate the

robustness of the controller by monitoring its behavior under prolonged stressful tests.

7

4. Hard Ware Details

Processor: Next Generation Xeon Processors

Ethernet Card: Intel Giga Bit Ethernet Card

Ethernet Controller: Intel Giga Bit Ethernet Card

Soft Ware Details:

Programming Language: Python 2.7.6

Performance Tools: Iperf

Packet Analyzing Tool: Wire Shark

8

5. Work done so far

5.1 Auto Negotiation

In real time computers are connected to different range in speeds of Networks. So whenever

speed is changed computer should be able to connect to that speed by auto negotiating with

the Link partner. If we change the speed any number of times it should be able to connect. By

keeping that in view in post silicon validation after Ethernet controller is designed we are

harassing the controller by changing the speed number of times in combination with the Auto

Negotiation. In this process after changing speed every time we will check the speed by calling

Link speed function running. By using Iperf also we can verify the same. In this way we can

validate the robustness of the Ethernet Controller. Speed change is implemented as part of

Auto Negotiation. So we will discuss the Auto Negotiation below.

Auto-Negotiation plays a key role in the area of Computer Networks. Auto-negotiation is best

defined as the mutual agreement by two network devices sharing a wire on the speed, duplex,

and controls to govern the use of that wire. It allows a device to advertise enhanced modes of

operation it possesses to a device at the remote end of a link segment and to detect

corresponding enhanced operational modes that the other device may be advertising. The

objective of the Auto-Negotiation function is to provide the means to exchange information

between two devices that share a link segment and to automatically configure both devices to

take maximum advantage of their abilities

As a protocol auto-negotiation exists strictly at the PHY (physical) layer of the OSI (Open System

Interconnection Reference Model) and is implemented by software, hardware, or a mixture of

both. Relationship of Auto Negotiation function with OSI Reference model is shown in following

Figure 5.1.

9

Figure 5.1 Location of Auto-Negotiation function within the ISO OSI Reference Model

The Auto-Negotiation function provides a mechanism to control connection of a single MDI to a

single PHY type, where more than one PHY type may exist. The Auto-Negotiation functions shall

interact with the technology dependent PHYs through the Technology-Dependent interface.

Technology-Dependent PHYs include 1000BASE-KX, 10GBASE-KX4, 10GBASE-KR, 40GBASE-KR4,

40GBASE-CR4, and 100GBASE-CR10.When the MDI supports multiple lanes, then lane 0 of the

MDI shall be used for Auto Negotiation and for connection of any single-lane PHYs (e.g.,

1000BASE-KX or10GBASE-KR).

For a link to function properly the devices on either side of the wire must be configured in the

same manner; either both set to auto negotiation or both set to the same hard-coded speed

and duplex settings. In an environment where one device is set to auto-negotiate and the other

device is set to a hard-coded speed and duplex the auto-negotiate algorithm can detect speed

and set that appropriately. The duplex setting of the remote device is indeterminable by the

auto-negotiating device. Following the IEEE standard, the auto-negotiating device falls back to

10

half-duplex. This presents an issue if the remote device is set to full-duplex. Typically in such a

scenario, users complain of slow network connectivity and application timeouts.

5.1.1 Speed

Speed is one of the two two parameters which is to be negotiated with the link partner. IEEE

802.3u introduced 100Mb/s to what was previously only a 10 Mb/s Ethernet networking world.

Now that computers had a choice of what speed to communicate a procedure needed to be

introduced to govern this decision. With the introduction of a third speed, 1000 Mb/s or Gigabit

Ethernet, this procedure became even more important. Thus the auto-negotiation protocol was

created while still maintaining complete backwards compatibility with the 10Mb/s protocol.

A device capable of auto-negotiation transmits and receives the Link code word base page. The

receiver must identify three identical LCWs before the information is authenticated and used in

the arbitration process. The devices decode the LCW base Page and select capabilities of the

highest common denominator supported by both devices. Figure 5.2 illustrates the Base Page.

Figure 5.2 LCW Base Page

11

The First 5 bits only have two valid values. They state either to use IEEE 802.3 (Ethernet) or IEEE

802.9 (Iso Ethernet over Cat3twisted pair). The next 5 bits state what speed and duplex

combinations that a device can communicate. Bits A5 and A6 are used for Flow Control and D14

is used to acknowledge a negotiation. The last bit, D15 is used to denote the need to use Next

Page, a more advanced LCW used to negotiate Gigabit speeds and controls.

Once the LCWs are properly received, each device transmits a Base Page with an acknowledge

bit. At this point, both devices enable the mode that is the highest common mode negotiated.

The clock pulses are used for timing and recovery of the data pulses are shown in figure 5.3.

Figure 5.3 FLP Burst Timing

If the data pulse is present, it represents a value of one in the LCW for that position. The lack of

a data pulse indicates a zero in the LCW for that position, as shown in Figure 5.4.

Figure 5.4 FLP Burst Encoding

12

To support Giga Bit Speeds, the advanced version of Link Code Word Base Page is implemented

in Auto Negotiation Mechanism which is shown in below figure 5.5.

Figure 5.5 Link code word Base Page

Link Code word Base Page consisting of 48 bits. These 48 bits are transmitted with the speed of

clock pulse. As it doesn't has any particular speed before auto negotiation. The Purpose of each

bit in Link Code word Base page is described below.

Selector Field: Selector Field (S[4:0]) is a 5 bit wide field, encoding 32 possible messages.

Combinations not specified are reserved for future use .The first 5 bits only have two valid

values. They state either to use IEEE 802.3 (Ethernet) with or IEEE 802.9 (Iso Ethernet over Cat3

twisted pair).For IEEE 802.3 selector field is 00001 and for IEEE 802.9 selector field is 00010.

Technology Ability Field: Technology Ability Field (A[24:0]) is a 25-bit wide field containing

information indicating supported technologies specific to the selector field value when used

with the Auto-Negotiation for Ethernet. These bits are mapped to individual technologies such

that abilities are advertised in parallel for a single selector field value. The Technology Ability

Field encoding for the IEEE 802.3 selector with Auto-Negotiation for Ethernet is described in

below Table 5.1.

13

Table 5.1: Technology Ability Field encoding

Remote Fault: Remote Fault (RF) is encoded in bit D13 of the base link code word. The default

value is logic zero. The Remote Fault bit provides a standard transport mechanism for the

transmission of simple fault information.

Acknowledge: Acknowledge (Ack) is used by the Auto-Negotiation function to indicate that a

device has successfully received its link partners link code word.

Next Page: Next Page (NP) is encoded in bit D15 of link code word. Support of Next Pages is

mandatory. If the device does not have any Next Pages to send, the NP bit shall be set to logical

zero. If a device wishes to engage in Next Page exchange, it shall set the NP bit to logical one. If

a device has no Next Pages to send and its link partner has set the NP bit to logical one, it shall

transmit Next Pages with Null message codes and the NP bit set to logical zero while its link

partner transmits valid Next Pages. Next page exchanges will occur if either the device or its link

Partner sets the Next Page bit to logical one.

Priority Resolution Table:

Since a local device and a link partner may have multiple common abilities, a mechanism to

resolve which mode to configure is required. The mechanism used by Auto Negotiation is a

Priority Resolution function that predefines the hierarchy of supported technologies. The single

14

PHY enabled to connect to the MDI by Auto-Negotiation shall be the technology corresponding

to the bit in the Technology Ability Field common to the local device and link partner that has

the highest priority as defined in below Table 5.2.

Table 5.2 Priority Resolution Table

5.1.2 Duplex

Duplex mismatch is the most common cause for network link problems outside of physical

cabling or hardware failure. Duplex mismatches are caused by the inability of an auto

negotiation device to predict the settings of a hard-coded device. Also in accordance with the

IEEE specification the auto-negotiation device will connect with the Half-Duplex setting when

the duplex setting of the other device cannot be determined.

Parallel detection

Parallel Detection is a part of the Auto Negotiation process when trying to establishing a link

between two devices to the highest common Denominator. An Auto Negotiation Device

Transmits Base page to broadcast its capabilities such as 10 Gbps Full Duplex. To be compatible

with Devices that do not auto negotiate, Parallel detection was implemented as part of the

standard. A Non-auto negotiating device will send an idle signal indicating the speed at which it

operates. An auto negotiating device detect this idle go to half duplex and set its speed to

match what was indicated in the idle signal.

15

Case 1: Interoperability with non-auto-negotiation 100 Base T

The link partner can be a port on a 100 Mbps hub or a 10/100 Mbps switch configured for 100

Mbps operation only. The NIC in the server is configured for auto-negotiation.

Figure 5.6 Non-Auto Negotiation 100BaseT

Communication between a non-auto-negotiation 100BaseT device and the NIC follows specific

steps given below. The corresponding figure is shown in Figure 5.6.

-> The DTE powers up in link fail mode and transmits FLPs.

-> The 100BaseTX link partner powers up and sends idle symbols.

-> The DTE parallel detection function detects the idle symbol, bypasses the auto

Negotiation function, passes control to the 100BaseTX PMA, and transmits idle.

->A link is established at 100 Mbps half duplex.

Case 2 : Interoperability with auto-negotiation 100BaseT (10/100)

The link partner is a port on a 10/100 switch configured for auto negotiation. The NIC in the

server is configured for auto-negotiation and capable of 10/100/1000 Mbps operation.

Communication between auto-negotiation 100BaseT device and the NIC follows specific steps

given below. The corresponding figure is shown in Figure 5.7.

16

->Both devices power up in link fail mode and transmit FLPs.

->Each device receives and decodes the capabilities of the other.

->A link is established at 100 Mbps full duplex.

Figure 5.7: Auto Negotiation 100BaseT

17

5.2 Interrupts

In real time we send and receive lot of data through Ethernet. Any time we want to send data

we need to get the attention of CPU. So in Post Silicon Validation After designing Ethernet

Controller we are trying to validate the robustness of the Ethernet Controller by sending some

traffic and manually setting interrupts from the Ethernet Controller. These interrupts enable

the CPU in processing the data efficiently.

Interrupt is a way of getting attention to the interrupting device from the Interrupted device

An Interrupt is a hardware signal from a device to a CPU, informing the CPU that the needs

attention and signaling that the CPU should stop current processing and responding to the

device.

If the CPU is performing a task that has lower priority then the priority of the interrupt, the CPU

suspends its current thread. The CPU then invokes the interrupt handler for the device that sent

the interrupt signal. The interrupt handler services the device and when the interrupt handler

returns, the CPU resumes the processing it was doing, before the interrupt occurred.

First we will see how devices do interrupts in a legacy PC.

Figure 5.8 Older Way of Interrupts

Legacy interrupts need Multi-step communication to execute an interrupt. The required steps

need are as follows.

18

->A device signals that it needs CPU service

->The Interrupt Controller signals the CPU

->The CPU responds with INTA

->INTA puts ID-number on system bus

->CPU uses ID-number to lookup IVT entry

->Interrupt handler executes Interrupt service routine and returns where it was

interrupted.

Improvement to be done for faster Interrupt handling

Faster response to interrupts is possible if the old multi-step communication scheme can be

replaced by a single-step protocol. Less expensive PCs can be manufactured if their total

number of signal pins and the physical interconnections can be reduced. More devices can have

their own private interrupt(s) if signal lines are not required so this brought the need for

development of a new system for handling interrupts in a fast and efficient way. So MSI were

developed for this. Message Signaling allows all the needed information to arrive in a single

package, and go directly from a device to the CPU.

Figure 5.9 New Way of handling interrupts

19

5.2.1 Introduction to MSI and Its Capabilities

Message Signaled Interrupts (MSI) are an alternative in-band method of signaling an interrupt,

using special in-band messages to replace traditional out-of-band assertion of dedicated

interrupt lines. While more complex to implement in a device, message signaled interrupts

have some significant advantages over pin-based out-of-band interrupt signaling Message

signaled interrupts are supported in PCI bus since its version 2.2, and in later available PCI

Express bus. Some non-PCI architectures also use message signaled interrupts. Traditionally, a

device has an interrupt line (pin) which it asserts when it wants to signal an interrupt to the

host processing environment. This traditional form of interrupt signaling is an out-of-band form

of control signaling since it uses a dedicated path to send such control information, separately

from the main data path. Message signaled interrupts are replacing those dedicated interrupt

lines with in-band signaling, where special messages indicating interrupts are exchanged

through the main data path.

As an example, PCI Express does not have separate interrupt pins at all, and it uses special in

band messages to allow it to emulate an interrupt pin assertion or de assertion. Message

signaled interrupts allow the device to write a small amount of data to a special memory-

mapped I/O address, the chipset then delivers the corresponding interrupt to a processor.

A common misconception with Message Signaled Interrupts is that they allow the device to

send data to a processor as part of the interrupt. The data that is sent as part of the write is

used by the chipset to determine which interrupt to trigger on which processor. It is not

available for the device to communicate additional information to the interrupt handler.

20

5.2.2 MSI Types

PCI defines two optional extensions to support Message Signaled Interrupts.

They are

->MSI

->MSI-X

MSI:

MSI permits a device to allocate 1, 2, 4, 8, 16 or 32 interrupts. The device is programmed with

an address to write to (generally a control register in an interrupt controller), and a 16-bit data

word to identify it. The interrupt number is added to the data word to identify the interrupt.

Some platforms such as Windows do not use all 32 interrupts but only use up to 16 interrupts.

Figure 5.10 shows how Ethernet traffic is distributed across single CPU in a single core system.

Figure 5.10 Network Data Flow In a Single Core Processor

MSI-X:

MSI-X is an extension to MSI to enable support for more vectors and other advantages. MSI-X

permits a device to allocate up to 2048 interrupts. The single address used by original MSI was

found to be restrictive for some architectures. In particular, it made it difficult to target

individual interrupts to different processors, which is helpful in some high-speed networking

21

applications. MSI-X allows a larger number of interrupts and gives each one a separate target

address and data word. Devices with MSI-X do not necessarily support 2048 interrupts but at

least 64 which is double the maximum MSI interrupts. Optional features in MSI (64-bit

addressing and interrupt masking) are also mandatory with MSI-X.

The ability to communicate efficiently between queues and particular processor cores is

handled by MSI-X. MSI-X is the next generation of MSI, which passes interrupts to a single

processor core. Conversely, MSI-X provides multiple interrupt vectors, which allow multiple

interrupts to be handled simultaneously and load balanced across multiple cores. This

improvement helps improve CPU utilization and lower latency.

With an interrupt vector for each queue, the controller can handle multiple interrupts

simultaneously, preventing the bottlenecks associated with guiding all interrupts through a

single vector.

Figure 5.11 shows how Ethernet traffic is distributed across CPU cores in a multi-core System.

Figure 5.11 Network Data Flow In a Multi Core Processor

22

5.3 Power States

In real time we switch ON and off the Ethernet Device by switching ON or OFF the Operating

System number of times. So every time we switch ON the Computer Ethernet Link should come

up. So in Post Silicon Validation After designing Ethernet Controller we are trying to manually

change the Ethernet Device to ON and OFF state repetitively and in each state by running some

link reliable tests such as Iperf we can validate the robustness of the controller. We will discuss

the implementation of different power states below.

Communication devices such as Ethernet net work devices often in corporate industry

standards giving the devices the ability to be powered down to a sleep state or an off state by

the operating system of the computer.

Figure 5.12 Network Device Connected to Host Computer System Over PCI Bus

23

As shown in Figure 5.12, a communication arrangement 10 includes a host computer

system(12) and a network device(16), e.g., a Gigabit Ethernet device, that both interface with a

Peripheral Component Interconnect (PCI) bus 14. The host computer system 12 executes an

operating system 12a stored on a computer readable medium (not shown) and loaded into

resident memory (not shown) when the host computer system 12 boots up. The operating

system 12a controls functions of the host computer system 12 and could cause the host

computer system 12 or the network device 16 to enter a sleep or low power state. The host

computer system includes a main power supply 12b and an auxiliary power supply 12c. The

network device 16 includes a physical layer interface 18 that interfaces with a physical network

link 20.

Figure 5.13 Gigabit Ethernet Device with an Integral Physical Layer Interface

24

Referring to Figure 5.13, a Gigabit Ethernet device 16 inter faces with a PCI bus 14 and a

physical network link 20. The Gigabit Ethernet device 16 includes a Media Access Control (MAC)

subsystem 30 and an electrically powered physical layer interface (18). The MAC subsystem (30)

includes a PCI Bus Interface (32), a Direct Memory Access (DMA) Controller(36), and a Media

Access Controller (MAC) 38. The PCI Bus Interface 32 includes a 16-bit Power Management

Control/Status (PMCS) Register 34 which includes a two-bit Power State field (not shown) used

both to determine the current power state of the device 16 by the operating system 12a and to

permit the operating system 12a to set the device 16 to a different power management state in

accordance with the definitions provided in Table 5.3.

Bit Value

Power Management

state of Device

Definition

00 D0 Device 16 is on and running. It is receiving full power

from the host computer 12 and is delivering full

functionality to the user

11 D3 Device 16 is OFF

Table 5.3 Table showing the basic Power management states of Ethernet Device

25

Figure 5.14 Power Management State Transitions of Gigabit Ethernet Device

Referring to Figure 5.14, a power management state transition of the Gigabit Ethernet device

16 depicted in Figure 2 is shown. The Gigabit Ethernet device 16 has three power management

states, D0 Active (52), D0 Uninitialized (54) and D3 (58) and they are generally defined in Table

5.4.

Power Management

state of Device Definition

D0 Active Device 16 is on and running and is delivering

full functionality and performance to the user

D0 Uninitialized Device 16 is powering up and awaiting

initialisation by BIOS

D3 Device 16 is OFF

Table 5.4 Table Showing the Power management states of Ethernet Device

26

D0 Active (52) and D0 Uninitialized (54) are subsets of the ACPI Specification 2.0 power

management state D0. Additionally, the Gigabit Ethernet devices 16 power management state

D3 (58) includes the D3 hot state, which means that the Gigabit Ethernet device 16 can be

transitioned to the D0 Uninitialized (54) state via software by writing 00 to the devices 16

Power Management Control/Status register 34 or by having the PCI reset signal asserted. The

Gigabit Ethernet device 16 power management state D3 (58) also includes the D3 Cold power

management state, which means that the Gigabit Ethernet device 16 is transitioned to a D0

Uninitialized state (54) by re applying the main power supply, 12b and de asserting the PCI

reset signal. However, other embodiments may only support the D3 Cold power management

state or the D3 hot power management state.

The Gigabit Ethernet device 16 may transition to a different power management state as a

result of the operating system 12a or Basic Input/output System (BIOS) directing a power

management state change (60, 62, 64). For example, if the Gigabit Ethernet device 16 is up and

running in the D0 Active state (52) and the operating system 12a writes 11 to the Power State

field in the Power Management Control/Status Register (62), the device 16 transitions to state

D3(58). Similarly, if the device 16 is in power management state D3 (58) and the operating

system 12a writes 00 to the Power State field in the Power Management Control/Status

Register (62), the device 16 transitions to state D0 Uninitialized (54). The device 16 also

transitions from D0 Uninitialized (54) to the D0 Active (52) when the BIOS writes a 1 to the

memory access enable bit (64) of a PCI command register (not shown) on the PCI interface 32.

In addition to changing power management states as a result of direction from the operating

system (60, 62) or BIOS (64), the Gigabit Ethernet device 16 also automatically changes power

management states upon detecting an assertion or de assertion of the PCI reset signal (66, 68)

or an assertion of the chip reset signal (71). An assertion of a PCI reset signal (PCI RST) occurs

shortly before the host computer system 12 transitions from its main power supply 12b to its

auxiliary power supply 12c.

27

The PCI bus interface 32 is configured to monitor the PCI reset signal on the PCI bus 14. If an

assertion of the PCI reset signal (PCI RST) is detected (66), the MAC subsystem 30 automatically

reverts the device 16 to a reset power state, D Reset (56).

The device 16 remains in state D Reset (56) until the PCI interface 32 senses a de assertion of

the PCI reset signal (68), Which causes the MAC subsystem 30 to transition the device 16 to the

D0 Uninitialized state (54). The device 16 is also in the D Reset state (56) When it receives a chip

reset signal (LAN PWR GOOD assertion)(71) the first time the host computer system 12 receives

power after power down of both the main 12b and auxiliary 12c power supplies.

6. Conclusion

Harassers such as Auto Negotiation, Interrupts, Change in Power states are introduced in to the

Giga Bit Ethernet controller in Post silicon server validation for validating the Functionality of

Giga Bit Ethernet and stress the Gigabit Ethernet Controller and validated the robustness of the

controller by monitoring its behavior under prolonged stressful tests.

28

REFERENCES

[1] S. Mitra, S. A. Seshia, and N. Nicolici, \Post-silicon validation opportunities, challenges and

recent advances," in Design Automation Conference (DAC), 2010 47th ACM/IEEE. IEEE, 2010, pp.

12-17.

[2] S. M. Balabatti and R. Radha, Calculation of ecrc for tlp-packets of pcie protocol."

[3] I. Crayford, fast ether net" gets plug-and-play," in WESCON'95. Conference record.'Microelectronics Communications Technology Producing Quality Products Mobile and Portable Power Emerging Technologies'. IEEE, 1995, p. 354.[4] D. C. Chalupsky, G. V. Gritton, and T. L. Stachura, \Automatic power down," Nov. 8 2005, us

Patent 6,963,985.

[5] B. H. Leitao, Tuning 10gb network cards on linux," in Proceedings of the 2009 LinuxSymposium, 2009.