Nasim, I can relate to the software engineering problem you are trying to solve, but would advise against using the preprocessor directives to solve it. Perhaps the features of "generate" or "configurations" would be more suitable. Your proposal assumes that compiler directives are being used in the usual trivial way. As a language feature, however, they are more powerful and can quickly render any snapshot you take of their values meaningless. 1364-2005 19.3.1 says: > Redefinition of text macros is allowed; the latest > definition of a particular text macro read by the > compiler prevails when the macro name is encountered > in the source text. Also "runtime" may only be reached after quite a few separate compilations of many source files - which of those macro definition sets would you expect to see? There is also nothing distinguished about macros `defined on the command line vs those `defined in the RTL source. So every macro value (e.g., `include file semaphores) would have to be stored to respond to mc_scan_compiler_directive(). You probably expect access to every macro definintion, and to be complete that ought to include macros with arguments. As a first cut at your software engineering problem, I'd advise using your existing directives to control the production of observable components in the design which can function as "tags" for the runtime purposes you have in mind. Another choice could be to establish a scripting framework which can build command line macro choices into the file or directory names of the components as they are produced. I'm sure the consultant & training communities have even better suggestions than mine... Good luck, Greg Jaxon Disclaimer: These opinions represent just one language implementer's first reaction... They are not the official position of my employer, or the SV standards community. Nasim Hussain wrote: > hello- > > > i wanted to ask if there is enough interest in the systemverilog > community to add the following, i am not aware if it is possible today, > i looked inside the LRM but couldn't find anything as such. but it > appears it could prove to be useful. > > in RTL, we all use various compiler directives that are invoked during > compile/build time according to what suits our needs. i want to be able > to know, at runtime, if a certain compiler directive was used. > > > for example... suppose we have: > > > ---------------------------------------------- > module dff (q, d, clk); > > parameter SIZE = 1; > output [(SIZE - 1):0] q; > input [(SIZE - 1):0] d; > input clk; > reg [(SIZE - 1):0] q; > reg [(SIZE - 1):0] q_b; > > `ifdef FF > always @(posedge clk) q <= d; > `elsif LATCH > always @(negedge clk) q_b <= d; //B-phase > always @(d) if (clk==0) q_b <= d; > > always @(posedge clk) q <= q_b; //A-phase > always @(q_b) if (clk==1) q <= q_b; > `else > // structural modeling > `endif > > endmodule > ---------------------------------------------- > > > > during compile/build, say +define+LATCH was used. now, at runtime, i > would like to know if the binary/snapshot was generated with that > particular compiler directive. if all "+define+<...>"s are stored inside > a data structure within the binary/snapshot, then via a vpi routine, i > can access it and see what was used at the beginning of simulation. > > > > inside a C code, i can have something like: > > > ---------------------------------------------- > char *str = (char *)NULL; > str = (char *)malloc(25*sizeof(char)); > > if ( (str = mc_scan_compilerdirective((const char *)"+define+LATCH")) > != (char *)NULL) ) > { > // +define+LATCH was used > // ... something similar to today's mc_scan_plusargs > } > else if ( (str = mc_scan_compilerdirective((const char *)"+define+FF")) > != (char *)NULL) ) > { > // +define+FF was used > > } > ---------------------------------------------- > > > > > thanks, > -nasim >Received on Wed Aug 9 10:52:01 2006
This archive was generated by hypermail 2.1.8 : Wed Aug 09 2006 - 10:52:07 PDT