ISSUE 93

Number 93
Category errata
Synopsis 17.10.2: errors in the example
State lrmdraft
Class errata-discuss
Arrival-DateAug 12 2002
Originator Charles Dawson
Release 2001b: 17.10.2
Environment
See thread beginning at
http://boydtechinc.com/etf/archive/etf_2002/0743.html
Description
The example has several problems:

1. The 5th line

reg 8*32:1 testname;

should read:

reg [8 * 32 : 1] testname;

2. The 31st line

pstring = "+TEST%d";

should read:

pstring = "TEST%d";

3. The 32nd line

if ($value$plusargs(pstring, test[31:0))

should read:

if ($value$plusargs(pstring, test[31:0]))

Please note that even with these changes, this example will
not compile. It needs additional begin/end a module
statement, ...etc. I have a now working example that I
could ship to you.

Fix
Replace the entire example, including the command line args
and expected output with the following:

Examples:

Given the following Verilog HDL:


`define STRING reg [1024 * 8:1]

module goodtasks;
  `STRING str;
  integer int;
  reg [31:0] vect;
  real realvar;

  initial
    begin
      if ($value$plusargs("TEST=%d",int))
        $display("value was %d",int);
      else
        $display("+TEST= not found");
      #100 $finish;
    end

endmodule

module ieee1364_example;
  real frequency;
  reg [8*32:1] testname;
  reg [64*8:1] pstring;
  reg clk;

  initial
    begin
      if ($value$plusargs("TESTNAME=%s",testname))
        begin
          $display(" TESTNAME= %s.",testname);
          $finish;
        end

      if (!($value$plusargs("FREQ+%0F",frequency)))
        frequency = 8.33333; // 166 MHz
      $display("frequency = %f",frequency);

      pstring = "TEST%d";
      if ($value$plusargs(pstring, testname))
        $display("Running test number %0d.",testname);
    end

endmodule


Adding the following plusarg to the tool's command line:

+TEST=5 


will result in the following output:

value was           5
frequency = 8.333330
Running text number x.


Adding the following plusarg to the tool's command line:

+TESTNAME=bar


will result in the following output:

+TEST= not found
 TESTNAME=                              bar.


Adding the following plusarg to the tool's command line:

+FREQ+9.234


will result in the following output:

+TEST= not found
frequency = 9.234000


Adding the following plusarg to the tool's command line:

+TEST23


will result in the following output:

+TEST= not found
frequency = 8.333330
Running test number 23.


(Note: my earlier comments that "frequency = 8.333330" and
"Running text number x." should also be printed in the
second case as well, were incorrect.)

Audit-Trail

From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/93: PROPOSAL - Section 17.10.2 errors in the example
Date: Tue, 31 Dec 2002 15:57:45 +0200

This is to enter into the database the correspondence which followed the
proposal:

Date: Mon, 16 Dec 2002 13:20:35 -0800
From: Gordon Vreugdenhil<gvreugde@synopsys.com>

I disagree with the expected output.

The matching rules at the beginning of the LRM talk about the
return value being non-zero if the "string" is found -- it says
nothing about a zero value if the string is found and there
is a conversion error.

The provided output makes that assumption.

The example run with "+TEST=5" should produce:

value was 5
frequency = 8.333330
Running test number x.

since the string "TEST" is found and it is only
the conversion that fails.

If we want to differentiate between a string search
failure and a conversion failure, we should specify
additional status codes.


Date: Mon, 16 Dec 2002 16:47:23 -0500
From: Charles Dawson<chas@cadence.com>

A good point that I did not think of. The LRM does not specify
what should be returned if a conversion fails. Currently
NC-Verilog produces an error in this case and returns 0 from
the system function. This may not be correct because the last
sentence in the first paragraph of section 17.10.2 says:

No warnings shall be generated when the function returns
zero (0).

Obviously, whoever wrote this section did not consider the
possibility that a conversion would fail. The best solution
would be to specify another non-zero return code for a
conversion failure. That would however, require that people
use the system function in conjunction with a case statement.


Date: Mon, 16 Dec 2002 13:58:26 -0800
From: Gordon Vreugdenhil<gvreugde@synopsys.com>

The best solution would be to invert the condition code --
0 means "all is well", 1 means "no such string", 2 means
"conversion failed". Unfortunately such a change would
invalidate all existing uses of $value$plusargs.

Yet another choice is to invent something like:
$value$plusargscode (or a better name)
that does the above and then define $value$plusargs in
terms of this function so that $value$plusargs has the
same behavior and the new one has the right behavior.

I don't like that choice since it allows bad definitions
to continue; we should probably pay the price now in terms
of incompatibilities and get it right.

If so, as an implementor, I'd like this decided on asap so that
such changes can be widely announced by the vendors immediately.


From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/93: PROPOSAL - Section 17.10.2 errors in the example
Date: Mon, 06 Jan 2003 14:23:31 +0200

> A good point that I did not think of. The LRM does not specify
> what should be returned if a conversion fails.
>
> Obviously, whoever wrote this section did not consider the
> possibility that a conversion would fail.

I think the LRM is quite clear that the function returns 0 if there is no
string match, and non-zero if there is a string match.

The case of an illegal conversion is dealt with explicitly at the end of
para. 4, and says,
"If characters exist in the string available for conversion,
which are illegal for the specified conversion,
the variable shall be written with the value 'bx."

> The best solution would be to invert the condition code --
> 0 means "all is well", 1 means "no such string", 2 means
> "conversion failed".

That would be incompatible with $test$plusargs,
which has existed for years.

I suggest not to change the currently defined behavior.

Comments on the suggested version of the example:

1. `define STRING [1024*8:0]

should be

`define STRING [1024*8:1]


2. module ieee1354_example;

should be

module ieee1364_example ;


3. The line "frequency = 8.333330" should be printed in the second case as
well.


4. The line "Running test number x." should be printed in the second case
as well.

Shalom

--
Shalom Bresticker Shalom.Bresticker@motorola.com
Design & Reuse Methodology Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478

"The devil is in the details."



Unformatted


Hosted by Boyd Technology