Describe the bug Windows build failed after installing all dependencies and adding environment variables as instructed in the foedag documentation in dependencies section. It failed when running the make "release command " after all environment configuration

To Reproduce Steps to reproduce the behavior:

• Install Visual Studio Community Edition o From Installer, Check "Desktop development with C++" o Ensure "CMake tools for windows is checked"
• Install QT5 for MSVC o I tried https://download.qt.io/official_releases/qt/5.12/5.12.12/qt-opensource-windows-x86-5.12.12.exe from
  https://www.qt.io/offline-installers (there might be easier paths/better installers for this) o When asked to select components, checked MSVC 2017 32 and 64 bit

• Update Environment Variables o System Properties > Advanced > Environment Variables… o Edit Path and add a new entry for Qt5, mine was C:\Qt\Qt5.12.12\5.12.12\msvc2017_64\bin o Create a new Variable called Qt5_DIR and point it to cmake/Qt5, mine was C:\Qt\Qt5.12.12\5.12.12\msvc2017_64\lib\cmake

• Install Make Package by following command for windows: Steps for Installing "windows make": o Installed make using "winget install gnuwin32.make" on cmd o Select environment variable under the Advanced tab. o Under the variable name, enter make. o Under Variable as "make" and value as , C:\Program Files(x86)\GnuWin32\bin\make.exe.

• MSYS2 env with the MinGW64 g++ compiler can be used to build FOEDAG as mentioned in the documentation.
• git clone https://github.com/os-fpga/FOEDAG.git
• cd FOEDAG
• git submodule update --init --recursive

• make release -ERRORS: Screenshots

Expected behavior FOEDAG should build and run successfully in Windows environment

Additional context Add any other context about the problem here.

Motivate of the pull request

Add post synthesis project type

Which part of the code base require a change

• [x] Library: compiler, newproject
• [ ] Plug-in:
• [ ] Engine
• [ ] Documentation
• [ ] Regression tests
• [ ] Continous Integration (CI) scripts

Screenshots

Do we have a plan for specific parameters in the project settings JSON file? Some variables can already be set by TCL commands, if these are also defined in the JSON file, would it be appropriate for the TCL command to override the JSON file settings?

counter_16bit.json.txt A example preliminary JSON file that we are currently using is attached to provide more clarity on a possible way to organize the parameters. VPR parameters are separate as of now, and they should go into the appropriate Task Settings - it is not yet clear on how to neatly categorize them.

I intend to implement the following functions on the dialog.

New project wizard
Project Location
    project name(default project_1)
    project location (support create subdirectory)
    
Project Type
    RTL project (default)
    Post-synthesis project
    
Add Design Source Files
    Add files
    Add directories
    Create file
        file name
        file type
        file path
    Display source file list
    Remove
    Move up
    Move Down
    Support copy design files to project
    
Add Constraints
    Add files
    Create file
        file name
        file type
        file path
    Display source file list
    Remove
    Move up
    Move Down
    Support copy files to project
    
Select device/board
    Display the device/board list(Read data form a device/board file(like *.xml))
    Support search by family, device，package and so on.
    
Summary
    Displays the details of the project you are about to create.

The project type and file type can be configured through a configuration file(like *.xml).

After clicking finish, the project file and project directory will be generated.As follows:

About the widget window floorplanning ,I will do it soon by QT designer.

Open to discussion here.

http://yosyshq.net/yosys/cmd_verific.html supports Compilation Libraries. It is specially important for VHDL. Please read the Yosys documentation to understand the principles. Add additional options to the Tcl command add_design_file: -work and -L If -work is not specified, no need to pass the option to the Verific/Other parser, by default Verific/Other will compile under the "work" library (Equivalent to -work work).

Typical Foedag usage: ... add_design_file -work lib1 file1.vhd file2.vhd add_design_file -work lib2 file21.vhd file22.vhd add_design_file -L lib1 -L lib2 top.vhd ... Will translate to the Yosys script: ... verific -work lib1 -vhdl file1.vhd file2.vhd verific -work lib2 -vhdl file21.vhd file22.vhd verific -L lib1 -L lib2 -vhdl top.vhd ...

