Physical layer interface for IEEE 802.11 MAC18707/FULLTEXT01.pdf · and networking recognize names...

Physical layer interface forIEEE 802.11 MAC

Examensarbete utfört i Elektroniksystem

av

Per Norén

LiTH-ISY-Ex-3241

2002-10-01

Physical layer interface forIEEE 802.11 MAC

Examensarbete utfört i Elektroniksystem vid

Linköpings Tekniska Högskola

av

Per Norén

LiTH-ISY-Ex-3241-2002

Handledare: Mikael Rudberg

Examinator: Lars Wanhammar

Linköping 2002-10-01

Avdelning, InstitutionDivision, Department

Institutionen för Systemteknik581 83 LINKÖPING

DatumDate2002-10-01

SpråkLanguage

RapporttypReport category

ISBN

Svenska/SwedishX Engelska/English

LicentiatavhandlingX Examensarbete ISRN LITH-ISY-EX-3241-2002

C-uppsatsD-uppsats Serietitel och serienummer

Title of series, numberingISSN

Övrig rapport____

URL för elektronisk versionhttp://www.ep.liu.se/exjobb/isy/2002/3241/

TitelTitle

Hårdvaruinterface för IEEE 802.11 MAC

Physical layer interface for IEEE 802.11 MAC

Författare Author

Per Norén

SammanfattningAbstractThere are several standards for wireless communication. People that are involved in computersand networking recognize names like Bluetooth, HiperLAN and IEEE 802.11. A fundamentalpart of an IEEE 802.11 node is the Medium Access Controller. It establishes and controls commu-nication with other nodes, using a physical layer unit. This is the work that was carried out as amaster thesis project at Ericsson Microelectronics. The main goal was to design, implement andevaluate a hardware interface between the MAC and the physical layer. An important part of thework was to find a suitable partition scheme for hardware and software and to achieve this, aninvestigation of processor-cycles usage was carried out to support design decisions. The hard-ware/software partition resulted in hardware-functionality for decode of received frames andautomatic transmission of acknowledge frames.

NyckelordKeyworddigital, electronics, IEEE, 802.11, WLAN, MAC, elektronik

Abstract

There are several standards for wireless communication.

People that are involved in computers and networking recog-

nize names like Bluetooth, HiperLAN and IEEE 802.11. The

last one was standardized in 1997 [2,6] and has begun to reach

acceptance as a solid ground for wireless networking.

A fundamental part of an IEEE 802.11 node is the Medium

Access Controller, or MAC. It establishes and controls commu-

nication with other nodes, using a physical layer unit (in most

cases a radio transceiver).

This is the work that was carried out as a master thesis project

at Ericsson Microelectronics, Linköping Design Center. The

main goal was to design, implement and evaluate a hardware

interface between the MAC and the physical layer. An impor-

tant part of the work was to find a suitable partition scheme for

hardware and software and to achieve this, an investigation of

processor-cycles usage was carried out to support design deci-

sions.

The hardware/software partition resulted in hardware-function-

ality for decoding of received frames and automatic transmis-

sion of acknowledge frames. It was found that this solution

fullfilled the hard timing requirements but it is also a

wellknown fact that a hardware solution is less flexible than

software.

Per Norén 2002

Ericsson Microelectronics

Per Norén 2002


Preface

This thesis concludes five years of hard work at Linköping

Institute of Technology, aiming for a master’s degree. It has

given the author the opportunity to practise the experiences col-

lected in a wide area of courses within computer engineering

and digital electronics.

I would like to take the opportunity to thank the people at Eric-

sson Microelectronics in Linköping that made it possible for

me to complete my education with this final thesis. I also want

to thank my wife Laila that has supported me during these

years at the University of Linköping.

Per Norén, Linköping 2002-10-01

Per Norén 2002


Per Norén 2002


Contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .11.1 This report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.2 Reading instructions . . . . . . . . . . . . . . 1

1.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Computer science and engineering . . . . . . . . . 2

1.5 Ericsson Microelectronics . . . . . . . . . . . . . . . . 3

1.5.1 Microsystems. . . . . . . . . . . . . . . . . . . . 3

1.5.2 Linköping Design Center. . . . . . . . . . . 3

1.6 The project . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.6.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Wireless communication . . . . . . . . . . . . . . . .52.1 Networking. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 What is a header?. . . . . . . . . . . . . . . . . 7

2.3 Standards for wireless communication . . . . . . 7

3 IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . .93.1 IEEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 Substandards . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3 Overview of WLAN. . . . . . . . . . . . . . . . . . . . 10

3.4 Distributed vs Point coordination. . . . . . . . . . 10

3.4.1 Ad hoc network . . . . . . . . . . . . . . . . . 10

3.4.2 Distributed algorithm. . . . . . . . . . . . . 11

3.4.3 Point coordination . . . . . . . . . . . . . . . 11

3.5 MAC layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.6 PHY layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 The MAC unit . . . . . . . . . . . . . . . . . . . . . . . 134.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.2 The IEEE 802.11 MAC frame. . . . . . . . . . . . . 14

4.3 MAC interfaces in IEEE 802.11 . . . . . . . . . . . 14

4.4 Time critical sections . . . . . . . . . . . . . . . . . . . 14

5 Design flow. . . . . . . . . . . . . . . . . . . . . . . . . . 175.1 Hardware-software partitioning . . . . . . . . . . . 17

5.1.1 Timing requirements. . . . . . . . . . . . . . 17

5.1.2 Estimation of clock cycle usage . . . . . 18

5.1.3 Results of clock cycle investigation . . 18

5.2 Top level design. . . . . . . . . . . . . . . . . . . . . . . . 20

5.2.1 Design decisions . . . . . . . . . . . . . . . . . 22

5.2.2 From design to implementation . . . . . 25

5.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.3.1 Example transmission of a frame . . . . 25

5.3.2 Example reception of a frame. . . . . . . 26

5.4 Processor and system bus . . . . . . . . . . . . . . . . 27

5.4.1 ARM 7 . . . . . . . . . . . . . . . . . . . . . . . . 27

5.4.2 Bus architecture . . . . . . . . . . . . . . . . . 28

6 Implementation . . . . . . . . . . . . . . . . . . . . . . 316.1 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.1.1 Renoir . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.1.2 VHDL . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.2 Verification with ModelSim . . . . . . . . . . . . . . 33

6.2.1 ModelSim . . . . . . . . . . . . . . . . . . . . . . 34

7 Evaluation and results . . . . . . . . . . . . . . . . 377.1 Technical results . . . . . . . . . . . . . . . . . . . . . . . 37

7.2 Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7.2.1 Design for reuse or tailor made blocks?38

7.2.2 Planning problems . . . . . . . . . . . . . . . 38

7.3 Future development. . . . . . . . . . . . . . . . . . . . . 38

7.3.1 Development. . . . . . . . . . . . . . . . . . . . 38

Per Norén 2002


7.3.2 Error correction. . . . . . . . . . . . . . . . . . 39

7.4 Outcome of time plan . . . . . . . . . . . . . . . . . . . 39

7.4.1 The first four weeks . . . . . . . . . . . . . . 40

7.4.2 Week 5 to 17. . . . . . . . . . . . . . . . . . . . 40

7.4.3 The last three to five weeks . . . . . . . . 40

7.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Appendix A: Abbreviations . . . . . . . . . . . . .A-1

Appendix B: Design specification . . . . . . . .B-1B.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1

B.2 Readers guidelines . . . . . . . . . . . . . . . . . . . . B-1

B.3 Design decisions. . . . . . . . . . . . . . . . . . . . . . B-2

B.4 HWIF top level design . . . . . . . . . . . . . . . . . B-4

B.5 Block Control . . . . . . . . . . . . . . . . . . . . . . . . B-6

B.6 Block amba_data . . . . . . . . . . . . . . . . . . . . B-23

B.7 Block buffer_out. . . . . . . . . . . . . . . . . . . . . B-25

B.8 Block crc_unit . . . . . . . . . . . . . . . . . . . . . . B-26

B.9 Block buffer_tx. . . . . . . . . . . . . . . . . . . . . . B-27

B.10 Block buffer_rx . . . . . . . . . . . . . . . . . . . . B-28

B.11 Block buffer_in. . . . . . . . . . . . . . . . . . . . . B-29

B.12 Component blocks . . . . . . . . . . . . . . . . . . B-30

Appendix C: Block diagrams. . . . . . . . . . . .C-1

Appendix D: Copyright . . . . . . . . . . . . . . . .D-1D.1 På svenska . . . . . . . . . . . . . . . . . . . . . . . . . . D-1

D.2 In English . . . . . . . . . . . . . . . . . . . . . . . . . . . D-2

Per Norén 2002


Per Norén 2002


This report

1 Introduction

This chapter gives some background and the circumstances for

this final thesis.

1.1 This report

1.1.1 Overview

Chapter 2, 3 and 4 is intended to give a basic understanding of

the the subject of the report. Chapter 5 describes how the prob-

lem was faced and what design decisions that was taken, as

well as a short description of the data flow in the different

blocks. How implementation was made can be read about in

Chapter 6. Design, implementation and the project planning is

evaluated in Chapter 7. A detailed technical description is

given in appendices B and C, however it should be noted that

some basic knowledge about the IEEE 802.11 standard is

needed to understand everything in appendix B.

1.1.2 Reading instructions

• For a brief overview of this thesis work, read Chapters 1, 5,

6 and 7.

• If you want more detailed information, but without going

into detailed design and hardware description, Chapter 1 to 5

should be appropriate.

• Detailed knowledge about design and implementation can

be extracted from Chapter 5, 6 and appendix B. Appendix B is

a design specification with descriptions on signal and register

level.

1.2 Background

There are several standards for wireless communication.

People that are involved in computers and networking recog-

nize names like Bluetooth, HiperLAN and IEEE 802.11. The

Per Norén 2002

Ericsson Microelectronics Page 1

Introduction

last one was standardized in 1997 [2,6] and has gained wide-

spread acceptance as a solid ground for wireless networking.

A fundamental part of an IEEE 802.11 node is the Medium

Access Controller, (denoted MAC in this report). It establishes

and controls communication with other nodes, using a physical

layer unit (in most cases a radio transceiver). At first this thesis

work was initated to investigate how a possible MAC architec-

ture would look like. The first discussions indicated that the

complexity and work effort would exceed the scope of a thesis

work and the task was decided to be: “to develop a low level

interface for the MAC”. Read more in 1.3.

1.3 Purpose

The main goal of this master’s degree project was to design,

implement and evaluate a hardware interface between the IEEE

802.11 MAC and the physical layer (see Chapter 4). An impor-

tant part of the work was to find a suitable partition scheme for

hardware and software. The result was to be used in a concur-

rent ongoing project at Ericsson to determine how complex

