Subject: Re: [sv-ac] context extraction resend
From: Prakash Narain (prakash@realintent.com)
Date: Wed Feb 19 2003 - 12:09:30 PST
Steve,
I object to the default clock specification in the testbench.
That makes the code unreadable. Procedural assertions
are typically written by designers and the information for
interpreting the assertions should be available in the
module.
Also, your clock-inference proposal needs to specify the
rules for inferring the clock for procedural asserts in a
combinational block. I believe that this adds way too much
complexity without providing much value.
Best Regards,
Prakash
Stephen Meier wrote:
> Adam: Thanks for your helpful and clarifying comments.
>
> At 11:09 AM 2/19/2003 -0600, Adam Krolnik wrote:
>
>
>
>> Hi Steve;
>>
>> These slides are good descriptions of the extraction.
>>
>> I have a few questions from them:
>>
>> o Page 3, How does the association of a 'clk' attribute work in
>> the presence of multiple edge sensitive signals? What is the
>> 'reset' attribute attached to? Does it mean accept=('reset' signal) ?
>
>
> The rule for extraction is to find the edge trigger signal which is
> not referenced inside of the always block. This is the same inference
> as with synthesis tools.
>
> There is no feature to infer reset attributes, it does not mean
> accept=(<reset_signal>). This was not supported in DWG so
> it is not there.
>
>> E.g.
>>
>> always @(posedge clk or negedge rst_n or negedge set_n)
>> if (!rst_n) q <= 1'b0;
>> else if (!set_n) q <= 1'b1;
>> else q <= d;
>>
>>
>> o Page 6. assert/cover must resolve to clocked.
>>
>> Can I do this?
>>
>> function [1:0] encode4;
>> input [3:0] onehot;
>>
>> begin
>> assert ($onehot(onehot));
>> case (1'b1) //synopsys full_case parallel_case
>> onehot[0] : encode4 = 2'd0;
>> onehot[1] : encode4 = 2'd1;
>> onehot[2] : encode4 = 2'd2;
>> onehot[3] : encode4 = 2'd3;
>> endcase
>> end
>> endfunction
>>
>> ...
>> wire [1:0] ec2 = encode4(dec4);
>> ...
>> wire [1:0] ec3 = encode4(dec14);
>>
>> Will this obtain a default clock and will it check all instantiations?
>
>
> This seems complicated. You could have default clocking coming
> implicitly which may not be immediately apparent. We may need to
> consider restricting assertions to not be defined inside of functions
> or tasks. Do you think we can
> make this type of restriction ? Another restriction is to say that
> any assertions inside of functions or tasks must be explicitly clocked.
>
>
>
>> o Page 4 - How does one specify a default clock?
>
>
> The default clock is specified in the clocking domain description coming
> from testbench in SV-EC. The current proposal for clocking domain
> defines a default clock for a module so if an assertion refers to signals
> within the module then the default clock is used as sampling condition.
>
>
>> o Page 12 shows an example:
>>
>> always @(posedge ...
>> if (c1) property p1 = ...
>>
>>
>> always @(posedge ...
>> if (c2) r1: assert (p1)
>>
>>
>> 1. Verilog does not allow declarations inside unnamed procedural blocks.
>> 2. Verilog declarations terminate at the end of the block scope in
>> which they
>> are defined. Something like:
>>
>> Error-[IND] Identifier not declared
>> Identifier 'p1'.
>> "illegref.v", 18
>>
>> Solving these issues has bearing on how templates work.
>
>
> Yes this is a departure from standard Verilog restrictions. We should
> review this
> further. There is value in getting the context extraction, but we
> should ensure it
> works robustly.
>
>
>> Thanks Steve.
>>
>> Adam Krolnik
>> Verification Mgr.
>> LSI Logic Corp.
>> Plano TX. 75074
>>
>>
>>
>>
>
> Steve Meier (stephen.meier@synopsys.com) W: 650-584-4476, Cell:
> 408-393-8246
>
>
>
This archive was generated by hypermail 2b28 : Wed Feb 19 2003 - 12:10:18 PST