iverilog-devel

[Iverilog-devel] System verilog support in Icarus

[Krishnaraj B. <kri...@gm...>]

Hello,

I am using Icarus tool for  simulating the verilog models.

I have a question regarding Icarus tool. Now I am working on System verilog
and want to simulate the system verilog models. I have
 downloaded latest version v.10.1 of Icarus tool. Built it and installed it
in my system. Tried to compile a simple up-counter system Verilog module.
But compilation fails. Below is the command I have used to compile the
module.

iverilog -g2005-sv xxxx.sv.

I have even tried with the -g2012 flag. But the result is same. As per my
limited knowledge (based on google search) Icarus supports system verilog.
But I want to confirm about this in this forum. Could you please let me
know whether the latest version (10.1) supports system verilog? If so, what
might be the  reason for compilation error of the attached system verilog
module.

Thank you in advance,
Krishnaraj Bhat

Re: [Iverilog-devel] System verilog support in Icarus

[Larry D. <ldo...@re...>]

Krishnaraj -

On Wed, Mar 23, 2016 at 01:56:02PM +0530, Krishnaraj Bhat wrote:
> Tried to compile a simple up-counter system Verilog module.
> But compilation fails.
> Could you please let me
> know whether the latest version (10.1) supports system verilog?

I'm not a SystemVerilog language laywer.  I suspect the literal answer
is "no", there are odd corners of the language that don't work in
iverilog.  Practically, it's supposed to be usable now.

I don't know why you think you can use non-blocking assignment to
a wire, or what "always_ff" is supposed to mean.  But the following
module compiles just fine under Icarus.  There are no SystemVerilog
language features used here, just ordinary Verilog.

module up_counter (
  output reg [7:0] out,
  input  wire      enable,
  input  wire      clk,
  input  wire      reset    
);
always @(posedge clk)
  if (reset) begin 
    out <= 8'b0;
  end else if (enable) begin
    out ++;
  end
endmodule

   - Larry

Re: [Iverilog-devel] System verilog support in Icarus

[Corey O. <cor...@gm...>]

Correct me if I'm wrong, but I believe the 'out ++' portion is not standard
Verilog.  Therefore it sounds like some SystemVerilog constructs are
supported by Icarus and some are not.  Is there a list anywhere of the
things that are supported?

-Corey

On Wed, Mar 23, 2016 at 1:34 PM, Larry Doolittle <ldo...@re...>
wrote:

> Krishnaraj -
>
> On Wed, Mar 23, 2016 at 01:56:02PM +0530, Krishnaraj Bhat wrote:
> > Tried to compile a simple up-counter system Verilog module.
> > But compilation fails.
> > Could you please let me
> > know whether the latest version (10.1) supports system verilog?
>
> I'm not a SystemVerilog language laywer.  I suspect the literal answer
> is "no", there are odd corners of the language that don't work in
> iverilog.  Practically, it's supposed to be usable now.
>
> I don't know why you think you can use non-blocking assignment to
> a wire, or what "always_ff" is supposed to mean.  But the following
> module compiles just fine under Icarus.  There are no SystemVerilog
> language features used here, just ordinary Verilog.
>
> module up_counter (
>   output reg [7:0] out,
>   input  wire      enable,
>   input  wire      clk,
>   input  wire      reset
> );
> always @(posedge clk)
>   if (reset) begin
>     out <= 8'b0;
>   end else if (enable) begin
>     out ++;
>   end
> endmodule
>
>    - Larry
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

Re: [Iverilog-devel] System verilog support in Icarus

[Jonathan D. <jb_...@ya...>]

I'm not sure about what features are and are not supported, but I believe that the 1800-2012 standard is available for free through the ieee, thanks to an Accelera program. For those of you who are not aware what always_ff or always_comb etc are supposed to do.I would expect that the module level  features (ie RTL features like these ) would be farther along than the class and package related features. But I haven't installed icarus for a while, so can't really comment on the present state.Jonathan 

Sent from Yahoo Mail on Android 
 
  On Wed, Mar 23, 2016 at 12:37 PM, Corey Olson<cor...@gm...> wrote:   Correct me if I'm wrong, but I believe the 'out ++' portion is not standard Verilog.  Therefore it sounds like some SystemVerilog constructs are supported by Icarus and some are not.  Is there a list anywhere of the things that are supported?

-Corey
On Wed, Mar 23, 2016 at 1:34 PM, Larry Doolittle <ldo...@re...> wrote:

Krishnaraj -

On Wed, Mar 23, 2016 at 01:56:02PM +0530, Krishnaraj Bhat wrote:
> Tried to compile a simple up-counter system Verilog module.
> But compilation fails.
> Could you please let me
> know whether the latest version (10.1) supports system verilog?

