iverilog-devel — Conversations on matters of Icarus Verilog development

Re: [Iverilog-devel] Icarus Verilog Version 10 Branch

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

It was not easy to fix the two vlog95 conversion problems so they have been marked as fails with a description of the issue. I also removed the two failing analog tests from the V10 checks. I'm not sure what we want to do with the four remaining failures in V10.

There are a couple other things that I have here locally that are issues. I may submit one of those as an official bug report later.


Cary





On Monday, August 17, 2015 12:10 AM, Cary R. <cy...@ya...> wrote:
I think we should update the copyright dates on all the targets.

Cary






On Sunday, August 16, 2015 4:29 PM, Stephen Williams <st...@ic...> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/16/2015 03:28 PM, Martin Whitaker wrote:
> Should the copyright dates shown with the -V option to iverilog or
> vvp be updated?

It should. I think I did update at least some of the copyright
dates.

- -- 
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

iEYEARECAAYFAlXRHNcACgkQrPt1Sc2b3inXwwCfaTgZi4zghBhfvvqvXu0U39bR
TPAAoM7YtRrAaTQg+S/HlkRVDxLD560D
=Qygr
-----END PGP SIGNATURE-----


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

Re: [Iverilog-devel] Icarus Verilog Version 10 Branch

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

I think we should update the copyright dates on all the targets.

Cary





On Sunday, August 16, 2015 4:29 PM, Stephen Williams <st...@ic...> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/16/2015 03:28 PM, Martin Whitaker wrote:
> Should the copyright dates shown with the -V option to iverilog or
> vvp be updated?

It should. I think I did update at least some of the copyright
dates.

- -- 
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

iEYEARECAAYFAlXRHNcACgkQrPt1Sc2b3inXwwCfaTgZi4zghBhfvvqvXu0U39bR
TPAAoM7YtRrAaTQg+S/HlkRVDxLD560D
=Qygr
-----END PGP SIGNATURE-----


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

Re: [Iverilog-devel] Icarus Verilog Version 10 Branch

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

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

On 08/16/2015 03:28 PM, Martin Whitaker wrote:
> Should the copyright dates shown with the -V option to iverilog or
> vvp be updated?

It should. I think I did update at least some of the copyright
dates.

- -- 
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

iEYEARECAAYFAlXRHNcACgkQrPt1Sc2b3inXwwCfaTgZi4zghBhfvvqvXu0U39bR
TPAAoM7YtRrAaTQg+S/HlkRVDxLD560D
=Qygr
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Icarus Verilog Version 10 Branch

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

Stephen Williams wrote:
> I've created in the git repository the v10-branch branch that
> holds Version 10. I've changed the version format slightly to
> make the version numbers better reflect how we refer to versions
> ("10" instead of "0 point 10") so we're pretty close to a release.
> The 10.0 is beta, meaning only that I haven't tagged and packaged
> it. Those who are interested may pull from this branch and try it
> out before I stamp it.

I've just fixed the version number shown in the vvp man page (in both v10 and 
devel).

Should the copyright dates shown with the -V option to iverilog or vvp be updated?

Martin

Re: [Iverilog-devel] Icarus Verilog Version 10 Branch

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

Thanks for taking care of that. It looks like there may be a bug in the compiler that is exposed by the vlog95 back end where the appropriate information is not getting into the target data structures. This does not appear to effect the VVP code. since it does not really care about port direction. There is also one other failure that I need to look at. Hopefully I can look at and fix these issues over the next few days.

Everything is compiling cleanly and with only the expected warnings on Ubuntu 12.04 using both gcc and clang.


Cary




On Sunday, August 16, 2015 1:05 PM, Stephen Williams <st...@ic...> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I've made and pushed the matching v10 changes.

On 08/15/2015 10:06 PM, Cary R. wrote:
> The new two digit version scheme broke a few things. I have pushed
> some changes to make the example code in vvp work correctly for
> development (V11.0) (make check, etc). The same still needs to be
> done for the V10 branch. I have also pushed patched that fix the
> normal and strict checks for development. I am working on getting
> the vlog95 checks working correctly. Like for the examples much of
> this will need to be back ported for the V10 branch.
> 
> Cary
> 
> 
> 
> 
> 
> 
> On Saturday, August 15, 2015 2:33 PM, Stephen Williams
> <st...@ic...> wrote:
> 
> I've created in the git repository the v10-branch branch that holds
> Version 10. I've changed the version format slightly to make the
> version numbers better reflect how we refer to versions ("10"
> instead of "0 point 10") so we're pretty close to a release. The
> 10.0 is beta, meaning only that I haven't tagged and packaged it.
> Those who are interested may pull from this branch and try it out
> before I stamp it.
> 
> I'm thinking I'll stamp and release version 10 next weekend. That 
> will give folks the coming week to assess the branch and suggest 
> changes.


- -- 
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

iEYEARECAAYFAlXQ7QMACgkQrPt1Sc2b3ikZ/ACgvfO9Va/cRKYIYR/aQyx2zzpT
PqoAoKrXlDYF0P0rCqwE3XW+9jgv8s5B
=Npi6

-----END PGP SIGNATURE-----

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

Re: [Iverilog-devel] Icarus Verilog Version 10 Branch

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

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


I've made and pushed the matching v10 changes.

On 08/15/2015 10:06 PM, Cary R. wrote:
> The new two digit version scheme broke a few things. I have pushed
> some changes to make the example code in vvp work correctly for
> development (V11.0) (make check, etc). The same still needs to be
> done for the V10 branch. I have also pushed patched that fix the
> normal and strict checks for development. I am working on getting
> the vlog95 checks working correctly. Like for the examples much of
> this will need to be back ported for the V10 branch.
> 
> Cary
> 
> 
> 
> 
> 
> 
> On Saturday, August 15, 2015 2:33 PM, Stephen Williams
> <st...@ic...> wrote:
> 
> I've created in the git repository the v10-branch branch that holds
> Version 10. I've changed the version format slightly to make the
> version numbers better reflect how we refer to versions ("10"
> instead of "0 point 10") so we're pretty close to a release. The
> 10.0 is beta, meaning only that I haven't tagged and packaged it.
> Those who are interested may pull from this branch and try it out
> before I stamp it.
> 
> I'm thinking I'll stamp and release version 10 next weekend. That 
> will give folks the coming week to assess the branch and suggest 
> changes.


- -- 
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

iEYEARECAAYFAlXQ7QMACgkQrPt1Sc2b3ikZ/ACgvfO9Va/cRKYIYR/aQyx2zzpT
PqoAoKrXlDYF0P0rCqwE3XW+9jgv8s5B
=Npi6
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Icarus Verilog Version 10 Branch

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

The new two digit version scheme broke a few things. I have pushed some changes to make the example code in vvp work correctly for development (V11.0) (make check, etc). The same still needs to be done for the V10 branch. I have also pushed patched that fix the normal and strict checks for development. I am working on getting the vlog95 checks working correctly. Like for the examples much of this will need to be back ported for the V10 branch.

Cary






On Saturday, August 15, 2015 2:33 PM, Stephen Williams <st...@ic...> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I've created in the git repository the v10-branch branch that
holds Version 10. I've changed the version format slightly to
make the version numbers better reflect how we refer to versions
("10" instead of "0 point 10") so we're pretty close to a release.
The 10.0 is beta, meaning only that I haven't tagged and packaged
it. Those who are interested may pull from this branch and try it
out before I stamp it.

I'm thinking I'll stamp and release version 10 next weekend. That
will give folks the coming week to assess the branch and suggest
changes.

- -- 
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

iEUEARECAAYFAlXPsAYACgkQrPt1Sc2b3ilRgwCYsqCO90DInrhL7hXfPVVMjl4N
hgCg0j824wPVMXl5YYBgurWQtYfCbpg=
=6DKD
-----END PGP SIGNATURE-----

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

[Iverilog-devel] Icarus Verilog Version 10 Branch

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

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


I've created in the git repository the v10-branch branch that
holds Version 10. I've changed the version format slightly to
make the version numbers better reflect how we refer to versions
("10" instead of "0 point 10") so we're pretty close to a release.
The 10.0 is beta, meaning only that I haven't tagged and packaged
it. Those who are interested may pull from this branch and try it
out before I stamp it.

I'm thinking I'll stamp and release version 10 next weekend. That
will give folks the coming week to assess the branch and suggest
changes.

- -- 
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

iEUEARECAAYFAlXPsAYACgkQrPt1Sc2b3ilRgwCYsqCO90DInrhL7hXfPVVMjl4N
hgCg0j824wPVMXl5YYBgurWQtYfCbpg=
=6DKD
-----END PGP SIGNATURE-----

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

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

Steve -

On Tue, Aug 11, 2015 at 11:23:08PM +0100, Martin Whitaker wrote:
> Stephen Williams wrote:
> > We need a version 10 release. It's getting desperate.
> Just one thing needs attention - the latest vhdlpp patches have introduce some 
> shift/reduce errors:

I also see
parse.cc:7759:18: warning: missing initializer for member ‘vlltype::text’ [-Wmissing-field-initializers]

And the string "elabortae_rootscope_tasks does not understand " in
elab_scope.cc should have elabortae changed to elaborate.

  - Larry

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

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

Stephen Williams wrote:
> I've been talked out of making a version 10 release several
> times now, but this time I think I'm going to make an executive
> decision.
>
> We need a version 10 release. It's getting desperate. The 0.9.7
> release is very old, and too many of the bug reports we received
> are from the 0.9 release and have been already fixed in the devel
> branch.
>
+1 from me (as usual!). I've just checked that everything still compiles and 
runs as expected under Windows/MinGW.

Just one thing needs attention - the latest vhdlpp patches have introduce some 
shift/reduce errors:

bison --verbose -t -d -o parse.cc ../../source/vhdlpp/parse.y
../../source/vhdlpp/parse.y: warning: 90 shift/reduce conflicts [-Wconflicts-sr]
../../source/vhdlpp/parse.y: warning: 30 reduce/reduce conflicts [-Wconflicts-rr]

Martin

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

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

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


I've been talked out of making a version 10 release several
times now, but this time I think I'm going to make an executive
decision.

We need a version 10 release. It's getting desperate. The 0.9.7
release is very old, and too many of the bug reports we received
are from the 0.9 release and have been already fixed in the devel
branch.

I have some free time this coming weekend (August 15,16) so I
think I will make the branch and make a draft release then. I'm
not taking requests to hold off anymore, we'll instead discuss
how to fit your pet project into the development path.


On 04/24/2015 06:11 PM, Stephen Williams wrote:
> 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

iEYEARECAAYFAlXKNk8ACgkQrPt1Sc2b3imENQCg2WdnkD77PgGXJvoN3jJMm6pd
xRAAnj3jhnIGTTJGvnX9ohSxiB9GbODi
=arUf
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] MVSE 2015 hacks

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

Thanks for looking into this Larry. I was able to compile Icarus and run the test suite to verify that things still work correctly with clang.

Cary





On Monday, July 27, 2015 8:13 PM, Larry Doolittle <ldo...@re...> wrote:
Cary -

On Mon, Jul 27, 2015 at 05:38:35AM +0000, Cary R. wrote:
> The other issue is we also compile using clang so __GNUC__ does not likely work for all cases. I have not looked at this to check if there are issues, but I'm guessing we may need an #ifdef for MSVC just like we have for mingw.

I agree in general, and of course this needs some thought and testing.
It turns out clang does define __GNUC__, as shown here on Debian Jessie:

$ clang --version
Debian clang version 3.5.0-10 (tags/RELEASE_350/final) (based on LLVM 3.5.0)
Target: x86_64-pc-linux-gnu
Thread model: posix
$ clang -dM -E - < /dev/null | grep GNU
#define __GNUC_MINOR__ 2
#define __GNUC_PATCHLEVEL__ 1
#define __GNUC_STDC_INLINE__ 1
#define __GNUC__ 4

$

   - Larry

Re: [Iverilog-devel] MVSE 2015 hacks

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

Cary -

On Mon, Jul 27, 2015 at 05:38:35AM +0000, Cary R. wrote:
> The other issue is we also compile using clang so __GNUC__ does not likely work for all cases. I have not looked at this to check if there are issues, but I'm guessing we may need an #ifdef for MSVC just like we have for mingw.

I agree in general, and of course this needs some thought and testing.
It turns out clang does define __GNUC__, as shown here on Debian Jessie:

$ clang --version
Debian clang version 3.5.0-10 (tags/RELEASE_350/final) (based on LLVM 3.5.0)
Target: x86_64-pc-linux-gnu
Thread model: posix
$ clang -dM -E - < /dev/null | grep GNU
#define __GNUC_MINOR__ 2
#define __GNUC_PATCHLEVEL__ 1
#define __GNUC_STDC_INLINE__ 1
#define __GNUC__ 4
$

   - Larry

