Design of I2C Master Core with AHB Protocol for High Performance Interface

Abstract— This paper explains a block that communicates between processor and any IC. Generally, this
needs two different modules in between. But here, both are integrated as one to avoid external peripheral
usage. The incorporation of Inter-Integrated Circuit (IIC) master module in Advanced High Performance Bus
(AHB) protocol in order to merge the merits of both IIC and AHB in terms of performance and speed.
Considering these aspects, the functional coverage for the base master module (AHB) is obtained to be
100%. In terms of performance, with 2 phase cycle methodology, the data is obtained without any clash
and traffic.

Keywords—IIC, AHB

Project Type – FrontEnd

Software Used –Xilinx ISE

1
 CHAPTER 1

1.1. INTRODUCTION

Present day’s technology has reached a goal where an entire system can be implemented on a
single chip which is nothing but SOC (System On-chip). The communication between the processor
and IC is usually attained through external peripherals. This may have speed matching issues. The
idea is to avoid external peripherals in turn avoids extra power consumption and incorporate the
entire communication in one single chip.

AHB is itself high in performance and when it comes to IIC, it is specifically good in terms of speed
matching from GHz to MHz. When combined both, the communication between processor and the
integrated chip (IC) is made promising as a result of this. The designing part is done using System
Verilog and the simulation is done in EDA playground.

Inter integrated circuit (I2C) bus transport is a two determination lines framework convention viz.
serial information (SDA) and serial clock (SCL) signals. I2C transport has produced for passing the
data from one module to different modules on one common communication network. I2C can be
utilized for multi purposes to address by novel programmable address. I2C is communicating with
different gadgets in a module by testing the SDA above Nyquist rate On the opposite side AHB
2
giving interfaces to top of the line devices and here in the correspondence between these devices as
full duplex parallel correspondence. AHB is a large data transfer capacity and rapid protocol. AHB
is a less mind-boggling convention and good with any plan stream. In [1], I2C convention has been
discussed effortlessly with gadgets with no loss of information. Further, it gives rapid information
transfer. In [2], the information has been spared in registers with the assistance of I2C convention.
In [3] I2C convention gave on less demanding medium to correspondence between the gadgets as it
utilizes just two lines (SCL and SDA) for correspondence between the ace and slave. In [4], the
creators' exhibited that the address and the chip select flag select the I2C gadgets. In this outline
both chip select and address of the gadget are default to1 as configuration is for a particular slave
only. In[5]the creator shows how I2C ace controls transmits and gets information to and from the
slave with appropriate synchronization. Be that as it may, I2C serial convention to AHB parallel
convention for fast information change isn't yet revealed in the writing. In this paper, the
information transfer from I2C master to I2C slave, AHB master to AHB slave by utilizing
correspondence connect

A System-On-Chip (SoC) is a system on a single substrate that consists of different modules that communicate with
each other to achieve some specific task. State of the art SoCs are typical composed of various masters (e.g.
embedded microprocessors and DMA controllers) and several slaves (e.g. peripherals and hardware accelerators) all
interconnected through a bus or network on chip (NoC) structure. The module that initiates the transfer is formally
known as the master and a module that responds to the master’s requests is known as a slave module. The bus
transfers the data from the master to the slave and vice-versa. Figure 1 shows a typical SoC structure.
Integrating an entire system onto the same chip leads to reduced cost and lower power consumption.

3
 Master1 (CPU) Master2 (GPU)

On-chip Bus

Slave1 (HW Accelerator) Slave2 (HW Accelerator) Slave3 (Memory)

Figure 1: A simple example of System-on-Chip (SOC)

The main problem with these SoCs is that they require considerably more time and effort to design. Using traditional
low-level hardware description languages is slow and error-prone. Moreover, they are too slow to simulate the
entire system, which implies that the SoC needs to be verified

4
component by component. This might lead to overseeing errors at the interfaces between the different components
as well as important timing issues.
One approach to facilitate the design of these SoCs is to raise the level of VLSI design abstraction from RT-Level to
behavioral level. High-Level Synthesis (HLS) is a technique that converts untimed behavioral descriptions into
efficient RTL code making it easier and faster to design VLSI circuits. The main problem with HLS is that it is a
single component synthesis method. Thus, allowing only to synthesize individual components in the system. This
thesis aims at providing a way to allow the generation of complete systems at the behavioral level, thereby, enabling
a path to simulate complete SoCs.

1.1 THESIS MOTIVATION

The primary motivation of the thesis is to enable the generation of behavioral SoC quickly. With the complexity and
the size of SoC increasing with time, it can be very beneficial and will save time to have a tool that can quickly
generate the SoC in a way where the designer only has to worry about the functionality of individual components
that will form the part of SoC and not worry about the interconnect and bus protocol. This can substantially improve
the production time thereby reducing the time-to-market of the SoC design. This can also facilitate a faster changing
of the bus interface to some other bus type as per the design requirement as the individual components would be
completely independent of the bus.

1.2 THESIS CONTRIBUTION

This thesis makes the following contributions:

i. Developed a tool to automate the generation of SoC in synthesizable C following the

AMBA AHB bus specifications. In particular, two main types: AHB-Lite (only one master)
and regular AHB (any number of masters allowed).
ii. Generate a library of synthesizable bus APIs to read and write to the bus using single
data mode or bust mode.
iii. Performed extensive experiments to analyze the run-time of RTL and cycle-accurate
model by varying the number of masters/slaves in the system, varying the address/data
bit- width of the bus

5
 iv. Performed experiments to analyze the area consumption of the bus, area consumption
of master/slave interfaces and area consumption of the entire SoC by varying the
number of master/slave, varying the address/data bit-width of the bus

Chapter 2
Literature OVERVIEW

1. SOC LEVEL VERIFICATION USING SYSTEM VERILOG:

The SoC level verification of AMBA AHB interconnect matrix and I2C DUT is presented in this
paper. The verification environment has been developed and test cases have been implemented for
I2C DUT. The assertions and monitor are developed to check the functionality of Interconnect
matrix of multilayer AHB Lite. The whole verification is done using SystemVerilog hardware
description and verification language. The verification environment developed is reusable.
2. IMPLEMENTING COMMUNICATION BRIDGE BETWEEN I2C AND
AHB:

The group of function blocks in a design unit is called as module. Fundamentally, these modules are
should synchronize with each and different squares to share the information in a plan unit. The
modules are following a distinctive convention which is having diverse piece rate and baud rate of
information exchange. In this paper, entomb incorporated circuits (I2C) and progressed
microcontroller design transport (AMBA) conventions are considered. In AMBA convention, two
unique kinds of sub conventions are accessible viz. propelled fringe transport (APB) and propelled
superior transport (AHB) convention. The information in the plan unit is exchanged through I2C
convention to AHB convention utilizing slave. It is watched that the territory of APB and AHB are
2% separately. Further, it is seen that the rate change in deferral of AHB is 4.937ns when contrasted
with APB convention.

6
 3. ARM ADVANCED HIGH – PERFORMANCE BUS INTER
INTEGRATED CIRCUIT:

This paper implements is an novel approach to enable data transfer between two bus architectures,
AHB and I2C which have different functionalities and characteristics. The coding for this module is
designed in the Verilog HDL (IEEE Std 2001) and simulated in Model sim 10.1C. This module
includes both design and verification phases. The Communication is done with AHB as Master and
I2C as Slave, hence achieve error free data transfer between the two bus architectures. This
implementation includes one Master and two Slaves. It can further extended to many Slaves. It can
be used to read & write registers of the connected device, accessing low speed ADCs and DACs,
controlling LED & LCD displays.

4. FRONTEND DESIGN FLOW OF DIGITAL SUBSYSTEM:

Complexities in the chip designs are continuously increasing with the increase in the size of the
designs.
The integration of IP blocks into a design and managing the design is becoming more and
more challenging. Thus the semiconductor industry has began to embrace new design and reuse
methodologies to keep in pace with increased complexities of circuits. The predesigned and pre
verified blocks known as intellectual property are obtained from internal sources or third parties and
are integrated together into a single chip. This traditional process of integration is time consuming,
error prone and requires a lot of efforts from the designer. A large percentage of design errors
come from connectivity issues.
Component reuse, complex buses and input/output connections add challenges to the SoC
integration process. Intellectual Property reuse improves system on chip design productivity, helps
to meet design quality and time to market goals.
In this thesis a design methodology has been used which enables the IP reuse by using the standard
bus architectures such as AMBA bus protocol and IP-XACT standards which allow the extensive
reuse of designs and ease the process of design integration. The IPs are packaged into IP-XACT
standard .XML files. The packaging extracts the metadata of designs and makes the design easy to
use in different tools flow. The IPs are then integrated together to make a subsystem. A subsystem,

