Re: [sv-bc] Mantis 1571: Add default values for macro arguments

Just noting that despite any other merits, this design is not
backward compatible with existing uses of macro expansion.

In  the expansion of `ABC(.arg1(arg1), ...), existing products
will use the token sequences .arg1(arg1) and this may have been
the user's intent.

In the expansion of `ABC #(.arg1(arg1),...), `ABC has no arguments
so it's expansion will be followed by #(.arg1(arg1),...).

Greg

Bresticker, Shalom wrote:
> Dave,
> 
> You may have misunderstood.
> 
> No one is creating a whole new language using macro syntax.
> 
> No one is proposing different macro functionality for different parts of 
> the language.
> 
> Some enhancements to macros are being proposed, but they are universally 
> applicable and beneficial. No one is proposing special macro syntax for 
> assertions or anything like that. One purpose of the proposed 
> enhancements is to make macro syntax and features more consistent with 
> other similar language constructs. So if anything, there is a goal to 
> increase the uniformity of the language.
> 
> It is true that macros sometimes have certain disadvantages. That is 
> true of many useful language features. For example, parameters have 
> their own debugging difficulties. Like everything else, you have to know 
> how to use them. Verilog did not invent macros and users find them useful.
> 
> Macros are extensively used in major Intel CPU projects.
> 
> It is certainly true that sometimes macros are used to work around 
> language deficiencies. There are additional enhancement requests which 
> attempt to solve some of those deficiencies.
> 
> If there are better ways to address the needs, then of course we’d be 
> glad to hear your suggestions. Dmitry has been very open about that.
> 
> Please note that the enhancement proposals did not just sprout out of 
> someone’s crazed mind. Rather, they are the result of real user needs 
> and problems on real projects. Some were found when migrating from an 
> internal Intel RTL language to SV, some others were found when migrating 
> from an internal Intel assertion language to SVA. All the enhancement 
> proposals have been presented with the motivations behind them.
> 
> I have attached a file from an OVL member (not Dmitry) showing an 
> example of use of some of the proposed enhancements.
> 
> Specifically about macro argument defaults: please note that argument 
> defaults were around in the language before pass by name, in the form of 
> parameters. It is true that there is a problem with copying the regular 
> pass by name syntax to macros. Since pass by name is so much more 
> readable (and safe), and also makes defaults easier, as you note, the 
> conclusion is that we should find a different way to do pass by name to 
> macro arguments.
> 
> I imagine that a small syntax change would allow it. For example, 
> instead of `ABC(.arg1(arg1), ...), maybe something like `ABC 
> #(.arg1(arg1),...). The need for the syntax change is unfortunate, but I 
> think the benefit justifies it. We should make it as similar to the 
> usual syntax as possible.
> 
> Regards,
> 
> Shalom
> 
> ------------------------------------------------------------------------
> 
> *From:* Rich, Dave [mailto:Dave_Rich@mentor.com]
> *Sent:* Tuesday, October 10, 2006 11:25 PM
> *To:* Bresticker, Shalom; sv-bc@server.eda.org
> *Subject:* RE: [sv-bc] Mantis 1571: Add default values for macro arguments
> 
>  
> 
> Shalom,
> 
>  
> 
> Someone forwarded me a list of enhancements that are being talked about 
> in the OVL and possibly the SV-AC committees. I don’t know if this is 
> related to your request, but it seems to me they are creating a whole 
> new language using macro syntax, and I find it horrible that someone 
> would propose different macro functionality for different parts of the 
> language.
> 
>  
> 
> My basic objection to macros is that they are very difficult to debug, 
> and they are usually there as a hack to cover up a language deficiency. 
> I’d rather spend the effort addressing the original need, and staying 
> away from the use of macros. One other point for this particular 
> enhancement is with defaults values is that it is not very readable 
> without pass by name. I think we have already shown that the pass by 
> name syntax is not backward compatible with existing Verilog code.
> 
> Dave
> 
> Attached:
> 
> *From:* Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
> *Sent:* Monday, October 09, 2006 12:18 AM
> *To:* ovl-vsva@lists.accellera.org
> *Subject:* [ovl-vsva] SVA extensions compatible with module packaging
> 
> Hi all,
> 
>  
> 
> I was asked to send a list of proposed SVA extension features that OVL 
> may benefit when OVL checkers are still packaged into 
> modules/interfaces. I would like to mention, however, that using 
> modules/interfaces for this purpose leads to the flexibility loss – no 
> context inference, no possibility to pass a property/sequence as an 
> argument. Therefore most of the proposed extensions are not relevant for 
> modules, and the list is very poor.
> 
>  
> 
> Cosmetic changes in the OVL checker invocation may be done using 
> enhancements in the compiler directives:
> 
>     * Default argument values in a macro
>     * Passing macro argument by name
>     * Repeatable macro arguments
> 
>  
> 
> E.g., the invocation of the checker assert_delta
> 
>  
> 
> assert_delta
> 
>     #(OVL_ERROR, 16, 0, 8, OVL_ASSERT,
> 
>             “Error: y values not smooth”, OVL_COVER_ALL)
> 
>     valid_smooth ( clk, reset_n, y );
> 
>  
> 
> may the look like:
> 
>  
> 
> `ASSERT_DELTA(valid_smooth, y, .width(16), .max(8), .msg(“Error: y 
> values not smooth”));
> 
>  
> 
>  
> 
> A very important feature is an ability to specify user-defined 
> compile-time messages:
> 
>  
> 
> Compare:
> 
>  
> 
> // Compile-time message when module parameter is wrong
> 
> if (num_cks < 2)
> 
>                         $error("Illegal value set for action_on_new_start");
> 
>  
> 
> instead of a run-time message as now:
> 
>  
> 
> initial begin
> 
>             if (num_cks < 2)
> 
>                         ovl_error_t("Illegal value set for 
> action_on_new_start");
> 
> end
> 
>  
> 
> A proposal concerning property modeling is also beneficial for OVL, 
> since it eliminates races which occur when RTL is used for the modeling. 
> The problem is that in my proposal the modeling code may be specified 
> inside checkers (new construct for property packaging)  only, and not 
> within modules.
> 
>  
> 
> Regards,
> 
> Dmitry
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> //----------------------------------------------------------------------------
> // CONTENTS
> // ========
> // 21.  About this file (SVA OVL assertions for arb1_* arbiter)
> // 25.    - Standard defines
> // 30. 
> // 31.  Arbiter Assertions
> // 35.    1) Never more than one grant
> // 40.    2) No requests means no grants
> // 46.    3) No unwanted grants
> // 57.    4) Max bus usage
> // 63.    5) Grant within N cycles
> // 70.         a) 121 cycles (15x8 + 1)
> // 81.         b) 136 cycles (15x9 + 1)
> // 92.    6) No hogging the bus
> //
> // This version demonstrates the improved readability/usability from
> // the proposed SV extensions:
> // - Checkers: ugly separation between # parameters and ports is removed,
> //   and only non-default values need to be specified
> // - Global default clock and reset:  these don't need to be in each assert
> // - Variable typing: eliminates need for redundantly specifying widths 
> // - This also allows single-bit asserts to operate on full vectors,
> //   instead of having  to 'generate' an array of assertions.  The
> //   reduced # of insts will probably give simulation performance
> //   benefits as well.	
> //
> // Even though only a small subset of the extensions are applied in this
> // example, I think the benefits at the user level are very clear.
> //----------------------------------------------------------------------------
> 
> 
> // INDEX: About this file (SVA OVL assertions for arb1_* arbiter)
> // =====
> 
> 
> // INDEX:   - Standard defines
> // =====
> `include "std_ovl_defines.h"
> 
> // Global clock and reset should be defined in calling RTL
> 
> // INDEX:
> // INDEX: Arbiter Assertions
> // =====
> 
> 
> // INDEX:   1) Never more than one grant
> // =====
> // OLD:  assert_zero_one_hot #(`OVL_ERROR,16,`OVL_ASSERT,"Never more than one grant") ovl_max_one_grant (clk, reset_n, grant);
> 
> ovl_max_one_grant:  assert_zero_one_hot(
> 		.msg("Never more than one grant"),.vec(grant));
> 
> 
> // INDEX:   2) No requests means no grants
> // =====
> // This should also be covered by "No unwanted grants"
> // OLD: assert_implication #(`OVL_ERROR,`OVL_ASSERT,"No requests means no grants") ovl_no_reqs_no_grants (clk, reset_n, ~|req, ~|grant);
> 
> ovl_no_reqs_no_grants:  assert_implication(
> 		.msg("No requests means no grants"), .ant(~|req),
> 	        .cons(~|grant));
> 
> 
> // INDEX:   3) No unwanted grants
> // =====
> // WAS
> // generate 
> //  genvar i;
> //  for (i=0; i<16; i++) begin: i
> //     assert_implication #(`OVL_ERROR,`OVL_ASSERT,"No unwanted grants for master") ovl_no_unwanted_grants (clk, reset_n, grant[i],  req[i]);
> //  end
> //endgenerate
> 
> ovl_no_unwanted_grants:  assert_implication(
> 		.msg("No unwanted grants for master"),
> 		.ant(grant), .cons(req)); 
> 
> 
> // INDEX:   4) Max bus usage
> // =====
> // Simple round-robin schemes will fail this
> // WAS: assert_implication #(`OVL_ERROR,`OVL_ASSERT,"Max bus usage: one grant if any requests") ovl_max_usage (clk, reset_n, |req, |grant);
> 
> ovl_max_usage:  assert_implication( 
> 		.msg("Max bus usage: one grant if any requests"),
> 		.ant(|req), .cons(|grant));
> 
> 
> // INDEX:   5) Grant within N cycles
> // =====
> // Note: sva31a version uses generate to avoid verbose listing in vlog95
> //
> // Need the 136-cycle version as the 121-cycle version will fail in a simple round robin
> 
> 
> // INDEX:        a) 121 cycles (15x8 + 1)
> // =====
> // Simple round-robin will fail this, due to servicing current master when bus quiet
> // WAS:
> //generate
> //  genvar j;
> //  for (j=0; j<16; j++) begin: j
> //     assert_frame #(`OVL_ERROR,0,121,`OVL_IGNORE_NEW_START,`OVL_ASSERT,"Grant master within 121 cycles")  ovl_grant_within_121  (clk, reset_n, req[j],  ~req[j]  | grant[j]);
> //  end
> //endgenerate
> 
> ovl_grant_within_121:  assert_frame(
> 		.msg("Grant master within 121 cycles"), .maxtime(121), 
> 	        .start_event(req), .test_expr(~req | grant));
> 
> 
> 
> // INDEX:        b) 136 cycles (15x9 + 1)
> // =====
> // Simple round-robin will pass this
> // WAS: generate
> //  genvar k;
> //  for (k=0; k<16; k++) begin: k
> //     assert_frame #(`OVL_ERROR,0,136,`OVL_IGNORE_NEW_START,`OVL_ASSERT,"Grant master within 136 cycles")  ovl_grant_within_136  (clk, reset_n, req[k],  ~req[k]  | grant[k]);
> //  end
> //endgenerate
> 
> ovl_grant_within_136:  assert_frame (
> 	      .msg("Grant master within 136 cycles"), .maxtime(136), 
> 	      .start_event(req), .test_expr(~req | grant));
> 
> 
> // INDEX:   6) No hogging the bus
> // =====
> // If there are multiple requests, the master should not hog the bus
> // and do a subsequent 8-cycle burst.
> //
> // This is different to the within-N proofs, as you might still hog the
> // bus yet guarantee a response within N cycles (e.g. after two back-to-back
> // bursts).
> //
> // Note: sva31a version uses $countones (vlog95 has a verbose expression)
> wire aux_multiple_reqs = ($countones(req) > 1);
> 
> // WAS: assert_change #(`OVL_ERROR,16,9,`OVL_IGNORE_NEW_START,`OVL_ASSERT,"Master cannot hog the bus if there are multiple requests") ovl_no_hogging
> //  (clk, reset_n, aux_multiple_reqs, ({16{~aux_multiple_reqs}} & grant));
> 
> ovl_no_hogging:  assert_change( 
> 	.msg("Master cannot hog the bus if there are multiple requests"),
> 	.maxtime(9), .start_event(aux_multiple_reqs),
> 	.vec((16{~aux_multiple_reqs}) & grant));