RE: [sv-ac] blocking assignments

Hi Arturo,

My example is artificial, I think we should adopt Matt's example
instead.

Thanks,
Dmitry

-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Arturo Salz
Sent: Wednesday, November 08, 2006 11:54 PM
To: Rich, Dave; sv-ac@server.eda.org
Subject: RE: [sv-ac] blocking assignments

Unfortunately, the code used is problematic because it will cause
synthesis to infer a latch (actually two latches the way it is written).

	always_comb begin
                 if (cond) begin
                     a = b;
                     b = c;
                  end
	end

Even if you remove the conditional, this code is problematic

	always_comb begin
                   a = b;
                   b = c;
	end

The above block will cause signal a to exhibit memory (the previous
value of b) whereas synthesis will treat it as a combinational block and
infer a wire:

	assign a = c;

    Arturo

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Rich, Dave
Sent: Wednesday, November 08, 2006 5:57 AM
To: sv-ac@eda.org
Subject: RE: [sv-ac] blocking assignments

BTW,

The usage of 'always @(*)' should be deprecated in favor of
'always_comb', which is considered is more in line with synthesis rules.

> -----Original Message-----
> From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org]
On
> Behalf Of Korchemny, Dmitry
> Sent: Wednesday, November 08, 2006 2:58 AM
> To: Doron Bustan; sv-ac@server.eda.org
> Subject: RE: [sv-ac] blocking assignments
> 
> Hi Doron,
> 
> You are right. @(posedge clk) is a typo, should be @(*) (or @(b), but
it
> is not synthesizable).
> 
> always @* begin
>                 if (cond) begin
>                      a = b;
>                      assert (a == c) ;
>                      b = c;
>                end
> end
> 
> Is it correct now?
> 
> I'll try to get a real life example in addition to this artificial
one.
> 
> I think, we should define simulation semantics that would be
consistent
> with FV in the synthesizable case. Two candidates are
> -  taking the latest signal value from the active region before the
> first entry to the observed region, and
> - "sampling" the signal values at the first entry to the observed
> region. As for non-synthesizable or "difficult" for synthesis example,
> it is important only that the algorithm is well defined: for "exotic"
> cases it is difficult to invent something better than immediate
> assertions.
> 
> Thanks,
> Dmitry
> 
> -----Original Message-----
> From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org]
On
> Behalf Of Doron Bustan
> Sent: Wednesday, November 08, 2006 12:26 AM
> To: sv-ac@server.eda.org
> Subject: [sv-ac] blocking assignments
> 
> Just to make sure that I don't miss something important...
> 
> In the example:
> 
> always @(posedge clk) begin
>                 if (cond) begin
>                      a = b;
>                      assert (a == c) ;
>                      b = c;
>                end
> end
> 
> the assertion is being evaluated at most once in every "clk" cycle.
> 
> 
> I think that we need more than one always block to cause the assertion
> to
> execute more than once, something like:
> 
> always @(b) begin
>                if (cond) begin
>                      a = b;
>                      assert (a == c) ;
>                end
> end
> 
> always @(c) begin
>             b = c;
> end
> 
> this will cause the assert to possibly fire twice at the same time
step
> without
> exiting the active region. We should also consider the following case:
> 
> 
> always @(b) begin
>                if (cond) begin
>                      a = b;
>                      assert (a == c) ;
>                end
> end
> 
> always @(c) begin
>             b <= c;
> end
> 
> Here the assert is being triggered twice, but the simulator goes to
the
> NBA
> region between the two triggers.
> 
> 
> is this right?
> 
> Doron