Hello, I am currently trying to find out how to trigger a transfer of DMA Controller Intel FPGA IP (connected between f2h_sdram0 and on-chip 2-port RAM in QSYS) using an interrupt from the FPGA side. The DMA works when the transfer is started from the Linux userspace by writing GO bit (2^3) to the CONTROL register (offset 6 in the /dev/mem memory-mapped space of the controller's control_port_slave on the AXI bus). The CONTROL register contains interrupt enable bit (2^4) but I believe it is only used to enable Interrupt Sender (irq port of the IP block). Q: Is this IP related to the HPS' DMA Peripheral Requests (0 to 7)? If so, how to tell the IP block what request should be used as an interrupt source for trigger? Or maybe I use wrong IP block and I should use eg. mSGDMA instead? Thanks in advance.

Hi,These are the interfaces, you need to refer to the Cyclone V HPS TRM, f2h interrupts:https://www.intel.com/content/www/us/en/docs/programmable/683126/21-2/interrupts-38262.htmlDMA controller interface:https://www.intel.com/content/www/us/en/docs/programmable/683126/21-2/dma-controller-interface-83696.htmlAlternatively, you may want to look at an example design below from Robertofem:https://github.com/robertofem/CycloneVSoC-examples/tree/master/Linux-applications/DMA_transfer_FPGA_DMAC

Hi, thanks, I have already seen these resources before. In the first site there is no information about using f2h interrupts directly with the DMA Controller. Of course I could use an interrupt kernel driver writing the DMA control register but that's not what I am looking for. The second link you provided also doesn't explain how to connect the DMA Peripheral Requests (f2h_dma_reqX) to the DMA Controller QSYS. It also doesn't say how the DMA controller in the HPS is related to the QSYS component. The third link provides source code (fpga_dmac_api.c) I have been already using (ie. the CONTROL register I mentioned in the first post). But it also doesn't relate to the interrupts or to triggering of the DMA from the FPGA side. The only way I can think of right now is accessing the control_port_slave (Avalon MM Slave) of the DMA Controller QSYS component directly from the fabric but it would mean sharing the physical address of the allocated buffer from HPS first, which doesn't seem like a valid approach to me. What's the proper way to accomplish this?

Hi,We do not really have a direct example for this, but to best guide you, it is the peripheral requests mentioned for DMA controller for Cyclone V SoC:https://www.intel.com/content/www/us/en/docs/programmable/683126/21-2/peripheral-request-interface-mapping.htmlThe FPGA peripherals, these channels are mapped in the registers of Cyclone V SoC here:https://www.intel.com/content/www/us/en/programmable/hps/cyclone-v/hps.html#sfo1410067855000.htmlFor future usage and info on the DMA controller, you need to refer to the ARM doc , on the "using events and interrupts" section:https://developer.arm.com/documentation/ddi0424/b/functional-overview/using-events-and-interrupts/using-an-event-to-restart-dma-channelsFrom there you can either use an event to restart the DMA channels or Interrupting a microprocessor. I hope these documents may help you.

Hi,Do you have any other questions that I may help with?

Hello, thank you for the provided links. I started digging deeper into the register map of the Cyclone V HPS and into the ARM Docs to find answers to my questions about usage of the AMBA DMA Controller DMA-330. As far as I understand it now, the registers mentioned in the DMA Module Address Map are all read-only except the Debug registers (DBGCMD Debug Command Register, DBGINST0 Debug Instruction-0 Register, DBGINST1 Debug Instruction-1 Register), the 2 interrupt-related Control registers (INTEN Interrupt Enable Register, INTCLR Interrupt Clear Register) and the WD Watchdog Register in Configuration registers, so the DMAC can be controlled only via DMA instructions (Instruction set summary). So to be able to issue DMA instructions - ie. writing them with their parameters to the DBGINST registers (up to 6 bytes) followed by writing zero to the DBGCMD Register - and to use other instructions than DMAGO, DMAKILL and DMASEV (when the DMAC is operating in the real-time), the DMA must be first set to the Non-secure state. I am still confused about all the information provided, so my questions are: Q1: What are the Secure and Non-secure states of the DMAC anyway? I can see there are 2 instances of the DMAC in the Register map: Non-Secure DMA Module (at 0xFFE00000) and Secure DMA Module (at 0xFFE01000). Does that mean, for example, I need to write to the Non-secure Debug registers when the DMAC started in Non-secure state, and write to the Secure Debug Registers when the DMAC is started in the Secure state? Q2: How do I change the state of the DMAC? I guess I have to put the DMAC to the reset state by writing the Reset Manager Module - PERMODRST register with the dma bit set to 1, write the System Manager Module - DMA - CTRL register wtih the mgrnonsecure bit set to 1 and then release the DMAC from reset using the PERMODRST register, is that right? Q3: Should the bits of the irqnonsecure field in the CTRL register be set or kept intact for the use with the f2h_dma_reqX signals from the FPGA? From both of the Intel and ARM Docs it seems that the interrupts are used for generating outputs from the DMAC (eg. when the transaction is finished to the peripheral), on the other hand the events get generated by the interrupt request signals or by the software (DMASEV) to be used internally, is that right? Q4: In the ARM Docs there is also mentioned the security state for the DMA manager thread, controlled by the boot_manager_ns signal. What is that signal and is it the same as the SYSMGR mgrnonsecure bit? Q5: So based on the table in the link you provided, I guess the f2h_dma_req0 to f2h_dma_req7 signals are mapped to the first 8 FPGA request interfaces. Are these interfaces enabbled by the first 8 bits in the event_irq_select field in the INTEN Interrupt Enable Register or is this register irrelevant for these signals? Also, based on my understanding, DMASEV (Send Event Instruction) is only used for software generated events to restart channels which issued DMAWFE (Wait For Event Instruction) - Do I understand it correctly that I need to issue DMAWFP (Wait For Peripheral Instruction) on the selected DMA channel to make it wait for the peripheral request f2h_dma_reqX (as suggested here)? Both the Intel and ARM Docs are REALLY confusing. Thank you for any help in advance.

Cyclone V - DMA Controller Intel FPGA IP Interrupts

15 Replies

EBERLAZARE_I_Intel
Regular Contributor
3 years ago
Hi,

These are the interfaces, you need to refer to the Cyclone V HPS TRM, f2h interrupts:
https://www.intel.com/content/www/us/en/docs/programmable/683126/21-2/interrupts-38262.html

DMA controller interface:
https://www.intel.com/content/www/us/en/docs/programmable/683126/21-2/dma-controller-interface-83696.html

Alternatively, you may want to look at an example design below from Robertofem:
https://github.com/robertofem/CycloneVSoC-examples/tree/master/Linux-applications/DMA_transfer_FPGA_DMAC
- vrbavojtech
  New Contributor
  3 years ago
  Hi,
  
  thanks, I have already seen these resources before.
  
  In the first site there is no information about using f2h interrupts directly with the DMA Controller. Of course I could use an interrupt kernel driver writing the DMA control register but that's not what I am looking for.
  
  The second link you provided also doesn't explain how to connect the DMA Peripheral Requests (f2h_dma_reqX) to the DMA Controller QSYS. It also doesn't say how the DMA controller in the HPS is related to the QSYS component.
  
  The third link provides source code (fpga_dmac_api.c) I have been already using (ie. the CONTROL register I mentioned in the first post). But it also doesn't relate to the interrupts or to triggering of the DMA from the FPGA side.
  
  The only way I can think of right now is accessing the control_port_slave (Avalon MM Slave) of the DMA Controller QSYS component directly from the fabric but it would mean sharing the physical address of the allocated buffer from HPS first, which doesn't seem like a valid approach to me.
  
  What's the proper way to accomplish this?
EBERLAZARE_I_Intel
Regular Contributor
3 years ago
Hi,

We do not really have a direct example for this, but to best guide you, it is the peripheral requests mentioned for DMA controller for Cyclone V SoC:
https://www.intel.com/content/www/us/en/docs/programmable/683126/21-2/peripheral-request-interface-mapping.html

The FPGA peripherals, these channels are mapped in the registers of Cyclone V SoC here:
https://www.intel.com/content/www/us/en/programmable/hps/cyclone-v/hps.html#sfo1410067855000.html

For future usage and info on the DMA controller, you need to refer to the ARM doc , on the "using events and interrupts" section:
https://developer.arm.com/documentation/ddi0424/b/functional-overview/using-events-and-interrupts/using-an-event-to-restart-dma-channels

From there you can either use an event to restart the DMA channels or Interrupting a microprocessor. I hope these documents may help you.
EBERLAZARE_I_Intel
Regular Contributor
3 years ago
Hi,

Do you have any other questions that I may help with?
vrbavojtech
New Contributor
3 years ago
Hello,

thank you for the provided links. I started digging deeper into the register map of the Cyclone V HPS and into the ARM Docs to find answers to my questions about usage of the AMBA DMA Controller DMA-330.

As far as I understand it now, the registers mentioned in the DMA Module Address Map are all read-only except the Debug registers (DBGCMD Debug Command Register, DBGINST0 Debug Instruction-0 Register, DBGINST1 Debug Instruction-1 Register), the 2 interrupt-related Control registers (INTEN Interrupt Enable Register, INTCLR Interrupt Clear Register) and the WD Watchdog Register in Configuration registers, so the DMAC can be controlled only via DMA instructions (Instruction set summary).

So to be able to issue DMA instructions - ie. writing them with their parameters to the DBGINST registers (up to 6 bytes) followed by writing zero to the DBGCMD Register - and to use other instructions than DMAGO, DMAKILL and DMASEV (when the DMAC is operating in the real-time), the DMA must be first set to the Non-secure state.

I am still confused about all the information provided, so my questions are:

Q1: What are the Secure and Non-secure states of the DMAC anyway? I can see there are 2 instances of the DMAC in the Register map: Non-Secure DMA Module (at 0xFFE00000) and Secure DMA Module (at 0xFFE01000). Does that mean, for example, I need to write to the Non-secure Debug registers when the DMAC started in Non-secure state, and write to the Secure Debug Registers when the DMAC is started in the Secure state?

Q2: How do I change the state of the DMAC? I guess I have to put the DMAC to the reset state by writing the Reset Manager Module - PERMODRST register with the dma bit set to 1, write the System Manager Module - DMA - CTRL register wtih the mgrnonsecure bit set to 1 and then release the DMAC from reset using the PERMODRST register, is that right?

Q3: Should the bits of the irqnonsecure field in the CTRL register be set or kept intact for the use with the f2h_dma_reqX signals from the FPGA? From both of the Intel and ARM Docs it seems that the interrupts are used for generating outputs from the DMAC (eg. when the transaction is finished to the peripheral), on the other hand the events get generated by the interrupt request signals or by the software (DMASEV) to be used internally, is that right?

Q4: In the ARM Docs there is also mentioned the security state for the DMA manager thread, controlled by the boot_manager_ns signal. What is that signal and is it the same as the SYSMGR mgrnonsecure bit?

Q5: So based on the table in the link you provided, I guess the f2h_dma_req0 to f2h_dma_req7 signals are mapped to the first 8 FPGA request interfaces. Are these interfaces enabbled by the first 8 bits in the event_irq_select field in the INTEN Interrupt Enable Register or is this register irrelevant for these signals? Also, based on my understanding, DMASEV (Send Event Instruction) is only used for software generated events to restart channels which issued DMAWFE (Wait For Event Instruction) - Do I understand it correctly that I need to issue DMAWFP (Wait For Peripheral Instruction) on the selected DMA channel to make it wait for the peripheral request f2h_dma_reqX (as suggested here)?

Both the Intel and ARM Docs are REALLY confusing.

Thank you for any help in advance.
EBERLAZARE_I_Intel
Regular Contributor
3 years ago
Hi,

Please allow me some more time to look into this.
I shall get back to you.
EBERLAZARE_I_Intel
Regular Contributor
3 years ago
Hi,

I am still working on this case, I shall update to you the answers soon.

Thanks for your patience.
EBERLAZARE_I_Intel
Regular Contributor
3 years ago
Hi,

You may find the answers below:

A1:
Yes, you can check the mgrnonsecure, the default value should be secure state.

A2:
Yes, to be exact permodrst.dma.

A3:
Based on the ARM doc, the DMASEV is not related to the interrupts request signals.
By default the value should be in secure mode, so no, only if you need to test a non secure then you might need to set to bit to 1.

A4:
Yes they are.

A5:
Yes you are correct, issuing the DMAWFP is needed as you mentioned.
- vrbavojtech
  New Contributor
  3 years ago
  Hello,
  
  thank you for your answers, but I need a more specific help now.
  
  I tried Test_DMA_PL330_LKM - the code for building DMA programs and starting transactions works fine even from Linux userpace together with u-dma-buf kernel driver for allocating DMAble buffers.
  
  This DMA program for reading 128B (= 16x 64bit) chunks of data from on-chip RAM works as expected:
  
  DMAMOV SAR <source physical 32b address>
  DMAMOV DAR <destination physical 32b address>
  DMAMOV CCR SB16 SS64 DB16 DS64 ES64
  DMALP <num_loops_of_128B_trans>
  DMALD
  DMAST
  DMALPEND
  DMAEND
  
  But the interrupts still don't work.
  
  I am clearing all 8 bits in the RSTMGR-PER2MODRST register during boot to enable FPGA request interfaces using this line in u-boot script:
  
  mw.b 0xFFD05018 0x00
  
  I don't know how to use the DMAWFP instruction properly. When I use this program, the channel gets stuck in the WFP state (ALT_DMA_CHANNEL_STATE_WFP) no matter how I toggle the f2h_dma_req0_req (burst) port in the fabric:
  
  DMAMOV SAR <source physical 32b address>
  DMAMOV DAR <destination physical 32b address>
  DMAMOV CCR SB16 SS64 DB16 DS64 ES64
  DMAFLUSHP P0
  DMAWFP P0 burst
  DMALP <num_loops_of_128B_trans - 1>
  DMALDB
  DMASTB
  DMALPENDB
  DMALDB
  DMASTPB P0
  DMAEND
  
  (Here I understand P0 as the ALT_DMA_PERIPH_FPGA_0 ie. f2h_dma_req0 request.)
  
  Thanks for any help.
EBERLAZARE_I_Intel
Regular Contributor
3 years ago
Hi,

I am not familiar as well on how it should work, I guess maybe you could check on ARM forum help in the mean time.

I hope I got something to help you with, please allow me some time to dig in on the DMAWFP.
EBERLAZARE_I_Intel
Regular Contributor
3 years ago
Hi,

I may need sometime to help you with this issue, please expect delay in my respond.

Thanks and I appreciate your patience.
EBERLAZARE_I_Intel
Regular Contributor
3 years ago
Hi,

I hope these info might help:

If you see below, there are 8 channels reset in the per2modrst register, and there should remain reset after POR:
https://www.intel.com/content/www/us/en/programmable/hps/cyclone-v/hps.html#sfo1410067767358.html

For e.g, let the HPS run and see the CSR0 state changes, make sure channel0/or any channel is waiting for peripheral0/any peripheral, DMA should be waiting.

The 8 channels reset in the per2modrst register, they remain reset after POR. Try to run something like:

"mm.b 0xffd05018"

After execution, the DMA330 should respond to the peripheral requests from FPGA.

Just for reference:
https://docs.rtems.org/doxygen/branches/master/group__ALT__DMA__PRG.html#ga4990f947286b37cfda315697743fdd57

Forum Discussion

Cyclone V - DMA Controller Intel FPGA IP Interrupts

15 Replies

Recent Discussions

Worst-Case Completion Time for PLL Dynamic Phase Shift (PHASESTEP → PHASEDONE)

Agilex5 - Timings configuration

10M04SCU169I7G issue.

HDMI example design errors with Agilex 7

Agilex 7 DDR4 Reset and ADDR/CMD Clock PCB Implementation Documentation Discrepancy