On Jan 9, 2012, at 1:45 AM, Walter F.J. Mueller wrote:
> On 01/08/2012 12:06 AM, David Koontz wrote:
>> While technically challenging, a rather dry subject.
> > ....
>
> Hello David,
>
> many thanks for the extensive analysis !!!
I combined a reply to your two messages because they are completely related.
> the sdf 3.0 specification states
>
> Comments can be placed in SDF files using either “C” or “C++” styles.
>
> and ghdl indeed accepts
> // C++ style comments
> but does not recognize
> /* "C" style comments */
>
> So to comment out prepending with // works with ghdl , /* ... */ doesn't.
SDF 2.1 on a closer read also supports both comment mechanisms identically to
3.0.
It's a useful question to ask why Tristan didn't implement C Style (multi line)
comments.
>
> I tried a pragmatic approach, and wrote a small filter which generates
> from the USE generated sdf files one that ghdl can digest. This
> filter (see attachment) will
>
> 1. use rtriples instead of an RNUMBER for VOLTAGE and TEMPERATURE clauses
> 2. use rtriples instead of RNUMBER for all IOPATH clauses
> 3. remove all TIMINGCHECK clauses
>
> The original lines are preserved as C++ style comments.
>
> This way several of my models now work also in ghdl with timing annotation.
> In one case however the patched sdf files produced the error
>
> tbd_fifo_2c_dram_tsim.sdf_ghdl:208:26: bad character in SDF file
>
> looking into the sdf file showed that the problem was in the middle
> of unmodified and quite innocent text
>
> (CELL (CELLTYPE "X_OBUF")
> (INSTANCE DO_14_OBUF)
> (DELAY
> (ABSOLUTE
> (PORT I (19:24:24))
> (IOPATH I O (3566:4459:4459))
> )
> )
> )
> (CELL (CELLTYPE "X_BUF")
> ^
> 208:26: bad character in SDF file
> (INSTANCE DI_12_IBUF)
> (DELAY
> (ABSOLUTE
> (IOPATH I O (120:150:150))
> )
> )
> )
>
> Adding a blank line before '(CELL (CELLTYPE "X_BUF")' made the error
> go away, a quite confusing behavior of the sdf parser in ghdl ...
>
The code for C Style comments is kind of simple and could easily go in the case
statement in Skip_Spaces ( in ghdl/translate/grt/grt-sdf.ad[bs], where the SDF
parser is) except for one critical issue. The buffer being used as an input
buffer is a block buffer and not a line buffer (or stream pointer). The buffer
is reloaded with a procedure called Refill_Buf, and there's also a procedure
called Read Append used when manipulating Qstrings and Identifiers. It
basically allows an additional blocks worth of read into Buf, which is big
enough.
Unfortunately there is nothing that limits the size of multi C Style comments,
you could poor your life story (or one of my GHDL-discuss posts) into a
comment. The issue has to to with the boundary between successive blocks.
Imagine if you will the first character of a C Style comment end delimiter ('*'
of "*/") is the last character in the buffer. If you peek ahead successive
characters of a multi character delimiter (as in comment delimiters) or
operators (Level 1), you either need to operate the buffer as a FIFO or store
state for successive buffers. I think we're seeing behavior related to that
here. It would also occur when you are counting on a following delimiter to
tell you something if the token you are dealing with falls on the last
character of the buffer (as in a required white space delimiter).
The expand the buffer trick for identifiers and Qstrings Tristan has isn't
suitable, because sooner or later you can still hit the last character in the
expanded buffer.
The solution appears to be to switch Buf from a block buffer loaded using
fread() to one using fgetln() or fgets() (ya, foreign calls in Ada, the main
lexer for VHDL is stream pointer based if I recall correctly, written in Ada).
It would allow simplifying the SDF parser in a couple of places and counts on
the newline being the end of the buffer (unless End of Text (End of File) or
error). White space is always a delimiter (separator) for tokens in SDF (and
VHDL, and ...). Now all we need is a buffer long enough for the longest line
plus one character position for a newline character. Buf_Len becomes a global
variable (natural) instead of a constant. Multiple character non-identifier
and non Qstring lexical elements simply won't get accepted recognized if not
enough characters are available at the end of line. There's also an issue
where you need the string value of something straddling a buffer boundary,
hence the Read_Append.
The changes to do use a line buffer aren't particularly extensive and would
actually simplify bits of the SDF parser. (And the reason I'm so situationally
aware of the issues using block versus line buffers, is I was beating up
someone over the distinction a couple of days ago).
I think there's at least one token recognizer that isn't end of buffer clean in
the SDF parser right now. The C++ Style comments actually work right scanning
for a newline.
The drawback of using a line buffer is having the concept of maximum line
length lurking around. Note Tristan already has a block buffer big enough for
two blocks.
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
