FPGA Central

Hi all,

A common syntax I use with $display is the following:

$display("%t INFO: ", $time,
"A write to address 0x%h ", address,
"of data 0x%h occurred." data);

However, if instead of sending it to the display, I want to write it to
a string reg variable, the following (very similar) construct does NOT work
(using NCVerilog 5.1):

reg [320*8:1] TmpStr;
...
$sformat(TmpStr, "%t INFO: ", $time,
"A write to address 0x%h ", address,
"of data 0x%h occurred." data);

I get a run-time error message saying too many arguments for the format
specifiers. Recoding it like this:

$sformat(TmpStr, "%t INFO: A write to address 0x%h of data 0x%h occurred."
$time, address, data);

works -- but I really don't like this style since many times I have long
and descriptive info, error or warning message and I like keeping my lines
to 80 characters or less (even if I didn't care about line width -- the
format specification supported by $display is much more user-friendly).

So is $sformat specified in the LRM like this -- or is this a restriction of
the Cadence simulator? If the behavior is correct according to the LRM --
what bozo didn't keep the same syntax rules for $sformat as $display? I
suppose I <could> write my own PLI routine that did the right thing -- but
never having done that -- it seems like it would be a lot more pain than I'm
willing to go through.

Thanks,
Russell

Hi,
As LRM says, $sformat syntax is:

$sformat(output_reg, format_string, list_of_arguments);

So all your formatting has to appear as second arguemnt.

Interestingly, I don't find the exact synatx for $display in LRM -
doesn any know where to find it? Obviously it is relaxed and works
fine as shown in this post.

One possible suggestion would be to use concatenation operator: {} in
Verilog. But perhaps it works best with string data type - added in SV
(Does NC support string data type?)

Thanks,
Aji,
http://www.noveldv.com

"Russell Fredrickson" <[email protected]> wrote in message news:<ci7vvp$638$[email protected]>...
> Hi all,
>
> A common syntax I use with $display is the following:
>
> $display("%t INFO: ", $time,
> "A write to address 0x%h ", address,
> "of data 0x%h occurred." data);
>
> However, if instead of sending it to the display, I want to write it to
> a string reg variable, the following (very similar) construct does NOT work
> (using NCVerilog 5.1):
>
> reg [320*8:1] TmpStr;
> ...
> $sformat(TmpStr, "%t INFO: ", $time,
> "A write to address 0x%h ", address,
> "of data 0x%h occurred." data);
>
> I get a run-time error message saying too many arguments for the format
> specifiers. Recoding it like this:
>
> $sformat(TmpStr, "%t INFO: A write to address 0x%h of data 0x%h occurred."
> $time, address, data);
>
> works -- but I really don't like this style since many times I have long
> and descriptive info, error or warning message and I like keeping my lines
> to 80 characters or less (even if I didn't care about line width -- the
> format specification supported by $display is much more user-friendly).
>
> So is $sformat specified in the LRM like this -- or is this a restriction of
> the Cadence simulator? If the behavior is correct according to the LRM --
> what bozo didn't keep the same syntax rules for $sformat as $display? I
> suppose I <could> write my own PLI routine that did the right thing -- but
> never having done that -- it seems like it would be a lot more pain than I'm
> willing to go through.
>
> Thanks,
> Russell

"Russell Fredrickson" <[email protected]> wrote in message news:<ci7vvp$638$[email protected]>...
>
> So is $sformat specified in the LRM like this -- or is this a restriction of
> the Cadence simulator? If the behavior is correct according to the LRM --
> what bozo didn't keep the same syntax rules for $sformat as $display? I
> suppose I <could> write my own PLI routine that did the right thing -- but
> never having done that -- it seems like it would be a lot more pain than I'm
> willing to go through.

Yes, $sformat is specified in the LRM like that. Only one of the arguments
is treated as a format string.

What you want to use is not $sformat, but $swrite. This works the same
way as $write (which is the same as $display except without the carriage
return at the end). It allows for multiple format strings mixed with the
arguments, just like $display.

The reason that $sformat was added also is that it allows the format string
to be supplied in a variable, rather than just a string literal. Since you
can't tell whether a variable should be interpreted as a format string or a
value to be printed, one specific argument is always treated as a format
string and the others are not. Personally, I think the reasons for adding
the $sformat task were dubious.

Just just made my day! Thanks for the reply!

"Steven Sharp" <[email protected]> wrote in message
news:[email protected] m...
> "Russell Fredrickson" <[email protected]> wrote in message
news:<ci7vvp$638$[email protected]>...
> >
> > So is $sformat specified in the LRM like this -- or is this a
restriction of
> > the Cadence simulator? If the behavior is correct according to the
LRM --
> > what bozo didn't keep the same syntax rules for $sformat as $display? I
> > suppose I <could> write my own PLI routine that did the right thing --
but
> > never having done that -- it seems like it would be a lot more pain than
I'm
> > willing to go through.
>
> Yes, $sformat is specified in the LRM like that. Only one of the
arguments
> is treated as a format string.
>
> What you want to use is not $sformat, but $swrite. This works the same
> way as $write (which is the same as $display except without the carriage
> return at the end). It allows for multiple format strings mixed with the
> arguments, just like $display.
>
> The reason that $sformat was added also is that it allows the format
string
> to be supplied in a variable, rather than just a string literal. Since
you
> can't tell whether a variable should be interpreted as a format string or
a
> value to be printed, one specific argument is always treated as a format
> string and the others are not. Personally, I think the reasons for adding
> the $sformat task were dubious.

Well -- actually didn't quite make my day as much as I would've liked.
$swrite doesn't seem to be implemented 100% correctly in NCVerilog. I've
filed a service request with Cadence to get it fixed.

Russell

"Russell Fredrickson" <[email protected]> wrote in message
news:cjf8hp$3um$[email protected]..
> Just just made my day! Thanks for the reply!
>
> "Steven Sharp" <[email protected]> wrote in message
> news:[email protected] m...
> > "Russell Fredrickson" <[email protected]> wrote in message
> news:<ci7vvp$638$[email protected]>...
> > >
> > > So is $sformat specified in the LRM like this -- or is this a
> restriction of
> > > the Cadence simulator? If the behavior is correct according to the
> LRM --
> > > what bozo didn't keep the same syntax rules for $sformat as $display?
I
> > > suppose I <could> write my own PLI routine that did the right thing --
> but
> > > never having done that -- it seems like it would be a lot more pain
than
> I'm
> > > willing to go through.
> >
> > Yes, $sformat is specified in the LRM like that. Only one of the
> arguments
> > is treated as a format string.
> >
> > What you want to use is not $sformat, but $swrite. This works the same
> > way as $write (which is the same as $display except without the carriage
> > return at the end). It allows for multiple format strings mixed with
the
> > arguments, just like $display.
> >
> > The reason that $sformat was added also is that it allows the format
> string
> > to be supplied in a variable, rather than just a string literal. Since
> you
> > can't tell whether a variable should be interpreted as a format string
or
> a
> > value to be printed, one specific argument is always treated as a format
> > string and the others are not. Personally, I think the reasons for
adding
> > the $sformat task were dubious.
>
>

"Russell Fredrickson" <[email protected]> wrote in message news:<cjfh71$4ek$[email protected]>...
> Well -- actually didn't quite make my day as much as I would've liked.
> $swrite doesn't seem to be implemented 100% correctly in NCVerilog. I've
> filed a service request with Cadence to get it fixed.

And now I've been contacted about it :-)

Your testcase should work. We will take care of the problem.