such an interface could be, as a basis for design decisions in

that project.

1.4 Computer science and engineering

The thesis work concludes 4.5 years of studies (180 credits) on

a master degree study programme. This one has been carried

out on the programme for Computer Science and engineering

at Linköping Institute of Technology (LiTH) and with Electron-

ics as profile of specialization. The programme was established

20 years ago, in a cooperation between university and industry.

One of its pioneering features was the combining of studies in

hardware and software into an integrated entity. Considerable

time is devoted to mathematics, an essential foundation for the

applied computer courses. Emphasis is also placed on the way

computers are used.

Per Norén 2002

Page 2 Ericsson Microelectronics


1.5 Ericsson Microelectronics

Ericsson Microelectronics is a company with global operations

in microelectronic solutions and products. It is part of the Eric-

sson group and it has its headquarters in Stockholm, Sweden.

The organization designs, manufactures and markets products

for applications such as mobile phones, base stations and other

products for the communications industry. Its technologies sup-

port mobile and Internet applications and include components

and modules for wireless applications.

1.5.1 Microsystems

Microsystems is a so called business line within Microelectron-

ics that develops and provides highly integrated microelec-

tronic systems solutions. Targeted application areas are

Complete Bluetooth Solutions, Mobile Devices, Broadband

Access and Packet Switching.

1.5.2 Linköping Design Center

The design centers in Kista, Linköping, Oslo (Norway), Swin-

don (UK) and Dallas (USA) i part of the organization

Global R&D within Microsystems, developing Microelectron-

ics solutions for Wireless and Broadband Communication.

Linköping Design Center is a combined unit for research and

development of processor based integrated circuits and

advanced mixed signal circuits. It is also a cooperation between

Global R&D and MERC (Microelectronics Research Center).

1.6 The project

The thesis was initiated in cooperation with a WLAN project

aiming at developing complete solutions for the IEEE 802.11

standard. At first the plan was to develop a MAC (see Chapter

4) with some basic functionality in parallell with another thesis,

but due to the high grade of complexity in a MAC this turned to

develop an interface between the MAC and the physical layer

Per Norén 2002


Introduction

(baseband processing, radio). The WLAN project in total cov-

ered all layers from physical up to network processing.

1.6.1 Planning

Initally, a time plan was developed as follows:

• The first four weeks consisted of a prestudy and definition

phase. Main activities was to read background theory (IEEE

802.11 standard, see [2]) and to produce a block diagram for

the interface.

• Week 5 to 17 was the design and implementation phase, that

was divided into a number of smaller activities; Report writing

in parallell with design, VHDL implementation and simulation

of every subblock. An investigation of how many clockcycles

certain operations “consumed” was to be carried out to.

• The last three to five weeks (depending on amount of work-

ing hours in total) was devoted to error correction on top level

and finishing of the report.

The time plan is evaluated in 7.4.

Per Norén 2002


Networking

2 Wireless communication

What is a computer network? In the early days of computers it

was a set of lines that connected dumb terminals to a central

computer. Today we see it as a general network, capable of

transferring all kinds of data from one computer to another. We

want it to be transparent for the application, i.e., the user will

not know if his data is transported over a wireless or a wired

network.

2.1 Networking

A classic definition is that a networks consists of a set of nodes

connected by links, but the complexity has grown very large in

modern computer systems. The theory for computer network-

ing is a fundament for all kind of networks. This theory regards

topological views as well as coding techniques for transmission

of bit streams and different types of switching techniques. One

distinction that is of special interest in this report is that of

wired vs wireless networks. In a wired network the links are

made of cables while in wireless network the links are radio

signals in the air.

2.2 OSI

The International Standards Organization (ISO) has defined an

architecture called the Open Systems Interconnection, com-

monly known as the OSI reference model (see Figure 2.1). Ref-

erence model is a good description though it is not a protocol

graph but a model to build one. It consists of seven protocol

layers with the application layer on top and the physical layer

on the bottom. The IEEE 802.11 standard, which is in focus in

this report, is situated in the physical layer and the data link

layer that is on top of physical. OSI can be compared with the

Internet (or TCP/IP) architecture which only has four layers

and would put 802.11 in the first one, Network. (Source: [7])

Per Norén 2002


Wireless communication

When data, e.g. an e-mail from an e-mail client in the applica-

tion layer, is transmitted it is first passed down through the pro-

tocol levels at the transmitter. This means that every protocol

adds its own header (see explanation of header below) to it . On

the network level, a piece of data is called a packet and this is

the unit of data that is handed to IEEE 802.11 (if this is the pro-

Figure 2.1: The OSI reference model

Physical

Data link

Network

Transport

Session

Presentation

Application

Transmitting host Receiving host

Physical

Data link

Network

Physical

Data link

Network

Transport

Session

Presentation

Application

A node in the network,

e.g. a router

Data on its way

through the

network

Per Norén 2002


Standards for wireless communication

tocol to be used). The packet is fragmented to smaller pieces

and sent as frames, i.e. a stream of bits or bytes with the IEEE

802.11 header in front of it. At the receiver, the procedure is

reversed and the email can be read as text.

2.2.1 What is a header?

It is information that the protocol needs to handle the packet or

frame. It contains fields like addresses, sequence numbers and

frame type. The receiver makes decisions depending on what

information it gets when it decodes the header of a frame.

2.3 Standards for wireless communication

This category can include mobile telephones as well as walkie

talkies, but when we talk about wireless communication we

usually mean short range networks that can be used for trans-

missions between for instance a computer and some other unit.

Bluetooth, HiperLAN and IEEE 802.11 is some of the most

wellknown of these standards. As 802.11 is in focus in this

report, Chapter 3 will give an overview of such networks.

Per Norén 2002


Wireless communication

Per Norén 2002


IEEE

3 IEEE 802.11

Even if WLAN is an acronym for any general Wireless Local

Area Network, it has become a commonly used name for the

wireless standard IEEE 802.11, so when we talk about WLAN

in this text it shall be interpreted as this standard.

3.1 IEEE

The IEEE is a non-profit, technical professional association of

more than 375,000 individual members in 150 countries. The

full name is the Institute of Electrical and Electronics Engi-

neers, Inc., although the organization is most popularly known

and referred to as IEEE. Through its members, the IEEE is a

leading authority in technical areas ranging from computer

engineering, biomedical technology and telecommunications,

to electric power, aerospace and consumer electronics, among

others. Through its technical publishing, conferences and con-

sensus based standards activities, the IEEE produces 30 percent

of the world’s published literature in electrical engineering,

computers and control technology, holds annually more than

300 major conferences and has more than 800 active standards

with 700 under development (2002). For more information,

look at the website at [5].

3.2 Substandards

Within the IEEE standards collection, there is a special branch

with focus on networking. It is known as the IEEE 802 LAN/

MAN Standards Committee and it develops Local Area Net-

work standards and Metropolitan Area Network standards. The

most widely used standards are for the Ethernet family, Token

Ring, Wireless LAN (802.11), Bridging and Virtual Bridged

LANs. An individual Working Group provides the focus for

each area. A standard that is part of IEEE 802 is named by add-

ing .x, were x is the number of the substandard, e.g. IEEE

802.11. This particular example (802.11) is the standard that is

Per Norén 2002


IEEE 802.11

in focus in the thesis work that is covered by this report. Info

about the standard is available on www [6].

3.3 Overview of WLAN

The basic IEEE 802.11 standard from 1999 [2] described a

common MAC functionality (see Chapter 4 for information

about MAC) and 3 different physical layers; one called Fre-

quency Hopping Spread Spectrum, another called Direct

Sequence Spread Spectrum (both for radio) and one for trans-

mission with infrared light. In 1999 some supplements were

added that described two more standards for physical layers,

one in the 5 GHz band [3] called 802.11a and one in the 2.4

GHz band [4] called 802.11b. There are also several extensions

under development such as Spectrum and Transmit power man-

agement in the 5 GHz band (11h), MAC enhancements for

Quality of Service (11e), Further Higher-Speed Physical Layer

Extension in the 2.4 GHz Band (11g) and Specification for

Enhanced Security (11i). The alphabet will probably be used in

years to come.

3.4 Distributed vs Point coordination

A WLAN network according to IEEE 802.11 can be formed in

some different ways.

3.4.1 Ad hoc network

Indepent nodes (denoted STA:s in the standard) can connect to

eachother using an authentication protocol. Such a network is

called an ad hoc network and access to the medium is con-

trolled with a distributed algorithm. In the standard this is

denoted an IBSS (independent basic service set). Any collec-

tion of nodes that communicates is called a BSS (basic service

set) and this is the basic building block of an 802.11 network.

Per Norén 2002


MAC layer

3.4.2 Distributed algorithm

When a distributed algoritm is used, access to medium is

achieved by sending a control frame called “Request To Send”

or RTS. When the intended receiver answers with “Clear To

Send” (CTS) data can be transmitted.

3.4.3 Point coordination

An alternative to the IBSS is to add an AP (access point). An

AP running a point coordination function can introduce cen-

tralized control over communication aswell as connection to

another, non-802.11 network, e.g. ethernet. Two AP:s and an

interconnection, e,g, ethernet, is called a DS (distribution sys-

tem). A DS can connect several BSS:s. A STA can associate to

an AP and then communicate with the DS aswell as other

STA:s under the control of the AP.

3.5 MAC layer

MAC functionality (see Chapter 4) is very similar for all

802.11 versions. The purpose of the MAC layer is to handle the

distributed and centralized protocols that controls access to the

medium aswell as giving parameters for transmissions to the

physical layer. It can do fragmenting of large messages and

also implements flow control by using acknowledges. A secu-

rity protocol named WEP is optional to use. WEP stands for

Wired Equivalent Privacy and the purpose is to enforce at least

the same security as e.g. a network cable offers. MAC is

described more detailed in Chapter 4.

3.6 PHY layer

Equipment on the market today is dominated by 802.11b that

has a maximum rate of 11 Mbps. Development on 802.11a that

offers up to 54 Mbps goes on, and system requirements in this

thesis work is adapted to this rate.

Per Norén 2002


IEEE 802.11

Per Norén 2002


Overview

4 The MAC unit

This chapter is intended to give an introduction to the MAC

that is necessary to understand the following chapters, espe-

cially those about design and implementation.

4.1 Overview

MAC is an abbreviation for Medium Access Controller. Using

networking terminology it implements the first protocol layer

above the physical, and would be situated in the data link layer

of the OSI reference model (The OSI model is described in

2.2). The datalink layer generally consists of two sublayers.

The upper which is called LLC (Logical Link Control) and the

lower MAC layer. The medium access control sublayer is

responsible for carrying out all the operations concerned with

the transmission and reception of frames to and from the physi-

cal layer.

A frame is a consecutive sequence of bits that is transmitted to

