solve...before is a little misleading, because it does not actually
impose an ordering. Rather, it alters the probability distribution of
the results.
e.g.:
class C;
rand bit a;
rand bit [31:0] b;
constraint c { a == 1 -> b == 0; }
endclass
Let's randomize this. What is the solution space?
a==1 b==0 is one solution.
a==0 b==... is 2**32 other solutions.
Therefore, there are 2**32+1 solutions to this problem, and only one
solution has a==1. Therefore, the probability that randomize will
produce a==1 is very low.
You probably wanted a==1 to come up 50% of the time. You can do that by adding:
solve a before b;
All this does is make the overall probability distribution for a
completely independent of b. The same 2**32+1 solutions could
potentially be produced, but they will be produced with different
probability.
solve...before indeed cannot cause a compliant solver to fail. The
solver must find a solution within the solution space, and
solve...before does not alter the solution space.
randc does indeed alter the solving order, but that's consistent with
solve...before, as the latter does not alter a true solving order.
On Thu, Nov 18, 2010 at 11:18 AM, Daniel Mlynek
<daniel.mlynek@aldec.com.pl> wrote:
> 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 randc
> 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.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Nov 18 08:50:36 2010
This archive was generated by hypermail 2.1.8 : Thu Nov 18 2010 - 08:50:41 PST