I'm not a SystemVerilog language laywer.  I suspect the literal answer
is "no", there are odd corners of the language that don't work in
iverilog.  Practically, it's supposed to be usable now.

I don't know why you think you can use non-blocking assignment to
a wire, or what "always_ff" is supposed to mean.  But the following
module compiles just fine under Icarus.  There are no SystemVerilog
language features used here, just ordinary Verilog.

module up_counter (
  output reg [7:0] out,
  input  wire      enable,
  input  wire      clk,
  input  wire      reset
);
always @(posedge clk)
  if (reset) begin
    out <= 8'b0;
  end else if (enable) begin
    out ++;
  end
endmodule

   - Larry

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel


------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
  

Re: [Iverilog-devel] System verilog support in Icarus

[Iztok J. <izt...@gm...>]

A few comments regarding the provided source.
1. I usually use logic for all signals in RTL code, I use wire only for
tristate signals
2. for coding registers always_ff is great, but the 'out' signal should not
be a wire, it should be logic/reg (this two are the same in SystemVerilog)
3. the out++ syntax is not appropriate for RTL, since it is not clear if
the assignment is blocking or not. I usually use ++ in bench code, inside
initial statements or for loops

Icarus has only a partial SystemVerilog support, not even all RTL features
are supported. In case somebody would like to create a table of supported
features, I am wiling to help with code examples, unit tests, with the
focus on RTL features.

Regards,
Iztok Jeras

On Wed, Mar 23, 2016 at 8:37 PM, Corey Olson <cor...@gm...> wrote:

> Correct me if I'm wrong, but I believe the 'out ++' portion is not
> standard Verilog.  Therefore it sounds like some SystemVerilog constructs
> are supported by Icarus and some are not.  Is there a list anywhere of the
> things that are supported?
>
> -Corey
>
> On Wed, Mar 23, 2016 at 1:34 PM, Larry Doolittle <ldo...@re...
> > wrote:
>
>> Krishnaraj -
>>
>> On Wed, Mar 23, 2016 at 01:56:02PM +0530, Krishnaraj Bhat wrote:
>> > Tried to compile a simple up-counter system Verilog module.
>> > But compilation fails.
>> > Could you please let me
>> > know whether the latest version (10.1) supports system verilog?
>>
>> I'm not a SystemVerilog language laywer.  I suspect the literal answer
>> is "no", there are odd corners of the language that don't work in
>> iverilog.  Practically, it's supposed to be usable now.
>>
>> I don't know why you think you can use non-blocking assignment to
>> a wire, or what "always_ff" is supposed to mean.  But the following
>> module compiles just fine under Icarus.  There are no SystemVerilog
>> language features used here, just ordinary Verilog.
>>
>> module up_counter (
>>   output reg [7:0] out,
>>   input  wire      enable,
>>   input  wire      clk,
>>   input  wire      reset
>> );
>> always @(posedge clk)
>>   if (reset) begin
>>     out <= 8'b0;
>>   end else if (enable) begin
>>     out ++;
>>   end
>> endmodule
>>
>>    - Larry
>>
>>
>> ------------------------------------------------------------------------------
>> Transform Data into Opportunity.
>> Accelerate data analysis in your applications with
>> Intel Data Analytics Acceleration Library.
>> Click to learn more.
>> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
>> _______________________________________________
>> Iverilog-devel mailing list
>> Ive...@li...
>> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>

Re: [Iverilog-devel] System verilog support in Icarus

[Larry D. <ldo...@re...>]

Friends -

On Wed, Mar 23, 2016 at 09:23:41PM +0000, Jonathan David wrote:
> I would expect that the module level  features (ie RTL features like these ) would be farther along than the class and package related features. But I haven't installed icarus for a while, so can't really comment on the present state.

I looked up what the state of always_ff, always_latch, and always_comb
are in Icarus git master.

They are present and accounted for as language-level-specific keywords
in lexor_keyword.gperf and parse.y.  But parse.y never uses them in
in the grammar.

Adding them to the grammar would be easy -- even I could do that.
But then Icarus would need new enum values for ivl_process_type_e,
and handle their semantics correctly.  This has to be done without
breaking the old "always" semantics.

Good thing we have ivtest!

  - Larry

Re: [Iverilog-devel] System verilog support in Icarus

[Alan M. G. <alm...@gm...>]

On Thu, Mar 24, 2016 at 5:44 AM, Larry Doolittle <ldo...@re...>
wrote:

> Friends -
>
> On Wed, Mar 23, 2016 at 09:23:41PM +0000, Jonathan David wrote:
> > I would expect that the module level  features (ie RTL features like
> these ) would be farther along than the class and package related
> features. But I haven't installed icarus for a while, so can't really
> comment on the present state.
>
> I looked up what the state of always_ff, always_latch, and always_comb
> are in Icarus git master.
>
> They are present and accounted for as language-level-specific keywords
> in lexor_keyword.gperf and parse.y.  But parse.y never uses them in
> in the grammar.
>
> Adding them to the grammar would be easy -- even I could do that.
> But then Icarus would need new enum values for ivl_process_type_e,
> and handle their semantics correctly.  This has to be done without
> breaking the old "always" semantics.
>

In particular, always_comb is not precisely the same as always@*;
always_comb executes its contents at startup immediately, then blocks on
sensitivity list.  So instead of always@* begin foo; bar; end, it's more
like always begin foo; bar; @*; end  This hack is because constant wires
and parameters might not trigger @*, leading to an RTL-vs-gate mismatch
during simulation startup if you use always@*.

As I understand it, always_ff and always_latch behave exactly the same as
always, but an implementation is supposed to warn if it will not be
inferred as a ff or latch.  Whether actual tools actually warn, and whether
those warnings will get glossed over in practice when you're synthesizing a
100k gate product with not the best coding style, is a separate question.
Personally,  I'd prefer a flag somewhere that indicates that an
always_ff/always_latch not being inferrable to ff/latch should be thrown as
an error rather than a warning.


>
> Good thing we have ivtest!
>
>   - Larry
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

Re: [Iverilog-devel] System verilog support in Icarus

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

Alan Manuel Gloria wrote:
> In particular, always_comb is not precisely the same as always@*;
> always_comb executes its contents at startup immediately, then blocks on
> sensitivity list.  So instead of always@* begin foo; bar; end, it's more
> like always begin foo; bar; @*; end  This hack is because constant wires
> and parameters might not trigger @*, leading to an RTL-vs-gate mismatch
> during simulation startup if you use always@*.

That's not too hard to implement. What will take more work will be the differences in the implied 
sensitivity list - in particular the sensitivity to the contents of called functions. Then there's 
the additional checks for delays and multiple assignments...

Martin

Re: [Iverilog-devel] System verilog support in Icarus

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

For the scheduling part, there is an internal attribute that elaboration
can attach to the process (the NetProc instance?) to adjust scheduling
at startup. That would probably be the best way to handle it.

On 4/8/16 1:09 AM, Martin Whitaker wrote:
> Alan Manuel Gloria wrote:
>> In particular, always_comb is not precisely the same as always@*;
>> always_comb executes its contents at startup immediately, then blocks on
>> sensitivity list.  So instead of always@* begin foo; bar; end, it's more
>> like always begin foo; bar; @*; end  This hack is because constant wires
>> and parameters might not trigger @*, leading to an RTL-vs-gate mismatch
>> during simulation startup if you use always@*.
>
> That's not too hard to implement. What will take more work will be the differences in the implied
> sensitivity list - in particular the sensitivity to the contents of called functions. Then there's
> the additional checks for delays and multiple assignments...
>
> Martin
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>

-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           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] System verilog support in Icarus

[<ni...@ly...>]

Stephen Williams <st...@ic...> writes:

> For the scheduling part, there is an internal attribute that elaboration
> can attach to the process (the NetProc instance?) to adjust scheduling
> at startup. That would probably be the best way to handle it.

This is from a thread on support for always_comb and always_ff, one and
a half year ago. When I pulled today, I noticed

commit 585a0232cbd54e20d1dc41d2cb7712e18784bb8d
Author: Cary R <cy...@ya...>
Date:   Mon Nov 20 07:48:35 2017 -0800

    Add preliminary support for always_comb, always_ff and always_latch

Can you say something more about status and plans?

Being able to use these (and getting clear and reliable errors for
incorrect usage) would help me write less buggy code, as I try to
use separate processes for combinational and stateful logic. So I'm
really happy for progress on this front.

Best regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.

Re: [Iverilog-devel] System verilog support in Icarus

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

Niels Möller wrote:
> Stephen Williams <st...@ic...> writes:
>
>> For the scheduling part, there is an internal attribute that elaboration
>> can attach to the process (the NetProc instance?) to adjust scheduling
>> at startup. That would probably be the best way to handle it.
>
> This is from a thread on support for always_comb and always_ff, one and
> a half year ago. When I pulled today, I noticed
>
> commit 585a0232cbd54e20d1dc41d2cb7712e18784bb8d
> Author: Cary R <cy...@ya...>
> Date:   Mon Nov 20 07:48:35 2017 -0800
>
>     Add preliminary support for always_comb, always_ff and always_latch
>
> Can you say something more about status and plans?

