From: by way of Tom Fitzpatrick (sharp@cadence.com)
Date: Mon Oct 26 1998 - 13:45:31 PST
BAD MSG:
Hi Adam,
-Lines: 101
Content-Type: text/plain; charset="us-ascii"
Content-Length: 3518
X-Status: $$$$
X-UID: 0000000684
Status: RO
I've forwarded this note to you from a member of our R&D team. Feel free to
include him (sharp@cadence.com) on your reply.
> You wrote, "We don't believe it's a good idea to have different rules for
> $swrite
> and $fwrite."
>
> reg [32*8:1] string;
> initial begin
> string = "Hello Tom, this is a test";
> $display(string);
> end
>
> Tom, what does this produce? How do you get what is really needed?
You can get what he presumably wants with
$display("%s", string);
And following the same pattern, you can use
$fwrite(file, "%s", string);
$swrite(reg, "%s", string);
But his next example uses %s, so why is he asking this question?
> You said, "We're also not entirely sold on the notion that users will
> actually use a
> string variable to specify a format string. Can you give an example of
> where this functionality would be used?"
>
> Here is the example I want to work and why one should have $swrite.
>
> task report_error;
> input [256*8:1] message;
> begin
> $display("ERROR %0d: %0s", $stime);
> <more stuff>
> end
> endtask
>
> begin
> ...
> $swrite(string, err_msg[`THIS_ERR], address, exp_data, receive_data);
> report_error(string);
> ...
> end
>
> In this example, 'err_msg' is an array that holds the error messages (with
> format specifiers.) I want to use this "format string" to create an
> error message that I pass to a task. I can't do this with $display or any
> other system task.
This is convenient, but not necessary. All of the format strings have to use
the same pattern of format specifiers because they are printing the same
arguments. You can split out the format specifiers and make them string
literals. Here is an example of how it could be done in the worst case of
format specifiers completely embedded in the string:
$swrite (string, "%s %x", err_msg1[`THIS_ERR], address,
"%s %x", err_msg2[`THIS_ERR], exp_data,
"%s %x", err_msg3[`THIS_ERR], recieve_data,
"%s", err_msg4[`THIS_ERR]);
This is inconvenient, but convenience in an unusual situation is much less
important than consistency with the rest of the language in more common
situations.
> The definition of the second parameter as intepreted
> as a string gets over the $display() problem I exhitibed above.
There is no $display problem that he has exhibited.
> The existance
> of $swrite() is simply because the functionality of $display is rather large
> to ask users to rewrite it if the want $swrite functionality.
And yet he is asking us to rewrite that same large functionality by changing
the definition of it from string literal formats to variable ones.
> We already have $fscanf and $swrite is the opposite of this.
No, $fprintf would be the opposite of $fscanf, and that doesn't exist here.
Anybody using $fscanf is going to have to look it up to see how it works, or
will expect it to work something like the C function of that name. There is
no other comparable Verilog task. However, anybody using $swrite will expect
it to work like $fwrite.
> If we want to support your example, then one needs to have the second
argument
> always intepreted as a string (still) and 3 more system tasks: $swriteb,
> $swriteo,
> $swriteh to switch the implicit default. I really don't like the shorthand
> syntax (implicit format specification) for $swrite().
I really don't like it for $display, $monitor, $fwrite, etc. but that is the
way Verilog does it and therefore any extensions should follow the pattern
that
has been set.
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:00 PDT
and
sponsored by Boyd Technology, Inc.