iverilog-devel — Conversations on matters of Icarus Verilog development

Re: [Iverilog-devel] New release for iverilog

[Stephen W. <st...@ic...>]

So, Cary, Martin? Thoughts on a release 11? I believe Cary has
something he wants to sneak into a release. What's the schule for
that?

On Thu, Jul 30, 2020 at 11:05 AM Stephen Williams <st...@ic...> wrote:
>
> You make a very good point. This is being discussed, and we're
> thinking sooner rather than later.
>
> On Thu, Jul 30, 2020 at 11:03 AM Jean THOMAS <pu...@gi...> wrote:
> >
> > Hi everyone,
> >
> > Lots of changes have happened in iverilog since its last release. In
> > most Linux distros only the latest release is available, which is a year
> > old now. When can we expect a new release for iverilog?
> >
> > Cheers,
> > Jean
> >
> >
> > _______________________________________________
> > Iverilog-devel mailing list
> > Ive...@li...
> > https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>
>
> --
> Steve Williams                "The woods are lovely, dark and deep.
> st...@ic...              But I have promises to keep,
> http://www.icarus.com         and lines to code before I sleep,
> http://www.picturel.com       And lines to code before I sleep."



-- 
Steve Williams                "The woods are lovely, dark and deep.
st...@ic...              But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

Re: [Iverilog-devel] New release for iverilog

[Stephen W. <st...@ic...>]

You make a very good point. This is being discussed, and we're
thinking sooner rather than later.

On Thu, Jul 30, 2020 at 11:03 AM Jean THOMAS <pu...@gi...> wrote:
>
> Hi everyone,
>
> Lots of changes have happened in iverilog since its last release. In
> most Linux distros only the latest release is available, which is a year
> old now. When can we expect a new release for iverilog?
>
> Cheers,
> Jean
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel



-- 
Steve Williams                "The woods are lovely, dark and deep.
st...@ic...              But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

[Iverilog-devel] New release for iverilog

[Jean T. <pu...@gi...>]

Hi everyone,

Lots of changes have happened in iverilog since its last release. In 
most Linux distros only the latest release is available, which is a year 
old now. When can we expect a new release for iverilog?

Cheers,
Jean

Re: [Iverilog-devel] -g 2012 argument in Command file

[<bo...@el...>]

Cary R. via Iverilog-devel writes:
> It should be possible and I was hoping to look at what was needed to implement
> this over the weekend.

Hello Cary,

the question was half an offer that I could look into it.

However my incentive diminished as the problem was with an 2010
Spartan 6 design where I have to use ISE for implementation and ISE
does not cope with arrays in the module headers. In the meantime I
rewrote the code to use vectors and I no longer need the array
functionality with the more recent verilog language versions.

Bye
-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------

Re: [Iverilog-devel] -g 2012 argument in Command file

[Cary R. <cy...@ya...>]

 It should be possible and I was hoping to look at what was needed to implement this over the weekend.
Cary

    On Wednesday, June 17, 2020, 2:34:30 AM PDT, <bo...@el...> wrote:  
 
 Martin Whitaker writes:
 
> No, the "-g" options aren't supported. The "Command Files" section in 
> the iverilog man page lists what can be done.

Is there any reason that it can not be done beside not yet implemented?

-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------


_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
  

Re: [Iverilog-devel] -g 2012 argument in Command file

[<bo...@el...>]

Martin Whitaker writes:
 
> No, the "-g" options aren't supported. The "Command Files" section in 
> the iverilog man page lists what can be done.

Is there any reason that it can not be done beside not yet implemented?

-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------

Re: [Iverilog-devel] -g 2012 argument in Command file

[Martin W. <ic...@ma...>]

On 15/06/2020 14:43, bo...@el... wrote:
> Probably my question was not clear. I meant to put the Verilog
> language generation selection into a cmd file like:
> 
> ==== llbbc_reg.cmd ====
> +libdir+.
> +libdir+../avr_if
> +libext+.v
> -g2012
> llbbc_reg_tb.v
> 
> and call it like "iverilog -c  llbbc_reg.cmd"
> This results in
>> iverilog -c llbbc_reg.cmd
> Error: unable to parse line 4 in llbbc_reg.cmd.
> iverilog: parsing failed in base command file llbbc_reg.cmd.
> 
> Only by omitting the -g line in the command line and calling
> "iverilog -c llbbc_reg.cmd -g2012" iverilog compiles.
> 
> My question was: Is there any syntax to put things like the "-g2012"
> argument in the command file, so I do not have to specify it on the
> command line?

No, the "-g" options aren't supported. The "Command Files" section in 
the iverilog man page lists what can be done.

Re: [Iverilog-devel] -g 2012 argument in Command file

[<bo...@el...>]

Cary R. via Iverilog-devel writes:
> Hi Uwe,
> 
> Any of the following should work: -g2005-sv, -g2009, -g2012, -g2017 to tell
> iverilog to process the files as SystemVerilog using the appropriate keywords.
> 
> We support both array declaration styles:
> 
>   logic mdarr [0:3][0:7];
> or
>   logic mdarr [4][8];
> 
> I ran a quick test example and it works. I believe we do not currently support
> passing arrays as arguments, array patterns, array slices, etc., but the basic
> support is there.
> 
Hi Carry,

sorry for not getting back earlier, I has a long weekend ;-)

Probably my question was not clear. I meant to put the Verilog
language generation selection into a cmd file like:

==== llbbc_reg.cmd ====
+libdir+.
+libdir+../avr_if
+libext+.v
-g2012
llbbc_reg_tb.v

and call it like "iverilog -c  llbbc_reg.cmd"
This results in
> iverilog -c llbbc_reg.cmd
Error: unable to parse line 4 in llbbc_reg.cmd.
iverilog: parsing failed in base command file llbbc_reg.cmd.

Only by omitting the -g line in the command line and calling
"iverilog -c llbbc_reg.cmd -g2012" iverilog compiles.

My question was: Is there any syntax to put things like the "-g2012"
argument in the command file, so I do not have to specify it on the
command line?

Bye
 
-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------

Re: [Iverilog-devel] -g 2012 argument in Command file

[Cary R. <cy...@ya...>]

 Hi Uwe,
Any of the following should work: -g2005-sv, -g2009, -g2012, -g2017 to tell iverilog to process the files as SystemVerilog using the appropriate keywords.
We support both array declaration styles:
  logic mdarr [0:3][0:7];or
  logic mdarr [4][8];
I ran a quick test example and it works. I believe we do not currently support passing arrays as arguments, array patterns, array slices, etc., but the basic support is there.

Cary
    On Tuesday, June 9, 2020, 9:33:36 AM PDT, <bo...@el...> wrote:  
 
 Hello,

trying to instantiate a 2-dimensional array, systemverilog comes nice.
However I have not found a way to request systemverilog from a cmd file.

Do I miss soemthing or is that feature missing?

Thanks for iverilog!
-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------


_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
  

[Iverilog-devel] -g 2012 argument in Command file

[<bo...@el...>]

Hello,

trying to instantiate a 2-dimensional array, systemverilog comes nice.
However I have not found a way to request systemverilog from a cmd file.

Do I miss soemthing or is that feature missing?

Thanks for iverilog!
-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------

Re: [Iverilog-devel] NULL file descriptor or MCD

[Martin W. <ic...@ma...>]

OK by me.

