The remainder of this thesis is organized as follows. In chapter 2, we describe the related
works and design concepts in our design. The virtual socket concept for packet transmission
in downlink and uplink are illustrated. In chapter 3, we illustrate the design process step by
step. Besides we demonstrate the heterogeneous simulation at electronic system level. A
hardware modeling technology is adopted in our design and we present the simulation
performance will be improved by hardware modeling technology. In chapter 4, we conclude
with a summary of contributions and suggestions for future works.
Chapter 2
Related Work
In this chapter, we explain some related works and design concepts about our design. In
order to explain why we implement our behavior model on ARM-based platform at electronic
system level, we discuss the SoC design and verification issues in section 2.1. The MAC
functions that are relative to our behavior model are explored in section 2.2. Different design
and verification languages are used for different purposes at different abstraction levels. In
section 2.3 the hardware modeling technology is discussed and SystemC language for
developing the hardware model in our design is introduced. In the section 2.4, the
platform-based design concept is explored and the actual implementation is demonstrated. In
the section 2.5, we propose a virtual socket concept for the packet transmission. We explain
the concept and the behavior of this model. Finally we make a summary of this chapter in
section 2.6.
2.1 SoC Design and Verification Issue
As the semiconductor industry continues to drive toward more advanced manufacturing
technologies, all design companies face shrinking product lifecycles and rising demand for
greater functionality. Moore’s Law is the empirical observation made in 1965 that the number
of transistors on an integrated circuit for minimum component cost doubles every 18 months,
as shown in Figure 4.[23] Due to the scale down of the transistor, the capacity in each device
is increasing.
Figure 4 Moore’s Law.
We understand that the progress of semiconductor technology brings more silicon
complexity. It means the growth of silicon complexity is much more than the designer’s
productivity. Therefore the productivity gap between integration capacity and design
complexity becomes worse as shown in Figure 5. In the SoC design, many design flows and
design methodologies are proposed to close the productivity gap like the platform-based
design and electronic system level design. We adopt both two design methodologies for our
development. We use the top-down design flow to design our communication system.
Figure 5 Productivity Gap.
2.2 The WiMAX System Functional Block
In this subsection, we disclose the basic functions of WiMAX system. The MAC
management message generator is responsible to generate the corresponding message types in
specific communication situations. The cyclic redundancy check is responsible for error
detection, and the automatic repeat request is responsible for error correction. In order to
support mobile user, the handover function must decide to link with a new base station and
disconnect with the current base station at proper moment. The scheduler is in charge of the
QoS control. Ranging and initialization is responsible for keeping the radio link working, like
synchronization, power control, etc. Packing, fragmentation, concatenation is responsible for
the transmission efficiency by constructing different packet sizes. Bandwidth allocation is
responsible for allocating the proper bandwidth when the subscribers request for bandwidths.
The breakdown of MAC functionality is shown in Figure 6. Detailed definition for each
related function is described in the following section.
Figure 6 Breakdown of MAC Functionality.
2.2.1 MAC Management Message
A MAC protocol data unit (PDU) consists of a fixed length header, a variable length
payload and an optional field for cyclic redundancy check (CRC). The format of the
management message is given in Figure 7.
Figure 7 Format of MAC PDU.
A set of MAC management messages is defined. These messages shall be carried in the
payload of MAC PDU. All MAC management messages begin with a management message
type field and may contain additional fields. MAC management messages on the basic,
broadcast, and initial ranging connections shall neither be fragmented nor packed. MAC
management messages on the primary management connection may be packed and/or
fragmented. For the SCa, OFDM, and OFDMA PHY layers, management messages carried
on the initial ranging, broadcast, basic, and primary management connections shall have CRC
usage enabled. The encoding of the management message type field is given in Figure 8 and
Figure 9. [1]
Figure 8 MAC Management Message Table I.
Figure 9 MAC Management Message Table II.
2.2.2 Header and Subheader
Two MAC header format are defined. The first is the generic MAC header that begins each
MAC PDU containing either MAC management messages or data from the upper layer. The
second is the bandwidth request header used to request additional bandwidth. The single-bit
Header Type (HT) field distinguishes the generic MAC header and bandwidth request header
formats. The HT field shall be set to zero for the Generic Header and one for a bandwidth
request header. The Figure 10 shows the format of MAC general header.[1]
Figure 10 MAC General Header.
The second is the bandwidth request header used request additional bandwidth. It is used
by the subscriber station to request more bandwidth on the uplink. The Bandwidth Request
PDU shall consist of bandwidth request header alone and shall not contain a payload. The
Figure 11 shows the format of the MAC bandwidth request header.[1]
Figure 11 MAC Bandwidth Request Header.
There are five types of subheaders. The subheaders may be inserted in MAC PDUs
immediately following the generic MAC header. The definition of the type field is indicated
in Figure 12. The grant management subheader is used to convey bandwidth management
needs to the BS. The fragmentation subheader indicates the presence and orientation of
service data units (SDU) in the payload. The packing subheader indicates the packing of
multiple SDUs into signal PDU. If both the fragmentation subheader and grant management
subheader are indicated, the grant management subheader shall come first. The packing and
fragmentation subheaders are mutually exclusive and shall not both be present within the
same MAC PDU. The mesh subheader is only necessary for mesh network. All the
subheaders included the mesh subheader are within payload. If the mesh subheader is
indicated, it shall precede all other subheaders. The fast-feedback allocation subheader shall
always appear as the last per-PDU subheader. This is used to tell the PHY layer to provide an
immediate measurement of the quality of the radio signal.[1]
Figure 12 Types of Subheaders.
2.2.3 Automatic Repeat Request
The ARQ mechanism is a part of MAC, which is optional for implementation. When
implemented, ARQ may be enabled on a per-connection basis. The per-connection ARQ shall
be specified and negotiated during connection creation. A connection cannot have a mixture
of ARQ and non-ARQ traffic. Similar to other properties of the MAC protocol the scope of a
specific instance of ARQ is limited to one unidirectional connection. For ARQ-enabled
connections, enabling of fragmentation is optional. When fragmentation is enabled, the
transmitter may partition each SDU into fragments for separate transmission based on the
value of the ARQ_BLOCK_SIZE parameter. When fragmentation is not enabled, the
connection shall be managed as if fragmentation was enabled. In this case, regardless of the
negotiated block size, each fragment formed for transmission shall contain all the blocks of
data associated with the parent SDU. The ARQ feedback information can be sent as a
standalone MAC management message on the appropriate basic management connection, or
piggybacked on an existing connection. ARQ feedback cannot be fragmented.[1]
2.2.4 Cyclic Redundancy Check
The cyclic redundancy check (CRC) is a way to detect small changes in blocks of data.
Error detection is especially important when the control messages are transmitted or data are
stored, because an error of even one bit is often sufficient to make a system shutdown. An
error correction protocol triggered by CRC error detection can provide this accuracy at low
cost.
The CRC algorithm operates on a block of data as a unit. We can understand the CRC
better if we see a block of data as a single numerical value. The CRC algorithm divides this
large value by a magic number (the CRC polynomial or generator polynomial), leaving the
remainder, which is our CRC result.
The CRC result can be sent or stored along with the original data. According to the format
of PDU, we attach the CRC result to the tailor of payload. When the data is received, the CRC
algorithm can be reapplied, and the latest result compared to the original result. If any error
has occurred, we will probably get a different CRC result. Most uses of CRC do not attempt
to classify or locate the error, but simply arrange to repeat the data operation until no errors
are detected.
2.3 Design and Verification Language
Different design languages are used for different abstraction levels. The higher abstraction
level is suitable for algorithm development. On the other hand, the lower abstraction level is
suitable for modeling the actual hardware behavior. From the Figure 13, we find four different
design languages. Different design languages are for different purposes. The Matlab is a
powerful mathematic tool and it is used to model the complicated mathematic issues or
advanced algorithms. The hardware description language (HDL) like VHDL or Verilog is
used to model the real hardware behavior and evaluate the physical information like timing,
area, and power.
Figure 13 Different Levels of Abstraction.
In our implementation, we adopt C language and SystemC language to construct our
behavior model. C language is most popular language in the world and supported by various
compliers. It can be ported from one platform to another platform easily, so C language is
suitable for embedded system design. SystemC provides a unified environment for architects,
verification engineers and implementation engineers. In the following two subsections, we
explore the hardware modeling technology and introduce SystemC language. Our purpose is
to implement the behavior model at electronic system level and execute the heterogeneous
simulation, so both C language and SystemC language are necessary for the development of
our model.
2.3.1 Hardware Modeling
In the early 1980s, the logic of integrated circuits was designed via gate level drawing. The
appearance of the first IEEE HDL standard was in 1987. The hardware description languages
are meant to provide a unified notation for describing electronic systems at register transfer
level. In RTL design, a circuit behavior is defined in terms of the flow of signals or the
transfer of data between registers so the design efficiency is better than the gate level design.
SystemC was announced in 1999. It is a much higher level of abstraction than writing
hardware description language at register transfer level.
There are many differences between traditional and modern design processes. The main
advantage in the modern process is to enable both software and hardware development
concurrently. In order to start the software development and verification prior to the hardware
is completed, a hardware model becomes essential. The hardware modeling technology not
only shortens the SoC development schedule but also improves the simulation performance at
electronic system level platform. In our behavior model, we compare the performance
between the pure software version and the new version with hardware modeling. After the
simulation, we prove the hardware CRC module can improve the simulation performance.
2.3.2 SystemC
The first version of SystemC was released in September 1999. Early development was done
by Synopsys, UC Irvine and CoWare. The Open SystemC Initiative (OSCI) was founded in
2000. SystemC becomes one IEEE standard in 2005.
As a standard, SystemC could possibly enable and accelerate the exchange of system level
intellectual property (IP) models and executable specifications using a common C-based
modeling platform. SystemC provides a single language to define hardware and software
components, to facilitate hardware/software co-simulation, and to facilitate step by step
refinement of a system design down to the register transfer level for synthesis.
Replacing the traditional hardware description language (DHL) with SystemC minimizes
the communication overheads involved in current system design flow, deceases simulation
time and thus speeds up the design process.[12]
The advantages of SystemC as a system level design level design language are [13]
[14][15]. The first is it enables modeling of systems above the RTL level of abstraction –
including systems that might be implemented in hardware, software or a combination of both.
The second is SystemC promotes reuse of the developed components from one system to
another with minimum efforts. The third is SystemC offers good design space exploration of
functional specification and architectural implementation alternatives. The Figure 14 shows
the architecture of SystemC language.[24]
Figure 14 SystemC Language Architecture.
2.4 Platform-based Design
Our behavior model is implemented according to the platform-based design methodology.
Platform-based design is a powerful concept for releasing the increased pressure on
time-to-market, design and manufacturing costs. The modern SoC design flow increases the
productivity of each engineer. Usually the engineers just change few functions in the former
design to create a new one. Most design effort is reused and shared in the following projects.
The engineers will reuse the components like the ARM processor, the memory, and some
peripheral modules. As shown in Figure 15, the AMBA interface and protocol enable the
designer to develop the SoC system by assembling essential IPs. The platform-based design
concept is adopted by our design methodology. In the following subsections, we will
introduce the features of AMBA, the interaction of hardware and software, and the memory
mapping concept for accessing declared registers.
Figure 15 The Platform-based Design.
2.4.1 AMBA
The AMBA protocol is an open standard, on-chip bus specification that details a strategy
for the interconnection and management of functional blocks that makes up a System-on-Chip
(SoC). The AMBA protocol enhances a reusable design methodology by defining a common
backbone for SoC modules.
There are three different buses in the AMBA specification: AHB, ASB and APB. AHB
stands for Advanced High-performance Bus. AHB is a new generation of AMBA bus which
is intended to address the requirements of high-performance synthesizable designs. It is a
high-performance system bus that supports multiple bus masters and provides high-bandwidth
operation. ASB stands for Advanced System Bus. This is an older version has been replaced
by AHB. APB stands for Advanced Peripheral Bus. It is a simple lower performance and low
power bus used for low speed peripherals. The APB is optimized for minimal power
consumption and reduced interface complexity. The macrocells designed to interface with
AMBA can be seen as building blocks which can be reused in future designs and mixed and
matched in different combinations to realize complex systems in a shorter period of time. The
AMBA architecture is shown as Figure 16.[22]
Figure 16 The AMBA Architecture.
2.4.2 The HW/SW Interaction
Hardware/software interaction plays an important role in co-design of the embedded system.
It connects the software part and the hardware part in a system. There are two main
approaches for hardware/software interaction: Polling and Interrupt.
Polling the device usually means reading its status register so often until the device's status
changes to indicate that it has completed the request. Interrupt is a signal from a device
attached to a processor or from a program within the processor that causes the main program
that operates the system to stop and figure out what to do next. An interrupt can be generated
by one of two sources: software interrupt and hardware interrupt. The interrupt signals
initiated by programs are called software interrupt. An interrupt also can be generated by an
external device. These are called hardware interrupts. When a program receives an interrupt
signal, it takes a specified action. Interrupt signals can cause a program to suspend itself
temporarily to service the interrupt.
Figure 17 Interaction between Hardware and Software.
The behavior of the interrupt and the actual layout is shown in the Figure 17. The
interaction between our hardware module and ARM processor is hardware interrupt. This is a
more effective approach than polling. After the unprocessed data is moved into the input
buffer, the CRC module is enabled by software with the CRC_enable signal. Then the CRC
hardware module will start to process the data and return the CRC result. After the CRC
hardware finishing it job, the hardware module will inform the ARM core to fetch the CRC
result from the output buffer by using the interrupt signal. In the embedded system design, the
interrupt signal is connected to an interrupt control IC. Then the IC will inform the CUP that a
hardware module and jumps to the address of the service routine and deal with the process.
2.4.3 Hardware Registers
In embedded system design, hardware registers compose a storage area for control signals
and data.Hardware registers are contained within a certain peripheral unit. Usually we divide
the hardware registers into three types -- control registers, status registers, and data buffers. A
status register is a collection of bits for a processor that indicates the status of various specific
operations. When a status register is read, it will report the state of the peripheral device.
When a control register is written, it will change the state of the peripheral device. The data
buffers usually storage the raw data for processing and the output data for accessing. Registers
is costly, so the registers will not be used unlimited.
2.4.4 Memory Mapping
Memory mapping is a process that a digital hardware is connected to a processor’s address
bus and data bus. In this way, the component can be accessed exactly as if it were a memory
cell. To a processor, everything is memory. The memory mapping is to define the address of
the I/O registers in the memory table so the embedded processor can exactly access the
specific registers. Memory-mapped I/O (MMIO) and port-mapped I/O (PMIO) are two
complementary methods of performing input/output between the CPU and I/O devices in an
embedded system. In our implementation, we use the memory-mapped I/O methodology.
Memory-mapped I/O uses the same bus to address both memory and I/O devices, and the
same CPU instructions are used to access both memory and I/O devices. The I/O devices
monitor the CPU's address bus and map the address to their hardware registers. The Figure 18
shows the memory map in our implementation.
Figure 18 Memory Map.
2.5 Virtual Socket Concept
A socket is one end-point of a two-way communication link between two programs running
on the network. Socket classes are used to represent the connection between a client program
and a server program. In our simulation platform, we don’t have the socket API for
communication, so we propose the virtual socket concept for our simulation platform. In the
simulation platform, we use share memory as the transmission medium. Besides we define an
arbiter, some control flags, and a finite state machine for synchronizing the data transmission.
2.5.1 Simulation Platform and Architecture
SoC Designer is a system level simulation tool supporting the hardware modeling in
SystemC. New SystemC components can be created using the SoC Designer Component
Wizard. For legacy SystemC TLM model reuse, existing SystemC models can be imported
into SoC Designer with little or no modifications to the original source code. There are two
into SoC Designer with little or no modifications to the original source code. There are two