iverilog-devel — Conversations on matters of Icarus Verilog development

Re: [Iverilog-devel] MinGW builds

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

Cary R. wrote:
> Martin,
> I tried cross compiling under cygwin using the i686-w64-mingw32 compilers and I get the following when trying to run make check:
> ./vvp -M../vpi ../../iverilog/vvp/examples/hello.vvp | grep 'Hello, World.'
> system:`../vpi\system.vpi' failed to open using dlopen() because:
>      The specified module could not be found.
> .
> N/A:0: Error: System task/function $display() is not defined by any module.
> It looks like the old mingw32 may have translated / to \ in the dlopen() routine or maybe it is some other problem. To avoid too many cooks in the kitchen I'll let you look at this until told otherwise.

It's working OK on my msys2 builds, so I suspect it's a configuration problem. 
I know when I last tried to cross-compile Icarus, I had to patch a few things 
to get it to work.

Martin

Re: [Iverilog-devel] MinGW builds

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I cross compile for my day job. It's to the point where I don't
even have Windows native makefiles for the (precious few) Windows
binaries that I make. Seems to work fine.

On 05/05/2015 12:57 AM, Martin Whitaker wrote:
> ni...@ly... (Niels Möller) wrote:
>> Have you looked into cross-compiling? In other projects, I do
>> windows builds by something like
>> 
>> sudo apt-get install mingw-w64 wine ./configure
>> --host=x86_64-w64-mingw32 make make check TEST_ENVIRONMENT=wine
>> 
>> Not a perfect substitute for native testing, of course, but it
>> makes it possible to do some testing without having to mess with
>> a real MS windows installation.
>> 
> I use cross-compiling for another project (and have become
> sufficiently confident with it that I just send the binaries off to
> the people who need them). I'd not thought of using wine to test.
> 
> MSYS2 makes the native build and test a lot easier than it used to
> be.
> 
> Martin
> 
> ------------------------------------------------------------------------------
>
> 
One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications 
> Performance metrics, stats and reports that give you Actionable
> Insights Deep dive visibility with transaction tracing using APM
> Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y 
> _______________________________________________ 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."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlVI3RIACgkQrPt1Sc2b3iluQwCfZdw6mSxdabjWhdhhczGfZ6hV
sOQAoI9KKUBrCrdrdkmGVhtYkCdpfMEd
=k0bb
-----END PGP SIGNATURE-----

[Iverilog-devel] Fwd: [iverilog] Add travis-ci integration (#66)

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anybody have opinions on this? Does it make sense to add these sorts
of files to the iverilog repository?


- -------- Forwarded Message --------
Subject: 	[iverilog] Add travis-ci integration (#66)
Date: 	Tue, 05 May 2015 08:00:52 -0700
From: 	Tomasz Hemperek <not...@gi...>
Reply-To: 	steveicarus/iverilog
<rep...@re...>
To: 	steveicarus/iverilog <ive...@no...>
CC: 	Stephen Williams <st...@ic...>



themperek wants to merge 1 commit into steveicarus:master from
themperek:master:

This will add a simple configuration file for free continuous
integration service https://travis-ci.org.
It will build and run the ivtest on every commit on Ubuntu 12.04. It
integrates with github and also builds all pull requests giving a status.

It has to be enabled by @steveicarus <https://github.com/steveicarus>
see: http://docs.travis-ci.com/user/getting-started/#Step-one%3A-Sign-in

To get proper status for ivtest one need to add exit 0/1 to vhdl_reg.pl
so travis knows if it passes or not.

Suggestion:
It is maybe easier to keep it clean when ivtest is part of iverilog
repository.

Best Regards,
Tomasz

- ------------------------------------------------------------------------


        You can view, comment on, or merge this pull request online at:

  https://github.com/steveicarus/iverilog/pull/66


        Commit Summary

  * Add .travis.yml


        File Changes

  * *A* .travis.yml
    <https://github.com/steveicarus/iverilog/pull/66/files#diff-0> (24)


        Patch Links:

  * https://github.com/steveicarus/iverilog/pull/66.patch
  * https://github.com/steveicarus/iverilog/pull/66.diff

—
Reply to this email directly or view it on GitHub
<https://github.com/steveicarus/iverilog/pull/66>.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlVI3AMACgkQrPt1Sc2b3imVKgCgry66rLuaw1iGeBROTaETgUtv
+HoAn3HJw/PUCiSsZl50cvUmPXlmow6P
=7wMX
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] MinGW builds

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

ni...@ly... (Niels Möller) wrote:
> Have you looked into cross-compiling? In other projects, I do windows
> builds by something like
>
>    sudo apt-get install mingw-w64 wine
>    ./configure --host=x86_64-w64-mingw32
>    make
>    make check TEST_ENVIRONMENT=wine
>
> Not a perfect substitute for native testing, of course, but it makes it
> possible to do some testing without having to mess with a real MS
> windows installation.
>
I use cross-compiling for another project (and have become sufficiently 
confident with it that I just send the binaries off to the people who need 
them). I'd not thought of using wine to test.

MSYS2 makes the native build and test a lot easier than it used to be.

Martin

Re: [Iverilog-devel] MinGW builds

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

Martin,
I tried cross compiling under cygwin using the i686-w64-mingw32 compilers and I get the following when trying to run make check:
./vvp -M../vpi ../../iverilog/vvp/examples/hello.vvp | grep 'Hello, World.'
system:`../vpi\system.vpi' failed to open using dlopen() because:
    The specified module could not be found.
