DMA IP Integration
1. 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
3.2 SIGNALS
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.
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
FLOW CONTROLLER:
Hardware block which is responsible for indicating the end of transfer.
3.3 Alternate Design1
Figure Below shows the Alternate Design that can be used in most of the SOC
Figure 2
3.3.1 Description
This is particularly useful when peripheral is made the flow controller. As shown in the diagram All the request lines from the peripheral (DMACBREQ, DMACLBREQ , DMACSREQ, DMACLSREQ)is also branched to Interrupt control Block. As a result some changes or addition may be required in ICU block.
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
The signals can also be brought out of DMAC . In such a case the status registers must be added within DMAC IP. These registers would be in addition of TC status register.
3.5 Status Register
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
Case 2: Data flow is from peripheral to memory using Last single request
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.
Case 3: Data flow is from memory to peripheral using Burst request transfer(BREQ) and Last Burst Request (LBREQ)
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.
Note: Though the single Request (DMACSREQ) is also connected to the ICU, it can be seldomly used as we do not want interrupt to be generated for every byte . So for single byte only LSREQ is best advisable.
3.5.1 Software Handler:
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(){
{
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)
{
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)
{
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)
{
// As explained above it can be reading the data from module1
If(SREQ_INTERRUPT_STATUS_REGISTER !=1)
{
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)
{
// As explained above it can be reading the data from module1
3.5.2 Constraints or Restrictions of the Alternate Design:
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
3.5.3 Advantages:
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.
4. Conclusion
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
Related Articles
- Simplifying analog and mixed-signal design integration
- Creating SoC Designs Better and Faster With Integration Automation
- Shift Left for More Efficient Block Design and Chip Integration
- Using PSS and UVM Register Models to Verify SoC Integration
- Synopsys 3DIO Solution for Multi-Die Integration (2.5D/3D)
New Articles
- Quantum Readiness Considerations for Suppliers and Manufacturers
- A Rad Hard ASIC Design Approach: Triple Modular Redundancy (TMR)
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- UPF Constraint coding for SoC - A Case Study
- Dynamic Memory Allocation and Fragmentation in C and C++
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)
E-mail This Article | Printer-Friendly Page |