Re: [Iverilog-devel] MVSE 2015 hacks

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

The other issue is we also compile using clang so __GNUC__ does not likely work for all cases. I have not looked at this to check if there are issues, but I'm guessing we may need an #ifdef for MSVC just like we have for mingw.

Cary




On Thursday, July 23, 2015 7:38 AM, Stephen Williams <st...@ic...> wrote:



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


Yeah, some of hthem I would have done better and I may go back
and clean some of them up a bit. If anyone beats me to that, then
that's great.

On 07/22/2015 08:40 PM, Larry Doolittle wrote:
> Friends -
> 
> I see a bunch of commits from Frederick C. Kurz to let iverilog
> run smoothly on "Microsoft Visual Studio Express 2015 RC Web". I
> appreciate the value in making the iverilog code base usable for 
> more people and environments.
> 
> Some of the patches look terrible, in the sense of duplicating code
> and introducing maintenance headaches, as well as adding cognitive
> load on the developers from all the #ifdef's.  Could we go through
> and try to get the same result with better coding style?
> 
> One simple and concrete suggestion: suppose we #ifdef __GNUC__ 
> #define MAYBE_UINT #else #define MAYBE_UNIT : unsigned int #endif 
> somewhere.  Then commits 82d46a5e and 093e7eb2 could be
> accomplished without further conditional code, just changing 
> typedef enum ivl_variable_type_e { to typedef enum
> ivl_variable_type_e MAYBE_UINT { etc.  If tests show that gcc and
> clang give the same result on normal computers _with_ the
> enumeration based on unsigned int, even that one bit of conditional
> magic could be eliminated.
> 
> I don't know anything about this, but I wonder if Frederick looked 
> for something equivalent to "--std=c99" in MVSE2015RCW?  It's hard 
> to believe a compiler today (especially one with 2015 in its name) 
> really needs commit 5e931b7e.
> 
> - Larry
> 
> ------------------------------------------------------------------------------
>
> 
_______________________________________________
> 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

iEYEARECAAYFAlWw/F4ACgkQrPt1Sc2b3ikl6gCg7d+kGfRIaP1MaFzZEIPJuYbf
tVUAoN1kqVpqy17zyZ7qEOXLObn3D4Xl
=NIFc
-----END PGP SIGNATURE-----


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

Re: [Iverilog-devel] MVSE 2015 hacks

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

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


Yeah, some of hthem I would have done better and I may go back
and clean some of them up a bit. If anyone beats me to that, then
that's great.

On 07/22/2015 08:40 PM, Larry Doolittle wrote:
> Friends -
> 
> I see a bunch of commits from Frederick C. Kurz to let iverilog
> run smoothly on "Microsoft Visual Studio Express 2015 RC Web". I
> appreciate the value in making the iverilog code base usable for 
> more people and environments.
> 
> Some of the patches look terrible, in the sense of duplicating code
> and introducing maintenance headaches, as well as adding cognitive
> load on the developers from all the #ifdef's.  Could we go through
> and try to get the same result with better coding style?
> 
> One simple and concrete suggestion: suppose we #ifdef __GNUC__ 
> #define MAYBE_UINT #else #define MAYBE_UNIT : unsigned int #endif 
> somewhere.  Then commits 82d46a5e and 093e7eb2 could be
> accomplished without further conditional code, just changing 
> typedef enum ivl_variable_type_e { to typedef enum
> ivl_variable_type_e MAYBE_UINT { etc.  If tests show that gcc and
> clang give the same result on normal computers _with_ the
> enumeration based on unsigned int, even that one bit of conditional
> magic could be eliminated.
> 
> I don't know anything about this, but I wonder if Frederick looked 
> for something equivalent to "--std=c99" in MVSE2015RCW?  It's hard 
> to believe a compiler today (especially one with 2015 in its name) 
> really needs commit 5e931b7e.
> 
> - Larry
> 
> ------------------------------------------------------------------------------
>
> 
_______________________________________________
> 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

iEYEARECAAYFAlWw/F4ACgkQrPt1Sc2b3ikl6gCg7d+kGfRIaP1MaFzZEIPJuYbf
tVUAoN1kqVpqy17zyZ7qEOXLObn3D4Xl
=NIFc
-----END PGP SIGNATURE-----

[Iverilog-devel] MVSE 2015 hacks

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

Friends -

I see a bunch of commits from Frederick C. Kurz to let iverilog run
smoothly on "Microsoft Visual Studio Express 2015 RC Web".
I appreciate the value in making the iverilog code base usable for
more people and environments.

Some of the patches look terrible, in the sense of duplicating
code and introducing maintenance headaches, as well as adding
cognitive load on the developers from all the #ifdef's.  Could we
go through and try to get the same result with better coding style?

One simple and concrete suggestion: suppose we
#ifdef __GNUC__
#define MAYBE_UINT
#else
#define MAYBE_UNIT : unsigned int
#endif
somewhere.  Then commits 82d46a5e and 093e7eb2 could be accomplished
without further conditional code, just changing
  typedef enum ivl_variable_type_e {
to
  typedef enum ivl_variable_type_e MAYBE_UINT {
etc.  If tests show that gcc and clang give the same result on normal
computers _with_ the enumeration based on unsigned int, even that one
bit of conditional magic could be eliminated.

I don't know anything about this, but I wonder if Frederick looked
for something equivalent to "--std=c99" in MVSE2015RCW?  It's hard
to believe a compiler today (especially one with 2015 in its name)
really needs commit 5e931b7e.

  - Larry

[Iverilog-devel] VHDL procedure calls

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

Hi Steve,

I have prepared a new branch [1] & tests [2]. New features include:

- Support for selected assignments (vhdlpp) (i.e. with x select a <= val).

- Variable initialization in the declaration line (vhdlpp).

- Procedure calls (vhdlpp), excluding support for procedures stored in
packages. Currently ivl does not handle invoking tasks using
'package_name::task_name()', though vhdlpp is able to output such code.
I do not really need it, just a side note.

- Array query functions for localparams (ivl):
$left/$high/$increment/$size/etc.


A few words of explanation for the remaining changes:
- Subprogram class is split to SubprogramHeader & SubprogramBody. My
intention was to avoid adding more system functions to
ExpFunc::elaborate() and emit(), so now they are treated in a more
generic way.

- Standard types have dedicated global objects that can be used with
SubprogramHeaders. Boolean type has been converted to a typedef to match
its definition in the VHDL standard library.

- Enumerated output ports are treated as implicit registers, if their
base type is 'logic'. As enum provides named values for a given type, it
seems valid to treat logic-based types as regs.

- Conversion of 'rising/falling_edge(sig)' to 'always begin..end
@(pos/negedge sig)' is removed, as now the same functionality is
provided with $ivlh_rising/falling_edge(). Aside from that, processes
were launched in the initalization phase, even though there were no
signal changes.

- You may also have noticed that I changed a few tests. Normally it
should not happen, but it turned out they were not entirely correct.
There are 2 extra delays (br943_944.v & vhdl_range_func.v) due to the
change described in the previous point. In vhdl_range_func.vhd
assignment type was incorrect.

Regards,
Orson

1. https://github.com/steveicarus/iverilog/pull/71
2. https://github.com/orsonmmz/ivtest/commits/procedure_calls_test

Re: [Iverilog-devel] Vhpi/vhpi and vhdl

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

Brave man Jon!

I hear gHDL is making good progress these days.

Actually I suspect using VHDL for an OS is possibly better use than hardware description ;-)

Given that it's impossible to persuade everybody to use the same language or the same simulator, I recommend using an OO API for boundary elements between systems.

The boundary elements in electronics are the wires that connect things, the objects that connect the processes to the wires are drivers and receivers (Verilog-AMS parlance), so you need an API for connecting drivers and receivers to wires in other simulations/partitions.

I would handle the resolution process for multiple types connected to a wire outside the HDLs because although it's not particularly difficult the standards bodies have not got their heads round it in the last 2+ decades, and I'm not expecting any sudden enlightenment.

Also, you want to handle scheduling (for NBAs) as well as resolution within the objects representing the wires.

You can do a large chunk of that with C and DPI calls in SystemVerilog resolution functions for user defined types, but I'm not up to speed on where Icarus is with SV support. Likewise I haven't used gHDL in years and don't know where it stands.

Kev.

On 06/10/2015 03:33 PM, Jon Taylor wrote:
>
> Hi all,
>
> I am the author of Controlix, an operating system written in vhdl. I am currently developing it using GHDL as the compiler, and the system interface uses vhpi calls. Works OK on top of POSIX, but Icarus' vpp is written in c instead of in ada, making a static linkage job for bare metal targeting much more feasible.
>
> Afaics from perusing the sources, neither vhpi or vpp are currently supported by vhdlpp. If someone is already looking into writing support for this, I'd be happy to test, otherwise I might be able to take a crack at it myself (I have the coding time available).
>
> Jon
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel

Re: [Iverilog-devel] Vhpi/vhpi and vhdl

[Jon T. <dos...@gm...>]

Hi Cary,

Sorry, I forgot to answer your first question.  So:

VHDL VHPIDIRECT function call ->
SystemVerilog DPI function call ->
VPP %vpi_call("VHPIDIRECT", "printf", ...) function call ->
VHPI.c VHPIDIRECT(...) function call ->
Linked native object file dlsym() entry point

Something like that?

Jon

On Mon, Jun 22, 2015 at 4:44 PM, Cary R. <cy...@ya...> wrote:
> Would adding functionality for the SystemVerilog DPI functionality be
> enough? Can you give us a quick overview of the VHPI you are hoping to
> translate.
>
> Cary
>
>
>
> On Monday, June 22, 2015 4:08 PM, Jon Taylor <dos...@gm...> wrote:
>
>
> On Mon, Jun 22, 2015 at 12:38 PM, Martin Whitaker
> <mai...@ma...> wrote:
>> Jon Taylor wrote:
>>> Hi all,
>>>
>>> I am the author of Controlix, an operating system written in vhdl. I am
>>> currently developing it using GHDL as the compiler, and the system
>>> interface uses vhpi calls. Works OK on top of POSIX, but Icarus' vpp is
>>> written in c instead of in ada, making a static linkage job for bare
>>> metal
>>> targeting much more feasible.
>>>
>>> Afaics from perusing the sources, neither vhpi or vpp are currently
>>> supported by vhdlpp. If someone is already looking into writing support
>>> for
>>> this, I'd be happy to test, otherwise I might be able to take a crack at
>>> it
>>> myself (I have the coding time available).
>>>
>> Hello Jon,
>>
>> Sorry nobody has replied to you sooner. As far as I know nobody is working
>> on
>> supporting VHPI - hopefully Steve or Orson will chime in if I'm wrong.
>>
>> I'm not familiar with VHPI myself, but at a quick glance it seems very
>> similar
>> to VPI.
>
> Yes, although the full spec is a lot more complex than a simple
> function-binding strategy.
> However, most of the time you don't end up needing to implement the
> full spec - GHDL
> doesn't, all it implements is procedure and function calls.
>
>> This means support would need to be added to the simulator runtime
>> (vvp).
>
> Yes again.  What I am researching now is whether I can piggyback the
> VHPI interface
> on top of the VPI interface in VVP - that is, if %vpi_call() calls can
> be generated by
> vhdlpp from VHPIDIRECT functions and procedures.
>
>> This may not be a big deal in itself, but I suspect the problem you
>> will run into is that vhdlpp is just a preprocessor that converts VHDL to
>> SystemVerilog, so some knowledge of the original code may get lost on the
>> way.
>
> I think that as long as the end product .vpi code contains the
> necessary %vpi_call()s,
> this shouldn't be a problem.  All I will need at that point is a .c
> file to link into
> vpp to map a VHPIDIRECT string to a symbol in the object file.  I think
> libDL can do that.
>
> [snip]
>
>> By vpp, do you mean the VHDL preprocessor?
>
> No, sorry I meant VVP, not vpp. |->
>
>
> Jon
>
> ------------------------------------------------------------------------------
> Monitor 25 network devices or servers for free with OpManager!
> OpManager is web-based network management software that monitors
> network devices and physical & virtual servers, alerts via email & sms
> for fault. Monitor 25 devices for free with no restriction. Download now
> http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
>

Re: [Iverilog-devel] Vhpi/vhpi and vhdl

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

Would adding functionality for the SystemVerilog DPI functionality be enough? Can you give us a quick overview of the VHPI you are hoping to translate.
Cary
 


     On Monday, June 22, 2015 4:08 PM, Jon Taylor <dos...@gm...> wrote:
   

 On Mon, Jun 22, 2015 at 12:38 PM, Martin Whitaker
<mai...@ma...> wrote:
> Jon Taylor wrote:
>> Hi all,
>>
>> I am the author of Controlix, an operating system written in vhdl. I am
>> currently developing it using GHDL as the compiler, and the system
>> interface uses vhpi calls. Works OK on top of POSIX, but Icarus' vpp is
>> written in c instead of in ada, making a static linkage job for bare metal
>> targeting much more feasible.
>>
>> Afaics from perusing the sources, neither vhpi or vpp are currently
>> supported by vhdlpp. If someone is already looking into writing support for
>> this, I'd be happy to test, otherwise I might be able to take a crack at it
>> myself (I have the coding time available).
>>
> Hello Jon,
>
> Sorry nobody has replied to you sooner. As far as I know nobody is working on
> supporting VHPI - hopefully Steve or Orson will chime in if I'm wrong.
>
> I'm not familiar with VHPI myself, but at a quick glance it seems very similar
> to VPI.

Yes, although the full spec is a lot more complex than a simple
function-binding strategy.
However, most of the time you don't end up needing to implement the
full spec - GHDL
doesn't, all it implements is procedure and function calls.

> This means support would need to be added to the simulator runtime
> (vvp).

Yes again.  What I am researching now is whether I can piggyback the
VHPI interface
on top of the VPI interface in VVP - that is, if %vpi_call() calls can
be generated by
vhdlpp from VHPIDIRECT functions and procedures.

> This may not be a big deal in itself, but I suspect the problem you
> will run into is that vhdlpp is just a preprocessor that converts VHDL to
> SystemVerilog, so some knowledge of the original code may get lost on the way.

I think that as long as the end product .vpi code contains the
necessary %vpi_call()s,
this shouldn't be a problem.  All I will need at that point is a .c
file to link into
vpp to map a VHPIDIRECT string to a symbol in the object file.  I think
libDL can do that.

[snip]

> By vpp, do you mean the VHDL preprocessor?

No, sorry I meant VVP, not vpp. |->

Jon

------------------------------------------------------------------------------
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel


  

Re: [Iverilog-devel] Vhpi/vhpi and vhdl

[Jon T. <dos...@gm...>]

On Mon, Jun 22, 2015 at 12:38 PM, Martin Whitaker
<mai...@ma...> wrote:
> Jon Taylor wrote:
>> Hi all,
>>
>> I am the author of Controlix, an operating system written in vhdl. I am
>> currently developing it using GHDL as the compiler, and the system
>> interface uses vhpi calls. Works OK on top of POSIX, but Icarus' vpp is
>> written in c instead of in ada, making a static linkage job for bare metal
>> targeting much more feasible.
>>
>> Afaics from perusing the sources, neither vhpi or vpp are currently
>> supported by vhdlpp. If someone is already looking into writing support for
>> this, I'd be happy to test, otherwise I might be able to take a crack at it
>> myself (I have the coding time available).
>>
> Hello Jon,
>
> Sorry nobody has replied to you sooner. As far as I know nobody is working on
> supporting VHPI - hopefully Steve or Orson will chime in if I'm wrong.
>
> I'm not familiar with VHPI myself, but at a quick glance it seems very similar
> to VPI.

Yes, although the full spec is a lot more complex than a simple
function-binding strategy.
However, most of the time you don't end up needing to implement the
full spec - GHDL
doesn't, all it implements is procedure and function calls.

> This means support would need to be added to the simulator runtime
> (vvp).

Yes again.  What I am researching now is whether I can piggyback the
VHPI interface
on top of the VPI interface in VVP - that is, if %vpi_call() calls can
be generated by
vhdlpp from VHPIDIRECT functions and procedures.

> This may not be a big deal in itself, but I suspect the problem you
> will run into is that vhdlpp is just a preprocessor that converts VHDL to
> SystemVerilog, so some knowledge of the original code may get lost on the way.

I think that as long as the end product .vpi code contains the
necessary %vpi_call()s,
this shouldn't be a problem.  All I will need at that point is a .c
file to link into
vpp to map a VHPIDIRECT string to a symbol in the object file.  I think
libDL can do that.

[snip]

> By vpp, do you mean the VHDL preprocessor?

No, sorry I meant VVP, not vpp. |->

Jon

Re: [Iverilog-devel] Vhpi/vhpi and vhdl

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

Jon Taylor wrote:
> Hi all,
>
> I am the author of Controlix, an operating system written in vhdl. I am
> currently developing it using GHDL as the compiler, and the system
> interface uses vhpi calls. Works OK on top of POSIX, but Icarus' vpp is
> written in c instead of in ada, making a static linkage job for bare metal
> targeting much more feasible.
>
> Afaics from perusing the sources, neither vhpi or vpp are currently
> supported by vhdlpp. If someone is already looking into writing support for
> this, I'd be happy to test, otherwise I might be able to take a crack at it
> myself (I have the coding time available).
>
Hello Jon,

Sorry nobody has replied to you sooner. As far as I know nobody is working on 
supporting VHPI - hopefully Steve or Orson will chime in if I'm wrong.

I'm not familiar with VHPI myself, but at a quick glance it seems very similar 
to VPI. This means support would need to be added to the simulator runtime 
(vvp). This may not be a big deal in itself, but I suspect the problem you 
will run into is that vhdlpp is just a preprocessor that converts VHDL to 
SystemVerilog, so some knowledge of the original code may get lost on the way. 
Furthermore, quite a lot of knowledge about SystemVerilog types are also lost 
during compilation, and vvp's support for VPI is far from complete... But 
having said that, I don't want to discourage you from having a crack at it!

By vpp, do you mean the VHDL preprocessor?

Martin

Re: [Iverilog-devel] patch for format_vpiStringVal

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

Martin Whitaker wrote:
> Unfortunately the standard is silent on how $display or vpi_get_value should
> handle null ASCII characters when formatting as a string.

Small correction - it does say leading zeros are never displayed by $display.

Martin

Re: [Iverilog-devel] patch for format_vpiStringVal

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

Hello Fabrizio,

First, apologies that it has taken so long for someone to reply to this.

Fabrizio Ferrandi wrote:
> Playing with strings and $fopen I discovered a possible bug of
> format_vpiStringVal in vpi_signal.cc.
>
> This function seems to convert all 0s in spaces. This creates problems when
> a signal is used as first parameter of $fopen and when the signal size is
> greater than the filename to be open. I've changed the code leaving the
> space conversion for middle zeros but I've removed the trailing ones.

I not sure this is really a bug. Verilog itself doesn't use a string 
terminator character. The relevant paragraph of the standard (1364-2005, 
section 3.6.2) says

"When a variable is larger than required to hold a string value being 
assigned, the value is right-justified, and the leftmost bits are padded with 
zeros, as is done with nonstring values. If a string is larger than the 
destination string variable, the string is right-justified, and the leftmost 
characters are truncated."

So if you write

   reg [8*8-1:0] str = "hello";

   initial $display("%h", str);

the expected output is

   00000068656c6c6f

i.e. all the zero padding is at the start of the string. The end of a string 
is always the character stored in the least significant bits of the string 
variable.

Unfortunately the standard is silent on how $display or vpi_get_value should 
handle null ASCII characters when formatting as a string. Clearly it is 
necessary to remove the leading nulls, but what happens after that seems to 
vary according to which simulator you use. The three choices seem to be:

1) Remove leading nulls and convert the remaining ones to spaces.
2) Remove all nulls.
3) Remove leading nulls and terminate at the first remaining null.

Currently Icarus follows option 1. FWIW, Verilog-XL follows option 1 if you 
use $display("%s", str), but option 2 if you use $display("%0s", str) or 
vpi_get_value.

Martin

[Iverilog-devel] Vhpi/vhpi and vhdl

[Jon T. <dos...@gm...>]

Hi all,

I am the author of Controlix, an operating system written in vhdl. I am
currently developing it using GHDL as the compiler, and the system
interface uses vhpi calls. Works OK on top of POSIX, but Icarus' vpp is
written in c instead of in ada, making a static linkage job for bare metal
targeting much more feasible.

Afaics from perusing the sources, neither vhpi or vpp are currently
supported by vhdlpp. If someone is already looking into writing support for
this, I'd be happy to test, otherwise I might be able to take a crack at it
myself (I have the coding time available).

Jon