- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello.
Part: Cyclone V 5CSXFC5D6F31C7, about 85% utilized.
I've written RTL in verilog for a simple MM interface from the FPGA to SDRAM 1 HPS interface. I created a test bench utilizing an MM DRAM interface model and debugged my hardware until it worked.
However, in the actual FPGA, the MM interface appears to hang. I have very little visibility into the design at this point so I'm not entirely sure what is happening.
The SDRAM 0 interface is working because I have an PCIe NVMe interface working under linux.
I have attempted to generate a full simulation model of the HPS system in Platform Designer but I get an error message:
Error: TB_Gen: pcie_cv_hip_avmm_0.hip_ctrl is not exported for sim partner
I don't need to simulate that, is there a way to disable it for simulation or do I have to create a new platform designer qsys missing the hip and PCIe?
I have also changed the MM interface to use the FPGA to HPS bus and it's behavior is basically the same. I can see my state machine running, but the data in the destination registers that are supposed to be updated from DRAM don't change. So the state machine appears to hang on a read, but restarts on the next 1ms cycle and hangs again.
Bandwidth is not an issue because the most reads the hardware will ever do is 48, 32 bit words every millisecond.
I'm hoping someone can offer guidance on how to debug this.
Thanks.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quick update: I removed the PCIe stuff from the Platform Designer file and attempted to generate a test bench for just the HPS and my FPGA implementation.
Now I get this error:
Error: fpga_interfaces: add_fileset_file: No such file /opt/intelFPGA/20.1/ip/altera/mentor_vip_ae/axi3/bfm/mgc_common_axi.sv
while executing
"add_fileset_file mgc_common_axi.sv SYSTEM_VERILOG PATH $MENTOR_VIP_DIR/axi3/bfm/mgc_common_axi.sv"
("if" then script line 3)
invoked from within
"if {$include_axi_bfm} {
add_fileset_file questa_mvc_svapi.svh SYSTEM_VERILOG PATH $MENTOR_VIP_DIR/common/questa_mvc_svapi.svh
add_fileset_..."
(procedure "add_files_to_simulation_fileset" line 33)
invoked from within
"add_files_to_simulation_fileset $data(interfaces)"
(procedure "sim" line 41)
invoked from within
"sim CPU_Subsys3_sim_hps_0_fpga_interfaces"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi ,
Thanks for contacting Intel Support.
Please let us know the version of Quartus and Platform designer which you are using.
A similar error for NIOS can be seen below.
https://www.intel.com/content/www/us/en/support/programmable/articles/000086142.html
Thanks and Regards
Anil
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Anil,
I'm using Quartus 20.1.1 Build 720 on linux.
That patch only seems to apply to Windows, is there a linux version?
Thanks,
Brian
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi ,
Can you try to install the Linux patch available in the the below link and let us know the results.
https://www.intel.com/content/www/us/en/support/programmable/articles/000085873.html
Thanks and Regards
Anil
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Anil,
Instead of using the HPS simulation model, I used the intel Avalon Slave BFM simulation model in my simple test bench. It took a while to get it to do what I want but I was finally able to understand what my Avalon Master interface was lacking. I changed the interface to burst 16 and fill little SRAM Cache's spread throughout the design.
Simulation showed that it worked and after finding a connection error at the top level of the part, I was able to get the DRAM interface working.
I have not tested this patch, but when I get the opportunity, I'd like to test with it to determine exactly how much overhead the FPGA to DRAM interface has to make sure my burst logic is efficient enough in all the corner cases.
When I get a chance to try this, I'll post an update.
Thanks much.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page