BE Project Final Report

PROJECT REPORT
ON
DEVELOPING BUS FUNCTIONAL MODEL

FOR APB SLAVE USING VLSI DESIGN
Submitted in Partial Fulfilment of the

Requirements for the Degree of
Bachelor of Engineering
In
Electronics and Telecommunication
By
Pranav Naresh Kulkarni (Exam Seat No-B190353042 )
Sheshrao Vasantrao Sawandkar (Exam Seat No- B190353070)
Anushka Dhanajay Deshmukh (Exam Seat No- B190353018 )
Under the Guidance of
Mrs.V.S.Surwase
Department of Electronics and Telecommunication Engineering,
VIDYA PRATISHTHAN’S KAMALNAYAN BAJAJ INSTITUTE OF
ENGINEERING & TECHNOLOGY, BARAMATI
2023-24
Affiliated to
Savitribai Phule Pune University

Department of Electronics and Telecommunication Engineering,
Vidya Pratishthan’s Kamalnayan Bajaj Institute of Engineering & Technology, Baramati
CERTIFICATE
This is to Certify that the Project Report Entitled
“Developing Bus functional Model For APB Slave Using VLSI

Design”
Submitted By
Pranav Naresh Kulkarni (Exam Seat No-B190353042)
Sheshrao Vasantrao Sawandkar(Exam Seat No-B190353070)
Anushka Dhanajay Deshmukh(Exam Seat No-B190353018)
is a bonafide work carried out satisfactorily by them under supervision and

guidance and it is submitted towards the partial fulfillment of the requirements
of Savitribai Phule Pune University, Pune for the award of degree, Bachelor
of Engineering (Electronics and Telecommunication) during the academic year
2023-24.
Place: Baramati
Date:
Mrs. V. S. Surwase Dr. B. H. Patil

Guide Head of the Department
Dr. R. S. Bichkar
Principal
VPKBIET, Baramati.
ACKNOWLEDGEMENT
We want to express our sincere admiration to everyone those who have played a pivotal
role in the successful development and completion of this project, Developing Bus Func-
tional Model For APB Slave Using VLSI Design First and foremost, We wish to express
our heartfelt appreciation to Our project guide, Mrs. V. S. Surwase, whose profound
knowledge, guidance, and continuous encouragement have been instrumental in shaping this
project. We would also like to thank our Head Of Department Dr. B.H.Patil for pro-
viding the necessary resources, facilities, and funding, enabling us to carry out our research
and development effectively. I would like to extend my gratitude to Principal Dr. R. S.
Bichkar for facilitating us to present our project. The facilities and academic commu nity
at VPKBIET, Baramati have been crucial to the success of this project. Further more,
Their insightful feedback and encouragement have been instrumental in shaping our design
and methodology. A special thanks to the members of our project team. Your commitment,
hard work, and collaboration have been the driving force behind the project’s success. Each
one of you has made a significant contribution. I would like to acknowledge the support and
resources provided by My Collage VPKBIET, Baramati. These resources, including access
to tools, facilities, and technical assistance, have been crucial to our project’s progress.
iii
ABSTRACT
This VLSI design project tackles the problem of creating an Advanced Peripheral Bus (APB)
slave Bus Functional Model (BFM). To ensure precise behavior and timing, the work entails
building a realistic software version of an APB slave that adheres to the APB protocol and
permits testing and simulation. With careful planning, in-depth knowledge of the APB
protocol, and cooperative effort, we were able to create a reliable BFM that closely mimics
the actions of the APB slave. In the broader VLSI design project, this BFM will be an
invaluable tool that will streamline the development process and help the project succeed
overall by enabling thorough testing and verification while lowering the reliance on physical
hardware.
iv
Contents
Acknowledgement iii
Abstract iv
List of Figures vi
List of Abbreviation vii
1 INTRODUCTION 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Foreground AMBA Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Introduction To AMBA APB . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 LITERATURE REVIEW 7
3 SYSTEM DEVELOPMENT 10
3.1 APB Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 APB Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Operating States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4 Interaction With Peripherals 18

4.1 UART Interaction With APB . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 APB UART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3 I2C Interaction With APB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.4 APB I2C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.5 Software Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5 RESULTS 34
5.1 Implemented Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6 CONCLUSION 40
References 41
Appendix 42
v
List of Figures
1 AMBA Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 APB Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Timing Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 Signal Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5 With No Wait Write Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6 With Wait Write Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7 With No Wait Read Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8 With No Wait Read Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9 Finite State Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10 UART Data Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11 Transmitter FSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
12 Receiver FSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
13 APB UART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
14 I2C Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
15 I2C FSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
16 Start Stop Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
17 APB with I2C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
18 Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
vi
List of Abbreviations
Abbreviation Meaning
1. BFM Bus Functional Model
2. APB Advance Peripheral Bus
3. VLSI Very Large Scale Integration
4. HDL Hardware Discription Language
5. VHDL VHSIC Hardware Discription Language
6. SOC System Onchip
7. AMBA Advance Microcontroller Bus Architecture
8. RTL Register Transfer Level
9. PCLK Peripheral Clock
10. PRESETn Reset Signal
11. PADDR Address BUS
12. I/O Input/Output
13. PSELn Slave Select Signal
14. PWRITE Write Enable Signal
15. PREAD Read Data Bus
16. FSM Finite State Machine
17. FPGA Field Programmable Gate Array
18. DUT Design Under Test
19. UVM Universal Verification Methodology
20. TB Test Bench
21. STA Static Timing Analysis
22. I2C Inter Integrated Circuit
23. UART Universal Asynchronous receiver-Transmitter
vii
Developing Bus Function Model For APB Slave Using Vlsi Design
1 INTRODUCTION
Using VLSI design principles, a bus functional model for an APB (Advanced Peripheral
Bus) slave is to be developed for the project. The purpose of this model is to replicate
the actions and features of an APB slave within a digital design environment. The project
entails comprehending the APB protocol, developing the APB slave, and building a bus
functional model that manages time constraints, provides read and write access, monitors
APB bus signals, and is tested using test benches and simulation to ensure that it works
as intended. Prior to hardware implementation, the ultimate goal is to guarantee that the
APB slave functions properly and adheres to the protocol. Before moving on to hardware
implementation, the solution seeks to create a trustworthy and accurate simulation model
of the APB slave, allowing for a complete evaluation of its behavior and protocol compliance.
When designing System on Chips (SOCs), the Advanced Microcontroller Bus Architec-
ture (AMBA) is a popular interconnection standard. Analysis of AMBA-based embedded
systems is difficult since AMBA supports a wide range of bus signals to enable high-speed
pipelined data transfers. The AMBA specification has become a de-facto standard for the
semiconductor industry, it has been adopted by more than 95 percent of ARM’s partners
and a number of IP providers. This specification has been successfully tested in several
ASIC designs. Since the AMBA interface is processor technology independent, it helps in
enhancing the reusability of Peripheral and system components across a wide range of ap
plications. The AMBA specification has been derived to satisfy the following four key re-
quirements: (i)To facilitate the right-first-time development of Embedded Microcontroller
Products with one or more CPUs or signal processors. (ii)To be technology-independent
and ensure that highly reusable peripheral and system macro cells can be migrated across a
diverse range of IC processes and be appropriate for full-custom, standard cell and gate array
technologies. (iii)To encourage modular system design to improve processor independence,
providing a development roadmap for advanced cached CPU cores and the development of
peripheral libraries. (iv)To minimize the silicon infrastructure required supporting efficient
on-chip and off-chip communication for both operation and manufacturing test. The present
design of UART slave devices which are compatible with AMBA APB bus protocol can be
plugged in to AMBA bus oriented system, its functionality and requirement can be used
with AMBA based systems.
Department of E & TC 1 VPKBIET,Baramati

