|
From: Joshua S. <kni...@gm...> - 2015-05-13 16:53:10
|
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 > ********************************************* > |