7
Hardware Security Module has been implemented by using this methodology in the design
flow. This use of these standards significantly reduced the design time.
5. DESIGN AND IMPLEMENTATION OF HIGH PERFORMANCE MASTER/
SLAVE MEMORY CONTROLLER WITH MICROCONTROLLER BUS
ARCHITECTURE:

The on-chip interconnection system known as advanced microcontroller bus architecture (AMBA)
is a well-established open specification for the proper management of functional blocks comprising
system-on-chips (SOCs). In the subject paper, the design and implementation details of AMBA
high-performance bus (AHB) master and slave with memory controller (MC) interface are
discussed. A bridge between AHB master and slave with supportive application of MC is also
proposed and the resultant efficiency in respect of area overhead and speed is provided. The
realization of the control structure is based on the concept of conventional finite state machines
(FSMs). The intellectual property (IP) blocks of AHB master and slave are implemented on a Xilinx
Spartan3 field programmable gate array (FPGA) chip (3s50pq208-5).

6. IMPROVING MEMORY ACCESS TIME BY BUILDING AN AMBA

AHB COMPLAINT MEMORY CONTROLLER:

Memory access time has been a bottleneck in many microprocessor applications which limits the
system performance. Memory controller (MC) is designed and built to attacking this problem. The
memory controller is the part of the system that, well, controls the memory. The memory controller
is normally integrated into the system chipset. This paper shows how to build an Advanced
Microcontroller Bus Architecture (AMBA) compliant MC as an Advanced High-performance Bus
(AHB) slave. The MC is designed for system memory control with the main memory consisting of
SRAM and ROM. Additionally, the problems met in the design process are discussed and the
solutions are given in the paper.

8
 CHAPTER 3 ON-CHIP BUSES

3.1 INTRODUCTION
A bus is a communication system that transfers data between components (from Latin “omnibus”, meaning “for
all”).

Network on Chip

Bus Matrix
Hierarchical
Shared Bus
Custom
Time

1990 1995 2000 2005 2010

Figure 10: Evolution of on-chip buses

Custom (point-to-point connections): Before SoC technology, point-to-point connections for address/control and
data signals were used between components to enable communication between them. This led to many interconnect
wires on the board leading to a nightmare to back-end physical design engineers when the number of components in
the system increased. It also led to an increase in area and power consumption as these wires consumed a lot of area
and power. The dense network topology and scalability of the system became a major issue that led to the evolution
of SoC technology and the technique of shared buses.
Shared Bus: A shared bus allows several masters and slave devices that reside on the chip to communicate with each
other. At any given time, only one master can have ownership of the bus to guarantee mutual exclusion. To achieve
this, a shared bus includes an arbiter. An arbiter ensures that at any given time, only one master is having the
ownership of the bus. The advantages of a shared bus include its simple architecture, low area requirement, and easy
to build. The disadvantages of a shared bus include longer data transfer delay and lower bandwidth.

9
Hierarchical Bus: A hierarchical bus consists of several shared buses connected together. Individual components in
a hierarchical bus are connected such that lower performance components are connected to lower performance bus
and higher performance components are connected to higher performance bus. An example of hierarchical bus
architecture is AMBA bus architecture which has the AHB/ASB for high-performance components and APB for
lower performance components. The two buses are connected via an AHB to APB bridge. The conversion of
transactions from AHB to APB side leads to additional overhead and is one of the downsides of hierarchical bus
architecture. The other downside of such an architecture is that the design is slightly complex as compared to a
shared bus. On the other hand, since lower performance components can be placed on the lower performance bus
side, hierarchical bus architecture ensures that there is no unwanted additional load on the higher performance bus
side thereby improving the performance in terms of bandwidth and throughput.
Network-on-Chip (NoC): NoC is a network-based communication subsystem most typically between modules that
reside on the SOC. It is a router-based packet switching network between the modules in a SOC. NoCs improve the
scalability and power efficiency of complex SOCs compared to other communication subsystem designs. The wires
in the link of NoC are shared by many signals. This enables to achieve a high level of parallelism as all data links in
NoC can operate simultaneously on different data packets. Therefore, with an increase in the complexity of a SOC,
an NoC provides enhanced performance in terms of throughput and scalability as compared to previous
communication architectures like custom point-to-point signal wires, shared buses, or hierarchical buses with
bridges. GPU is an example that employs the technique of NoC to enable communication between cores that form a
part of the GPU. NoCs are an emerging technology with projections for large growth in the near future as many-core
computer architectures become more common.
The next few sections describe the AMBA family of buses.

3.2 AMBA BUS

Advanced Microcontroller Bus Architecture (AMBA) is an on-chip communication protocol. It is a freely- available,
open standard for connection and management of functional blocks in a system- on-chip (SoC). It is primarily
devised to support efficient on-chip communications among ARM

10
processor cores. It is one of the leading on-chip bus systems that is used on low-power SoCs like mobile devices.
AMBA is a hierarchical bus system and is made of two segments. Modules requiring higher performance are
connected on the higher performance bus whereas modules that do not require higher performance are connected on
the lower performance side of the bus. The two segments of the bus are connected via a bridge. AHB or ASB are
used for modules that require high performance whereas APB is used for peripherals that do not require higher
performance. The two segments of the bus are connected via a bridge known as an AHB-to-APB bridge.

Figure 11: AMBA based system architecture

An SoC primarily consists of multiple master modules, multiple slave modules, an arbiter, a decoder. Bus masters

are devices that control the sending of address and control signals e.g. whether it’s a read/write transfer along with
the address from where it wants to write or read from. Examples of bus masters include a high-performance
processor, DMA, Digital signal processor (DSP). A slave is a module that responds to the master’s request. E.g.
sending back the read data for a particular address that the master has requested or writing the data sent by the
master in case of a write transaction to its memory address. A slave in the case of AHB could be a high-bandwidth
memory module. A bus slave also sends an acknowledgment to the master signaling whether the transfer was
successful or not. An arbiter is needed in the case of a multiple master SoC. The role of an arbiter is to ensure that
only one master is owning the bus at any given point of time. The type of arbiter could be high-priority or round-
robin (fair access) depending on the application. A decoder is also a part of the system and is used to select the
appropriate slave to whom the transfer belongs to. It provides a select signal to the slave to whom the transfer
belongs to. The family of AMBA buses includes AXI, AHB, ASB, and APB.

11
3.2.1 Advanced High-Performance Bus (AHB)
AHB is a type of bus that is built mainly to support high performance, high clock frequency system modules. The
components for which an AHB bus is used include a high-performance processor, high bandwidth memory, and off-
chip external memory interfaces with low-power peripheral microcell functions. AHB bus is used to form
connections between a high-performance processor, high bandwidth memory, and off-chip external memory
interfaces with low-power peripheral macrocell functions. AHB supports include 8, 16, 32, 64, 128-bit transfer.
AHB is a high- performance bus and supports multiple masters and multiple slave devices and provides support to a
high-bandwidth operation. AHB uses pipelined signaling as opposed to latched address and control signaling that is
supported by low-performance bus like APB. The performance benefit of a bus like AHB that supports pipelined
operation is much higher as compared to a bus that only supports latched address and control operations. E.g. to
transfer two units of data, the least time AHB bus can take is just 3 cycles as compared to the APB bus which would
need at least 4 cycles. AHB also supports burst transfers and is another reason why it is considered as a high-
performance bus. It can support a burst of size 16 i.e. INCR16 or WRAP16. The advantage of a burst transfer to that
of a single transfer is that the master has to arbitrate for the bus just once and once it receives the ownership of the
bus from the arbiter, it can send the 16 units of data without having to re- arbitrate. Whereas in case of a bus that
only supports single transfer, to transfer 16 units of data, the master would need to arbitrate for the bus 16 times
which can drastically lower the performance of the system. AHB also supports split transactions which gives the
option of breaking the transfer in case a slave is not able to service the master on time. The idea behind this is to
give the bus to some other master rather than just hold on to the bus and do nothing. The slave keeps a note of the
master number with whom it split and then requests the arbiter to give the ownership of the bus to the same master
who had split so that the master can complete the remaining transfers of the burst. Features of AHB:
- High performance
- Pipelined operation (e.g. to transfer two units of data, the leas time it can take is just 3 cycles.
In case of a bus that is not pipelined e.g. APB, it would take 4 cycles because it always takes
two cycles to transfer data in case of an APB)

