Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
11 years ago

Cyclone V SX SoC - DMA Controller Peripheral Request Interface

Hi guys,

I am trying to find out how the DMA peripheral request interface could be used.

In the HPS component Interface description(cv_54028) and in the DMA Controller description(http://www.altera.com/literature/hb/cyclone-v/cv_54016.pdf) is no information how the fpga peripheral request interface must handled.

my specific question is how is the burst length determined at fpga logic peripheral requests??

In the DMA Controller description is Peripheral Length Management and DMA controlled length management possible.

I need Peripheral Length Management, but there are not the same signals like in the DMA Controller Interface description...:confused:

I hope someone have experience with this. Thanks a lot for your Support !

(From HPS component Interface description)

--- Quote Start ---

peripheral signal interfaces

The DMA controller interface allows soft IP in the FPGA fabric to communicate with the DMA controller

in the HPS. You can configure up to eight separate interface channels.

• f2h_dma_req0—FPGA DMA controller peripheral request interface 0

Each of the DMA peripheral request interface contains the following three signals:

• f2h_dma_req—This signal is used to request burst transfer using the DMA

• f2h_dma_single—This signal is used to request single word transfer using the DMA

• f2h_dma_ack—This signal indicates the DMA acknowledgment upon requests from the FPGA

For more information, refer to the DMA Controller chapter in the Cyclone V Device Handbook, Volume 3.

--- Quote End ---

16 Replies

Show More
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Those are the DMA "peripheral request interface" signals. The RX group is for flow control of receive channel of the FIFO (writing data to the FIFO) and the TX group is for the flow control of the transmit channel of the FIFO (reading data from the FIFO).

    tx_single represents the FIFO not full status

    rx_single represents the FIFO not empty status

    tx_burst represents the FIFO having a fill level equal to or exceeding the burst size

    rx_burst represents the FIFO having a fill level low enough that it can handle another burst of data written into it

    rx_ack is a signal that pulses every time the DMA either issues a flush or acknowledges a peripheral transfer

    tx_ack .... same thing for the TX channel

    When I say "burst" in this context I'm talking about a predefined block of data and not memory-mapped bursts. The burst size programmed into the peripheral needs to match the burst size programmed into the DMA channel thread. These PRI interfaces let the peripherals communicate to the DMA letting it know when it's safe to transfer data. I recommend reading the DMA chapter of the technical reference manual as well as the comments in the custom FIFO IP to learn more about peripheral transfers and how the handshake works. This group of single, burst, and acknowledge signals is defined by Synopsys and used within the HPS block for all the Synopsys IP that communicates with the DMA-330 core.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Dear BadOmen

    As per my understanding of the verilog code, I think that your explanation of the RX and TX interfaces is mixed up. It should be the other way round. Am I correct?

    --- Quote Start ---

    Those are the DMA "peripheral request interface" signals. The RX group is for flow control of receive channel of the FIFO (writing data to the FIFO) and the TX group is for the flow control of the transmit channel of the FIFO (reading data from the FIFO).

    --- Quote End ---

    I think the RX and TX here are in terms of the DMAC. It uses the TX channel to write data to the FIFO and RX channel to read the data from the FIFO.

    --- Quote Start ---

    tx_single represents the FIFO not full status

    rx_single represents the FIFO not empty status

    tx_burst represents the FIFO having a fill level equal to or exceeding the burst size

    rx_burst represents the FIFO having a fill level low enough that it can handle another burst of data written into it

    --- Quote End ---

    Again here the single and burst signals contradict each other. Only looking at the single signals, FIFO not being full implies that tx channel is used for writing into the FIFO and not empty implies that rx channel is used for reading from the FIFO.

    Sincerely

    Ankit
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Dear fberndl

    I am new to device drivers and I am having a tough time understanding the fpga-dma.c device driver.

    Can you please guide me on how to write the application program using this device driver? If anyone can share some sample code already written using this driver, it would be of great help.

    I have slightly modified the hardware this driver is intended for. Instead of the device being a loopback FIFO (data written to a FIFO and then read back from the same FIFO), I have created to separate FIFOs. Data is written into one, Passed to a second FIFO internally in hardware and then read back from that second FIFO.

    Can you please guide me on the changes required in this driver for that? Also I think that the application code should have 2 separate threads, one for writing and one for reading, else we wouldn’t be using the device to its full potential (i.e. the max data transfer speed achievable). Am I correct?

    Sincerely

    Ankit

    PS: As per your advice I have also replied to rocketboards mail thread concerning this driver. Haven't heard back though. I was hoping that you could help me.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Oops you are correct, I had RX and TX backwards. The RX and TX are from the perspective of the DMA and not the FIFO, so TX is when you write data into the FIFO and RX is when you read data from it.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Dear ankpradh,

    how does the user interact with your driver , so what is the high level application.

    I think in the dma driver there is the debugfs interface used,or in some other example driver . With this debugfs interface you can start an write or read to/from the FIFO via command line.

    So what happens if you trigger something from debugfs?

    0.)debugfs function is called

    1.)Register of fifo will be read (length information)

    2.)The DMAC will be configured for this DMA Peripheral Request

    3.) An "start" bit will be set in the "CSR" or named similar

    4.) The fifo control logic sets the DMA Peripheral Request Interface signals (tx_single,tx_burst, rx_single,rx_burst)

    5.) The dmac does the configured stuff ..

    So if you need two threads depends on which application you have? Again: What is the target of this project?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    In case anyone is getting stuck on CYCLONE V DMA peripheral request DMAWFP. (f2h_dma_req)

    Here is the clue.

    First, search for per2modrst register in the Reset Manager on HPS altera homepage.

    Second, you need to make sure the DMA channels are taken out of reset, all 8 channels are being reset and remain reset after POR. For example, I need channel 0,1,2, you have to do this in the u-boot cmd:

    >mm.b 0xFFD05018

    ffd05018: ff ? f8

    ffd05019: 00 ? q

    >

    Finally your DMA330 should be able to respond to the requests from FPGA.

    good luck.