RE: [sv-champions] RE: [sv-ac] Errata in section 17, checker

From: Stuart Sutherland <stuart@sutherland-hdl.com>
Date: Fri May 11 2012 - 11:23:33 PDT

Ben,

 

My definition of editorial correction is a little more strict: Editorial
corrections are primarily limited to fixing font, spelling, and punctuation
errors, and simple grammatical corrections. Changes to wording, or
adding/deleting text are beyond simple editorial fixes.

 

Of the corrections you have requested, I would classify changing always to
always_ff and adding the vector size to "bus" as editorial, and will make
those correction in the re-ballot draft. The remaining requested changes,
no matter how obvious, will need to be filed as a Mantis item for committee
consideration in a future version of the standard.

 

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland

Sutherland HDL, Inc.

stuart@sutherland-hdl.com

503-692-0898
www.sutherland-hdl.com

 

From: owner-sv-champions@eda.org [mailto:owner-sv-champions@eda.org] On
Behalf Of Rich, Dave
Sent: Thursday, May 10, 2012 11:24 PM
To: hdlcohen@gmail.com
Cc: sv-ac@eda-stds.org; Korchemny, Dmitry; stuart@sutherland-hdl.com;
Bresticker, Shalom; sv-xc@eda.org
Subject: [sv-champions] RE: [sv-ac] Errata in section 17, checker

 

Ben,

 

I am about to send out an e-mail describing how the IEEE ballot review
process works. Regardless of how trivial, we are only allowed to vote on
comments made during the ballot process, which is now closed. The only way
to get a change like this in the ballot process is if this text touches one
of the existing comments, or you can convince the editor that is only an
editorial change.

 

Dave

Mentor Graphics

 

From: Ben Cohen [mailto:hdlcohen@gmail.com]
Sent: Thursday, May 10, 2012 11:15 PM
To: Rich, Dave
Cc: sv-ac@eda-stds.org; Korchemny, Dmitry; stuart@sutherland-hdl.com;
Bresticker, Shalom; sv-xc@eda.org
Subject: Re: [sv-ac] Errata in section 17, checker

 

I filed http://www.eda-stds.org/svdb/view.php?id=4154

Dave, those changes are not that severe; they could easily be approved by an
sv-ac phone meeting, and can be handled in less than 15minutes. I don't
know if we can get that approved.

Ben

On Thu, May 10, 2012 at 11:05 PM, Rich, Dave <Dave_Rich@mentor.com> wrote:

Ben,

 

These may be minor issues, but in my opinion, are beyond what are considered
"editorial" changes. I delineate an editorial change to be one that could be
made by someone with no knowledge of the standard and yet they would be
reasonably confident that the change would have no impact on the meaning of
the text.

 

Please file a mantis issue and we can deal with this in the next revision of
the standard.

 

Dave

Mentor Graphics

 

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Ben
Cohen
Sent: Thursday, May 10, 2012 2:54 PM
To: sv-ac@eda-stds.org; Korchemny, Dmitry; stuart@sutherland-hdl.com;
Bresticker, Shalom
Subject: [sv-ac] Errata in section 17, checker

 

Here is a list of needed fixed. Did not file a mantis. Will do one if
needed.

Those are minor, and may be handled by Stuart directly.

17.3 Checker instantiation

...

module m(wire bus, logic clk);

...

On each rising edge of clk the bits of bus are checked for mutual exclusion

[Ben] bus is defined as a single bit, thus to states that "the bits of bus"
is incorrect.

Change needed:

module m(wire[31:0] bus, logic clk);

-------------------------

17.4 Context inference

checker check_in_context (logic test_sig,

       event clock = $inferred_clock,

       logic reset = $inferred_disable);

...

module m(logic rst);

  wire clk;

  logic a, en;

  wire b = a && en;

  // No context inference

   check_in_context my_check1(.test_sig(b), .clock(clk), .reset(rst));

[Ben] I think that the intent here was for the clocking event to be posedge
clk and not clk

Change needed

check_in_context my_check1(.test_sig(b), .clock(posedge clk), .reset(rst));

---------------------

17.5 Checker procedures

checker clocking_example (logic sig1, sig2, default_clk, rst,

        event e1, e2, e3 );

   ..

    always @(e1) begin: p1_block

  ..

    always @(e2 or e3) begin: p2_block

    ...

    always @(rst or e3) begin: p3_block

   ..

  [Ben] The "always" is illegal in a checker. We need the always_ff

Change to

always_ff @(e1) begin: p1_block

always_ff @(e2 or e3) begin: p2_block

always_ff @(rst or e3) begin: p3_block

 

-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 
 
-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, 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 May 11 11:24:17 2012

This archive was generated by hypermail 2.1.8 : Fri May 11 2012 - 11:24:41 PDT