|
|||
DMA IP Integration1. ABSTRACT There are many IP’s today . These IP’s can be simple IP’s like Timer to complex IP’s like Accelerators. In Most of the cases IP’s are Integrated in standard way. There are cases where you have the option of Integrating it differently. This goes un-noticed or unable to be implemented due to time constraints. One such IP that would be discussed in this paper is DMA . This paper tries to explain idea of Integrating Direct Memory access(DMA) and Interrupt Control Unit(ICU) differently but final implementation requires some changes in IP. There is a possibility that alternate design explained below may be already implemented. ARM Primecell DMA is used for explaining the Designs. 2. INTRODUCTION The Alternate design that would be discussed in the below sections requires changing the IP design of DMA and ICU block. Therefore this paper only talks about the idea that can be utilized but may not be applicable in most of the current IP’s . Secondly, It may not be advantageous in some cases. Every design comes with advantages and disadvantages. Final Decision is left to Reader. Advantages and functioning are explained on case by case basis and restrictions are explained in separate section. 3. DESIGN 3.1 Current Design In the current Design, peripheral signals like DMACBREQ, DMACLBREQ , DMACSREQ, DMACLSREQ are used for Integrating peripheral and DMA. These signals are connected to DMA in most of today’s Designs and is used by peripherals to transfer or receive data(requesting or ready to transfer). All these signals is acknowledged by DMA with DMACCLR. Figure Below shows the current Design used in most of the SOC Figure 1 Before going in to further details, a small brief on these signals and definition of flow controller
DMACBREQ: This signal is used by the peripheral to DMA ,informing that it is going to transmit or ready to receive burst of data. Burst can be 4,8 or 16 bytes. When large amount of data needs to be transmitted then it is sent in burst of bytes. e.g: If 32 bytes have to be transmitted , if the burst size is 4 then there would be 7 DMACBREQ and the last DMACBREQ or 8th DMACBREQ is called as DMACLBREQ. DMACLBREQ: The last burst request of DMACBREQ is called as DMACLBREQ.
DMACSREQ: It is used by peripheral to indicate that it is ready to transmit or receive single byte of data. As explained if 32 bytes have to be transmitted , then 31 times DMACSREQ is sent and the 32nd DMACSREQ is called as DMACLSREQ.
The last single request is called as DMACLSREQ. Depending on the peripheral IP, burst(DMACBREQ, DMACLBREQ) or single request (DMACSREQ DMACLSREQ) is tied low. In some cases both of them are used. The interrupts raised using this design is Terminal count Interrupt and Error interrupt or DMACINTR (error and terminal count combined). Terminal Count Interrupt is raised by the DMA when the last byte has been transferred Error Interrupt is raised when there is an error during the transfer
Hardware block which is responsible for indicating the end of transfer.
Figure 2
The changes that is required is the addition of status registers in addition to the existing status register The new status register will have the following bits 1. DMACBREQ and DMACLBREQ 2. DMACSREQ and DMACLSREQ There are 2 options for the adding these registers. These registers can be added in Interrupt control block IP or DMA IP. These status registers identify the peripheral which has generated the interrupt.
3.4 Alternate Design2
Each bit corresponds to peripheral number. Similarly there should be interrupt clear register for clearing the interrupts. Typically terminal count interrupt is used for identifying the end of transfer. With the new design Burst request or single request Interrupts can also be used which increases the system efficiency The Below cases explains the advantage of the design. In all the cases peripheral is considered as the flow controller. Note: When DMA is made the flow controller, DMACBREQ is the only interrupt that can be used when data transfer is between memory to peripheral whereas if the data flow is from peripheral to memory then DMACSREQ can also be used. To make the explanation simpler only peripheral as flow controller is considered. Case 1: The data flow is from memory to peripheral and when LBREQ Interrupt is utilized In this scenario peripheral issues the BREQ signal, which is followed by the burst of data from DMA(memory) to peripheral , when the last burst of data has to be received peripheral sends LBREQ request to the DMA block. As per the alternate design, there would be interrupt when last 4 bytes(8 byte or 16 byte) have to be transmitted from DMA block. As a result , there would be some time gap between LBREQ interrupt and Terminal count (TC)interrupt which can be used to perform various tasks(Terminal Count interrupt is generated when the last byte of data is transmitted from DMA block, status is known in the last byte of transfer.). The term task is very generic, it depends on a. SOC Design b. Firmware Design
transfer(DMACLSREQ) Note: Single request (DMACSREQ) is not used as it may result in interrupt for every byte which may slow down the process. Therefore only last single request is considered(DMACLSREQ). Let us assume that 10 bytes have to be transmitted and Last Single Request or LSREQ is used(enabling interrupt for LSREQ and TC only). Though the time difference between LSREQ and terminal count(TC) interrupt is very less but it is significant enough to be used for real time applications. This time can be used effectively for some of the activities. As it is the last byte, we can clear the data fifo of the peripheral (if memory mapped). The clearing should not affect the last data that is being transmitted as the data would be placed in the bus line when LSREQ interrupt is raised or data transmission would have completed. If it is later then TC interrupt would be in the pending state as we are already in ISR because of LSREQ interrupt. Is it advantageous over Terminal count Interrupt? It is ineffective to have two interrupts communicating the same message. As LSREQ gives forehand information which is important for any application than Terminal count. LSREQ may be best suited in most of the cases.
This is useful for readying the next set of data (memory to peripheral) especially when BREQ is used. If there is a design where module1 data needs to be written to module2 . Based on the count module1 data can be read and stored in memory for transmission to the module2. In this case it is assumed that module1 does not have DMA interface capability (e.g: camera). For understanding let us assume that 40 bytes needs to be transmitted to module 2. When BREQ (each Burst is set for 4 bytes)count reaches 5, firmware can be designed to use this count to read the data from module1. When LBREQ interrupt is asserted, module 2 can be readied for next transfer.
Software handler for this design is explained. There is always better way of writing this handler but the current handler is explained for better understanding of the design. Isr_handler_peripheral(){ If(LBREQ_INTERRUPT_STATUS_REGISTER !=1) } { // LAST Burst Request interrupt has been raised } Read the status register to identify the peripheral which generated this interrupt Perform the task as per the requirement If(LSREQ_INTERRUPT_STATUS_REGISTER !=1) { // LAST Single Request interrupt has been raised } Read the status register to identify the peripheral which generated this interrupt Perform the task as per the requirement If(BREQ_INTERRUPT_STATUS_REGISTER !=1) { // Burst Request interrupt has been raised } Read the status register to identify the peripheral which generated this interrupt Burstreq_count_channel_number+=1; // Here 20 is just a number , it can be any as per requirement If(Burstreq_count_channel_number ==20) { Perform the task as per the requirement } // As explained above it can be reading the data from module1 If(SREQ_INTERRUPT_STATUS_REGISTER !=1) { // Single Request interrupt has been raised } Read the status register to identify the peripheral which generated this interrupt singlereq_count_channel_number+=1; // Here 20 is just a number , it can be any as per requirement If(singlereq _count_channel_number ==20) { Perform the task as per the requirement } // As explained above it can be reading the data from module1
1. Connecting the peripheral signals to Interrupt lines will consume interrupt lines on ICU block 2. In ideal case 16 peripherals can be connected, but with this design not many peripheral’s can be connected. Connecting all peripheral signals to ICU is close to impossible. 3. Difficult when two peripheral asserts interrupt at the same time. In such cases, priority of handling two requests is determined by software which may reduce efficiency in some cases. 4. Peripheral to peripheral data transfer may be difficult
1. With this design we have control over data transfer. Where as in the old design you do not know the number of bytes transferred. e.g. After 12 bytes if the transfer need to be stopped , we can stop it by disabling the channel 2. Data transfer is known only at the end in the old design whereas with the new design data transfer is known at various stages 3. Time can be utilized in Real time applications when BREQ interrupts are used.
This Design could be useful when large burst of data transfer. The usage depends on the final SOC and firmware design. As mentioned in the initial sections, this is just an idea. Implementation depends on the application, and Design. 5. References PrimeCell DMA Controller (PL080) Technical Reference Manual from ARM 6. Contact: For comments and feedback , I can be reached at gurushesha@gmail.com guruvadhiraj@gmail.com mobile : +91-9739817849 Guruprasad Have 11 years of experience in Low Level Drivers for ARM, IP verification, IP validation and have worked on Analyzing the performance of ARM. Working as verification lead at Global Edge software |
Home | Feedback | Register | Site Map |
All material on this site Copyright © 2017 Design And Reuse S.A. All rights reserved. |