12
- Multiple bus masters
- Burst transfers
- Split transactions
3.2.2 Advanced System Bus (ASB)
ASB can be used as an alternate to AHB where the performance requirement is not high as AHB is considered to
consume more power because of the advanced features it supports as compared to ASB. Similar to AHB, ASB also
provides support high-performance system modules and connections between processors, on-chip memories, and
external peripherals. ASB can be used when high-performance of AHB is not required. Picking the type of bus
between the two i.e. AHB and ASB would depend on the type of bus. ASB provides support to 8, 16, 32-bit transfer
and similar to AHB uses pipelined signaling. Similar to AHB, ASB is also a high performance, supports pipelined
operation, multiple masters, and burst transfers.
Features of ASB:

- High performance
- Pipelined operation
- Burst transfers
- Multiple bus masters
3.2.3 Advanced Peripheral Bus (APB)
APB is primarily designed for low-power peripherals and is optimized for low power consumption and reduced
interface complexity to support peripheral functions. APB is used in conjunction with either AHB or ASB. AHB or
ASB can be used to connect high-performance modules like connecting the processor to memory and APB can be
used to connect peripheral devices in the SoC. The two buses i.e. AHB or ASB and APB are connected with a
bridge called AHB to APB bridge. APB is used for low bandwidth peripherals which do not require the high
performance of a pipelined bus transfer. APB supports latched address and control signaling as opposed to
AHB/ASB that supports the pipelined operation. A system that has AHB/ASB and APB also consists of an
AHB/ASB to APB bridge. This bridge converts the signals sent from the AHB side into the format compatible on
the APB side for the slaves that reside on the APB bus. e.g. if a master (processor) which is connected to the AHB
bus and sends signals as per the AHB protocol

13
wants to commute with a peripheral that is residing on the APB side. The signals that are sent from the master
(processor) which is in the AHB protocol format has to be converted to signals that are compatible with the APB
protocol. This requirement is taken care by the AHB-APB bridge. APB is a low power bus and has a simple
interface. It is suitable for many peripheral devices.
Features of APB:

- Latched address and control

- Simple interface
- Suitable for many peripherals
3.2.4 Advanced eXtensible Interface (AXI)
AXI is an advanced high-performance bus that provides support to modules with high-bandwidth and high clock
frequency requirements. AXI has much better scalability as compared to its predecessor as it has a point-to-point
network architecture as opposed to a shared bus in the case of its predecessor. Like AHB, AXI supports burst
operations and also supports out-of-order transfers which enhances the performance of AXI even further but also
makes it a bus that would consume more power. AXI has separate address/control and data channels and supports
bit-width of 8, 16, 32, 64, 128, 512, 1024. The separate address/control and data channels result in five channels
namely write address channel, write data channel, write response channel, read address channel, and read response
channel. Each of the transfers in AXI has a tag which acts as an ID for that transfer. This is how AXI supports the
out-of-order transfer feature. The read data for an address can be sent by the slave later using the ID of the transfer.
The ID that the slave sends with the read response is how the master can make-out for which transfer does this read
data belong to. As it supports out-of-order transactions, it permits address information to be issued ahead of the data
and supports multiple outstanding transactions. Additionally, AXI is good in terms of scalability as it does not use a
shared bus but a point-to-point interface.

14
3.3 COMPARING BUS TYPES
Table 2: Comparing features of AMBA AHB bus

AXI AHB ASB APB

Data-width Supports Supports Supports 8,16,32 Supports 8,16,32
8,16,32,64,128, 8,16,32,64,128
256,512,1024
Transfer Address/control Pipelined Pipelined Latch
operation and data phase operation operation address/control
separate and data
Burst operations Supports burst Supports burst Supports burst Does not support
transfer transfer transfer burst transfer
Out-of-order Supports out-of- Does not support Does not support Does not support
transactions order transaction out-of-order out-of-order out-of-order
transactions transactions transactions
Performance High performance High performance High performance Low performance
Channels 5 channels Single channel Single channel Single channel
Split transfer Allows masters to Supports split Does not support Does not support
send address and transfers split transfer split transfer
data separately.
Data for a
particular address
can be sent at a
later time using
the
transaction ID
Scalability Point-to-point Shared bus does Shared bus does Shared bus does
interface not scale well. not scale well. not scale well.
connections scales Scalability is Scalability is Scalability is
very well limited upto a limited upto a limited upto a
certain number of certain number of certain number of
master and slave master and slave master and slave
devices as the devices as the devices as the
performance drops performance drops performance drops

3.4 CONCLUSION
On-chip buses provide efficient communication medium for IPs to communicate with each other as compared to its
predecessor. They are efficient in terms of throughput, physical design, and power consumption. AMBA family of
buses are on-chip buses and provide support to both high- speed devices like processors, DMAs, GPUs as well as
low-speed peripheral devices like a keypad,

15
UART. AHB/ASB is typically used as a high-speed bus whereas APB is used to provide interconnection for low-
speed devices. The two buses are connected using an AHB/ASB to APB bridge. Scalability is a major downside of
shared buses and to counter this problem AMBA had introduced AXI. AXI provides point-to-point interface
connections between IP modules and scales well. NOC is another class of router-based communication medium that
scales very well and provides very good throughput. GPUs that houses many cores are known to use NOC as a
communication medium.

16
 CHAPTER 4 BEHAVIORAL SOC GENERATION

4.1 INTRODUCTION
The focus of the thesis is to enable the generation of behavioral SoC just by inputting a file with the details of the
system. The details of the system include information like the type of bus, the type of the arbiter in the bus, the
number of master/slave devices, the memory map of the slave devices, the address/data bit-width of the bus. The
tool developed would then generate a system using these details. The system developed by the tool would involve
the following modules namely the bus module, the master and slave interfaces, and an API file. The API file is a
library of synthesizable APIs that abstracts away the interconnect from the different components in the SoC. Using
the bus definition file, explained in detail in section 4.3, the system generates the bus module and the master and
slave interfaces. An API file is also generated which consists of the list of functions that are supported by the bus.
The designer of the system is only required to add the master mainframe module and the slave mainframe module as
part of the SoC with the desired functionality in it. The master mainframe module as part of its intended application
is required to use the APIs from the API file to send transactions to the slave via the bus. The master mainframe
module is connected to the master interface. The driving of the signals to the bus is done by the master interface by
generating the appropriate signals as per the bus protocol that is used. This allows the master mainframe module to
be completely independent of the bus interface and the protocol. Figure 13 shows a snapshot of the master
mainframe module illustrating the use of APIs. The SoC can then be created by encompassing all the required
modules in an entity called the top module which is a feature provided in the CWB tool. The top module connects all
the individual modules based on the signal names to form an SoC. Input and output signals which have the same
name are connected. A detailed description of the different components that are generated by the tool is presented in
section 4.4.

17
 Figure 12: Example of master mainframe module illustrating the use of APIs

4.2 ADVANTAGES OF PRESENTED WORK This

approach has some important advantages:
i. The automatic bus generator enables the generation of the entire SoC quickly. The
designer using the bus generator only needs to provide the details of the bus and the
interface through a bus definition file which is fed as an input to the Python script. The
designer does not have to worry about the bus interface or the bus protocol and is
required to only call the APIs to generate transactions.
ii. The bus generator enables the generation of quick cycle-accurate simulation models
that allows simulation of complete SoCs cycle-accurately. Experimental results of
different types of SoC configurations show that these simulation models are
substantially faster than systems described at the RT-level. This can help reduce a lot of
verification as a major part
18
 of verification is spent on running simulations which are known to consume a lot of time. This would in
turn enable faster time-to-market of the product.
iii. The bus generator allows to fully abstract away the bus interface from different
components making it very easy to change between different bus protocols.
iv. The bus generator allows to change the bus architecture including arbiter and bus bit-
width with minor modifications to the behavioral descriptions of the individual
components. This can save a lot of design time.

4.3 BUS DEFINITION FILE

The tool developed as part of the thesis takes as input a bus definition file. The bus definition file initiates the
generation of system components. It contains details like the bus type, the type of arbiter in case of a multi-master
system, the bus bit-width, the number of masters, the number of slaves along with the memory map of each of slave.
The developed tool parses this file to extract information of modules that needs to be generated. Using these details,
the developed tool generates a bus interconnect module, master and slave interface modules, and an API file.

Figure 13: Example of a bus definition file

19
Figure 13 shows an example of a bus definition file. One of the primary advantages of the tool is that it enables the
generation of a new system/architecture simply by changing the parameters in the bus definition file. For example,
by simply changing the arbiter type from round-robin to fixed- priority, a new bus with fixed-priority arbiter gets
generated.

4.4 SYSTEM ARCHITECTURE

To ensure the proper working of the behavioral SoC that gets generated automatically on running the developed
tool, experimentation was done by connecting the master mainframe module on the master interface side and slave
mainframe module on the slave side. The number of master and slave devices, the bit-width of the bus were varied
as part of testing and experimentation.

Figure 14: Architecture of the system

The master mainframe module consisted of an application

stheat would nd write and read
transactions to the slave via the bus. The master would first write data to the slave, the slave on receiving this data
would do some computation on the data. The master would keep on checking the slave’s status register to see if it is
done with the computation and once the slave is done with the computation, the master would send a read request to
read the data from the slave. This process was repeated for 300 iterations. In the case of multiple master and slave,
this operation was done by all the masters on all the slave devices.
The architecture of the SoC that was used for testing is as shown in Figure 14. It consists of an AMBA AHB bus
which acts as an interconnect between the master and the slave side. The AMBA AHB bus is connected to the
master interface on one side and the slave interface on the other side. The master interface is connected to master
mainframe module and the slave interface is connected to the slave mainframe module. The AHB bus generated
by the developed tool is of three types: AHB-Lite, AHB bus with fixed-priority as arbiter, AHB bus with round-
robin as arbiter.

20
AHB-Lite bus supports one master and up to 16 slave devices. It is ideal for systems that do not need multiple
masters. AHB bus with fixed-priority/round-robin arbiter supports multiple masters.

4.5 SOC COMPONENTS

4.5.1 Different types of bus supported by the system
The different types of buses supported by the system developed as part of the thesis include AMBA AHB-Lite,
AHB bus with fixed-priority as arbiter, AHB bus with round-robin as arbiter.

4.5.1.1 AMBA AHB-Lite bus

Figure 15: SOC with AMBA AHB-Lite as the bus

Figure 15 shows a system with AHB-Lite as the bus and consists of one master and three slave devices. AHB-Lite is
a type of AHB bus which is required to have exactly one master and up to sixteen slave devices. It consists of a
decoder logic to activate the appropriate slaves HSEL signal based on the address that is sent by the master. The
decoder logic is also used to forward the appropriate slave’s read data to the master. Of all the slaves read data, the
decoder logic uses the appropriate slave’s read data and sends that to the master. This is done based on the address
that

21
was sent by the master. If the address that was sent by the master belonged to slave# 1 during a read transaction then
out of all the slaves in the system, slave# 1’s read data is sent to the master. In case of a write transaction, the
address and control signals are sent from the master side to the bus. The decoder, that resides inside the bus, on
receiving the address signal from the master activates the appropriate slaves HSEL signal based on the address it has
received. E.g. if the address sent by the master falls in the range of slave# 2 then slave# 2’s HSEL signal is asserted
and all other slaves HSEL signal is set to 0. All the slaves use the HSEL signal, that gets driven from the bus, to
sample the address, control, and data signal that is sent from the master. The slave first checks to see if its HSEL
signal is high. If its high that means the address, control, and data signals that have been sent belongs to it. So, the
slave samples these signals. At any given time, only one HSEL signal is high.
In case of a read transaction, the slave whose HSEL has been activated sends the read data back to the master via the
bus for the address that has been sent from the master. The bus then forwards this read data to the master. Out of all
the read data that the bus receives at a time from all the slaves, the bus uses the HSEL signal of all the slaves and
AND’s these HSEL signal with the read data to send the read data of the slave that has been selected to the master.
The appropriate slaves HSEL signal is activated based on the address that was sent. If the address that was sent by
the master belongs to slave# 1 then slave# 1’s HSEL signal is set to 1 and every other slave’s HSEL signal is set to
0.
AMBA AHB Lite bus is a type of bus that supports strictly one master and can have multiple slave devices. For
systems that do not require multiple masters would benefit from this type of bus as the size of the bus is lower
compared to the other two types of buses. The reason for this reduction of size is the simplicity of the bus as
compared to the other two types of buses which houses an arbiter inside it. This simplicity of the bus as compared to
one that houses an arbiter would lead to a reduction in the area as well as a reduction in power consumption. It
would also increase the overall speed of the circuit due to the simplicity of the bus as it does not have to deal with
the initial part of arbitration that a bus which has an arbiter has to deal with. Since it does not have to go through the
arbitration logic, the overall speed of the circuit is faster as compared to the bus which has an arbiter in it.

22
 Figure 16: AMBA AHB-Lite Bus with input and output signals

4.5.1.2 AMBA AHB bus with Fixed-Priority as the Arbiter type

The role of an arbiter in a multi-master SoC system is to guarantee that at any given point of time only one master is
having access to the bus. This ensures that there is no contention amongst the masters for the bus. The arbiter
decides which master should get access to the bus based on the type of arbitration that has been used. So, at any
given point of time, only one master has ownership of the bus. The arbitration that is supported involves fixed-
priority and round-robin. AMBA AHB bus with fixed-priority as the arbiter supports multiple masters and multiple
slave devices. Fixed priority is a type of arbiter in which each of the participating masters has a fixed priority
associated with them.

23
 Figure 17: SoC with fixed-priority/round-robin as the arbiter for AMBA AHB bus

When multiple masters request the bus at the same time, the master with the highest priority is given access to the
bus. After a transfer is completed by a master that is owning the bus, the arbiter checks to see which all masters are
requesting access to the bus and grants master with the highest priority access to the bus. It is built on the idea that
the highest priority master should get the grant within the possible least amount of time.

24
 Figure 18: Input/output signals for AMBA AHB bus with fixed-priority/round-robin as the arbiter type

Note: Here, X in Master/Slave indicates the number as it supports multiple master/slave devices The advantage of
having a bus with fixed-priority arbiter is that the master with the highest priority only needs to wait the least
possible amount of time to get ownership of the bus. The master with the highest priority could be a master that is
handling some very critical applications like applying brakes in an automatic braking system (ABS) in a vehicle.
The downside of having a bus with fixed-priority as the arbiter type is that it can lead to starvation. It is possible that
a master with the least priority might never get a grant. This can arise when there is always one higher priority
master requesting for the bus when the least priority master is requesting.

4.5.1.3 AMBA AHB bus with Round-Robin as the Arbiter type

AMBA AHB bus with round-robin as the arbiter supports multiple masters and multiple slave devices. Round-Robin
is a type of arbiter in which the masters are circularly given access to the bus. This leads to a fair-access for the bus
to all the participating masters. A bus with this type of arbiter is also known as a bus with fair-access arbiter type.
After a master that is done accessing the bus, releases the bus, the arbiter checks to see which all masters are
requesting access to the

25
bus. The arbiter stores ID of all the masters that are requesting the bus in a queue. It then grants access to these
masters that have been stored in the queue serially. The arbiter iterates through the queue to give masters access to
the bus serially. The masters are given access to the bus until their transfer is complete. The highest number of
cycles a master can get access to the bus is 16 cycles. This is achieved by the bus keeping track of the number of
cycles a master has completed accessing the bus. It compares this with the masters HBURST signal which indicates
the number of cycles the master would require access to the bus. Once the master has completed its transaction, the
arbiter takes away the access of the bus from that master. If no masters are requesting access to the bus, the bus is
left idle and the arbiter keeps on checking every cycle if any master is requesting access to the bus. The advantage of
having a bus with round-robin as the arbiter type is that all the masters in the bus would benefit equally. There will
never be a case of starvation as all the masters are guaranteed access to the bus circularly or fairly.

4.5.2 Master interface

Figure 19: Master interface for AMBA AHB-Lite bus type

The master interface generates all the required AHB signals and drives the data into the bus. The master interface,
therefore, acts as an interface between the master mainframe module and the AMBA AHB bus. In an AMBA AHB
bus, the address and data get driven in an overlapped manner. This requirement of the protocol is achieved in the
master interface module. For a burst transfer

26
type, only the starting address of the transfer is sent from the master mainframe module. The remaining consecutive
addresses are generated by the master interface.
In case of a write transaction, the master interface sends the write data to the bus along with the address and control
signals. In the case of a read transaction, the master interface forwards the read data that it receives from the bus to
the master mainframe module. Similar to a write transaction, in a read transaction, the address and control signals
are sent from the master interface to the bus but the read data is sent from the bus to the master mainframe via the
master interface.

Figure 20: Master interface for AMBA AHB bus with fixed-priority/round-robin as the arbiter type

