Number | 93
|
Category | errata
|
Synopsis | 17.10.2: errors in the example
|
State | lrmdraft
|
Class | errata-discuss
|
Arrival-Date | Aug 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