Physical Layer Interface for IEEE 802.11 MAC

Physical layer interface for IEEE 802.11 MAC

Examensarbete utfört i Elektroniksystem av

Per Norén

LiTH-ISY-Ex-3241 2002-10-01

Physical layer interface for IEEE 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, Institution Datum Division, Department Date 2002-10-01

Institutionen för Systemteknik 581 83 LINKÖPING

Språk Rapporttyp ISBN Language Report category

Svenska/Swedish Licentiatavhandling X Engelska/English X Examensarbete ISRN LITH-ISY-EX-3241-2002

C-uppsats D-uppsats Serietitel och serienummer ISSN Title of series, numbering

Övrig rapport ____

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

Titel Hårdvaruinterface för IEEE 802.11 MAC Title Physical layer interface for IEEE 802.11 MAC

Författare Per Norén Author

Sammanfattning Abstract There are several standards for wireless communication. People that are involved in computers and networking recognize names like Bluetooth, HiperLAN and IEEE 802.11. A fundamental part of an IEEE 802.11 node is the Medium Access Controller. It establishes and controls communication with other nodes, using a physical layer unit. This is the work that was carried out as a master thesis project at Ericsson Microelectronics. The main goal was to design, implement and evaluate a hardware interface between the MAC and the physical layer. An important part of the work was to ﬁnd a suitable partition scheme for hardware and software and to achieve this, an investigation of processor-cycles usage was carried out to support design decisions. The hardware/software partition resulted in hardware-functionality for decode of received frames and automatic transmission of acknowledge frames.

Nyckelord Keyword digital, electronics, IEEE, 802.11, WLAN, MAC, elektronik

Abstract

There are several standards for wireless communication. People that are involved in computers and networking recognize 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 communication 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 important part of the work was to ﬁnd a suitable partition scheme for hardware and software and to achieve this, an investigation of processor-cycles usage was carried out to support design decisions.

The hardware/software partition resulted in hardware-functionality for decoding of received frames and automatic transmission of acknowledge frames. It was found that this solution fullﬁlled the hard timing requirements but it is also a wellknown fact that a hardware solution is less ﬂexible than software.

Per Norén 2002 Ericsson Microelectronics Per Norén 2002 Ericsson Microelectronics Preface

This thesis concludes ﬁve 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 ﬁnal 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 ...... 1 1.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 ...... 5 2.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 ...... 9 3.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 ...... 13 4.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 ﬂow...... 17 5.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 ...... 31 6.1 Tools ...... 31 6.1.1 Renoir ...... 31 6.1.2 VHDL ...... 32 6.2 Veriﬁcation with ModelSim ...... 33 6.2.1 ModelSim ...... 34

7 Evaluation and results ...... 37 7.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-1 B.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-1 D.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 ﬁnal 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 problem was faced and what design decisions that was taken, as well as a short description of the data ﬂow 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 speciﬁcation 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 recognize 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 ﬁrst this thesis work was initated to investigate how a possible MAC architecture would look like. The ﬁrst 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 important part of the work was to ﬁnd a suitable partition scheme for hardware and software. The result was to be used in a concurrent 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 (180credits) 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 proﬁle of specialization. The programme was established 20years 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 support 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 microelectronic 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 ﬁrst 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 covered 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 working 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 deﬁnition 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 networking 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 deﬁned an architecture called the Open Systems Interconnection, commonly 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 ﬁrst one, Network. (Source: [7])

Per Norén 2002 Ericsson Microelectronics Page 5 Wireless communication

Transmitting host Receiving host

Application Application

Data on its way Presentation Presentation through the network Session Session

Transport Transport

Network Network Network

Data link Data link Data link

Physical Physical Physical

A node in the network, e.g. a router Figure 2.1: The OSI reference model

When data, e.g. an e-mail from an e-mail client in the application layer, is transmitted it is ﬁrst passed down through the protocol 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-

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 ﬁelds 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 transmissions 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-proﬁt, 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 30percent 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 transmission 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 management 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 Speciﬁcation 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 controlled with a distributed algorithm. In the standard this is denoted an IBSS (independent basic service set). Any collection 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 10Ericsson 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 centralized 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 system). 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 ﬂow control by using acknowledges. A security 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, especially those about design and implementation.

4.1 Overview

MAC is an abbreviation for Medium Access Controller. Using networking terminology it implements the ﬁrst 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 physical 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 chapter 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 fragmenting, 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 conﬁrm 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 ﬂow 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 ﬁeld (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 ﬁeld 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 deﬁnes one data interface and one management interface in in each direction. The management 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 “virtual” 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 operations. This leads to another discussion (read more in 5.1) regarding what to implement in software (more ﬂexible) 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 ﬂow

The design of the hardware interface (denoted HWIF in this report) was divided in some different activities. The partitioning between hardware and software as well as the writing of the design speciﬁcation 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 speciﬁcation 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 understanding of the required functionality. To get this understanding, 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 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 operations.

Per Norén 2002 Ericsson Microelectronics Page 17 Design ﬂow

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 processor 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 timing aspects as result. These results could then be used to support 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 frequency, data rate and different types of delay. To get useful results, 80 MHz and 54 Mbps was chosen as this was the frequency 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 ﬁrst 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 deﬁned 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 developed for this investigation gives as output an estimated value for MacProcessingDelay to support design decisions.

A number of different conﬁgurations could be chosen, but the parameters that gave most impact on the result was the following:

• 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 ﬂow

Table 5.1: Results from clock cycle estimation

Lowest Average Conﬁguration Highest value value MacProcessingDelay CRC calculation, 6.2 µµµs 495(!) s 117 s decode and reply all in SW CRC calculation in 0.3 µµs 2.2 s 1.27 µs HW, decode and reply in SW CRC calculation, 0.3 µµs 1.2 s 0.49 µs decode and reply all in HW

SW is software, HW is hardware, µ s is microseconds The average value is calculated from a number of simulations with different 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.

Per Norén 2002 Page 20Ericsson Microelectronics Top level design

Figure 5.1: Block diagram for MAC

Per Norén 2002 Ericsson Microelectronics Page 21 Design ﬂow

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 controlling 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 status to make decicions on. The parameter vectors are described in the standard [2] and it seemed like a good decision 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" conﬁrmed 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 partitioning. As described in 5.1.3, the maximum value for MacProcess- ingDelay was 2 to 3 microseconds. Table 5.1 indicates that the conﬁguration 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 justiﬁcation 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 ﬂow

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 available in Appendix B: Design speciﬁcation.

5.2.2 From design to implementation

It is not always so easy to identify the structure of a hierarchical design before the construction work has begun. The level of difﬁculty 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 methodology, 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 corresponds to the block names in the diagram in Figure 5.2, and is only an overview of the data and control ﬂow 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 ﬂow

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 concurrently 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 interface “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 handled by the AMBA protocol). 5. The ﬁrst byte of data is transferred to “Buffer_Rx” from the physical layer. 6. “CRC_unit” reads the ﬁrst 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 microprocessor macrocell for use in application-speciﬁc 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 ﬂow

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 ﬂexible 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 number 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 transfer 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

Control (n) Control (n+1)

Address (n) Address (n+1)

Data (n-1) Data (n)

Figure 5.3: Pipelined transfers on AMBA AHB

Per Norén 2002 Ericsson Microelectronics Page 29 Design ﬂow

