From: Michael McNamara (mac@surefirev.com)
Date: Fri Oct 08 1999 - 07:59:50 PDT
Basically, in a nutshell, I'm ok with vpi opens of filenames
getting the same file if that file is opened by the old $fopen.
If users reopen the same file multiple times with the old $fopen,
INMO, they get what they deserve, and the current behaviour is fine.
what I am against, which you have not proposed, is a new vpi
open, that can join in with the new style $fopen.
Note that the same file could be opened by the old and new style
$fopen.
I'm off to a week a travel, so you get to be the last voice!
-mac
Stuart Sutherland writes:
> Mac,
>
> I agree with the principles of your arguments that two processes should be
> able to write to different points in the same file. But, if I understand
> the new features of $fopen correctly (always a big IF) I think there is a
> flaw in your arguments.
>
> You mentioned that an mcd file can be opened in append mode. It is my
> understanding, however, that only the new fd (file descriptor) can open
> files in append mode. The old behavior for $fopen is that a file is opened
> as a new file each time $fopen is called -- there was no append mode for
> mcd's. As a new file, The second $fopen will wipe out the file and
> pointers being used by the first $fopen.
>
> It is my understanding that for 1364-2000 the old "mcd" usage of $fopen is
> to remain unchanged. That is, when $fopen is used without a second
> argument, a new file is created, and an mcd is returned. The new "fd"
> usage of $fopen is what opens a file in append mode, and would support
> multiple file descriptors for the same file.
>
> >From the PLI side, only mcd's are supported. The 1995 vpi_mcd_open()
> remains unchanged, and only return mcd's (as is indicated by the routine
> name). vpi_mcd_printf() also remains unchanged, and only writes to files
> using an mcd -- using an fd with vpi_mcd_printf() is an error. The changes
> we made for the 1364-2000 standard are only to document that the new fd
> file descriptor is not supported by these routines. We decided not to add
> new VPI routines to support the fd file descriptors for two reasons: It
> would require adding several more routines to the VPI library, and it does
> not add any capability that C can't do already (including, as you noted,
> opening and appending to a file already open).
>
> This leaves the original question unspecified in section 17 of the draft 3
> LRM: What happens if $fopen is called twice on the same file? Perhaps the
> answer is different for $fopen without its second argument (the old mcd)
> versus $fopen with its second argument (the new fd).
>
> And there is the objection you raised: Should vpi_mcd_open() be allowed to
> 'magically' return an existing mcd for a file that is already open?
>
> >From my perspective, it makes sense to state for both $fopen without its
> second argument, and for vpi_mcd_open(), that if the file is already open,
> an mcd of 0 is returned (and perhaps a run-time error or warning is
> generated).
>
> It also makes sense for the two functions to do the same thing, so the BTF
> and PTF should try to resolve this together, and soon.
>
> That's my 2 cents worth. Now it's time for the real experts to jump in...
>
> Stu
>
> At 08:26 AM 10/7/99, Michael McNamara wrote:
> >
> >Stuart Sutherland writes:
> > > BTF,
> > >
> > > In our PTF meeting today, it was noted that the draft 3 description
> > > in section 17 for $fopen does not say if it is legal or illegal to
> > > open the same file twice. By not saying anything, the implication
> > > is that it is legal.
> >
> > That is correct.
> >
> > > In the VPI counterpart, vpi_mcd_open(), which only supports mcd
> > > descriptors, we explicitly state:
> > >
> > > If the file has already been opened either by a previous call to
> > > vpi_mcd_open() or using $fopen in the Verilog source code, then
> > > vpi_mcd_open(), shall return the descriptor number.
> > >
> > > Please let us know what the intended behavior should be for $fopen.
> >
> >My expectation is that if you open the same file twice, you get two
> >completely different file descriptors, which which you can do two
> >completely different things, and hence which each might point to
> >different parts of the file at any particular time.
> >
> >This is what unix would do in general, and does provide for the most
> >flexibility. One could imagine usefully opeing a file twice in read
> >mode, once say, to read top level documentation, and once walking
> >through a section of the later instructions.
> >
> >I argue _strongly_ against vpi_mcd_open() having the 'magical' ability
> >to latch on to the file descriptor of a file that happens to be
> >already opened from verilog, and then moving that file pointer.
> >
> >Let me be clear: I have no problem passing a file descriptor from the
> >verilog to the vpi, and allowing the vpi to perform operations through
> >that passed file descriptor that modify data. This is wonderful.
> >
> >I also have no problems with vpi passing filedescriptors to verilog,
> >for verilog's use.
> >
> >I also have no problem with the vpi appending data to the same
> >verilog.log file. Since mcd's can only be opened for append (writing
> >at the end), what you have in the vpi is ok. But I would have a real
> >problem if you extended the vpi to be able to 'horn in' on a file
> >descriptor opened for reading, or for random access writing, by
> >$fopen.
> >
> >For example, given:
> >
> > fd = $fopen("program.exe", "rb");
> > while (1) begin
> > if (cde) begin
> > cde = $fread(op, fd);
> > if (cde) top.execute(op);
> > end
> > if(!cde) top.finish();
> > end
> >
> >It is possible that the vpi could get invoked in the middle of this
> >loop (say due to some call back), happen to open "program.exe", and
> >get the same file pointer, move it around, and hence break the
> >expected execution of the above loop.
> >
> >-mac
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Stuart Sutherland Sutherland HDL Inc.
> stuart@sutherland.com 22805 SW 92nd Place
> phone: 503-692-0898 Tualatin, OR 97062
>
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:30 PDT
and
sponsored by Boyd Technology, Inc.