The present design is configured with the control signals of the AMBA standard specifi-
cation. The control of these slave devices can be taken by APB controller of another AMBA
based system when they are connected to it.
This project aims to develop BFMs for APB, UART, and I2C, which will serve as es-
sential tools for simulating and verifying the behavior of these communication proto cols.
The development of these models will involve a thorough understanding of the protocol
specifications, meticulous design and implementation of the models, and extensive simula-
tion to verify their functionality. The BFMs will not only enhance the verification process
by abstracting the complexities of physical bus interfaces but also significantly reduce the
time and effort involved in debugging and testing. Ultimately, the successful completion of
this project will contribute to more reliable and efficient VLSI designs, ensuring that they
adhere to protocol specifications and function correctly under various conditions.

1.1 Motivation
The development of bus functional models for interfaces such as APB, UART, and I2C within
VLSI design is essential for ensuring reliable communication in complex SoC architectures.
These models play a critical role in verifying the correct operation of various protocols,
enabling designers to identify and address design issues early in the development cycle.
By simulating real-world scenarios and interactions, these BFMs streamline the verification
process, reduce debugging time and costs, and contribute to the creation of more efficient
and high-performance VLSI systems tailored to meet the demands of advanced electronic
applications.
1.2 Objective
What are the performance measures of your project The primary objective of the project is
to develop a bus functional model for an APB (Advanced Peripheral Bus) slave using VLSI
design principles. The project aims to create a simulation model that accurately emulates
the behavior and functionality of an APB slave within a digital design. This model will
be used for the verification and testing of the APB slave’s operation, ensuring that it ad-
heres to the APB protocol and functions correctly within the context of a digital system.
The objective of this project is to develop Bus Functional Models (BFMs) for APB slave
interfaces, UART, and I2C using VLSI design principles. These models aim to provide a
comprehensive simulation environment that accurately emulates the behavior of these com
munication protocols, facilitating thorough verification of digital designs. Specifically, the
project seeks to create BFMs that can emulate the master and slave roles for APB, UART,
and I2C interfaces, enabling detailed testing of data transactions, timing, and protocol com
pliance. By developing these models, the project aims to ensure that the integrated circuits
incor porating these protocols are robust, efficient, and adhere to industry standards. The
BFMs will be instrumental in identifying and resolving potential design issues early in the
de velopment cycle, thereby reducing the time and cost associated with hardware debugging
and verification. Ultimately, this project aims to enhance the reliability and performance
of VLSI designs, contributing to the creation of more dependable and efficient electronic
systems.

1.3 Foreground AMBA Architecture
An AMBA-based microcontroller typically consists of a high-performance system backbone

bus (AMBA AHB or AMBA ASB), able to sustain the external memory bandwidth, on
which the CPU, on-chip memory and other Direct Memory Access (DMA) devices reside.
This bus provides a high-bandwidth interface between the elements that are involved in the
majority of transfers. Also located on the high-performance bus is a bridge to the lower
bandwidth APB, where most of the peripheral devices in the system are located.
The Advanced Microcontroller Bus Architecture (AMBA) specification defines an on-
Figure 1: AMBA Architecture
chip communications standard for designing high-performance embedded microcontrollers.

Three distinct buses are defined within the AMBA specification:
• the Advanced High-performance Bus (AHB)

• the Advanced System Bus (ASB)
• the Advanced Peripheral Bus (APB). A test methodology is included with the AMBA
specification which provides an infrastructure for modular macrocell test and diagnostic
access. The AMBA specification has been derived to satisfy four key requirements:
• to facilitate the right-first-time development of embedded microcontroller products with

one or more CPUs or signal processors
• to be technology-independent and ensure that highly reusable peripheral and system

macrocells can be migrated across a diverse range of IC processes and be appropriate for
full-custom, standard cell and gate array technologies
• to encourage modular system design to improve processor independence, providing a de-
velopment road-map for advanced cached CPU cores and the development of peripheral
libraries
• to minimize the silicon infrastructure required to support efficient on-chip and off-chip
communication for both operation and manufacturing test. AMBA APB provides the ba-
sic peripheral macrocell communications infrastructure as a secondary bus from the higher
bandwidth pipelined main system bus. Such peripherals typically:
• have interfaces which are memory-mapped registers

• have no high-bandwidth interfaces
• are accessed under programmed control The external memory interface is application-
specific and may only have a narrow data path, but may also support a test access mode
which allows the internal AMBA AHB, ASB and APB modules to be tested in isolation
with system-independent test sets.
1.4 Introduction To AMBA APB
The APB is part of the AMBA hierarchy of buses and is optimized for minimal power con-
sumption and reduced interface complexity. The AMBA APB appears as a local secondary
bus that is encapsulated as a single AHB or ASB slave device. APB provides a low-power
extension to the system bus which builds on AHB or ASB signals directly. The APB bridge
appears as a slave module which handles the bus handshake and control signal retiming on
behalf of the local peripheral bus. By defining the APB interface from the starting point
of the system bus, the benefits of the system diagnostics and test methodology can be ex-
ploited. The AMBA APB should be used to interface to any peripherals which are low
bandwidth and do not require the high performance of a pipelined bus interface. The latest
revision of the APB is specified so that all signal transitions are only related to the rising
edge of the clock. This improvement ensures the APB peripherals can be integrated easily
into any design flow, with the following advantages:
• high-frequency operation easier to achieve
• performance is independent of the mark-space ratio of the clock
• static timing analysis is simplified by the use of a single clock edge

• no special considerations are required for automatic test insertion

• many Application Specific Integrated Circuit (ASIC) libraries have a better selection of
rising edge registers
• easy integration with cycle-based simulators. These changes to the APB also make it
simpler to interface it to the new AHB. An AMBA APB implementation typically contains
a single APB bridge which is required to convert AHB or ASB transfers into a suitable
format for the slave devices on the APB. The bridge provides latching of all address, data
and control signals, as well as providing a second level of decoding to generate slave select
signals for the APB peripherals. All other modules on the APB are APB slaves. The APB
slaves have the following interface specification:
• address and control valid throughout the access (unpipelined) Introduction to the AMBA
Buses ARM IHI 0011A Copyright © 1999 ARM Limited. All rights reserved. 1-11.
• zero-power interface during non-peripheral bus activity (peripheral bus is static when not
in use).
• timing can be provided by decode with strobe timing (unclocked interface).
• write data valid for the whole access (allowing glitch-free transparent latch implementa-
tions).

2 LITERATURE REVIEW
Developing a Bus Functional Model for APB slave using Universal Verification Method
ology: Deekshith Krishnegowda, San Jose State University In this Paper Testbench was
implemented using UVM with focus of functional verification. Simulations was performed
using Synopsys VCS.[1]
VLSI Design AHB AMBA2 APB:Aparna Kharade1 and V. Jayashree2 implemented

AHB2APB Bridge successfully by using Verilog tool and simulated the implemented design
in Xilinx ISE environment. Testing of this bridge was done by usingUniversal verification
Methodology Environment using an industrial standard Aldec Riviera-Pro simulator. Here
we are using master clock, Hclk alone with Penable which will help for reducing the power
consumption. Implementation of AHB2APB Bridge for multi master and multi slave is one
of the future scope.[2]
Design Implementation of Advance Peripheral Bus Protocol: Heli ShahP PR ,RP PCh
inmay ModiP ,P, Bhargav TarparaP:This paper gives an outline of the AMBA bus architec
ture and explain the APB bus in detail. The APB bus is designed using the Verilog HDL
according to the specification and is verified using Xilinx. The simulation results show that
thedata read from a particular memory location is So After completion of this, we can move
to physical design for IC fabrication for the same.[3]
Design and FPGA Implementation of AMBA APB Bridge with Clock Skew Minimiza
tion Technique:The implementation of AMBA APB Bridge with efficient deployment of sys-
tem resources which can provide low bandwidth between AMBA high speed ASB and low
speed APB buses and APB multi slave interface is designed. It defines both bus specifi
cation and a technology independent methodology for designing, implementing and testing
customized high-integration embedded interfaces. The objective of the paper is achieved
when bridge is designed with three bit ripple counter for minimizing the clock skew. In this
Design the Xilinx VIVADO IDE Tool is used for synthesis and simulation and verified the
APB Bridge with one master and two slaves. This design supports APB protocol 32 or 64
bit data width M. Kiran Kumar1, Amrita Sajja2 Dr. Fazal Noorbasha3 [4]

