Trying to recompile sim libraries for MAX 10 under quartus 21.1

[roboknave]

I saw another question, essentially the same question but different hardware, relating to recompiling the sim libraries to perform simulation.  Anytime you recompile these libraries, it reaches down into protected IP and appears to get "Macro `<protected> is undefined" finally followed by a syntax error.  The files I get this on appear in the $(QUARTUS_ROOTDIR)/eda/sim_lib/mentor/fiftyfivenm_atoms_ncrypt.v file.  I suspect, however, since there are MORE files in this directory which contain protected IP, that I will ALSO get this error for those (and have when I moved the above file as a test), on those files as well.  So how do I either EXCLUDE protected IP from this compilation, or get Quartus to figure out how to use the protected IP?

I'm running Quartus 21.1 (it also happens on the latest Quartus, so this isn't the problem as far as I can tell, and I am using 21.1 because it was the last version that seemed to officially support the MAX10) on Ubuntu 20.04.  I've tried the latest version of the simulation tools combined with this version of Quartus as well, but it appears that protected IP can't be ignored and can't be simulated?  Maybe there is someone who can point me in a direction where I can get a resolution to this, because I can't even simulate a trivial single AND gate without resolving this.  I believe the command that is failing is the following:

vlog -work fiftyfivenm_ver -vlog0lcompat path_to_fiftyfivenm_atoms_ncrypt.v

It then says Macro `<protected> is undefined (two times)

then: syntax error in protected region

then: Syntax error found in the scope following `<protected>'  Is there a missing '::'?

I can't provide the project here as the system I'm using Quartus on *IS NOT* connected to the internet.  So please don't ask.  Besides, I suspect there is something wrong with the setup since I can't simulate even a signal AND gate design plucked down with the schematic editor (so the tool wrote all of the code here and it STILL doesn't work).

Regards.

[RichardTanSY_Intel]

"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. 

[roboknave]

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.

[roboknave]

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.

[roboknave]

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.

[RichardTanSY_Intel]

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

[roboknave]

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.

[RichardTanSY_Intel]

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

[roboknave]

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.

[roboknave]

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.

[RichardTanSY_Intel]

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

[RichardTanSY_Intel]

As the operating system in question is not officially supported, there are limitations in terms of functionality and compatibility.

Unfortunately, I do not have further assistance or solutions to offer in this case.

Considering the circumstances, I will now transition this thread to community support.

If you have any new questions or concerns, please don't hesitate to reach out.

Thank you and have a great day!

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. 

[kadenaron]

Hi,

We are currently facing the same problem.

We are trying to simulate the Triple speed Ethernet IP (TSE).

The compilation fails with the "Macro '<protected> is undefined" message for all encrypted files.

The operating system is RHEL 7.9.

Older versions of questa are able to compile the encrypted file without error:

• Questa v10.2d -> compilation without error
• Questa v10.6C -> fail to compile the encrypted files
• Questa v2023.2 -> fail to compile the encrypted files

It seems that starting from a certain version, Questa is not able to compile the encrypted files.

I've noticed that the keyname used to encrypt the file is "MGC-DVT-MTI", the key_method is "rsa" and the data method is "aes128-cbc".

In the Questa documentation, it is written that for version 2023.2, the MGC-DVT-MTI and MGC-VERIF-SIM-RSA keys are deprecated. Maybe this is related to the impossibility to compile encrypted files which use the MGC-DVT-MTI key?

We use exactly the same script for the 3 version of the simulators.

Without changing anything but the tool version, the compilation with Questa 10.2d succeed and the compilation with version 10.6C and 2023.2 fails. We have tried all language compatibility flags on the VLOG command line but that did not help.

We need to use newer version of the simulator than version 10.2d and we currently can't because we are not able to compile the Ethernet IP. Any help would be welcomed.

Thanks.

---

[roboknave]

I hope you find an answer.  You might look in your logs and see if you can find when it is running vlog.  I suspect, on any version of linux, vlog doesn't seem to know how to process protected IP.  That is what I found on Ubuntu.  I'm not sure that would be different on RHEL.  I'm not sure why it is the case, but maybe replacing just the one vlog binary, from the older package that works, into the newer version of Questa that doesn't, might help here.  Not really sure.  I suspect, if it is as you state above, the newer Questa not supporting the kind of license/crypto protecting the IP, and you needed new IP wrapped in the CORRECT crypto, then it might be a long time coming from Intel.  As it is, while this thread hasn't necro'd that far yet, I suspect you might also have better luck with a new thread in the same vein as this thread because based on a previous reply, I don't think Intel folks are even paying attention to this thread anymore because I mentioned the dreaded "unsupported platform".  Not that Intel has to support every old thing Altera had out there, but the MAX10 is still in their "recommended for current designs" list (good at least for my case) and they did SOME work in the past to support Quartus in Linux.  So I was kind of hoping for a bit more support when I asked this, but it appears to be a bridge too far.

Anyway, good luck with this.

PS:  As I noted above, the Windows version of the software DOES seem to work fine.  Running vlog in the Windows version still supports the crypto.  Maybe it didn't get any update?  Not sure.  In any case, using Windows might actually help you.