The GUI New Project should also support the Library concept. Compilation libraries are both usable for VHDL and Verilog files.

Motivate of the pull request

• [x] To address an existing issue. If so, please provide a link to the issue: Add support for build all the components under Windows with MSYS2 + MinGW64
• [ ] Breaking new feature. If so, please describe details in the description part.

Describe the technical details

What is currently done? (Provide issue link if applicable)

What does this pull request change?

Which part of the code base require a change

• [ ] Library:
• [ ] Plug-in:
• [ ] Engine
• [ ] Documentation
• [ ] Regression tests
• [ ] Continous Integration (CI) scripts

Impact of the pull request

• [ ] Require a change on Quality of Results (QoR)
• [ ] Break back-compatibility. If so, please list who may be influenced.

The MSYS2 MinGW64 env is assumed to be setup, and has the following packages installed:

pacman -S --needed base-devel mingw-w64-x86_64-toolchain git mingw-w64-x86_64-cmake mingw-w64-x86_64-qt5-base-debug mingw-w64-x86_64-qt5 mingw-w64-x86_64-swig mingw-w64-x86_64-qt5-declarative-debug mingw-w64-x86_64-tcl mingw-w64-x86_64-zlib

Motivate of the pull request

• [x] To address an existing issue. If so, please provide a link to the issue: #36
• [ ] Breaking new feature. If so, please describe details in the description part.

Describe the technical details

What is currently done? (Provide issue link if applicable)

Currently, FOEDAG has the following limitations:

• The start gui command cannot be typed in through Tcl interface. Main window pops up directly at the beginning
• When you close main window, the complete program ends. There is no interaction possible between GUI and tcl

What does this pull request change?

This PR improves in the following aspects:

• [x] Added a Tcl-Qt notifier which enables the interaction between GUI and tcl
• [x] Added a command gui_end which can close Qt without terminating tcl. GUI can be restarted any time when gui_start command is typed in

Which part of the code base require a change

• [ ] Library:
• [ ] Plug-in:
• [x] Engine
• [ ] Documentation
• [ ] Regression tests
• [ ] Continous Integration (CI) scripts

Impact of the pull request

• [ ] Require a change on Quality of Results (QoR)
• [ ] Break back-compatibility. If so, please list who may be influenced.

Since we're going to use Qt's open source and @tangxifan asked about our GUI's license, I just checked Qt Open source Licensing FAQ and Qt Open Source Obligations of the GPL and LGPL. MIT licensed software can be integrated with GPL software, though not being a law expert and lacking experience with mixed-license open source projects, I'm not sure if that means we can take GPL/LGPL code from Qt (headers, libraries, modules etc.), modify it and then make it MIT, or do we have to keep our own MIT code strictly seperated from Qt's GPL/LGPL code, or how else should this be properly handled. As the definitive versions of all the above licenses are in English, I recommend someone in the States consult a law expert familar with this field. Keep in mind that GPL/LGPL both have several versions so that's another thing to watch out for. If consulting a lawyer is not viable, maybe we should go with LGPLv3 for the peace of mind?

Motivate of the pull request

Provide user another compilation from with simulation.

Describe the technical details

TaskManager has two option start compilation:

• Regular steps, like Analyze, synth, place...
• Regular with simulation.

Also every task now can be enabled and disabled. Disabled task will be grayed out and will not run.

Which part of the code base require a change

• [x] Library: compiler, foedagcore
• [ ] Plug-in:
• [ ] Engine
• [ ] Documentation
• [ ] Regression tests
• [ ] Continous Integration (CI) scripts

Screenshots

Disabled Simulate RTL:

Describe the bug A clear and concise description of what the bug is.

To Reproduce Steps to reproduce the behavior:

1. Clone repository and checkout commit id:
2. Execute a test case or your own example:
3. See error

Expected behavior A clear and concise description of what you expected to happen.

Screenshots If applicable, add screenshots to help explain your problem.

