iverilog-devel — Conversations on matters of Icarus Verilog development

Re: [Iverilog-devel] Icarus Verilog Snapshot 20150513

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

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

There are a few VHDL tests in the ivtest suite that fail. It's
possible that it's simply a matter of the ivtest not being updated
after I pulled a couple of your patches.

On 05/13/2015 11:44 AM, Maciej Sumi?ski wrote:
> On 05/13/2015 07:35 PM, Stephen Williams wrote:
>> 
>> I'm still thinking in terms of making a version 10 soon, but
>> I've made a snapshot first, here:
>> 
>> ftp://ftp.icarus.com/pub/eda/verilog/snapshots/iverilog-20150513.tar.gz
>>
>>
>> 
This is simply a dump of what was at the head of the master branch.
>> There are a few issues with the vhdl support, but in general
>> this should give a good idea of what's going to be in the
>> release.
> 
> Hi Steve,
> 
> What are the problems related to the VHDL support? Perhaps I could
> fix them before the new release. I have just run the test suite and
> there were no tests broken.
> 
> Regards, Orson
> 
>> Maybe the weekend of May 23/24 I may create a release branch?
>> 
>> 
>> ------------------------------------------------------------------------------
>>
>> 
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
>> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
>
> 
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

iEYEARECAAYFAlVTqzwACgkQrPt1Sc2b3il9KgCg5t7kuU7AI6cD0TVrEd7PCaX8
+McAnRGb9iWlwS4BXTqP0gGhGjo+7x/+
=sNp1
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] periodic updating of vcd file

[Joshua S. <kni...@gm...>]

I don't think I need it to output every simulation time step. I just don't
think it's flushing at all. The flush call returns true, but the file size
hasn't changed. I am not at all sure what is going on. I will try to play
with it a bit more. Otherwise, the only other solution I can think of is to
just close the file handle and reopen it, which definitely is updating the
vcd properly

On Wed, May 13, 2015 at 2:52 PM, Cary R. <cy...@ya...> wrote:

> Getting this back on the development list.
>
> Yes, VCD output is only output at the end of the simulation time step. It
> is not done interactively as the values change otherwise you would have a
> huge amount of excess data as values stabilize to their final value. I
> would not call this from the scheduler, but if needed do it as a final step
> when emitting VCD output for a given time step. I believe that is at the
> end of the variable_cb_2() call back routine.
>
> Cary
>
>
>
>   On Wednesday, May 13, 2015 11:43 AM, Joshua Street <
> kni...@gm...> wrote:
>
>
> so I think I'm still confused as to how to call the vpi callback functions
> from within schedule.cc.
>
> I thought that since these two functions were called in stop.cc that I
> could also call these and have it immediately flush.
>
>  invoke_command_const("$fflush");
>  invoke_command_const("$dumpflush");
>
> However, I think flush is the command I want. The only problem is that it
> doesn't seem to execute flush immediately.
>
> I'm guessing from trying to read the source that a callback handler is
> registered and that it is later called when vpiPostSim takes place.
>
>
>
>
>
>
>

Re: [Iverilog-devel] Icarus Verilog Snapshot 20150513

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

Hi Cary,

Thank you for the information. Which compiler do you use or what flags
cause the warning to appear? I have tried gcc 4.9.2/5.1.0 & clang 3.6.0
(all 64 bits) and none of them have displayed the message.

Regards,
Orson

On 05/13/2015 08:59 PM, Cary R. wrote:
> One thing I see when compiling under RHEL5 64-bit is I get the following warning:
> expression.cc: In copy constructor ‘ExpConditional::else_t::else_t(const ExpConditional::else_t&)’:
> expression.cc:313: warning: base class ‘class LineInfo’ should be explicitly initialized in the copy constructor
> Cary 
> 
> 
> 
>      On Wednesday, May 13, 2015 11:44 AM, Maciej Sumiński <mac...@ce...> wrote:
>    
> 
>  On 05/13/2015 07:35 PM, Stephen Williams wrote:
>>
>> I'm still thinking in terms of making a version 10 soon, but I've
>> made a snapshot first, here:
>>
>> ftp://ftp.icarus.com/pub/eda/verilog/snapshots/iverilog-20150513.tar.gz
>>
>> This is simply a dump of what was at the head of the master branch.
>> There are a few issues with the vhdl support, but in general this
>> should give a good idea of what's going to be in the release.
> 
> Hi Steve,
> 
> What are the problems related to the VHDL support? Perhaps I could fix
> them before the new release. I have just run the test suite and there
> were no tests broken.
> 
> Regards,
> Orson
> 
>> Maybe the weekend of May 23/24 I may create a release branch?
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
> 
> 
> ------------------------------------------------------------------------------
> 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
> 
> 
>   
> 
> 
> 
> ------------------------------------------------------------------------------
> 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] Icarus Verilog Snapshot 20150513

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

One thing I see when compiling under RHEL5 64-bit is I get the following warning:
expression.cc: In copy constructor ‘ExpConditional::else_t::else_t(const ExpConditional::else_t&)’:
expression.cc:313: warning: base class ‘class LineInfo’ should be explicitly initialized in the copy constructor
Cary 



     On Wednesday, May 13, 2015 11:44 AM, Maciej Sumiński <mac...@ce...> wrote:
   

 On 05/13/2015 07:35 PM, Stephen Williams wrote:
> 
> I'm still thinking in terms of making a version 10 soon, but I've
> made a snapshot first, here:
> 
> ftp://ftp.icarus.com/pub/eda/verilog/snapshots/iverilog-20150513.tar.gz
> 
> This is simply a dump of what was at the head of the master branch.
> There are a few issues with the vhdl support, but in general this
> should give a good idea of what's going to be in the release.

Hi Steve,

What are the problems related to the VHDL support? Perhaps I could fix
them before the new release. I have just run the test suite and there
were no tests broken.

Regards,
Orson

> Maybe the weekend of May 23/24 I may create a release branch?
> 
> 
> ------------------------------------------------------------------------------
> 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
> 


------------------------------------------------------------------------------
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] periodic updating of vcd file

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

Getting this back on the development list.

Yes, VCD output is only output at the end of the simulation time step. It is not done interactively as the values change otherwise you would have a huge amount of excess data as values stabilize to their final value. I would not call this from the scheduler, but if needed do it as a final step when emitting VCD output for a given time step. I believe that is at the end of the variable_cb_2() call back routine.
Cary
 


     On Wednesday, May 13, 2015 11:43 AM, Joshua Street <kni...@gm...> wrote:
   

 so I think I'm still confused as to how to call the vpi callback functions from within schedule.cc. 

I thought that since these two functions were called in stop.cc that I could also call these and have it immediately flush.
 invoke_command_const("$fflush"); invoke_command_const("$dumpflush");
However, I think flush is the command I want. The only problem is that it doesn't seem to execute flush immediately.

I'm guessing from trying to read the source that a callback handler is registered and that it is later called when vpiPostSim takes place.





  

Re: [Iverilog-devel] Icarus Verilog Snapshot 20150513

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

On 05/13/2015 07:35 PM, Stephen Williams wrote:
> 
> I'm still thinking in terms of making a version 10 soon, but I've
> made a snapshot first, here:
> 
> ftp://ftp.icarus.com/pub/eda/verilog/snapshots/iverilog-20150513.tar.gz
> 
> This is simply a dump of what was at the head of the master branch.
> There are a few issues with the vhdl support, but in general this
> should give a good idea of what's going to be in the release.

Hi Steve,

What are the problems related to the VHDL support? Perhaps I could fix
them before the new release. I have just run the test suite and there
were no tests broken.

Regards,
Orson

> Maybe the weekend of May 23/24 I may create a release branch?
> 
> 
> ------------------------------------------------------------------------------
> 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] periodic updating of vcd file

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

Is there a reason $dumpflush() does not work? If you wanted to maximize the likelihood of the file having all the data you could add a call to $dumpflush() whenever time advanced, but you are still left with the buffering that normally happens during writing data for a specific time step. I use GTKWave and reload data all the time without doing anything extra, but I am usually generating a fair amount of data at every time step.
Cary
 


     On Wednesday, May 13, 2015 11:08 AM, Guy Hutchison <ghu...@gm...> wrote:
   

 Periodic updates allow you to track the progress of the simulation while it is still running.  To do this you need to leave the VCD file in a consistent state, the in the waveform viewer you can reload to see recent updates.

I believe other simulators do this based on wall clock time or the amount of buffered write data they have.

Guy

> On May 13, 2015, at 8:42 AM, Stephen Williams <st...@ic...> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> The VCD reading and writing is not done in the vvp program, but in
> the system.vpi that the vvp program loads at run time. That means
> you cannot access arbitrary functions in the system.vpi from within
> the schedule.cc file.
> 
> Anyhow, it is not at all clear what problem you are trying to solve,
> and why you are trying to solve it by tapping into the scheduler.
> 
>> On 05/12/2015 10:37 PM, Joshua Street wrote:
>> Dear Sirs:
>> 
>> I am trying to add periodic updates to the vcd file output by
>> icarus during simulation using vvp.exe.  I want to be able to
>> update the file so I can read it with another vcd program, but I
>> need to call fclose on the dumpfile in sys_vcd.c
>> 
>> Sorry but I'm a noob at coding in c++, so any help would be deeply 
>> appreciated.
>> 
>> I am wondering what the best way to get access to this function is.
>> 
>> 
>> I tried to add a header called sys_vcd.h to the vpi folder. This
>> just contained an extern declaration of the function that I wanted
>> access to in sys_vcd.c. However, i also added a string so that I
>> could make sure it was working.
>> 
>> extern void reopen_dumpfile(void); char cake[] = "WHAT IS UP";
>> 
>> 
>> I then included the file in vvp/schedule.cc. I found that I could
>> access the string from schedule.cc but not the function. I assume
>> this is because I initialized the string in the header, but the
>> actual definition of the function is contained in sys_vcd.c.
>> 
>> How do I go about giving myself access to this function? As I
>> remember, I think to get the actual definition, I need access to
>> the object file sys_vcd.o.
>> 
>> S I thought I could just change the makefile in the vvp folder like
>> so:
>> 
>> V = vpi_modules.o vpi_callback.o vpi_const.o vpi_event.o
>> vpi_iter.o vpi_mcd.o \ vpi_priv.o vpi_scope.o vpi_real.o
>> vpi_signal.o vpi_tasks.o vpi_time.o \ vpi_vthr_vector.o vpip_bin.o
>> vpip_hex.o vpip_oct.o \ vpip_to_dec.o vpip_format.o vvp_vpi.o
>> ../vpi/sys_vcd.o
>> 
>> 
>> but this didn't work. the makefile gives some error message: mv:
>> cannot move ../vpi/sys_vcd.d to dep/../vpi/sys_vcd.d : no such
>> file or directory.
>> 
>> I have no idea what this error means. I feel like the object file
>> should contain the definition of the function I added to the
>> header.
>> 
>> Does anyone know what i'm doing wrong? i feel like it's really
>> obvious, but I'm stumped.
>> 
>> Also I get the feeling that probably the original intent of the
>> icarus developers was for me not to access vpi headers from inside
>> the vvp folder. Should I add a function to the vpi library instead?
>> I know it already handles commands like $dumpflush, $dumpvars,
>> etc.
>> 
>> Regardless, I just want the ability to regularly flush and close
>> the vcd file so that it updates with new data periodically or when
>> a pause command is sent. then I could update the graph with this
>> updated vcd file.
> 
> 
> - -- 
> 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
> 
> iEYEARECAAYFAlVTcMwACgkQrPt1Sc2b3inGzQCcDeflidS2ofd/uFrJWQG4Tf2E
> qLYAnjQu3jA6Isvo5tsrRuJ44pVAEjL4
> =iuel
> -----END PGP SIGNATURE-----
> 
> ------------------------------------------------------------------------------
> 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

------------------------------------------------------------------------------
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] periodic updating of vcd file

[Guy H. <ghu...@gm...>]

Periodic updates allow you to track the progress of the simulation while it is still running.  To do this you need to leave the VCD file in a consistent state, the in the waveform viewer you can reload to see recent updates.

I believe other simulators do this based on wall clock time or the amount of buffered write data they have.

Guy

