RE: issues in LRM sections 9.5.3, 9.5.4, and 9.5.5

From: Bresticker, Shalom <shalom.bresticker@intel.com>
Date: Wed Mar 23 2011 - 08:46:06 PDT

$fgetc is not described in the VAMS LRM as well as $fungetc.

This is the description from 1800-2009:

"21.3.4.1 Reading a character at a time

A single character can be read from a file using $fgetc. For example:

Example 1:
integer c;
c = $fgetc ( fd );

reads a byte from the file specified by fd. If an error occurs reading from the file, then c is set to EOF (-1).
The code defines the width of variable c to be wider than 8 bits so that a return value from $fgetc of EOF (-1) can be differentiated from the character code 0xFF. Applications can call $ferror to determine the cause of the most recent error (see 21.3.7).

Example 2:
integer code;
code = $ungetc ( c, fd );

inserts the character specified by c into the buffer specified by file descriptor fd. The character c shall be returned by the next $fgetc call on that file descriptor. The file itself is unchanged. If an error occurs pushing a character onto a file descriptor, then code is set to EOF. Otherwise, code is set to zero. Applications can call $ferror to determine the cause of the most recent error (see 21.3.7).

NOTE-The features of the underlying implementation of file I/O on the host system limit the number of characters that
can be pushed back onto a stream. Operations like $fseek might erase any pushed back characters."

Regards,
Shalom

> -----Original Message-----
> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
> Behalf Of Marq Kole
> Sent: Wednesday, March 23, 2011 3:20 PM
> To: Verilog-AMS LRM Committee
> Subject: RE: issues in LRM sections 9.5.3, 9.5.4, and 9.5.5
>
> Hi Geoffrey,
>
> In that respect there is no difference between $fgets which is
> supported in the analog context (9.5.4.1) and $fgetc. They only differ
> in the amount of characters they collect. In both cases the states
> should be completely controllable during iteration. When an iteration
> is not accepted, all variables and file positions should be reset to
> the value they had at the last accepted time-point. That can be done
> for both a single character read ($fgetc) or multiple characters read
> ($fgets).
>
> Cheers,
> Marq
>
>
> -----Original Message-----
> From: Geoffrey.Coram [mailto:geoffrey.coram@analog.com]
> Sent: Wednesday, March 23, 2011 2:14 PM
> To: Marq Kole
> Subject: Re: issues in LRM sections 9.5.3, 9.5.4, and 9.5.5
>
> Might there be a problem with $fgetc and $ungetc when the analog block
> is called for multiple iterations at a timepoint?
>
>
> Marq Kole wrote:
> > Hi All,
> >
> >
> >
> > Upon reading the contents of the sections 9.5.3, 9.5.4, and 9.5.5 in
> the
> > 2.3.1 LRM I've found a few items where I think we can improve:
> >
> >
> >
> > 9.5.3: In the second paragraph, just below the syntax box twice the
> > phrase "family of tasks" is used. To me this implies that there are
> more
> > system tasks like $swrite, but they are not mentioned here. A
> reference
> > is made to the $fwrite family of tasks but in the section 9.5.2 they
> are
> > not mentioned - $fwrite appears in company of $fdisplay, $fstrobe,
> > $smonitor, and $fdebug. Instead, the $fwrite family of tasks refers
> to
> > the $fwrite, $fwriteb, $fwriteh, and $fwriteo tasks. To prevent
> > confusion the phrase "family of tasks" should be replaced by "task"
> and
> > the sentence should be adjusted to match the singular form.
> >
> >
> >
> > 9.5.4: In subsection 9.5.4.2 at the bottom of page 206, a descriptor
> is
> > mentioned with the character c. In the list at the top of the next
> page
> > (207), this character is not mentioned at all. This is a significant
> > omission as it is not clear whether the receiving variable for such a
> > descriptor should be a string variable, an integer variable or any of
> > the two.
> >
> >
> >
> > 9.5.5: Twice a reference is made to $ungetc while this system task is
> > not mentioned anywhere else in the LRM except in the overview table
> 9-2
> > on page 194. I would also like to know why there is a restriction for
> > using the $fgetc function and $ungetc task from the analog context.
> This
> > seems rather arbitrary to me, and limits the ability to read textual
> > data from file for detailed processing. I would suggest to support
> > $ungetc and $fgetc in the analog context as well. Otherwise, a
> reference
> > to $ungetc in the 1364-2005 or 1800-2009 standard might be relevant.
> >
> >
> >
> > Cheers,
> >
> > Marq
> >
> >
> >
> >
> >
> > *Marq Kole*
> >
> > Product Manager AMSRF Simulation
> >
> > NXP Semiconductors / Central R&D / Foundation Technology
> >
> >
> >
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by *MailScanner* <http://www.mailscanner.info/>,
> and is
> > believed to be clean.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Wed Mar 23 08:47:25 2011

This archive was generated by hypermail 2.1.8 : Wed Mar 23 2011 - 08:47:28 PDT