On 17/05/2020 19:24, Cary R. via Iverilog-devel wrote:
>   The other issue I see is if you call $fclose() with a MCD and any of the bits are invalid files none of the files will be closed. This is existing functionality and not something new. It almost seems like we need to pass the MCD to vpi_mcd_close() and then report an failures based on what could not be closed. All other routines that take a MCD also just return with a warning message.
> Cary
> 
>      On Sunday, May 17, 2020, 11:11:22 AM PDT, Cary R. <cy...@ya...> wrote:
>   
>   Here is example code and what I have implemented for checking the return value of vpi_mcd_close(). The "could not close ..." lines are the new output from checking the close return value. If this is acceptable I will commit this and update the tests as needed.
> 
> module top;
>    integer fd;
> 
>    initial begin
>      // MCD
>      fd = 0;
>      $fclose(fd); // NULL
>      fd = 1;
>      $fclose(fd); // STDOUT
>      fd = 2;
>      $fclose(fd); // Invalid
> 
>      // FD
>      fd=32'h80000000;
>      $fclose(fd); // STDIN
>      fd=32'h80000001;
>      $fclose(fd); // STDOUT
>      fd=32'h80000002;
>      $fclose(fd); // STDERR
>      fd=32'h80000003;
>      $fclose(fd); // Invalid
>    end
> endmodule
> WARNING: tmp.v:9: could not close MCD STDOUT (0x1) in $fclose().
> WARNING: tmp.v:11: invalid MCD (0x2) given to $fclose().
> WARNING: tmp.v:15: could not close file descriptor STDIN (0x80000000) in $fclose().
> WARNING: tmp.v:17: could not close file descriptor STDOUT (0x80000001) in $fclose().
> WARNING: tmp.v:19: could not close file descriptor STDERR (0x80000002) in $fclose().
> WARNING: tmp.v:21: invalid file descriptor (0x80000003) given to $fclose().
> Cary
>     On Sunday, May 17, 2020, 2:18:34 AM PDT, Cary R. via Iverilog-devel <ive...@li...> wrote:
>   
>    Thanks Martin,
> That is what is currently implemented except for the fclose() failure. At the moment $fclose() is implemented using vpi_mcd_close(), which now returns the failing MCD/FD correctly. One of the fixes I added is if you try to close the preopened descriptors (STDOUT either MCD or FD along with the STDIN or STDERR FDs) it returns them since they were not closed (it's an error). Should we report an error when trying to close these or just when the underlying fclose() fails? My inclination would be report them
> 
> The big-3 simulator I use appears to not report any messages when invalid FD/MCDs are used. I guess a place where we can do things better. I get a failing fclose() is fairly benign, but it seems like giving information regarding bugs would be helpful.
> 
> Cary
>     On Sunday, May 17, 2020, 1:11:27 AM PDT, Martin Whitaker <ic...@ma...> wrote:
>   
>   A null MCD (empty set) was accepted by the file I/O tasks in Verilog-XL
> without any warning. I have used that feature in test benches (including
> passing it to $fclose), and would not want a warning.
> 
> I'm not against warnings if you pass an invalid FD/MCD to $fclose or
> $fclose fails.
> 
> On 17/05/2020 03:38, Cary R. via Iverilog-devel wrote:
>>    And on the subject of $fclose() should it print a warning when you try to close one of the preopened MDC/FDs?  Should it print a message if the underlying fclose() fails for some reason? We do cleanup the entry even if it fails so it is no longer available, but vpi_mcd_close() returns the descriptor for any failing items (well it does it correctly now) so we could report underlying issues correctly.
>> Cary
>>
>>        On Saturday, May 16, 2020, 4:24:29 PM PDT, Cary R. via Iverilog-devel <ive...@li...> wrote:
>>    
>>    It looks like Icarus along with at least one of the Big-3 simulators allows, without warning, the various file I/O system tasks/functions to accept a NULL (0) file descriptor/MCD. I can see this as helpful if you want to disable output by just setting the FD/MCD to zero, but it could be an issue if the $fopen failed and the user did not check so having a warning would be beneficial for that. We do print a warning for an invalid non-zero FD/MCD.
>>
>> So should a zero FD/MCD print a warning or do we just want it to return as if nothing happened?
>> I tend to like the warnings, but I'm not certain if there is an easy way to disable MCD output without using the zero value. Should $fclose be handled differently?
>>
>> Thoughts/suggestions appreciated.
>>
>> Thanks,
>> Cary
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>      
>>
>>
>>
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>
> 
> 
> 
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>    _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>      
> 
> 
> 
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 

Re: [Iverilog-devel] NULL file descriptor or MCD

[Michael S. <mic...@gm...>]

As long it is a warning message, I think it's ok. It is a good practice to
show people that something is not right.
Best regards,
Michael Strelnikov


On Mon, 18 May 2020 at 04:24, Cary R. via Iverilog-devel <
ive...@li...> wrote:

> The other issue I see is if you call $fclose() with a MCD and any of the
> bits are invalid files none of the files will be closed. This is existing
> functionality and not something new. It almost seems like we need to pass
> the MCD to vpi_mcd_close() and then report an failures based on what could
> not be closed. All other routines that take a MCD also just return with a
> warning message.
>
> Cary
>
> On Sunday, May 17, 2020, 11:11:22 AM PDT, Cary R. <cy...@ya...>
> wrote:
>
>
> Here is example code and what I have implemented for checking the return
> value of vpi_mcd_close(). The "could not close ..." lines are the new
> output from checking the close return value. If this is acceptable I will
> commit this and update the tests as needed.
>
> module top;
>   integer fd;
>
>   initial begin
>     // MCD
>     fd = 0;
>     $fclose(fd); // NULL
>     fd = 1;
>     $fclose(fd); // STDOUT
>     fd = 2;
>     $fclose(fd); // Invalid
>
>     // FD
>     fd=32'h80000000;
>     $fclose(fd); // STDIN
>     fd=32'h80000001;
>     $fclose(fd); // STDOUT
>     fd=32'h80000002;
>     $fclose(fd); // STDERR
>     fd=32'h80000003;
>     $fclose(fd); // Invalid
>   end
> endmodule
>
> WARNING: tmp.v:9: could not close MCD STDOUT (0x1) in $fclose().
> WARNING: tmp.v:11: invalid MCD (0x2) given to $fclose().
> WARNING: tmp.v:15: could not close file descriptor STDIN (0x80000000) in
> $fclose().
> WARNING: tmp.v:17: could not close file descriptor STDOUT (0x80000001) in
> $fclose().
> WARNING: tmp.v:19: could not close file descriptor STDERR (0x80000002) in
> $fclose().
> WARNING: tmp.v:21: invalid file descriptor (0x80000003) given to $fclose().
>
> Cary
> On Sunday, May 17, 2020, 2:18:34 AM PDT, Cary R. via Iverilog-devel <
> ive...@li...> wrote:
>
>
> Thanks Martin,
>
> That is what is currently implemented except for the fclose() failure. At
> the moment $fclose() is implemented using vpi_mcd_close(), which now
> returns the failing MCD/FD correctly. One of the fixes I added is if you
> try to close the preopened descriptors (STDOUT either MCD or FD along with
> the STDIN or STDERR FDs) it returns them since they were not closed (it's
> an error). Should we report an error when trying to close these or just
> when the underlying fclose() fails? My inclination would be report them
>
> The big-3 simulator I use appears to not report any messages when invalid
> FD/MCDs are used. I guess a place where we can do things better. I get a
> failing fclose() is fairly benign, but it seems like giving information
> regarding bugs would be helpful.
>
> Cary
> On Sunday, May 17, 2020, 1:11:27 AM PDT, Martin Whitaker <
> ic...@ma...> wrote:
>
>
> A null MCD (empty set) was accepted by the file I/O tasks in Verilog-XL
> without any warning. I have used that feature in test benches (including
> passing it to $fclose), and would not want a warning.
>
> I'm not against warnings if you pass an invalid FD/MCD to $fclose or
> $fclose fails.
>
> On 17/05/2020 03:38, Cary R. via Iverilog-devel wrote:
> >  And on the subject of $fclose() should it print a warning when you try
> to close one of the preopened MDC/FDs?  Should it print a message if the
> underlying fclose() fails for some reason? We do cleanup the entry even if
> it fails so it is no longer available, but vpi_mcd_close() returns the
> descriptor for any failing items (well it does it correctly now) so we
> could report underlying issues correctly.
> > Cary
> >
> >      On Saturday, May 16, 2020, 4:24:29 PM PDT, Cary R. via
> Iverilog-devel <ive...@li...> wrote:
> >
> >  It looks like Icarus along with at least one of the Big-3 simulators
> allows, without warning, the various file I/O system tasks/functions to
> accept a NULL (0) file descriptor/MCD. I can see this as helpful if you
> want to disable output by just setting the FD/MCD to zero, but it could be
> an issue if the $fopen failed and the user did not check so having a
> warning would be beneficial for that. We do print a warning for an invalid
> non-zero FD/MCD.
> >
> > So should a zero FD/MCD print a warning or do we just want it to return
> as if nothing happened?
> > I tend to like the warnings, but I'm not certain if there is an easy way
> to disable MCD output without using the zero value. Should $fclose be
> handled differently?
> >
> > Thoughts/suggestions appreciated.
> >
> > Thanks,
> > Cary
> > _______________________________________________
> > Iverilog-devel mailing list
> > Ive...@li...
> > https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
> >
> >
> >
> >
> > _______________________________________________
> > Iverilog-devel mailing list
> > Ive...@li...
> > https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> >
>
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

Re: [Iverilog-devel] Verilog execution of always block as multiple events

[Evan L. <sa2...@cy...>]

Yes, interesting stuff - it surprises me that anyone ever managed to
write a Verilog simulator. The second edition of Thomas and Moorby's
book (1995) doesn't appear to have a single mention of the scheduler.

Re: [Iverilog-devel] Verilog execution of always block as multiple events

[<by...@nc...>]

BTW, one difference between Icarus and VCS/Questa that I've noticed is
that events on packed arrays on those simulators are only triggered
for writes to a given array index's bitvector, not the whole packed
array.

I've had to ifdef code for Icarus where:
wire [7:0][7:0] mybits;
were
logic [7:0] mybits [7:0];

in order to function correctly. The logic thing is a separate issue
elsewhere as VCS and Questa can handle non-constant array indices in
almost all cases and Icarus can only in a subset of them.

So for the above, if I have access to a packed array across multiple
instances in a generate, there are times where Icarus goes into an
infinite retrigger condition whereas VCS/Questa gracefully complete
properly. Synopsys DC, VCLint, etc. can handle that packed construct
across multiple generate iterations fine as well.

-Tony

Re: [Iverilog-devel] Verilog execution of always block as multiple events

[Julian T. P. <jtp...@uw...>]

That is an interesting bug report. Assuming that update events
should not be processed during the always block for sanity reasons,
then your second example with the continuous assignment (or the
original report using modules) shouldn't be an infinite loop.

I think your first example without any wires or module ports between
the mutual triggering always blocks should be an infinite loop. The
assignment to 0 should schedule an evaluation event for the other
block, which can't be unscheduled by the assignment to 1. That being
said, I tried it under ModelSim for comparison and it stops looping
after one iteration of unchanged values (i.e. once tmp0 = 1 and
tmp1 = 1, each always block runs one more time), a behavior which I
don't see an explanation for.


-Julian

________________________________
From: Martin Whitaker <ic...@ma...>
Sent: Sunday, May 17, 2020 5:33 AM
To: ive...@li... <ive...@li...>
Subject: Re: [Iverilog-devel] Verilog execution of always block as multiple events

Steve's point that the time control requires the whole begin...end block
to be executed as a single event does mean that I am wrong and the vvp
behaviour is broken. See the second example I gave in

https://github.com/steveicarus/iverilog/issues/321#issuecomment-626305761

If update events are not allowed to be executed during the begin...end
blocks, the wires should never reflect the glitches.

On 16/05/2020 23:52, Stephen Williams wrote:
> This is an interesting problem, and has come down to an unwritten rule
> that sequential statements are executed without interruption until
> they voluntarily yield by a time or event statement. Many people who
> tried to implement multi-threaded Verilog simulators have discovered
> this assumption the hard way. The problem is that Verilog has no
> thread synchronization primitives other than the time and event
> controls, and so every Verilog programmer has used these controls
> exactly that way. So:
>
> always @(a or b) begin
>    temp = a & b;
>    c = temp;
> end
>
> Once this thread is started, it will run, uninterrupted, until it gets
> to the @(...) statement, which yields the CPU.
>
> Now, it can also be pointed out that this is technically only a single
> statement. The @(a or b)... is a single statement that has as a
> sub-statement a begin..end block. People don't usually think about it
> that way, but it is technically true.
>
> On Sat, May 16, 2020 at 3:05 PM Julian Thomas Parkin
> <jtp...@uw...> wrote:
>>
>> This isn't an issue with iverilog, but I have a question about the
>> execution semantics of Verilog. There isn't much information online
>> and a lot of it points to this mailing list
>> (e.g. https://sourceforge.net/p/iverilog/mailman/message/36358575/)
>> so I'm hoping it's alright if I ask here.
>>
>> In 1364-2005, section 11.4.2 includes the following sentence (which
>> is also present in SystemVerilog): "Another source of nondeterminism
>> is that statements without time-control constructs in behavioral
>> blocks do not have to be executed as one event."
>>
>> As an example, it presents the following:
>>
>>    assign p = q;
>>    initial begin
>>        q = 1;
>>        #1 q = 0;
>>        $display(p);
>>    end
>>
>> The simulator is allowed to process the "q = 0" assignment, then
>> suspend execution in favour of updating p, and then display p as 0.
>>
>> Does this also apply to the typical style of always process used
>> to express combinatorial circuits ?
>>
>> For example, if someone were to implement an and gate using a
>> temporary variable:
>>
>>    always @(a or b) begin
>>        temp = a & b;
>>        c = temp;
>>    end
>>
>> Say a and b both have pending update events. Could the simulator
>> update a, see that the always has been activated, execute
>> "temp = a | b;", then suspend execution to update b ? At which
>> point the always block is not sensitive to changes because it is
>> still being executed, so it ends up missing the second update even
>> though b is in the sensitivity list.
>>
>> Is this valid behavior according to the standard ? Or does
>> "statements without time-control constructs" apply to the
>> "begin end" block as a whole and prevent it from being executed as
>> multiple events because it does have a time-control ? If this is
>> valid, do iverilog or other simulators ever behave in this manner ?
>>
>>
>> Thanks,
>>
>> -Julian
>>
>>
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>
>



_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel

Re: [Iverilog-devel] Verilog execution of always block as multiple events

[Julian T. P. <jtp...@uw...>]

Thanks for the links. I found this other Steven Sharp comment from
that discussion to be particularly illuminating (referring to trying
to understand the scheduling only by reading the standard, something
which I guess I was guilty of).

"This is a bit dangerous. The section on scheduling semantics was
grafted onto the standard rather late in the process.  It uses
terminology that is not used anywhere else in the standard.  It tries
not to disallow any behavior of Verilog-XL or other simulators of the
time, and in the process allowed so much nondeterminism that it would
be hard to write working Verilog if it were taken too literally."


-Julian

________________________________
From: Evan Lavelle <sa2...@cy...>
Sent: Sunday, May 17, 2020 12:37 PM
To: ive...@li... <ive...@li...>
Subject: Re: [Iverilog-devel] Verilog execution of always block as multiple events

On 17/05/2020 07:11, Julian Thomas Parkin wrote:
> Thanks for the explanations everyone, very helpful.
>
> Would I be correct in summarizing this as, the standard doesn't
> strictly require an always block to run uninterrupted until it
> suspends on its own, but there's a lot of inertia behind the
> assumption that it does (an "unwritten rule" as Steve calls it) to
> the point that it's a safe assumption to make when writing Verilog.

Basically, yes, but the unwritten rule is occasionally broken. The
scheduler is event-driven, not pre-emptive; it shouldn't arbitrarily
decide when to transfer control between different processes. But, OTOH,
the LRM does *not* specify atomic execution of code between scheduling
points, and explicitly says in 11.4.1(a) that "Execution of statements
in a particular begin-end block can be suspended in favor of other
processes in the model".

Steven Sharp covered this in comp.lang.verilog at

https://groups.google.com/forum/?hl=en#!topic/comp.lang.verilog/2X9f9ds9XnE

as follows (in other words, this is as Gospel as it gets for Verilog):

"There is the rigamarole about allowing a begin-end to suspend in favor
of executing another process, and then resume later.  If taken to
extremes, this would make the language very hard to use, since many
common practices would become nondeterministic.  This seems to have
been stated partly to allow for simulator optimizations involving
inlining of one process into another.  For example, when an always
block updates a variable, a simulator might immediately update a net
that is assigned from that variable.  This can be viewed as suspending
the always block, executing the continuous assignment, and then
resuming the always block.  But no simulator is going to arbitrarily
suspend one process to execute another, unless there is at least some
kind of event-driven connection between them".

I'm sure this is covered elsewhere in c.l.v, but it's next to useless
now, since Google removed the advanced search.

But not all simulators play ball. See:

https://groups.google.com/forum/#!searchin/comp.lang.verilog/%22STEVEN$20SHARP%22$20scheduler|sort:date/comp.lang.verilog/tK-MpHdfVCE/uGAgIp4BpBIJ

Look up my comment for:

x = add(x, 1);

I found one simulator where this wasn't atomic. This was a long time ago
(2008), and I don't have notes, so I don't know which sim it was.


_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel

Re: [Iverilog-devel] NULL file descriptor or MCD

[Cary R. <cy...@ya...>]

 The other issue I see is if you call $fclose() with a MCD and any of the bits are invalid files none of the files will be closed. This is existing functionality and not something new. It almost seems like we need to pass the MCD to vpi_mcd_close() and then report an failures based on what could not be closed. All other routines that take a MCD also just return with a warning message.
Cary

    On Sunday, May 17, 2020, 11:11:22 AM PDT, Cary R. <cy...@ya...> wrote:  
 
 Here is example code and what I have implemented for checking the return value of vpi_mcd_close(). The "could not close ..." lines are the new output from checking the close return value. If this is acceptable I will commit this and update the tests as needed.

module top;
  integer fd;

  initial begin
    // MCD
    fd = 0;
    $fclose(fd); // NULL
    fd = 1;
    $fclose(fd); // STDOUT
    fd = 2;
    $fclose(fd); // Invalid

    // FD
    fd=32'h80000000;
    $fclose(fd); // STDIN
    fd=32'h80000001;
    $fclose(fd); // STDOUT
    fd=32'h80000002;
    $fclose(fd); // STDERR
    fd=32'h80000003;
    $fclose(fd); // Invalid
  end
endmodule
WARNING: tmp.v:9: could not close MCD STDOUT (0x1) in $fclose().
WARNING: tmp.v:11: invalid MCD (0x2) given to $fclose().
WARNING: tmp.v:15: could not close file descriptor STDIN (0x80000000) in $fclose().
WARNING: tmp.v:17: could not close file descriptor STDOUT (0x80000001) in $fclose().
WARNING: tmp.v:19: could not close file descriptor STDERR (0x80000002) in $fclose().
WARNING: tmp.v:21: invalid file descriptor (0x80000003) given to $fclose().
Cary
   On Sunday, May 17, 2020, 2:18:34 AM PDT, Cary R. via Iverilog-devel <ive...@li...> wrote:  
 
  Thanks Martin,
That is what is currently implemented except for the fclose() failure. At the moment $fclose() is implemented using vpi_mcd_close(), which now returns the failing MCD/FD correctly. One of the fixes I added is if you try to close the preopened descriptors (STDOUT either MCD or FD along with the STDIN or STDERR FDs) it returns them since they were not closed (it's an error). Should we report an error when trying to close these or just when the underlying fclose() fails? My inclination would be report them

The big-3 simulator I use appears to not report any messages when invalid FD/MCDs are used. I guess a place where we can do things better. I get a failing fclose() is fairly benign, but it seems like giving information regarding bugs would be helpful.

Cary
   On Sunday, May 17, 2020, 1:11:27 AM PDT, Martin Whitaker <ic...@ma...> wrote:  
 
 A null MCD (empty set) was accepted by the file I/O tasks in Verilog-XL 
without any warning. I have used that feature in test benches (including 
passing it to $fclose), and would not want a warning.

I'm not against warnings if you pass an invalid FD/MCD to $fclose or 
$fclose fails.

On 17/05/2020 03:38, Cary R. via Iverilog-devel wrote:
>  And on the subject of $fclose() should it print a warning when you try to close one of the preopened MDC/FDs?  Should it print a message if the underlying fclose() fails for some reason? We do cleanup the entry even if it fails so it is no longer available, but vpi_mcd_close() returns the descriptor for any failing items (well it does it correctly now) so we could report underlying issues correctly.
> Cary
> 
>      On Saturday, May 16, 2020, 4:24:29 PM PDT, Cary R. via Iverilog-devel <ive...@li...> wrote:
>  
>  It looks like Icarus along with at least one of the Big-3 simulators allows, without warning, the various file I/O system tasks/functions to accept a NULL (0) file descriptor/MCD. I can see this as helpful if you want to disable output by just setting the FD/MCD to zero, but it could be an issue if the $fopen failed and the user did not check so having a warning would be beneficial for that. We do print a warning for an invalid non-zero FD/MCD.
> 
> So should a zero FD/MCD print a warning or do we just want it to return as if nothing happened?
> I tend to like the warnings, but I'm not certain if there is an easy way to disable MCD output without using the zero value. Should $fclose be handled differently?
> 
> Thoughts/suggestions appreciated.
> 
> Thanks,
> Cary
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>    
> 
> 
> 
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 



_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
  _______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
    

Re: [Iverilog-devel] NULL file descriptor or MCD

[Cary R. <cy...@ya...>]

Here is example code and what I have implemented for checking the return value of vpi_mcd_close(). The "could not close ..." lines are the new output from checking the close return value. If this is acceptable I will commit this and update the tests as needed.

module top;
  integer fd;

  initial begin
    // MCD
    fd = 0;
    $fclose(fd); // NULL
    fd = 1;
    $fclose(fd); // STDOUT
    fd = 2;
    $fclose(fd); // Invalid

    // FD
    fd=32'h80000000;
    $fclose(fd); // STDIN
    fd=32'h80000001;
    $fclose(fd); // STDOUT
    fd=32'h80000002;
    $fclose(fd); // STDERR
    fd=32'h80000003;
    $fclose(fd); // Invalid
  end
endmodule
WARNING: tmp.v:9: could not close MCD STDOUT (0x1) in $fclose().
WARNING: tmp.v:11: invalid MCD (0x2) given to $fclose().
WARNING: tmp.v:15: could not close file descriptor STDIN (0x80000000) in $fclose().
WARNING: tmp.v:17: could not close file descriptor STDOUT (0x80000001) in $fclose().
WARNING: tmp.v:19: could not close file descriptor STDERR (0x80000002) in $fclose().
WARNING: tmp.v:21: invalid file descriptor (0x80000003) given to $fclose().
Cary
   On Sunday, May 17, 2020, 2:18:34 AM PDT, Cary R. via Iverilog-devel <ive...@li...> wrote:  
 
  Thanks Martin,
That is what is currently implemented except for the fclose() failure. At the moment $fclose() is implemented using vpi_mcd_close(), which now returns the failing MCD/FD correctly. One of the fixes I added is if you try to close the preopened descriptors (STDOUT either MCD or FD along with the STDIN or STDERR FDs) it returns them since they were not closed (it's an error). Should we report an error when trying to close these or just when the underlying fclose() fails? My inclination would be report them

The big-3 simulator I use appears to not report any messages when invalid FD/MCDs are used. I guess a place where we can do things better. I get a failing fclose() is fairly benign, but it seems like giving information regarding bugs would be helpful.

Cary
   On Sunday, May 17, 2020, 1:11:27 AM PDT, Martin Whitaker <ic...@ma...> wrote:  
 
 A null MCD (empty set) was accepted by the file I/O tasks in Verilog-XL 
without any warning. I have used that feature in test benches (including 
passing it to $fclose), and would not want a warning.

I'm not against warnings if you pass an invalid FD/MCD to $fclose or 
$fclose fails.

On 17/05/2020 03:38, Cary R. via Iverilog-devel wrote:
>  And on the subject of $fclose() should it print a warning when you try to close one of the preopened MDC/FDs?  Should it print a message if the underlying fclose() fails for some reason? We do cleanup the entry even if it fails so it is no longer available, but vpi_mcd_close() returns the descriptor for any failing items (well it does it correctly now) so we could report underlying issues correctly.
> Cary
> 
>      On Saturday, May 16, 2020, 4:24:29 PM PDT, Cary R. via Iverilog-devel <ive...@li...> wrote:
>  
>  It looks like Icarus along with at least one of the Big-3 simulators allows, without warning, the various file I/O system tasks/functions to accept a NULL (0) file descriptor/MCD. I can see this as helpful if you want to disable output by just setting the FD/MCD to zero, but it could be an issue if the $fopen failed and the user did not check so having a warning would be beneficial for that. We do print a warning for an invalid non-zero FD/MCD.
> 
> So should a zero FD/MCD print a warning or do we just want it to return as if nothing happened?
> I tend to like the warnings, but I'm not certain if there is an easy way to disable MCD output without using the zero value. Should $fclose be handled differently?
> 
> Thoughts/suggestions appreciated.
> 
> Thanks,
> Cary
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>    
> 
> 
> 
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 



_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
  _______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
  

Re: [Iverilog-devel] Verilog execution of always block as multiple events

[Evan L. <sa2...@cy...>]

On 17/05/2020 07:11, Julian Thomas Parkin wrote:
> Thanks for the explanations everyone, very helpful.
> 
> Would I be correct in summarizing this as, the standard doesn't
> strictly require an always block to run uninterrupted until it
> suspends on its own, but there's a lot of inertia behind the
> assumption that it does (an "unwritten rule" as Steve calls it) to
> the point that it's a safe assumption to make when writing Verilog.

Basically, yes, but the unwritten rule is occasionally broken. The
scheduler is event-driven, not pre-emptive; it shouldn't arbitrarily
decide when to transfer control between different processes. But, OTOH,
the LRM does *not* specify atomic execution of code between scheduling
points, and explicitly says in 11.4.1(a) that "Execution of statements
in a particular begin-end block can be suspended in favor of other
processes in the model".

Steven Sharp covered this in comp.lang.verilog at

https://groups.google.com/forum/?hl=en#!topic/comp.lang.verilog/2X9f9ds9XnE

as follows (in other words, this is as Gospel as it gets for Verilog):

"There is the rigamarole about allowing a begin-end to suspend in favor
of executing another process, and then resume later.  If taken to
extremes, this would make the language very hard to use, since many
common practices would become nondeterministic.  This seems to have
been stated partly to allow for simulator optimizations involving
inlining of one process into another.  For example, when an always
block updates a variable, a simulator might immediately update a net
that is assigned from that variable.  This can be viewed as suspending
the always block, executing the continuous assignment, and then
resuming the always block.  But no simulator is going to arbitrarily
suspend one process to execute another, unless there is at least some
kind of event-driven connection between them".

I'm sure this is covered elsewhere in c.l.v, but it's next to useless
now, since Google removed the advanced search.

But not all simulators play ball. See:

https://groups.google.com/forum/#!searchin/comp.lang.verilog/%22STEVEN$20SHARP%22$20scheduler|sort:date/comp.lang.verilog/tK-MpHdfVCE/uGAgIp4BpBIJ

Look up my comment for:

x = add(x, 1);

I found one simulator where this wasn't atomic. This was a long time ago
(2008), and I don't have notes, so I don't know which sim it was.

Re: [Iverilog-devel] Verilog execution of always block as multiple events

[Martin W. <ic...@ma...>]

Steve's point that the time control requires the whole begin...end block 
to be executed as a single event does mean that I am wrong and the vvp 
behaviour is broken. See the second example I gave in

https://github.com/steveicarus/iverilog/issues/321#issuecomment-626305761

If update events are not allowed to be executed during the begin...end 
blocks, the wires should never reflect the glitches.

On 16/05/2020 23:52, Stephen Williams wrote:
> This is an interesting problem, and has come down to an unwritten rule
> that sequential statements are executed without interruption until
> they voluntarily yield by a time or event statement. Many people who
> tried to implement multi-threaded Verilog simulators have discovered
> this assumption the hard way. The problem is that Verilog has no
> thread synchronization primitives other than the time and event
> controls, and so every Verilog programmer has used these controls
> exactly that way. So:
> 
> always @(a or b) begin
>    temp = a & b;
>    c = temp;
> end
> 
> Once this thread is started, it will run, uninterrupted, until it gets
> to the @(...) statement, which yields the CPU.
> 
> Now, it can also be pointed out that this is technically only a single
> statement. The @(a or b)... is a single statement that has as a
> sub-statement a begin..end block. People don't usually think about it
> that way, but it is technically true.
> 
> On Sat, May 16, 2020 at 3:05 PM Julian Thomas Parkin
> <jtp...@uw...> wrote:
>>
>> This isn't an issue with iverilog, but I have a question about the
>> execution semantics of Verilog. There isn't much information online
>> and a lot of it points to this mailing list
>> (e.g. https://sourceforge.net/p/iverilog/mailman/message/36358575/)
>> so I'm hoping it's alright if I ask here.
>>
>> In 1364-2005, section 11.4.2 includes the following sentence (which
>> is also present in SystemVerilog): "Another source of nondeterminism
>> is that statements without time-control constructs in behavioral
>> blocks do not have to be executed as one event."
>>
>> As an example, it presents the following:
>>
>>    assign p = q;
>>    initial begin
>>        q = 1;
>>        #1 q = 0;
>>        $display(p);
>>    end
>>
>> The simulator is allowed to process the "q = 0" assignment, then
>> suspend execution in favour of updating p, and then display p as 0.
>>
>> Does this also apply to the typical style of always process used
>> to express combinatorial circuits ?
>>
>> For example, if someone were to implement an and gate using a
>> temporary variable:
>>
>>    always @(a or b) begin
>>        temp = a & b;
>>        c = temp;
>>    end
>>
>> Say a and b both have pending update events. Could the simulator
>> update a, see that the always has been activated, execute
>> "temp = a | b;", then suspend execution to update b ? At which
>> point the always block is not sensitive to changes because it is
>> still being executed, so it ends up missing the second update even
>> though b is in the sensitivity list.
>>
>> Is this valid behavior according to the standard ? Or does
>> "statements without time-control constructs" apply to the
>> "begin end" block as a whole and prevent it from being executed as
>> multiple events because it does have a time-control ? If this is
>> valid, do iverilog or other simulators ever behave in this manner ?
>>
>>
>> Thanks,
>>
>> -Julian
>>
>>
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 
> 
> 

Re: [Iverilog-devel] NULL file descriptor or MCD

[Cary R. <cy...@ya...>]

 Thanks Martin,
That is what is currently implemented except for the fclose() failure. At the moment $fclose() is implemented using vpi_mcd_close(), which now returns the failing MCD/FD correctly. One of the fixes I added is if you try to close the preopened descriptors (STDOUT either MCD or FD along with the STDIN or STDERR FDs) it returns them since they were not closed (it's an error). Should we report an error when trying to close these or just when the underlying fclose() fails? My inclination would be report them

The big-3 simulator I use appears to not report any messages when invalid FD/MCDs are used. I guess a place where we can do things better. I get a failing fclose() is fairly benign, but it seems like giving information regarding bugs would be helpful.

Cary
   On Sunday, May 17, 2020, 1:11:27 AM PDT, Martin Whitaker <ic...@ma...> wrote:  
 
 A null MCD (empty set) was accepted by the file I/O tasks in Verilog-XL 
without any warning. I have used that feature in test benches (including 
passing it to $fclose), and would not want a warning.

I'm not against warnings if you pass an invalid FD/MCD to $fclose or 
$fclose fails.

On 17/05/2020 03:38, Cary R. via Iverilog-devel wrote:
>  And on the subject of $fclose() should it print a warning when you try to close one of the preopened MDC/FDs?  Should it print a message if the underlying fclose() fails for some reason? We do cleanup the entry even if it fails so it is no longer available, but vpi_mcd_close() returns the descriptor for any failing items (well it does it correctly now) so we could report underlying issues correctly.
> Cary
> 
>      On Saturday, May 16, 2020, 4:24:29 PM PDT, Cary R. via Iverilog-devel <ive...@li...> wrote:
>  
>  It looks like Icarus along with at least one of the Big-3 simulators allows, without warning, the various file I/O system tasks/functions to accept a NULL (0) file descriptor/MCD. I can see this as helpful if you want to disable output by just setting the FD/MCD to zero, but it could be an issue if the $fopen failed and the user did not check so having a warning would be beneficial for that. We do print a warning for an invalid non-zero FD/MCD.
> 
> So should a zero FD/MCD print a warning or do we just want it to return as if nothing happened?
> I tend to like the warnings, but I'm not certain if there is an easy way to disable MCD output without using the zero value. Should $fclose be handled differently?
> 
> Thoughts/suggestions appreciated.
> 
> Thanks,
> Cary
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>    
> 
> 
> 
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 



_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
  

Re: [Iverilog-devel] NULL file descriptor or MCD

[Martin W. <ic...@ma...>]

A null MCD (empty set) was accepted by the file I/O tasks in Verilog-XL 
without any warning. I have used that feature in test benches (including 
passing it to $fclose), and would not want a warning.

I'm not against warnings if you pass an invalid FD/MCD to $fclose or 
$fclose fails.

On 17/05/2020 03:38, Cary R. via Iverilog-devel wrote:
>   And on the subject of $fclose() should it print a warning when you try to close one of the preopened MDC/FDs?  Should it print a message if the underlying fclose() fails for some reason? We do cleanup the entry even if it fails so it is no longer available, but vpi_mcd_close() returns the descriptor for any failing items (well it does it correctly now) so we could report underlying issues correctly.
> Cary
> 
>      On Saturday, May 16, 2020, 4:24:29 PM PDT, Cary R. via Iverilog-devel <ive...@li...> wrote:
>   
>   It looks like Icarus along with at least one of the Big-3 simulators allows, without warning, the various file I/O system tasks/functions to accept a NULL (0) file descriptor/MCD. I can see this as helpful if you want to disable output by just setting the FD/MCD to zero, but it could be an issue if the $fopen failed and the user did not check so having a warning would be beneficial for that. We do print a warning for an invalid non-zero FD/MCD.
> 
> So should a zero FD/MCD print a warning or do we just want it to return as if nothing happened?
> I tend to like the warnings, but I'm not certain if there is an easy way to disable MCD output without using the zero value. Should $fclose be handled differently?
> 
> Thoughts/suggestions appreciated.
> 
> Thanks,
> Cary
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>    
> 
> 
> 
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> 

Re: [Iverilog-devel] Verilog execution of always block as multiple events

[Julian T. P. <jtp...@uw...>]

Thanks for the explanations everyone, very helpful.

Would I be correct in summarizing this as, the standard doesn't
strictly require an always block to run uninterrupted until it
suspends on its own, but there's a lot of inertia behind the
assumption that it does (an "unwritten rule" as Steve calls it) to
the point that it's a safe assumption to make when writing Verilog.


-Julian

________________________________
From: Julian Thomas Parkin <jtp...@uw...>
Sent: Saturday, May 16, 2020 4:55 PM
To: ive...@li... <ive...@li...>
Subject: [Iverilog-devel] Verilog execution of always block as multiple events

This isn't an issue with iverilog, but I have a question about the
execution semantics of Verilog. There isn't much information online
and a lot of it points to this mailing list
(e.g. https://sourceforge.net/p/iverilog/mailman/message/36358575/)
so I'm hoping it's alright if I ask here.

In 1364-2005, section 11.4.2 includes the following sentence (which
is also present in SystemVerilog): "Another source of nondeterminism
is that statements without time-control constructs in behavioral
blocks do not have to be executed as one event."

As an example, it presents the following:

  assign p = q;
  initial begin
      q = 1;
      #1 q = 0;
      $display(p);
  end

The simulator is allowed to process the "q = 0" assignment, then
suspend execution in favour of updating p, and then display p as 0.

Does this also apply to the typical style of always process used
to express combinatorial circuits ?

For example, if someone were to implement an and gate using a
temporary variable:

  always @(a or b) begin
      temp = a & b;
      c = temp;
  end

Say a and b both have pending update events. Could the simulator
update a, see that the always has been activated, execute
"temp = a | b;", then suspend execution to update b ? At which
point the always block is not sensitive to changes because it is
still being executed, so it ends up missing the second update even
though b is in the sensitivity list.

Is this valid behavior according to the standard ? Or does
"statements without time-control constructs" apply to the
"begin end" block as a whole and prevent it from being executed as
multiple events because it does have a time-control ? If this is
valid, do iverilog or other simulators ever behave in this manner ?


Thanks,

-Julian


_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel

Re: [Iverilog-devel] NULL file descriptor or MCD

[Cary R. <cy...@ya...>]

 And on the subject of $fclose() should it print a warning when you try to close one of the preopened MDC/FDs?  Should it print a message if the underlying fclose() fails for some reason? We do cleanup the entry even if it fails so it is no longer available, but vpi_mcd_close() returns the descriptor for any failing items (well it does it correctly now) so we could report underlying issues correctly.
Cary

    On Saturday, May 16, 2020, 4:24:29 PM PDT, Cary R. via Iverilog-devel <ive...@li...> wrote:  
 
 It looks like Icarus along with at least one of the Big-3 simulators allows, without warning, the various file I/O system tasks/functions to accept a NULL (0) file descriptor/MCD. I can see this as helpful if you want to disable output by just setting the FD/MCD to zero, but it could be an issue if the $fopen failed and the user did not check so having a warning would be beneficial for that. We do print a warning for an invalid non-zero FD/MCD.

So should a zero FD/MCD print a warning or do we just want it to return as if nothing happened?
I tend to like the warnings, but I'm not certain if there is an easy way to disable MCD output without using the zero value. Should $fclose be handled differently?

Thoughts/suggestions appreciated.

Thanks,
Cary
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
  

[Iverilog-devel] NULL file descriptor or MCD

[Cary R. <cy...@ya...>]

It looks like Icarus along with at least one of the Big-3 simulators allows, without warning, the various file I/O system tasks/functions to accept a NULL (0) file descriptor/MCD. I can see this as helpful if you want to disable output by just setting the FD/MCD to zero, but it could be an issue if the $fopen failed and the user did not check so having a warning would be beneficial for that. We do print a warning for an invalid non-zero FD/MCD.

So should a zero FD/MCD print a warning or do we just want it to return as if nothing happened?
I tend to like the warnings, but I'm not certain if there is an easy way to disable MCD output without using the zero value. Should $fclose be handled differently?

Thoughts/suggestions appreciated.

Thanks,
Cary