.
N/A:0: Error: System task/function $display() is not defined by any module.
It looks like the old mingw32 may have translated / to \ in the dlopen() routine or maybe it is some other problem. To avoid too many cooks in the kitchen I'll let you look at this until told otherwise.
Cary

Re: [Iverilog-devel] MinGW builds

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

Martin,
I see no problem with switching if we update the wiki regarding how to build under windows, though we should coordinate with Pablo who has been providing a windows binary to make sure he does not have any objections.

Cary
 


     On Sunday, May 3, 2015 11:58 PM, Niels Möller <ni...@ly...> wrote:
   

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

> Note that I don't generally use Windows myself, so I'm looking to minimise the 
> time I have to spend on maintaining the Windows builds.

Have you looked into cross-compiling? In other projects, I do windows
builds by something like

  sudo apt-get install mingw-w64 wine
  ./configure --host=x86_64-w64-mingw32
  make
  make check TEST_ENVIRONMENT=wine

Not a perfect substitute for native testing, of course, but it makes it
possible to do some testing without having to mess with a real MS
windows installation.

Regards,
/Niels

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

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel

  

Re: [Iverilog-devel] MinGW builds

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

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

> Note that I don't generally use Windows myself, so I'm looking to minimise the 
> time I have to spend on maintaining the Windows builds.

Have you looked into cross-compiling? In other projects, I do windows
builds by something like

  sudo apt-get install mingw-w64 wine
  ./configure --host=x86_64-w64-mingw32
  make
  make check TEST_ENVIRONMENT=wine

Not a perfect substitute for native testing, of course, but it makes it
possible to do some testing without having to mess with a real MS
windows installation.

Regards,
/Niels

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

[Iverilog-devel] MinGW builds

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

Folks,

The good news is that, courtesy of the Git for Windows and MSYS2 projects, 
it's got a lot easier to install a build environment for Icarus under Windows.

The catch is that MSYS2 uses the mingw-w64 fork of MinGW (for both 32-bit and 
64-bit builds). This is not 100% compatible with the original MinGW (32-bit 
only). The differences are not great - generally mingw-w64 doesn't have the 
quirks of the original MinGW, so is more compatible with *nix.

Unfortunately, when run in the 32-bit MSYS2 environment, config.guess outputs 
the same tuple string as it does in the original MSYS environment, so it is 
not easy to handle the differences.

As the original MinGW project seems to be stagnating (last update was 
Sep-2013), whereas the mingw-w64 project is still being actively developed, 
and as it is easier to install a build environment for the latter, I propose 
we drop support for the original MinGW. Does anyone want to argue against this.

Note that I don't generally use Windows myself, so I'm looking to minimise the 
time I have to spend on maintaining the Windows builds.

Martin

Re: [Iverilog-devel] vhdlpp update

[Kevin C. <iv...@gr...>]

I've done recursive descent (RD) on C++, it can't be worse than that. I just tokenize everything according to the context then do RD on the token stream - ideally I'd be able to parallel process chunks snipped of the stream, but I never got that far.

I don't use lexx/yacc/bison etc. - it's bad enough reading human generated code, debugging those is way too painful. With RD you can tell where you are when things go wrong, and it's easier to handle corner cases. It's particularly easy when the beginning and end of blocks are clearly marked.

Someone at Synopsys was claiming that the reason for not doing something was "keyword incompatibility" - that's the lamest of excuses, and just means they're clueless about writing parsers.

Kev.

On 04/26/2015 08:33 AM, Stephen Williams wrote:
>
> Um...
>
> 1) VHDL is definitely NOT suitable for recursive descent parsing.
> Few modern computer languages are.
>
> 2) If you integrate left context into your lexor, then yes a LALR
> parser, and bison in particular, would have an easier time directly
> mapping. Oh wait, that's almost what we do by matching these things
> as IDENTIFIERS and handling them in the rules. We just do it outside
> of the flex/bison infrastructure.
>
> You have a point that TRUE and FALSE may be enumeration values.
> It turns out that they are, and they are defined in the BOOLEAN
> type enumeration in the standard package. Orson, this is something
> you need to take note of. While they are not keywords, they ARE
> predefined enumeration values. There is infrastructure in vhdlpp
> for predefining types, that is what you want to use here.
>
>
> On 04/25/2015 11:30 AM, Kevin Cameron wrote:
>
> > The whole keyword thing is just a consequence of how people did
> > parsers - if you use context aware recursive-descent parsers then
> > there isn't a problem.
>
> > One useful thing that VHDL does is that it moved a lot of stuff to
> > user-space by putting it in "standard headers". You don't have to
> > take the LRM literally, and you can move things like "true" &
> > "false" to enum in a header file.
>
> > The LRMs are really just statements of what you need to understand
> > to be compatible, you can implement your version with more/better
> > capabilities.
>
> > Kev.
>
> > On 04/23/2015 08:35 AM, Stephen Williams wrote:
> >> On 04/23/2015 07:16 AM, Maciej Sumiński wrote:
> >>> I have one doubt regarding the proposed branch. It introduces a
> >>> few new keywords (true, false, note, warning, error, failure).
> >>> Because of that, it is impossible to use them as names, so for
> >>> example you cannot have a signal called 'true', which should be
> >>> technically valid according to the VHDL standard.
> >>
> >> If the word is not a reserved word as listed in the IEEE1076
> >> standard, then it cannot be parsed as a keyword. It needs to be
> >> matched as an IDENTIFIER and interpreted during semantic
> >> analysis. This is one of the painful quirks of VHDL.
> >>
> >> So no, you cannot add new keywords. Match them as IDENTIFIERs,
> >> then check the actual value in the rules where you expect them.
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel

[Iverilog-devel] Diagnostic messages to stderr

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

It would be nice if all vvp diagnostics, warning messages, and the like,
were sent to stderr. And stdout reserved for explicit output from $write
and $display.

E.g., when I'm simulating my toy cpu, I have a memory mapped tty
registers which read from stdin and write to stdout, and I have my own
debug output which (for now) is also are sent to stdout. My testcases
examine this output for various test programs and inputs. But my output
on stdout is mixed with other diagnostics from vvp, in particular, I see
the message

  WARNING: main.vl:93: $readmemh(examples/hello.hex): Not enough words in the file for the requested range [0:4095].

sent to stdout rather than stderr.

Regards,
/Niels


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

Re: [Iverilog-devel] vhdlpp update

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Um...