In case of AHB bus with fixed-priority or round-robin as the arbiter type, in addition to all the signals that are sent
by a master mainframe module with AMBA AHB-Lite as the system bus, the master mainframe module sends a
request to the master interface module to generate a request signal to the bus. On receiving a request from the master
mainframe module, the master interface sends a request to the bus. The master interface then waits for a grant from
the bus and on receiving a grant from the bus, notifies the master mainframe module about it. The master mainframe
module then sends the details of the transaction to the master interface. The master interface uses this

27
information to generate transactions as per the AHB protocol. This is how handshaking is achieved between the bus,
master interface, and master mainframe module.

4.5.3 Slave interface

The slave interface is a module that resides between the bus and the slave mainframe module. The role of a slave
interface is to transfer the address and write data from the bus to the slave mainframe module. It, therefore, acts as
an interface between the bus and the slave mainframe module. In the case of a read transaction, the slave interface
transfers the read data from the slave to the bus.

Figure 21: Slave interface for AMBA AHB bus

4.5.4 API file

The API file is part of the master mainframe module and consists of all the required functions that are called from
the master/slave mainframe module. The developer of the application is only required to call these functions from
the master mainframe module with the appropriate arguments. The API file needs to be included in the master/slave
mainframe module. The API file helps to abstract away the interconnect from the individual modules that form a
part of the SOC. The following functions are included in the AMBA AHB API file. In the case of a system with
fixed- priority or round-robin as the arbiter in the bus, handshaking for request and grant signal is performed at the
start of the transaction. This handshaking protocol is performed at the start of every transactional function that is
called from the master mainframe module. Only after the grant signal is received from the bus, the actual transaction
in terms of address/control and data is started.

28
This handshaking is not required in case of an AHB-Lite bus as AHB-Lite only supports one master.
single_write (address, data): Used in the master mainframe module, the arguments for single write are address and
data. Here, the address indicates the address of the slave to which the data must be written to. Once this function is
called from the master mainframe module, the function first checks to see whether the slave is ready and then sends
the address along with control information and data to the master interface module.
burst_write (address, data, length_of_burst): Used in the master mainframe module, this function is used to send a
burst of undefined length as opposed to fixed-length burst. The arguments for burst_write include the start address of
the burst, a pointer to the array that holds the data, and the length of the burst. Once this function is called from the
master mainframe module, the function first checks to see whether the slave is ready and then sends the start address
along with control information and data to the master interface module. In the following cycles, it again waits to see
if the slave is ready and continues to send the data for the next address in the burst. It only sends the data as
generating the subsequent addresses and control signals is done by the interface module. This process continues until
the count becomes equal to the value of the HBURST signal. cburst_write (address, data, type_of_burst): Used in
the master mainframe module, this function is used to send fixed-length burst transactions. The supported fixed-
length burst includes INCR4, INCR8, INCR16. The arguments to the function are the address of the first beat in the
burst, a pointer to the array where the data is stored, and the type of burst. On calling this function from the master
mainframe module, the function first checks to see if the slave is ready and then sends the address along with control
information and data of the first beat in the burst. In the following cycles, it repeats the process of checking whether
the slave is ready and then sends only the data of the next beat in the burst. The subsequent address and control
signals for the remaining beats in the burst is generated by the interface module. This process is repeated until the
count becomes equal to the value of the HBURST signal.
single_read (address): Used in the master mainframe module, this function is used to send a single read transaction.
The argument of the function includes the address from where the data has to be read. On calling this function from
the master mainframe module, the functions first checks to see

29
whether the slave is ready and then sends the address along with the control information. In the following cycle, it
waits for the read data from the slave. Note, it does not wait for the read data in the same cycle as it sends the
address. This is because the protocol requires data to be read in the next cycle as that of address. On receiving the
read data, the function returns the value for the master mainframe module to process.
burst_read (address, memory_to_store, length_of_burst): Used in the master mainframe module, this function is
used to read data of undefined length burst. The arguments of the function include the address of the first beat in the
burst, a pointer to the array where the read data has to be stored and the length of the burst. On calling this function
from the master mainframe module, the function first checks to see whether the slave is ready and then sends the
address and control information of the first beat in the burst. It waits for the read data in the following cycle and
stores the read data in the array in the location pointed by the pointer. In the subsequent cycles, it increments the
pointer and continues to store the read data in the location pointed by the pointer. This process continues until count
becomes equal to the value of the HBURST signal. Note, only the address and control information of the first beat in
the burst is sent by this function and the generation of subsequent addresses is done by the master interface module.
cburst_read (address, memory_to_store, burst_type): Used in the master mainframe module, this function is used to
read data of fixed-length burst. The supported fixed-length burst includes INCR4, INCR8, INCR16. The arguments
of the function include the address of the first beat in the burst, a pointer to the array where the read data has to be
stored and the length of the burst. On calling this function from the master mainframe module, the function first
checks to see whether the slave is ready and then sends the address and control information of the first beat in the
burst. It waits for the read data in the following cycle and stores the read data in the array in the location pointed by
the pointer. In the subsequent cycles, it increments the pointer and continues to store the read data in the location
pointed by the pointer. This process continues till count becomes equal to the value of HBURST signal. Note, only
the address and control information of the first beat in the burst is sent by this function and the generation of
subsequent addresses is done by the master interface module.
get_data(): Used in the slave module, this function is used to get the write data that is sent by the master.

30
put_data(): Used in the slave module, this function is used to return the read data to the master. poll_req(pointer_to_struct): Used in
the slave module, this function is used to poll the read/write signal and the address signal from the master. The argument to this
function is a pointer to a struct that has a type of request (read or write) and address as the fields.

4.6 CONCLUSION
The automatic generation of behavioral SOC enables a quick and efficient way of building entire SOCs. The proposed generator
takes as input a bus definition file that has details of the system like the number of master and slave devices, the memory map of
slave devices, the type of bus and arbiter, the bus width of the bus. Using these details, the bus generator generates a bus module,
interface modules for each of the master and slave devices, and an API file. The API file contains a list of all the functions that are
required/supported by the bus. The user is required to include the API file in the master and slave mainframe module and call the
functions from it appropriately. The API file thus abstracts away the interconnect from the individual master and slave mainframe
modules. The bus module along with the generated interfaces and API files are synthesizable. RT- level as well as cycle-accurate
simulation of the entire SOC is supported.

31
 CHAPTER 5

Existing And Proposed Work

The paper published by P. D. Mulani, "SoC Level Verification Using System Verilog," 2009 Second
International Conference on Emerging Trends in Engineering & Technology” explains the SoC level verification
of AMBA AHB interconnect matrix and I2C Design Under Test (DUT). The assertions and monitor are
developed to check the functionality of Interconnect matrix of multilayer AHB Lite. The whole verification is
done using System Verilog hardware description and verification language.

The verification environment developed is reusable. The bridging of AHB with inter-integrated circuit is done
using an interface concept. Both the designs are bridged together and the verification holds few test cases to
make sure that the design works perfect not only for one, but for multiple possibilities.

The paper “Implementing communication bridge between I2C and AHB” by Busireddypally Jayaramudu et.al.,
explains the bridging of both APB and AHB protocols with I2C. The methodology used is interfacing concept.
The final analysis is covered with the area, delay and power checking of both APB and AHB checked separately
with I2C. The design is done in Xilinx platform and the outputs are verified. The port mapping in the interfacing
block is well analysed in the waveform. Here the AHB design is acting as a slave thus helping IIC to propagate
the needed information to be transferred. The blocks are formed as separate modules and then mapped in the
interface block to be verified as one single module in the verification side. This methodology is standardly used
for both APB and AHB case of the entire work. “ARM Advanced High-Performance Bus (AHB)Complaint Inter
Integrated Circuit” by Prabhakar.k et.al., have merged both AHB and I2C for data transfer and have achieved the
proper output in the waveform analysis. This paper explains clearly about integrating both the modules into one.
Here, the AHB acts as the master and the IIC acts as the slave responding to its master and giving trusty outputs
as requested. The methodology used to integrate both the modules here is the wrapper logic. A separate logic for
the wrapper block is designed which wraps the signals of the AHB master, decodes it and sends it correctly to
the IIC slave. The design part is done in Verilog HDL language and simulated in model sim tool. . The
waveforms obtained shows the synchronization except for the read data signal in the multi test case.

2.2. AHB:

32
Advanced High performance Bus protocol is a ARM Advanced Microcontroller Bus Architecture (AMBA)
protocol family which deals with high frequency devices like processor, Universal Asynchronous Receiver
Transmitter (UART) and such devices. It is a high performance protocol which will enhance the performance of
the device by its phasing concept which is peculiar in this protocol specification. It works in a two phase concept
which will make the address and the data phase get activated in a two cycle manner. For every address phase,
the corresponding data phase occurs in the next cycle of the clock and not on its own cycle. This concept is
called the pipelining architecture of the AHB. This will thus enhance the system performance which gets
designed by this protocol. Fig. 1. Shows the clear waveform of how this pipelining concept takes place. For
every data phase, the address phase happens at the previous cycle thus eliminating any race conditions or data
trafficking issues during communication process.

Fig 1. Pipelining concept of AHB where address and data phase happens in two clock cycle

2.3. IIC:

Inter-Integrated Circuit (IIC) is a block which helps in communication between a processor and an IC
(Integrated Chip). Any processor will work in a high range of frequency in terms of GHz. Whereas an IC
works in a low frequency range in terms of KHz or MHz. This gap in the speed cannot be met if simply a
processor is connected directly to an IC. The speed mismatch will ultimately result in problems like data
loss, data mismatch or even data trafficking sometimes.To avoid this, the gap must be met. This is done
when a bus interface which will receive and debug the speed issue of the processor and then give it to the IC
according to its speed.This issue is generally met up by using at least two different blocks in between the
processor and the IC along with some external peripherals. This will further lead to area and power issues.
33
This problem is targeted in this paper. Fig.2 shows the general block connections between a processor and
an IC.

Fig.2 General processor to IC connection

Here in Fig.2, It is clearly shown that the Bus receives the data from the processor in terms of high
frequency (GHz) and gives it to the low frequency IIC. Thus in IIC, there is a clock matching block which
will receive this GHz and debug it to MHz (low frequency). This will hence make it easy for the IC for the
speed matching.

But this happens in two different blocks which are again connected by external peripherals. Hence this
delay will be more than the direct data passage, which is what focused in this work. The two blocks are
combined to one as shown in Fig.3 and thus the need for the external peripherals are also reduced.

2.4. IIC WORKING SPEED:

Based on the mode of operation, IIC have 3 different working speeds. The normal mode IIC works in 100
Kbps, the fast mode in 400 Kbps and the high mode IIC in 3,5 Mbps.

The mode on which the designed IIC is going to work has to be decided previously in order to design the
prescale register which is the main source to do the speed matching to fill the gap between the processor
and an IC. In this design, the IIC is a normal mode IIC with a 100 Kbps speed. Using the desired speed, the
pre scale register is designed using the formula as follows:-

34
Pre scale = AHB frequency
-1
5*SCL
So, using this formula, the pre scale value is calculated to be 100 and then thus the register is designed to
give the required SCL (Serial clock).

.METHODOLOGY:

This interfacing of the AHB and IIC is designed in such a way that all the signals are port mapped from
AHB to IIC so that there is a direct link in both the modules. The AHB acts as the master here whereas the
IIC as the slave. Any trigger in the master will directly affect the slave as the connection is direct and there
is no interface or wrapper block in between.
This further avoids the excess area for all these intermediate blocks. Since the AHB and IIC are designed
as one single module, in the communication between the processor and an IC, there is only one
intermediate block which is clearly shown in Fig.3

Fig.3 Processor to IC connection as per the proposed design

This will still more reduce the area and the external peripherals used is also avoided as both are been
combined as one single chip.

35
 Fig.4 Framework of the design

The framework of the entire designed used here is given in Fig.4. Different blocks as per the architecture of
AHB and IIC are designed and the signals are generated as per the specification. The mapping of signals are
done in each module and thus the connection between the master and the slave is emphasized.

3.2. I2C PROTOCOL EACH I2C:

transport comprises of two signs: SCL and SDA. SCL is the clock flag, and SDA is the information flag. The
clock flag is constantly produced by the present transport master; some slave devices may compel the time low
now and again to defer the master sending more information (or to require more opportunity to plan information
before the master endeavors to check it out). This is called "clock extending" and is depicted on the convention
page.

I2C tradition anticipated that would allow different slave fused circuit communicate with no less than one
specialists on circuits. All data trade with two conditions. They are starting and stop bit condition. The condition
begins with acknowledgment of start condition and is finished by encountering stop condition. At the point when
start condition develops transport is believed to be involved and it will re-essential in a comparable state till all
sales for the bus have been permitted. For the read/make assignment, first the slave's address is sent trailed by
the looking at data, as showed up in figure 1. The recognize happens after each byte.

The recognize bit enables the beneficiary to flag the transmitter. That the byte was effectively gotten another
byte might be sent. The master produces all tickers beats including recognize ninth clock beat. The clock
characterized as takes after the transmitter discharge than SDA line amid the recognize clock beat. So, the
collector can pull the SDA line low and it stays stable low amid the high time of this clock beat.

36
 Fig.1: I2C Data Transfer Protocol

3.3. APB PROTOCOL:

Fig. 2 Explains the edge cycle as-IDLE: The default state. SETUP: When exchange is required the bus moves
into the SETUP state, where the select flag, PSELx, is avowed. The exchange remains here for one clock
cycle and moves to the ENABLE state on the running with rising edge of the clock. Attract: The enable hail,
PENABLE, is imparted. The address, make and select signs need to remain stable in the midst of the advance
from the SETUP to ENABLE state. If no further trades are required the vehicle returns to the IDLE state.
Obviously, if another move's to be made then the exchange will move to SETUP. Address, make and select
signs would glitch be able to in the midst of advance. In [6] this paper isolates the reusability of I2C utilizing
UVM and showed how the certification condition is manufactured and test cases are executed for this
convention.

Fig.2: State Diagram for write operation

37
 DESINGNED ARCHITECTURE:
The illustrating square configuration of the finished correspondence assistants among I2C and APB is
appeared in Fig. 3. The Structure contains two basic pieces, i.e. I2C Slave and APB Master. I2C Slave takes
the information from I2C Master in isolated course of action and offers it to APB Master. This APB Master
likewise passes on this information to APB Slave in APB Protocol. In this manner a correspondence between
I2C Master and APB Slave is finished.

A. Write Operation

1) Whenever I2C Master needs to visit with APB Slave it would be done by frameworks for I2C Slave.
2) I2C Slave will affirm Data Valid and Address Valid signs.
3) Seeing these banners high, masterminded APB Master considers the memory for its responsiveness and
begins APB shape state machine.
4) I2C sends four bits of 8-bit information serially to be shaped on APB Memory at four unfaltering spaces.
5) After trade of every byte APB Master keeps a mind tally whether each and every one of the four memory
territories are vivified sensibly.
As soon as the information at APB Master is restored it traded the same 32-bit information to APB Slave.

B. Read Operation
Here again when I2C need to investigate information from the APB slave, Correspondence will occur through
APB master to I2C slave to I2C master APB Salve will send a banner to APB Master empowering that the
information is available to be examined. APB Salve by then transmits the data to APB Master where it is
secured in the internal memory to be brought by I2C Slave at time explanation behind time

38
 Fig.3: Communication Bridge

C. AHB APB Interface

Focus AHB to APB is an AHB slave and AMBA APB Master that gives an interface (associate) between the
fast AHB space and the low-control APB territory. The Core AHB to APB interfaces with Core AHB/Core
AHB Lite through the AHB interface, or Core APB through the APB interface.

D. Key Features
1) Bridges between Advanced Microcontroller Bus Architecture (AMBA) Advanced High-Performance Bus
(AHB) and Advanced Peripheral Bus (APB).
2) Automatic relationship with Core AHB/Core AHB Lite and Core APB in Smart Design.
3) AMBA APB agreeable.
39
E. Maintained Interfaces
Center AHB to APB supports an AHB or AHB-Lite slave interface related with an AHB or AHB-Lite
reflected slave interface (for example, Core AHB or Core AHB Lite) and likewise an AMBA APB pro
interface that interfaces with an AMBA APB reflected pro interface (for example, Core APB)

F. Block Diagram

Fig.4: AHB and APB Bridge

