iverilog takes the current directory into the default search path (a simple -mvpi-XXX is sufficient), while vvp does not (this needs the option "-M.").
A consistent behaviour between tools would be preferable.
This doesn't fix the problem if you need to call vvp directly. Steve can decide which tool has the correct behavior. It should not be too hard to fix this either way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I thought about this a bit on the drive home and I think you are misunderstanding how things work. First the -M flag is not the same between the two programs. The -m flag to iverilog is used to put the library entry in the a.out file. It is not used to actually read the file. vvp is the only program that reads the library. That is why we have a sft file. They contain the type information for the compiler. vvp needs a -M because it is actually reading the library and the system library is the only directory that is read by default.
So if you want you can omit the -m to iverilog and only put it and the -M on vvp, but you need to read a sft file if your functions do not match the default type. Or you can use a -m on iverilog and then you only need the -M on vvp.
I should mark this pending, but since you didn't post this from an account you would likely not know where to look to find it. It is also best to remember to set the correct group.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Steve gets to decide this. I can see the argument both ways. It's kind of like where do you put "." in your path. I have it last or omitted for root, but some like to have it first. The one argument against having it first is that you don't want to accidentally override the system libraries, though if a user is messing with the VPI interface we would hope they are sophisticated enough to not mess this up.
Also if I understand what you want the summary line is incorrect. There is no inconsistency between iverilog and vvp. What you want is vvp changed to add . to the library search path. So the questions to be answered are is this what we want and if so where does "." go relative to the system library and any -M flags?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
when I wrote the subject line, I believed that the compiler somehow checks the VPI module types, I was not aware of the fact that this is omitted unless you generate a sft file (what's the search path for this one?).
I would suggest to add "." by default and before the system-wide search path, so that user-provided vpi modules are choosen first.
Otherwise it may be impossible to replace the system vpi, for debugging, or if the verilog code is expecting slightly different behaviour, or the same code is used for different simulators, and some of them don't provide a function or system call as the other ones...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The sft files do not really have a search path. If you use -m to specify a library iverilog will, as a convenience, automatically look for a sft file with the same name as the library in the system directory. Other than this you have to specify the sft file directly on the command line.
Could you explain what you are trying to do? Overriding any function in the system.vpi file is probably not a good idea. It's much easier to just rebuild the system.vpi file. I guess I'm just trying to understand exactly what you are trying to do and what the problem is with the current implementation.
I stumbled over this issue when I was trying to use my local VPIs, which I don't want to install into the system-wide directory. Since iverilog writes the VVP call into the first line of the generated VPI script to make it a stand-alone executable, I assumed it should pass the required options to run this vvp-script as well (which includes the VPI path).
Why is the SFT path not the same as the "vvp -M" path by default? Usually I would expect vpi and description file in the same place to ease maintenance?
The system library seems fine for me now, but I came about the iverilog-announce mail from 2008-02-04 (Verilog-A math library (1.0-RC2), which announces the plan to "plan to eventually integrate this library into the 0.9 release". Since there are several implementations of such math libraries floating around (and many people even writing one on their own), not all necessarily compatible, I assume it's not too bad to think ahead in order to avoid future troubles...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK so we need to clean up/provide better VPI documentation to more clearly explain what is going on and the expected flow. You are correct that it would be better if -M meant the same thing for both iverilog and vvp. If it did then I also agree it would be best if iverilog would use and pass on the -M information. Since iverilog does not know about library paths (other than the system path) it can't use a -M path to search for SFT files. Remember iverilog is run before vvp.
If you look at the Verilog-A math library you will notice it already installs itself into the system directory. This library is being provided so the users do not have to role their own or try to port another library to Icarus. It should be fully functional, complete and 100% compatible with the Verilog-A standard. If another library is providing more functionality it's not just a Verilog-A math library. I have ideas for other analog functionality, but it will likely be a separate library to keep the current library on task (it provides all the Verilog-A math functionality and constants).
Thank you for your comments. This probably needs to be converted to a feature request since I don't think there are any real bug here. It's more learning how things are currently done and what we could do to make things better/more consistent. I'm going to wait for a reply before I switch this so it doesn't disappear on you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What is the purpose of using a sft file at all, since all information for type and size checks are implemented by the checktf/compiletf and sizetf callback of the PLI/VPI interface?
Shouldn't the compiler call the module callbacks in the elaboration phase (as the Sutherland Quick Reference Guide suggests, cf. p. 4 for VPI and p.1 for PLI)?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't know for sure, but I have ask Steve a similar question in the past. From memory I think it was done to alleviate the compiler from having to load the vpi files just to find the size and type information, also vpiSizedSignedFunc is relatively new and the system may have needed that functionality before the standard supported it.
There are a huge number of improvements that could be made to Icarus and patches are always welcomed, but there is a path that works correctly. Icarus uses a SFT file to provide type and size information to the compiler (elaboration phase). In the future it could be changed to support reading the information directly from the library and I agree this would match the standard better, but there are a number of VPI defects that have a higher priority than fixing the type/size elaboration interface.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've not been paying attention to this discussion (although I would have if it were held on iverilog-devel) but I think it makes some sense for the iverilog command to grow a -M flag that it uses to search for .sft files. Currently, iverilog only looks in the system library (or on the command line) for .sft files.
This is not as bad as it sounds, though, because typically a re-implementation of a vpi function does not change the system/task type, so the .sft for the override would typically be the same as that of the overridden vpi.
Also, it might not be all that evil to bit the bullet and have the iverilog compiler load the .vpi itself instead of getting the task/function types from a separate file. One way to do this would be to compile the .sft file into a separate section (or function) in the .vpi file and have ivl load that instead of the user-compiled C code. Loading and executing the user VPI code in the compiler is not really practical because the ivl core does not implement any of the vpi entry points and I don't want to get into providing stubs in the ivl core. (This is why iverilog doesn't load the .vpi to call the sizetf.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: NO
This patch resolves the problem, but maybe not the best solution:
----------------
diff -rpu verilog-20080111-orig/tgt-vvp/Makefile.in verilog-20080111/tgt-vvp/Makefile.in
--- verilog-20080111-orig/tgt-vvp/Makefile.in 2008-01-11 23:24:52.000000000 +0100
+++ verilog-20080111/tgt-vvp/Makefile.in 2008-02-27 22:58:41.000000000 +0100
@@ -68,10 +68,10 @@ vvp.tgt: $O $(TGTDEPLIBS)
$(CC) @shared@ -o $@ $O $(TGTLDFLAGS)
vvp.conf: $(srcdir)/vvp.conf.in
- echo 'flag:VVP_EXECUTABLE=$(bindir)/vvp' | cat $(srcdir)/vvp.conf.in - > vvp.conf
+ echo 'flag:VVP_EXECUTABLE=$(bindir)/vvp -M.' | cat $(srcdir)/vvp.conf.in - > vvp.conf
vvp-s.conf: $(srcdir)/vvp-s.conf.in
- echo 'flag:VVP_EXECUTABLE=$(bindir)/vvp' | cat $(srcdir)/vvp-s.conf.in - > vvp-s.conf
+ echo 'flag:VVP_EXECUTABLE=$(bindir)/vvp -M.' | cat $(srcdir)/vvp-s.conf.in - > vvp-s.conf
Makefile: Makefile.in config.status
./config.status
----------------
Logged In: YES
user_id=1651735
Originator: NO
This doesn't fix the problem if you need to call vvp directly. Steve can decide which tool has the correct behavior. It should not be too hard to fix this either way.
Logged In: YES
user_id=1651735
Originator: NO
I thought about this a bit on the drive home and I think you are misunderstanding how things work. First the -M flag is not the same between the two programs. The -m flag to iverilog is used to put the library entry in the a.out file. It is not used to actually read the file. vvp is the only program that reads the library. That is why we have a sft file. They contain the type information for the compiler. vvp needs a -M because it is actually reading the library and the system library is the only directory that is read by default.
So if you want you can omit the -m to iverilog and only put it and the -M on vvp, but you need to read a sft file if your functions do not match the default type. Or you can use a -m on iverilog and then you only need the -M on vvp.
I should mark this pending, but since you didn't post this from an account you would likely not know where to look to find it. It is also best to remember to set the correct group.
Logged In: NO
don't you think that the current working directory should be first in the search path list? That's the way shared libraries are linked at runtime...
Logged In: YES
user_id=1651735
Originator: NO
Steve gets to decide this. I can see the argument both ways. It's kind of like where do you put "." in your path. I have it last or omitted for root, but some like to have it first. The one argument against having it first is that you don't want to accidentally override the system libraries, though if a user is messing with the VPI interface we would hope they are sophisticated enough to not mess this up.
Also if I understand what you want the summary line is incorrect. There is no inconsistency between iverilog and vvp. What you want is vvp changed to add . to the library search path. So the questions to be answered are is this what we want and if so where does "." go relative to the system library and any -M flags?
Logged In: NO
when I wrote the subject line, I believed that the compiler somehow checks the VPI module types, I was not aware of the fact that this is omitted unless you generate a sft file (what's the search path for this one?).
I would suggest to add "." by default and before the system-wide search path, so that user-provided vpi modules are choosen first.
Otherwise it may be impossible to replace the system vpi, for debugging, or if the verilog code is expecting slightly different behaviour, or the same code is used for different simulators, and some of them don't provide a function or system call as the other ones...
Logged In: NO
The sft files do not really have a search path. If you use -m to specify a library iverilog will, as a convenience, automatically look for a sft file with the same name as the library in the system directory. Other than this you have to specify the sft file directly on the command line.
Could you explain what you are trying to do? Overriding any function in the system.vpi file is probably not a good idea. It's much easier to just rebuild the system.vpi file. I guess I'm just trying to understand exactly what you are trying to do and what the problem is with the current implementation.
iverilog <path_to_library>/<library>.sft
vvp -m <library> -M <path_to_library>
The Icarus system library should match the standard if it doesn't we need to know about that so it can be fixed.
Logged In: NO
I stumbled over this issue when I was trying to use my local VPIs, which I don't want to install into the system-wide directory. Since iverilog writes the VVP call into the first line of the generated VPI script to make it a stand-alone executable, I assumed it should pass the required options to run this vvp-script as well (which includes the VPI path).
Why is the SFT path not the same as the "vvp -M" path by default? Usually I would expect vpi and description file in the same place to ease maintenance?
The system library seems fine for me now, but I came about the iverilog-announce mail from 2008-02-04 (Verilog-A math library (1.0-RC2), which announces the plan to "plan to eventually integrate this library into the 0.9 release". Since there are several implementations of such math libraries floating around (and many people even writing one on their own), not all necessarily compatible, I assume it's not too bad to think ahead in order to avoid future troubles...
Logged In: YES
user_id=1651735
Originator: NO
OK so we need to clean up/provide better VPI documentation to more clearly explain what is going on and the expected flow. You are correct that it would be better if -M meant the same thing for both iverilog and vvp. If it did then I also agree it would be best if iverilog would use and pass on the -M information. Since iverilog does not know about library paths (other than the system path) it can't use a -M path to search for SFT files. Remember iverilog is run before vvp.
If you look at the Verilog-A math library you will notice it already installs itself into the system directory. This library is being provided so the users do not have to role their own or try to port another library to Icarus. It should be fully functional, complete and 100% compatible with the Verilog-A standard. If another library is providing more functionality it's not just a Verilog-A math library. I have ideas for other analog functionality, but it will likely be a separate library to keep the current library on task (it provides all the Verilog-A math functionality and constants).
Thank you for your comments. This probably needs to be converted to a feature request since I don't think there are any real bug here. It's more learning how things are currently done and what we could do to make things better/more consistent. I'm going to wait for a reply before I switch this so it doesn't disappear on you.
Logged In: NO
What is the purpose of using a sft file at all, since all information for type and size checks are implemented by the checktf/compiletf and sizetf callback of the PLI/VPI interface?
Shouldn't the compiler call the module callbacks in the elaboration phase (as the Sutherland Quick Reference Guide suggests, cf. p. 4 for VPI and p.1 for PLI)?
Logged In: YES
user_id=1651735
Originator: NO
I don't know for sure, but I have ask Steve a similar question in the past. From memory I think it was done to alleviate the compiler from having to load the vpi files just to find the size and type information, also vpiSizedSignedFunc is relatively new and the system may have needed that functionality before the standard supported it.
There are a huge number of improvements that could be made to Icarus and patches are always welcomed, but there is a path that works correctly. Icarus uses a SFT file to provide type and size information to the compiler (elaboration phase). In the future it could be changed to support reading the information directly from the library and I agree this would match the standard better, but there are a number of VPI defects that have a higher priority than fixing the type/size elaboration interface.
I've not been paying attention to this discussion (although I would have if it were held on iverilog-devel) but I think it makes some sense for the iverilog command to grow a -M flag that it uses to search for .sft files. Currently, iverilog only looks in the system library (or on the command line) for .sft files.
This is not as bad as it sounds, though, because typically a re-implementation of a vpi function does not change the system/task type, so the .sft for the override would typically be the same as that of the overridden vpi.
Also, it might not be all that evil to bit the bullet and have the iverilog compiler load the .vpi itself instead of getting the task/function types from a separate file. One way to do this would be to compile the .sft file into a separate section (or function) in the .vpi file and have ivl load that instead of the user-compiled C code. Loading and executing the user VPI code in the compiler is not really practical because the ivl core does not implement any of the vpi entry points and I don't want to get into providing stubs in the ivl core. (This is why iverilog doesn't load the .vpi to call the sizetf.)