Re: [sv-bc] catching compiler directives at runtime.....

From: Greg Jaxon <Greg.Jaxon_at_.....>
Date: Wed Aug 09 2006 - 10:51:52 PDT
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