the receiving protocol at the same level (see Figure 2.1 in chap-

ter 2) as the sending protocol (or peer) although this may

include passing it to some lower lever protocols in the general

case.

An example: A network protocol (e.g. IP via LLC) uses the

802.11 MAC protocol for exchange of data. The MAC adds its

own header (information needed to handle the transmission) to

the chunk of data. If a large chunk is to be sent it is possible

that the MAC divides it into smaller pieces. This is called frag-

menting, and every fragment get its own header. The data and

the header (a frame!) is handed down to the physical layer

which adds its own header and sends it over the air. The reverse

procedure is undertaken at the receiver, and its MAC layer can

deliver the data to the network layer. IEEE 802.11, as well as

many other protocols, sends an acknowledge (ack) frame back

to the sender to confirm the transmission, a technique called

“positive acknowledge”. If the sender does not get the ack. it

Per Norén 2002


The MAC unit

retransmits the frame, and this is one of the components that

implements flow control.

A MAC is however a quite complicated unit, and the example

above only includes the most basic functions. In most standards

there are many control functions cooperating to implement the

MAC protocol and to control the physical layer.

4.2 The IEEE 802.11 MAC frame

A MAC frame consists of a header, a frame body and an FCS

field (frame check sequense, i.e. a checksum). The header and

frame body may vary in size and function, but for a normal data

frame the header is 24 bytes and the frame body, that contains

the data from higher level protocols, can be from 0 up to 2312

bytes. The FCS field is 4 bytes. The header has information

about e.g. frame type, addresses and sequense numbers.

Frames can be of type Data, Control (e.g. acknowledge) or

Management where the frame body carries management

parameters instead of data.

4.3 MAC interfaces in IEEE 802.11

A protocol layer has to interface both higher and lower level

protocols. The 802.11 standard defines one data interface and

one management interface in in each direction. The manage-

ment interface is used to transfer parameters and settings and

the data interface has signals to control input and output of

data. The data interface also contains the physical carrier sense

mechanism that indicates whether the medium is busy or not

(the term “physical” is used because of the existance of a “vir-

tual” carrier sense that is based on timers).

4.4 Time critical sections

Some substandards of 802.11 supports rates up to 54 Mbps. To

take advantage of these high rates, time constraints between

frames are hard. After the reception of the last byte in the

Per Norén 2002


Time critical sections

incoming frame the MAC only have a few microseconds before

it must have started the transmission of the acknowledge, and

this includes to make the decision whether to answer or not due

to address decoding, checksum calculating and similar opera-

tions. This leads to another discussion (read more in 5.1)

regarding what to implement in software (more flexible) or to

put in hardware (faster).

Per Norén 2002


The MAC unit

Per Norén 2002


Hardware-software partitioning

5 Design flow

The design of the hardware interface (denoted HWIF in this

report) was divided in some different activities. The partition-

ing between hardware and software as well as the writing of the

design specification were two important ones that created a

foundation for the construction of HWIF. The hardware also

had to be adapted to the ARM 7 processor that was chosen as

platform for MAC software as well as the AMBA AHB bus

system.

This chapter contains an overview of the design and the design

decisions that was taken. Appendix B: Design specification is a

detailed description of all subblocks.

5.1 Hardware-software partitioning

There is no unique solution for how to design a unit like a

MAC. Different partitions can be made regarding what to

implement in software or to develop in hardware. To make

good decisions in this matter, one must have a good under-

standing of the required functionality. To get this understand-

ing, a thorough study of the IEEE 802.11 standard was carried

out during the prestudy phase (see 1.6.1). This was very time

consuming but gave a good view of what was the most time-

critic mechanisms in the system and helped to form a feasible

top level design.

5.1.1 Timing requirements

To support rates up to 54 Mbps, some hard time constraints

between frames must be applied. After the reception of the last

byte in the incoming frame the MAC only have a few microsec-

onds before it must have started the transmission of the

acknowledge, and this includes to make the decision whether to

answer or not due to address decoding, checksum calculating

and similar operations.

Per Norén 2002


Design flow

5.1.2 Estimation of clock cycle usage

During the first attempts to create a top level design, a need was

discovered for knowledge of how many clock cycles certain

operations would use. Two weeks of work was devoted to get

this knowledge. One part of the estimation work was to exam-

ine operations on low level to figure out how the ARM 7 pro-

cessor would execute them, and how transfers would be

handled on the bus (read more about this in 5.4). Another part

was to investigate how those low level operations would be

combined. To do this a C program was developed that could

take different configurations (e.g. header decoding in SW and

CRC calculations in HW) as input and give some different tim-

ing aspects as result. These results could then be used to sup-

port design decisions regarding HW/SW partitioning.

5.1.3 Results of clock cycle investigation

The C program mentioned in 5.1.2 was developed so that a

number of parameters could be input to it, such as clock fre-

quency, data rate and different types of delay. To get useful

results, 80 MHz and 54 Mbps was chosen as this was the fre-

quency that was to be used in the system according to Ericsson

engineers and the highest bitrate used by the standard (worst

case). Typical delays aswell as worst case delays were given as

input.

The most time critic operations occur when a reply frame is to

be sent due to an incoming message. Possible replies can be:

• Acknowledge frame, if the incoming frame is of a type that

requires this (more on acknowledge in Chapter 4)

• CTS (Clear To Send), if incoming is an RTS (Request To

Send) frame. RTS and CTS are explained in 3.4.2.

• Data frame. This can occur during CFP (Contention Free

Period), i.e. when a centralized coordination function has

control over the medium (this is explained in 3.4.3). If a

Per Norén 2002


Hardware-software partitioning

polling message (asks if I want to transmit anything) arrives

during that period, the station is allowed to send 1 frame.

In all of these reply situations a time period called SIFS is to be

used. It is measured from the end of the last symbol of the

incoming frame ON THE MEDIUM (the air) to the beginning

of the first symbol of the reply frame. This includes delays in

the physical layer (the radio part). The part of this time that is

used in the MAC is called “MacProcessingDelay”, and it is in

the order of a few microseconds. SIFS is defined by IEEE

802.11, but MacProcessingDelay depends on how the different

delays is distributed in the system. Ericsson engineers estimate

that the upper limit for MacProcessingDelay is somewhere

between 2 and 3 microseconds. The program that was devel-

oped for this investigation gives as output an estimated value

for MacProcessingDelay to support design decisions.

A number of different configurations could be chosen, but the

parameters that gave most impact on the result was the follow-

ing:

• CRC calculation in hardware or software. CRC means

Cyclic Redundancy Check and is a method to check if the

frame is damaged

• Decoding of frame headers in hardware or software (more

on headers in 2.2.1).

• Reply functionality in hardware or software. This regards

the reply situations described above.

If reply funcionality is put in hardware it requires decoding and

CRC calculation to be there to. Decoding in hardware is useless

if reply is in software.

The most important results are presented in Table 5.1.

Per Norén 2002


Design flow

SW is software, HW is hardware, s is microseconds

The average value is calculated from a number of simulations with dif-

ferent delays applied.

Conclusions that can be drawn from these results is that CRC-

calculation must be in hardware, but further decisions is not so

obvious. Design decisions are discussed in 5.2.1.

5.2 Top level design

HWIF was intended to be a peripheral on the processor bus as

shown in Figure 5.1 (where HWIF is denoted “Data interface

block”). Control from CPU could then be applied by writing to

registers and status could be read from registers. Interrupts

should be possible to trigger from HWIF via an interrupt

request signal.

Table 5.1: Results from clock cycle estimation

ConfigurationLowest

valueHighest

Average

value

MacProcessingDelay

CRC calculation,

decode and reply all

in SW

6.2 s 495(!) s 117 s

CRC calculation in

HW, decode and

reply in SW

0.3 s 2.2 s 1.27 s

CRC calculation,

decode and reply all

in HW

0.3 s 1.2 s 0.49 s

µ µ µ

µ µ µ

µ µ µ

µ

Per Norén 2002


Top level design

Figure 5.1: Block diagram for MAC

Per Norén 2002


Design flow

5.2.1 Design decisions

The requirements that gave most impact on the design was the

following:

• Data and control interfaces to the AMBA AHB bus (see

5.4) should be present. The reason for this choice was that

the component was intended to be integrated in a processor-

system with an ARM 7 microprocessor (see 5.4.1) as con-

trolling unit and with an AMBA AHB bus as a system bus.

• There had to be an interface according to IEEE 802.11 to the

physical layer. This needs no further motivation though the

component itself was to be an interface to the physical layer.

• Some amount of buffer capacity was needed. Motivation: It

was clear from the start that an incoming or outgoing frame

could not be synchronized with the bus and memory system

because of the complexity of software execution.

• The interface had to contain registers for status, settings and

parameter vectors for the physical layer. This was motivated

by the fact that the controlling units in the interface was to

take some actions autonomously and then needed some sta-

tus to make decicions on. The parameter vectors are

described in the standard [2] and it seemed like a good deci-

sion to include them in this unit to make them accessable on

the system bus.

• Assumptions was made (after discussions with experienced

HW designers) that CRC calculations most probably should

be implemented in HW. The investigation in 5.1.2 and the

results in Table 5.1 ": Results from clock cycle estimation"

confirmed this assumptions, so a block for CRC calculation

was included.

• Some timers and counters according to the IEEE 802.11

standard [2] was to be integrated in the interface block

because of the tight relationship between these timers and

timing of transmissions, and in the case of putting decode

and reply in hardware (see below) this would be necessary.

Implementing them in software would decrease accuracy to

much.

Per Norén 2002


Top level design

To decide where to put decoding and reply functionality

(acknowledge and similar) was a harder decision to take and

this was the main problem in the hardware/software partition-

ing. As described in 5.1.3, the maximum value for MacProcess-

ingDelay was 2 to 3 microseconds. Table 5.1 indicates that the

configuration with CRC calculation in HW and Decode/Reply

in SW could work if the max value was 3 microseconds but not

if it was 2 microseconds. This gave the decision to implement

all this funcionality in hardware but with the possibility to turn

it off by setting different values in registers (this gives another

justification to design for such registers).

All these things helped to form a top level design for HWIF as

in Figure 5.2.

Per Norén 2002


Design flow

Figure 5.2: Top level diagram for HWIF

Per Norén 2002


Examples

A detailed description of the subblocks in Figure 5.2 is avail-

able in Appendix B: Design specification.

5.2.2 From design to implementation

It is not always so easy to identify the structure of a hierarchi-

cal design before the construction work has begun. The level of

difficulty depends on the complexity of the possible subblocks.

In Figure 5.2 there are 4 buffer blocks that are quite straight

forward to design but there is also a control block which is

more complex. The following design strategies where adopted:

• For the buffer blocks and the CRC block some components

such as FIFO buffers (First In - First Out) and multiplexers