Per Norén 2002 Page 30Ericsson 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 buffers 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-middle” 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 efﬁcient 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 diagram (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

Figure 6.1: Example block diagram

6.1.2 VHDL

An efﬁcient way to describe the function of a digital component 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 development 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 hardware description languages. (Source [1])

Per Norén 2002 Page 32 Ericsson Microelectronics Veriﬁcation 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 follows:

-- 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 Veriﬁcation 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 environment. It is quite easy to use but powerful and it has several features:

• 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 ﬁles.

If not used with Renoir or a command line compiler, a compiler can be called upon from within the ModelSim environment.

Figure 6.2: Waveform in ModelSim

It should be noted that a complete veriﬁcation of a component like this hardware interface can include applying a synthesis-

Per Norén 2002 Page 34 Ericsson Microelectronics Veriﬁcation with ModelSim tool and thourough testing in a programmable circuit like a FPGA (ﬁeld 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 different 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 speciﬁcations.

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 control 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 signiﬁcant than others:

7.2.1 Design for reuse or tailor made blocks?

As mentioned in 5.2.2, some blocks where designed as components 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 ﬁxed 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 appropriate 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 ﬁxed 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 transmission 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 functionality is the intended one. This means simply that the ﬁrst 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 ﬁrst four weeks

was described as a prestudy and deﬁnition 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 activities on block level proceeded according to plan and writing of this report went on very good. The investigation of clockcycles 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 ﬁnished 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 complexity 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 ﬁve 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 correction 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 40Ericsson 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 system. • The major drawback is that it is what it is: a hardware component. 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 ﬂexibility.

The ﬁnal conclusion from the author is that development of functionality to solve this problem should go towards more ﬂexible 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 speciﬁcation

This design speciﬁcation 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 acknowledge, 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 speciﬁcations 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 conﬁgure 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 subblocks take a look at Appendix C:'Block diagrams'.

Per Norén 2002 Ericsson Microelectronics Page B-1 Design speciﬁcation

AMBA speciﬁc remark: AMBA interfaces does not support HPROT signals and only the single transfer option of the HBURST signal.

B.3 Design decisions

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 partitioning. As described in 5.1.3, the maximum value for MacProcess- ingDelay was 2 to 3 microseconds. Table 5.1 indicates that the conﬁguration 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 different values in registers (this gives another justiﬁcation to design for such registers).

HWIF is designed assuming that decoding of an incoming signal field is done in the baseband circuits (part of the physical layer) and copied to the RxVector on start of reception. If baseband 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 baseband.

Per Norén 2002 Ericsson Microelectronics Page B-3 Design speciﬁcation

B.4 HWIF top level design

AMBA_data AMBA_ctrl (AMBA slave) (AMBA slave)

HWIF

PHY SAP (if to physical layer)

Figure B.1: HWIF

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 registers 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:

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 associated with PHY_CCA_indication and PHY_RXEND. PHY SAP is described in part 12, physical layer service speciﬁca- 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 diagrams' to get a good view of the structure.

Per Norén 2002 Ericsson Microelectronics Page B-5 Design speciﬁcation

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 transfers. 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 Conﬁg_W 0x00 Conﬁguration of this unit. Address 0x00 accessess bit 31-0, address 0x04 0x04 bit 63-32 and so on. 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 speciﬁcation

Table B.1: Registers externally accessable

Register Addr Info 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

ﬁelds TSF_temp 0x50 This is used to put incoming timestamp before decision of update is 0x54 taken NAV_temp 0x58 Incoming value

Register Conﬁg_W Some parameters must be set to control decisions in HWIF. Those parameters are written to this register. All 4 32-bit

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.

Table B.3: Register Conﬁg_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- Ack/CTS transmit time + SIFS 93 (added to duration in ack and cts)

122- - rx_delay in microseconds 118 127- - tx_delay in microseconds 123

Per Norén 2002 Ericsson Microelectronics Page B-9 Design speciﬁcation

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 0x0 Synchronous reset (from 0x1 TxRequest, new frame will follow CPU) 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 0x00 TxEndOk, transmission succeded (to CPU) 0x01 TxEndFail, transmission failed 0x02 RxStart

Per Norén 2002 Page B-10Ericsson Microelectronics Block Control

Table B.4: Register Cmd_RW

Bit Value Info 0x03 RxEndOk, reception was successful 0x04 RxEndFail, reception failed 0x10 CCAreset_conf 0x20 CCAind_idle 0x30 CCAind_busy 23-16 0x00 Not decided para meter 0x01 Not decided 0x02 Not decided 0x03 Not decided 0x04 Not decided

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.

Per Norén 2002 Ericsson Microelectronics Page B-11 Design speciﬁcation

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

Table B.5: Register Status_R

Bit Value Info 15 0x0 CP: contention period 0x1 CFP: contention-free period

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.

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

Register NAV_RW Network Allocation Vector (see B.5.4 also). Is updated by duration ﬁeld in header, or Beacon parameter (depends on circumstances). Value is put in Decode(31:16) and copied

Per Norén 2002 Ericsson Microelectronics Page B-13 Design speciﬁcation

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.

Table B.8: Register NAV_RW

Bit Value Info 15-0 - Decrementing microseconds

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.

Table B.9: Register TxVector_W

Bit Value Info 63-0 -

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.

Per Norén 2002 Page B-14 Ericsson Microelectronics Block Control

Table B.10: Register RxVector_R

Bit Value Info 63-0 -

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.

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 speciﬁcation

Parameter to RxEnd_indication.

Table B.13: Register RXERROR

Bit Value Info 1-0 0x0 NoError 0x1 FormatViolation 0x2 CarrierLost 0x3 UnsupportedRate

Register Decode This register contains decoded ﬁelds 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.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

Table B.14: Register Decode

Bit Info 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)

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.

Table B.15: Register Duplicate

Bit Info 63-0 from a previous frame 127-64 64 = more frags, 63-59 fragnr, 58-48 191-128 255-192 319-256 (one slice for each unique pair of )

Per Norén 2002 Ericsson Microelectronics Page B-17 Design speciﬁcation

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 conﬁguration 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 subblock 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 transfers 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 speciﬁcation

Table B.16: Control buses

Name Bit Info commonfor 0 Synch. reset, active low all control- 1 1 = rx, 0 = tx buses 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-20Ericsson Microelectronics Block Control

Table B.16: Control buses

Name Bit Info 14- To Status_R (3 downto 0) 9 (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

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 decstat, those two are internal to block control).

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

Per Norén 2002 Ericsson Microelectronics Page B-21 Design speciﬁcation

Table B.17: Status buses

Name Bit Info 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

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 duplicate ﬁltering.

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 ﬁltering: The receiving STA shall keep a cache of recently received

tuples and the register this A receiving STA is required to keep only the most recent cache entry per Address 2-sequence number pair,

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 ﬁeld and that matches an

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 ﬂows. 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 speciﬁcation

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, ﬁfo, 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, ﬁnal_data_av_out, buffer_full

Function: Contains FIFO as wide as AMBA bus + 1 bit for status”ﬁnal” + 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 ﬁfo. 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 ﬁfo

Parent block: buffer_out Function: To buffer data bytes. Complete description of component at B.12.1.

Per Norén 2002 Ericsson Microelectronics Page B-25 Design speciﬁcation

B.7.3 Subblock read_ctrl

Parent block: buffer_out Function: To control output from ﬁfo. 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 undamaged. 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 control 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 ﬁeld (the result after the last byte) is appended, if rx not.

B.8.3 Subblocks [data,data_av,data_rd,ﬁnal]_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,ﬁnal]_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, ﬁfo, read_ctrl In: data_tx(7:0), control_tx(7:0), data_av_tx, ﬁnal_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 speciﬁcation

