You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the past, we where automatically computing the number of segments per batch capture to maximize capture performance. Now, we always need to manually specify this value in the config file. But as different value are supported depending on the capture mode (random-batch vs. fvsr-key-batch) the user has to change multiple values in the config file.
I suggest to automatically choose the max value if no value is specified in the config file for Husky. WaveRunner we should probably leave untouched.
The text was updated successfully, but these errors were encountered:
If no num_segments is provided in the config file for Husky,
the scope driver automatically sets it to num_segments_max.
For WaveRunner, an error is raised if no num_segments max is
provided.
CloseslowRISC#277.
Signed-off-by: Pascal Nasahl <[email protected]>
If no num_segments is provided in the config file for Husky,
the scope driver automatically sets it to num_segments_max.
For WaveRunner, an error is raised if no num_segments max is
provided.
CloseslowRISC#277.
Signed-off-by: Pascal Nasahl <[email protected]>
If no num_segments is provided in the config file for Husky,
the scope driver automatically sets it to num_segments_max.
For WaveRunner, an error is raised if no num_segments max is
provided.
Closes#277.
Signed-off-by: Pascal Nasahl <[email protected]>
In the past, we where automatically computing the number of segments per batch capture to maximize capture performance. Now, we always need to manually specify this value in the config file. But as different value are supported depending on the capture mode (random-batch vs. fvsr-key-batch) the user has to change multiple values in the config file.
I suggest to automatically choose the max value if no value is specified in the config file for Husky. WaveRunner we should probably leave untouched.
The text was updated successfully, but these errors were encountered: