Re: gEDA-user: [icarus] task automatic causes assertion
Stephen Williams wrote: I think there is a bug report related to this in the icarus verilog bugs tracker already. automatic tasks are not supported yes, and there is a patch that I recently applied that reports this as a proper error. Are there any plans to add automatic tasks or is that too complicated or can their use be easily avoided? Guenter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [iverilog] running the git source of Icarus Verilog
Stephen Williams wrote: Günter Dannoritzer wrote: ... How can I check that it works correct? It is just as likely that you found a bug that is segfaulting instead of tripping an assert. That is rare in Icarus Verilog because we're so liberal with assertions, but it does happen from time to time. I am not sure. I think it must have to do with my setup. This is the output I am getting when I run the 'task automatic' example that I have submitted for the bug report with my git installation: iverilog -o auto.vvp auto.v auto.v:16: syntax error sh: line 1: 28234 Done /home/hubert/dev//lib/ivl/ivlpp -L -F/tmp/ivrlg2294fdd02 -f/tmp/ivrlg294fdd02 -p/tmp/ivrli294fdd02 28235 Segmentation fault | /home/hubert/dev//lib/ivl/ivl -C/tmp/ivrlh294fdd02 -C/home/hubert/dev//lib/ivl/vvp.conf -- - make: *** [auto.vvp] Error 139 So with the latest development snapshot it gave me an assertion, but with the git version a segmentation fault. The reason I think it has to do with my setup is that this assertion gave a segmentation fault with the git source and the pli example that I provided with the cbValueChange bug report also caused a segmentation fault with the git source. Guenter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [iverilog] running the git source of Icarus Verilog
Jared Casper wrote: On Sat, Aug 16, 2008 at 12:55 PM, Günter Dannoritzer [EMAIL PROTECTED] wrote: So with the latest development snapshot it gave me an assertion, but with the git version a segmentation fault. I saw this behavior as well, so I don't think it is your setup. Something must have changed in git between the snapshot and your bug report that prevented the assertion from firing and it went on to segfault. Note that the bug has been fixed in git now (although for some reason I had to make clean then re make for it to pick up the new parsing code, maybe there is a bug in the Makefiles?) Thanks, after an update both segfaults that I had are gone. Guenter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: [iverilog] running the git source of Icarus Verilog
Hi, I tried to install Icarus Verilog from git and wonder whether I did something wrong, as when things go wrong it crashes with a segmentation fault. I have to say that I have the latest development snapshot installed in parallel in the standard path. So what I did with the git version is that I checked it out to my home folder, did the 'source autoconf.sh' and then configured it with the --prefix set to a path in my home folder. Then just typed make and make install, without any other options. The installation went fine and in order to use it I prepended the new bin/ folder to my path. Also added the new lib/ and lib/ivl/ folder to the LD_LIBRARY_PATH in the shell I want to use it. It seems to work with code that runs without error, but when I try other examples that cause problems it ends with a segmentation fault. Did I do something wrong with my installation? How can I check that it works correct? Thanks for you help. Cheers, Guenter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: [icarus] task automatic causes assertion
Hi, I tried compiling some Verilog code with a 'task automatic' statement using Icarus Verilog 0.9.devel s20080429 and got the following assertion: iverilog -o auto2.vvp auto.v auto.v:16: syntax error auto.v:3: assert: pform.cc:359: failed assertion lexical_scope == pform_cur_module sh: line 1: 8518 Done/usr/lib64/ivl/ivlpp -L -F/tmp/ivrlg2784ffa93 -f/tmp/ivrlg784ffa93 -p/tmp/ivrli784ffa93 8519 Aborted | /usr/lib64/ivl/ivl -C/tmp/ivrlh784ffa93 -C/usr/lib64/ivl/vvp.conf -- - When compiling it with the git version I got a segmentation fault: iverilog -o auto.vvp auto.v auto.v:16: syntax error sh: line 1: 8470 Done /home/hubert/dev//lib/ivl/ivlpp -L -F/tmp/ivrlg21e9b0033 -f/tmp/ivrlg1e9b0033 -p/tmp/ivrli1e9b0033 8471 Segmentation fault | /home/hubert/dev//lib/ivl/ivl -C/tmp/ivrlh1e9b0033 -C/home/hubert/dev//lib/ivl/vvp.conf -- - Is there something I need to change in order for the assertion to work when working with the git source? Below is the Verilog code I used. Thanks for your help. Guenter module auto; reg clk; initial begin clk = 1; forever begin #2.5; clk = ~clk; end end task automatic clk_wait; input integer count; begin repeat(count) @(negedge clk); end endtask initial begin $display(start sim @ %t,$time); clk_wait(2); $display(end sim @ %t,$time); $finish; end endmodule ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Verilog, testbenches, and Makefiles
Dan McMahill wrote:
[...]
\begin{shamelessplug}
If you're doing LateX documents and like Makefile's you might take a
look at latex-mk (http://latex-mk.sf.net). It is a set of makefile
fragments along with a couple of wrapper scripts. It manages
dependencies and all the building needed for complex documents.
Hi Dan,
Thanks for the information. I haven't known about this one yet.
I will look into it. My first step for now is that I have created a RPM
package for openSUSE, available through here:
http://software.opensuse.org/search
BTW, this is now going more towards logic development, but fits into the
Makefile idea, I ran across this tool that extracts register information
from a document and creates the Verilog code:
http://www.veripool.org/wiki/vregs
It also supports the extraction from LaTex and I was wondering whether
someone has already some experience with it?
Cheers,
Guenter
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Open VHDL Simulators?
Stephen Williams wrote: [...] Has anybody here used ghdl? freehdl? Relative merits? Which is most active? The most portable? Easiest to use? It just seems like ghdl has the most activity associated with it, but FreeHDL doesn't look completely dead either. So what to choose? For openSUSE you can find RPM packages of both simulators through: http://software.opensuse.org/search Both packages have source packages available and I believe it should be fairly simple to use those and compile a package for a different distribution. Although I did create the ghdl package, I only tested it with a simple VHDL example. So I cannot comment on how feature rich it is. Before creating the RPM I had installed it from source on one of my computers. What I always found to be a hassle to figure out is to get the correct version of ADA compiler. Guenter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Open VHDL Simulators?
al davis wrote: On Friday 25 April 2008, Stephen Williams wrote: As you know, this year's Icarus Verilog GSoC candidate is working on a VHDL code generator back-end for Icarus Verilog. Hooray! But suddenly the obvious question comes up, How are we going to run these generated files? I'm here looking for suggestions. What you need is the ability to translate the other way too. That way, you can go around the loop and see if you get equivalent Verilog back. Going both ways has another obvious benefit. We would get real VHDL support too. I fully agree. That would be awesome if along with the Verilog-VHDL converter there would be a VHDL-Verilog converter for the same feature set. When converting Verilog code to VHDL, chances are that there is a test bench already available in Verilog. So instead of converting this test bench as well, it would make more sense to keep that test bench and verify the VHDL based on the converted Verilog code. However, I do understand that in order to get matching Verilog-VHDL relationship there is the need during development to verify VHDL. I am not sure whether this fits here, there is Python project called MyHDL and it allows to convert Python code to Verilog. With the latest development snapshot the author Jan Decaluwe added a conversion from Python to VHDL. You can read about that under: http://myhdl.jandecaluwe.com/doku.php/dev:whatsnew:0.6 With the toVerilog conversion, co-simulation trough the PLI interface is used to verify the created Verilog code with the Python test bench. With the toVHDL conversation he could not use co-simulation and instead did some toVHDL conversation of the test bench code as well. Maybe his thoughts are of some help here. You will also find posts on comp.lang.vhdl from him about problems he ran into with the toVHDL conversion. That might be of some help for the student working on the VHDL converter. Now, Jan did not go that route, but, GHDL has some PLI interface support. It seems like there has been some work in ADA on that, but there is also some C or C++ code for that. At least I was reading about that in the GHDL mailing list archive some time ago. There is a IEEE paper about using GHDL in connection with SystemC via the PLI: A Methodology and Toolset to Enable SystemC and VHDL Co-simulation Maciel, R.; Albertini, B.; Rigo, S.; Araujo, G.; Azevedo, R. VLSI, 2007. ISVLSI apos;07. IEEE Computer Society Annual Symposium on Volume , Issue , 9-11 March 2007 Page(s):351 - 356 Maybe that is of any help here. Cheers, Guenter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Icarus Verilog: specify path for $readmemh?
Mike Jarabek wrote: Hi, You could try using a relative path, that is: Replace Romfile.txt with ../sim/Romfile.txt This might get you past the problem, at the expense of forcing the directory structure to always have the file in the 'sim' directory. I think the Xilinx tools can deal with the slashes. Thanks for the tip, that was the simplest solution that did it. Both, Icarus and ISE/Webpack like the relative path information. I ended up moving the file to the rtl folder, so calling Icarus from the ../sim folder finds the file and ISE/Webpack does so too. Guenter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Icarus Verilog: specify path for $readmemh?
Stephen Williams wrote: Günter Dannoritzer wrote: Hi, I am using the system task $readmemh to init some ROM. Now my question is, can I specify for the simulation with Icarus somewhere the path to the file I am using with $readmemh? I can think of 2 ways: You can use $value$plusargs at run time to get the path you want to use at run time as an extended argument to the vvp command. This won't work for synthesis, though. You can replace your text with a macro, and define that macro in your Makefile (-D) or your iverilog commands file (+define+). This will work with synthesis because you can also pass the correct definition of the path to your synthesizer command line. Thanks for the help. I am impressed about the $value$plusargs switch to pass information at run time. Need to read the help of Icarus more often :) I ended up using Mike's idea about specifying the file name with relative path. That ended up working. Guenter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Icarus Verilog: specify path for $readmemh?
Hi, I am using the system task $readmemh to init some ROM. Now my question is, can I specify for the simulation with Icarus somewhere the path to the file I am using with $readmemh? Here is my dilemma. My folder structure is as follows: + rtl/ + tb/ + sim/ + syn/ In rtl/ and tb/ I have my RTL implementation and in tb/ the test benches. In the sim/ folder I have a Makefile that does the compilation and simulation with Icarus Verilog. Now the $readmemh call is in some code in the rtl/ folder. The way I solved the path issue is that I moved the file that is read with the $readmemh call in the sim/ folder. Now the conflict happens with synthesis. In the syn/ folder I have a Makefile that calls synthesis with Xilinx webpack/ISE. It expects the file that is read in with the $readmemh call is in the rtl/ folder. I guess I could copy the ROM file in both locations or specify some macros and have two different $readmemh calls. Anyhow, is there a way to tell Icarus that the ROM file to be read with $readmemh is in another location than the folder the simulator (compiler) is called from? I did not find a command line switch that would apply to that issue. Thanks for the help. Guenter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Icarus Verilog issues with Teal
Matt Ettus wrote: [...] Günter, I am also interested in trying Teal/Truss. Do you like using it? Is it worth the effort to learn? And how well does it work with Icarus in general? Hi Matt, Unfortunately I have not used it very much yet. I got the book about a year ago and started trying out the software. I ran into several issues with the software, which partly had to do with my inexperience. After that first try I had not use it for a long time as I had no need for it and not the time to figure out how to get it going. In the recent weeks I have started spending some more time with it again. I have a 32-bit computer with SUSE 10.0 and gcc 4.0. I found two issues with the software, that unfortunately did not make it into a release yet. It seems like not too many people are using the C++ version. The code I have compiles fine now, at least the alu example seems to verify correct. I also have a 64-bit computer with openSUSE 10.2 and gcc 4.1. It seems like that gcc 4.1 is tougher with error checking and I ran into several more issues to get the code to compile on this computer. Unfortunately after all those changes there must be still another issue and I don't know whether it has to do with the 64-bit architecture or the compiler. But some basic teal tests do not work and I am still trying to figure that out now. So far I have read the book about half through and peeked through the other half. In my opinion the book is very well written and very practical oriented. I don't have much verification experience yet, so take my words with a grain of salt. I like the Teal/Truss approach, as I think it is very well thought through and the code for the framework is very simple and can be maintained by someone experienced in C++. Unfortunately I think it will still need some work to make it more user friendly and probably also to root out some errors. Considering the framework again, I think the advantage is that you have with the book all the knowledge you need to start a simple verification job, but can scale up to a much more complex design. The book actually shows this in two chapters. In one chapter it walks you through the verification of a UART 16550 from OpenCores and in the next it shows how to put 4 of those UARTs into a design and then do the verification for them. Hope this gives you some idea. Cheers, Guenter PS: The two errors you need to fix to get the 1.40b compile with gcc 4.0 and work with Icarus are documented in this discussion thread: http://trusster.com/node/95 However, I see there are also changes in the svn repository svn.trusster.com, that I had not considered yet. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Icarus Verilog vvp32 on 64bit systems
Stephen Williams wrote: Question: Does *anybody* use or even see value in the 32bit runtime support that Icarus Verilog includes in 64bit builds? In particular, there is support in the Icarus Verilog source for building simultaneously a vvp (64bit) and a vvp32 (32bit) to support 32bit VPI's transported from 32bit systems. I personally have never used the vvp32 and I'm starting to run into cases where it is actively getting in the way. I'm considering removing the whole business and forgetting about it, although there may be alternatives. Comments? I am not using vvp32, but I am also not a heavy user of the PLI. However, I did try to build openSUSE RPM's from the latest development snapshot and ran into problems related to vvp32, I did not have before. For openSUSE 10.2 x86_64 the build failed with some vvp32 errors. I haven't taken the time yet to look at them closer. So from the build point of view, taking out vvp32 would simplify matters. However, the build is not a purpose for itself. If there are people using vvp32, those should off course given priority over my troubles figuring out the build for vvp32. Guenter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Icarus Verilog issues with Teal
Stephen Williams wrote: Günter Dannoritzer wrote: Hi, I am looking into using Icarus Verilog with Teal/Truss, a C++ based verification framework. With Icarus 0.8.6 all tests but the last, with release of a_wire, are working. It's probably a matter of it not being implemented yet. Looks like a candidate for a bug report. I will try to figure this minimal VPI application out that I am working on to trigger this error and then will commit it with a bug report. [...] issue # 1652096 vpi_put_value to net doesn't work [...] Sounds like that this bug report describes the problem I am seeing with the Teal vreg_test. Is that a bigger issue to solve or is there someone working on its solution already? It's sitting in the database waiting for motivation. I wonder if this is the motivation that is needed?-) Well, I will be honest with you. Trying to figure out truss/teal I am still finding some other problems of the software itself that makes me not succeed using it. So for now I can live with using it with the stable version of Icarus. It would be great in the long run, if it works out to get teal/truss to work with Icarus, also have the development snapshot do so. Guenter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Icarus Verilog issues with Teal
Hi, I am looking into using Icarus Verilog with Teal/Truss, a C++ based verification framework. http://trusster.com/ Actually, to be more precise, Truss is the verification framework written in C++ and Teal are some utility classes, allowing to connect Truss to Verilog simulators via the PLI interface. The basic data type in Teal that does the PLI access to the simulator is the vreg class. There is a simple test that uses some vreg instances and connects them to a wire and a reg in Verilog code. The test is here: http://svn.trusster.com/tracker/repository/file/teal/trunk/cpp/test/vreg_test.cpp and the respective Verilog code is here: http://svn.trusster.com/tracker/repository/file/teal/trunk/cpp/test/vreg_test.v With Icarus 0.8.6 all tests but the last, with release of a_wire, are working. I went through the Teal code and what it boils down to is a vpi_put_value() call in connection with a Verilog wire type and the flag vpiReleaseFlag set. So the test is as follows: VERILOG: wire [5:0] a_wire; pullup (a_wire[0]); pulldown (a_wire[1]); In Verilog a_wire is created, with one bit being pulled up, another being pulled down. Then Teal connects to that wire and changes values and at the end calls the release function: TEAL: vreg a_wire (top.a_wire); a_wire(0,0) = reg (reg::Z); a_wire(1,1) = reg (reg::X); a_wire.release (); The expected outcome is that a_wire takes on its original value, assigned in the Verilog code (6'b01), but instead it is 6'bxz. The development snapshot has the same problem, but in addition the shown a_wire(0,0) = reg (reg::Z) assignments don't work. I searched through the bug-tracker and found issue # 1652096 vpi_put_value to net doesn't work Sounds like that this bug report describes the problem I am seeing with the Teal vreg_test. Is that a bigger issue to solve or is there someone working on its solution already? Now concerning vpiReleaseFlag I tried to create a simple test that triggers that behavior, but have a problem with the release. What I did is take a systemtask function from the Sutherland PLI book and changed it to write a value in the calltf function: ... s_vpi_value v; s_vpi_time t; s_vpi_vecval vecval; t.type = vpiSimTime; t.low = 0; t.high = 0; vecval.aval = (PLI_INT32)0; vecval.bval = (PLI_INT32)0; v.format = vpiVectorVal; v.value.vector = vecval; vpi_put_value(vector_h, v, t, vpiForceFlag); //vpi_put_value(vector_h, v, t, vpiReleaseFlag); My original idea was to add the vpi_put_value with the vpiForceFlag and the vpiReleaseFlag right after one another. But that is not correct, as they appear at the same simulation time. Now I was looking for a simple way to advance simulation time and then issue the vpi_put_value call with the vpiReleaseFlag. It seems like I need to do that with a callback function that gets called at a specific simulation time. Does anyone know a simpler method to issue the vpiReleaseFlag call a time step after the vpiForceFlag call? Thanks for your help and sorry for the lengthy explanation. Cheers, Guenter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Icarus Verilog Release 0.8.6
Werner Hoch wrote: ... Unfortunatly I wasn't able to build it for openSUSE 10.3 on x86_64 arch. The bz2_32bit_devel files are no longer part of openSUSE 10.3. ... I ran into the same problem with the development snapshot. I assumed it was just my limited knowledge about the changed packages due to the new library convention. However, when you bring that up it seems like they took this package out? And the following programs are not created: -- RPM build errors: File not found: /var/tmp/verilog-0.8.6-0-root/usr/lib/ivl/vpi64/system.vpi File not found: /var/tmp/verilog-0.8.6-0-root/usr/lib/ivl/system.sft File not found: /var/tmp/verilog-0.8.6-0-root/usr/lib/ivl/system.vpi Possible solutions: * not building the 32bit binaries for x86_64 arch * if its possible, build that binaries without bz2 support * ??? I am asking naive, but is building the bz2 package for 32 bit too complicated to add it to the repository? Do you know what the reason was in first place to remove it? Cheers, Guenter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Re: Icarus Verilog PLI example: PLI_INT32 vs static int
Stephen Williams wrote: int is PLI_INT32 in your case. The static part is something else altogether and perhaps more germain to your problem. You don't say what's crashing, Stu's example or mine, etc., so we have very little to go on. Sorry for being so vague. I was more curious about the need for the static. I am trying to run the pow() example from the Stu book. Originally I typed it off and added my own test bench. That crashed right away with a segmentation fault. Next I took the example from the accompanied CD. I modified the vpi_user.c to not needing the other application that comes along with that chapter 2 example and compiled it with: iverilog-vpi pow_vpi.c vpi_user.c iverilog -opow_test.vvp pow_test.v vvp -M. mpow_vpi pow_test.vvp The output I am getting is: $pow PLI application is being used. Segmentation fault What is odd, even after changing the definition and the implementation of the calltf, sizetf, compiletf functions I am getting warnings about incompatible pointer types. For example the calltf function I changed from: PLI_INT32 PLIbook_PowCalltf(PLI_BYTE8 *user_data); to: static int PLIbook_PowCalltf(PLI_BYTE8 *user_data); When compiling I am still getting: iverilog-vpi pow_vpi.c vpi_user.c Compiling pow_vpi.c... pow_vpi.c: In function ‘PLIbook_pow_register’: pow_vpi.c:46: warning: assignment from incompatible pointer type pow_vpi.c:47: warning: assignment from incompatible pointer type pow_vpi.c:48: warning: assignment from incompatible pointer type Compiling vpi_user.c... Making pow_vpi.vpi from pow_vpi.o vpi_user.o... Line 46, 47, and 48 are: tf_data.calltf = PLIbook_PowCalltf; tf_data.compiletf = PLIbook_PowCompiletf; tf_data.sizetf = PLIbook_PowSizetf; I even removed the .o and the .vpi file to make sure it compiles again, but still get the warning. The example can be downloaded from this page: http://sutherland-hdl.com/pli_book_files/pli_handbook_examples_unix.tar.gz Any idea what I am doing wrong? Thanks for the help. Cheers, Guenter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Some Linux distros to consider
Jason Elder wrote: [...] Finally I settled on OpenSUSE 10.2 with the GNOME desktop. SUSE has older versions of both firefox and openoffice, but needed to make a choice so I settled on this one. I really like it, especially the GNOME desktop with the X-sumthin-or-other that adds desktop effects with an open-gl enabled card (I have an nvidia 5500). The effects are really cool...I like the way I can make the desktops become cube faces and switch between each one using ctrl+alt+left-mouse-click. I don't know what the package is..I'll post it if there's interest. It's really cool! I hope I did not overlook some post and someone had already done this, but I want to point out that there are some RPMs for openSuse available. The following list shows what is available for 10.2: http://software.opensuse.org/download/home:/werner2101/openSUSE_10.2/repodata/ Those files are available from Suse 9.3 to openSuse 10.2 and can be found in the respective subfolder from here: http://software.opensuse.org/download/home:/werner2101/ Cheers, Guenter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Icarus Verilog with Xilinx simprims...
Evan Lavelle wrote: Günter Dannoritzer wrote: [...] Here are some information about that and a link to a previous discussion: http://iverilog.wikia.com/wiki/Graffiti#SDF_support I added a section to your entry covering the reasons for doing timing simulations (same URL). Haven't quite got the hang of this wiki yet. I tried to add it as a second-level heading under 'SDF support', but it's gone in as a main heading... Thanks Evan, Those are great information. I think the 'SDF support' headline was already a second-level == headline ==. To get it underneath you would need to make it a third-level === headline ===. Cheers, Guenter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Icarus Verilog with Xilinx simprims...
Andy Peters wrote: Does iverilog support SDF backannotation? The SDF has the delay information. Here are some information about that and a link to a previous discussion: http://iverilog.wikia.com/wiki/Graffiti#SDF_support Cheers, Guenter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Re: gEDA-announce: Information about Google Summer of Code and the gEDA Project
Stephen Williams wrote: I've started a section in the Graffiti page of the Icarus Verilog documentation wiki: http://iverilog.wikia.com/wiki/Graffiti and I've sent the initial contents directly to Dan. If any other Icarus Verilog ideas pop up, I can vet them and pass them on. (Hmm... I just thought of another idea...) Hi Steve, That looks good. There was a post from Stuart Brorson about needing to submit a mentor and I wanted to bring that up, whether this is already clear for Icarus' proposals or whether this would need to be discussed here? Cheers, Guenter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Icarus Verilog: Need for --enable-vvp32 in x86_64 ./configure call?
Hi, I compiled the recent snapshot on my openSuse 10.2 x86_64 system and recognized that by default, when running ./configure, it does not compile with vvp32 support. When I analyzed the verilog.spec file from the latest snapshot rpm, then it calls ./configure with the --enable-vvp32 flag. My question is now, what is the vvp32 used for on the x86_64 platform? Is it really needed for the rpm? I am trying to build a rpm from the current Icarus Verilog snapshot. I know that there exists one for the stable version and that for the development snapshots there exists a x86_64 version on the icarus.com ftp server. The reasons I still want to build one is for one I would like to run the builds with the opensuse build system. In fact I was able to run the i586 version successful for (open)Suse 10.0, 10.1, and 10.2. http://software.opensuse.org/download/home:/dannori/ The other reason to do it is that I want to add a cosimulation .vpi for myhdl to the rpm package. This will allow to run cosimulation with myhdl and Icarus by just installing the two respective rpms. Thanks for the help. Cheers, Guenter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Re: Icarus Verilog: Need for --enable-vvp32 in x86_64 ./configure call?
Stephen Williams wrote: Günter Dannoritzer wrote: [...] This is for users who have a 32bit .vpi module from a 3'rd party. They cannot use it with the 64bit vvp, but vvp32 will be able to load it just fine. That's the *only* reason for vvp32. OK, I understand, so for a rpm package that would be good to have. [...] I recommend fixing the exising verilog.spec file if you are having trouble with it, and by all means send patches. OK, I will do that. [...] The other reason to do it is that I want to add a cosimulation .vpi for myhdl to the rpm package. This will allow to run cosimulation with myhdl and Icarus by just installing the two respective rpms. To add an add-on like a vpi package, you don't need to rebuild the Icarus Verilog package! Just have the myhdl rpm drop the .vpi in the right directory at install time. How does that affect Icarus Verilog packaging? Yes, I undestand that. I was thinking about just adding it to the proper Icarus folder, as part of the myhdl package. What made me think about doing it the other way is that if someone does not install Icarus, that folder does not need to exist. So adding it to Icarus out of the Icarus rpm package everything will work fine when installed in connection with the myhdl package. If somebody decides for some reason to install Icarus from source, the .vpi installation would need to be done by hand. Concerning the packaging, I am not sure how I will do that. I am not that experienced with the creation of spec files yet. I would like to have it that I can put the Icarus source and the vpi source in a folder and the spec file will do the proper steps to compile both and then add the vpi file to the correct folder. That way I can just replace the Icarus source by future releases and run the build process again. My first goal will be to adjust the spec file so that the Icarus source will build correct by itself for the 64 bit platform. Guenter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Re: Icarus Verilog: Need for --enable-vvp32 in x86_64 ./configure call?
Stephen Williams wrote:
The way you handle that is to create a sub-package that depends on
Icarus Verilog. Users can install your main package without requiring
Icarus Verilog, but if they install the icarus verilog interface, they
will naturally require the Icarus Verilog package.
You only need one myhdl.spec file that creates multiple packages. It's
a fairly common thing to do.
Thanks for the hint, I will look into that.
Werner Hoch is already using the OPensuse system to build the stable
releases of Icarus Verilog (0.8 branch).
http://iverilog.wikia.com/wiki/Installation_Guide#SuSE_Linux.2FopenSUSE
Yes, I saw that. Actually I based my spec file on his and yours.
I fixed the build error for 10.2, now I don't know how much this spec
file will be good for your repository, as it has an openSuse 10.2
dependent BuildRequires in it.
One change done by Werner Hoch is to add build requires depending on
x86_64. I added another BuildRequires for openSuse 10.2:
-
%ifarch x86_64
BuildRequires: bzip2-32bit, glibc-devel-32bit, glibc-32bit, zlib-devel-32bit
BuildRequires: termcap-32bit, readline-32bit, readline-devel-32bit
%if 0%{?suse_version} == 1020
BuildRequires: gcc-32bit, libstdc++41-devel-32bit
%endif
%endif
--
That are the essential changes to your spec file.
Do you want me to add that as a ticket?
Guenter
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Re: Icarus snapshot 20060809 compile error tgt-vvp under cygwin w/ patch pr1541452.patch
Stephen Williams wrote: [...] Try adding ivl_lval_width to the ivl.def file in the main source directory, then rebuild from the top down. It looks like that got missed in the big fixup. If that does it for you, I'll check it into CVS. Thanks Steve, that works. Guenter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Icarus snapshot 20060809 compile error tgt-vvp under cygwin w/ patch pr1541452.patch
Hi, I tried to compile Icarus Verilog snapshot 20060809 under cygwin. I found a bug report about that setup not to compile correct. Along with that bug report came the patch pr1541452.patch which is applied to the source. When I compile the code I am getting a linker error for the tgt-vvp folder: make[1]: Entering directory `/cygdrive/e/MyDocuments/software/verilog-20060809/tgt-vvp' mkdir dep gcc -DHAVE_CVS_IDENT=1 -I. -I./.. -DHAVE_CONFIG_H -Wall -g -O2 -MD -c vvp.c -o vvp.o mv vvp.d dep gcc -DHAVE_CVS_IDENT=1 -I. -I./.. -DHAVE_CONFIG_H -Wall -g -O2 -MD -c draw_mux.c -o draw_mux.o mv draw_mux.d dep [...] gcc -shared -Wl,--enable-auto-image-base -o vvp.tgt vvp.o draw_mux.o draw_ufunc.o draw_vpi.o eval_bool.o eval_expr.o eval_real.o vector.o vvp_process.o vvp_scope.o -L.. -livl vvp_process.o: In function `set_vec_to_lval': /cygdrive/e/MyDocuments/software/verilog-20060809/tgt-vvp/vvp_process.c:261: undefined reference to `_ivl_lval_width' /cygdrive/e/MyDocuments/software/verilog-20060809/tgt-vvp/vvp_process.c:262: undefined reference to `_ivl_lval_width' /cygdrive/e/MyDocuments/software/verilog-20060809/tgt-vvp/vvp_process.c:106: undefined reference to `_ivl_lval_width' /cygdrive/e/MyDocuments/software/verilog-20060809/tgt-vvp/vvp_process.c:110: undefined reference to `_ivl_lval_width' vvp_process.o: In function `force_vector_to_lval': /cygdrive/e/MyDocuments/software/verilog-20060809/tgt-vvp/vvp_process.c:746: undefined reference to `_ivl_lval_width' vvp_process.o:/cygdrive/e/MyDocuments/software/verilog-20060809/tgt-vvp/vvp_process.c:769: more undefined references to `_ivl_lval_width' follow collect2: ld returned 1 exit status make[1]: *** [vvp.tgt] Error 1 make[1]: Leaving directory `/cygdrive/e/MyDocuments/software/verilog-20060809/tgt-vvp' Where does this ivl_lval_width come from? I did a search through the source and it is defined as extern? How can I resolve that compile problem? Thanks for any help. Cheers, Guenter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
