[sv-ec] solve before and randc inconsistency

From: Daniel Mlynek <daniel.mlynek@aldec.com.pl>
Date: Thu Nov 18 2010 - 08:18:36 PST

I'm having 2 doubts according to variable ordering. Could you please
express yours opinion on them:

*1.* Ordering of randomization of variable is in general done in 2 cases
- when solve before operator is used and when variable is rand*c*
I'm finding below 2 descriptions defining ordering contradictory

*Solve before*: "Variable ordering can be used to force selected corner
cases to occur more frequently than they would otherwise. However, a
"solve...before..." *constraint does not change the solution space and,
therefore, cannot
cause the solver to fail.*"

*randc: *"The semantics of random-cyclical variables requires that they
be solved before other random variables. A set of constraints that
includes both rand and randc variables shall be solved so that the randc
variables are
solved first, and this can sometimes cause randomize() to fail."

In my opinion definition used in randc is correct. In some cases
ordering can cause randomization failure. Lets analyze case like below:

class C;
         rand reg [3:0]r1,r2;
         function void post_randomize;
                 $display(" %d %d ",r1, r2);
         endfunction
     constraint c { solve r1 before r2;}
endclass

module top;
         C hnd=new;
         initial begin
                 repeat(20)begin
                         assert( hnd.randomize()with *{r1>r2; r2>10;
}*)else $error("randozmiation failed");*//here randomizatio should fail
if r1 is randomized 1st then we do not know what value will have r2*
                 end
         end
endmodule

*Summarizing: "**constraint does not change the solution space and,
therefore, cannot cause the solver to fail." used in solve before
definition is not true*

*2.* LRM says "Variables that are partially ordered" what does it mean?
what are partially ordered variables?

DANiel

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Nov 18 08:19:02 2010

This archive was generated by hypermail 2.1.8 : Thu Nov 18 2010 - 08:19:23 PST