B.9.1 Subblock write_ctrl

Parent block: buffer_tx Function: To control input to ﬁfo. 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 ﬁfo

Parent block: buffer_tx Function: To buffer data bytes. Complete description of component at B.12.1.

B.9.3 Subblock read_ctrl

Parent block: buffer_tx Function: To control output from ﬁfo. 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, ﬁfo, 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, ﬁnal_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 ﬁfo. 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 ﬁfo

Parent block: buffer_rx Function: To buffer data bytes. Complete description of component at B.12.1.

B.10.3 Subblock read_ctrl

Parent block: buffer_rx Function: To control output from ﬁfo. 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 ﬁfo. 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 speciﬁcation

B.11.2 Subblock ﬁfo

Parent block: buffer_in Function: To buffer data bytes. Complete description of component at B.12.1.

B.11.3 Subblock read_ctrl

Parent block: buffer_in Function: To control output from ﬁfo. 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 ﬁfo 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-30Ericsson 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 speciﬁcation

The internal interface connects the AMBA slave component. WRITE_EN = READ_EN = 0means 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 ﬁfo_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 ﬁfo for size and last-in-frame bit

This is an input interface block to component block ﬁfo_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 ﬁfo according to AMBA bus sizes (1, 2 or 4 bytes in one word, not 3).

B.12.6 ﬁfo_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 ﬁfo for size and last-in-frame bit

This is an output interface block from component block ﬁfo_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 ﬁfo 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 speciﬁcation

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 speciﬁcation 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 ﬁnns 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/

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 2002 Page D-2 Ericsson Microelectronics Index

A I access point 11 IEEE 9 Ad hoc network 10 Implementation 31 AHB 28 Introduction 1 AMBA 28 AP 11 L ARM 7 27 Linköping Design Center 3

B M Background 1 MAC 11 Block diagram 21 MAC interfaces 14 Medium Access Controller 13 C Microsystems 3 carrier 14 ModelSim 34 Conclusions 40 N D Networking 5 Design flow 17 Design for reuse or tailor made blocks?O 38 OSI 5 design tool 31 Outcome of time plan 39 Distributed vs Point coordination 10 Overview 1

E P Ericsson Microelectronics 3 PHY 11 Estimation of clock-cycle usage 18 Planning 4 Evaluation 37 Planning-problems 38 Problems 38 F Purpose 2 FCS-field 14 frame 14 R Future development 38 Reading instructions 1 Renoir 31 H results 37 Hardware-software partitioning 17 header 7

Per Norén 2002 Ericsson Microelectronics S SIFS 19 simulation 34 STA 10 Standards for wireless communication 7 system bus 28

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

V VHDL 32 VHSIC HDL 32

W Waveform 34 Wireless 5 WLAN 10

Per Norén 2002 Ericsson Microelectronics