Enviornment (please complete the following information):

• OS:

• Compiler:

• Version:

Additional context Add any other context about the problem here.

Is your feature request related to a problem? Please describe. Windows is a popular platform where most GUI projects are run. It is reasonable to ensure that our GUI is continuously deliverable on Windows platform

Describe the solution you'd like Set up a workflow on Github Actions, testing

• Build compatibility of the codes on Windows machines
• Run regression tests on Windowns machines

Refer to the workflow example at

https://github.com/chipsalliance/Surelog/blob/ac38329a10128579831ee8fd8dfa7a8bcfbfb936/.github/workflows/main.yml#L128

Describe the bug When adding a new test, it was discovered that system calls to python in the IP Catalog were failing. After some debug, it was observed that https://github.com/os-fpga/FOEDAG/blob/809bd94533e4e0e47db656249b6c0ba6c279f7e2/src/IPGenerate/IPCatalogBuilder.cpp#L120 is always empty in CI tests run on windows. On first glance the 2 possible causes are:

1. Python might not be properly installed on windows in our CI
2. LocateExecFilemight not be working on windows

To Reproduce Due to windows build not building locally for some right now, this is a bit hard to test, I'm unable to build windows locally so I can only see this error in github CI's when the tests are run on windows (note the test in question is currently disabled on windows). Steps to reproduce the behavior:

1. Add the following to the bottom of registerBasicGuiCommands()

  auto locate_exec_file = [](void* clientData, Tcl_Interp* interp, int argc,
                             const char* argv[]) -> int {
    if (argc < 1) {
      Tcl_AppendResult(
          interp, qPrintable("Expected Syntax: locate_exec_file <binary_name>"),
          nullptr);
      return TCL_ERROR;
    }

    std::filesystem::path foundPath =
        FOEDAG::FileUtils::LocateExecFile(argv[1]);

    Tcl_AppendResult(interp, foundPath.c_str(), nullptr);
    return TCL_OK;
  };

  session->TclInterp()->registerCmd("locate_exec_file", locate_exec_file,
                                    GlobalSession->MainWindow(), nullptr);

2. Add #include "Utils/FileUtils.h" to the same file
3. Build changes
4. On windows, open foedag and try locate_exec_file python3 in the console

Expected behavior

• FileUtils::LocateExecFile("python3") or test tcl command locate_exec_file python3 should return a valid path on windows runs
• tests/TestBatch/test_ip_configure_load.tcl should successfully run in windows CI (note the test currently disables itself on windows run, so remove the windows check inside the test first before verifying)

Enviornment (please complete the following information):

• OS: Other: Windows GitHub CI and possibly local windows
• Version: Current main

Additional context It's currently not known if this is a python install issue or a util function not working in windows issue so both areas need to be investigated It's possible that python3 isn't the proper name on windows, might test with python and python2 to see if our target binary names are correct

Is your feature request related to a problem? Please describe. VPR team is developing new features for their GUI (Visualizer for FPGA architecture)

Here are the thoughts proposed by Prof. Vaughn Betz and the student who is working on this project.

Vpr UI: use glade (graphical GUI builder to create all widgets) or use glade only for top-level organization (grid/layout) and code to create menus
Let me know if you have an opinion; can do either but Sebastian trying to figure out what is easiest for others for the future

Describe the solution you'd like If we do want to think about integrating the GUI as a widget into FOEDAG, we should talk to them and see how the choice on GUI builder will impact the FOEDAG integration.

Describe the bug By default, all the columns are sized according to their content. Task column allows manual resizing. While holding the mouse, text gets truncated according to the current width, but the button remains stable till the user releases the button:

Status column doesn't have this problem because it has fixed width. Stats can also be resized, but doesn't have such button. So it's just Task column.

We want to have access to qt widgets from tcl scripts. For example:

% set widget [expr getWidget "console"]
% ...

@alain-rs please describe more requirements for this feature.

Currently we can start new project only once. Possible solutions:

• Open another instance of the whole FOEDAG project. Create another process.
• Open another main widget within same process.