Overview
The DDMA is a four-channel Direct Memory Access Controller. Its purpose is to transfer data between memories and peripherals to reduce CPU utilization during data transfers. It can be programmed by the CPU via a 32-bit or 8-bit native interface. The DDMA can perform data transactions of configurable size over 32-bit address space. A single transaction size can be set in a range from 1B to 16MB. To limit the negative impact of different reads and writes timing the DDMA features transfer data buffer. This buffer is a 32-bit FIFO memory with configurable depth.
Data transactions can be triggered either by hardware or software. Hardware initialization is achieved via the Peripheral Request Interface, while software initialization is done by the CPU via registers. The Peripheral Request Interface is used by external controllers (peripherals) to set data transaction requests on specific DDMA channel. Each of the DDMA channels has a set of Peripheral Request Interface signals associated with it. Peripherals can request the transmission or reception of data. When multiple channels await data transfer the arbitration process utilizes a round-robin algorithm.
There are four DDMA channels. Each has its configuration registers and enable bit.
The DDMA offers three transfer modes:
* SINGLE – single data transfer on request,
* NORMAL – one data block transfer on request,
* BLOCK – all data blocks transfer on request.
They are distinguished by the amount of data transferred on a single request. Data transaction is divided into blocks. It is possible to configure the number of block bytes and blocks in a transaction. Data transfer is performed between the data source and the data destination. The DDMA channel can perform reads and writes on 32-bit, 16-bit, and 8-bit data which is separately configurable for both source and destination. Source and destination addresses can be freely configured.
The DDMA offers three addressing modes:
* INC – increment address after each data access,
* DEC – decrement address after each data access,
* FIXED – the address is fixed.
Apart from the above, the IP Core has three sources and destination address reload options:
* TRANSACTION – address is reloaded after the full transaction,
* BLOCK – the address is reloaded with each block transferred,
* NEVER – the address is never reloaded.
Address, block, and byte registers are double-buffered so that if they are changed while the channel is busy, the change does not take effect until the current data transfer is over.
Each channel has status and transfers status flags. Channel status is defined as BUSY, PENDING, or IDLE. Transfer status flags inform about the amount of data that has been sent by the channel. Proper flags are set after transmitting a single data, block, or transaction. Each transfer status flag is masked which allows for generating an interrupt request when a specific data transfer situation occurs.
Learn more about DMA IP core
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.
By Dany Nativel, Jacko Wilbrink and Tim Morin
As SoC architectures adopt AMBA® 5 fabrics and components, many proven IP blocks still rely on AMBA® 4 or earlier interfaces. That creates a common integration problem: how do designers connect newer AMBA® 5 system components to existing IP without redesigning the IP or replacing verified blocks?
This article shares our experience using Google’s FlatBuffers library as a memory subsystem stress test on the Andes AX46MPV RISC-V core.
This work investigates a novel threat model in which standard cells are considered untrusted. Our proposed threat model provides the design house with a tampered standard cell library. The intended netlist is synthesized and implemented using the tampered library.