1) VHDL is definitely NOT suitable for recursive descent parsing.
Few modern computer languages are.

2) If you integrate left context into your lexor, then yes a LALR
parser, and bison in particular, would have an easier time directly
mapping. Oh wait, that's almost what we do by matching these things
as IDENTIFIERS and handling them in the rules. We just do it outside
of the flex/bison infrastructure.

You have a point that TRUE and FALSE may be enumeration values.
It turns out that they are, and they are defined in the BOOLEAN
type enumeration in the standard package. Orson, this is something
you need to take note of. While they are not keywords, they ARE
predefined enumeration values. There is infrastructure in vhdlpp
for predefining types, that is what you want to use here.


On 04/25/2015 11:30 AM, Kevin Cameron wrote:
> 
> The whole keyword thing is just a consequence of how people did
> parsers - if you use context aware recursive-descent parsers then
> there isn't a problem.
> 
> One useful thing that VHDL does is that it moved a lot of stuff to 
> user-space by putting it in "standard headers". You don't have to
> take the LRM literally, and you can move things like "true" &
> "false" to enum in a header file.
> 
> The LRMs are really just statements of what you need to understand
> to be compatible, you can implement your version with more/better
> capabilities.
> 
> Kev.
> 
> On 04/23/2015 08:35 AM, Stephen Williams wrote:
>> On 04/23/2015 07:16 AM, Maciej Sumiński wrote:
>>> I have one doubt regarding the proposed branch. It introduces a
>>> few new keywords (true, false, note, warning, error, failure).
>>> Because of that, it is impossible to use them as names, so for
>>> example you cannot have a signal called 'true', which should be
>>> technically valid according to the VHDL standard.
>> 
>> If the word is not a reserved word as listed in the IEEE1076 
>> standard, then it cannot be parsed as a keyword. It needs to be
>> matched as an IDENTIFIER and interpreted during semantic 
>> analysis. This is one of the painful quirks of VHDL.
>> 
>> So no, you cannot add new keywords. Match them as IDENTIFIERs, 
>> then check the actual value in the rules where you expect them.


- -- 
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."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlU9BWIACgkQrPt1Sc2b3ikQiwCg1H6jJ3OwE5zyHcXK0K2cxdXE
uAsAmwfCfNTMr1hloty/PHW5OJlOFbYU
=jG3s
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] vhdlpp update

[Kevin C. <iv...@gr...>]

The whole keyword thing is just a consequence of how people did parsers - if you use context aware recursive-descent parsers then there isn't a problem.

One useful thing that VHDL does is that it moved a lot of stuff to user-space by putting it in "standard headers". You don't have to take the LRM literally, and you can move things like "true" & "false" to enum in a header file.

The LRMs are really just statements of what you need to understand to be compatible, you can implement your version with more/better capabilities.

Kev.

On 04/23/2015 08:35 AM, Stephen Williams wrote:
> On 04/23/2015 07:16 AM, Maciej Sumiński wrote:
> > I have one doubt regarding the proposed branch. It introduces a few
> > new keywords (true, false, note, warning, error, failure). Because
> > of that, it is impossible to use them as names, so for example you
> > cannot have a signal called 'true', which should be technically
> > valid according to the VHDL standard.
>
> If the word is not a reserved word as listed in the IEEE1076
> standard, then it cannot be parsed as a keyword. It needs to
> be matched as an IDENTIFIER and interpreted during semantic
> analysis. This is one of the painful quirks of VHDL.
>
> So no, you cannot add new keywords. Match them as IDENTIFIERs,
> then check the actual value in the rules where you expect them.
>
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel

Re: [Iverilog-devel] vhdlpp update

[Maciej S. <mac...@ce...>]