G. Description
The I2C-APB Bridge is used make a translation of AHB signs to APB signals. The I2C-APB Bridge is
moreover used to isolate the tip top AHB (system transport) from the slower APB (Peripheral Bus). The I2C-
APB Bridge is an AHB slave part which recognizes trades40
concentrating on an APB periphery, unravels the
address, and gives an APB, periphery transport, trade to the concentrated-on periphery or memory. The I2C-
APB Bridge can decipher up to sixteen APB peripherals. On create trades, the I2C-APB Bridge gives the
form control (PWRITE), select (PSELx), and address (PADDR) and data (PWDATA) to the concentrated-on
periphery or memory. On read trades, the I2C-APB Bridge multiplexes the concentrated-on periphery's data
(PRDATA_device) to the AHB HRDATA with the most ideal arranging. The I2C-APB Bridge furthermore
reestablishes the HREADYOUT movement back to the AHB pro to show that the IPC-APB Bridge has
completed the APB trade and the data is readied.

H. Interfacing APB to AHB

Interfacing the AMBA APB to the AHB is depicted in

Fig.5: Interface APB to AHB

The exchange starts on the AHB at time T1 and the address is investigated by the APB interface at T2. In case
the trade is for the periphery exchange then this address is conveyed and the best possible periphery select flag
41
is created. This first cycle on the periphery exchange is known as the SETUP cycle, this is trailed by the
 ENABLE cycle, when the PENABLE banner is certified. In the midst of the ENABLE cycle the periphery
must give the read data. Routinely it will be possible to course this read data particularly back to the AHB,
where the transport ace exchange can test it on the rising edge of the time toward the complete of the
ENABLE cycle, which is at time T4. In high clock repeat systems, it may wind up essential for the expansion
to select the read data toward the complete of the ENABLE cycle and thereafter for the framework to drive
this back to the AHB transport expert in the going with cycle. Regardless of the way that this will require an
extra sit tight state for periphery exchanges read trades, it allows the AHB to continue running at a higher
clock repeat, accordingly achieving a general change in system execution. A burst of read moves is showed up
in Figure 5-10. All read trades require a singular hold up state.

I. Write Transfer

Fig.6: Write Transfer

The transfers begin on the AHB at time T1 and the address is examined by the APB interface at T2. If the trade
is for the periphery exchange then this address is imparted and
42 the correct periphery select flag is delivered.
This first cycle on the periphery exchange is known as the SETUP cycle, this is trailed by the ENABLE cycle,
when the PENABLE banner is insisted.
In the midst of the ENABLE cycle the periphery must give the read data. Consistently it will be possible to
course this read data particularly back to the AHB, where the exchange Master can test it on the rising edge of
the time toward the complete of the ENABLE cycle, which is at time T4. In high clock repeat systems, it may
wind up imperative for the expansion to enlist the read data toward the complete of the ENABLE cycle and
thereafter for the framework to drive this back to the AHB move transport ace in the going with cycle. In spite
of the way that this will require an extra sit tight state for periphery exchange read trades, it allows the AHB to
continue running at a higher clock repeat, consequently realizing a general change in structure execution. A
burst of read moves is showed up in Figure 5-10. All read trades require a singular hold up state.

43
 CHAPTER

XILINX Software

Xilinx Tools is a suite of software tools used for the design of digital circuits implemented
using Xilinx Field Programmable Gate Array (FPGA) or Complex Programmable Logic
Device (CPLD). The design procedure consists of (a) design entry, (b) synthesis and
implementation of the design, (c) functional simulation and (d) testing and verification. Digital
designs can be entered in various ways using the above CAD tools: using a schematic entry tool,
using a hardware description language (HDL) – Verilog or VHDL or a combination of both. In
this lab we will only use the design flow that involves the use of VerilogHDL.

The CAD tools enable you to design combinational and sequential circuits starting with Verilog
HDL design specifications. The steps of this design procedure are listed below:

1. Create Verilog design input file(s) using template driveneditor.

2. Compile and implement the Verilog designfile(s).
3. Create the test-vectors and simulate the design (functional simulation) without using a
PLD (FPGA orCPLD).
4. Assign input/output pins to implement the design on a targetdevice.
5. Download bitstream to an FPGA or CPLDdevice.
6. Test design on FPGA/CPLDdevice

A Verilog input file in the Xilinx software environment consists of the following segments:

Header: module name, list of input and output ports.

Declarations: input and output ports, registers and wires.

Logic Descriptions: equations, state machines and logic functions.

End: endmodule

44
All your designs for this lab must be specified in the above Verilog input format. Note that the
state diagram segment does not exist for combinational logic designs.

2. Programmable Logic Device:FPGA

In this lab digital designs will be implemented in the Basys2 board which has a Xilinx Spartan3E
–XC3S250E FPGA with CP132 package. This FPGA part belongs to the Spartan family of
FPGAs. These devices come in a variety of packages. We will be using devices that are
packaged in 132 pin package with the following part number: XC3S250E-CP132. This FPGA is
a device with about 50K gates. Detailed information on this device is available at the Xilinx
website.

3. Creating a NewProject
Xilinx Tools can be started by clicking on the Project Navigator Icon on the Windows desktop.
This should open up the Project Navigator window on your screen. This window shows (see
Figure 1) the last accessed project.

45
Figure 1: Xilinx Project Navigator window (snapshot from Xilinx ISE software)

3.1 Opening aproject

Select File->New Project to create a new project. This will bring up a new project window
(Figure 2) on the desktop. Fill up the necessary entries as follows:

46
Figure 2: New Project Initiation window (snapshot from Xilinx ISE software)

ProjectName: Write the name of your newproject

Project Location: The directory where you want to store the new project (Note: DO NOT
specify the project location as a folder on Desktop or a folder in the Xilinx\bin directory.
Your H: drive is the best place to put it. The project location path is NOT to have any spaces
in it eg: C:\Nivash\TA\new lab\sample exercises\o_gate is NOT to be used)

Leave the top level module type as HDL.

Example: If the project name were “o_gate”, enter “o_gate” as the project name and then click
“Next”.

47
Clicking on NEXT should bring up the following window:

Figure 3: Device and Design Flow of Project (snapshot from Xilinx ISE software)

For each of the properties given below, click on the ‘value’ area and select from the list of
values that appear.
o Device Family: Family of the FPGA/CPLD used. In this laboratory we will be
using the Spartan3EFPGA’s.
o Device: The number of the actual device. For this lab you may enterXC3S250E
(this can be found on the attached prototyping board)
o Package:Thetypeofpackagewiththenumberofpins.TheSpartanFPGAusedin this lab
is packaged in CP132package.
o Speed Grade: The Speed grade is“-4”.
o Synthesis Tool: XST[VHDL/Verilog]
o Simulator: The tool used to simulate48and verify the functionality of the design.
 Modelsim simulator is integrated in the Xilinx ISE. Hence choose “Modelsim-XE
Verilog” as the simulator or even Xilinx ISE Simulator can beused.
o Then click on NEXT to save theentries.

All project files such as schematics, netlists, Verilog files, VHDL files, etc., will be stored in a
subdirectory with the project name. A project can only have one top level HDL source file (or
schematic). Modules can be added to the project to create a modular, hierarchical design (see
Section 9).

In order to open an existing project in Xilinx Tools, select File->Open Project to show the list
of projects on the machine. Choose the project you want and click OK.

Clicking on NEXT on the above window brings up the following window:

Figure 4: Create New source window (snapshot from Xilinx ISE software)

If creating a new source file, Click on the NEW SOURCE.

49
3.2 Creating a Verilog HDL input file for a combinational logicdesign

In this lab we will enter a design using a structural or RTL description using the Verilog HDL.
You can create a Verilog HDL input file (.v file) using the HDL Editor available in the Xilinx
ISE Tools (or any text editor).

In the previous window, click on the NEW SOURCE

A window pops up as shown in Figure 4. (Note: “Add to project” option is selected by default. If
you do not select it then you will have to add the new source file to the project manually.)

50
Figure 5: Creating Verilog-HDL source file (snapshot from Xilinx ISE software)

Select Verilog Module and in the “File Name:” area, enter the name of the Verilog source file
you are going to create. Also make sure that the option Add to project is selected so that the

source need not be added to the project again. Then click on Next to accept the entries. This pops
up the following window (Figure 5).

Figure 6: Define Verilog Source window (snapshot from Xilinx ISE software)

In the Port Name column, enter the names of all input and output pins and specify the Direction
accordingly. A Vector/Bus can be defined by entering appropriate bit numbers in the MSB/LSB
columns. Then click on Next> to get a window showing all the new source information (Figure 6). If
any changes are to be made, just click on <Back to go back and make changes. If everything is
acceptable, click on Finish > Next > Next > Finish tocontinue.

51
Figure 7: New Project Information window(snapshot from Xilinx ISE software)

Once you click on Finish, the source file will be displayed in the sources window in the
Project Navigator (Figure 1).

