Return value for $fscanf on EOF.

[John]

Reading the Verilog-2001 spec, I see that the $fscanf system call
returns the number of successfully matched and assigned input items.

Quote from text on p.293 of Verilog-2001 spec:
The number of successfully matched and assigned input items is
returned in "code"; this number can be 0 in the event of an early
matching failure between an input character and the control string. If
the input ends before the first matching failure or conversion, EOF is
returned.

However, I see different behavior in multiple simulators at the point
where end-of-file is reached when reading the exact same input file.

Specifically:
- Popular simulator-A returns "0" when end-of-file is reached since
there have been zero matches with the pattern in the system call.
- Unpopular simulator-B returns "-1" when end-of-file is reached since
that's the verilog representation for EOF.

Since the file ends immediately after the last correctly formatted
data set, I expected the behavior to be an EOF. Simulator-A caused my
simulation to run forever.

This is just a friendly warning to watch-out for EOF when using
$fscanf.

- John.

 

[Steven Sharp]

neophyte@mailinator.com (John) wrote in message news:<bd1d4deb.0311111852.5b4d40c2@posting.google.com>...

Quote from text on p.293 of Verilog-2001 spec:
If the input ends before the first matching failure or conversion,
EOF is returned.
....
Since the file ends immediately after the last correctly formatted
data set, I expected the behavior to be an EOF. Simulator-A caused my
simulation to run forever.

Have you reported this bug to the vendor of Simulator-A?

(I have already checked that our simulator handles this currectly,
so it must not be simulator-A.)

 

[John]

sharp@cadence.com (Steven Sharp) wrote in message news:<3a8e124e.0311121202.58fdb147@posting.google.com>...

Have you reported this bug to the vendor of Simulator-A?

(I have already checked that our simulator handles this currectly,
so it must not be simulator-A.)

Hi Steven,
since you've tested it - I can confirm that simulator-A is not from
Cadence, nor was my simulator-B either - I consider Cadence to be a
"popular" tool vendor.

I'm only now in a position to report the bug to the vendor. This
particular vendor requires a testcase to be posted along with the bug
report and it took a little time to create a generic testcase that I
could give away.

Thanks for taking the time to respond to this group,
- John.

 

[Steven Sharp]

One reason I posted was in case it actually was a problem in our simulator,
in which case I wanted to know about it.

The other reason was to let you know that there was a "popular" simulator
that agreed with your interpretation of the correct behavior. That might
be helpful support for your bug report.