arminalaghi / scsynth Goto Github PK

I tried the following synthesis run:

clear all
degrees =  [3,3,3];
m_input = 4;
m_coeff = 4;
N =  2^4;
domains = [0, 1;
           0, 1;
           0, 1];
granularities = [100, 100, 100];
nameSuffix='Multivariate';
singleWeightLFSR=true;
useParallel = false;

func = @(x1,x2,x3) 0.2*(x1+x2+x3);
VerilogMReSCFromFunction(func, degrees, N, m_input, m_coeff, nameSuffix,...
                    singleWeightLFSR, domains, granularities,useParallel);

And the program is unable to finish synthesis after an indefinite ammount of time. Using the profile feature from Octave I was able to track that line 90 is the responsible for all this time:
data = griddatan(vals(:,1:length(degrees)), vals(:,length(degrees) + 1), xi);

From what I understand, that line tries to approximate the data values to a uniform grid using linear interpolation. Since "granularities" is defined, by default, to 100, this means 101* 101* 101 points to be interpolated (unless I've overseen something). That problem will only aggravate as more variables are added.

The main questions are:
*How vital is this step?
*What happens with the increase or decrease in granularity values?
*How would the 'nearest' algorithm affect the results, if used instead of 'linear'?
*Is it part of solving the linear optimization problem? Are there alternative non-linear solvers available for comparison?

A few questions appeared when analysing the current wrapper module (specifically MReSC, but possibly applicable for all types).

1 - I recognize it uses the count register to count from all 0 to all 1 and check the done status basically when it overflows. This means it has 256 states: 0x00 up to 0xFF. This way, if the true answer to the stochastic function is 1, z_bin will try to add 1 256 times, which will result in an overflow and z_bin = 0 in the end.

Either this assumption is right and the SC works because it's improbably all bits will sum correctly, or it is wrong (maybe it adds 255 times and I'm overlooking it), but that would make z_bin = 255/256, which is also not how stochastic computing is supposed to work.

This concern is linked to the fact that the user can choose WBG as generators and, theoretically, they would produce exact SN representations, which linked to proper correlation considerations, would give a precise answer, that could be 1!

2 - Is the restart signal in LFSR modules necessary? As long as Reset pushes LFSRs to their seed values, they'll have their designed purposes. This leads to the main question: is restarting LFSRs for each calculation necessary? They're already pretty stabilished pseudo-random sources, as long as they've been set with their seeds, they'll have their periodic behaviour, with or without 'restarting' them, and that wouldn't affect SC performance.

I want to recommend changing module naming to prefer a prefix instead of a suffix. When the modules are ready in the destination folder, they end up scattered among any other files. If you've scheduled multiple synthesis runs sequentially, it might be hard finding the group of 4 modules you just generated by suffix. Currently, you can find your files sorting by data modified, but that's impractical.

By prefix, you can simply sort the folder by name (the default in most systems) and all your different files will be visible like

Module1_ReSC_Wrapper...
Module1...
Module1...
Module1...
Module2...
Module2...

Many scripting languages nowadays support keyword arguments, like Python and Octave, but Matlab does not.

As dicussed in multiple StackOverflow questions (for example) they have their own way of dealing with it, which may not be compatible with Octave. This is still not certain, since I haven't tried the detailed approach mentioned in the example, but it definitely is a current issue.

The simplest solution I can think at the moment is simply taking away the current default value form (val1='someValue',val2=100,... to val1,val2,...) and trusting the users to call the function with every argument in place, only proposing a few default values, but not enforcing them.

It has been confirmed that MReSC and ReSC have different LFSR generators. While VerilogSCGenerator has 3 possibilities, VerilogMultivariateReSCGenerator only has one, the SharedLFSR method. (A small patch shall be merged soon about this)

The main problem is the wrappers.

The single variable VerilogSCWrapperGenerator.m (line 131 and beyond) succesfully generates instances of LFSRs with different seeds for Inputs and Constants, also taking in consideration 'degrees'.

The multivariable VerilogMultivariateSCWrapperGenerator.m (line 101 and beyond), on the other hand, doesn't take in consideration number of variables. Thus, it generates LFSRs with the same seeds for different inputs, which will change the stochastic function synthesized!

On line 106 of VerilogMultivariateSCWrapperGenerator.m:

fprintf(fp, '\t\t.seed (%d''d%d),\n', m, round(N*j/(degrees(i)*2+1)));

This expression should, somehow, incorpate the value "i" (the loop count variable) to solve this problem.

Since I'm not currently familiar with the reasoning behind the value round(N*j/(degrees(i)*2+1)), I don't know how to properly modify it.