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 Division, Department Institutionen för Systemteknik 581 83 LINKÖPING Datum Date 2002-10-01 Språk Language Rapporttyp Report category ISBN Svenska/Swedish X Engelska/English Licentiatavhandling
X Examensarbete ISRN LITH-ISY-EX-3241-2002 C-uppsats
D-uppsats Serietitel och serienummer
Title of series, numbering
ISSN
Övrig rapport ____
URL för elektronisk version
http://www.ep.liu.se/exjobb/isy/2002/3241/
Titel Title
Hårdvaruinterface för IEEE 802.11 MAC Physical layer interface for IEEE 802.11 MAC
Författare
Author
Per Norén
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 commu-nication 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 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 decisions. The hard-ware/software partition resulted in hardware-functionality for decode of received frames and automatic transmission of acknowledge frames.
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.
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.
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. . . 21.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?. . . 72.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
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 flow. . . 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 . . . 326.2 Verification 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.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
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
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 (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 profile 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.
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
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.
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])
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 propro-tocol 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
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.
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 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 NetNet-work 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
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.
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.
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
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
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).
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 writpartition-ing 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.
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
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.
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
Configuration Lowest value Highest 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 µ µ µ µ µ µ µ µ µ µ
Top level design
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.
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.
Design flow
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
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
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 acknowledge-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
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
Processor and system bus
Figure 5.3: Pipelined transfers on AMBA AHB
Control (n) Control (n+1)
Address (n)
Data (n) Address (n+1)
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 multiplexbuff-ers 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
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])
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.
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
Verification with ModelSim
tool and thourough testing in a programmable circuit like a FPGA (field programmable array).
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.
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
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.
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.
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
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.
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
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'.
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
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.
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 SAPHWIF 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.
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.
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
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 taken 0x54
NAV_temp 0x58 Incoming value
Table B.1: Registers externally accessable
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
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
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
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
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
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