where constructed to be reused. The blocks then where

assembled with these “basic blocks” and some “glue code”.

This is known as the “meet-in-the-middle” design method-

ology, a combination of top-down and bottom-up design.

• The control block where developed using a strict topdown

strategy.

Read more about the details in Chapter 6 “Implementation”.

5.3 Examples

To get a better view of how the interface works some examples

of transmission and reception is given. The descriptions corre-

sponds to the block names in the diagram in Figure 5.2, and is

only an overview of the data and control flow though all details

should take a number of pages to describe.

5.3.1 Example transmission of a frame

1. HWIF is in idle state.

2. CPU writes a request to transmit via the AMBA system-bus

to the block “Control” and starts to send a frame to

“Buffer_Out”, also via the AMBA bus.

Per Norén 2002


Design flow

3. “Control” sets “Buffer_Out”, “CRC_unit” and “Buffer_Tx”

in state to be ready for transmission of a new frame using

the control signals.

4. The first bytes of data is transferred to “Buffer_Out” from

memory (this is handled by CPU and later DMA controller)

via the AMBA system bus.

5. “CRC_unit” reads the first byte from “Buffer_Out”.

6. “CRC_unit” processes the data byte, and outputs it to

“Buffer_Tx” that reads the the bytes to its local buffer.

7. Step 4 through 6 is repeated as long the buffer in

“Buffer_Tx” is not full and end of the frame has not been

reached..

8. “Control” indicates start of transmission on the interface

“PHY SAP” to the physical layer and sets “Buffer_Tx” in

state to output the first byte.

9. Each byte is transferred from “Buffer_Tx” to the physical

layer using signals for synchronization, this happens con-

currently with step 4 through 6.

10.When the entire frame is sent, this is indicated from CPU

with a request to end transmission after the last transfer from

memory. This request will also be generated on the interface

“PHY SAP” when the last byte has passed “Buffer_Tx”.

11.“Control” generates an IRQ (interrupt request) to CPU

which causes CPU to read the status of the transmission in

status registers in “Control” via the AMBA bus.

5.3.2 Example reception of a frame

1. HWIF is in idle state.

2. The physical layer writes a request to receive via the inter-

face “PHY SAP” to the block “Control”.

3. “Control” sets “Buffer_Out”, “CRC_unit” and “Buffer_Tx”

in state to be ready for reception of a new frame using the

control signals.

4. “Control” indicates start of reception to the CPU by generat-

ing an IRQ. This causes CPU (and DMA controller) to start

reading data bytes from “Buffer_In” over the AMBA bus (at

Per Norén 2002


Processor and system bus

this time there is no data available to read, but this is han-

dled by the AMBA protocol).

5. The first byte of data is transferred to “Buffer_Rx” from the

physical layer.

6. “CRC_unit” reads the first byte from “Buffer_Rx”.

7. “CRC_unit” processes the data byte, and outputs it to

“Buffer_In” that reads the the bytes to its local buffer.

8. Step 4 through 6 is repeated as long as end of the frame has

not been received. Each byte is also decoded by a decoding

block in “Control”. If it decides that e.g. an acknowledge-

frame is to be sent in reply, that frame is generated an placed

in “Buffer_Out”.

9. Each byte is transferred from “Buffer_In” to the memory

using the protocol for the AMBA AHB bus (see 5.4.2), this

happens concurrently with step 5 through 7.

10.If the decoding functions has generated a reply frame AND

the CRC calculation of the received frame indicates that it is

undamaged, the reply frame is transmitted using steps 5

through 10 in the transmission example.

11.When the entire received is sent, this is indicated from the

physical layer with a request on the interface “PHY SAP” to

end transmission. “Control” then sends IRQ (interrupt

request) to CPU which causes it to read the status registers

in “Control”.

5.4 Processor and system bus

We have earlier talked about the ARM 7 microprocessor and

the AMBA AHB system bus. Here is some information about

those architectures.

5.4.1 ARM 7

The ARM7 is a low power, general purpose 32 bit RISC micro-

processor macrocell for use in application-specific integrated

circuts (ASICs). Its simple and fully static design is particularly

suitable for cost and power-sensitive applications. The ARM7 s

Per Norén 2002


Design flow

small die size makes it ideal for integrating into a larger custom

chip that could also contain RAM, ROM, logic, DSP and other

cells. There is an extensive model called ARM7TDMI that has

a three-stage instruction pipeline and both 16 (for high code

density) and 32 (for high performance) bits instruction sets.

This is the one that was intended to be used in Ericssons

WLAN project and consequently the one that HWIF is prima-

rily designed for.

5.4.2 Bus architecture

The AMBA AHB system bus is a flexible architecture that is

intended to be a backbone bus for connection of processors, on

chip memories and other peripherals such as the hardware

interface that is the issue in this report. A unit connected to the

bus is either an AHB master or a slave. Some units can have

both master and slave interfaces, e.g. DMA controllers. Initia-

tion of transfer is always made by a master.

The AHB protocol can have transfer sizes (width of bus) up to

1024 bits, but typical sizes are 8, 16 and 32 bits. If the bus is

designed for 32 bits then it is also possible to transfer 8 or 16

bits by setting a size value. Transfers are controlled by a num-

ber of control signals that sets the conditions for address and

data cycles.

Address and control cycles are pipelined to make it possible to

execute one transfer every cycle. This means that the data cycle

is the same as the address and control cycle for the next trans-

fer as shown in Figure 5.3. More information about the AMBA

architecture can be retrieved from

www.arm.com

Per Norén 2002


Processor and system bus

Figure 5.3: Pipelined transfers on AMBA AHB

Control (n) Control (n+1)

Address (n)

Data (n)

Address (n+1)

Data (n-1)

Per Norén 2002


Design flow

Per Norén 2002


Tools

6 Implementation

In 5.2.2 we stated that the following design strategies were

used.

• For the buffer blocks some components such as FIFO buff-

ers and multiplexers where constructed to be reused. The

blocks then were assembled with these “basic blocks” and

some “glue code”. This is known as the “meet-in-the-mid-

dle” design methodology, a combination of top-down and

bottom-up design.

• The control block where developed using a strict top-down

strategy.

In this chapter we will discuss the details in the hardware

design for this project.

6.1 Tools

A hardware designer must have access to various tools to be

efficient in his work. For the implementation of this hardware

interface Renoir and the graphical simulation environment

Modelsim was the most important. Those two are described

below. The text editor Emacs was used for writing VHDL code

and Framemaker was used for documents.

6.1.1 Renoir

Renoir from Mentor Graphics is a design tool for hierarchical

digital design. The top level can be represented by a block dia-

gram (se Figure 6.1) and every block can be described using

some different methods where the most common are:

• Block diagram (adds another level of abstraction)

• State machine

• Truth table

• Verilog/VHDL code

For HWIF block diagrams and VHDL code was used.

Per Norén 2002


Implementation

6.1.2 VHDL

An efficient way to describe the function of a digital compo-

nent is to use a hardware description language. Wellknown

ones are Verilog and VHDL and the last one is used in this

project.

VHDL is an abbreviation for Very high speed integrated circuit

Hardware Description Language (VHSIC HDL). The develop-

ment of VHDL started 1983 under sponsorship from the US

Department of Defence and it was released as IEEE standard

1076 in 1987. An updated standard was released in 1993 and

since then it has become a defacto industry standard for hard-

ware description languages. (Source [1])

Figure 6.1: Example block diagram

Per Norén 2002


Verification with ModelSim

To describe digital circuits in VHDL is very similar to software

development but there is some major differences; It can model

concurrent behaviour and it is possible to add delay to actions.

VHDL has an ADA look-a-like syntax with statements like if

and case. A combinatorial NAND-gate can be modeled as fol-

lows:

-- Port declaration of in- and outsignals

A, B : in

C : out

-- A logical expression

C <= not (A and B);

If you want to describe a sequential logic there is a construct

named “process”:

-- a simple flipflop

flipflop : process (CLK)

begin

if (CLK’event and CLK = 1) then

Q <= D

end if;

end

end process flipflop;

(The if-condition is true on positive edge of the clock)

6.2 Verification with ModelSim

To ensure that every subblock aswell as the top level design

gives the correct response to its input, a simulation tool was

used to verify the functionality of HWIF.

Per Norén 2002


Implementation

6.2.1 ModelSim

ModelSim from ModelTech is a graphical simulation environ-

ment. It is quite easy to use but powerful and it has several fea-

tures:

• Waveform window were selected signals can be watched

(example in Figure 6.2)

• Source code window with possibility to add breakpoints and

step through execution

• Possibility to create input stimuli from macro files.

If not used with Renoir or a command line compiler, a compiler

can be called upon from within the ModelSim environment.

It should be noted that a complete verification of a component

like this hardware interface can include applying a synthesis-

Figure 6.2: Waveform in ModelSim

Per Norén 2002


Verification with ModelSim

tool and thourough testing in a programmable circuit like a

FPGA (field programmable array).

Per Norén 2002


Implementation

Per Norén 2002


Technical results

7 Evaluation and results

A very important part of a project, yet often forgotten, is to

evaluate the result. To analyze what should have been done dif-

ferent is very important to avoid mistakes in future projects, but

one must not forget to give positive feedback when appropriate.

7.1 Technical results

The goal of this project was to design a digital component with

a certain functionality and to implement that functionality

using a hardware description language. Because of this it is not

obvious how to discuss results in terms of performance. Perfor-

mance such as maximum clock frequency or number of gates

can be examined when testing a physical circuit or maybe

using technology specifications.

The result in this work is more of the kind that the functionality

is realised or not, and after many hours of simulating and not so

many hours of error correction, the basic functionality has been

found to work correct. If a simulated frame of type that

demands a reply was created in the simulator and input to the

interface, the correct reply frame was detected as output. The

simulated received frame was also detected on the system bus

which is a correct behaviour, and in a complete system the

frame would have been written to memory via the system bus.

It was found during the activities discussed above that all con-

trol functionality and data paths work correctly when applying

these standard testcases. It should be noted that the complexity

of the component gives hundreds of testcases to simulate, but

the fact that the basic structures works for the most typical

cases indicates that the design decisions was correct.

It can be interesting to know that the implementation in VHDL

resulted in 9477 lines of code.

Per Norén 2002


Evaluation and results

7.2 Problems

A few problems has been more significant than others:

7.2.1 Design for reuse or tailor made blocks?

As mentioned in 5.2.2, some blocks where designed as compo-

nents that were to be reused in more than one place by passing

parameters to them at compile-time. This caused some extra-

work to allow e.g. various number of inputs to blocks, and the

lesson to learn from this is that reuse must not be applied in

absurdum. Some of these problems would have been avoided

with more experience of VHDL coding.

7.2.2 Planning problems

This was a two-faced problem: One could say that to little time