> On May 13, 2015, at 8:42 AM, Stephen Williams <st...@ic...> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> The VCD reading and writing is not done in the vvp program, but in
> the system.vpi that the vvp program loads at run time. That means
> you cannot access arbitrary functions in the system.vpi from within
> the schedule.cc file.
> 
> Anyhow, it is not at all clear what problem you are trying to solve,
> and why you are trying to solve it by tapping into the scheduler.
> 
>> On 05/12/2015 10:37 PM, Joshua Street wrote:
>> Dear Sirs:
>> 
>> I am trying to add periodic updates to the vcd file output by
>> icarus during simulation using vvp.exe.  I want to be able to
>> update the file so I can read it with another vcd program, but I
>> need to call fclose on the dumpfile in sys_vcd.c
>> 
>> Sorry but I'm a noob at coding in c++, so any help would be deeply 
>> appreciated.
>> 
>> I am wondering what the best way to get access to this function is.
>> 
>> 
>> I tried to add a header called sys_vcd.h to the vpi folder. This
>> just contained an extern declaration of the function that I wanted
>> access to in sys_vcd.c. However, i also added a string so that I
>> could make sure it was working.
>> 
>> extern void reopen_dumpfile(void); char cake[] = "WHAT IS UP";
>> 
>> 
>> I then included the file in vvp/schedule.cc. I found that I could
>> access the string from schedule.cc but not the function. I assume
>> this is because I initialized the string in the header, but the
>> actual definition of the function is contained in sys_vcd.c.
>> 
>> How do I go about giving myself access to this function? As I
>> remember, I think to get the actual definition, I need access to
>> the object file sys_vcd.o.
>> 
>> S I thought I could just change the makefile in the vvp folder like
>> so:
>> 
>> V = vpi_modules.o vpi_callback.o vpi_const.o vpi_event.o
>> vpi_iter.o vpi_mcd.o \ vpi_priv.o vpi_scope.o vpi_real.o
>> vpi_signal.o vpi_tasks.o vpi_time.o \ vpi_vthr_vector.o vpip_bin.o
>> vpip_hex.o vpip_oct.o \ vpip_to_dec.o vpip_format.o vvp_vpi.o
>> ../vpi/sys_vcd.o
>> 
>> 
>> but this didn't work. the makefile gives some error message: mv:
>> cannot move ../vpi/sys_vcd.d to dep/../vpi/sys_vcd.d : no such
>> file or directory.
>> 
>> I have no idea what this error means. I feel like the object file
>> should contain the definition of the function I added to the
>> header.
>> 
>> Does anyone know what i'm doing wrong? i feel like it's really
>> obvious, but I'm stumped.
>> 
>> Also I get the feeling that probably the original intent of the
>> icarus developers was for me not to access vpi headers from inside
>> the vvp folder. Should I add a function to the vpi library instead?
>> I know it already handles commands like $dumpflush, $dumpvars,
>> etc.
>> 
>> Regardless, I just want the ability to regularly flush and close
>> the vcd file so that it updates with new data periodically or when
>> a pause command is sent. then I could update the graph with this
>> updated vcd file.
> 
> 
> - -- 
> 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
> 
> iEYEARECAAYFAlVTcMwACgkQrPt1Sc2b3inGzQCcDeflidS2ofd/uFrJWQG4Tf2E
> qLYAnjQu3jA6Isvo5tsrRuJ44pVAEjL4
> =iuel
> -----END PGP SIGNATURE-----
> 
> ------------------------------------------------------------------------------
> 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] Icarus Verilog Snapshot 20150513

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

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


I'm still thinking in terms of making a version 10 soon, but I've
made a snapshot first, here:

ftp://ftp.icarus.com/pub/eda/verilog/snapshots/iverilog-20150513.tar.gz

This is simply a dump of what was at the head of the master branch.
There are a few issues with the vhdl support, but in general this
should give a good idea of what's going to be in the release.

Maybe the weekend of May 23/24 I may create a release branch?

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

iEYEARECAAYFAlVTi2MACgkQrPt1Sc2b3inuOwCbBoIrPsPFZJT2RXvEMZP/hGdg
/ToAniYOnGkt234tM9sKjy9DCLpgZwro
=Riyh
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] periodic update of vcd file.

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

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


There is the existing $dumpflush command. If it doesn't flush the
data out to the file, then adding an fflush() in there somewhere
should do the trick.

I do not, in general, think the scheduler should be flushing the
vcd output, that could potentially be a nasty performance hit. But
I see where you are coming from, you want to sometimes flush and
refresh an interactive display. I can think of a couple ways of
handling that, but the easiest I think is to somehow decide at the
start that you want unbuffered output (for example, a +arg to vvp)
and turn off buffering to the fopened stream that the vcd dumper
uses.

On 05/13/2015 09:52 AM, Joshua Street wrote:
> I am trying to hook icarus into a graphviewer program, but I would 
> like to be able to periodically update what's on screen.  And yes, 
> I realized that I am probably not intended to make files in vvp 
> reliant on those in the vpi folder.
> 
> Is there a recommended path that I could use? I notice that in the 
> stop handler of vvp you call the $dumpflush command. Anyway after 
> reading a bit more of the documentation, I think the best way to 
> get the behavior I want might be to just add a command to the vpi 
> library and then call it.

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

iEYEARECAAYFAlVThJgACgkQrPt1Sc2b3ins2QCgk3REPAV19Wef5R/EdXUD6d0K
bhEAoMwY8VDTOailIat47SOzW3vfeqaI
=TArt
-----END PGP SIGNATURE-----

[Iverilog-devel] periodic update of vcd file.

[Joshua S. <kni...@gm...>]

I am trying to hook icarus into a graphviewer program, but I would like to
be able to periodically update what's on screen.  And yes, I realized that
I am probably not intended to make files in vvp reliant on those in the vpi
folder.

Is there a recommended path that I could use? I notice that in the stop
handler of vvp you call the $dumpflush command. Anyway after reading a bit
more of the documentation, I think the best way to get the behavior I want
might be to just add a command to the vpi library and then call it.




On Wed, May 13, 2015 at 11:42 AM, <
ive...@li...> wrote:

> Send Iverilog-devel mailing list submissions to
>         ive...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.sourceforge.net/lists/listinfo/iverilog-devel
> or, via email, send a message with subject or body 'help' to
>         ive...@li...
>
> You can reach the person managing the list at
>         ive...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Iverilog-devel digest..."
>
>
> Today's Topics:
>
>    1. Re: Icarus keys in the Windows registry (Martin Whitaker)
>    2. Do we still support systems without inttypes.h? (Martin Whitaker)
>    3. Re: Do we still support systems without inttypes.h?
>       (Stephen Williams)
>    4. Re: MinGW builds (Martin Whitaker)
>    5. periodic updating of vcd file (Joshua Street)
>    6. Re: periodic updating of vcd file (Stephen Williams)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 08 May 2015 08:33:33 +0100
> From: Martin Whitaker <mai...@ma...>
> Subject: Re: [Iverilog-devel] Icarus keys in the Windows registry
> To: Discussions concerning Icarus Verilog development
>         <ive...@li...>
> Message-ID: <554...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Michael Strelnikov wrote:
> > I'm not sure about storing in .ini file is a good idea either.
> > Sometimes this path can be changed and user will have a hard time
> wondering
> > why simulations stopped working.
> >
> iverilog-vpi does check whether the C compiler can be found on the
> currently
> stored path, and outputs an informative message if not.
>
> The logic I've implemented is:
>
>    - If -mingw=path is supplied alone on the command line, the
>      path is stored in the registry as before. If access is
>      denied, a message is output that suggests running as
>      administrator.
>
>    - If -mingw=path is supplied with a list of source files, it
>      is used as the path for that run only and not stored in the
>      registry.
>
>    - If -mingw=path is not supplied, iverilog-vpi first looks in
>      the registry, and if a path is stored there, uses that. If
>      there is no entry in the registry, it seaches the system path.
>      If the C compiler is not found on the system path, it outputs
>      an informative message and quits.
>
> Hopefully this will satisfy all parties.
>
> I've removed the -ivl option, and made iverilog-vpi automatically extract
> the
> IVL root directory from the location of the .exe file, exactly as vvp does.
>
> Martin
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 08 May 2015 08:42:31 +0100
> From: Martin Whitaker <mai...@ma...>
> Subject: [Iverilog-devel] Do we still support systems without
>         inttypes.h?
> To: Discussions concerning Icarus Verilog development
>         <ive...@li...>
> Message-ID: <554...@ma...>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> There are a number of places in the Icarus code where a pointer is cast to
> an
> integer or vice versa. Currently the code uses a long or unsigned long
> integer
> for the purpose. This doesn't work in 64-bit Windows, because the Windows
> ABI
> requires long integers to be 32 bits. The proper solution is to use the
> intptr_t or uintptr_t types.
>
> In parts of the Icarus code, there are tests for HAVE_INTTYPES_H, but in
> other
> parts things from inttypes.h (e.g. int64_t and uint64_t) are used
> unconditionally. What is the current policy on this?
>
> I would guess that any compiler that supports the C++ features we use is
> also
> going to have inttypes.h.
>
> Martin
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 08 May 2015 08:04:37 -0700
> From: Stephen Williams <st...@ic...>
> Subject: Re: [Iverilog-devel] Do we still support systems without
>         inttypes.h?
> To: ive...@li...
> Message-ID: <554...@ic...>
> Content-Type: text/plain; charset=windows-1252
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> I think in this day and age, inttypes.h or stdint.h can be assumed
> to be present.
>
> On 05/08/2015 12:42 AM, Martin Whitaker wrote:
> > There are a number of places in the Icarus code where a pointer is
> > cast to an integer or vice versa. Currently the code uses a long or
> > unsigned long integer for the purpose. This doesn't work in 64-bit
> > Windows, because the Windows ABI requires long integers to be 32
> > bits. The proper solution is to use the intptr_t or uintptr_t
> > types.
> >
> > In parts of the Icarus code, there are tests for HAVE_INTTYPES_H,
> > but in other parts things from inttypes.h (e.g. int64_t and
> > uint64_t) are used unconditionally. What is the current policy on
> > this?
> >
> > I would guess that any compiler that supports the C++ features we
> > use is also going to have inttypes.h.
>
>
> - --
> 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
>
> iEYEARECAAYFAlVM0IUACgkQrPt1Sc2b3ilGwQCeKxD/IE5g9aU0TPoSTi40nuK4
> Q5cAn2YKMxeUYh61Grtp3QRNHmA7772y
> =iLxl
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 10 May 2015 23:54:01 +0100
> From: Martin Whitaker <mai...@ma...>
> Subject: Re: [Iverilog-devel] MinGW builds
> To: "Cary R." <cy...@ya...>,      Discussions concerning Icarus
>         Verilog development     <ive...@li...>
> Message-ID: <554...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Cary R. wrote:
> > 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.
> >
> I have updated the wiki and fixed the development branch to support both
> 32-bit and 64-bit builds. v0.9 can also be built with MSYS2, but I've not
> back-ported the changes to support 64-bit builds (on the basis we are
> releasing v10 soon).
>
> Doing this has allowed me to remove a lot of the MinGW workarounds from the
> code base and has reduced the number of tests that fail with MinGW. I've
> updated the test suite README file to reflect this.
>
> None of the changes I've made prevent building with the original MinGW
> (providing you use a reasonably up-to-date version), but a new
> incompatibility
> has crept into the code base - using %z in sscanf calls, which the original
> MinGW does not support. If Pablo does want to continue using the original
> MinGW, the simple fix is for him to replace %z with %.
>
> Martin
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 13 May 2015 01:37:51 -0400
> From: Joshua Street <kni...@gm...>
> Subject: [Iverilog-devel] periodic updating of vcd file
> To: ive...@li...
> Message-ID:
>         <
> CAL...@ma...>
> Content-Type: text/plain; charset="utf-8"
>
> Dear Sirs:
>
> I am trying to add periodic updates to the vcd file output by icarus during
> simulation using vvp.exe.  I want to be able to update the file so I can
> read it with another vcd program, but I need to call fclose on the dumpfile
> in sys_vcd.c
>
> Sorry but I'm a noob at coding in c++, so any help would be deeply
> appreciated.
>
> I am wondering what the best way to get access to this function is.
>
> I tried to add a header called sys_vcd.h to the vpi folder. This just
> contained an extern declaration of the function that I wanted access to in
> sys_vcd.c. However, i also added a string so that I could make sure it was
> working.
>
> extern void reopen_dumpfile(void);
> char cake[] = "WHAT IS UP";
>
>
> I then included the file in vvp/schedule.cc. I found that I could access
> the string from schedule.cc but not the function. I assume this is because
> I initialized the string in the header, but the actual definition of the
> function is contained in sys_vcd.c.
>
> How do I go about giving myself access to this function? As I remember, I
> think to get the actual definition, I need access to the object file
> sys_vcd.o.
>
> S I thought I could just change the makefile in the vvp folder like so:
>
> V = vpi_modules.o vpi_callback.o vpi_const.o vpi_event.o vpi_iter.o
> vpi_mcd.o \
> vpi_priv.o vpi_scope.o vpi_real.o vpi_signal.o vpi_tasks.o vpi_time.o \
> vpi_vthr_vector.o vpip_bin.o vpip_hex.o vpip_oct.o \
> vpip_to_dec.o vpip_format.o vvp_vpi.o ../vpi/sys_vcd.o
>
>
> but this didn't work. the makefile gives some error message:
> mv: cannot move ../vpi/sys_vcd.d to dep/../vpi/sys_vcd.d : no such file or
> directory.
>
> I have no idea what this error means. I feel like the object file should
> contain the definition of the function I added to the header.
>
> Does anyone know what i'm doing wrong? i feel like it's really obvious, but
> I'm stumped.
>
> Also I get the feeling that probably the original intent of the icarus
> developers was for me not to access vpi headers from inside the vvp folder.
> Should I add a function to the vpi library instead? I know it already
> handles commands like $dumpflush, $dumpvars, etc.
>
> Regardless, I just want the ability to regularly flush and close the vcd
> file so that it updates with new data periodically or when a pause command
> is sent. then I could update the graph with this updated vcd file.
>
>
> Josh
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 6
> Date: Wed, 13 May 2015 08:42:04 -0700
> From: Stephen Williams <st...@ic...>
> Subject: Re: [Iverilog-devel] periodic updating of vcd file
> To: ive...@li...
> Message-ID: <555...@ic...>
> Content-Type: text/plain; charset=windows-1252
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> The VCD reading and writing is not done in the vvp program, but in
> the system.vpi that the vvp program loads at run time. That means
> you cannot access arbitrary functions in the system.vpi from within
> the schedule.cc file.
>
> Anyhow, it is not at all clear what problem you are trying to solve,
> and why you are trying to solve it by tapping into the scheduler.
>
> On 05/12/2015 10:37 PM, Joshua Street wrote:
> > Dear Sirs:
> >
> > I am trying to add periodic updates to the vcd file output by
> > icarus during simulation using vvp.exe.  I want to be able to
> > update the file so I can read it with another vcd program, but I
> > need to call fclose on the dumpfile in sys_vcd.c
> >
> > Sorry but I'm a noob at coding in c++, so any help would be deeply
> > appreciated.
> >
> > I am wondering what the best way to get access to this function is.
> >
> >
> > I tried to add a header called sys_vcd.h to the vpi folder. This
> > just contained an extern declaration of the function that I wanted
> > access to in sys_vcd.c. However, i also added a string so that I
> > could make sure it was working.
> >
> > extern void reopen_dumpfile(void); char cake[] = "WHAT IS UP";
> >
> >
> > I then included the file in vvp/schedule.cc. I found that I could
> > access the string from schedule.cc but not the function. I assume
> > this is because I initialized the string in the header, but the
> > actual definition of the function is contained in sys_vcd.c.
> >
> > How do I go about giving myself access to this function? As I
> > remember, I think to get the actual definition, I need access to
> > the object file sys_vcd.o.
> >
> > S I thought I could just change the makefile in the vvp folder like
> > so:
> >
> > V = vpi_modules.o vpi_callback.o vpi_const.o vpi_event.o
> > vpi_iter.o vpi_mcd.o \ vpi_priv.o vpi_scope.o vpi_real.o
> > vpi_signal.o vpi_tasks.o vpi_time.o \ vpi_vthr_vector.o vpip_bin.o
> > vpip_hex.o vpip_oct.o \ vpip_to_dec.o vpip_format.o vvp_vpi.o
> > ../vpi/sys_vcd.o
> >
> >
> > but this didn't work. the makefile gives some error message: mv:
> > cannot move ../vpi/sys_vcd.d to dep/../vpi/sys_vcd.d : no such
> > file or directory.
> >
> > I have no idea what this error means. I feel like the object file
> > should contain the definition of the function I added to the
> > header.
> >
> > Does anyone know what i'm doing wrong? i feel like it's really
> > obvious, but I'm stumped.
> >
> > Also I get the feeling that probably the original intent of the
> > icarus developers was for me not to access vpi headers from inside
> > the vvp folder. Should I add a function to the vpi library instead?
> > I know it already handles commands like $dumpflush, $dumpvars,
> > etc.
> >
> > Regardless, I just want the ability to regularly flush and close
> > the vcd file so that it updates with new data periodically or when
> > a pause command is sent. then I could update the graph with this
> > updated vcd file.
>
>
> - --
> 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
>
> iEYEARECAAYFAlVTcMwACgkQrPt1Sc2b3inGzQCcDeflidS2ofd/uFrJWQG4Tf2E
> qLYAnjQu3jA6Isvo5tsrRuJ44pVAEjL4
> =iuel
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> 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
>
>
> End of Iverilog-devel Digest, Vol 88, Issue 4
> *********************************************
>

