From: Michael McNamara (mac@surefirev.com)
Date: Mon Jul 12 1999 - 13:36:12 PDT
Charles Dawson writes:
> Hi BTF,
>
> I have a proposal to handle the PLI for B29. Drew Lynch has questioned
> whether or not I took the correct approach, and so I would like feedback
> from you. Here are the two solutions:
>
> 1. My solution.
>
> Add new properties to get the "original" location. Leave the current
> properties as they are, namely that these properties would return the
> location in the files that were actually compiled for the simulation.
>
> Advantages: This allows applications complete access. An application
> can perform a cross-reference.
>
> 2. Drew's solution.
>
> Whenever a `file is encountered in the HDL, the tool will automatically
> convert the location properties to the original location.
>
> Advantages: No extra properties required. This is more GDB-like, in
> that a debugger will point back at the original source, just
> like GDB does.
>
> Please let me know which you prefer, and why. Also contact me if you need
> further clarification or have any questions.
The `line directive allows a tool to 'lie' to the rest of the
world about where code came from.
For the lie to be convincing, all the rest of the tools must
participate.
If the following is encountered:
module foo;
`line /dev/null 34
reg [31:0] a;
reg [7:0] b;
endmodule
then it must be presented to the user that the definition of a is on
line 34 of /dev/null, and the definition of b is on line 35 of
/dev/null, an so on. (maybe it's line 35 & 36? see the spec)
Any other implementation will have problems.
Note that as a lie, it is quite possible that there really is no line
34 of /dev/null, and that tools that try to print out the code at that
line will encounter problems. In this case it is of course, certain
that there will be problems.
But the intent is that only verilog to verilog translators will ever
insert such code (e.g., things like the old Radiant Design radify
program), and such programs will behave with the best intentions of
the user.
Chas: examining your proposal, it is implied, but not stated that one
would have to check each object's vpiLevel property to see if there is
there is a line directive in effect, in order to know the correct call
to make to get the FileName / LineNumber pair.
--------------------------------
I am curious: If you wanted to retain 'real' location information,
then envisioning the typical usage of this data, my inclination would
be to make vpiFile and vpiLineNo always have the file name / line
number as modified by any `line directives, and have vpiRealFile and
vpiRealLineNo always have the actual filename and line number.
This way the error printer simply always uses vpiFile/vpiLineNo
without needing to concern itself with whether there is any `line
directives around anywhere. (note that `line affects all the
subsequent objects until an end of file, or another `line directive is
found)
Applications that always want to get the real thing always use
vpiRealFile and vpiRealLineNo, and hence see through any illusions.
Applications that want to know if there is a `line directive in effect
for the current object can simply compare vpiFile with vpiRealFile and
vpiLineNo with vpiRealLineNo.
--------------------------------
Note that something I do when I want to debug yacc (which isn't too
often these days) is:
foo.c : foo.y
yacc foo.y -o foo_1.c
# Uncomment the next line if you want gdb to step through the
# generated parser rather than the parser source
# sed -e '/^# line/d' foo_1.c > foo.c
<p>(With bison, of course, it is much easier:
-l
--no-lines
Don't put any #line preprocessor commands in the parser
file. Ordinarily bison puts them in the parser file so
that the C compiler and debuggers will associate errors
with your source file, the grammar file. This option
causes them to associate errors with the parser file,
treating it an independent source file in its own
right.
)
This is a good example, that I believe we should follow.
My fear with the current proposal is that you create the requirement
for a two filename pointers, and two linenumber variables for each
object in the design, hence we are adding 8 bytes * number_of_objects
to the memory size of every VPI compliant application. IMHO it would
be cheaper to suggest the user write a perl script to delete the `line
directives, or that the generation tool impliment a --no-lines switch,
or that the verilog application implement a +no-lines switch, should
some one want to debug the generated output.
<p> >
> I need a response this week if at all possible. Thanks.
>
> -Chas
>
> P.S. Here is my actual proposal:
>
> > ************************************************************************
> >
> > PLI Task Force ID: PTF-301
> > Summary: Implement BTF enhancement B29 in PLI
> > (file and line compiler directives)
> > Relevant LRM Sections: ?
> > Current Status: Analyzed (pending Chas.)
> > Date Submitted: 22 Jan 1999
> > Date Analyzed: 24 May 1999
> > Date of Last Action: 24 May 1999
> > Author of Submission: Stuart Sutherland
> > Author's Net Address: stuart@sutherland.com
> > Description of Problem:
> >
> > 22 Jan 1999: This enhancement to Verilog has been approved by the BTF.
> > Need to implement in the PLI.
> >
> > 17 may 1999: The enhancement has been officially approved by the 1364
> > working group.
> >
> > Proposed Resolution:
> >
> > 24 May 1999: Assigned to Chas. to propose changes required in LRM.
> >
> > TF Recommendation for changes to 1364-1995 standard:
> >
> > 03 Jun 1999:
> >
> > I propose making the following changes to support this BTF enhancement:
> >
> >
> > 1. Since almost all objects have a location, we should remove these
> > properties from the diagrams (just like vpiType is not in the
> > diagrams), and create a new sub-section in section 22.2.1 as follows:
> >
> > 22.2.1.1 Default Properties
> >
> > Some properties apply to every object, and therefore are not
> illustrated
> > in section 22.5. Specifically, the property
> >
> > -> type
> > int: vpiType
> >
> > can be used on every object. Note, that this property can also be
> > accessed as a string using vpi_get_str().
> >
> > Other properties which are not listed are location properties:
> >
> > -> location
> > int: vpiLineNo
> > str: vpiFile
> > int: vpiOrigLineNo
> > str: vpiOrigFile
> > int: vpiLevel
> >
> > The properties vpiOrigLineNo, vpiOrigFile, and vpiLevel are only
> > applicable if there is a `line compiler directive associated with the
> > object. If there is no `line compile directive then the following
> > values will be returned for each property, without an error being
> > generated:
> >
> > vpiOrigLineNo will return vpiUndefined
> > vpiOrigFile will return NULL
> > vpiLevel will return vpiUndefined
> >
> > These properties are applicable to every object that corresponds to
> > some object within the HDL. The exceptions are objects of type:
> >
> > vpiCallback
> > vpiDelayTerm
> > vpiDelayDevice
> > vpiInterModPath
> > vpiTimeQueue
> >
> > 2. Add the following properties to the module object:
> >
> > -> definition location
> > int: vpiDefOrigLineNo
> > str: vpiDefOrigFile
> > int: vpiDefLevel
>
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:28 PDT
and
sponsored by Boyd Technology, Inc.