Hello, I am trying to set up a Cyclone V FPGA so that I can configure the core image through a PCIe connection. As far as I understand it, I need to create a .periph.jic file to upload to the FPGA first, which should make the FPGA visible when I connect it through PCIe.My specific board development kit is the Cyclone V GT 5CGTFD9EF35C7N. It has the Cyclone V and a MAX V on it. I am stuck trying to upload the test .periph.jic file I created just to try and determine if I was on the right track. I get an error, "Can't recognize silicon ID for device 1" that I am unsure how to resolve. I do not have a ByteBlasterMV cable to connect to the 10 pin port on the board. Is there any way I can successfully program the board using USB Blaster II through the USB mini port on the FPGA? Is there a better way to get the FPGA set up for a PCIe connection? Thank you for your assistance, Alex.
Hi,--- Quote Start --- Is there any way I can successfully program the board using USB Blaster II through the USB mini port on the FPGA --- Quote End --- Yes, you can use USB Blaster II. Check below link for steps to configure the flash device. https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/literature/manual/rm_cvgt_fpga_dev_b... https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/literature/ug/ug_cvgt_fpga_dev_kit.p... --- Quote Start --- Can't recognize silicon ID for device 1 --- Quote End --- Default board setting is FPP change it to AS mode. https://www.altera.com/support/support-resources/knowledge-base/solutions/rd02112014_88.html CVP user guide. https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/literature/ug/ug_cvp.pdf May be because of following
After a lot of experimentation, I still haven't quite gotten something working.I found an example Altera provided for my board at https://cloud.altera.com/devstore/platform/17.0.0/standard/pcie-avmm-dma-gen2x4-on-chip-and-external... When I downloaded it and opened the project with Quartus, the device name matched that of my device. I compiled successfully and found that I could write the .sof file to the board if I wanted. However, my goal is to have the cyclone v be visible to the linux machine that it is connected to through pcie. I don't really care how this happens as long as I can program it through that connection in the end. So I used the Nios II EDS terminal to create a flash file and then program the FPGA as per the instructions of Appendix pages 2 and 3 in the link you provided: https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/literature/ug/ug_cvgt_fpga_dev_kit.p... When I ran the last command: nios2-flash-programmer --base=0x00000000 <yourfile>_hw.flash (with my .sof file), I didn't receive any errors (the ip on the screen attached to the board changed the first digit to a 0 for some reason) The LEDs labeled PGM CONF and PGM 1 were lit. Lspci still didn't show the board at all on the Linux machine still (after a hard reboot too). However, when I tried to configure it as per the steps listed for the Board Update Portal, I would successfully upload the flash file and when I proceeded to "Press button PGM_SEL (S6) until PGM LED 1 is lit then press button PGM_CONFIG (S5) to configure the FPGA with the new image" I would see the red ERR LED light up. I'm not sure if I am missing something small or if this is closer. Thank you for your help, after all this fruitless effort I really appreciate it. A lot. Let me know if you need anything I haven't specified. Best regards, Alex
Hi,Have you try to program the .sof file directly to the Cyclone V via the JTAG successfully? Since you are using the on-board USB Blaster II port, you can try to reduce the TCK frequency in USB Blaster II to 16Mhz or 6Mhz. You can modify the USB Blaster II JTAG frequency with the following command in command prompt: > jtagconfig --setparam <cable_number> JtagClock <frequency> where <frequency> is either 6M or 16M. Since you mentioned that your goal is to have the Cyclone V be visible to the Linux machine that it is connected to through PCIe and don't really care how this happens, you can just program the .sof file directly to the Cyclone V device. Plug the Cyclone V GT dev kit to your Linux machine PCIe slot. Power up the Cyclone V GT dev kit via its own power adapter via J8 connector. While the power is on, program the .sof file via the J5 connecter (on-board USB Blaster II). Once the .sof file programming is successful (where the Quartus programmer show the success message), power up the Linux machine. Then try to use the lspci command. Regards, nyusof (This message was posted on behalf of Intel Corporation)
Hello, I have tried lowering the TCK frequency to 16MHz.As of right now, I have tried programming the .sof directly and Quartus reports the programming was successful. However, the board is still not detected by the Linux machine (tried with no reboot, soft reboot, hard reboot). I have also successfully uploaded the flash file now (both through the Nios II EDS terminal and through the Board Update Portal). But on power-up there is no change in what lspci reports. I believe the .sof file and the flash file upload & programming cause the board to have the same behavior because there are 8 LEDs that are lit upon factory reset. However, when I write to the board in any of the above ways, exactly 3 of these LEDs remain lit. The board update portal also no longer comes online unless I flip the FACT switch and have the board powered up such that it has factory default settings. I am not sure where to look for any mistake. Is there a different example I could try to use for the PCIe interface? I was able to program a different example I made that just connected some of the LEDs to buttons on the board. I confirmed its success when the buttons still effected the LEDs after a reboot. Thanks for any assistance you can provide, Best regards, Alex
Hi,You can try to refer to AN456 in the following link which has the example design for Cyclone V GT dev kit (PCI Express High-Performance Reference Design in Cyclone V GT Devices): https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/literature/an/an456.pdf Regards, nyusof (This message was posted on behalf of Intel Corporation)
Hello again, I determined that the fault was actually on the motherboard of the machine I was trying to get the board working on. I apologize for the inconveniences caused by my assumption that it must have been a software issue.Best regards, Alex