API calls failed while running PCIe DMA transfer example design
Hi, I was working the PCIe DMA transfer example design for Arria 10. I have added a counter custom IP which counts upto 1000, and An Avalon FIFO IP with the design. My intention is to write the data created in counter to DDR4 and then use the DMA API call (provided by Terasic in Demonstrations/PCIe_SW_KIT/Windows/PCIe_DDR4/PCIE_DDR4.cpp) to read them from PC. Even if I follows the steps given in the User manual of DE5a_DDR4_NET (attaching the manual. The chapter-7 section 7.6 is what I was following), the DMA API calls to read data fails. I would like to know why I could not run Read DMA API from the PC. The It would be great if someone could give any helping hand. I am attaching the error message (Crash_op.PNG). I am just listing the procedure I followed, 1. Installed both DDR4 2400 4GB SODIMM on the FPGA board. 2. Connected the FPGA board with PC through PCIe. 3. Configured FPGA with DE5A_NET.sof (here the design .sof having PCIe DMA transfer example design + Avalon FIFO + Counter custom IP) by executing the test.bat. 4. Restart Windows 4. I could see the PCIe driver in the device manager (Windows has detected the FPGA Board). 7. Executed the PCIE_DDR4.exe. Then in the menu putting the options 3, 4 and 5 gives the failure. FYI: I have been using Quartus Prime Pro 18.1 in Windows 10.
A design based on the PCIe DMA transfer example design for Arria 10 device.
Hi, This is a extension of the discussion https://community.intel.com/t5/Programmable-Devices/Modifying-the-PCIe-DMA-transfer-example-design-for-Arria-10/m-p/1484799#M90698 and https://community.intel.com/t5/FPGA-Intellectual-Property/API-calls-failed-while-running-PCIe-DMA-transfer-example-design/m-p/1520494#M28014 where we could not get a solution to the problem we are facing. We also tried trying to get a Intel Premium help (We are based on a University in USA, but purchased the FPGA and Intel Quartus Prime Pro with normal rate NOT through University reduced rate). But thats is rejected by Intel explaining that since, We are from a University, We are not eligible for Premium help. It would be great if you suggest a way to resolve the issue. Story in short: We were working on a project to use the FPGA to increase the data throughput in an experiment. We are planning to use FPGA as an intermediate in signal transmission through an optical fiber from electronic readout to the Data Acquisition System. So we need a way to transfer signal though the FPGA (input though the QSFP+ port and output through the PCIe). We were planning to develop a design based on the PCIe DMA transfer example design (that involve the DDR4 memory to store data). In the example design, data is created at a host computer and is written into the DDR4 memory through DMA write through PCIe. And then it read it back to the hot computer to verify the sending data is same as the receiving data. What we need in our project to stream data from QSFP+ to the DDR4 memory and then DMA read through PCIe to host computer using the API provided. As an initial step (to test the working of the FIFO + PCIE DMA transfer example design, as our final aim is to get the data from QSFP+ to FIFO to goto the DDR4 element), we used a custom IP of data counter that counts upto 1000 (works on getting an trigger from a switch SW[0] ) to connect to Avalon FIFO IP. Then this design is integrated to the PCIe DMA transfer example design using Platform Builder. The idea is to stream created at the counter though FIFO to the DDR4 memory element. Then DMA read though PCIE to a host computer. But when we try to do DMA read from the host computer, we could not see the counter outputs (which we are suppose to get?). Great if you could help us out. Any suggestion where to get help for making our design work is highly appreciated.
Understanding AvalonĀ® Memory-Mapped Interfaces: A Guide for Beginners
Overview This article is written for beginners who have just started developing Field Programmable Gate Arrays (FPGAs) with IntelĀ®, especially those who have started to use the Platform Designer in IntelĀ® QuartusĀ® Prime Software but are not quite sure about the interfaces of Intellectual Property (IP). While there are various types of AvalonĀ® Interfaces (please refer to this page), this article introduces the frequently used AvalonĀ® Memory-Mapped Interfaces and also explains the Avalon Verification IP Suite used for signal verification. Specifically, for AvalonĀ® Verification IP Suite, you can download the test benches by clicking on Avalon Verification IP Suite Design Files here, and we will actually run them. Note that you can run the test benches if you have the IntelĀ® QuartusĀ® Prime Software Standard Edition, so no actual hardware is required. *In terms of data exchange, the MasterāSlave relationship often comes up. In this article, we will explicitly state "who is sending the signal" in the explanations to avoid any confusion. What is AvalonĀ® Interface? The AvalonĀ® Interface refers to the ports of Intellectual Property (IP), in other words, the 'entrances and exits' for signals such as clock and data. However, it's important to note that in addition to having physical entrances and exits, there are also various rules in place. Take an airport as an example: there are physical boarding gates for embarking and disembarking, but there are also pre-established ārulesā such as which flights are connected to which gates and the specific times for departures and arrivals of airplanes. If these rules are not followed, airplanes cannot travel to and from the airport. The same concept applies to the AvalonĀ® Interface; it represents not just the physical 'entrances and exits', but also defines the protocol (rules) for using these entrances and exits. So, what kind of protocols exist for the AvalonĀ® Interface? Specifically, there are: AvalonĀ® Clock and Reset Interfaces AvalonĀ® Memory-Mapped Interfaces AvalonĀ® Interrupt Interfaces AvalonĀ® Streaming Interfaces AvalonĀ® Streaming Credit Interfaces AvalonĀ® Conduit Interfaces AvalonĀ® Tristate Conduit Interface and so on. In this session, we will take a closer look at AvalonĀ® Memory-Mapped Interfaces, which is one of the most frequently used interfaces. Direction Signal Role Width Required Desctiption address 1-64 Master ā Slave No This signal is used for data address specification. Of course, if the Master is asserting the read signal (making the signal active; the opposite, making it inactive, is called deasserting), the Slave cannot determine which data it wants to read unless an address is specified. Similarly, if the Master is asserting the write signal, the Slave cannot decide where it wants to write the data unless an address is specified. However, address specification is not necessary if there is only one register provided on the Slave side. byteenable 2, 4, 8, 16, 32, 64, 128 Master ā Slave No This signal is used to specify which bytes of the readdata and writedata you want to read and write. For example, for a 32-bit data, if byteenable=0b0001, it means reading and writing the lower 8 bits, and if byteenable=0b1000, the upper 8 bits are read and written. Especially when the Slave side supports byte-by-byte access, the byteenable signal is used for transmission and reception. If you are using peripherals that are not compatible, please check the access method in the manual. read 1 Master ā Slave No If the Master asserts the read signal, the Slave can determine that the Master wants to read data. Additionally, if you only want to perform a write operation, the read signal is not necessary. readdata 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024 Slave ā Master No After the Slave receives the read signal from the Master, this data is transmitted from the Slave to the Master. If the read signal is not used, the readdata signal is also not necessary. response[1:0] 2 Slave ā Master No This is the reception status signal sent by the Slave. It is used to inform the status of whether the transaction was carried out correctly. write 1 Master ā Slave No If the Master asserts the write signal, the Slave can determine that the Master wants to write data. Additionally, if you only want to perform a read operation, the write signal is not necessary. writedata 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024 Master ā Slave No The writedata signal is the data that the Master sends simultaneously with the write signal, to be written to the Slave. If the write signal is not used, the writedata signal is also not necessary. Signal Patterns of AvalonĀ® Memory-Mapped Interfaces Below, we will take a look at some of the signal patterns described in the manual. We will explain the state of the signals around each cycle. Typical Read and Write Transfers This section presents a typical interaction of read and write signals. Pay attention to which of the Master or Slave is asserting each signal. Image Source: AvalonĀ® Interface Specifications Figure 7. Read and Write Transfers with Waitrequest address, byteenable, and read are asserted by the Master. However, since the Slave asserts waitrequest, no data is sent from Slave to Master. Since the Slave asserts waitrequest, no data transfer occurs. The Slave deasserts waitrequest, and data is sent from Slave to Master. The Master completes the reception of readdata. Since both read and write are deasserted, no data transfer occurs. Although the Master continues to send writedata, the Slave does not receive data yet because waitrequest is asserted. Since waitrequest is deasserted, the Slave receives address, byteenable, write, and writedata from the Master. ā» The sections of the signals that are grayed out represent undefined values. ā» Signals are output slightly delayed relative to the rising edge of the clock. For example, if we focus near the rising edge of the first clock, we see that the Master asserts the address, byteenable, and read signals, but they are asserted slightly after the rising edge of the clock. This delay is due to the time it takes for the output to be obtained from the D flip-flop. Write Bursts This example demonstrates signal behavior during write operations in burst mode. Burst mode refers to a mode where data is sent continuously. By specifying an address and burst count (the number of consecutive data items to receive or send) at the beginning, you can receive or send burst count number of data items from the address location. Image Source: AvalonĀ® Interface Specifications Figure 14. Write Burst with constantBurstBehavior Set to False for Master and Slave address, beginbursttransfer, burstcount, write, and writedata are asserted by the Master. However, since the Slave asserts waitrequest, no data is sent from Slave to Master. The Slave asserts waitrequest, so it does not complete reception of writedata. Since the Slave deasserts waitrequest, it receives data 1. Since the Slave deasserts waitrequest, it receives data 2. The Master deasserts write, so the Slave does not receive writedata. Since the Slave deasserts waitrequest, it receives data 3. The Slave asserts waitrequest, so it does not receive writedata. Since the Slave deasserts waitrequest, it receives data 4. Let's Try Running the AvalonĀ® Verification IP Suite Design Example The AvalonĀ® Verification IP Suite is a simulation library for observing the signals of AvalonĀ® Interfaces. As shown in the diagram below, you can define a Test Module on the user side and specify what kind of simulation to perform. In the Design Example used for the later section, Downloading the Design Example, the User Test Bench is written in SystemVerilog. Image Source: AvalonĀ® Verification IP Suite Design Example Figure 1. Verification testbench using Avalon Verification IP Suite. By utilizing this example design, you will be able to simulate the behavior of your custom hardware design with an AvalonĀ® interface, and check the state of signals and the flow of data. This allows you to verify that the hardware design is functioning as expected, or to identify any issues at an early stage. Required Environment Windows 10 21H2 IntelĀ® QuartusĀ® Prime Software Standard Edition Downloading the Design Example Please click on ug_avalon_verification.zip here to download the Design Example. Avalon Verification IP Suite User Guide (PDF) is the manual. Once the download is complete, unzip the file and make sure it contains the following: avlmm_1x1_verilog.zip avlmm_1x1_vhdl.zip avlmm_2x2_verilog.zip avlmm_2x2_vhdl.zip ug_avalon_verification.zip We will only be using avlmm_1x1_verilog.zip, so please unzip this file as well. Operating IntelĀ® QuartusĀ® Prime Software Open IntelĀ® QuartusĀ® Prime Software and click on File > Open. This will launch the File Explorer. Navigate to avlmm_1x1_verilog/avlm_avls_1x1.qsys, select it, and click "Open". Platform Designer will start, and the following window will appear. There will be a warning about the IP version, but it is not a problem. Please click Close. A window will also appear to inform you that the IP has been upgraded. Please click "Close" to close it. Please click on "Generate HDL..." located at the bottom right of the Platform Designer. A window for Generation will appear. Please set it up as shown in the image below, and click on "Generate". When the "Save System Completed" window appears, click "Close" to close it. When the "Generate Completed" window appears, click "Close" to close it. Please open Questa from the Windows start menu. This is the startup screen for Questa. Navigate to the location of "avlmm_1x1_verilog" in the Transcript, and execute the following command: > do run_simulation.tcl As shown in the image below, "run_simulation.tcl" should be included within "avlmm_1x1_verilog". Please confirm that the simulation results are displayed as follows. You can zoom in using the 'i' key on your keyboard and zoom out using the 'o' key. If the waveform is difficult to capture, it may be helpful to zoom to an appropriate size for viewing. Focusing on the avm_write and avm_read signals (the cyan squares) in the gray pane on the left side, you can see that they are divided into four parts marked by red squares: The master asserts the write signal (no burst). The master asserts the read signal (no burst). The master asserts the write signal (burst). The master asserts the read signal (burst). This allows you to observe how the AvalonĀ® Verification IP Suite behaves under different conditions and signals. Letās closely observe the simulation results to see if the AvalonĀ® memory-mapped interface behaves as described in the sections, Typical Read and Write Transfers and Write Bursts. Below, we will explain each part of the four red blocks. Master Asserts Write Signal (No Burst) Starting at 1.45ns Letās take a look at the moment when avm_write is asserted without burst for the first time. cycle0: The Master asserts avm_address, avm_burstcount, avm_write, avm_writedata, and avm_byteenable. The Master expects the Slave to receive the writedata. Shortly after (this delay is because it takes time for the Master to send the above signals to the Slave and for signals to come out of the Slave), the Slave asserts waitrequest. cycle1: Since waitrequest is asserted, the Slave does not complete receiving data from the Master. cycle2: Here, the Slave deasserts waitrequest. Other signals remain constant. cycle3: Since waitrequest is deasserted, the Slave finally receives data from the Master. Master Asserts Read Signal (No Burst) Starting at 2.35ns cycle0: The master asserts avm_address, avm_burstcount, avm_write, avm_writedata, and avm_byteenable. The master expects the slave to receive the writedata. cycle1: As the slave does not assert waitrequest, it receives the data from the master. cycle2: The master asserts avm_address, avm_burstcount, avm_write, avm_writedata, and avm_byteenable again. The master expects the slave to receive the new writedata. cycle3: Since the slave does not assert waitrequest, it receives the data from the master. At the same time, the master asserts new address and writedata to send the next piece of data. cycle4: As the slave does not assert waitrequest, it receives the data from the master. Master Asserts Write Signal (Burst) Starting at 7.25ns cycle0: The master asserts avm_address, avm_burstcount, avm_read, and avm_byteenable. The master expects the slave to send the read data. Additionally, a bit later, the slave asserts waitrequest. cycle1: Since waitrequest is asserted, the slave does not complete receiving data from the master. cycle2: waitrequest remains asserted, so the slave does not complete receiving data from the master. The slave deasserts waitrequest. cycle3: With waitrequest now deasserted, the slave receives avm_address, avm_burstcount, avm_read, and avm_byteenable from the master. cycle4: Neither the master nor the slave assert any signals. cycle5: The data requested by the master from the slave in cycle0 arrives at the master. Master Asserts Read Signal (Burst) Starting at 32.85ns The number of cycles to check has increased, but please do your best to review the following flow. cycle0: Master asserts avm_address, avm_burstcount, avm_read, and avm_byteenable. The Master expects the Slave to send readdata. <b>Note that the burstcount is 3.</b> Shortly after, the Slave asserts waitrequest. cycle1: Since waitrequest is asserted, the Slave does not complete receiving data from the Master. The Slave deasserts waitrequest. cycle2: With waitrequest deasserted, the Slave receives avm_address, avm_burstcount, avm_read, and avm_byteenable from the Master. cycle3: Master asserts avm_address, avm_burstcount, avm_read, and avm_byteenable again, expecting the Slave to send readdata. Shortly after, the Slave asserts waitrequest. Data1 requested by the Master from the Slave in cycle0 reaches the Master. cycle4: With waitrequest deasserted, the Slave receives avm_address, avm_burstcount, avm_read, and avm_byteenable from the Master. cycle5: Neither Master nor Slave assert any signals. cycle6: Data2 requested by the Master from the Slave in cycle0 reaches the Master. cycle7: Neither Master nor Slave assert any signals. cycle8: Neither Master nor Slave assert any signals. cycle9: Neither Master nor Slave assert any signals. cycle10: Master asserts avm_address, avm_burstcount, avm_read, and avm_byteenable, expecting the Slave to send readdata. Additionally, Data3 requested by the Master from the Slave in cycle0 reaches the Master. This concludes the transfer of all data requested by the Master from the Slave in cycle0. Summary How was it? From the simulation results, I believe you were able to understand the operation of the AvalonĀ® memory-mapped interface. Itās just like how busy person A and busy person B need rules (protocols) to communicate. The same applies to IP; communication is rule-based, and it is very important to understand the rules, such as signaling āwait a momentā (waitrequest) when busy, whether you want to receive (read) or send (write) a message, and so on. Notices & Disclaimers Intel technologies may require enabled hardware, specific software, or service activation. Ā© Intel Corporation. Intel, the Intel logo, and other Intel marks are trademarks of Intel Corporation or its subsidiaries. Names and brands of other entities may be claimed as the property of others. For more information, please visit Intel's Benchmark Overview.Need PCI Express 5.0 for your next FPGA design? Check out IntelĀ® Agilexā¢ I-series and M-series FPGAs
Are you designing systems that need PCI Express (PCIe) 5.0 capability? If so, youāll want to take a good look at the IntelĀ® Agilexā¢ I- and M-series FPGAs and SoC FPGAs because these programmable-logic devices incorporate PCIe 5.0 capabilities and have just passed PCI-SIG compliance tests.
Avalon Streaming Dual Clock FIFO
Hi, I am trying to connect the AV DC FIFO as followed: The idea being that the main clock is running at 100MHz and is connected to the mSGDMA which reads from the FIFO, and iopll is outputting a 200MHz clock and is connected to the oscillator which writes to the FIFO. The above design compiles, but on boot I am given this error: ..Error sending bitstream! Command 'load' failed: Error -110 FPGA not ready. Bridge reset aborted! Note that this design works when there is no PLL, and everything is clocked from the same source (although this causes boot to take a long time). I have looked through the docs here however these docs seems not to match the IP interfaces. The docs here here seem to match but don't explain the interface. Could someone help point me in the correct direction? Thanks!