On 04/25/2015 10:28 AM, Martin Whitaker wrote:
> Maciej Sumiński wrote:
>> I enclose one more patch that needs a review. I am wondering if it is
>> required for both arguments in NetEBDiv to have the same width? There is
>> a testcase attached which causes an assertion failure, but in fact it
>> works fine. It also does not break any other tests, but I might have
>> missed something important there.
>>
> The first argument to $ivlh_to_unsigned should be treated as a self-determined 
> expression. The compiler was not doing this; instead it was elaborating the 
> argument using the cast width. I've pushed a fix for this to the master 
> branch. I'll update the test suite later.
> 
> Martin

Hi Martin,

Thank you for the explanation and the fix. Now it works fine for me.

Regards,
Orson

Re: [Iverilog-devel] vhdlpp update

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

Maciej Sumiński wrote:
> I enclose one more patch that needs a review. I am wondering if it is
> required for both arguments in NetEBDiv to have the same width? There is
> a testcase attached which causes an assertion failure, but in fact it
> works fine. It also does not break any other tests, but I might have
> missed something important there.
>
The first argument to $ivlh_to_unsigned should be treated as a self-determined 
expression. The compiler was not doing this; instead it was elaborating the 
argument using the cast width. I've pushed a fix for this to the master 
branch. I'll update the test suite later.

Martin

Re: [Iverilog-devel] vhdlpp update

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

Maciej Sumiński wrote:
> I enclose one more patch that needs a review. I am wondering if it is
> required for both arguments in NetEBDiv to have the same width? There is
> a testcase attached which causes an assertion failure, but in fact it
> works fine. It also does not break any other tests, but I might have
> missed something important there.
>
The steps required for expression evaluation in Verilog are:

   - determine the width of the expression, according to the rules
     in the standard

   - extend all operands to the width of the expression, using
     the type of the expression (unsigned/signed), not the
     type of the operands, to decide whether to zero extend
     or sign extend

   - evaluate the expression

If you don't make sure all the operands are the same size before evaluating 
the expression, most of the time you'll get the same result, but there will be 
corner cases where you don't.

Martin

Re: [Iverilog-devel] Thinking of Icarus Verilog 10

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/08/2015 01:38 PM, Stephen Williams wrote:
> I know this has been discussed before, but I want to bring it up 
> again. I think we are due for a new release.

I threatened to start making the release this weekend, but some
issues have come up, so instead I will make a snapshot. This will
be a dry run for making the release, but otherwise will have no
other consequences. (It's also been a long time since the last
snapshot.)

I've delayed the proposed release date to May 10. That too is a
working date, not cast in stone.
- -- 
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."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlU66c8ACgkQrPt1Sc2b3ilnFgCgycqwqpX3pxiPZQsN+yN2ZqtT
H+8AoKytk13nKttIxfrd7ODLpbOayyot
=ATJx
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] vhdlpp update

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/24/2015 06:42 AM, Maciej Sumiński wrote:
> I enclose one more patch that needs a review. I am wondering if it
> is required for both arguments in NetEBDiv to have the same width?
> There is a testcase attached which causes an assertion failure, but
> in fact it works fine. It also does not break any other tests, but
> I might have missed something important there.

The assertions you want to remove are in the eval_tree(...) method
of the NetEBDiv node, which evaluates the division/mod expression.
The problem here is that the verinum divide (/ and %) operators
kinda assume that the operands and the result are the same size.
The assert is apparently there because the consequences of passing
mismatched arguments to these operators will not have predictable
results, and doesn't handle the various consequences.

The way forward to removing the asserts involves adjusting the
operands so that their sizes match the output size (cast_to_width
should help you there) first, then do the divide.

Otherwise, I do not think there are constraints that the divide
operand sizes must match, so the above approach should do it
for you.


- -- 
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."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlU66NEACgkQrPt1Sc2b3ilCNgCgyKwMnmDab5WbYQ4d1LiBuuCw
PEMAoIcXpss/x7T1dXnCpgaVyKpOyLen
=NXdy
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] vhdlpp update

[Maciej S. <mac...@ce...>]

