Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Quartus path resolution incorrect for windows, SILENT fallback to QUARTUS_ROOTDIR #671

Open
dbee-novosound opened this issue Sep 27, 2024 · 3 comments
Labels
bug Something isn't working

Comments

@dbee-novosound
Copy link

Describe the bug
Setting quartusInstallationPath does not work on windows, getQuartusPath only checks for unix-style executable endings. I lost a lot of time trying to figure out why the teros config was ignoring both my global and project specific settings and just using my QUARTUS_ROOTDIR settings. I have attached the fix for windows as a suggestion.

rootdir was working because it doesn't check file existence of the executable, it just accepts if the directory exists.

Perhaps another fix is to just not check for full installation path to quartus.exe, but also only just for existance of directory for quartus installation path.

To Reproduce
Be on windows and try to set installation path to a quartus version other than the one defined by rootdir.

Code
Here is a fix, and a suggestion to add emitter logging so the resolution of tool paths can be at INFO or DEBUG level

function getQuartusPath(config, emitterProject = undefined) {
    // Try with config installation path
    let quartusInstallationPath = config.tools.quartus.installation_path;
    if (quartusInstallationPath !== "") {
        if (file_utils.check_if_file(quartusInstallationPath)) {
            quartusInstallationPath = file_utils.get_directory(quartusInstallationPath);
        }
        const quartusBinPath = path_lib.join(quartusInstallationPath, "quartus");
        const quartusBinPathExe = quartusBinPath + ".exe";
        if (emitterProject !== undefined) {
            emitterProject.emitEventLog("Checking if quartus bin available at " + quartusBinPath, projectEmitter_1.e_event.STDOUT_INFO);
        }
        if (file_utils.check_if_path_exist(quartusBinPath) || file_utils.check_if_path_exist(quartusBinPathExe)) {
            if (emitterProject !== undefined) {
                emitterProject.emitEventLog("Quartus path exists!" , projectEmitter_1.e_event.STDOUT_INFO);
            }
            return normalizePath(quartusInstallationPath);
        }

    }
    runTask(taskType, callback) {
        const config = super.get_config();
        this.taskStateManager.setCurrentTask(undefined);
        const quartusDir = (0, utils_1.getQuartusPath)(config, this.emitterProject);
        const projectDir = (0, file_utils_2.get_directory)(this.projectDiskPath);
        const family = this.get_config().tools.quartus.family;
        return (0, taskRunner_1.runTask)(taskType, this.taskStateManager, quartusDir, projectDir, this.get_name(), this.currentRevision, family, this.emitterProject, callback);

Please complete the following information:

  • OS: windows 11 pro
  • VSCode version : 1.93.1

Screenshots
If applicable, add screenshots to help explain your problem. Share the code as text, not as a screenshots!

Additional context
When you FIRST enter the installation path in the configuration settings, you should immediately get feedback if that is a valid path or not. very frustrating experience to hunt down this issue with a severe lack of logging.

Also, it was super annoying that the tool kept editing my QSF file.

@dbee-novosound dbee-novosound added the bug Something isn't working label Sep 27, 2024
@qarlosalberto
Copy link
Contributor

Describe the bug Setting quartusInstallationPath does not work on windows, getQuartusPath only checks for unix-style executable endings. I lost a lot of time trying to figure out why the teros config was ignoring both my global and project specific settings and just using my QUARTUS_ROOTDIR settings. I have attached the fix for windows as a suggestion.

Thanks for the report! It should be fixed in the market version. Please let me know if now it's working fine.

When you FIRST enter the installation path in the configuration settings, you should immediately get feedback if that is > a valid path or not. very frustrating experience to hunt down this issue with a severe lack of logging.

Sure, it's my next big task. I want to have a complete extension checker.

Also, it was super annoying that the tool kept editing my QSF file.

Can you exaplain more? In which situations? It should be edited when you add files, change config...

@dbee-novosound
Copy link
Author

Many thanks for the quick turn around, much appreciated!! I've just tried it and checked and it all seems good now.

Also, it was super annoying that the tool kept editing my QSF file.

Can you explain more? In which situations? It should be edited when you add files, change config...

I think this may be a quartus quirk rather than a teros quirk, but when my installation path was pointing to quartus prime pro (22.2) and I was in a workspace with a QSF created for a quartus prime lite (20.1.1), it was commenting out a bunch of qsf lines and saying they are deprecated in 22.2 (this was how I recognised that my installation path wasn't working correctly). It seemed to be constantly running quartus through the qsf because if I reverted the local changed it made, it would almost instantly re-make them.

It may be that because I was reverting the qsf changes, that counted as a file change that then prompted quartus to modify it again.

@dbee-novosound
Copy link
Author

@qarlosalberto Apologies, after setting up another project with quartus-pro and setting quartus-pro as my default setting. I am seeing some odd behaviour again.

I think both the project-specific settings for quartus tool path are being used simultaneously on any QSF. The project I am trying to use is a quartus-lite cyclone-V project and is correctly selected, but the other project is a quartus-pro cyclone 10GX project.

I observe that my .qsf file is stuck in an infinite loop of one quartus tool modifies LAST_QUARTUS_VERSION to one version and then the other changes it back.

After some trial and error I found the main cause was when I had two workspaces open at the same time with differently selected projects of different quartus versions. My work around is to only open one workspace at a time when using teros, but I really dislike how my workspace specific configs were bleeding into eachother.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants