Trying to recompile sim libraries for MAX 10 under quartus 21.1

"fiftyfivenm_atoms_ncrypt.v" is the simulation model for the MAX10 device. Therefore, you may encounter an error even when simulating a simple component like an AND gate.

Have you tried launching the EDA Simulation Library Compiler?

This tool facilitates the generation of simulation libraries. You can find more information about it in the following link: [https://www.intel.com/content/www/us/en/programmable/quartushelp/17.0/mapIdTopics/jka1465596847489.htm]

Since you are using Quartus Standard, you can also try simulating using the Nativelink feature. Nativelink automatically compiles your design, Intel IP, simulation model libraries, and testbench. You can refer to this article for more details:

[https://www.macnica.co.jp/en/business/semiconductor/articles/intel/131009/]

Best Regards,

Richard Tan

p/s: If you find any answers from the community or Intel Support to be helpful, we encourage you to mark them as the best answer or rate them 4/5 in the survey.

The error that I was getting *WAS* when I was trying to run the EDA simulation library compiler, as it seems I needed to do that before I could simulate anything. I'm glad to know that the MAX 10 devices are referred to by their process size vs their product name. That piece of info definitely helps clarify some things. I did all of the things specified by the first link and that led to the errors I'm seeing from the "quartus/eda/sim_lib/mentor/fiftyfivenm..." files. Would this kind of error occur if there was something wrong in the license file? From everything I've read about verilog and protected IP, it seems vlog *SHOULD* understand what its trying to process, but it doesn't seem to know what `<protected> is?

The second link appears to point to a Japanese language website, which I get the translated directions from so hopefully I'm not missing anything there, but in my simple test case I have *NO* ip included from any of the Mega wizards.

When I try to do anything with Nativelink, nothing at all happens except I see "Successfully launched NativeLink simulation" with the command and the report file contains no messages. So I'm not sure where that is going wrong, but I *DO* see a "Nativelink Error" dialog box which tells me to check the report file, which, as mentioned, is empty.

Actually, there is ONE way I can get NativeLink to open. But when I try to load the module I was building (called simulation_test in this case), it ends up having 1014 errors in which several things are not defined (which seem to be related to the fiftyfivenm_...

I was able to collect 2 transcripts. One is from trying to run the sim_lib compile (transcript_1.txt). The second was from running Questa by running it AFTER compilation (there seems to be a checkbox for that). This at least seems to bring up the design in Questa, but it cannot simulate the design because it doesn't have several fiftyfivenm pieces which, as you pointed out before, is for the MAX10, so I would likely have to have those. I don't know where I would even find those files, or if I have to generate those.

The design is just two, two-input and gates with outputs being fed into an or gate. The original design didn't even have the inputs or outputs going to actual pins, just to see if I could simulate anything without specifically tying it to anything other than the FPGA chip itself, but that led to compile errors, so I connected the inputs to pins on my ARROW DECA board (old now for sure) and the single output to another pin. This let the design compile, but I can't simulate this in any fashion. I was able to add signal tap, and was able to get some things for that, but signal tap, nice as it can be, will mean I have to reprogram the FPGA every time before testing the design. I was hoping to at least do some basic design testing to make sure things worked. But so far, no matter what I've tried, nothing works as it always seems to result in needing files I either don't have, like these transcripts show, or files I can't include because they have encrypted IP which the tool seems not to understand.

I updated this to include a third transcript, which I shows what happens when I try to simulate something using the university path... (i.e. add a vwf file and simulate this way). Because I can't generate the sim_lib for the MAX10, I am guessing that is what is causing the errors in transcript3.txt.

One thing it seems I was finally able to determine is that by removing any mention of fiftyfivenm_atoms_ncrypt.v from quartus/common/tcl/packages/sim_lib_info/sim_lib_info_pkg.tcl , I was able to complete the "Launch Simulation Library Compiler" step. But I'm afraid that might have somehow crippled any functionality from anything in the fiftyfivenm_ver library. It seems to build, but it could just be building an empty stub without any code to back it up. At any rate, that got me one step closer, but even after the library is built, I can't seem to link it to the thing that uses it within the Questa Intel simulation tools. So now I still just get things in the simulation like "fiftyfivenm_io_ibuf" are not defined.

I finally had a colleague test this under his Windows box. On the Windows box, I was able to make the same thing work, although we had to use the "Simulate after compile" checkbox to actually get the simulator to run. But in his case, the system compiles the library for simulation just fine. So under Ubuntu 20.04, it seems to fail to compile the library for simulation. The modification I made, as I suspected, removed the actual guts of the library, so instead of looking for "fiftyfivenm_io_ibuf" as before (as well as a few other things), it is looking for "fiftyfivenm_io_ibuf_encrypted" which is what I suspect was in the encrypted block I removed to get the thing to finish compiling. So now my question is: Why does this fail to compile if I keep the encrypted block, while on Windows, it seems to work just fine (which is what I expected under Ubuntu 20.04)?

As a note: It appears that when trying to simulate using the Quartus menu from "Run Simulation Tool"->"RTL Simulation" it doesn't work because the qnativesim.tcl script eventually says:

"Error: Error: NativeLink did not detect any HDL files in the project"

From there I can't determine what it is looking for, although it appears to be running another TCL script which must not contain any verilog or VHDL files within one of the variables. I'm not sure how that variable is populated because TCL isn't really my thing, but I suspect that some issue with some TCL output might be my issue with generating the simulation library.

Based on your last reply, I think I now understand why it is not working in Ubuntu 20.04. I have discovered that the Questa Intel FPGA Edition is not officially supported on the Ubuntu operating system. My apologies for not noticing this earlier.

Link: [https://www.intel.com/content/www/us/en/support/programmable/support-resources/design-software/os-support.html]

I noticed that someone has attempted to run it on Ubuntu and appears to have been successful. You may consider reaching out to them for further guidance.

[https://community.intel.com/t5/Intel-Quartus-Prime-Software/Quartus-Prime-Lite-21-1-on-Ubuntu-21-10-Questa-does-not-start/m-p/1327018#M71324]

However, please be aware that Ubuntu is not officially supported for Questa Intel FPGA Edition, and any modifications or actions taken based on the community response are done at your own risk.

Best Regards,

Richard Tan

I guess that means Intel is chalking this up to "it's unsupported so you're on your own". Well, for as much help as you've given, thanks. So it appears the suggested workaround is "go get a copy of Windows and use that"?

Regards,

Roboknave.

I understand your frustration regarding the compatibility issue with Ubuntu and the Questa. I apologize for any inconvenience this may have caused.

While Questa Intel FPGA Edition does not officially support Ubuntu as an operating system, there have been reports of users successfully running it on Ubuntu through community-driven solutions.

If running Questa on Ubuntu is not feasible, an alternative solution could be to explore other supported operating systems such as Windows or Linux Red Hat Enterprise to ensure optimal compatibility and support. Perhaps it is possible to run a virtual Windows environment on your Ubuntu system using virtualization software such as VirtualBox, VMware, or KVM (Kernel-based Virtual Machine).

Best Regards,

Richard Tan

From what I can tell, vlog under Ubuntu (and likely other versions of Linux, though I have not direct way to test that right now) and vlog under Windows work differently. Under Windows, it appears to know what an encrypted IP is and how to deal with it. Under Ubuntu, it seems to operate differently and not support it. I'm unsure why that is the case, but this seems to happen even when running vlog by hand, using the same command as listed in the log. I can't track why that is the case.

This isn't even the only issue I've had running Questa, even under Windows. There is one bug that I had to puzzle out and nearly couldn't get things to work there either had I not been having such trouble here. It seems that when you go to build the simulation Library, under Windows or Linux, unless you point the GUI at the binaries, press start compile, let it fail, and then add a single character (such as a slash to the end of the directory), the GUI doesn't register that you've pointed it at anything and keeps telling you to point it at the binaries. I can't tell you how long it took me to figure that one out. And that was using the whole thing under a supposedly SUPPORTED platform. I get the feeling Intel just wants this stuff to die and only support AI based things with FPGAs because there are many niggling little bugs like this. I don't mean to direct this at you, because you have definitely tried to help, but I have been frustrated by these tools for a while now as they seem to have gotten worse and I'm not even sure who to really speak with at this point (and yes, we have a paid license, but that doesn't seem to help).

Again, thanks for the help. Believe me, knowing what "fiftyfivenm..." is cleared a TON of things up. Especially when all of the other files were named based on product names. It has let me navigate around under the hood to get some more answers at least and maybe point me to where to look for myself. I'm also hoping to get an answer in the thread you pointed me to, but I think the person with the answers appears to be gone.

Regards,

roboknave.

PS: just a note - the Linux and Windows versions of vlog (or qverilog... I guess they are the same thing) were at least compiled 1 day different. I don't know if they use the same code base, but the Linux version was compiled 1 day prior to the Windows version. Probably means nothing as maybe it takes the build system a whole day to compile for each platform, but the Windows version of vlog has no problem compiling the encrypted verilog. But the Linux one seems to. Not that anyone will take a look at that, but it seems that's where the problem appears to be. At least for building the Simulation libraries. I don't know if you can just build them on Windows and copy them to Linux and skip the step entirely. I'm hoping I don't have to run things on a VM, as it runs slow enough already as well as maintaining a copy of Windows I didn't have to maintain before, but it seems there isn't another alternative.

I was able to tar up a copy of the simulation library from a Windows box and bring it to the Linux box. Now at least the tool runs and things can be simulated. However, the wave editor doesn't seem to be available. So I'll either have to find another way to specify a waveform, or be forced to use a Windows VM... The further I've gotten down this path, the darker it gets. You weren't kidding when you said it was unsupported.

I'm sorry to hear about your experience and the difficulties you encountered while using our Questa tool.

I admire your dedication and efforts in trying to make it work. However, as the operating system is not officially supported, there are limitations in terms of functionality and compatibility.

At this point, I regret to inform you that there may not be much I can do to address the issues you are facing. I apologize for any inconvenience this may cause.

If there are any other ways I can assist you or if you have any further questions, please let me know.

Best Regards,

Richard Tan