AMBA Specification (Rev 2.0) This Paper Shows The The Complete Outline About The
AMBA Architecture.[6]
Design and Verification of AMBA APB Protocol :Shankar SNeeraj Kr. Shukla, Ph.D This
paper gives an overview of the AMBA bus architecture and discusses the APB bus in detail.
The APB bus is designed using the verilog HDL according to the specification and is ver-
ified using Universal Verification Methodology. The simulation results show that the data
read from a particular memory location is same as the data written to the given memory
location. Hence, the design is functionally correct.The UVM report summary also ensures
the functional correctness of the design.[9]
A. Suresh and S. Nandi, ”Physical Bridge Design for High Performanceto Peripheral Bus:
An Open Source Approach,” 2020 Third InternationalConference on Advances in Electron-
ics, Computers and Communications(ICAECC),2020,The Advanced Microcontroller Bus
Architecture (AMBA) offering from ARM is one of the most widely used standards for
System on Chip (SoC) design in the semiconductor industry. The specifications defined
by AMBA provide many advantages such as right-first-time development and technology
independence for design of high performance chipsets. The main focus in this paper is
on two protocols - Advanced High performance Bus (AHB) and Advanced peripheral Bus
(APB). Keeping in mind that these specifications are an open standard, we aim to develop
an AMBA AHB-APB bridge from Register Transfer Level (RTL) to Graphical Display Sys-
tem (GDSII) using only open source tools and libraries. The proposed design is developed
with Verilog Hardware Definition Language (HDL), followed by compilation and functional
simulation. Physical design is performed after verification to obtain graphical display of the
bridge module. Detailed analysis of the results obtained indicates that open source options
are viable to test various digital designs obviating the need to invest in expensive propri-
etary design tools. This would accrue benefit by greatly improving the scope and reach of
Very Large Scale Integration (VLSI) design.[10]
PARIKI MANASA1, B. PADMINI2, S. NAGI REDDY, ”Design of an I2C Master Inter-

facing with APB Bus”:-This paper gives an overview of Design of an I2C Master Interfacing
with APB Bus in detail The implemented communication bridge between I2C and APB was
designed and implemented in Xilinx ISE 14.2 I2C Bus was successfully designed according
to the standards given by NXP Semiconductors. A working communication model was set

up between I2C protocol and APB protocol. Data flow from I2C master to I2C slave to
APB master to APB Slave is shown while describing the architecture. Simulation results are
verified and data transfer from I2C master to APB slave can be clearly seen in simulation
results. They intend to design a model with added buffers at the interface to get even higher
speed of data transfer.[11]
Mukthi S. L.1, Dr. A. R. Aswatha2Design and Implementation of an Interfacing Protocol

between I2C and APB for an AMBA Based SOC :- This paper gives an overview of Design
and Implementation of an Interfacing Protocol between I2C and APB for an AMBA Based
SOC in detail Implementation of I2C Protocol Interface which build the bridge between
I2C and APB. Implementation of this design is done in ModelSim-Altera Starter Edition
6.5e, using Verilog Bus Protocol bsed on NXP Semiconductor Standards. Read and Write
operation if i2c Master is verified and Simulation result also discussed. Data flow from I2c
Master to i2c slave to Apb Slave in simulation result. This research likely references other
studies on connecting different parts of a computer chip using AMBA buses. Specifically, it
would look at existing ”bridge” designs that connect AMBA’s AXI (high-performance) and
APB (low-power) protocols. The review would mention research on both AXI and APB
protocols, and how they’re typically used. By comparing this research to prior work, the
authors would show how their new bridge design is different and potentially better.[12]

3 SYSTEM DEVELOPMENT
3.1 APB Protocol
The APB protocol is a low-cost interface, optimized for minimal power consumption and
reduced interface complexity. The APB interface is not pipelined and is a simple, syn-
chronous protocol. Every transfer takes at least two cycles to complete. The APB interface
is designed for accessing the programmable control registers of peripheral devices. APB
peripherals are typically connected to the main memory system using an APB bridge. For
example, a bridge from AXI to APB could be used to connect a number of APB peripherals
to an AXI memory system. APB transfers are initiated by an APB bridge. APB bridges
can also be referred to as a Requester. A peripheral interface responds to requests. APB
peripherals can also be referred to as a Completer. This specification will use Requester
and Completer.
Figure 2: APB Block Diagram
APB is a component of AMBA Hierarchy Bus and it is used to connect with the low
peripheral devices. AMBA-APB usually consists of APB Bridge/master and APB slave
and it can be used to interface with many number of slaves. APB Slave have a simple,
yet flexible interface and it can be used to interface many slaves. And it performance the
subsequent functions.

Timing Diagrams:
The components used in timing diagrams are explained in the figure Key to timing diagram
conventions. Variations have clear labels, when they occur. Do not assume any timing
information that is not explicit in the diagrams. Shaded bus and signal areas are undefined,
so the bus or signal can assume any value within the shaded area at that time. The actual
level is unimportant and does not affect normal operation.
Figure 3: Timing Diagram
Timing diagrams sometimes show single-bit signals as HIGH and LOW at the same time
and they look similar to the bus change shown in Key to timing diagram conventions. If
a timing diagram shows a single-bit signal in this way then its value does not affect the
accompanying description.
Signals The signal conventions are: Signal level The level of an asserted signal depends on
whether the signal is active-HIGH or active-LOW. Asserted means:
• HIGH for active-HIGH signals
• LOW for active-LOW signals.
Lower-case n At the start or end of a signal name denotes an active-LOW signal.

AMBA APB Signal Description :

This section describes the APB interface signals. Some signals on the APB interface have
a fixed width and some can take a variety of widths. When the width is not fixed, it is
described using a property. If the property value is zero, this means the signal is not present
on the interface.
Figure 4: Signal Description
Address bus: An APB interface has a single address bus, PADDR, for read and write
transfers. PADDR indicates a byte address. PADDR is permitted to be unaligned with
respect to the data width, but the result is UNPREDICTABLE. For example, a Completer
might use the unaligned address, aligned address, or signal an error response.
Data buses : The APB protocol has two independent data buses, one for read data and
one for write data. The buses can be 8, 16, or 32 bits wide. The read and write data buses
must have the same width. Data transfers cannot occur concurrently because the read data
and write data buses do not have their own individual handshake signals.

3.2 APB Transfers
Write Transfer: This chapter describes typical AMBA APB transfers, the error response,
and protection unit support. Write transfers This section describes the following types of
write transfer:
• With no wait states
• With wait states All signals shown in this section are sampled at the rising edge of PCLK.
Write Transfer With No Wait :shows how the Completer can use PREADY to extend the
transfer
Figure 5: With No Wait Write Transfer
The Setup phase of the write transfer occurs at T1 in Figure 3-1. The select signal, PSEL,
is asserted, which means that PADDR, PWRITE and PWDATA must be valid. The Ac-
cess phase of the write transfer is shown at T2 in Figure 3-1 where PENABLE is asserted.
PREADY is asserted by the Completer at the rising edge of PCLK to indicate that the
write data will be accepted at T3. PADDR, PWDATA, and any other control signals, must
be stable until the transfer completes. At the end of the transfer, PENABLE is deasserted.
PSEL is also deasserted, unless there is another transfer to the same peripheral.
Write Transfer with Wait :
During an Access phase, when PENABLE is HIGH, the Completer extends the transfer by
driving PREADY LOW. The following signals remain unchanged while PREADY remains
LOW:
• Address signal, PADDR
• Direction signal, PWRITE
• Select signal, PSELx