was assigned to VHDL coding and simulation (see discussion

on outcome of time plan in 7.4). On the other hand, there was a

fixed amount of time to use for this work (as in all projects) and

theres wasn’t any activities to omit, so it may be more appropri-

ate to say that the scope of the thesis work should have been

shrinked.

7.3 Future development

After the termination of this thesis project there was, as in

every project, some things left that one might want to adjust or

complete.

7.3.1 Development

Here we describe some future functionality that may be of

interest:

1. Load good-crc from registers: When the block that handles

CRC calculation checks if a received frame is undamaged it

compares the result of the calculation to a fixed value. This

Per Norén 2002


Outcome of time plan

value is hardcoded in VHDL and is only valid for the certain

CRC algorithm that is specified by the standard. If another

algorithm is to used it would be good to be able to load this

value from software. This feature is already partially

designed for and it is not so much work to develop to full

functionality. See details in Table B.3 and Table B.16 in

Appendix B: Design specification.

2. Preload polled frames: If a centralized control over the

medium is applied, there may be cases where an STA that

want to transmit is waiting for polling. Here it would be

good to be able preload the first words of the intended trans-

mission in the buffers of the interface and to start to transmit

when triggered by a polling frame. Development to achieve

this regards decoding a the central state machines for control

and means many hours of work.

3. Adaption to future standards: In 3.3 some extensions to the

basic IEEE 802.11 standard is described. This design only

applies to the basic standard and the extensions .a and .b. A

future development could be to investigate how the interface

can be changed to handle other extensions to the standard.

7.3.2 Error correction

As mentioned earlier, the complexity of the design gives a lot

of testcases that should be simulated to control that all func-

tionality is the intended one. This means simply that the first

thing to do as an extension of this work would be to simulate a

lot of different test cases. Especially decoding criterias should

be checked to see if they fully conform to the standard.

7.4 Outcome of time plan

In 1.6.1 the timeplan for the project was described. Here it will

be compared to reality.

Per Norén 2002



7.4.1 The first four weeks

was described as a prestudy and definition phase in the time

plan. It was completed in time and its main activities were per-

formed. A thorough study of the IEEE 802.11 standard [2] was

carried out and a top level block diagram was developed.

7.4.2 Week 5 to 17

This was the design and implementation phase. Design activi-

ties on block level proceeded according to plan and writing of

this report went on very good. The investigation of clock-

cycles was assigned 1 to 2 weeks and consumed about 3 weeks

so a delay of 1,5 weeks can be noted here. Then VHDL coding

and simulation of every subblock came up as the major error in

the time plan: When those activities were finished almost 900

hours were used, about 80 to 100 hours more than planned for

the thesis work. It was decided that a limit was to be set at

about 1000 hours which left a few weeks for error correction

on top level.

The main reason for this delay was a misjudgement of the com-

plexity of some subblocks and of how time consuming the

development in VHDL would be. This is an important lesson to

learn from when taking on similar projects.

7.4.3 The last three to five weeks

This phase was shrinked to about two weeks due to the discu-

sion in 7.4.2. Results of top level simulation and error correc-

tion is available in 7.1, see also 7.3.2.

A total of 1054 hours were used for this thesis work.

7.5 Conclusions

Some general remarks can be made regarding this design and if

it is the correct solution to the problem.

Per Norén 2002


Conclusions

• The current design handles the hard timing constraints very

well. It is modular and therefore easier to develop further. It

solves the problem as the problem was presented at start of

the project. It also allows for a less powerful CPU in the sys-

tem.

• The major drawback is that it is what it is: a hardware com-

ponent. Once it has been manufactured as a circuit it can not

be changed.

These opinions gives a very good picture of the problem: to

make a compromise between timing constraints and flexibility.

The final conclusion from the author is that development of

functionality to solve this problem should go towards more

flexible software based solution, but it is essential that software

execution is predictable as the timing constraints are so called

“hard realtime”, i.e. deadlines must be met or the system will

fail. The main problem with a software based solution is that it

may require a quite fast processor that adds more cost to a

product that uses the system. But that is more business than

engineering

Per Norén 2002



Per Norén 2002


8 References

References according to Harvard/Oxford-systems:

Name of author(s), printing year, title (complete), place of

publishing, publisher, edition, ISBN.

1. Armstrong & Gray (2000), VHDL Design and Syn-

thesis, Upper Saddle River NJ: Prentice Hall, second

edition, ISBN 0-13-021670-4.

2. IEEE (1999), ANSI/IEEE Std 802.11, Piscatawa

USA: IEEE Standards Board, 1999 Edition, ISBN 0-

7381-1658-0.

3. IEEE (1999), High-Speed Physical Layer in the 5

GHz Band, Piscatawa USA: IEEE Standards Board,

1999 Edition.

4. IEEE (1999), Higher-Speed Physical Layer Extension

in the 2.4 GHz Band, Piscatawa USA: IEEE Stan-

dards Board, 1999 Edition.

5. IEEE, Welcome to the IEEE:

http://www.ieee.org

6. IEEE, The working group for wireless LANs:

http://grouper.ieee.org/groups/802/11/

7. Peterson & Davie (2000), Computer Networks a Sys-

tems Approach, San Fransisco: Morgan Kaufmann,

second edition, ISBN 1-55860-577-0.

Per Norén 2002


References

Per Norén 2002


Appendix A: Abbreviations

AHB Advanced high-performance bus

AMBA Advanced microcontroller bus architecture

ARM Advanced risc machines

BSS Basic service set

CPU Central Processing Unit

CRC Cyclic redundancy check

DMA Direct Memory Access

DS Distribution system

HW Hardware

HWIF Hardware interface for MAC

IBSS Independent basic service set

IEEE Institute of Electrical & Electronics Engineers

MAC Medium access controller

Mbps Megabits per second

SIFS Short InterFrame Space

SW Software

Per Norén 2002

Ericsson Microelectronics Page A-1

Abbreviations

Per Norén 2002

Page A-2 Ericsson Microelectronics

Summary

Appendix B: Design specification

This design specification should be read after achieving some

basic knowledge of IEEE 802.11. It is recommended to read

the report before reading this appendix.

B.1 Summary

Some substandards of 802.11 supports rates up to 54 Mbps. To

take advantage of these high rates, time constraints between

frames are hard. After the reception of the last byte in the

incoming frame, the MAC only have a few microseconds

before it must have started the transmission of the acknowl-

edge, and this includes to make the decision whether to answer

or not due to address decoding, CRC calculating and similar

operations. This is a hardware interface between the physical

level and the software MAC. It encapsulates buffer capacity,

CRC calculating as well as decoding and reply functionality.

The interface is denoted HWIF in this document.

B.2 Readers guidelines

A design overview is given in B.3. In B.4 we describe in and

output ports to the top level, intended function of those ports

and give a brief overview of internal structure. B.5 to B.11 is

specifications of the blocks and subblocks in HWIF. “Compo-

nent blocks” are described in B.12. Those are building blocks

that are intended to be reused in more than one top level block

and most of these blocks have generic VHDL parameters to

configure them (this means that the VHDL code uses variables

that can be assigned values at compile time).

All signals are active high except those that has an “n” in the

end of their names. Ports are described on top level only. For a

complete view of the interconnections between blocks and sub-

blocks take a look at Appendix C:'Block diagrams'.

Per Norén 2002

Ericsson Microelectronics Page B-1

Design specification

AMBA specific remark:

AMBA interfaces does not support HPROT signals and only

the single transfer option of the HBURST signal.

B.3 Design decisions

The requirements that gave most impact on the design was the

following:

• Data and control interfaces to the AMBA AHB bus (see

5.4) should be present. The reason for this choice was that

the component was intended to be integrated in a processor-

system with an ARM 7 microprocessor (see 5.4.1) as con-

trolling unit and with an AMBA AHB bus as a system bus.

• There had to be an interface according to IEEE 802.11 to the

physical layer. This needs no further motivation though the

component itself was to be an interface to the physical layer.

• Some amount of buffer capacity was needed. Motivation: It

was clear from the start that an incoming or outgoing frame

could not be synchronized with the bus and memory system

because of the complexity of software execution.

• The interface had to contain registers for status, settings and

parameter vectors for the physical layer. This was motivated

by the fact that the controlling units in the interface was to

take some actions autonomously and then needed some sta-

tus to make decicions on. The parameter vectors are

described in the standard [2] and it seemed like a good deci-

sion to include them in this unit to make them accessable on

the system bus.

• Assumptions was made (after discussions with experienced

HW designers) that CRC calculations most probably should

be implemented in HW. The investigation in 5.1.2 and the

results in Table 5.1 ": Results from clock cycle estimation"

confirmed this assumptions, so a block for CRC calculation

was included.

• Some timers and counters according to the IEEE 802.11

standard [2] was to be integrated in the interface block

because of the tight relationship between these timers and

Per Norén 2002

Page B-2 Ericsson Microelectronics

Design decisions

timing of transmissions, and in the case of putting decode

and reply in hardware (see below) this would be necessary.

Implementing them in software would decrease accuracy to

much.

To decide where to put decoding and reply functionality

(acknowledge and similar) was a harder decision to take and

this was the main problem in the hardware/software partition-

ing. As described in 5.1.3, the maximum value for MacProcess-

ingDelay was 2 to 3 microseconds. Table 5.1 indicates that the

configuration with CRC calculation in HW and Decode/Reply

in SW could work if the max value was 3 but not if it was 2.

This gave the decision to implement all this funcionality in

hardware but with the possibility to turn it off by setting differ-

ent values in registers (this gives another justification to design

for such registers).

HWIF is designed assuming that decoding of an incoming sig-

nal field is done in the baseband circuits (part of the physical

layer) and copied to the RxVector on start of reception. If base-

band lacks this functionality and signal field is first in the data

stream, decoding in HWIF must be extended to handle this and

write RxVector TO baseband instead of reading it from base-

band.

Per Norén 2002



B.4 HWIF top level design

A structural view of interfaces is given in Figure B.1.

Global inputs for HWIF (connected to all blocks)

HCLK, HRESETn (asynchronous reset)

Ports for HWIF

AMBA_ctrl:

This is the control interface used by CPU to control HWIF. It is

an AMBA slave (see 5.4.2) that can be addressed to access reg-

isters in the control block (see B.5).

In:

HSEL_HWIFCTRL, HWRITE, HADDR(31:0),

HTRANS(1:0), HSIZE(2:0), HBURST(2:0),

HWDATA(31:0), HREADYin

Out:

HRDATA_HWIFCTRL(31:0), HREADY_HWIFCTRL,

HRESP_HWIFCTRL(1:0),

AMBA_data:

Figure B.1: HWIF

HWIF

AMBA_data

(AMBA slave)

AMBA_ctrl

(AMBA slave)