On 04/23/2015 05:35 PM, Stephen Williams wrote:
> If the word is not a reserved word as listed in the IEEE1076
> standard, then it cannot be parsed as a keyword. It needs to
> be matched as an IDENTIFIER and interpreted during semantic
> analysis. This is one of the painful quirks of VHDL.
> 
> So no, you cannot add new keywords. Match them as IDENTIFIERs,
> then check the actual value in the rules where you expect them.

Ok, it is already fixed. I have also added a patch from Larry Doolittle
to handle or_reduce() and and_reduce() function.

I enclose one more patch that needs a review. I am wondering if it is
required for both arguments in NetEBDiv to have the same width? There is
a testcase attached which causes an assertion failure, but in fact it
works fine. It also does not break any other tests, but I might have
missed something important there.

Regards,
Orson

Re: [Iverilog-devel] vhdlpp update

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/23/2015 07:16 AM, Maciej Sumiński wrote:
> I have one doubt regarding the proposed branch. It introduces a few
> new keywords (true, false, note, warning, error, failure). Because
> of that, it is impossible to use them as names, so for example you
> cannot have a signal called 'true', which should be technically
> valid according to the VHDL standard.

If the word is not a reserved word as listed in the IEEE1076
standard, then it cannot be parsed as a keyword. It needs to
be matched as an IDENTIFIER and interpreted during semantic
analysis. This is one of the painful quirks of VHDL.

So no, you cannot add new keywords. Match them as IDENTIFIERs,
then check the actual value in the rules where you expect them.

- -- 
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."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlU5EUoACgkQrPt1Sc2b3ilnTwCePXWloYRaJvxc7X6AI6wkfpbu
nA8AoLAoH78HMbxkhhrBPjnbAkhf+EwE
=Ms/R
-----END PGP SIGNATURE-----

[Iverilog-devel] vhdlpp update

[Maciej S. <mac...@ce...>]

Hi,

There is a new branch [1, 2] that contains new features for vhdlpp:
- assertion & report statements
- boolean type (to be more precise: "true" & "false" values)
- fixes missing std_logic values in emit() functions

I have one doubt regarding the proposed branch. It introduces a few new
keywords (true, false, note, warning, error, failure). Because of that,
it is impossible to use them as names, so for example you cannot have a
signal called 'true', which should be technically valid according to the
VHDL standard.

Alternatively, I could detect the keywords with strncmp() in appropriate
rules in the parser. Is it the preferred approach or is there another
more elegant solution to the problem?

I am also wondering if there is a way to translate weak std_logic values
('L', 'H' & 'W') to SystemVerilog. I know there is 'strength' property,
but it is not exactly the same (e.g. it cannot be used to compare to a
net value).

Regards,
Orson

1. https://github.com/steveicarus/iverilog/pull/61
2. https://github.com/orsonmmz/ivtest/tree/asserts_test

Re: [Iverilog-devel] Thinking of Icarus Verilog 10

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I've gotten generally positive feedback from this idea, so I'm
going to set a deadline for objections. If I don't hear any
objects by the evening of Saturday, 25 April 2015, I will feel
free to start wrapping up an Icarus Verilog release anytime
from the 26th on. This will involve locally testing the package
build, then making a branch and making an actual draft release.

Maybe a week after the draft release, I'll probably make the
Version 10 release (10.1) and we can start promoting the new
release to distribution packagers.

Sound like a plan?

On 04/08/2015 01:38 PM, Stephen Williams wrote:
> 
> I know this has been discussed before, but I want to bring it up 
> again. I think we are due for a new release.
> 
> I've been noting that a huge portion of users are finding that 
> their needs are met by recent snapshots that are not otherwise 
> handled by the 0.9 release. We've been spending some amount of our
> support time just telling people that "it's been fixed" in the
> master branch.
> 
> But there are many users out there who get their Icarus Verilog fix
> from package managers, and so are using the 0.9 release. These 
> people are not particularly motivated to build from source, and 
> after all they shouldn't need to. Our making a release is our way
> to say that this is what we recommend.
> 
> Since we've been recommending git master for a while now, maybe it
> is time to make a release.
> 
> Also, name change. Rather then go to 0.10.x, let's simple call it
> version 10. Somewhere along the line, Icarus Verilog became 
> production ready while we weren't looking. I think the leading zero
> is no longer informative.