Figure 6: With Wait Write Transfer
• Enable signal, PENABLE

• Write data signal, PWDATA
• Write strobe signal, PSTRB
• Protection type signal, PPROT
• User request attribute, PAUSER
• User write data attribute, PWUSER PREADY can take any value when PENABLE is
LOW. This ensures that peripherals that have a fixed two cycle access can tie PREADY
HIGH.
Read Transfer: Two types of read transfer are described in this section:
• With no wait states
• With wait states
All signals shown in this section are sampled at the rising edge of PCLK.
The timing of the address, PADDR, write, PWRITE, select, PSEL, and enable, PENABLE,
signals are the same as described in Write transfers . The Completer must provide the data
before the end of the read transfer.
with Wait State :
The transfer is extended if PREADY is driven LOW during an Access phase. The following
signals remain unchanged while PREADY remains LOW:
• Address signal, PADDR
• Direction signal, PWRITE
• Select signal, PSEL
• Enable signal, PENABLE

Figure 7: With No Wait Read Transfer
Figure 8: With No Wait Read Transfer
• Protection signal, PPROT

• User signal, PAUSER

3.3 Operating States
The state machine operates through the following states:
Figure 9: Finite State Machine
IDLE This is the default state of the APB interface. SETUP When a transfer is required,
the interface moves into the SETUP state, where the appropriate select signal, PSELx, is
asserted. The interface only remains in the SETUP state for one clock cycle and always
moves to the ACCESS state on the next rising edge of the clock. ACCESS The enable
signal, PENABLE, is asserted in the ACCESS state. The following signals must not change
in the transition between SETUP and ACCESS and between cycles in the ACCESS state:
• PADDR
• PPROT
• PWRITE
• PWDATA, only for write transactions
• PSTRB

• PAUSER
• PWUSER
Exit from the ACCESS state is controlled by the PREADY signal from the Completer:
• If PREADY is held LOW by the Completer, then the interface remains in the ACCESS
state.
• If PREADY is driven HIGH by the Completer then the ACCESS state is exited and the
bus
returns to the IDLE state if no more transfers are required. Alternatively, the bus moves
directly to the SETUP state if another transfer follows.
• IDLE: This will be the default state where there is no transfer of data.
• SETUP: within this state appropriate PSLELx signal is asserted, bus only remains in the
SETUP state for one clock cycle and will always move to the ENABLE state on the next
rising edge of the clock.
– ENABLE/ACCESS: In the ENABLE state PENABLE signal is asserted. The address,
write and select signals all remain stable during the transition from the SETUP to ENABLE
state. The ENABLE state also only lasts for a single clock cycle and after this state the bus
will depart to the IDLE state if no further transfers are required. Alternatively, if another
transfer be to follow then the bus will move directly to the SETUP state. It is acceptable
for the address, write and select signals to glitch during a transition from the ENABLE to
SETUP states.
• Write cycle: During the write transfer operation, the PSEL, PWRITE, PADDR and PW-
DATA signals are asserted at the T1 clock edge which is called the SETUP cycle. At the
next rising edge of the clock T2, the PENABLE signal and PREADY signal are asserted.
This is called the ACCESS cycle. At the clock edge T3, PENABLE signal is disabled and
if further data transfer is required, a high to low transition occurs on the PREADY signal.
• Read Cycle: During the read operation, the PSEL, PENABLE, PWRITE, PADDR signals
are asserted at the clock edge T1 (SETUP cycle). At the clock edge T2, (ACCESS cycle),
the PENABLE, PREADY are asserted and PRDATA is also read during this phase.

4 Interaction With Peripherals
4.1 UART Interaction With APB
In Previous Chapters We Discuss About The APB And AMBA Whole Descritpion And
Operation In This Chapter We ellaborate The Full Implementatio Of Peripheral Via Com-
munication Protocol Like UART, I2C Etc With There System Requirments , Functionality
And Specification. To Communicate Via APB Bridge.
UART : Universal Asynchronous Receiver/Transmitter (UART) is a standard serial

communication protocol for exchanging data between two devices. In this communication
protocol, data is transferred sequentially, one bit at a time. This implementation uses a
frame consisting of 8 data bits, one start bit, one optional parity bit, and one or more stop
bits. A parity bit is a bit, with a value of 0 or 1, that is added to a block of data for error
detection purposes. This bit is optional; it may or may not be added to the data payload.
It can also be set either to odd or even. These bits are often used in data transmission
to ensure that data is not corrupted during the transfer process. If the data transmission
protocol is set to an odd parity, each data packet must have an odd parity. If it is set to
even, each packet must have an even parity. If a packet is received with the wrong parity,
an error will be produced and the data will need to be retransmitted. The parity bit for
each data packet is computed before the data is transmitted. Because the UART protocol
is asynchronous, it does not need a clock signal. In UART communication, speed is defined
by the baud rate. The baud rate is equal to the number of bits transmitted per second
including the start and stop bits. For reliable data transmission and reception without any
loss of bits, both the transmitter and receiver should have same baud rate. Mismatch in
baud rates typically results in framing error. Common baud rates are 4800, 9600, 19200,
38400, 57600, and 115200 but other rates may also be used.
Basically UART Is Divided Into Three Parts :
1) BoadRate Generator
2) Transmitter
3) Receiver

Baudrate Generator : The baud rate, often expressed in bits per second (bps), de-
fines the speed at which data is transmitted over the UART.The baud rate specifies the
number of bits transmitted per second. For example, a baud rate of 9600 means 9600 bits
are transmitted per second. To set the baud rate, you configure the baud rate generator
with a specific divisor value (often called the ”baud rate divisor”). The divisor is calculated
based on the system’s clock frequency and the desired baud rate using the formula: Baud
Rate Divisor = System Clock Frequency / (16 × Baud Rate) It is the number of Symbol
per second transferred.
UART DATA Frame : The UART transmitter receives data from a data source,
which could be a microcontroller, sensor, or any device that needs to send data. This data
is typically in a parallel format, meaning each bit of data is transmitted simultaneously on
multiple wires. The parallel data received from the source is converted into a serial format.
This means the data is sent bit by bit in a specific sequence, typically starting with the least
significant bit (LSB) and ending with the most significant bit (MSB). The serial format al-
lows for easier and more reliable transmission over a single wire.
Figure 10: UART Data Frame
UART Transmitter : The transmitter uses the TX Buffer, TX Shift, and TX Control
registers of a Digital Communications type PSoC block. The TX Control register is initial-
ized and configured using the UART User Module firmware API routines. When the Enable
bit in the TX Control register is set, an internal divide-by-eight bit clock is generated. A
data byte to transmit is written by an API routine into the TX Buffer register, clearing the
Tx Buffer Empty status bit in the TX Control register. This status bit can be used to detect
and prevent transmit overrun errors. The rising edge of the next bit clock transfers the data

to the Shift register and sets the Tx Buffer Empty bit in the TX Control register. If the
interrupt enable mask is enabled, an interrupt is triggered. This interrupt enables queuing
the next byte to transmit. So when the current data byte is completely transmitted, the
new byte is transmitted on the next available transmit clock. The start bit is transmitted
at the same time that the data byte is transferred from the TX Buffer register to the TX
Shift register. Successive bit clocks shift a serial bit stream to the output. The stream is
composed of each bit of the data byte, least significant bit first, an optional parity bit, and
a final stop bit. When the stop bit is completely transmitted, the TX Control register’s Tx
Complete status bit is set. This bit remains valid until read. If a new data byte has been
written to the TX Buffer register, the data byte is transferred to the TX Shift register and
transmission of the data begins on the next rising edge of the bit clock.
Figure 11: Transmitter FSM
• Start Bit:
Before transmitting the actual data, the UART transmitter sends a start bit to indicate the
beginning of a data frame. This start bit is always set to logic level 0 (low).
• Data Transmission:
After the start bit, the transmitter sends the data bits serially, one at a time, typically in a
predefined order (LSB to MSB or MSB to LSB). The data bits can be set to logic 0 or 1,
depending on the value of the data being transmitted.
• Parity Bits:
Some UART systems use a parity bit for error checking. The parity bit is an additional bit
transmitted after the data bits and can be set to odd or even parity. It helps detect errors

