When we using the PROLEAD to read a new cell created below:
Gate
1
MUX3_X1
5
A B C S0 S1
1
Z
((not S0) and (not S1) and A) or (S0 and (not S1) and B) or (S1 and C)

We will see that the cell cannot be read correctly. The code in Read.cpp
if (*pos != 0)
{
sprintf(Start, "I%d", Intermediate + CellType->Operations[i].NumberOfClauses + 1);
strncpy(TempStr, End + 1, Max_Name_Length - 1);
TempStr[Max_Name_Length - 1] = '\0';
strcat(MyStr, TempStr);
}

            CellType->Operations[i].NumberOfClauses++; // Fix the not() read bug
    } while (*pos != 0);
}

Here is an bug that, after strcat(MyStr, TempStr), the char pointer pos address will inexpertly change.
I change the code as:
if (*pos != 0)
{
sprintf(Start, "I%d", Intermediate + CellType->Operations[i].NumberOfClauses + 1);
strncpy(TempStr, End + 1, Max_Name_Length - 1);
TempStr[Max_Name_Length - 1] = '\0';
strcat(MyStr, TempStr);
CellType->Operations[i].NumberOfClauses++; // Fix the not() read bug
}
else
{
CellType->Operations[i].NumberOfClauses++; // Fix the not() read bug
break; // Fix the not() read bug
}
pos=MyStr; // Fix the not() read bug */

    } while (*pos != 0);
}

The issue is fixed. Please check.
Thank you,
Vienna
NVIDIA.

Is your feature request related to a problem? Please describe.
It is frustrating to have to change the max_no_of_threads setting every time you run the same test on systems with a vastly different number of cores.
If you don't do this, you either incur additional overhead on the system with fewer cores or you don't use all the cores that the stronger system has available.

Example:
We have two systems, a server and a laptop, and we want to run a configuration on both.
The server has 128 CPU cores.
Let us now assume that we want to use all cores of the server.
Therefore, we set max_no_of_threads to 128.
If we now run the same config on a laptop with 12 threads (logical cores) we still create 128 threads of which only 12 can be executed in parallel.
For each additional specified thread that is also spawned, we generate unnecessary overhead.
The alternative is to set max_no_of_threads to 12.
This might be the best option to run the test with the laptop, but with regard to the server, 116 available cores now remain unused.

Describe the solution you'd like
Allow to set max_no_of_threads to the keywords all to select all logical cores of the current system..
Additionally, the keyword half could be used to select the half of all available logical cores.

Describe alternatives you've considered
An alternative to introducing the all keyword is to select all cores when max_no_of_threads is set to 0.

Describe the bug
The release build of prolead does not throw an error if an incorrect number of expected_outputs or no_of_groups is given.
Instead, PROLEAD simply closes after "Read settings file..." is issued.

To Reproduce
Steps to reproduce the behavior:

1. Select a working configuration.
2. Manipulate it in a way that it contains either

% no_of_groups bug
no_of_groups % number of groups to conduct the test, e.g., fixed vs. fixed, fixed vs. random, etc.
2

64'h$$$$$$$$$$$$$$$$
%64'h$$$$$$$$$$$$$$$$

no_of_outputs
2

[31:0] rd_s0
[31:0] rd_s1

expected_output

32'h$$$$$$$$
32'h$$$$$$$$

, or

% expected_output bug
no_of_groups % number of groups to conduct the test, e.g., fixed vs. fixed, fixed vs. random, etc.
2

64'h$$$$$$$$$$$$$$$$
64'h$$$$$$$$$$$$$$$$

no_of_outputs
2

[31:0] rd_s0
[31:0] rd_s1

expected_output

32'h$$$$$$$$
%32'h$$$$$$$$

3. Execute PROLEAD

Expected behavior
We expect a meaningful error message, which explains what the problem is.
In the first given case above the error message should contain information that two inputs must be given if no_of_outputs=2.
In the second case the error message should inform the user that two expected_outputs must be given if no_of_outputs=2.

Additional context
Since it is already planed to replace the current parser with a more robust one, using a standardized format (see #10),
we plan to address this bug by introducing the new parser.

Is your feature request related to a problem? Please describe.
Right now, a configuration for PROLEAD is written in a custom format and thus requires a custom parser.
Therefore, we have to maintain the code for parsing the config.
Furthermore, the structure of the config file is not straight forward.
It takes some time to get familiar with it.
Thus, it could be advantageous to use a well established file format,
which is already known by the users.

Describe the solution you'd like
It would be great to have the possibility to configure PROLEAD via a JSON or YAML config file.
This addresses both the requirement of maintaining a custom parser and using a well established file format.
Therefore, we should evaluate alternative libraries which can parse JSON or YAML.
In a next step, we should implement a new configuration parser utilizing one of the evaluated libraries.

PROLEAD is used broadly for research.
Therefore, it is necessary that we do not drop support for the old parser directly after finishing the new one.
This could cause problems with submitted artifacts.

Furthermore, a converter from the old in the new configuration file format should be provided.

Describe alternatives you've considered
Change nothing.