[sv-ac] Summary of my concerns with 2804

From: Little Scott-B11206 <B11206@freescale.com>
Date: Tue Jan 25 2011 - 06:50:02 PST

Hi all:

I thought I would summarize my concerns with 2804 in writing prior to the meeting. The current language in the mantis states, "If the procedure is inside a checker, and the event control did not satisfy this condition before the substitution of actual values for any event arguments to the checker, it shall be checked again after this substitution." My understanding is that if a clock can be inferred pre-substitution it will be inferred at that time and not checked post-substitution. The concern is that the substitution can create a situation where the clock that was inferred pre-substitution would no longer be inferred post-substitution because the substitution results in code that breaks the inference rules.

Pre-substitution:
always @clk1 begin
   a1: assert property(a);
   cVar1 <= var1;
   cVar2 <= var2;
end

clk1 is inferred as the assertions clock. The substitution is as follows:
clk1 -> posedge clk1 or negedge clk2
var1 -> clk1
var2 -> clk2

Post-substitution:
always @(posedge clk1 or negedge clk2) begin
   a1: assert property(a);
   cVar1 <= clk1;
   cVar2 <= clk2;
end

According to the pre-substitution inference 'posedge clk1 or negedge clk2' is the assertion clock. No clock would be inferred if this block was evaluated for clock inference post-substitution. I don't necessarily see a problem with this result, but I think we should be aware that this sort of thing is possible with the update to inference rules.

Thanks,
Scott

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Jan 25 06:50:28 2011

This archive was generated by hypermail 2.1.8 : Tue Jan 25 2011 - 06:50:37 PST