Date: Thu Oct 19 2006 - 02:30:01 PDT
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
- text/plain attachment: Arbiter_using_Dmitrys_SV_extensions.2006-07-07.txt