PHY SAP

(if to physical layer)

Per Norén 2002


HWIF top level design

This is the data interface were a DMA controller or the CPU

can read or write 8, 16 or 32 bytes of data each cycle. This is

an AMBA slave.

In:

HSEL_HWIFDATA, HWRITE, HADDR(31:0),

HTRANS(1:0), HSIZE(2:0), HBURST(2:0),


Out:

HRDATA_HWIFDATA(31:0), HREADY_HWIFDATA,

HRESP_HWIFDATA(1:0)

PHY_SAP:

This is the service interface towards the physical layer. It con-

forms to the standard IEEE 802.11 [2] with some extensions;

PHY_[RX/TX]DATA_CONF signals is added and may be

removed if suitable. TX_PARAM is intended for TX-vectors.

RX_PARAM is intended for RX-vectors and parameters asso-

ciated with PHY_CCA_indication and PHY_RXEND. PHY

SAP is described in part 12, physical layer service specifica-

tion, of the 802.11 standard [2]

In:

RX_PARAM(32:0), PHY_CCA_IND,

PHY_CCARESET_CONF, PHY_RXEND_IND,

PHY_RXSTART_IND, PHY_TXEND_CONF,

PHY_TXSTART_CONF, PHY_RXDATA(7:0),

PHY_RXDATA_IND, PHY_TXDATA_CONF

Out:

TX_PARAM(32:0), PHY_CCARESET_REQ,

PHY_TXEND_REQ, PHY_TXSTART_REQ,

PHY_RXDATA_CONF, PHY_TXDATA(7:0),

PHY_TXDATA_REQ

Detailed information about ports is available in the descriptions

of the blocks that has top level ports attached. Take a look at the

top level block diagram in appendix Appendix C:'Block dia-

grams' to get a good view of the structure.

Per Norén 2002



B.5 Block Control

Parent block: HWIF

Subblocks: controller, status_regs, amba_ctrl, decode

In:

AMBA_control:


HTRANS(1:0), HSIZE(2:0), HBURST(2:0), HPROT(3:0),


status_out(7:0), status_crc(7:0), status_tx(7:0),

status_rx(7:0), status_in(7:0)

PHY_SAP:

RX_PARAM(32:0), PHY_CCA_IND,

PHY_CCARESET_CONF, PHY_RXEND_IND,

PHY_RXSTART_IND, PHY_TXEND_CONF,

PHY_TXSTART_CONF

Out:

AMBA_control:


HRESP_HWIFCTRL(1:0)

insert_data(33:0), control_out(7:0), control_crc(7:0),

control_tx(7:0), control_rx(7:0), control_in(7:0),

IRQ_HWIF

PHY_SAP:

TX_PARAM(32:0), PHY_CCARESET_REQ,

PHY_TXEND_REQ, PHY_TXSTART_REQ

This block controls data transfers through HWIF. It has several

registers for status and parameters. A block diagram over this

block can be found in Appendix C:'Block diagrams'. Subblock

functionality is described in the following paragraphs.

Per Norén 2002


Block Control

B.5.1 Subblock status_regs

Parent block: control

Subblocks: tsf, nav

Function:

This block contains status registers used to control the trans-

fers. Table B.1 is memory map for the registers addressable by

CPU on AMBA_ctrl and Table B.2 the ones internal to HWIF.

Bits 2 to 5 of HADDR will be used to address the registers in

Table B.1 (AMBA addresses increments in steps of 4 so bits 0

and 1 is always 0).

Register overview and descriptions

Registers with “_R” in the end means read only on AMBA bus,

“_W” is write only and “_RW” both. All addresses and register

values are given in hexadecimal notation.

Table B.1: Registers externally accessable

Register Addr Info

Config_W 0x00 Configuration of this unit. Address

0x00 accessess bit 31-0, address 0x04

bit 63-32 and so on.0x04

0x08

0x0C

Cmd_RW 0x10 Command exchange with CPU

Status_R 0x14 Status register

TSF_RW 0x18 Setting/sampling TSF-timer bit 31-0

0x1C Bit 63-32

NAV_RW 0x20 Network allocation vector

Per Norén 2002



Register Config_W

Some parameters must be set to control decisions in HWIF.

Those parameters are written to this register. All 4 32-bit

TxVector_R 0x24 As in IEEE 802.11. Bit 31-0

0x28 Bit 63-32

RxVector_R 0x2C As in IEEE 802.11. Bit 31-0

0x30 Bit 63-32

BSSID_W 0x34 As in IEEE 802.11. Bit 31-0

0x38 Bit 47-32

Table B.2: Registers internally accessable

Register Addr Info

PrevCmd 0x40 Copy of previous content in Cmd_RW

RXERROR 0x44 Parameter to RxEnd_ind. (PHY SAP)

Decode 0x48 Status of latest decode

Duplicate 0x4C Cache of <address 2,seq.ctrl> fields

TSF_temp 0x50 This is used to put incoming times-

tamp before decision of update is

taken0x54

NAV_temp 0x58 Incoming value

Table B.1: Registers externally accessable

Register Addr Info

Per Norén 2002


Block Control

parts must be written in a sequence (starting with bits 31-

0), it is not possible to write to only one address.

Register Cmd_RW

Table B.3: Register Config_W

Bit Value Info

47-0 - The MAC-address of this unit

79-48 - Used good-crc value (7B DD 04 C7)

80 0x0 This unit is a STA

0x1 This unit is an AP

84-81 0x0 All functionality off, asynch. reset value

0x1 crc on

0x2 crc, decode and reply on

0x3 crc, decode, reply and NAV-update on

0x4 crc, decode, reply and TSF update on

0x5 crc, decode, reply, NAV- and TSF update on

92-85 - Clock frequency for HCLK in MHz

108-

93

Ack/CTS transmit time + SIFS

(added to duration in ack and cts)

122-

118

- rx_delay in microseconds

127-

123

- tx_delay in microseconds

Per Norén 2002



Commands from CPU is written into this register and

requests to CPU is read from it. Interrupt is used to signal a

new request to CPU and it is reset when CPU reads the

command.

The parameter part is common for both read and write.

Write is to bit 23-16+7-0 and read is from bit 23-16+15-8

Table B.4: Register Cmd_RW

Bit Value Info

7-0

(from

CPU)

0x0 Synchronous reset

0x1 TxRequest, new frame will follow

0x2 TxEnd

0x3 RxAbort, stop receiving

0x4 CCAreset_req

0x5 NAVreset (also implicitly on CCAreset_req)

0x6 TSF reset

0x7 Insert timestamp

0x8 Frame waiting to be polled

0x9 Polling will be deferred

0xA This STA is associated to an AP

0xB This STA has de-associated to an AP

15-8

(to

CPU)

0x00 TxEndOk, transmission succeded

0x01 TxEndFail, transmission failed

0x02 RxStart

Per Norén 2002


Block Control

Register Stat_R

This is a status register for HWIF. The different values of

bit 0-3 in this register corresponds to the state machine in

subblock status control. Bit 6 is copied from

RX_PARAM(0) on CCA indication.

0x03 RxEndOk, reception was successful

0x04 RxEndFail, reception failed

0x10 CCAreset_conf

0x20 CCAind_idle

0x30 CCAind_busy

23-16

para

meter

0x00 Not decided

0x01 Not decided

0x02 Not decided

0x03 Not decided

0x04 Not decided

Table B.4: Register Cmd_RW

Bit Value Info

Per Norén 2002



Table B.5: Register Status_R

Bit Value Info

3-0 0x0 idle or tx/rx finished, reset value

0x1 TxStart: txstart req. but not conf. from PHY

0x2 Tx : txstart confirmed from PHY, transmitting

0x3 TxEnd: txend req. but not conf.

0x4 RxStart: rxstart indicated but no data received.

0x5 Rx: receiving data

0x6 RxEnd: rxend indicated but crc not finished

0x7 RxReplyStart: reply-txstart req. but not conf.

0x8 RxReply: reply-txstart confirmed from PHY

0x9 RxReplyEnd: reply-txend req. but not conf.

0xA TxTs: Inserting timestamp

0xB CCAresetreq: request from cpu

0xC CCAresetconf: confirmation received

0xD CCAindication

4 - 1 = associated to an AP, 0 if not

5 0x0 CrcOk

0x1 CrcFail, RxEndFail set in Cmd_RW

6 0x0 CCA indication: Last CCA indicated IDLE

0x1 Last CCA indicated BUSY

Per Norén 2002


Block Control

Register TSF_RW/TSF_temp

Timer Synchronization Function (see B.5.3 also). Is

updated by Beacon or Probe Response frames or reset by

MAC. Timestamps from incoming frames are put in

TSF_temp. If decision is taken to update TSF, the value in

TSF_temp is copied to TSF.

Register NAV_RW

Network Allocation Vector (see B.5.4 also). Is updated by

duration field in header, or Beacon parameter (depends on

circumstances). Value is put in Decode(31:16) and copied

15 0x0 CP: contention period

0x1 CFP: contention-free period

Table B.6: Register TSF_RW

Bit Value Info

63-0 - Incrementing microseconds

Table B.7: Register TSF_temp

Bit Value Info

63-0 - Timestamp from incoming frame

Table B.5: Register Status_R

Bit Value Info

Per Norén 2002



to NAV if update is to be done (demands decode and fcs

results to be ok). Conditions for updating are described in

B.5.4.

Register TxVector_W

This is a parameter vector according to IEEE 802.11. Both

32-bit parts must be written in a sequence (starting with

bits 31-0), it is not possible to write to only one address.

Register RxVector_R

This is a parameter vector according to IEEE 802.11. Both

32-bit parts must be written in a sequence (starting with

bits 31-0), it is not possible to write to only one address.

Table B.8: Register NAV_RW

Bit Value Info

15-0 - Decrementing microseconds

Table B.9: Register TxVector_W

Bit Value Info

63-0 -

Per Norén 2002


Block Control

Register BSSID

When associated, this is the MAC address of the AP. When

in an IBSS this is random generated. Both addresses must

be written in one sequence.

Register PrevCmd

Copy of previous content in Cmd_RW. Internal register.

Register RXERROR

Table B.10: Register RxVector_R

Bit Value Info

63-0 -

Table B.11: Register BSSID

Bit Value Info

47-0 -

Table B.12: Register PrevCmd

Bit Value Info

23-0

Per Norén 2002



Parameter to RxEnd_indication.

Register Decode

This register contains decoded fields from the header of the

incoming frame. Old values remains until new frame or

reset.

Bits higher than 239 is from beacon or probe response

frame bodies.

Table B.13: Register RXERROR

Bit Value Info

1-0 0x0 NoError

0x1 FormatViolation

0x2 CarrierLost

0x3 UnsupportedRate

Table B.14: Register Decode

Bit Info