Re: [Iverilog-devel] periodic updating of vcd file

[J F. <jfi...@sb...>]

The error cannot move is pretty simple. Do an ls of that directory and you will see that the source file does not exist.

Sent from Yahoo Mail on Android

From:"Joshua Street" <kni...@gm...>
Date:Wed, May 13, 2015 at 8:36 AM
Subject:[Iverilog-devel] periodic updating of vcd file

Dear Sirs: 


I am trying to add periodic updates to the vcd file output by icarus during simulation using vvp.exe.  I want to be able to update the file so I can read it with another vcd program, but I need to call fclose on the dumpfile in sys_vcd.c


Sorry but I'm a noob at coding in c++, so any help would be deeply appreciated.


I am wondering what the best way to get access to this function is.  


I tried to add a header called sys_vcd.h to the vpi folder. This just contained an extern declaration of the function that I wanted access to in sys_vcd.c. However, i also added a string so that I could make sure it was working.  


extern void reopen_dumpfile(void);

char cake[] = "WHAT IS UP";



I then included the file in vvp/schedule.cc. I found that I could access the string from schedule.cc but not the function. I assume this is because I initialized the string in the header, but the actual definition of the function is contained in sys_vcd.c.  


How do I go about giving myself access to this function? As I remember, I think to get the actual definition, I need access to the object file sys_vcd.o.


S I thought I could just change the makefile in the vvp folder like so:


V = vpi_modules.o vpi_callback.o vpi_const.o vpi_event.o vpi_iter.o vpi_mcd.o \

vpi_priv.o vpi_scope.o vpi_real.o vpi_signal.o vpi_tasks.o vpi_time.o \

vpi_vthr_vector.o vpip_bin.o vpip_hex.o vpip_oct.o \

vpip_to_dec.o vpip_format.o vvp_vpi.o ../vpi/sys_vcd.o



but this didn't work. the makefile gives some error message:

mv: cannot move ../vpi/sys_vcd.d to dep/../vpi/sys_vcd.d : no such file or directory.


I have no idea what this error means. I feel like the object file should contain the definition of the function I added to the header.


Does anyone know what i'm doing wrong? i feel like it's really obvious, but I'm stumped. 


Also I get the feeling that probably the original intent of the icarus developers was for me not to access vpi headers from inside the vvp folder. Should I add a function to the vpi library instead? I know it already handles commands like $dumpflush, $dumpvars, etc.


Regardless, I just want the ability to regularly flush and close the vcd file so that it updates with new data periodically or when a pause command is sent. then I could update the graph with this updated vcd file.



Josh

Re: [Iverilog-devel] periodic updating of vcd file

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

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


The VCD reading and writing is not done in the vvp program, but in
the system.vpi that the vvp program loads at run time. That means
you cannot access arbitrary functions in the system.vpi from within
the schedule.cc file.

Anyhow, it is not at all clear what problem you are trying to solve,
and why you are trying to solve it by tapping into the scheduler.

On 05/12/2015 10:37 PM, Joshua Street wrote:
> Dear Sirs:
> 
> I am trying to add periodic updates to the vcd file output by
> icarus during simulation using vvp.exe.  I want to be able to
> update the file so I can read it with another vcd program, but I
> need to call fclose on the dumpfile in sys_vcd.c
> 
> Sorry but I'm a noob at coding in c++, so any help would be deeply 
> appreciated.
> 
> I am wondering what the best way to get access to this function is.
> 
> 
> I tried to add a header called sys_vcd.h to the vpi folder. This
> just contained an extern declaration of the function that I wanted
> access to in sys_vcd.c. However, i also added a string so that I
> could make sure it was working.
> 
> extern void reopen_dumpfile(void); char cake[] = "WHAT IS UP";
> 
> 
> I then included the file in vvp/schedule.cc. I found that I could
> access the string from schedule.cc but not the function. I assume
> this is because I initialized the string in the header, but the
> actual definition of the function is contained in sys_vcd.c.
> 
> How do I go about giving myself access to this function? As I
> remember, I think to get the actual definition, I need access to
> the object file sys_vcd.o.
> 
> S I thought I could just change the makefile in the vvp folder like
> so:
> 
> V = vpi_modules.o vpi_callback.o vpi_const.o vpi_event.o
> vpi_iter.o vpi_mcd.o \ vpi_priv.o vpi_scope.o vpi_real.o
> vpi_signal.o vpi_tasks.o vpi_time.o \ vpi_vthr_vector.o vpip_bin.o
> vpip_hex.o vpip_oct.o \ vpip_to_dec.o vpip_format.o vvp_vpi.o
> ../vpi/sys_vcd.o
> 
> 
> but this didn't work. the makefile gives some error message: mv:
> cannot move ../vpi/sys_vcd.d to dep/../vpi/sys_vcd.d : no such
> file or directory.
> 
> I have no idea what this error means. I feel like the object file
> should contain the definition of the function I added to the
> header.
> 
> Does anyone know what i'm doing wrong? i feel like it's really
> obvious, but I'm stumped.
> 
> Also I get the feeling that probably the original intent of the
> icarus developers was for me not to access vpi headers from inside
> the vvp folder. Should I add a function to the vpi library instead?
> I know it already handles commands like $dumpflush, $dumpvars,
> etc.
> 
> Regardless, I just want the ability to regularly flush and close
> the vcd file so that it updates with new data periodically or when
> a pause command is sent. then I could update the graph with this
> updated vcd file.


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

iEYEARECAAYFAlVTcMwACgkQrPt1Sc2b3inGzQCcDeflidS2ofd/uFrJWQG4Tf2E
qLYAnjQu3jA6Isvo5tsrRuJ44pVAEjL4
=iuel
-----END PGP SIGNATURE-----

[Iverilog-devel] periodic updating of vcd file

[Joshua S. <kni...@gm...>]

Dear Sirs:

I am trying to add periodic updates to the vcd file output by icarus during
simulation using vvp.exe.  I want to be able to update the file so I can
read it with another vcd program, but I need to call fclose on the dumpfile
in sys_vcd.c

Sorry but I'm a noob at coding in c++, so any help would be deeply
appreciated.

I am wondering what the best way to get access to this function is.

I tried to add a header called sys_vcd.h to the vpi folder. This just
contained an extern declaration of the function that I wanted access to in
sys_vcd.c. However, i also added a string so that I could make sure it was
working.

extern void reopen_dumpfile(void);
char cake[] = "WHAT IS UP";


I then included the file in vvp/schedule.cc. I found that I could access
the string from schedule.cc but not the function. I assume this is because
I initialized the string in the header, but the actual definition of the
function is contained in sys_vcd.c.

How do I go about giving myself access to this function? As I remember, I
think to get the actual definition, I need access to the object file
sys_vcd.o.

S I thought I could just change the makefile in the vvp folder like so:

V = vpi_modules.o vpi_callback.o vpi_const.o vpi_event.o vpi_iter.o
vpi_mcd.o \
vpi_priv.o vpi_scope.o vpi_real.o vpi_signal.o vpi_tasks.o vpi_time.o \
vpi_vthr_vector.o vpip_bin.o vpip_hex.o vpip_oct.o \
vpip_to_dec.o vpip_format.o vvp_vpi.o ../vpi/sys_vcd.o


but this didn't work. the makefile gives some error message:
mv: cannot move ../vpi/sys_vcd.d to dep/../vpi/sys_vcd.d : no such file or
directory.

I have no idea what this error means. I feel like the object file should
contain the definition of the function I added to the header.

Does anyone know what i'm doing wrong? i feel like it's really obvious, but
I'm stumped.

Also I get the feeling that probably the original intent of the icarus
developers was for me not to access vpi headers from inside the vvp folder.
Should I add a function to the vpi library instead? I know it already
handles commands like $dumpflush, $dumpvars, etc.

Regardless, I just want the ability to regularly flush and close the vcd
file so that it updates with new data periodically or when a pause command
is sent. then I could update the graph with this updated vcd file.


Josh

Re: [Iverilog-devel] MinGW builds

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

Cary R. wrote:
> 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.
>
I have updated the wiki and fixed the development branch to support both 
32-bit and 64-bit builds. v0.9 can also be built with MSYS2, but I've not 
back-ported the changes to support 64-bit builds (on the basis we are 
releasing v10 soon).

Doing this has allowed me to remove a lot of the MinGW workarounds from the 
code base and has reduced the number of tests that fail with MinGW. I've 
updated the test suite README file to reflect this.

None of the changes I've made prevent building with the original MinGW 
(providing you use a reasonably up-to-date version), but a new incompatibility 
has crept into the code base - using %z in sscanf calls, which the original 
MinGW does not support. If Pablo does want to continue using the original 
MinGW, the simple fix is for him to replace %z with %.

Martin

Re: [Iverilog-devel] Do we still support systems without inttypes.h?

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

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


