Hi all, I have a competing proposal to Michaels, with example, for discussion, attached. Note the vpi_user.h only has partial routine overrides, I haven't done all the ones that might need to be done, this is just proof-of-concept. In this proposal, there is no default for the macro. The default in the absence of any defined macro is vpi_handle(), vpi_iterate() etc, whatever they are, which is assumed to be tool-dependent behavior. Multiple-defined macros is an error. The Makefile64 is obviously tuned to our tool. The example assumes that the differentiated routine names in the library can be resolved in the tool executable: $ nm vpi_presentation_app_2005.o 0000000000000000 T cbStartOfSimulation_function U _GLOBAL_OFFSET_TABLE_ 00000000000001fd T RegisterMyTfs U strcpy 0000000000000000 D vlog_startup_routines U vpi2005_get_str U vpi2005_iterate U vpi2005_scan U vpi_handle_by_name U vpi_printf U vpi_register_cb Here is what I found when I actually tried to implement this. 1. If the values for the macro definition are included in the vpi_user.h file, then you don't have the values available until you have included it, to define them. But of course the definitions need to be available before vpi_user.h is included, so that the vpi_user.h definitions are correct. A catch-22 problem. So I changed it to having several mutually exclusive macros using only #ifdef to make the determination, not #defined values. This way, you can define the macro you want to '1' either via a compilation option or in the code as long as you do so before you include vpi_user.h. The make file shows examples of both methods. Another solution would be a new include file. 2. The tool writer has to undef the overrides for vpi_handle, vpi_iterate etc outside of vpi_user.h in the file in which these routines exist, because the tool itself must differentiate vpi2001_handle(), vpi_handle() etc.. So this solution is more application-friendly than tool-friendly, but that is probably OK.. 3. Note that this proposal (and any fix applied at application compilation) DOES NOT FIX the case where the user has two object libraries, both calling vpi_handle(), vpi_scan(), etc, but one expecting the behavior from these routines to be 2001 and the other expecting 2005. A compilation-fix proposal assumes that one or both of these libraries can be recompiled, or has been supplied in a pre-compiled version, appropriate to the required model. Another way to say this is that only one library can get the tool default behavior of vpi_handle(), though the tool may allow you to select whether this is 2001 or 2005. The other libraries must be using the external symbols from the vpi2005_*() or vpi2001_*() set, so that they can be differentiated by the tool. Abi
This archive was generated by hypermail 2.1.8 : Tue Oct 31 2006 - 11:11:43 PST