Mirek, I brought up the same issues at the informal meeting that Dmitry had a few weeks ago. We need to separate the individual features included with the mantis 1900 proposal from the checkers now if there is going to be any hope of doing it in the future. There are so many restrictions like "Unlike modules, interfaces, and programs, checker ports may not be connected to interfaces." or "It shall be an error to specify an initial_check procedure outside a checker body." without explaining why the restrictions exists (i.e. is it because we're not ready to deal with it, or is there some fundamental reason behind it.) When there are so many of these restrictions, it becomes very difficult for the people who come after us to figure out the intent I think there have been some mistaken assumptions made as to what are the syntheses semantics of SV. For example, a sensitivity list is simply a list of event controls and nothing else. No synthesis semantics have ever been defined to infer the meaning of sensitivity lists (not in P1800 at least). always_comb and always_latch create sensitivity lists, and apply restrictions on what can be included within those constructs, but in no case do they alter the semantics of what is included within those constructs. The always_check and initial_check constructs are attempting to alter the implied semantics of event control included within the constructs. A better solution would be to add to the event control semantics. Dave ________________________________ From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On Behalf Of Mirek Forczek Sent: Tuesday, April 08, 2008 2:11 AM To: 'Korchemny, Dmitry'; sv-ec@server.eda.org Cc: sv-ac@server.eda.org Subject: RE: [sv-ec] 1900 mantis (checkers): some new keywords could be avoided Hi Dimitry, 1) I understand the motivation for the checkvar syntax now. Thanks for the explanation. 2) So the initial_check and always_check were introduced mainly because of not satisfactory clock inferrence semantics of the ordinary inital and always. From this point of view: use of initial_check or always_check in other design units (i.e. module) - will it be legal ? (it seems to be useful to have a better clock inferrence semantics available in other units too) Another issue is: does the existing clock infference semantics meet users expactations ? are the inferrence rules of the 'always' intuitive ? @(posedge clk) is interred, @clk is not inferred, if this is not what users expect, the construct (clock inferrence from 'always') may become just a dead one (nobody will use it ?) in a language and we will loose a usefull syntax only ... (?) Also: the 1800-2005 says only: "A clock is inferred if the statement is placed in an always or initial block with an event control abiding by the following rules: - The clock to be inferred must be placed as the first term of the event control as an edge specifier (posedge expression or negedge expression)." there is no strong statement in 1800-2005 saying: "clock is not inferred if there is no edge specifier" ... from this point of view: adding the @clk to the sufficient conditions set for clock inferrence for 'always' still can be seen a rule upgrade/improvement, with a backward incompatibility of course, but maybe acceptable in this case ... (?) Regards, Mirek ________________________________ From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com] Sent: 7 kwietnia 2008 22:10 To: Mirek Forczek; sv-ec@server.eda.org Cc: sv-ac@eda.org Subject: RE: [sv-ec] 1900 mantis (checkers): some new keywords could be avoided Hi Mirek, The reason for introducing a new syntax is to avoid potential future backward incompatibility issues. See more detailed comments below. Thanks, Dmitry ________________________________ From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On Behalf Of Mirek Forczek Sent: Monday, April 07, 2008 1:18 PM To: sv-ec@server.eda.org Subject: [sv-ec] 1900 mantis (checkers): some new keywords could be avoided Hi, 1) In "16.18.6 Checker variables" section of the proposal there is: "Any variable declared within a checker preceded by the keyword checkvar is a checker variable [...]" "A declaration without checkvar in a checker body or a declaration of a checker variable outside it shall be illegal [...]" [Korchemny, Dmitry] This is not exact. In action blocks and in final procedures the declared variables are regular variables, and not checker variables. In future other cases may come as well. The semantics of checker variables differs more significantly from the semantics of regular variables than just an evaluation in a different region. If sometime checker variables become legal in modules they will need to have a special syntax in any case. (following the example: module with checkervar bit, checker with checkvar bit, the "module" is just an example of the design unit, the "bit" is just an example of the variable declaration): The module-bit context could imply ordinary variable semantics, the checker-bit context could imply checker variable semantics. In other words - the proper semantics would be choosen upond declaration context (automatically). The introduction of a new keyword: "checkvar" could be avoided. There would be no need to additional restrictions in LRM text as above. The example would simplify: module m; bit a; // legal: ordinary variable endmodule : m checker c; bit a; // legal: checker variable endchecker : c 2) In "16.18.5 Checker procedures" section of the proposal there is: "The following procedures are allowed inside a checker body: - initial_check procedure, and - always_check procedure" Assuming that the initial_check and always_check cannot be used outside checker, and an ordinary initial and always procedures cannot be used inside checker: the module-initial, module-always context could imply ordinary initial, always semantics the checker-initial, checker-always context could imply initial_check, always_check semantics (actually: restrictions over inital, always inside checker), The introduction of a new keywords "initial_check", "always_check" could be avoided. Such approach would be consistent with similar one taken already in program context: program is allowed to have initial and final procedures only, these procedures have changed evaluation semantics to Reactive region (i.e.), but still they are "initial" and "final", no "initial_program" nor "final_program" where introduced. [Korchemny, Dmitry] initial_check and always_check have been introduced not because of another simulation region, but because of the clock inference rules for concurrent assertions. E.g., if you write an assertion inside always @(posedge clk) ... procedure, the @(posedge clk) is inferred for the assertion, but if you write it inside always @clk ... procedure, the @clk is not inferred for the assertion. Inferring the clock in the last case is important for checkers, and either a new construct always_check with different inference rules should be introduced (as in 1900) or the existing inference rules for regular always procedures should be changed. If the inference rules for regular always procedures are changed everywhere, the new standard will become backward incompatible; if the inference rules are changed in checkers only, the inference rules become inconsistent. Regards, Mirek --------------------------------------------------------------------- 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 <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 Tue Apr 8 15:58:00 2008
This archive was generated by hypermail 2.1.8 : Tue Apr 08 2008 - 15:58:50 PDT