Did you not see Cary's announcement about this (3 days ago)?

If not, see the mailing list archive:

https://sourceforge.net/p/iverilog/mailman/iverilog-devel/?viewmonth=201711

Re: [Iverilog-devel] System verilog support in Icarus

[<ni...@ly...>]

Martin Whitaker <ic...@ma...> writes:

> Did you not see Cary's announcement about this (3 days ago)?
>
> If not, see the mailing list archive:
>
> https://sourceforge.net/p/iverilog/mailman/iverilog-devel/?viewmonth=201711

Thanks for the pointer. And no, I didn't see it. It seems I was somehow
kicked out from the list a few months ago and I haven't received list
mail since April 23 (and I've not had any reason to post, either). First
attempt at sending this question, a few days ago, failed with a
non-member bounce, and I had to resubscribe.

I'm reading Cary's announcement as good progress, but not yet quite
useful for my purposes. And I totally agree it makes sense to have
correctness for valid code as the top priority, even if my main interest
is in stricter compile-time checks for incorrect code.

Thanks a lot,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.

Re: [Iverilog-devel] System verilog support in Icarus

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

Niels Möller wrote:
> Martin Whitaker <ic...@ma...> writes:
>
>> Did you not see Cary's announcement about this (3 days ago)?
>>
>> If not, see the mailing list archive:
>>
>> https://sourceforge.net/p/iverilog/mailman/iverilog-devel/?viewmonth=201711
>
> Thanks for the pointer. And no, I didn't see it. It seems I was somehow
> kicked out from the list a few months ago and I haven't received list
> mail since April 23 (and I've not had any reason to post, either). First
> attempt at sending this question, a few days ago, failed with a
> non-member bounce, and I had to resubscribe.

I had similar problems. And the lack of response to my recent posts makes 
me wonder how many others we've lost...

> I'm reading Cary's announcement as good progress, but not yet quite
> useful for my purposes. And I totally agree it makes sense to have
> correctness for valid code as the top priority, even if my main interest
> is in stricter compile-time checks for incorrect code.

The checks are likely to be more tricky. At the moment the compiler 
calculates sensitivities down to the individual variable level, but to 
correctly implement the checks you need to know the sensitivities down to 
the individual bit level. The synthesis code in the compiler has the same 
problem when it is trying to detect latches.

Martin

Re: [Iverilog-devel] System verilog support in Icarus

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

My goal is to work on the shall (required) parts and work on the more user friendly (should) parts if they are not too complicated.Support for the T0 trigger for always_comb/latch has been added as the first event in the inactive region. Support for converting this to vlog95 has also been added.
Cary
 

    On Friday, November 24, 2017, 4:07:19 AM PST, Martin Whitaker <ic...@ma...> wrote:  
 
 Niels Möller wrote:
> Martin Whitaker <ic...@ma...> writes:
>
>> Did you not see Cary's announcement about this (3 days ago)?
>>
>> If not, see the mailing list archive:
>>
>> https://sourceforge.net/p/iverilog/mailman/iverilog-devel/?viewmonth=201711
>
> Thanks for the pointer. And no, I didn't see it. It seems I was somehow
> kicked out from the list a few months ago and I haven't received list
> mail since April 23 (and I've not had any reason to post, either). First
> attempt at sending this question, a few days ago, failed with a
> non-member bounce, and I had to resubscribe.

I had similar problems. And the lack of response to my recent posts makes 
me wonder how many others we've lost...

> I'm reading Cary's announcement as good progress, but not yet quite
> useful for my purposes. And I totally agree it makes sense to have
> correctness for valid code as the top priority, even if my main interest
> is in stricter compile-time checks for incorrect code.

The checks are likely to be more tricky. At the moment the compiler 
calculates sensitivities down to the individual variable level, but to 
correctly implement the checks you need to know the sensitivities down to 
the individual bit level. The synthesis code in the compiler has the same 
problem when it is trying to detect latches.

Martin

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
  

Re: [Iverilog-devel] System verilog support in Icarus

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

 I have committed more basic synthesis construct checking for the always_* processes and a number of other fixes. The big remaining items are checking that L-values are assigned correctly and that the blocks have the correct constructs for the block type (synthesize correctly). I have a few more cleanup issues that I need to take care of and then I plan to look at the L-value checking. I would be interested in knowing if the latest checks match what people are expecting. At the moment there is not a disable for these, but that could easily be added. The question is at what granularity should they be disabled if this is needed?

Cary

    On Sunday, December 3, 2017, 8:35:16 PM PST, Cary R. via Iverilog-devel <ive...@li...> wrote:  
 
 My goal is to work on the shall (required) parts and work on the more user friendly (should) parts if they are not too complicated.Support for the T0 trigger for always_comb/latch has been added as the first event in the inactive region. Support for converting this to vlog95 has also been added.
Cary
 

    On Friday, November 24, 2017, 4:07:19 AM PST, Martin Whitaker <ic...@ma...> wrote:  
 
 Niels Möller wrote:
> Martin Whitaker <ic...@ma...> writes:
>
>> Did you not see Cary's announcement about this (3 days ago)?
>>
>> If not, see the mailing list archive:
>>
>> https://sourceforge.net/p/iverilog/mailman/iverilog-devel/?viewmonth=201711
>
> Thanks for the pointer. And no, I didn't see it. It seems I was somehow
> kicked out from the list a few months ago and I haven't received list
> mail since April 23 (and I've not had any reason to post, either). First
> attempt at sending this question, a few days ago, failed with a
> non-member bounce, and I had to resubscribe.

I had similar problems. And the lack of response to my recent posts makes 
me wonder how many others we've lost...

> I'm reading Cary's announcement as good progress, but not yet quite
> useful for my purposes. And I totally agree it makes sense to have
> correctness for valid code as the top priority, even if my main interest
> is in stricter compile-time checks for incorrect code.

The checks are likely to be more tricky. At the moment the compiler 
calculates sensitivities down to the individual variable level, but to 
correctly implement the checks you need to know the sensitivities down to 
the individual bit level. The synthesis code in the compiler has the same 
problem when it is trying to detect latches.

Martin

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
  ------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
  

Re: [Iverilog-devel] System verilog support in Icarus

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

 A quick question on the following from 1800-2012 page 171.
    Variables on the left-hand side of assignments within an always_comb procedure, including vari-
    ables from the contents of a called function, shall not be written to by any other processes
Does this apply to procedural continuous assignments (force/assign) statements? Basically is the following an error?

module top;  reg a;
  reg test;  initial begin    a = 1'b0;    force test = 1'b1;
  end  always_comb    test = a;
endmodule
I would expect procedural force/assign statements to be okay since they are used to patch/override logic.
Cary
    On Wednesday, December 27, 2017, 3:15:38 PM PST, Cary R. via Iverilog-devel <ive...@li...> wrote:  
 
  I have committed more basic synthesis construct checking for the always_* processes and a number of other fixes. The big remaining items are checking that L-values are assigned correctly and that the blocks have the correct constructs for the block type (synthesize correctly). I have a few more cleanup issues that I need to take care of and then I plan to look at the L-value checking. I would be interested in knowing if the latest checks match what people are expecting. At the moment there is not a disable for these, but that could easily be added. The question is at what granularity should they be disabled if this is needed?

Cary

    On Sunday, December 3, 2017, 8:35:16 PM PST, Cary R. via Iverilog-devel <ive...@li...> wrote:  
 
 My goal is to work on the shall (required) parts and work on the more user friendly (should) parts if they are not too complicated.Support for the T0 trigger for always_comb/latch has been added as the first event in the inactive region. Support for converting this to vlog95 has also been added.
Cary
 

    On Friday, November 24, 2017, 4:07:19 AM PST, Martin Whitaker <ic...@ma...> wrote:  
 
 Niels Möller wrote:
> Martin Whitaker <ic...@ma...> writes:
>
>> Did you not see Cary's announcement about this (3 days ago)?
>>
>> If not, see the mailing list archive:
>>
>> https://sourceforge.net/p/iverilog/mailman/iverilog-devel/?viewmonth=201711
>
> Thanks for the pointer. And no, I didn't see it. It seems I was somehow
> kicked out from the list a few months ago and I haven't received list
> mail since April 23 (and I've not had any reason to post, either). First
> attempt at sending this question, a few days ago, failed with a
> non-member bounce, and I had to resubscribe.

I had similar problems. And the lack of response to my recent posts makes 
me wonder how many others we've lost...

> I'm reading Cary's announcement as good progress, but not yet quite
> useful for my purposes. And I totally agree it makes sense to have
> correctness for valid code as the top priority, even if my main interest
> is in stricter compile-time checks for incorrect code.

The checks are likely to be more tricky. At the moment the compiler 
calculates sensitivities down to the individual variable level, but to 
correctly implement the checks you need to know the sensitivities down to 
the individual bit level. The synthesis code in the compiler has the same 
problem when it is trying to detect latches.

Martin

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
  ------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
  ------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel