Chapter 2 Related Work 7
2.6 Summary
In this chapter, we introduce the design concepts for our behavior model. In the section 2.1,
we discuss the SoC design and verification issues. In the section 2.2, we identify some
subfunctions which are relative to our implementation. In the section 2.3, we explore the
abstraction level of our implementation and choose the proper design language to model our
design. In the section 2.4, we illustrate the concept of platform-based design, the embedded
system design and the details for hardware modeling. In the section 2.5, we introduce the
simulation tool and we propose a virtual socket for the data transmission.
Chapter 3
Case Study:A Behavior Model Design
The related work about our implementation is described in the previous chapter. In this
chapter, we describe the development of our behavior model and demonstrate the simulation
result. In the beginning, we develop and verify our reference software and applications in C
language on the personal computer environment. Then we port our C model to the ESL
platform and verify the functionality of the traffic behavior, the error detection behavior, and
the error correction behavior. Further, we implement a hardware module for
hardware/software co-simulation platform. We modify the firmware to define the interaction
between the hardware module and the processor.
3.1 Our Design Flow for Behavior Model
We implement our behavior model in C code according to the IEEE 802.16 specification.
The specification describes the MAC functionality in English. When we study the meanings
of these functionalities, we have to turn these descriptions from the nature language into
executable code in C language. The executable specification not only avoids the ambiguous
meaning in nature language but also provides the quantitative analysis in engineering
applications. After verifying on PC, we use the ADS (ARM Developer Suite) tool to generate
the image file and download to the SoC Designer for simulation. Then we design a hardware
module for CRC function and compare the simulation performance with the pure software
verison. The Figure 21 shows the design flow and the development environments for our
behavior model.
Figure 21 Design Flow for Behavior Model
3.1.1 Reference Software Development
The basic function of our behavior model is to provide data integrity during the
transmission. There are three subsystems are built in our implementation – the BS module, the
MS module, and the Channel module. The transmission side generates the transmitted packets
based on the proper format and generates the CRC result for the error detection. The channel
models the behavior of channel fading and changes the value in the RX buffer. The channel
also acts like the arbiter to schedule the TX/RX behavior by changing the control flags and
the state of finite state machine. The received side generates the CRC result again and
compares the CRC value to confirm the completeness of received packet. According to the
comparison, the receiver generates the ACK message to inform the transmitter to transmit the
next packet or retransmit the original one.
Figure 22 The Function for Error Detection and ARQ Frame Generation.
Some control flags and data buffers are used in the transmission behavior, most of the
details are not declared in the specification, so we have to prototype and verify the error
detection function and the retransmission scheme on the PC platform as shown in Figure 22.
Furthermore we implement a basic protocol for TX/RX transmission. Stop and wait
transmission is the simplest reliability technique and is adequate to a very simple
communications environment. A stop and wait protocol transmits a Protocol Data Unit (PDU)
of information and then waits for a response. The receiver receives each PDU and sends an
acknowledgement (ACK) PDU if a data PDU is received correctly, and a negative
acknowledgement (NACK) PDU if the data was not received correctly. The Figure 23 shows
the behavior of transmission.
Figure 23 The System Approximation on PC Platform.
3.1.2 Simulation on ADS and ESL Platform
When we verify the communication system, we need to create the environment for
communication under the conditions that no physical layer and no socket API are existed. We
establish the logic architecture, which is shown in the Figure 24. We divide our C model to
three subsystems – the BS module, the MS module, and the Channel model.
The design concept of the communication system is different from the other systems like
various multi-media decoders. Communication systems must communicate with the other
members in the wireless environment. Usually it is hard to build the whole system and verify
the protocol in the beginning. In our simulation platform, the SoC designer supports the
multi-core simulation. It means different programs can be executed concurrently on this
platform. We take advantage of the simulation platform and construct a logic system on it
including the base station, the subscriber station, and the channel model to verify the
downlink and uplink traffic.
When developing exactable codes for three ARM processors, we use ARM Developer Suite
(ADS) to generate the three image files. After passing the debugging in the ARM compiler,
linker, and utility programs proved by ADS, we load the image codes to three subsystems on
the SoC Designer platform.
Figure 24 The Logic and Physical System Architecture.
3.1.3 System Level Simulation with Pure Software
The Figure 25 shows the functional verification on the ESL platform. The simulation
demonstrates the interaction between the base station and the subscriber station on the
downlink traffic and the uplink traffic. The simulation also demonstrates the error model to
replace the real wireless channel because there are no physical connection and actual medium.
This simulation also demonstrates the error detection and error correction function in a
wireless environment for supporting data integrity.
Figure 25 The Functional Verification.
3.2 Our Design Flow for Hardware Modeling
In this section we explore our design flow for hardware modeling. The design process
includes the interface design, I/O register design, behavior model coding, and firmware
coding. The Figure 26 shows the design flow and the development environments for our
hardware modeling. In the research [16] [18] indicate the framing function, ARQ function, the
encryption function, and the CRC function are timing critical and large overhead. Among
these functions of MAC, we choose the CRC function as an example for hardware modeling.
Figure 26 Design Flow for Hardware Modeling
3.2.1 Interface Design
There are three main interfaces in our hardware module. One is the AMBA for transferring
the transmitted packet and fetching the CRC result. Another is the interrupt signal for
indicating the processor that the CRC result is ready. The third is the input pin of clock cycle.
The appearance of CRC module is shown in Figure 27 below.
Figure 27 Interface Design
3.2.2 Input/Output Register Design
Within the hardware module we define input registers, output registers, and data buffers.
The CRC_enable, BytesOffset, and Input_Buffer are input ports. The CRC_done and
CRC_result are the output ports. The processor moves the unprocessed data to the
Input_Buffer and defines the length of unprocessed data by setting the CRC_length. The
processor enables CRC hardware module by setting the CRC_enable equal to “high”. After
calculating, the CRC result will be written into the Output_Buffer. Then CRC_done register
will be set to “high” and this signal is wired to the processor for informing the processor that
the CRC value is ready. The architecture is shown as Figure 28.
Figure 28 I/O Register Design
3.2.3 Behavior Model Coding
New SystemC components can be created by using the SoC Designer Component Wizard.
We use a SoC Designer component as a top level wrapper to instantiate the modules as
sub-components. The component wizard will generate the following files: A cpp/h file for the
SoC Designer component, a cpp/h file for each slave port, and a cpp/h file MxDI if
selected.[20] The newly generated SoC Designer component does not contain any behavior
and we have to construct the CRC function in Visual C++ environment. Then we generate a
library with correct behavior. The design is based on the SystemC language. It can facilitate
the design speed of our hardware module.
3.2.4 Import to the ARM-based Platform
We imported the SystemC component and connected the interfaces properly to the ralative
SoC Designer modules. In general, ports and channels of imported SystemC modules are
based on user-defined SystemC interfaces. We drag the CRC module from the component
window and connect the module to the AMBA bus and the interrupt controller.
3.2.5 System Level Simulation with Hardware Modeling
After we establish the SystemC model, we can fast prototype the hardware model in
SystemC at higher abstraction level. This is good for designers to verify the system
functionality concurrently by both the hardware side and the software side. This also can
reduce the rework penalty and the delay in a rush schedule.
As the Figure 29 shown, the simulation result demonstrates the hardware/software
heterogeneous simulation on SoC Designer platform. The completed module can be defined
as a library, and this design can be reused and redesign in the future.
Figure 29 The SoC Designer Co-simulation Environment.
3.3 Simulation Result and Application
There are two purposes for the hardware/software co-simulation. The first is we want to
guarantee that the hardware module behavior is correct. The second is we want to improve the
simulation performance at electronic system level.
3.3.1 Hardware/Software Co-verification
In this subsection, we demonstrate the functional verification of hardware and software
in an electronic system level platform. The function of our behavior model provides a virtual
socket for packet transmission and guarantees the data integrity in a channel with an error
model. The behavior model is implemented on the ARM-based platform. It can be used to
design the other embedded communication systems. Due to the higher abstraction level, the
simulation overhead is less than the register transfer level. Furthermore, the simulation
platform supports the hardware/software co-verification. We turn the CRC function into
hardware module in SystemC language. Hardware/software co-verification is to make sure the
embedded software works correctly with the hardware parts. The design methodology
accelerates the firmware debugging. Early debugging also reduces the risk of redesign.
3.3.2 Simulation Model and Simulation Result
In this subsection, we use three simulation models to compare the simulation performance.
We want to calculate the clock cycle of the software function and hardware module based on
different packet sizes. There are three simulation models - the model with no CRC function,
the model with software CRC function, and the model with hardware CRC module. The
Figure 30 shows the clock cycles of three simulation models in three different packet sizes.
Figure 30 The Clock Cycles of Three Simulation Models in Different Packet Sizes
The Figure 31 shows the comparison of simulation result. We obtain the clock cycle for
software function and hardware module in different transmitted packet sizes. The simulation
result explains the improvement of the overall system performance in heavy traffic data. The
simulation shows that there are 1.6% and 11.7% improvements by setting the packet size in
100bits and 1000bits respectively.
The processed data is transferred between software and hardware through the AMBA bus.
The bus transaction is an overhead for system simulation. For the small packet size, the
simulation result of hardware version is worst because the extra overhead in bus transaction is
larger than the processing gain of hardware component. For the large packet size, the
transaction is smaller than the processing gain of hardware component. The packet size in
100bits is an approximate threshold in our behavior model for using the CRC accelerator.
3.4 Summary
In this chapter, we illustrate our implementation process and demonstrate our simulation
results. In the section 3.1, we explore our design flow for our behavior model and finish the
system level simulation. In the section 3.2, we explore our design flow for hardware modeling
and finish the heterogeneous simulation. In the section 3.3, we have a comparison between the
pure software version and the other version with hardware accelerator model. The design
methodology and platform can be used to verify different communication scenarios. By using
this platform, a behavior model with the error detection and error correction function is
demonstrated in this chapter. The simulation result shows our hardware accelerator can
improve the simulation performance for this platform.
Chapter 4
Conclusions and Future Work
This thesis presents an implementation of our behavior model on an electronic system level
simulation platform to enable the data transmission. A virtual socket concept is proposed to
deal with the packet transmission. We implement our behavior model at the electronic system
level simulation platform, which provides three purposes: system level design, system level
verification, and hardware/software co-design. The design concepts and design methodology
are exploded. This behavior model demonstrates the packet transmission between the
transmitter and the receiver and guarantees the data integrity. The behavior model also can be
used to verify the different communication scenarios.
The heterogeneous simulation improves the efficiency of the system simulation. The
hardware module is become a library that can be reuse for the other designs. Finally, we
demonstrate the heterogeneous simulation at electronic system level and improve the efficient
for the system simulation.
For the further improvement of our behavior model, the hardware module can be realized in
the register transfer level and obtain the time, area, and power information.
Bibliography
[1] IEEE 802.16.IEEE Standard for Local and Metropolitan Area Networks-Part 16.Air Interface for Fixed Broadband Wireless Access Systems-2004.
[2] A. Ghosh et al., “Broadband Wireless Access with WiMAX/802.16:Current Performance Benchmarks and Future Potential”, IEEE Communications Magazine, vol.43, no.2, pp.
129-136, 2005.
[3] Thorsten Grotker, Stan Liao, Grant Martin and Stuart Swan, System Design with SystemC, Kluwer Academic Publisher, 2002.
[4] M. Keating and P. Bricaudr, Reuse Methodology Manual for System-On-A-Chip Designs, Kluwer Academic Publishers, 2002.
[5] Steve Furber, ARM System-on-Chip Architecture second edition, ADDISON WESLEY, 2000.
[6] Takayuki Tachikawa and Makoto Takizawa, “ARQ Protocols for Bi-directional Data Transmission”, International Conference on Information Networking (ICOIN-12), Tokyo, Japan, pp.468-473, 1998.
[7] Tim Hopes, “Hardware/Software Co-verification, an IP Vendors Viewpoint”, Proceedings of the International Conference on Computer Design (ICCD), Austin, TX, USA, pp.242-246, 1998.
[8] Jing-Yang Chou, “Special Topics in Computer Aided Design”.
[9] Theo A.C.M Claasen, “An Industry Perspective on Current and Future State of the Art in System-on-Chip (SoC) Technology ” Proceedings of the IEEE, Vol. 94, No. 6, pp.
1121-1137, 2006.
[10] ARM Limited, “The Software Development Toolkit”, version 2.50, pp. 370, 1998.
[11] Ray Turner, “System Level Verification – a Comparison of Approaches”, Proceedings of the 10th IEEE International Workshop on Rapid System Prototyping, Clearwater, FL, USA, pp154-159, 1999.
[12] Joanne DeGroat, Arun Raman, Bakr Younis, “A Design Project for System Design with SystemC”, Proceedings of the IEEE International Conference on Microelectronic Systems Education, Anaheim, CA, USA, pp108-109, 2003.
[13] Liao, S. Y., “Towards a New Standard for System-Level Design”, Proceedings of the Eighth International Workshop on Hardware/Software Co-design, San Diego, 2000.
[14] Open SystemC Initiative. See http://www.systemc.org
[15] J. Bhasker, A SystemC Primer, Star Galaxy Publishing, 2002.
[16] H. Holisaz, S. Shamshiri et al, “Hardware Accelerator IP-Core for Wireless 802.16 MAC”, IFIP International Conference on Wireless and Optical Communication Networks, Bangalore, India, 2006.
[17] Liangshan Ma and Dongyan Jia, “The Competition and Cooperation of WiMAX, WLAN and 3G”, 2nd Asia Pacific Conference on Mobile technology application and systems, Guangzhou, China, 2005.
[18] Nak Woon Sung, “HW/SW Codesigned Implementation of IEEE 802.16 TDMA MAC for the Subscriber Station”, Proceedings of the Fourth Annual ACIS International Conference on Computer and International Science, Jeju Island, South Korea, pp436-440, 2005.
[19] Jorg Henkel, “Closing the SoC Design Gap”, Computer, Volume 36, Issue 9, pp119-121, 2003.
[20] ARM Limited, “RealView SoC Designer SystemC-TML Import”, version 3.06, pp. 22, 2006.
[21] Collett International Research:2000, 2002 Functional Verification Studies.
[22] ARM Limited, “AMBA Specification (Rev 2.0)”, pp. 1-4, 1999.
[23] Gordon Moore, “Cramming more components onto integrated circuits”, Electron. Mag, vol.38, no.8, pp.114-117, 1965.
[24] Thorsten Grotler, Stan Liao, Grant Martin, Stuart Swan, System Design with SystemC, Kluwer Academic Publishers, 2002.
[25] International Technology Roadmap for Semiconductors, 2006 Update, Semiconductor Industry Association. Available from http://www.itrs.net/