Re: [sv-ac] Feedback request

From: Mirek Forczek <mirekf@aldec.com.pl>
Date: Fri Nov 28 2014 - 07:17:38 PST
I would like to provide some feedback:

3478: Make drivers of inout ports accessible
No opinion

5063: Automatic inference of assertion statement type
No opinion

5064: Create standard package to define constants used in 
assertion-related stuff
Nice to have

5065: Create standard package to define implementation for commonly used 
properties
Nice to have
If package will be created than I assume that the language will not be 
extended for this purpose, only an advanced property definitions will be 
written using existing language capabilities. This would be good move in 
general for the language (not increasing its volume without need).
A consequence will be that those properties will have 'function-call' 
usage syntax at best, not the 'operator' syntax (unless the language 
supports operator functions with custom names which is very rare case I 
think) - which will increase effort required while porting property 
source between SVA and PSL notations (SVA and PSL notation are different 
just at time-shift syntax so is it a concern anyway ?).
Still an alternative approach is to define new operators in language.

5067: Allow variables in delays and repeat operators
Important
(following Ben proposal)
The bounds in delays and repetitions - if defined with variables - are 
about to be sampled when the assertion instance starts and remain fixed 
for that assertion instance trace (is this correct?). I would prefer to 
see some syntax here that emphasis that fact - in example let's re-use 
const'() syntax:
module forsv_ac;
bit a, b, c, clk;
int v;
// ...
ap_delay: assert property(@(posedge clk) a |=> ##const'(v) b);
ap_range: assert property(@(posedge clk) a |=> ##[0:const'(v)] ##1 b);
ap_repeat: assert property(@(posedge clk) a |=> b*[const'(v)] ##1 c);
ap_repeat_range: assert property(@(posedge clk) a |=> b*[0:const'(v)] 
##1 c);
ap_goto: assert property(@(posedge clk) a |=> b[-> const'(v)] ##1 c);
endmodule // forsv_ac

This would also simplify semantics concept here: the delays and 
repetitions still would be considered as "constant" (their bounds are 
constant) within assertion's instance,
only the bounds can be fixed late in run-time at assertion instance start.

5068: concurrent assertions in classes
Important

As additional enhancements I would like to suggest:

5070: support sequence/property open arguments
5071: support assertion match instance reflection API

Best regards,
Mirek

On 2014-11-21 12:47, Korchemny, Dmitry wrote:
>
> Hi,
>
> You are requested to send your feedback on working on the following 
> Mantis items in the next P1800 PAR by 1-Dec-2014, UTC:
>
> ·3478: Make drivers of inout ports accessible
>
> ·5063: Automatic inference of assertion statement type
>
> ·5064: Create standard package to define constants used in 
> assertion-related stuff
>
> ·5065: Create standard package to define implementation for commonly 
> used properties
>
> ·5067: Allow variables in delays and repeat operators
>
> ·5068: concurrent assertions in classes
>
> Your feedback should include one of the following marks for each item:
>
> ·Important
>
> ·Nice to have
>
> ·Not important
>
> ·No opinion
>
> along with any free text comments.
>
> You may also suggest additional enhancements not listed above, but 
> they need to be filed as Mantis items first.
>
> There is no need to discuss any errata or clarification items.
>
> Thanks,
>
> Dmitry
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, 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 Fri Nov 28 07:15:02 2014

This archive was generated by hypermail 2.1.8 : Fri Nov 28 2014 - 07:15:24 PST