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
Ericsson Microelectronics
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
Ericsson Microelectronics
Per Norén 2002
Ericsson Microelectronics
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
Ericsson Microelectronics
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
Ericsson Microelectronics
Per Norén 2002
Ericsson Microelectronics
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
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
Ericsson Microelectronics Page 3
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
Page 4 Ericsson Microelectronics
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
Ericsson Microelectronics Page 5
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
Page 6 Ericsson Microelectronics
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
Ericsson Microelectronics Page 7
Wireless communication
Per Norén 2002
Page 8 Ericsson Microelectronics
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
Ericsson Microelectronics Page 9
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
Page 10 Ericsson Microelectronics
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
Ericsson Microelectronics Page 11
IEEE 802.11
Per Norén 2002
Page 12 Ericsson Microelectronics
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
Ericsson Microelectronics Page 13
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
Page 14 Ericsson Microelectronics
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
Ericsson Microelectronics Page 15
The MAC unit
Per Norén 2002
Page 16 Ericsson Microelectronics
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
Ericsson Microelectronics Page 17
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
Page 18 Ericsson Microelectronics
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
Ericsson Microelectronics Page 19
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
Page 20 Ericsson Microelectronics
Top level design
Figure 5.1: Block diagram for MAC
Per Norén 2002
Ericsson Microelectronics Page 21
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
Page 22 Ericsson Microelectronics
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
Ericsson Microelectronics Page 23
Design flow
Figure 5.2: Top level diagram for HWIF
Per Norén 2002
Page 24 Ericsson Microelectronics
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
Ericsson Microelectronics Page 25
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
Page 26 Ericsson Microelectronics
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
Ericsson Microelectronics Page 27
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
Page 28 Ericsson Microelectronics
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
Ericsson Microelectronics Page 29
Design flow
Per Norén 2002
Page 30 Ericsson Microelectronics
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
Ericsson Microelectronics Page 31
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
Page 32 Ericsson Microelectronics
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
Ericsson Microelectronics Page 33
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
Page 34 Ericsson Microelectronics
Verification with ModelSim
tool and thourough testing in a programmable circuit like a
FPGA (field programmable array).
Per Norén 2002
Ericsson Microelectronics Page 35
Implementation
Per Norén 2002
Page 36 Ericsson Microelectronics
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
Ericsson Microelectronics Page 37
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
Page 38 Ericsson Microelectronics
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
Ericsson Microelectronics Page 39
Evaluation and results
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
Page 40 Ericsson Microelectronics
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
Ericsson Microelectronics Page 41
Evaluation and results
Per Norén 2002
Page 42 Ericsson Microelectronics
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
Ericsson Microelectronics Page 43
References
Per Norén 2002
Page 44 Ericsson Microelectronics
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
Ericsson Microelectronics Page B-3
Design specification
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
Page B-4 Ericsson Microelectronics
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),
HWDATA(31:0), HREADYin
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
Ericsson Microelectronics Page B-5
Design specification
B.5 Block Control
Parent block: HWIF
Subblocks: controller, status_regs, amba_ctrl, decode
In:
AMBA_control:
HSEL_HWIFCTRL, HWRITE, HADDR(31:0),
HTRANS(1:0), HSIZE(2:0), HBURST(2:0), HPROT(3:0),
HWDATA(31:0), HREADYin
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:
HRDATA_HWIFCTRL(31:0), HREADY_HWIFCTRL,
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
Page B-6 Ericsson Microelectronics
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
Ericsson Microelectronics Page B-7
Design specification
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
Page B-8 Ericsson Microelectronics
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
Ericsson Microelectronics Page B-9
Design specification
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
Page B-10 Ericsson Microelectronics
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
Ericsson Microelectronics Page B-11
Design specification
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
Page B-12 Ericsson Microelectronics
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
Ericsson Microelectronics Page B-13
Design specification
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
Page B-14 Ericsson Microelectronics
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
Ericsson Microelectronics Page B-15
Design specification
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
Page B-16 Ericsson Microelectronics
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
Ericsson Microelectronics Page B-17
Design specification
B.5.2 Subblock amba_ctrl
Parent block: control
Subblocks: amba_if, data_read_ctrl, data_write_ctrl, wait_ctrl
In:
AMBA_ctrl:
HSEL_HWIFCTRL, HWRITE, HADDR(31:0),
HTRANS(1:0), HSIZE(2:0), HBURST(2:0), HPROT(3:0),
HWDATA(31:0), HREADYin
read_reg(31:0), wait
Out:
AMBA_data:
HRDATA_HWIFCTRL(31:0), HREADY_HWIFCTRL,
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
Page B-18 Ericsson Microelectronics
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
Parent block: control
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
Ericsson Microelectronics Page B-19
Design specification
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
Page B-20 Ericsson Microelectronics
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
Ericsson Microelectronics Page B-21
Design specification
B.5.6 Subblock decode
Parent block: control
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
Page B-22 Ericsson Microelectronics
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),
HTRANS(1:0), HSIZE(2:0), HBURST(2:0), HPROT(3:0),
HWDATA(31:0), HREADYin
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
Ericsson Microelectronics Page B-23
Design specification
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
Parent block: amba_data
Function:
ERR = (WRITE_EN and READ_EN) or write_err or read_err.
B.6.3 Subblock data_read_ctrl
Parent block: amba_data
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
Parent block: amba_data
Function:
write_err = WRITE_EN and buffer_full
write_data_av = WRITE_EN and (not buffer_full)
B.6.5 Subblock size_decoder
Parent block: amba_data
Function:
RDATA(31:0) := read(31:0)
read_size_err = 0 if read(33:32) = SIZE(1:0)
Per Norén 2002
Page B-24 Ericsson Microelectronics
Block buffer_out
read_size_err = 1 if read(33:32)<>SIZE(1:0)
B.6.6 Subblock size_encoder
Parent block: amba_data
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
Parent block: buffer_out
Function: To buffer data bytes. Complete description of com-
ponent at B.12.1.
Per Norén 2002
Ericsson Microelectronics Page B-25
Design specification
B.7.3 Subblock read_ctrl
Parent block: buffer_out
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
Page B-26 Ericsson Microelectronics
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
Parent block: crc_unit
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
Parent block: crc_unit
Function:
Simply to merge two signals or buses to one common bus.
B.8.4 Subblocks [data,data_av,data_rd,final]_mux
Parent block: crc_unit
Function:
To choose inputs depending on the transfer direction (rx/tx).
B.9 Block buffer_tx
Parent block: HWIF
Subblocks: write_ctrl, fifo, read_ctrl
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
Ericsson Microelectronics Page B-27
Design specification
B.9.1 Subblock write_ctrl
Parent block: buffer_tx
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.9.2 Subblock fifo
Parent block: buffer_tx
Function: To buffer data bytes. Complete description of com-
ponent at B.12.1.
B.9.3 Subblock read_ctrl
Parent block: buffer_tx
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.10 Block buffer_rx
Parent block: HWIF
Subblocks: write_ctrl, fifo, read_ctrl
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.
B.10.1 Subblock write_ctrl
Parent block: buffer_rx
Per Norén 2002
Page B-28 Ericsson Microelectronics
Block buffer_in
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.10.2 Subblock fifo
Parent block: buffer_rx
Function: To buffer data bytes. Complete description of com-
ponent at B.12.1.
B.10.3 Subblock read_ctrl
Parent block: buffer_rx
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.11 Block buffer_in
Parent block: HWIF
Subblocks: write_ctrl, fifo, read_ctrl
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.
B.11.1 Subblock write_ctrl
Parent block: buffer_in
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.
Per Norén 2002
Ericsson Microelectronics Page B-29
Design specification
B.11.2 Subblock fifo
Parent block: buffer_in
Function: To buffer data bytes. Complete description of com-
ponent at B.12.1.
B.11.3 Subblock read_ctrl
Parent block: buffer_in
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.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
Page B-30 Ericsson Microelectronics
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
Ericsson Microelectronics Page B-31
Design specification
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
Page B-32 Ericsson Microelectronics
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
Ericsson Microelectronics Page B-33
Design specification
Per Norén 2002
Page B-34 Ericsson Microelectronics
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
Ericsson Microelectronics Page C-3
Block diagrams
Figure C.3: Subblock Control, left side
Per Norén 2002
Page C-4 Ericsson Microelectronics
Figure C.4: Subblock Control, right side
Per Norén 2002
Ericsson Microelectronics Page C-5
Block diagrams
Per Norén 2002
Page C-6 Ericsson Microelectronics
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