Hardware Implementation of AMBA Processor Interface Using Verilog and FPGA Iqbalur Rahman Rokon, Toufiq Rahman, and Ahsanuzzaman Abstract - In this paper, the design of AMBA processor interface and its hardware implementation are described. The interface between high-performance AMBA bus AHB and low performance AMBA bus APB is created in this work. Then two target devices register and Ram are connected to APB side to perform read/write operation through the designed interface commanding from AHB side. All the major signals of AHB and APB are used in this design. First, a block diagram is shown with some sub-blocks. Then a flow of interactions of sub-blocks is presented. After that, the flow of design of the testbench, AHB to APB interface, register, and RAM is shown starting from the top level. Next, hand-drawn waveforms of all the associated signals are given. Then comes the heart of the design the state machine. After that, simulation results are shown and in the end, conclusion is drawn discussing some areas of possible improvement in the future. Keywords AMBA Protocol, AMBA Processor Interface, FPGA, Verilog T I. INTRODUCTION HE Advanced Microcontroller Bus Architecture (AMBA) is a protocol that is used as an open standard, on-chip interconnect specification for the connection and management of functional blocks in a system-on-chip (SoC) [1]. AMBA assists the progress of right-first-time development of multiprocessor designs with large number of controllers & peripherals [2]. The Advanced Microcontroller Bus Architecture (AMBA) has the ability to re-use designs and here it means it has the ability to re-use IP. IP re-use in today s technology is an important factor in reducing the development costs and timescales for System-on-chip (SoC) [3]. AMBA is a standard interface specification that makes sure of the compatibility between IP components provided by different design teams or vendors. The world wide reception of AMBA specifications all over the semiconductor industry has driven a comprehensive market in third party IP products Mr. Iqbalur Rahman Rokon is with the department of Electrical Engineering and Computer Science, North South University, Dhaka 1213, Bangladesh e- mail: irahman@northsouth.edu Toufiq Rahman is a graduate student from the department of Electrical Engineering and Computer Science, North South University, Dhaka 1213, Bangladesh e-mail: ullash_nsu@yahoo.com Ahsanuzzaman is a graduate student from the department of Electrical Engineering and Computer Science, North South University, Dhaka 1213, Bangladesh e-mail: ahsanmars@hotmail.com and tools to support the development of AMBA based systems. There are three distinct buses defined within the AMBA specification - Advanced High Performance Bus (AHB), Advanced System Bus (ASB), and Advance Peripheral Bus (APB). This paper deals with AHB and APB. AHB: It is for high performance, high clock frequency system modules. The AHB works as the high-performance system backbone bus. AHB supports the efficient connection of processors, on-chip memory and off-chip external memory interfaces with low power peripheral macrocell functions. AHB is also specified to ensure ease of use in an efficient design flow using synthesis and automated test techniques [4]. APB: Advanced Peripheral Bus (APB): The AMBA APB is for low-power peripherals. APB is made perfect for minimum power consumption and reduced interface complexity to support peripheral functions. APB can be used in conjunction with any of the version of the system bus [4]. II. INTERFACE TOP BLOCK DIAGRAM Fig. 1 Block diagram A. State Machine This is a very vital block for the interface. It determines when different output signals will come in effect. Two most significant signal of this block is nextstate and currentstate both of which are 3 bit signals. To generate nextstate some other signals are needed like HWRITE, registered version of HWRITE (rghwrite), accept and currentstate as well. nextstate 194
and currentstate will be used as internal input signals in other blocks. IV. DESIGN FLOW B. Write Output Generator A DFF is used to implement this sub-block. It will take HCLK, HRESET and HWDATA as input and drive the output to PWDATA. Asynchronous reset is used here. C. Read Output Generator Another DFF is used to implement it. It will take HCLK, HRESET and PRDATA as input and drive the output to HRDATA. It uses asynchronous reset. D. Address Decoder This block the target device for the transfer. It compares the 4 most significant bits of HADDR and compares with some constants to determine whether RAM or register is intended for the transfer. A. Write Transfer Fig. 3 Design flow V. HAND-DRWAN TIMING DIAGRAMS E. APB Address and Control Output Generator This section is responsible for generating all other outputs in the APB side including PADDR, PWRITE, PENABLE. This section take input from state machine, AHB master side and some internal signals as well. F. AHB Transfer Output Generator This section is in the charge of generating transfer done output HREADYOUT and response output HRESP signals. HREADYOUT is generated basically from state machine and AHB inputs. HRESP is always set to 00 to show that the transfer has completed successfully. III. FLOW OF INTERACTIONS OF SUB-BLOCKS Fig. 4 Write transfer diagram Fig. 2 Interaction-flow of sub-blocks Fig. 4 Continued 195
B. Read Transfer Fig. 4 Continued Fig. 5 Continued VI. STATE MACHINE DETAILS Fig. 5 Read transfer diagram Fig. 6 State machine A. IDLE State During IDLE state, the APB bus signals and PWRITE transfer direction output are driven with the last values they had. PSEL xx and PENABLE signals are kept low. - HRESET = 0 when the system is initialized - READOK, WRITEOK or IDLE, when there are no peripheral transfers - READ for a read transfer when the AHB contains a valid read transfer request. - WWRITE for a write transfer when the AHB contains a valid write transfer request Fig. 5 Continued B. READ State 196
During this state the address is decoded and the relevant PSEL signal is driven high. Moreover, PWRITE is driven low and HADDR is driven onto PADDR. The READ state is entered from IDLE, READOK, WRITEOK or PNDWRITEOK during a valid read transfer. The next state will always be READOK. C. WWRITE State This state is required due to the pipelined structure of AHB transfers. It allows the AHB side of the write transfer to complete so that the write data becomes available on HWDATA. The APB write transfer is then started in the next clock cycle. This state is entered from IDLE, READOK or WRITEOK during a valid write transfer. The next state will be: - WRITE if there is no transfer request from the AHB side. - PNDWRITE if there is a valid transfer request from the AHB side. D. WRITE State During this state the address is decoded and the relevant PSEL signal is driven high. Moreover, PWRITE is driven high and HADDR is driven onto PADDR. - WWRITE when there is no further peripheral transfer - PNDWRITEOK when the currently pending peripheral transfer is a write and there is no further transfer - WRITEOK when there is no further peripheral transfer - PNDWRITEOK when there is one further peripheral write transfer E. PNDWRITE State During this state the address is decoded and driven onto PADDR, the relevant PSEL line is driven high, and PWRITE is driven high. - WWRITE when there is a further peripheral transfer to - PNDWRITEOK when the currently pending peripheral transfer is a write, and there is a further transfer The next state will always be PNDWRITEOK. F. READOK State During this state the PENABLE output is driven high The READOK state is always entered from READ. - READ when there is a further peripheral read transfer - WWRITE when there is a further peripheral write transfer - IDLE when there is no further peripheral transfer to G. WRITEOK State During this state the PENABLE output is driven high, This state is always entered from WRITE. - READ when there is a further peripheral read transfer - WWRITE when there is a further peripheral write transfer - IDLE when there is no further peripheral transfer to H. PNDWRITEOK State During this state the PENABLE output is driven high, - WRITE when there is a valid transfer request from the AHB side. - PNDWRITE. - READ when the pending transfer is a read. - WRITE when the pending transfer is a write and there is no further transfer - PNDWRITE when the pending transfer is a write and there is a further transfer 197
VII. SIMULATION ENVIRONMENT Fig. 7 Simulation environment It should be noted that two signals HRDATA and PRDATA are used in a different way in this paper. PRDATA is connected to both register and RAM. Due to the limitations of simulation softwares, PRDATA and HRDATA are not getting expected values with PRDATA connected to both register and RAM. That is why two signals are used for each of these read data bus signals PRDATA1 (for register), PRDATA2 (for RAM) instead of PRDATA & HRDATA1, HRDATA2 instead of HRDATA. Verilog HDL is used to implement the interface [5]. VIII. SIMULATION RESULTS and signals associated with AHB and APB, and learnt more in-depth about the verilog HDL coding. Still, there is some room for improvement in this paper. To name a few: burst transfer between AHB and APB are not shown here. The size of the data bus of AHB and APB signals and the size of RAM and register memory are same (32 bits). In future the authors are interested to develop the interface for burst transfers. Also, they want to use RAM and register with different memory size in comparison with AHB and APB data bus size. ACKNOWLEDGMENT At first the authors would want to thank the Almighty for giving them the strength and courage to begin and complete this paper. Then they would like to mention their parents who supported them with mental and financial support. They also convey their gratefulness to the Chairman of EECS Department Dr. Abdul Awal for helping them with his wise advice. They also thank all those people who helped them in any way regarding this paper and enriched them with different ideas and lot of support. REFERENCES [1] Advance Microcontroller Bus Architecture (AMBA) http://en.wikipedia.org/wiki/advanced_microcontroller_bus_architectu re [2] ARM. AMBA Open Specifications. http://www.arm.com/products/system-ip/amba/amba-openspecifications.php [3] ARM Launches AMBA Compliance Program and AMBA Compliance Testbench http://www.design-reuse.com/news/4818/arm-amba-compliance -program-amba-compliance-testbench.html [4] AMBA Specification http://polimage.polito.it/~lavagno/esd/ihi0011a_amba_spec.pdf [5] Palnitkar, S. (2006). A Guide to Digital Design and Synthesis (2 nd ed). India: Dorling Kindersley Pvt. Ltd. Fig. 8 Simulation results Fig. 8 Continued IX. CONCLUSION This paper presents an efficient design of AMBA processor interface. The authors are really satisfied with it. They learnt a lot of things regarding basic AMBA bus, different features 198