The Designer's Guide Community Forum

The Designer's Guide Community Forum
https://designers-guide.org/forum/YaBB.pl
Design Languages >> Verilog-AMS >> Return value of $fscanf depends on Spectre version
https://designers-guide.org/forum/YaBB.pl?num=1170422973

Message started by Daniel_Platte on Feb 2^nd, 2007, 5:29am

Title: Return value of $fscanf depends on Spectre version
Post by Daniel_Platte on Feb 2^nd, 2007, 5:29am

Hi NG!

I just experienced a strange problem with the $fscanf-statement:

The return value of the function seems to be inconsistent between different Spectre versions: While version 6.1. returns -1 for EOF and 1 otherwise (C-like?), version 5.1 returns 1 (for EOF) and 0 instead...

Was this changed intentionally or might it be a bug? How to resolve this problem and write 'version-independent' models?

Cheers,
Daniel

Title: Re: Return value of $fscanf depends on Spectre ver
Post by Geoffrey_Coram on Feb 5^th, 2007, 5:47am

The 1364-2005 Verilog Language Reference Manual says (17.2.4.3):

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. Applications can call $ferror to determine
the cause of the most recent error (see 17.2.7).

It sounds like 6.1 complies with the current LRM. I see similar wording in 1364-2001, but 1364-1995 doesn't even seem to have $fscanf. Since V-AMS is based on 1364-1995, the fact that it runs at all means some extensions were added in Spectre.

You might be able to work around this if EOF would be defined appropriately in the different versions, as long as you test for equality with "EOF" and not with "-1"

Title: Re: Return value of $fscanf depends on Spectre ver
Post by Andrew Beckett on Feb 6^th, 2007, 4:09pm

This was an intentional change. I saw this on an internal update presentation on things that were changed - the change was done to be compliant with the LRM (and it's more useful that way too!)

Regards,

Andrew.