in the data transmission.

• Stop Bits(s) :
One or more stop bits are sent after the data bits (and optionally the parity bit). Stop bits
are always set to logic 1 (high). The purpose of stop bits is to signal the end of the data
frame and provide a clear boundary between successive frames.
• Idle State:
After transmitting the data and stop bit(s), the UART transmitter remains in an idle state,
with the transmission line set to a logic 1 (high) level until the next data frame needs to be
transmitted.
UART Receiver: The receiver uses the RX Buffer, RX Shift, and RX Control registers
of a Digital Communications type PSoC block. The RX Control register is initialized and
configured using the UART User Module firmware API routines. Initialization of the RX
consists of setting the UART parity, optionally enabling the interrupt on the Rx Register
Full condition, and then enabling the UART. When a start bit is detected on the RX input,
a divide-by-eight bit clock is started and synchronized to sample the data in the center of
the received bits. On the rising edge of the next eight-bit clock, the input data is sampled
and shifted into the RX Shift register. If parity is enabled, the next bit clock samples the
parity bit. The sampling of the stop bit, on the next clock, results in the received data byte
transfer to the RX Buffer register and the triggering of one or more of the following events:
• Serial Data Input (RX):
The UART receiver takes in serial data from the communication channel, which is typically
received on the RX pin of a microcontroller or a UART module.
• Baud Rate Configuration:
The UART receiver is typically configured with a specific baud rate, which determines the
data rate at which it expects to receive data. The transmitter and receiver must use the
same baud rate for successful communication.
• Framing and Synchronization:
The receiver looks for the start bit to identify the beginning of a data frame. It synchronizes
its internal clock with the incoming data to sample bits accurately.

Figure 12: Receiver FSM
• Data Reception:
As each bit of the data frame is received, the UART receiver stores the bits and performs
error checking, such as checking for framing errors or parity errors, if these features are
enabled.
• Buffering:
The received data is usually buffered in a receive buffer. This buffer can hold multiple data
frames, allowing the CPU or microcontroller to read the data at its convenience.
Error Handling:
The UART receiver may be configured to check for errors like parity errors, framing errors,
and overrun errors. When an error is detected, it can generate an interrupt or trigger an
error flag for the CPU to handle.
• Data Extraction:
The receiver extracts the data bits from each received data frame and may also check for
the correctness of the data using optional features like parity.
• Data Framing and Interpretation:
Once a complete data frame is received, the receiver prepares the data for the CPU or mi-
crocontroller to use. This may involve stripping away start and stop bits, removing parity
bits, and presenting the actual data to the application.

4.2 APB UART
This is a complete implementation of a UART. The UART contains the Above main sec-
tions That We Discuss In Previous Topics In This Section We Actual Implement The UART
Communication Via APB And Simulation Result And RTL Design We Can Discuss In Re-
sult And Discussion Section.
Figure 13: APB UART
Configuration registers are written and read by the processor. The baud rate generator
produces timing strobes at the baud rate (for the transmitter) and at 16 times the selected
baud rate (for the receiver). The UART clock can be asynchronous to the APB clock. The
receiver examines the incoming data and uses the first edge of the start bit to determine
the bit timing. The transmit and receive paths can be configured to use a single register
for data or to use FIFOs. Finite State Machines (FSMs) control the transmit and receive
sections. Various error conditions can cause an interrupt to be generated.

The APB - UART is a master/slave that enables serial communication between other
UARTs that are externally connected. Device states are read by the APB using status
registers that reflect the completion of UART data transfers. The controller also supports
the interrupt pin for indicating the transaction completion or any error in the controller.
Standard UART protocol consists of start/stop indicators, data, and parity information.
The serial bit stream uses the following sequence: Start bit, Data bits, parity bit, stop bit.
A bit called the Start Bit is added to the beginning of each word that is to be transmitted.
The Start Bit indicates the start of the data transmission and it alerts the receiver that a
word of data is about to be sent. Upon reception of the start bit, the clock in the receiver
goes into synchronization with the clock in the receiver. The individual bits of the word
of data are sent after the start bit. The Least Significant Bit (LSB) is sent first. The
transmitter does not know when the receiver has read the value of the bit. The transmitter
begins transmitting the next bit of the word on the next clock edge. A parity bit is added
when the entire data word has been sent. This bit can be used to detect errors at the
receiver side. Then one or two Stop Bits are sent by the transmitter to indicate the end of
the valid data bits.
We Can Perform Read And Write Operation Using UART Protocol Via APB Protocol.To
See Actual Results We Can Separated Discuss In Result Section.

4.3 I2C Interaction With APB
The I2C master needs to communicate with APB slave via I2C slave only. The data transfer
is checked out by APB master and it is transferred to APB slave. The data and address
valid signals are given by I2C slave signal. To read data, communication is done via APB
master to I2C slave to I2C master.
I2C :
I2C is a two-wire serial communication protocol using a serial data line (SDA) and a se-
rial clock line (SCL). The protocol supports multiple target devices on a communication
bus and can also support multiple controllers that send and receive commands and data.
Communication is sent in byte packets with a unique address for each target device. A
typical embedded system consists of one or more microcontrollers and peripheral devices
like memories, converters, I/O expanders, LCD drivers, sensors, matrix switches, etc. The
complexity and the cost of connecting all those devices together must be kept to a minimum.
The system must be designed in such a way that slower devices can communicate with the
system without slowing down faster ones.
To satisfy these requirements a serial bus is needed. A bus means specification for the con-
nections, protocol, formats, addresses and procedures that define the rules on the bus. This
is exactly what I2C bus specifications define. The I2C bus uses two wires: serial data (SDA)
and serial clock (SCL). All I2C master and slave devices are connected with only those two
wires. Each device can be a transmitter, a receiver or both. Some devices are masters –
they generate bus clock and initiate communication on the bus, other devices are slaves and
respond to the commands on the bus. In order to communicate with specific device, each
slave device must have an address which is unique on the bus. I2C master devices (usually
microcontrollers) don’t need an address since no other (slave) device sends commands to
the master.
Transmitter:This is the device that transmits data to the bus.
Receiver: This is the device that receives data from the bus.
Master: This is the device that generates clock, starts communication, sends I2C com-
mands and stops communication.
Slave: This is the device that listens to the bus and is addressed by the master.
Multi-Master:I2C can have more than one master and each can send commands.
Arbitration: A process to determine which of the masters on the bus can use it when more
masters need to use the bus.

Figure 14: I2C Frame Format
Figure 15: I2C FSM
Synchronization: A process to synchronize clocks of two or more devices.

Bus Signals: Both signals (SCL and SDA) are bidirectional. They are connected via resis-
tors to a positive power supply voltage. This means that when the bus is free, both lines are
high. All devices on the bus must have open-collector or open-drain pins. Activating the
line means pulling it down. The number of the devices on a single bus is almost unlimited.
The only requirement is that the bus capacitance does not exceed 400 pF. Because logical
1 level depends on the supply voltage, there is no standard bus voltage.
Serial Data Transfer: For each clock pulse one bit of data is transferred. The SDA
signal can only change when the SCL signal is low – when the clock is high the data should
be stable.
Start and Stop Condition: Each I2C command initiated by master device starts with
a START condition and ends with a STOP condition. For both conditions SCL has to be
high. A high to low transition of SDA is considered as START and a low to high transition
as STOP.
After the Start condition the bus is considered as busy and can be used by another master

Figure 16: Start Stop Condition
only after a Stop condition is detected. After the Start condition the master can generate
a repeated Start. This is equivalent to a normal Start and is usually followed by the slave
I2C address.
Microcontrollers that have dedicated I2C hardware can easily detect bus changes and
behave also as I2C slave devices. However, if the I2C communication is implemented in
software, the bus signals must be sampled at least two times per clock cycle in order to
detect necessary changes.
One of the reasons that I2C is a common protocol is because there are only two lines used
for communication. The first line is SCL, which is a serial clock primarily controlled by the
controller device. SCL is used to synchronously clock data in or out of the target device.
The second line is SDA, which is the serial data line. SDA is used to transmit data to
or from target devices. For example, a controller device can send configuration data and
output codes to a target digital-to-analog converter (DAC), or a target analog-to-digital
converter (ADC) can send conversion data back to the controller device. I 2C is half-duplex
communication where only a single controller or a target device is sending data on the bus
at a time. In comparison, the serial peripheral interface (SPI) is a full-duplex protocol
where data can be sent to and received back at the same time. SPI requires four lines for
communication, two data lines are used to send data to and from the target device. In ad-
dition to the serial clock, a unique SPI chip select line selects the device for communication
and there are two data lines, used for input and output from the target device. An I2C
controller device starts and stops communication, which removes the potential problem of
bus contention. Communication with a target device is sent through a unique address on
the bus. This allows for both multiple controllers and multiple target devices on the I2C

bus. The SDA and SCL lines have an open-drain connection to all devices on the bus. This
requires a pullup resistor to a common voltage supply.
Speed Mode: I2C has several speed modes starting with the Standard-mode (Sm), which
is a serial protocol that operates up to 100 kilobits per second (kbps). This mode is fol-
lowed by the Fast-mode (Fm) which tops out at 400 kilo bits per second. Fast-mode can be
used by the controller if the bus capacitance and drive capability allow for the faster speed.
Both of these protocols are widely supported. The Fast-mode Plus (Fm+) mode allows for
communication as high as 1 megabit per second (Mbps). To achieve this speed, drivers in
the devices require extra strength to comply with faster rise and fall times. These three
modes are relatively similar, using a communication structure that is the same. However,
all have different timing specifications for each of the modes and hardware implementation
of the I2C in the devices are different to accommodate the different speeds. I 2C also has
two other modes for higher data rates. High-speed mode (Hs-mode) has a data rate to 3.4
megabits per second. In this mode, the controller device must first use a controller code to
allow for high-speed data transfer. This enables high-speed mode in the target device. This
mode can also require an active pullup to drive the communication lines at a higher data
rate. Ultra-Fast mode (UFm) is the fastest mode of operation and transfers data up to 5
Mbps. This mode is write-only and omits some I2C features in the communication protocol.
I2C Data Transfer: Data on the I2C bus is transferred in 8-bit packets (bytes). There is
no limitation on the number of bytes, however, each byte must be followed by an Acknowl-
edge bit. This bit signals whether the device is ready to proceed with the next byte. For all
data bits including the Acknowledge bit, the master must generate clock pulses. If the slave
device does not acknowledges transfer this means that there is no more data or the device
is not ready for the transfer yet. The master device must either generate Stop or Repeated
Start condition.

4.4 APB I2C
This is a complete implementation of a I2C. The I2C contains the Above main sections That
We Discuss In Previous Topics In This Section We Actual Implement The I2C Communi-
cation Via APB And Simulation Result And RTL Design We Can Discuss In Result And
Discussion Section.
The I2C protocol uses a two-wire interface for bidirectional communications between the
devices connected to the bus. The two interface lines, SCL and SDA, are connected to a pos-
itive supply through pull-up resistors. Any device connected to the bus uses open-collector
or open-drain drivers and can only pull the respective bus line low. Therefore, both the SCL
and SDA are wiredAND type signals. The device that initiates the transaction becomes the
master of the bus. The bus master generates SCL and terminates the transaction once
finished. One data bit is transferred on SDA during each pulse on SCL. Data is sampled
during the high state of SCL and can change while SCL is low. Each data transaction is
composed of a start condition, a number of byte transfers, and a stop condition to end the
transaction. Each byte is transferred with the Most Significant Bit (MSB) first. After each
byte (8 bits), an acknowledge signal must follow. A slave device can stall the master by
extending the low period of the SCL clock while it handles the previous data or prepares
new data. This process can occur after each bit is transferred or on a byte boundary. The
slave stalls the bus by pulling SCL low to extend the clock-low period. Typically, slaves
extend the first clock cycle of a transfer if a byte read has not yet been stored or if the next
byte to be transmitted is not yet ready.
The I2C Interface provides full support for the two-wire I2C synchronous serial interface,
compatible with the ACCESS. Bus physical layer, with additional support for the SMBus
protocol, including Packet Error Checking (PEC). Through its I2C compatibility, it pro-
vides a simple interface to a wide range of low-cost memories and I/O devices, including:
EEPROMs, SRAMs, timers, A/D converters, D/A converters, clock chips, and peripheral
drivers. The I2C is the same I2C Interface IP is proven in high-volume devices. The host
interface of the I2C Interface complies with the AMBA 2 APB protocol. Control regis-
ters provide CPU control of Serial Clock Line (SCL) frequency, start and stop condition
generation, PEC byte generation, I2C address assignment, 7-bit or 10-bit addressing, and
enabling/disabling interrupts. Status registers indicate current operating mode, packet er-
ror, and interrupt status. A serial data register shifts the serial I2C data into and out of

Figure 17: APB with I2C
the I2C Interface during receive and transmit operations. The I2C serial interface consists
of the standard bidirectional I2C signals: Serial Clock Line (SCL) and Serial Data Line
(SDA).
Integrating an I2C controller as an APB (Advanced Peripheral Bus) component involves
designing the I2C controller to operate either as a master or a slave, interfacing it with the
APB to enable communication between the main system bus in a system-on-chip (SoC) and
external I2C devices. The APB, designed for low-bandwidth peripherals, provides a simple
and low-power interface with key signals such as PCLK (clock), PADDR (address), PSEL
(select), PENABLE (enable), PWRITE (write), PWDATA (write data), and PRDATA
(read data). In this integration, the I²C master controller initiates communication on the
I2C bus, generates necessary clock (SCL) and data (SDA) signals, and communicates with
I2C slave devices. Registers accessible via APB, including control, status, data, address,
and clock divider registers, manage the I²C controller’s operation. Conversely, an I2C slave
controller responds to communications initiated by an I2C master, managing addressing and
acknowledging signals with its own set of registers, such as the slave address register. This
setup allows an SoC, like a microcontroller, to communicate seamlessly with external I²C
peripherals, such as EEPROMs or sensors, by converting I2C protocol messages to APB
protocol signals, ensuring efficient and synchronized data transfer while maintaining low
power consumption and minimal latency. Key considerations for this integration include
clock synchronization, interrupt handling, robust error management, and power optimiza-
tion to ensure reliable and efficient communication within the system.

4.5 Software Design
We give a summary of the software simulation carried out in the questa sim and Modelsim
development environment in our project report, with particular attention to two important
elements:
UART (Universal Asynchronous Receiver-Transmitter) communication and APB (Advanced
Peripheral Bus) slave. Our project’s successful completion was largely dependent on these
simulations, and this succinct explanation sheds light on the procedure and its importance.
Flow Chart for VLSI Design The process of VLSI design is iterative. Several issues, includ-
ing functional, logic, circuit, and physical design, are involved in designing a VLSI chip.
The method of simulation is used to confirm the accuracy of the design. If any design flaws
are discovered during the verification phase, at least one of the earlier design steps needs to
be redone in order to fix the flaw.
Understand Specification : System specification: The objective of the desired final prod-
uct is written in this step. During system specification, the designated cost of the system,
its performance, architecture, and how the system will communicate with the external world
are to be determined. During this step, the design specification should be provided by the
users or clients.
Behavioural Implementation: Behavioral Implementation is a crucial stage in the VLSI
(Very-Large-Scale Integration) design flow. It involves the creation of a behavioral model
that describes the high-level functionality and behavior of the integrated circuit without
specifying the detailed hardware implementation.
Model Sim is a hardware design simulator commonly used for verification in VLSI design
flows. Here’s a breakdown of developing a BFM for an APB slave model using Model Sim:
Design Considerations:
• Functionality: The BFM should accurately model the slave’s behavior, including reg-
ister access, data manipulation, and response generation.
• Configurability : Allow configuration of the slave’s address space, register details, and
response behavior for flexibility during verification.
• Scalability: If the slave has multiple functionalities, consider a modular design for
easier maintenance.
• Interface: Define a clear interface between the BFM and the testbench environment

Figure 18: Design Flow
for easy integration.
BFM Implementation in Verilog: Both QuestaSim and ModelSim support Verilog for
hardware design. The implementation steps are similar:
• State Machine: Implement a state machine using Verilog’s case statements or FSM
constructs to handle different stages of the APB transaction (idle, address phase, data
phase).
• Register Modeling: Create register structures within the BFM using Verilog’s reg
keyword to represent the slave’s internal registers.
• APB Signals: Model the APB bus signals (PADDR, PENABLE, PWRITE, PRDATA,
etc.) using Verilog’s input and output keywords.
• Response Generation: Implement logic using Verilog conditional statements and as-
signments to generate appropriate responses (PRDATI, PREADY) based on the read/write
operation and register access.
Simulation Setup: Both simulators offer similar functionalities for setting up the simula-
tion:
• Create a Project:Start by creating a new project in either QuestaSim or ModelSim.
• Add Source Files:Add your Verilog source code files for the BFM and any necessary
libraries (e.g., IEEE libraries).
• Compile the Design: Use the simulator’s compiler to compile the BFM code and ensure
there are no syntax errors.

• Develop a Testbench:Create a separate Verilog module to serve as the testbench. This

module will generate APB transactions to stimulate the BFM.
• Instantiate the BFM and Testbench: In the testbench, instantiate the BFM and con-
nect its signals to the APB bus signals generated by the testbench.
• Run Simulation:Start the simulation and observe the behavior of the BFM using the
simulator’s waveform viewer. Analyze the interactions between the BFM and the
testbench to verify correct functionality.
Verification and Debugging:
• Test Scenarios: Develop test scenarios covering various functionalities of the slave
model, including basic read/write operations, corner cases, and error handling.
• Waveform Analysis: Use the simulator’s waveform viewer to analyze signals and ensure
the BFM responds correctly to different transactions.
• Debugging: Utilize the simulator’s debugging features (breakpoints, variable watch-

ing) to identify and fix any issues within the BFM.
Key Points:
• The specific functionalities of the BFM will depend on the specific APB slave model
you are trying to verify.
• Both QuestaSim and ModelSim offer similar functionalities for developing and simu-
lating Verilog code.
• Consider using a verification methodology like UVM for a more structured verification
approach, especially for complex BFM designs.

5 RESULTS
5.1 Implemented Designs
APB Implementation: As we Early Discuss In Above Section How To APB Works With
Respect To Their FSM And Operating States , As Well How UART Works With Different
Modules And I2c , Here We Discuss About The Implemented Result Of All Protocols With
Their Simulated Wave.
figureAPB Write and Read
In The Above Figure We Can See Actual Implementation Of APB Protocol With Re-
spect To Finite State Machine For Simple APB Implementation Of APB To Read And
Write From RAM 8bit Read Write Configuration.
To See Actual Implementation Of How Data Can Transfer Through The PWDATA To
External RAM And Peripheral.

Read Operation: In the below figure you can able to see Actual Implementation of
APB Protocol with Respect to Finite State Machine for Simple APB Implementation of
APB to Read from RAM 8bit Read Configuration.
In the context of digital design, simulating an APB (Advanced Peripheral Bus) slave write
operation involves emulating the process by which an external master device writes data
to a peripheral connected to the APB bus. This simulation typically entails crafting and
validating scenarios in which the APB slave correctly receives and processes write requests
from the master. The write operation involves passing data from the master to the slave, en
suring the proper interpretation and storage of the transmitted information, and validating
that the slave accurately acknowledges the successful write transaction. Through simula
tion, designers can thoroughly test the reliability and functionality of the APB slave’s write
operation before moving to hardware implementation, contributing to robust and error-free
system design
figure:Read Operation
Write Operation: In The below Figure We Can See Actual Implementation Of APB
Protocol With Respect To Finite State Machine For Simple APB Implementation Of APB
To Write From RAM 8bit Write Configuration.
In the context of digital design, simulating an APB (Advanced Peripheral Bus) slave write
operation involves emulating the process by which an external master device writes data
to a peripheral connected to the APB bus. This simulation typically entails crafting and
validating scenarios in which the APB slave correctly receives and processes write requests

from the master. The write operation involves passing data from the master to the slave, en
suring the proper interpretation and storage of the transmitted information, and validating
that the slave accurately acknowledges the successful write transaction. Through simula
tion, designers can thoroughly test the reliability and functionality of the APB slave’s write
operation before moving to hardware implementation, contributing to robust and error-free
system designs.
figure:Write Operation
figure:Questa Implementation

Transcript:In Below figure you can see Actual PWRITE, PRDATA, PREADY, PW-
DATA every operation how many bit memory required. This APB operations run in Ques-
tasim Software.The Transcrpit Prompt Shows The Actual APB Read And Write log From
PWDATA As Shown In Figure Of Transcript.
figure:Transcript in Questasim
figure:RTL View
RTL View Shows The Gate And Combinational Circuit Under The DUT , Which Is Imple-
mentation Of HDL To Corrrelate The Design And Specification Of Device. From The RTL
View We Can See The Gate Level Implementation At Front End Side.

UART Implementation: Simulating a UART baud rate generator’s waveform is an

essential step in the design and verification process. This simulation generates a visual
representation of how the baud rate generator sets the timing for serial data transmission
and reception. By examining the waveform, designers can verify that the generated clock
signals and data bits align correctly, ensuring that data is transmitted at the intended rate.
The simulation helps identify any timing issues or discrepancies, allowing for adjustments to
achieve precise baud rate settings, ultimately ensuring reliable serial communication within
the UART system.
figure:Baudrate Waveform
figure:TX/Rx UART

Simulating UART (Universal Asynchronous Receiver-Transmitter) transmitter (TX) and

receiver (RX) waveforms is a fundamental aspect of UART design and verification. During
this simulation, the waveforms depict the data transmission process, showing how parallel
data is converted into serial format and transmitted by the TX, and how the RX interprets
the received serial data, converting it back into parallel form. The waveforms include start
and stop bits, data bits, and potential error detection signals like parity or checksum. By
analyzing these simulated waveforms, designers can ensure the UART’s proper operation,
verify data integrity, and identify and address potential issues such as synchronization prob
lems or signal glitches, ultimately guaranteeing accurate and reliable serial communication
in the UART system.
I2C Implementation: we are completed some operations of I2C but we have need to
more study on I2C and then Implement it some operations successfully run in Questasim
but some difficulty faced during this operations. we will focus on I2C in Future and Imple-
ment it successfully.
figure:I2C Implementation