- -- 
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."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlUxlZgACgkQrPt1Sc2b3ilgygCfZwaCxK+dLv6fQ74DROSxF5iP
Sg4An1z0kq9UnKOmoZnazfwNTiY2SdAh
=uzVD
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Thinking of Icarus Verilog 10

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/15/2015 06:45 AM, Niels Möller wrote:
> Stephen Williams <st...@ic...> writes:
> 
>> Also, name change. Rather then go to 0.10.x, let's simple call it
>> version 10. Somewhere along the line, Icarus Verilog became 
>> production ready while we weren't looking.
> 
> Cool! But why not simply "1.0"?


The previous version is 0.9.x, it's been informally called the
"point 9" release, it just feels like I'm shifting the decimal
point over one.

It's purely aesthetic.


- -- 
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."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlUudSEACgkQrPt1Sc2b3imeygCfSS+HzcFWOAhrSyQ7/nb3I+x3
pLMAoJnh6jmQC4gtt3dbS6FfbzTjtspQ
=PwdJ
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Thinking of Icarus Verilog 10

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

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

> Also, name change. Rather then go to 0.10.x, let's simple call
> it version 10. Somewhere along the line, Icarus Verilog became
> production ready while we weren't looking.

Cool! But why not simply "1.0"?

Regards,
/Niels

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

Re: [Iverilog-devel] Crash on invalid indexing of generate block

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

ni...@ly... (Niels Möller) wrote:
> For the attached (broken) code, I get the following error, and a
> segmentation fault. I'm using iverilog compiled from the repo.
>
>    $ iverilog ctz-reduced.vl
>    ctz-reduced.vl:28: error: Scope index expression is not constant: ((n)-(k))-('sd1)
>    ctz-reduced.vl:28: XXXXX: Errors evaluating scope index
>    ctz-reduced.vl:28: error: Scope index expression is not constant: ((n)-(k))-('sd1)
>    ctz-reduced.vl:28: XXXXX: Errors evaluating scope index
>    ctz-reduced.vl:28: error: Unable to bind wire/reg/memory `REDUCE[((n)-(k))-('sd1)].r[('sd2)*(cnt[(n)-('sd1):((n)-(k))+('sd1)])]' in `ctz'
>    Segmentation fault
>
> (I have a working version too, using a second generate block. I wasn't
> sure if that was necessary, but it seems one can't use regular variables
> (i.e., not params or genvar) when indexing generate blocks).
>
I've pushed a fix for the segmentation fault to both the master branch and the 
v0.9 branch.

Martin

Re: [Iverilog-devel] Thinking of Icarus Verilog 10

[XINGZHI W. <xin...@ho...>]

Hi Stephen,
It has been a while since I use Icarus simulator. Could you please share any update about UVM and system verilog support?
ThanksXingzhi
> Date: Wed, 8 Apr 2015 23:59:26 +0100
> From: mai...@ma...
> To: ive...@li...
> Subject: Re: [Iverilog-devel] Thinking of Icarus Verilog 10
> 
> Stephen Williams wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> > I know this has been discussed before, but I want to bring it up
> > again. I think we are due for a new release.
> >
> > I've been noting that a huge portion of users are finding that
> > their needs are met by recent snapshots that are not otherwise
> > handled by the 0.9 release. We've been spending some amount of
> > our support time just telling people that "it's been fixed" in
> > the master branch.
> >
> > But there are many users out there who get their Icarus Verilog
> > fix from package managers, and so are using the 0.9 release. These
> > people are not particularly motivated to build from source, and
> > after all they shouldn't need to. Our making a release is our
> > way to say that this is what we recommend.
> >
> > Since we've been recommending git master for a while now, maybe
> > it is time to make a release.
> >
> You know this will get my vote! Development is a huge advance over v0.9 - time 
> to get it in the hands of all our users.
> 
> Martin
> 
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel