Subject: Re: CP-007 and CP-008: textio for std_logic_1164
From: Jim Lewis (Jim@synthworks.com)
Date: Wed Feb 19 2003 - 23:16:01 PST
It sounds like whether the file was written in a Windows
or UNIX format, reading it in VHDL will not be a problem.
With write, it would be nice to be able to insert the
appropriate LF, CR, or CRLF depending on what the particular
OS would prefer to see. To deal with this, I would like
to define a string constant in std.textio named something like
CRLF. With this, inserting a newline in either OS would become:
write(Output, "%%%ERROR data value miscompare in CpuModel." &
CRLF & " Actual data value = " & to_hstring(Data) &
CRLF & " Expected data value = " & to_hstring(ExpData) &
CRLF & " at time: " to_string(now, right, 12) ) ;
Perhaps even have two additional constants, WCRLF (windows)
and UCRLF (UNIX) so if you simulating in windows and post
processing with UNIX utilities. This is more of a VHDL-200X
issue that we will need to address following next weeks
meeting.
Cheers,
Jim Lewis
Peter Ashenden wrote:
> On Thu, 2003-02-20 at 10:13, Rob Anderson wrote:
>
>
>>I agree with this implementation, "warning". THen "error" if we hit
>>the end of line; probable we also want to skip whitespace
>>as a matter of course, but not the EOL.
>
>
> Recall that we're reading from a string, not an input stream. So the
> end of the line is defined by there being no more characters in the
> string, not by coming across any particular character such as CR.
>
> The read procedures in CP-007 do skip whitespace. To be consistent with
> std.textio, whitespace is defined to be a sequence of space,
> non-breaking space and horizontal tab characters. Other characters,
> such as LF, CR, FF and VT, are not considered whitespace.
>
>
>
>>Other issues:
>>
>>Do we extend hex to include X,Z, etc? And, do we want to
>>select the case of hex digits (E.G. f vs F). perhaps a permissive
>>reader and case-controlled writer would be best.
>
>
> The oread and hread procedures in CP-007 allow reading X and Z, yielding
> a sequence of 'X' and 'Z' elements respectively. The procedures also
> accept lowercase and uppercase variations of hex digits A through F.
>
> The owrite and hwrite procedures will write Z for a sequence of all Z
> elements corresponding to an octal or hex digit.
>
>
>
>>Also, does a line end in <lf> or <cr> <lf> ? Perhaps there could
>>be a control for that as there is in some editors. It is annoying to
>>run a tool under cygwin then have to "d2u" the file. Possibly this
>>would be a VASG ISSUE.
>
>
> As I mentioned above, a line is just a string. How the characters got
> there from an input stream is not strictly relevant. For example, in my
> test suite for std_logic_textio, I wrote:
>
> L := new string'(" 01HL01");
> test_ieee.std_logic_textio.read ( L, value_std_ulogic_vector_12 );
>
> Usually, however, you'd get a string into the variable using the
> READLINE procedure. In that case, the answer to your question is given
> by the 1076 LRM in clause 14.3:
>
> Procedure READLINE causes the next line to be read from the file and
> returns as the value of parameter L an access value that designates an
> object representing that line. ... The representation of the line does
> not contain the representation of the end of the line. ...
>
> The language does not define the representation of the end of a line.
> An implementation must allow all possible values of types CHARACTER
> and STRING to be written to a file. However, as an implementation is
> permitted to use certain values of types CHARACTER and STRING as line
> delimiters, it might not be possible to read these values from a TEXT
> file.
>
> Presumably, if a file was written using CR/LF as line delimiters and
> read on a system that assumed just LF as the line delimiter, the CR
> would be read into the string variable. If you're reading values of any
> type other than character or string, encountering CR would not cause any
> additional problems over encountering the end of the line. It's only a
> pain if you're reading character or string values, since then the CR is
> read into the character or string variable. So you're right: if it is
> an issue, it is a VASG issue.
>
>
>
>>>write(Output, to_string(now, right, 12) & " " & to_hstring(A_slv)) ;
>>>
>>>This to me would work quite well in lieu of printf.
>>>Perhaps in a VHDL sense, it is easier than printf.
>>
>>
>>I prefer this over printf. It is easy to control formatting in VHDL
>>with this approach. It allows you to control the exact position of
>>every character, something we have to do for finnicky file readers.
>>I would not use printf, it is too obscure, there are non-compatible
>>implementations all over the place.
>
>
> Agreed. Let's see what the outcome of discussion is in VASG next week,
> and make sure we coordinate.
>
> Cheers,
>
> PA
>
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Wed Feb 19 2003 - 23:22:23 PST