6 CONCLUSION
The project involves the development of a functional model for an Advanced Peripheral
Bus (APB) slave in VLSI design. The problem at hand is to create a hardware description
of an APB peripheral that accurately represents its behavior, interaction with the APB
bus, and functionality. This entails defining the specifications, designing a state machine,
implementing the RTL design. The ultimate goal is to provide a robust and compliant
component for integration into a larger VLSI system while ensuring proper functionality,
timing constraints, and documentation. The proposed solution involves a systematic ap-
proach to develop a comprehensive APB slave model in VLSI design. We Can Design Bus
Functional Model For APB Slave AMBA Based Using VLSI Design , We Implemented APB
Simple Read And Write Operation Using Vivado And Questasim For Design And Simulate
The Waves To See Actual Read And Write As Well We Implemented The UART And I2C
Via APB Bridge . Approach Is Too Learn The Device Specification , Requirements And
Functionality And Design Functional Models For Different Protocol Using VLSI Design.

References
[1] Deekshith Krishnegowda, Developing a Bus Functional Model for APB slave
using Universal Verification Methodology.
[2] Aparna Kharade1 and V. Jayashree, VLSI DESIGN OF AMBA BASED

AHB2APB BRIDGE.
[3] Heli ShahP, PR,RP PChinmay ModiP, P,Bhargav TarparaP, Design Imple-
mentation of Advance Peripheral Bus Protocol.
[4] M.Kiran Kumar, Amrita Sajja2 Dr.Fazal Noorbasha,Design and FPGA Im-
plementation of AMBA APB Bridge with Clock Skew Minimization Tech-
nique.
[5] Vaishnavi R.K1, Bindu.S2, Sheik Chandbasha3 Design and Verification of

APB Protocol by using System Verilog.
[6] AMBA Specification (Rev 2.0)
[7] Flynn, D. Adv. RISC Machines Ltd., Cambridge, “AMBA:enabling reusable

on-chip designs”, IEEE Micro, Publication Date: Jul/Aug 1997.
[8] Prakash, Peram Bhanu, Panta Nishith Reddy, Maddireddy Sathish Reddy,
Rachapalyam Vignesh Kumar, and G. Bharatha Sreeja. Design of AMBA
Based AHB2APB Bridge Protocol. No. 7890. EasyChair, 2022.
[9] Shankar, Girdhar, D., Shukla, N. (2014). Design and Verification of AMBA
APB Protocol. International Journal of Computer Applications, 95, 29-35
[10] A. Suresh and S. Nandi, ”Physical Bridge Design for High Performance
to Peripheral Bus: An Open Source Approach,” 2020 Third International
Conference on Advances in Electronics, Computers and Communications
(ICAECC), 2020, pp. 1-5, doi:10.1109/ICAECC50550.2020.9339522
[11] PARIKI MANASA1, B. PADMINI2, S. NAGI REDDY, ”Design of an I2C

Master Interfacing with APB Bus”
[12] Mukthi S. L.1, Dr. A. R. Aswatha2Design and Implementation of an Inter-

facing Protocol between I2C and APB for an AMBA Based SOC.
41
Appendix
A. User Surveys and Feedback
We have gone through the user feedback on the current Abacus practice applications. Users
have concerns about the dynamic User Interface and time complexity. They want features
like Average answer submission time for the tracking of accuracy with time. Some potential
users also want to configure their questions according to the dynamic needs of a variety
of question types. After using this Application potential users with the above demands
gave a positive response and were satisfied with the key features of the application. So we
are motivated to improve its key functionality and add features for potential users in the
upcoming days.
B.Sample abacus Problem Sets
Users can practice the modes of questions provided in the application or they can con-
figure their questions with multiple operators and operands.
Example:
1. x + y2
2. (x+y)*(x-y)
3. x2 + y 2
4.xn − xm
5.x ∗ y/z
Inthismanner, userscanconf igureavarietyof questionsusingmultipleoperatorsandoperands.
C.Link
V isitthislinkf oruse :
https : //snack.expo.dev/@adityapatil687/abacus
Plagiarism report
A ug 2 0, 2 02 3
Adi ty a Na vn i t Pa ti l
has successfully completed
React Native
an online non-credit course authorized by Meta and offered through Coursera
Veri f y a t :
ht t ps://coursera .org /veri f y/B P9H 6C RVXH S W
Cour se r a ha s conf ir m e d t he ide nt it y of t his individua l a nd t he ir
pa r t icipa t ion in t he cour se .
A ug 2 2 , 2 02 3
Adi ty a Na vn i t Pa ti l
has successfully completed
React Basics
an online non-credit course authorized by Meta and offered through Coursera
Veri f y a t :
ht t ps://coursera .org /veri f y/RXXY U 4U XKFZG
Cour se r a ha s conf ir m e d t he ide nt it y of t his individua l a nd t he ir
pa r t icipa t ion in t he cour se .
To verify this certificate visit verify.mygreatlearning.com/UGFUDYZR

BE Project Final Report

Uploaded by

Copyright:

Available Formats

You might also like

BE Project Final Report

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BE Project Final Report

Uploaded by

Copyright:

Available Formats

PROJECT REPORT

DEVELOPING BUS FUNCTIONAL MODEL

Submitted in Partial Fulfilment of the

Under the Guidance of

Savitribai Phule Pune University

Vidya Pratishthan’s Kamalnayan Bajaj Institute of Engineering & Technology, Baramati

This is to Certify that the Project Report Entitled

“Developing Bus functional Model For APB Slave Using VLSI

is a bonafide work carried out satisfactorily by them under supervision and

Mrs. V. S. Surwase Dr. B. H. Patil

List of Abbreviation vii

4 Interaction With Peripherals 18

Department of E & TC 1 VPKBIET,Baramati

Department of E & TC 2 VPKBIET,Baramati

Department of E & TC 3 VPKBIET,Baramati

1.3 Foreground AMBA Architecture

An AMBA-based microcontroller typically consists of a high-performance system backbone

Figure 1: AMBA Architecture

chip communications standard for designing high-performance embedded microcontrollers.

• the Advanced High-performance Bus (AHB)

• to facilitate the right-first-time development of embedded microcontroller products with

Department of E & TC 4 VPKBIET,Baramati

• have interfaces which are memory-mapped registers

1.4 Introduction To AMBA APB

Department of E & TC 5 VPKBIET,Baramati

• no special considerations are required for automatic test insertion

Department of E & TC 6 VPKBIET,Baramati

VLSI Design AHB AMBA2 APB:Aparna Kharade1 and V. Jayashree2 implemented

Department of E & TC 7 VPKBIET,Baramati

PARIKI MANASA1, B. PADMINI2, S. NAGI REDDY, ”Design of an I2C Master Inter-

Department of E & TC 8 VPKBIET,Baramati

Mukthi S. L.1, Dr. A. R. Aswatha2Design and Implementation of an Interfacing Protocol

Department of E & TC 9 VPKBIET,Baramati

3.1 APB Protocol

Figure 2: APB Block Diagram

Department of E & TC 10 VPKBIET,Baramati

Figure 3: Timing Diagram

Department of E & TC 11 VPKBIET,Baramati

AMBA APB Signal Description :

Figure 4: Signal Description

Department of E & TC 12 VPKBIET,Baramati

3.2 APB Transfers

Figure 5: With No Wait Write Transfer

Department of E & TC 13 VPKBIET,Baramati

Figure 6: With Wait Write Transfer

• Enable signal, PENABLE

with Wait State :

Department of E & TC 14 VPKBIET,Baramati

Figure 7: With No Wait Read Transfer

Figure 8: With No Wait Read Transfer

• Protection signal, PPROT

Department of E & TC 15 VPKBIET,Baramati

3.3 Operating States

The state machine operates through the following states:

Figure 9: Finite State Machine

Department of E & TC 16 VPKBIET,Baramati

Department of E & TC 17 VPKBIET,Baramati

4 Interaction With Peripherals