15-0 Frame control

31-16 Duration/AID

79-32 Address 1 (receiver)

127-80 Address 2 (transmitter), reciever of reply

175-128 Address 3

191-176 Sequence control

239-192 Address 4

Per Norén 2002


Block Control

Register Duplicate

The receiving STA shall keep a cache of recently received

<Address 2, sequence number, fragment number> tuples.

A receiving STA is required to keep only the most recent

cache entry per Address 2/sequence number pair, storing

only the most recently received fragment number for that

pair. The size of this register will be set to contain the max

nr of active stations in a BSS, for now assumed to be 5. The

more fragments bit is also stored.

247-240 SSID_length

255-248 supp_rate_length

263-256 CFP count (nr of frames incl. this to next CFP-start)

279-264 CFP max duration

295-280 CFP duration remaining (0 during CP)

Table B.15: Register Duplicate

Bit Info

63-0 <more, frag. nr, seq. nr,address 2> from a previous

frame

64 = more frags, 63-59 fragnr, 58-48127-64

191-128

255-192

319-256

(one slice for each unique pair of <addr, seq. nr>)

Table B.14: Register Decode

Bit Info

Per Norén 2002



B.5.2 Subblock amba_ctrl


Subblocks: amba_if, data_read_ctrl, data_write_ctrl, wait_ctrl

In:

AMBA_ctrl:




read_reg(31:0), wait

Out:

AMBA_data:


HRESP_HWIFCTRL(1:0)

write_reg(34:0), addr_reg(3:0), write_enable_reg

This is the AMBA slave that is used for control communication

with CPU. Commands and configuration can be written to the

registers in subblock “status_regs” (see B.5.1) by CPU and

requests/status can be read using interrupt from HWIF. When

amba_ctrl performs write or read to status_regs, no other sub-

block can access the registers. The signal “wait” is used to

insert wait_stats on AMBA-bus. Example of use: CPU attempts

to read from tsf timer during an update of tsf. Wait states must

be inserted until all bytes of tsf is updated.

B.5.3 Subblock tsf

Parent block: status_regs

Function:

This block contains a 64 bit timer used to set timestamps on

transmitted frames and some logic to control the updates of the

timer (made by beacon and probe response frames).

TSF is addressable (see Table B.1 in B.5.1).

Per Norén 2002


Block Control

B.5.4 Subblock nav

Parent block: status_regs

Function:

This is the network allocation vector (NAV). It is a counter that

is given a value that corresponds to the calculated time that the

network is busy (virtual carrier sense). The counter is decre-

mented and the virtual carrier sense considers the network busy

as long as the value is greater than 0.

During decode, the value is put in the register “Decode” in

Block status_regs

NAV is addressable (see Table B.1 in B.5.1).

B.5.5 Subblock controller


Function:

This block contains the state machines that controls all trans-

fers by setting values on controlbuses and sampling values on

statusbuses. It is the most complex block of all in HWIF and

contains several state machines.

State machines will be described here in the next revision of

this document.

Description of control buses

Naming convention: control_out controls block buffer_out,

control_tx controls block buffer_tx etc (except for regcontrol

and deccontrol, those two are internal to block control).

Per Norén 2002



Table B.16: Control buses

Name Bit Info

commonfor

all control-

buses

0 Synch. reset, active low

1 1 = rx, 0 = tx

control_out 2 1 = data from control, 0 = data from AMBA

3 1 = data on “insert_data” available

4 1 = previous data was last in frame

control_crc 2 1 = bypassing

3 (future dev : input new good-crc on bits 4-7)

4-7 (future dev : good-crc)

control_tx 2 1 = transmit

control_rx 2 1 = receive

3 1 = last byte in frame received

control_in 2

regcontrol 2 Write enable (to registers )

3 txstart_req in next cycle

4 txstart_conf

5 rxstart_ind

6 rxend_ind

7 cca_ind

8 incoming frame_ok (after crc-check)

Per Norén 2002


Block Control

Description of status buses

Naming convention: status_out is status from block buffer_out,

status_tx from block buffer_tx etc (except for regstat and dec-

stat, those two are internal to block control).

14-

9

To Status_R (3 downto 0)

(state and crc result)

15 update_tsf

16 update_nav

17 update_nav during cf , start of cfp

18 update_nav during cf , during cfp

19 Frame is from my BSS

deccontrol 2 1 = new byte available

Table B.17: Status buses

Name Bit Info

status_out 0 1 = last byte in frame transmitted

status_crc 0 1 = crc result on bit 1

1 0 = crc res. is good-crc, 1 = frame damaged

status_tx 0 1 = last byte in frame transmitted

status_rx 0 1 = last byte in frame delivered

1 1 = new byte available for decoding

Table B.16: Control buses

Name Bit Info

Per Norén 2002



B.5.6 Subblock decode


Function:

This block contains functionality for decoding of headers in

frames. It writes decode results to the Decode register. Decode

is used to determine if a reply is to be generated and for dupli-

cate filtering.

A counter is present to count incoming bytes. This will be used

to decode frame header. Values to be sampled is transferred

from buffer_rx block. Decoding functionality may be turned

off.

Decoding order: type, subtype, tods, fromds, retry, duration/

aid, address 1, address 2, sequence control.

Duplicate filtering:

The receiving STA shall keep a cache of recently received

<Address 2, sequence number, fragment number> tuples and

the register this A receiving STA is required to keep only the

most recent cache entry per Address 2-sequence number pair,

status_in 0 1 = last word fetched by AMBA data

regstat 0 SRESET (from Cmd register)

1 New command in register.

2 duplicate error (abort rx)

decstat 7-0 Nr of decoded byte

Table B.17: Status buses

Name Bit Info

Per Norén 2002


Block amba_data

storing only the most recently received fragment number for

that pair. A receiving STA may omit tuples obtained from

broadcast/multicast or ATIM frames from the cache. A destina-

tion STA shall reject as a duplicate frame any frame that has the

Retry bit set in the Frame Control field and that matches an

<Address 2, sequence number, and fragment number> tuple of

an entry in the cache.

B.6 Block amba_data

Parent block: HWIF

Subblocks: amba_if, data_read_ctrl, data_write_ctrl,

size_decoder, size_encoder, data_error, wait_ctrl

In:

AMBA_data:

HSEL_HWIFDATA, HWRITE, HADDR(31:0),



read(34:0), read_data_av, buffer_full

Out:

AMBA_data:

HRDATA_HWIFDATA(31:0), HREADY_HWIFDATA,

HRESP_HWIFDATA(1:0)

write(34:0), write_data_av, read_data_rd

This is the AMBA slave through which data flows. When a

frame is transmitted the CPU or DMA controller writes data to

this slave which transfers it to a buffer. If a frame is transmitted

data is read from this slave by those units.

Transmission: If buffer_full = 0, write_data_av = 1 means that

new data is placed on write(34:0).

Reception: read_data_rd = (read_data_av and ok), where ok =

0 means that we are not ready to receive another byte from

buffer_in.

Bits 32 and 33 in write/read(34:0) indicates byte, halfword or

word. Bit 34 can indicate if this is the last bit in a frame, but

Per Norén 2002



this option will probably not be used. Instead this will be set in

Block buffer_out.

B.6.1 Subblock amba_if

Parent block: amba_data

Function:

See description of component blocks in B.12.4

B.6.2 Subblock data_error


Function:

ERR = (WRITE_EN and READ_EN) or write_err or read_err.

B.6.3 Subblock data_read_ctrl


Function:

read_err = READ_EN and (not read_data_av)

read_data_rd = READ_EN and read_data_av

B.6.4 Subblock data_write_ctrl


Function:

write_err = WRITE_EN and buffer_full

write_data_av = WRITE_EN and (not buffer_full)

B.6.5 Subblock size_decoder


Function:

RDATA(31:0) := read(31:0)

read_size_err = 0 if read(33:32) = SIZE(1:0)

Per Norén 2002


Block buffer_out

read_size_err = 1 if read(33:32)<>SIZE(1:0)

B.6.6 Subblock size_encoder


Function:

To encode bit 32 and 33 in write with the correct wordsize.

B.7 Block buffer_out

Parent block: HWIF

Subblocks: write_ctrl, fifo, read_ctrl

In:

write(34:0), insert_data(33:0), control_out(7:0),

data_rd_out, write_data_av

Out:

data_out(7:0), status_out(7:0), data_av_out,

final_data_av_out, buffer_full

Function:

Contains FIFO as wide as AMBA bus + 1 bit for status”final”

+ 2 bits for byte selection. Functionality to insert a reply frame

(ack, cts).

B.7.1 Subblock write_ctrl

Parent block: buffer_out

Function: To control input to fifo. It is intended to use when

indata to buffer is narrower then buffer or same size. Complete

description of component at B.12.5.

B.7.2 Subblock fifo


Function: To buffer data bytes. Complete description of com-

ponent at B.12.1.

Per Norén 2002



B.7.3 Subblock read_ctrl


Function: To control output from fifo. It is intended to use

when outdata from buffer is wider then outdata or same size.

Complete description of component at B.12.6.

B.8 Block crc_unit

Parent block: HWIF

Subblocks: crc_control, crc_block,

[data,data_av,data_rd,final]_merge,

[data,data_av,data_rd,final]_mux,

In:

data_out(7:0), data_rx(7:0), control_crc(7:0), data_av_out,

data_av_rx, data_rd_tx, data_rd_in, final_data_av_out,

final_data_av_rx

Out:

data_tx(7:0), data_in(7:0), status_crc(7:0), data_av_tx,

data_av_in,

data_rd_out, data_rd_rx, final_data_av_tx,

final_data_av_in

Function:

CRC calculation on frames (rx and tx).

Can be turned of (frames bypassed).

Must have a synch. reset from control between frames.

B.8.1 Subblock crc_control

Parent block: crc_unit

Function:

To control the use of the CRC algorithm; if direction is rx or tx

and bypassing (if CRC calculation is not used in HW).

To decide if the result is “good crc”, i.e. the frame is undam-

aged. The good-crc value is hardcoded in VHDL, but a future

Per Norén 2002


Block buffer_tx

development is to be able to load this from a register in the con-

trol block.

B.8.2 Subblock crc_block


Function:

CRC calculation on consecutive bytes of a frame. If direction is

tx, the fcs field (the result after the last byte) is appended, if rx

not.

B.8.3 Subblocks [data,data_av,data_rd,final]_merge


Function:

Simply to merge two signals or buses to one common bus.

B.8.4 Subblocks [data,data_av,data_rd,final]_mux


Function:

To choose inputs depending on the transfer direction (rx/tx).

B.9 Block buffer_tx

Parent block: HWIF


In:

data_tx(7:0), control_tx(7:0), data_av_tx,

final_data_av_tx, phy_data_conf

Out:

phy_txdata(7:0), status_tx(7:0), data_rd_tx, phy_data_req

Function:

This block collects bytes from the crc block and puts them

on PHY SAP (interface to physical layer). Timing for this

is handled by the control block via the control bus. Buffer

capacity is available and set with generic vhdl parameters.

Per Norén 2002




Parent block: buffer_tx




B.9.2 Subblock fifo



ponent at B.12.1.






B.10 Block buffer_rx

Parent block: HWIF


In:

phy_rxdata(7:0), control_in(7:0), data_rd_rx,

phy_data_ind

Out:

data_rx(7:0), rx_decode(7:0), status_rx(7:0), data_av_rx,

final_data_av_rx

Function:

Bytes is delivered here from PHY SAP during rx.

Bytes that are to be decoded is transferred to control block.


Parent block: buffer_rx

Per Norén 2002


Block buffer_in




B.10.2 Subblock fifo



ponent at B.12.1.






B.11 Block buffer_in

Parent block: HWIF


In:

data_in(7:0), control_in(7:0), data_av_in,

final_data_av_in, read_data_rd

Out:

read(34:0), status_in(7:0), data_rd_in, read_data_av

On_Off: None.

Power save: ?

Contains FIFO as wide as AMBA bus + 1 bit for status =

final + 2 bits for byte selcetion.


Parent block: buffer_in




Per Norén 2002



B.11.2 Subblock fifo



ponent at B.12.1.






B.12 Component blocks

Descriptions of component blocks for reuse.

B.12.1 Fifo_template

In:

D(WORDSIZE-1:0), CLK, HRESETn, WRITE_EN,

READ_EN

Out:

Q(Wordsize-1:0), FULL, EMPTY, LASTWORD, WERR,

RERR

Generic:

WORDSIZE (Positive), BUFFERSIZE (Positive)

This template is intended to be instantiated as fifo in all

buffers in HWIF. Wordsize and Buffersize gives dimen-

sions via generic map.

B.12.2 Bitmux_template

In:

INSIGNALS(NR_SIGNALS-1:0), CTRL(NR_CTRLS-

1:0)

Out:

Outsignal(NR_SIGNALS-1:0), ERR

Per Norén 2002


Component blocks

Generic:

NR_SIGNALS (Positive), NR_CTRLS (Positive)

NR_CTRLS must equal ceiling(2-log(NR_SIGNALS))

ERR = 1 when CTRL points to a non-existing input, e.g.

NR_SIGNALS = 5 and NR_CTRLS = 3 and CTRL = 7.

A multiplexer for a variable nr of signals.

B.12.3 Bytemux_template

In:

INBUSES(NR_BUSES-1:0), CTRL(NR_CTRLS-1:0)

Out:

Outsignal(NR_BUSES-1:0), ERR

Generic:

NR_BUSES (Positive), NR_CTRLS (Positive)

NR_CTRLS must equal ceiling(2-log(NR_BUSES))

ERR = 1 when CTRL points to a non-existing input, e.g.

NR_BUSES = 5 and NR_CTRLS = 3 and CTRL = 7.

A multiplexer for a variable nr of buses of width 8.

B.12.4 amba_if

In:

AMBA interface:

HSEL, HWRITE, HADDR(31:0), HTRANS(1:0),

HSIZE(2:0), HBURST(2:0), HWDATA(31:0),

HREADYin,

Internal interface: RDATA, SETWAIT, ERR

Out:

AMBA interface:

HRDATA(31:0), HREADYout, HRESP(1:0),

Internal interface:

WDATA(31:0), ADDR(31:0), SIZE(2:0), WRITE_EN,

READ_EN

On-Off: None

Per Norén 2002



The internal interface connects the AMBA slave compo-

nent. WRITE_EN = READ_EN = 0 means that the slave is

not addressed. WRITE_EN = 1, READ_EN = 0 means

write and so on. SETWAIT is used to add wait states.

HRDATA := RDATA, WDATA := HWDATA and SIZE :=

HSIZE. ERR = 1 means that an error has occured in

amba_if.

B.12.5 fifo_wctrl

In:

INDATA_IN((INWORDBYTES*8)-1:0),

CTRL_IN(15:0), SIZE(1:0), HCLK, HRESETn, WERR,

INDATA_AV, FINAL_AV, FULL

Out:

INDATA_OUT(CTRLBITS+(OUTWORDBYTES*8)-

1:0), STAT_IN(15:0), WE, INDATA_RD

Generic:

INWORDBYTES: Positive, , number of BYTES in one

dataword in indata, (1 or 4), OUTWORDBYTES: Positive,

number of BYTES in one dataword in outdata (1 or 4 but

>= INWORDBYTES), ,CTRLBITS: Positive range 3

downto 1, number of bits in fifo for size and last-in-frame

bit

This is an input interface block to component block

fifo_template from some data delivering block that has

DATA_AV (data is available) as output and DATA_RD

(ready for next) as input. It places bytes in 8 or 32 bit fifo

according to AMBA bus sizes (1, 2 or 4 bytes in one word,

not 3).

B.12.6 fifo_rctrl

In:

OUTDATA_IN(CTRLBITS+(INWORDBYTES*8)-1:0),

CTRL(15:0), HCLK, HRESETn, RERR, OUTDATA_RD,

EMPTY

Per Norén 2002


Component blocks

Out:

OUTDATA_OUT((OUTWORDBYTES*8)-1:0),

STAT(15:0), SIZE(1:0), RE, FINAL_AV, OUTDATA_AV

Generic:

INWORDBYTES (Positive), number of BYTES in one

dataword in indata, (1 or 4), OUTWORDBYTES: Positive,

number of BYTES in one dataword in outdata (1 or 4 but

<= INWORDBYTES), CTRLBITS (Positive), number of

bits in fifo for size and last-in-frame bit

This is an output interface block from component block

fifo_template to some data delivering block that has

DATA_RD (previous data is read, ready for next) as output

and DATA_AV (data available) as input. It reads bytes

from 8 or 32 bit fifo according to AMBA bus sizes (1, 2 or

4 bytes in one word, not 3).

B.12.7 bitmerge

In:

A, B

Out:

O

Function: O(0) = A, O(1) = B

Used as input to component bitmux

B.12.8 busmerge

In:

ABUS(7:0), BBUS(7:0)

Out:

Obus(1:0) of stdlogicvector(7:0)

Function: Obus(0) = Abus, Obus(1) = Bbus

Used as input to component bytemux

Per Norén 2002



Per Norén 2002


Appendix C: Block diagrams

This appendix contains block diagrams over the top level

design and the subblock “Control”. Because of the size of the

diagrams they are divided in two parts denoted left and right.

Left and right part are put in the same spread for best readabil-

ity.

Details of blocks in the diagram can be extracted from Appen-

dix B: Design specification using the block and subblock

names.

Per Norén 2002

Ericsson Microelectronics Page C-1

Block diagrams

Figure C.1: HWIF top level, left side

Per Norén 2002

Page C-2 Ericsson Microelectronics

Figure C.2: HWIF top level, right side

Per Norén 2002


Block diagrams

Figure C.3: Subblock Control, left side

Per Norén 2002


Figure C.4: Subblock Control, right side

Per Norén 2002


Block diagrams

Per Norén 2002


På svenska

Appendix D: Copyright

D.1 På svenska

Detta dokument hålls tillgängligt på Internet – eller dess

framtida ersättare – under en längre tid från publiceringsdatum

under förutsättning att inga extra-ordinära omständigheter upp-

står.

Tillgång till dokumentet innebär tillstånd för var och en att läsa,

ladda ner, skriva ut enstaka kopior för enskilt bruk och att

använda det oförändrat för ickekommersiell forskning och för

undervisning. Överföring av upphovsrätten vid en senare tid-

punkt kan inte upphäva detta tillstånd. All annan användning av

dokumentet kräver upphovsmannens medgivande. För att

garantera äktheten, säkerheten och tillgängligheten finns det

lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som

upphovsman i den omfattning som god sed kräver vid användn-

ing av dokumentet på ovan beskrivna sätt samt skydd mot att

dokumentet ändras eller presenteras i sådan form eller i sådant

sammanhang som är kränkande för upphovsmannens litterära

eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Elec-

tronic Press se förlagets hemsida

http://www.ep.liu.se/

Per Norén 2002

Ericsson Microelectronics Page D-1

Copyright

D.2 In English

The publishers will keep this document online on the Internet -

or its possible replacement - for a considerable time from the

date of publication barring exceptional circumstances.

The online availability of the document implies a permanent

permission for anyone to read, to download, to print out single

copies for your own use and to use it unchanged for any non-

commercial research and educational purpose. Subsequent

transfers of copyright cannot revoke this permission. All other

uses of the document are conditional on the consent of the

copyright owner. The publisher has taken technical and admin-

istrative measures to assure authenticity, security and accessi-

bility.

According to intellectual property law the author has the right

to be mentioned when his/her work is accessed as described

above and to be protected against infringement.

For additional information about the Linköping University

Electronic Press and its procedures for publication and for

assurance of document integrity, please refer to its WWW

home page:

http://www.ep.liu.se/

© Per Norén

Per Norén 2002

Page D-2 Ericsson Microelectronics

Index

Aaccess point 11Ad hoc network 10AHB 28AMBA 28AP 11ARM 7 27

BBackground 1Block diagram 21

Ccarrier 14Conclusions 40

DDesign flow 17Design for reuse or tailor made blocks?

38design tool 31Distributed vs Point coordination 10

EEricsson Microelectronics 3Estimation of clock-cycle usage 18Evaluation 37

FFCS-field 14frame 14Future development 38

HHardware-software partitioning 17header 7

IIEE

Im

Int

LLin

MMA

MA

Me

Mi

Mo

NNe

OOS

Ou

Ov

PPH

Pla

Pla

Pro

Pu

RRe

Re

res

Per Nor

Ericsson M

E 9plementation 31roduction 1

köping Design Center 3

C 11C interfaces 14

dium Access Controller 13crosystems 3delSim 34

tworking 5

I 5tcome of time plan 39erview 1

Y 11nning 4nning-problems 38blems 38

rpose 2

ading instructions 1noir 31ults 37

én 2002

icroelectronics

SSIFS 19simulation 34STA 10Standards for wireless communication 7system bus 28

TTechnical results 37The 13The IEEE 802.11 MAC frame 14Time critical sections 14Timing requirements 17Tools 31

VVHDL 32VHSIC HDL 32

WWaveform 34Wireless 5WLAN 10

Per Nor

Ericsson Mic

én 2002

roelectronics

Physical layer interface for IEEE 802.11 MAC18707/FULLTEXT01.pdf · and networking recognize names...

Documents

Transcript of Physical layer interface for IEEE 802.11 MAC18707/FULLTEXT01.pdf · and networking recognize names...