I need to specify to specman a maximal amount of dut_errors in the test, which after that limit the test should be terminated.
Currently i have the option to terminate the test when an error accord or never.
You can also change the check_effect to ERROR, so it will cause the run to stop. For example (I am taking here Thorsten's example, and modify it):
extend sn_util {
!count_errors: uint;
};
extend dut_error_struct {
pre_error() is also {
util.count_errors += 1;
if util.count_errors > 5 {
set_check_effect(ERROR);
};
};
};
AFAIK this does not work out of the box. You could count the errors by using a global variable and extending the error struct, something in the line of
extend sn_util {
!count_errors: uint;
count() is {
count_errors += 1;
if count_errors > 5 { stop_run() };
};
};
extend dut_error_struct {
write() is also { util.count() };
};
There might even be an object in global that does the counting already, but probably not documented.
Related
I am new to specman, I am now writing a testbench which i want to give many specific test cases to debug a calculator.
For example,
I have two files, the first one called "test1" and the second called "test2".
Here is my code for "test1":
extend instruction_s {
keep cmd_in_1 == ADD;
keep din1_1 < 10;
keep din2_1 < 10;
};
extend driver_u {
keep instructions_to_drive.size() == 10;
};
And here is my code for "test2":
extend instruction_s {
keep cmd_in_1 == SUB;
keep din1_1 < 10;
keep din2_1 < 10;
};
extend driver_u {
keep instructions_to_drive.size() == 10;
};
However, when I tried to test my code, specman shows error, it seems I can't do this like that.
Is there any possible way that I can let specman execute "test1" file first and then run "test2" file?
Or if there is some other way that I can achieve my goal?
Thanks for your helping.
Do you really want to have one test that executes 10 ADD instructions, and run another test that executes 10 SUB instructions?
If so, the common way to do so is to compile your testbench, and run multiple times - each time loading another test file.
For a start, try this:
xrun my_device.v my_testbench.e test1.e
xrun my_device.v my_testbench.e test2.e
I am able to get the count value with the following:
element.all(by.options('type as type for type in types')).then(function(elems){
return elems.length;
})
.then(function(count){
cnt = count;
});
Then later in the code I want to use cnt in a for loop where I also use closure:
for(var x = 1;x < cnt; x++){
search_options(x);
}
function test(y){
console.log('input'+y);
}
function search_options(input){
it('tess', function(){
test(input);
});
}
The problem is that the for does not execute.
Any tips or suggestions, guidance is appreciated or point out any errors.
I have read about IIFE but I find most samples use arrays, I believe 'cnt' has resolved
Unfortunately, I have to use the for loop. 'each' is not suitable.
The problem is that cnt would only be set when the promise would be resolved by the control flow mechanism. The for loop would be executed earlier.
Instead, define cnt as a promise and resolve it in your test:
cnt = element.all(by.options('type as type for type in types')).count();
cnt.then(function (actualCount) {
for(var x = 1; x < actualCount; x++){
search_options(x);
}
});
Also see: Using protractor with loops.
Also, I'm not exactly sure if dynamically creating its this way would actually work, here are some relevant threads:
https://github.com/jasmine/jasmine/issues/830
Can I dynamically create a test spec within a callback?
if ( $num_of_things > 1) {
my $max_element = $num_of_things -1;
for($max_element; $max_element >= 0; $max_element--) {
$value_array[$max_element] = $starting_hash{$key}[$max_element];
}
All of my variables not initialized in this code snippet have been initialized as part of the larger subroutine (which I don't want to put up due to length). I'm not sure where I'm getting the useless use of private variable in void context error in this code, my compiler is telling me it's the last line (with nothing but the closing brace "}"). All help is hugely appreciated as I've been staring at this loop for almost an hour with no idea what is wrong.
Move initialization (and declaration) of $max_element into for statement.
[see ooga comment ]
for( my $max_element=$num_of_things-1; $max_element>= 0; $max_element--) {
$value_array[$max_element] = $starting_hash{$key}[$max_element];
}
I have a few blocks of code, inside a function of some object, that can run in parallel and speed things up for me.
I tried using subs::parallel in the following way (all of this is in a body of a function):
my $is_a_done = parallelize {
# block a, do some work
return 1;
};
my $is_b_done = parallelize {
# block b, do some work
return 1;
};
my $is_c_done = parallelize {
# block c depends on a so let's wait (block)
if ($is_a_done) {
# do some work
};
return 1;
};
my $is_d_done = parallelize {
# block d, do some work
return 1;
};
if ($is_a_done && $is_b_done && $is_c_done && $is_d_done) {
# just wait for all to finish before the function returns
}
First, notice I use if to wait for threads to block and wait for previous thread to finish when it's needed (a better idea? the if is quite ugly...).
Second, I get an error:
Thread already joined at /usr/local/share/perl/5.10.1/subs/parallel.pm line 259.
Perl exited with active threads:
1 running and unjoined
-1 finished and unjoined
3 running and detached
I haven't seen subs::parallel before, but given that it's doing all of the thread handling for you, and it seems to be doing it wrong, based on the error message, I think it's a bit suspect.
Normally I wouldn't just suggest throwing it out like that, but what you're doing really isn't any harder with the plain threads interface, so why not give that a shot, and simplify the problem a bit? At the same time, I'll give you an answer to the other part of your question.
use threads;
my #jobs;
push #jobs, threads->create(sub {
# do some work
});
push #jobs, threads->create(sub {
# do some other work
});
# Repeat as necessary :)
$_->join for #jobs; # Wait for everything to finish.
You need something a little bit more intricate if you're using the return values from those subs (simply switching to a hash would help a good deal) but in the code sample you provided, you're ignoring them, which makes things easy.
I have a Perl routine that manages error checking. There are about 10 different checks and some are nested, based on prior success. These are typically not exceptional cases where I would need to croak/die. Also, once an error occurs, there's no point in running through the rest of the checks.
However, I can't seem to think of a neat way to solve this issue except by using something analogous to the following horrid hack:
sub lots_of_checks
{
if(failcond)
{
goto failstate:
}
elsif(failcond2)
{
goto failstate;
}
#This continues on and on until...
return 1; #O happy day!
failstate:
return 0; #Dead...
}
What I would prefer to be able to do would be something like so:
do
{
if(failcond)
{
last;
}
#...
};
An empty return statement is a better way of returning false from a Perl sub than returning 0. The latter value will actually be true in list context:
sub lots_of_checks {
return if fail_condition_1;
return if fail_condition_2;
# ...
return 1;
}
Perhaps you want to have a look at the following articles about exception handling in perl5:
perl.com: Object Oriented Exception Handling in Perl
perlfoundation.com: Exception Handling in Perl
You absolutely can do what you prefer.
Check: {
last Check
if failcond1;
last Check
if failcond2;
success();
}
Why would you not use exceptions? Any case where the normal flow of the code should not be followed is an exception. Using "return" or "goto" is really the same thing, just more "not what you want".
(What you really want are continuations, which "return", "goto", "last", and "throw" are all special cases of. While Perl does not have full continuations, we do have escape continuations; see http://metacpan.org/pod/Continuation::Escape)
In your code example, you write:
do
{
if(failcond)
{
last;
}
#...
};
This is probably the same as:
eval {
if(failcond){
die 'failcond';
}
}
If you want to be tricky and ignore other exceptions:
my $magic = [];
eval {
if(failcond){
die $magic;
}
}
if ($# != $magic) {
die; # rethrow
}
Or, you can use the Continuation::Escape module mentioned above. But
there is no reason to ignore exceptions; it is perfectly acceptable
to use them this way.
Given your example, I'd write it this way:
sub lots_of_checks {
local $_ = shift; # You can use 'my' here in 5.10+
return if /condition1/;
return if /condition2/;
# etc.
return 1;
}
Note the bare return instead of return 0. This is usually better because it respects context; the value will be undef in scalar context and () (the empty list) in list context.
If you want to hold to a single-exit point (which is slightly un-Perlish), you can do it without resorting to goto. As the documentation for last states:
... a block by itself is semantically identical to a loop that executes once.
Thus "last" can be used to effect an early exit out of such a block.
sub lots_of_checks {
local $_ = shift;
my $all_clear;
{
last if /condition1/;
last if /condition2/;
# ...
$all_clear = 1; # only set if all checks pass
}
return unless $all_clear;
return 1;
}
If you want to keep your single in/single out structure, you can modify the other suggestions slightly to get:
sub lots_of_checks
{
goto failstate if failcond1;
goto failstate if failcond2;
# This continues on and on until...
return 1; # O happy day!
failstate:
# Any clean up code here.
return; # Dead...
}
IMO, Perl's use of the statement modifier form "return if EXPR" makes guard clauses more readable than they are in C. When you first see the line, you know that you have a guard clause. This feature is often denigrated, but in this case I am quite fond of it.
Using the goto with the statement modifier retains the clarity, and reduces clutter, while it preserves your single exit code style. I've used this form when I had complex clean up to do after failing validation for a routine.