I think in this day and age, inttypes.h or stdint.h can be assumed
to be present.

On 05/08/2015 12:42 AM, Martin Whitaker wrote:
> There are a number of places in the Icarus code where a pointer is
> cast to an integer or vice versa. Currently the code uses a long or
> unsigned long integer for the purpose. This doesn't work in 64-bit
> Windows, because the Windows ABI requires long integers to be 32
> bits. The proper solution is to use the intptr_t or uintptr_t
> types.
> 
> In parts of the Icarus code, there are tests for HAVE_INTTYPES_H,
> but in other parts things from inttypes.h (e.g. int64_t and
> uint64_t) are used unconditionally. What is the current policy on
> this?
> 
> I would guess that any compiler that supports the C++ features we
> use is also going to have inttypes.h.


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

iEYEARECAAYFAlVM0IUACgkQrPt1Sc2b3ilGwQCeKxD/IE5g9aU0TPoSTi40nuK4
Q5cAn2YKMxeUYh61Grtp3QRNHmA7772y
=iLxl
-----END PGP SIGNATURE-----

[Iverilog-devel] Do we still support systems without inttypes.h?

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

There are a number of places in the Icarus code where a pointer is cast to an 
integer or vice versa. Currently the code uses a long or unsigned long integer 
for the purpose. This doesn't work in 64-bit Windows, because the Windows ABI 
requires long integers to be 32 bits. The proper solution is to use the 
intptr_t or uintptr_t types.

In parts of the Icarus code, there are tests for HAVE_INTTYPES_H, but in other 
parts things from inttypes.h (e.g. int64_t and uint64_t) are used 
unconditionally. What is the current policy on this?

I would guess that any compiler that supports the C++ features we use is also 
going to have inttypes.h.

Martin

Re: [Iverilog-devel] Icarus keys in the Windows registry

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

Michael Strelnikov wrote:
> I'm not sure about storing in .ini file is a good idea either.
> Sometimes this path can be changed and user will have a hard time wondering
> why simulations stopped working.
>
iverilog-vpi does check whether the C compiler can be found on the currently 
stored path, and outputs an informative message if not.

The logic I've implemented is:

   - If -mingw=path is supplied alone on the command line, the
     path is stored in the registry as before. If access is
     denied, a message is output that suggests running as
     administrator.

   - If -mingw=path is supplied with a list of source files, it
     is used as the path for that run only and not stored in the
     registry.

   - If -mingw=path is not supplied, iverilog-vpi first looks in
     the registry, and if a path is stored there, uses that. If
     there is no entry in the registry, it seaches the system path.
     If the C compiler is not found on the system path, it outputs
     an informative message and quits.

Hopefully this will satisfy all parties.

I've removed the -ivl option, and made iverilog-vpi automatically extract the 
IVL root directory from the location of the .exe file, exactly as vvp does.

Martin

Re: [Iverilog-devel] vhdlpp update

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

On 04/26/2015 05:33 PM, Stephen Williams wrote:
[..]
> 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.

Thank you for the suggestion. I have updated the branch [1] and extended
its test [2] to check logical operators.

To simplify things, I kept boolean type as VTypePrimitive instead of
VTypeEnum, and simply generated a header:

`ifndef __VHDL_STD_TYPES
`define __VHDL_STD_TYPES
typedef enum bit { \false , \true } boolean ;
`endif

It is important to use directives here to avoid multiple definitions.
Alternatively, I could turn boolean type into VTypeEnum, but I would
still need directives to have it defined only once, so I am not sure if
this could look better in the code (i.e. a dedicated if to output
boolean definition).

Unfortunately, this will not allow evil designers to name their signals
'true' and 'false', because even if VHDL accepts it, SystemVerilog is a
little bit more sane and objects to signals and enum values having the
same name.

Regards,
Orson

1. https://github.com/steveicarus/iverilog/pull/67
2. https://github.com/orsonmmz/ivtest/tree/boolean_test

Re: [Iverilog-devel] Icarus keys in the Windows registry

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

I'm not sure about storing in .ini file is a good idea either.
Sometimes this path can be changed and user will have a hard time wondering
why simulations stopped working.

Best regards,
Michael Strelnikov

On 7 May 2015 at 09:46, Martin Whitaker <mai...@ma...>
wrote:

> Stephen Williams wrote:
> > Ironically, after re-reading this post, I realized that setting the
> > path is exactly what we expect of users in order to get access to
> > the iverilog-vpi  tool in the first place. So, logic fail on my part.
> >
> > Still, it was my choice in the first place to locate the mingw tools
> > via the registry (not that I ever really use Windows) and my thinking
> > was to simplify the experience as much as possible, and also to not
> > pollute the users path any more then necessary. So if not a registry
> > entry, perhaps a .ini file in the iverilog install directory?
> >
> Users who have installed the MinGW compiler will most likely have added it
> to
> their path already - otherwise they won't be able to use it to compile C
> programs. In this case the current procedure complicates the user
> experience,
> because they have to run iverilog-vpi to set a path that is already known
> to
> the system. So I suggest a better solution is to first search the current
> path
> for the MinGW compiler, and if it is not found, prompt the user to enter a
> path and store it in a .ini file for future use.
>
> 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
>

Re: [Iverilog-devel] Icarus keys in the Windows registry

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

Stephen Williams wrote:
> Ironically, after re-reading this post, I realized that setting the
> path is exactly what we expect of users in order to get access to
> the iverilog-vpi  tool in the first place. So, logic fail on my part.
>
> Still, it was my choice in the first place to locate the mingw tools
> via the registry (not that I ever really use Windows) and my thinking
> was to simplify the experience as much as possible, and also to not
> pollute the users path any more then necessary. So if not a registry
> entry, perhaps a .ini file in the iverilog install directory?
>
Users who have installed the MinGW compiler will most likely have added it to 
their path already - otherwise they won't be able to use it to compile C 
programs. In this case the current procedure complicates the user experience, 
because they have to run iverilog-vpi to set a path that is already known to 
the system. So I suggest a better solution is to first search the current path 
for the MinGW compiler, and if it is not found, prompt the user to enter a 
path and store it in a .ini file for future use.

Martin

Re: [Iverilog-devel] Icarus keys in the Windows registry

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

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


Ironically, after re-reading this post, I realized that setting the
path is exactly what we expect of users in order to get access to
the iverilog-vpi  tool in the first place. So, logic fail on my part.

Still, it was my choice in the first place to locate the mingw tools
via the registry (not that I ever really use Windows) and my thinking
was to simplify the experience as much as possible, and also to not
pollute the users path any more then necessary. So if not a registry
entry, perhaps a .ini file in the iverilog install directory?


On 05/06/2015 07:39 AM, Stephen Williams wrote:
> 
> It is absolutely NOT realistic to expect users to add the mingw 
> directory to the path on windows systems. Yes it would work and yes
> that is kinda what the path is for, but that is not really the user
> experience/expectation on Windows, even for command line tools.
> 
> I'm also a little uneasy about changing the key from LOCAL_MACHINE 
> to CURRENT_USER. Doesn't the latter only apply to the currently 
> logged on user?
> 
> Can we insist that install is done by an admin user that can set 
> HKEY_LOCAL_MACHINE?
> 
> On 05/06/2015 12:46 AM, Martin Whitaker wrote:
>> Having slept on this, I'm questioning why iverilog-vpi needs to 
>> store anything in the registry. The two things it stores there
>> are
> 
>> - the path to the iverilog root directory - the path to the 
>> installed MinGW compiler
> 
>> The first of these it could work out for itself, in the same way 
>> vvp does. The second is just added to the PATH environment
>> variable - surely it is easier to ask the user to add this to
>> PATH themselves. After all, any user capable of writing VPI
>> modules is surely capable of setting up their PATH variable.
> 
>> Martin Whitaker wrote:
>>> When running natively in Windows, iverilog-vpi stores a couple
>>> of keys in the registry. Currently it stores these in
>>> 
>>> HKEY_LOCAL_MACHINE\Software\Icarus Verilog
>>> 
>>> With typical Microsoft consistency, a 32-bit application
>>> running with normal user privileges can add these keys to the
>>> registry, but, on the same Windows machine, a 64-bit
>>> application must be running with administrator privileges.
>>> 
>>> Currently iverilog-vpi silently fails to store the keys when 
>>> built as a 64-bit application. I could fix this in two ways:
>>> 
>>> - output a warning message to inform the user they need to run 
>>> with administrator privileges
>>> 
>>> - change the key location to HKEY_CURRENT_USER
>>> 
>>> I'm inclined to go for the second option. Does anyone wish to 
>>> argue otherwise?
> 
> 
>> ------------------------------------------------------------------------------
>
>> 
> 
> 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
> 
> 
> 
> 
> ------------------------------------------------------------------------------
>
> 
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

iEYEARECAAYFAlVKOdkACgkQrPt1Sc2b3ikbhACfTSMPaMTxajM6tuzvCHYNhdHx
7EUAn0il8tuNGWhAivukxk96u+Gi5MBj
=ZprX
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Icarus keys in the Windows registry

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

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


It is absolutely NOT realistic to expect users to add the mingw
directory to the path on windows systems. Yes it would work and
yes that is kinda what the path is for, but that is not really
the user experience/expectation on Windows, even for command line
tools.

I'm also a little uneasy about changing the key from LOCAL_MACHINE
to CURRENT_USER. Doesn't the latter only apply to the currently
logged on user?

Can we insist that install is done by an admin user that can set
HKEY_LOCAL_MACHINE?

On 05/06/2015 12:46 AM, Martin Whitaker wrote:
> Having slept on this, I'm questioning why iverilog-vpi needs to
> store anything in the registry. The two things it stores there are
> 
> - the path to the iverilog root directory - the path to the
> installed MinGW compiler
> 
> The first of these it could work out for itself, in the same way
> vvp does. The second is just added to the PATH environment variable
> - surely it is easier to ask the user to add this to PATH
> themselves. After all, any user capable of writing VPI modules is
> surely capable of setting up their PATH variable.
> 
> Martin Whitaker wrote:
>> When running natively in Windows, iverilog-vpi stores a couple of
>> keys in the registry. Currently it stores these in
>> 
>> HKEY_LOCAL_MACHINE\Software\Icarus Verilog
>> 
>> With typical Microsoft consistency, a 32-bit application running
>> with normal user privileges can add these keys to the registry,
>> but, on the same Windows machine, a 64-bit application must be
>> running with administrator privileges.
>> 
>> Currently iverilog-vpi silently fails to store the keys when
>> built as a 64-bit application. I could fix this in two ways:
>> 
>> - output a warning message to inform the user they need to run
>> with administrator privileges
>> 
>> - change the key location to HKEY_CURRENT_USER
>> 
>> I'm inclined to go for the second option. Does anyone wish to
>> argue otherwise?
> 
> 
> ------------------------------------------------------------------------------
>
> 
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

iEYEARECAAYFAlVKJ5IACgkQrPt1Sc2b3inqrwCdHNl4Rv1rBlM4774kdEwBd/8b
MgkAoI+hvehDBhRqdiqO7//tbyhB4rud
=WrYG
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Icarus keys in the Windows registry

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

Having slept on this, I'm questioning why iverilog-vpi needs to store anything 
in the registry. The two things it stores there are

   - the path to the iverilog root directory
   - the path to the installed MinGW compiler

The first of these it could work out for itself, in the same way vvp does. The 
second is just added to the PATH environment variable - surely it is easier to 
ask the user to add this to PATH themselves. After all, any user capable of 
writing VPI modules is surely capable of setting up their PATH variable.

Martin Whitaker wrote:
> When running natively in Windows, iverilog-vpi stores a couple of keys in the
> registry. Currently it stores these in
>
>     HKEY_LOCAL_MACHINE\Software\Icarus Verilog
>
> With typical Microsoft consistency, a 32-bit application running with normal
> user privileges can add these keys to the registry, but, on the same Windows
> machine, a 64-bit application must be running with administrator privileges.
>
> Currently iverilog-vpi silently fails to store the keys when built as a 64-bit
> application. I could fix this in two ways:
>
>     - output a warning message to inform the user they need to run with
>       administrator privileges
>
>     - change the key location to HKEY_CURRENT_USER
>
> I'm inclined to go for the second option. Does anyone wish to argue otherwise?

[Iverilog-devel] Icarus keys in the Windows registry

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

When running natively in Windows, iverilog-vpi stores a couple of keys in the 
registry. Currently it stores these in

   HKEY_LOCAL_MACHINE\Software\Icarus Verilog

With typical Microsoft consistency, a 32-bit application running with normal 
user privileges can add these keys to the registry, but, on the same Windows 
machine, a 64-bit application must be running with administrator privileges.

Currently iverilog-vpi silently fails to store the keys when built as a 64-bit 
application. I could fix this in two ways:

   - output a warning message to inform the user they need to run with
     administrator privileges

   - change the key location to HKEY_CURRENT_USER

I'm inclined to go for the second option. Does anyone wish to argue otherwise?