multiple $fopen of same file for write?

[David Rogoff]

Put your LRM caps on (although I couldn't find an answer there)...

I have some code I'm looking at that has multiple $fopen("file","w");
in it from different modules for the same file. I'm not seeing errors
from vcs, but this just doesn't seem kosher. Any thoughts?

Thanks,

David

 

[Jonathan Bromley]

On Sun, 9 May 2010 22:52:41 -0700, David Rogoff <david@therogoffs.com>
wrote:

Put your LRM caps on (although I couldn't find an answer there)...

I have some code I'm looking at that has multiple $fopen("file","w");
in it from different modules for the same file. I'm not seeing errors
from vcs, but this just doesn't seem kosher. Any thoughts?

hi David,

I absolutely agree with you that it sounds very dodgy, but there
are various things to consider here.

First off, Verilog simulators are generally surprisingly helpful about
abuse of files. I've noticed many times in the past that they are
rather good at atoning for my sins by properly flushing and
closing output files for me even when I stop the simulation
brutally with $finish or worse. So it's perfectly possible that
there may be some helpful magic going on.

Second, the operating system is very heavily implicated
in all this stuff. To what extent is it OK to have the same
file open twice for output? For example: I just fired up
a Tcl interpreter and tried to write to the same-named file
via two separate channels. The last one I closed was the
winner. A reasonable guess might be (OS gurus please
help here!) that each open-for-writing creates a
temporary file, and the specified filename is committed
to the directory only on file close; if that's true, then
the only data you will see in the finished file is what
you wrote to the channel that you closed last.

But then I opened the same file for append on two
distinct channels, and I saw _all_ the output from
both channels appended to the original file. So I
guess I'm a little confused.

It's the kind of stuff that falls squarely into my
I Don't Want To Do That category, but there's
no accounting for taste
--
Jonathan Bromley

 

[David Rogoff]

On 2010-05-10 13:28:29 -0700, Jonathan Bromley said:

On Sun, 9 May 2010 22:52:41 -0700, David Rogoff <david@therogoffs.com
wrote:

Put your LRM caps on (although I couldn't find an answer there)...

I have some code I'm looking at that has multiple $fopen("file","w");
in it from different modules for the same file. I'm not seeing errors
from vcs, but this just doesn't seem kosher. Any thoughts?

hi David,

I absolutely agree with you that it sounds very dodgy, but there
are various things to consider here.

....

It's the kind of stuff that falls squarely into my
I Don't Want To Do That category, but there's
no accounting for taste

Yeah, I ended up doing an $fopen for write in my testbench at time 0
and changed the other $fopens to append. Seems to work.

 

On May 10, 1:52 am, David Rogoff <da...@therogoffs.com> wrote:

Put your LRM caps on (although I couldn't find an answer there)...

I have some code I'm looking at that has multiple $fopen("file","w");
in it from different modules for the same file. I'm not seeing errors
from vcs, but this just doesn't seem kosher.  Any thoughts?

I agree that this is dangerous. I don't think the LRM has anything to
say about it.

It is possible that an implementation could compare newly opened files
to any previously opened files (by filename or by some file-system ID)
and return the same file handle value as for the previously opened
file. In this case you should be safe, since it is then the same as
if you used the first file handle everywhere. You could check for
this by printing out the file handle and seeing if it is the same
integer value in all cases.

If this is not occurring, then there are a number of ways that this
could go wrong. Each of the underlying file descriptors could be
tracking the position in the file, and each write could go to the
position where the previous one left off. In this case, the output
through each handle would overwrite any later output through another
handle. Opening the file in append mode would solve this, since each
write would seek to the end of the file first. Note that the first
$fopen would need to be done in append mode also, or writes through
that handle could overwrite data written through other handles. If
you didn't want to append to an existing file, you might need to open
and close the file in write mode first to empty it.

Then there is buffering. If the output is being buffered, then the
output from a write will not go into the file immediately. It will
just go into the buffer for that handle. When the buffer is full, you
might get everything written in the write that fills it, or it might
just dump the full buffer. So output might not come out in the same
order as the writes, and it might interleave on multiples of some
buffer size, rather than full writes or lines. I.e. it might stop in
the middle of a line from one write, and switch to the end of a line
from a write through a different handle. To fix this, you would need
to do a $flush after each set of writes through a particular handle.
Or the tool might have an option to turn off buffering of output,
though this would presumably slow it down some.

It is possible that your tool will work just fine, but the code might
not work if used with another tool.