BrianM
Occasional ContributorJoined 6 years ago
User Profile
Occasional Contributor
User Widgets
Contributions
Re: qmegawiz generated SRAM simulation model broken
I gave up and put in a synthesizable verilog dual port SRAM recommended by intel here: https://www.intel.com/content/dam/altera-www/global/en_US/others/support/examples/download/true_dpram_sclk_v.zip It simulates properly and appears to synthesize properly, although I have to verify that it is inferring ram.Re: qmegawiz generated SRAM simulation model broken
I used menu item Add -> Wave -> All Items in region and below and sub_wire0 is not present. There is clearly some issue with generation of the simulation model, but I can't figure out what it is. I've tried forcing different kind of SRAM (MRAM, M10K, etc). I've tried changing the bus size. I've even copied working ram .v and .qip files to these file names, leaving them untouched and it doesn't generate working simulation models. In the waveform, I can see the write strobe, address and data attempting writes, but the readback always returns as 32'hzzzzzzzz. I'm not sure what is going wrong.Re: qmegawiz generated SRAM simulation model broken
Thanks much. I can't actually see sub_wire0 in the objects windows when I select any of the RAMs that I've attempted to create recently. But it does exist in the old RAMs that were made a while ago. The odd thing is, I changed a sea of registers to SRAM a few weeks ago to see if it would save much space in the design and it did not and it failed to meet timing. The RAM that I created for that worked fine, no issues, but I went back to the registers so I wouldn't have to re-pipeline the design to add an output register to the SRAM. Here is a picture of questa showing the missing wire: sub_wire0 is missing This morning I tried removing the entire simulation folder to force Platform Designer to do a complete rebuild and it didn't help. I know I've done something foolish. I just can't figure out what it is.Re: qmegawiz generated SRAM simulation model broken
Thanks for the quick reply. The q output is always 32'hzzzzzzzz I can see the writes to the RAM happening, but readback always produces zzzzzzzz. I noticed that sub_wire0 exists in the RAM model that works that was created a long time ago for the original FPGA. But for the new RAM model, there is no sub_wire0.qmegawiz generated SRAM simulation model broken
I've tried 21.1 and 21.1.1, the results are the same. Here is the pertinent data from the generated variation file: module psu_mgmt_sram ( clock, data, rdaddress, wraddress, wren, q); input clock; input [31:0] data; input [5:0] rdaddress; input [5:0] wraddress; input wren; output [31:0] q; `ifndef ALTERA_RESERVED_QIS // synopsys translate_off `endif tri1 clock; tri0 wren; `ifndef ALTERA_RESERVED_QIS // synopsys translate_on `endif wire [31:0] sub_wire0; wire [31:0] q = sub_wire0[31:0]; altsyncram altsyncram_component ( .address_a (wraddress), .address_b (rdaddress), .clock0 (clock), .data_a (data), .wren_a (wren), .q_b (sub_wire0), .aclr0 (1'b0), .aclr1 (1'b0), .addressstall_a (1'b0), .addressstall_b (1'b0), .byteena_a (1'b1), .byteena_b (1'b1), .clock1 (1'b1), .clocken0 (1'b1), .clocken1 (1'b1), .clocken2 (1'b1), .clocken3 (1'b1), .data_b ({32{1'b1}}), .eccstatus (), .q_a (), .rden_a (1'b1), .rden_b (1'b1), .wren_b (1'b0)); defparam altsyncram_component.address_aclr_b = "NONE", altsyncram_component.address_reg_b = "CLOCK0", altsyncram_component.clock_enable_input_a = "BYPASS", altsyncram_component.clock_enable_input_b = "BYPASS", altsyncram_component.clock_enable_output_b = "BYPASS", altsyncram_component.intended_device_family = "Cyclone V", altsyncram_component.lpm_type = "altsyncram", altsyncram_component.numwords_a = 64, altsyncram_component.numwords_b = 64, altsyncram_component.operation_mode = "DUAL_PORT", altsyncram_component.outdata_aclr_b = "NONE", altsyncram_component.outdata_reg_b = "CLOCK0", altsyncram_component.power_up_uninitialized = "TRUE", altsyncram_component.ram_block_type = "M10K", altsyncram_component.read_during_write_mode_mixed_ports = "OLD_DATA", altsyncram_component.widthad_a = 6, altsyncram_component.widthad_b = 6, altsyncram_component.width_a = 32, altsyncram_component.width_b = 32, altsyncram_component.width_byteena_a = 1; endmodule I have tried multiple configurations, with and without byte enables. I haven't tried them all because ideally byte enables work the best for me. Although I will try a byte interface on the write path and 32 bit on the read path next. When I use Platform Designer to generate a simulation model, there is one big difference that I can see in Questa. The signal mentioned in the variation file, "subwire0" is missing from the module top level. In the rams that are working that signal shows the read data. I can't see into the firm macro with Questa. It looks to me like qmegawiz / Platform Designer are having problems with Cyclone V SRAM. I'll keep searching for a work around, but I would like someone to try to reproduce this. Thanks much for your support.Re: Questa not showing signals from verilog models
For anyone who finds this thread in the future. The fix is to enable access in vlog and in vsim and suppress the error message like this: From msim_setup.tcl: if ![info exists USER_DEFINED_VERILOG_COMPILE_OPTIONS] { set USER_DEFINED_VERILOG_COMPILE_OPTIONS "+acc -suppress 12110" } if ![info exists USER_DEFINED_ELAB_OPTIONS] { set USER_DEFINED_ELAB_OPTIONS "+acc -suppress 12110" }Re: Questa not showing signals from verilog models
Well, I remembered the alias created by Quartus Pro: alias ld_debug " dev_com com elab_debug " However when I enable that, questa barfs: # Questa Intel FPGA Edition-64 vlog 2021.2 Compiler 2021.04 Apr 14 2021 # ** Error (suppressible): (vlog-12110) All optimizations are disabled because the -novopt option is in effect. This will cause your simulation to run very slowly. If you are using this switch to preserve visibility for Debug or PLI features, please see the User's Manual section on Preserving Object Visibility with vopt. -novopt option is now deprecated and will be removed in future releases. # Errors: 1, Warnings: 0 So questa has disabled this option: -voptargs=+acc I can suppress it, I just have to figure out how. It seems to me that the Quartus qsys tool needs to be updated to add an option for enabling access to modules on a module by module basis when it creates msim_setup.tcl. If anyone knows a better way to do this, I'm all ears.Questa not showing signals from verilog models
Hello. I've just started using intel Questasim vs intel modelsim and it is faster! Which is great! Time to regress on my laptop went from around 37 minutes to around 25 minutes. However, my regressions had a single test failure (actually a single bit failure). So I need to run a simulation with waveforms to see what is going on and fix the testbench (probably). I already have a .do file for simulating this test, but none of the signals it refers to are found when it tries to load. And when I traverse the design tree in questa, none of my verilog modules show any signals at all. Many of the modules are completely free of Objects. Yet the simulation runs and, except for the one issue I need to debug, completely works! I'm running Questa on linux. Any help would be appreciated.