If a source has to be removed, just right click on the source file in the Sources in Project
window in the Project Navigator and select Removein that. Then select Project -> Delete
Implementation Data from the Project Navigator menu bar to remove any relatedfiles.

3.3 Editing the Verilog sourcefile

The source file will now be displayed in the Project52Navigator window (Figure 8). The source
 filewindowcanbeusedasatexteditortomakeanynecessarychangestothesourcefile.All

The input/output pins will be displayed. Save your Verilog program periodically by selecting the
File->Save from the menu. You can also edit Verilog programs in any text editor and add them to the
project directory using “Add Copy Source”.

Figure 8: Verilog Source code editor window in the Project Navigator (from Xilinx ISE
software)

Adding Logic in the generated Verilog Source codetemplate:

A brief Verilog Tutorial is available in Appendix-A. Hence, the language syntax and
construction of logic equations can be referred to Appendix-A.

The Verilog source code template generated shows the module name, the list of ports and
also the declarations (input/output) for each port. Combinational logic code can be added
to the verilog code after the declarations and53before the endmodule line.
 For example, an output z in an OR gate with inputs a and b can be described as,
assign z = a | b;
Remember that the names are case sensitive.

Other constructs for modeling the logicfunction:

A given logic function can be modeled in many ways in verilog. Here is another example
in which the logic function, is implemented as a truth table using a case statement:

moduleor_gate(a,
b,z); input a;

input
b;
output
z;

reg z;

always @(a
or b) begin

case
({a,b}) 00:
z =1'b0;

01: z =1'b1;

10: z =1'b1; 54
 11: z =1'b1;

endcase

end
en
dmodule

Suppose we want to describe an OR gate. It can be done using the logic equation as shown in
Figure 9a or using the case statement (describing the truth table) as shown in Figure 9b. These
are just two example constructs to design a logic function. Verilog offers numerous such
constructs to efficiently model designs. A brief tutorial of Verilog is available in Appendix-A.

Figure 9: OR gate description using assign statement (snapshot from Xilinx ISE
software)

55
Figure 10: OR gate description using case statement (from Xilinx ISE software)

4. Synthesis and Implementation of theDesign

The design has to be synthesized and implemented before it can be checked for correctness,
by running functional simulation or downloaded onto the prototyping board. With the top-
level Verilog file opened (can be done by double-clicking that file) in the HDL editor
window in the right half of the Project Navigator, and the view of the project being in the
Module view , the implement design option can be seen in the process view. Design entry
utilities and Generate Programming File options can also be seen in the process view. The
former can be used to include user constraints, if any and the latter will be discussed later.

56
 To synthesize the design, double click on the Synthesize Design option in the Processes
window.

To implement the design, double click the Implement design option in the Processes
window. It will go through steps like Translate, Map and Place & Route. If any of these
steps could not be done or done with errors, it will place a X mark in front of that, otherwise
a tick mark will be placed after each of them to indicate the successful completion. If
everything is done successfully, a tick mark will be placed before the Implement Design
option. If thereare

warnings, one can see mark in front of the option indicating that there are some warnings. One
can look at the warnings or errors in the Console window present at the bottom of the Navigator
window. Every time the design file is saved; all these marks disappear asking for a
freshcompilation.

57
Figure 11: Implementing the Design (snapshot from Xilinx ISE software)

The schematic diagram of the synthesized verilog code can be viewed by double clicking
View RTL Schematic under Synthesize-XST menu in the Process Window. This would be a
handy way to debug the code if the output is not meeting our specifications in the proto type
board.

By double clicking it opens the top level module showing only input(s) and output(s) as
shown below.

58
 Figure 12: Top Level Hierarchy of the design

By double clicking the rectangle, it opens the realized internal logic as

shown below.

59
 Figure 13: Realized logic by the XilinxISE for the verilog code

5. Functional Simulation of CombinationalDesigns

5.1 Adding the testvectors

To check the functionality of a design, we have to apply test vectors and simulate the
circuit. In order to apply test vectors, a test bench file is written. Essentially it will supply
all the inputs to the module designed and will check the outputs of the module. Example:
For the 2 input OR Gate, the steps to generate the test bench is as follows:

60
 In the Sources window (top left corner) right click on the file that you want to generate
the test bench for and select ‘New Source’

Provide a name for the test bench in the file name text box and select ‘Verilog test
fixture’ among the file types in the list on the right side as shown in figure 11.

Figure 14: Adding test vectors to the design (snapshot from Xilinx ISE software)

61
 Click on ‘Next’ to proceed. In the next window select the source file with which you
want to associate the test bench.

Figure 15: Associating a module to a testbench (snapshot from Xilinx ISE software)

Click on Next to proceed. In the next window click on Finish. You will now be provided
with a template for your test bench. If it does not open automatically click the radio
button next to Simulation .

62
You should now be able to view your test bench template. The code generated would be
something like this:
moduleo_gate_tb_v;

//
Inp
uts
reg
a;

reg b;

//
Out
puts
wire
z;

63
 // Instantiate the Unit Under
Test (UUT) o_gateuut (

.a(a),

.b(b),

.z(z)

);

initialbegin

// Initialize
Inputs a =
0;

b =0;

// Wait 100 ns for global

reset tofinish #100;

// Add stimulus here

end

endmodule

64
The Xilinx tool detects the inputs and outputs of the module that you are going to test an assigns
them initial values. In order to test the gate completely we shall provide all the different input
combinations. ‘#100’ is the time delay for which the input has to maintain the current value.
After 100 units of time have elapsed the next set of values can be assign to the inputs.
Complete the test bench as shown below:

moduleo_gate_tb_v;

//
In
put
s
reg
a;
reg
b;

//
Out
puts
wire
z;

// Instantiate the Unit Under

Test (UUT) o_gateuut (

.a(a),

.b(b),

65
 .z(z)

);

initialbegin

// Initialize
Inputs a =
0;

b =0;

// Wait 100 ns for global reset to finish #100;

a = 0;

b =1;

// Wait 100 ns for global

reset tofinish #100;

a = 1;

b =0;

66
 // Wait 100 ns for global
reset tofinish #100;

a = 1;

b =1;

// Wait 100 ns for global

reset tofinish #100;

end

endmodule

Save your test bench file using the File menu.s

5.2 Simulating and Viewing the OutputWaveforms

Now under the Processes window (making sure that the testbench file in the Sources
window is selected) expand the ModelSim simulator Tab by clicking on the add sign next
to it. Double Click on Simulate Behavioral Model. You will probably receive a complier
error. This is nothing to worry about – answer “No” when asked if you wish to abort
simulation. This should cause ModelSim to open. Wait for it to complete execution. If you
wish to not receive the compiler error, right click on Simulate Behavioral Model and select
process properties. Mark the

checkbox next to “Ignore Pre-Complied Library Warning Check”.

67
 Figure 16: Simulating the design (snapshot from Xilinx ISE software)

5.3 Saving the simulationresults

To save the simulation results, Go to the waveform window of the Modelsim simulator,
Click on File -> Print to Postscript -> give desired filename and location.

Notethatbydefault,thewaveformis“zoomedin”tothenanosecondlevel. Use the

zoom controls to display the entirewaveform.

Else a normal print screen option can be used on the waveform window and subsequently
stored in Paint.

68
 Figure 17: Behavioral Simulation output Waveform (Snapshot from
ModelSim)

For taking printouts for the lab reports, convert the black background to white in Tools ->
Edit Preferences. Then click Wave Windows -> Wave Background attribute.

69
 Figure 18: Changing Waveform Background in ModelSim

CHAPTER 7

CONCLUSION:
The AHB-IIC module is thus designed and checked for correct outputs. Thus the designed
module combines the advantages of both AHB and IIC and promises a high performance,

70
speed matching module which will make the communication between the processor and an IC
more efficient by reducing the area and external peripherals. The flexibility of the
communication is also increased because of the two cycle phase concept of the AHB thus
giving a highly advantageous outcome. The functional coverage is obtained to be 100%. The
synthesis report in terms of speed and frequency is inferred in the table below
Table 1.1 Speed-frequency report

PARAMETERS AHB IIC

Speed 20Mbps 100Kbps
Frequency 10MHz 50KHz

FUTURE SCOPE:
As proposed personality has been taken to organize data trade speed of both the vehicles
transports for better consistence. We intend to layout a model with added supports at the
interface to get essentially higher speed of data trade Latency and credibility of losing data can
be diminished by Expanding the help length at the interface of made APB master. Keeping the
working frequencies of influenced APB to master extraordinary with I2C. Exchange ways to
deal with oversee perform Reading Operations.

71
72