Subject: ISSUE:DirectC:Abstract Access Method requires rewrite of code
From: Michael Rohleder (Michael.Rohleder@motorola.com)
Date: Tue Nov 05 2002 - 08:26:38 PST
>From a user perspective it is _not_ acceptable that I have to rewrite a DirectC function after I have debugged it. This is a
manual, error prone process I will want to avoid under any circumstance. It is also a problem, since after changing the already
debugged version, I might just introduce some more problems. There must be some way to automate this work, something I would regard
as a critical and important feature.
On the other side it is my experience that having a more secure version for debugging or providing additional checks is very useful.
I would even request to have a third capabililty that permits me to interfere debug information (or writing a debug log file) with
these calls.
A poor man's solution we have implemented some years ago in one of our internal simulator is as follows [I do not propose this
solution, but this might be at least stimulate some discussion]:
- provide a set of parameter retrieval service functions for each parameter type
- provide a set of parameter modification service function for each parameter type
- overload these service functions within the predefined header file (I assume we have sthg. like this for SystemVerilog) to map
to:
* directly retrieving the value without any check for direct access
* retrieving the value after performing some obvious checks in case of Abstract Access
* providing some additional debug information in case of debugging ...
Simple hypothetical example how the method we have used would look like on SystemVerilog:
A) Assume the Direct C function definition
extern "C" void my_function( input bit [31:0] r1, output bit [32:0] r2 );
...
module dev1;
reg [31:0] bit1;
reg [32:0] bit2;
initial
begin
...
my_function(bit1,bit2);
...
end
endmodule
B) When using the argument type mappings in table 1-4 of the DirectC document, we might want to define some access functions of the
type:
int sv_get_int( parameter );
double sv_get_real( parameter );
scalar sv_get_bit( parameter );
...
C) The real mapping of one of this functions is dependent on the mode choosen ...
- in normal mode, it just returns parameter [for runtime reasons you might just want to #define this ...]
- in abstract access mode, you perform some plausibility checks like (e.g. sv_get_bit)
check whether the parameter is input, inout, but not output ...
run vc_isScalar(parameter) to check the type
and provide some meaningful error message about the parameter and its origin (file, line in SV code), reason for the failure)
- in debug mode provide some additional information at a debug stream that can be defined by the user ...
In all cases the function code of my_function looks the same. It always uses sv_get_bit() to get the first parameter; I choose by
some #define what version I actually want to use (we have none, CHECK or DEBUG).
Just loud thinking, but this is some problem we clearly need to attack.
And please understand
- I don't say we have to define what actions to take in normal, CHECK (Abstract Access) and/or DEBUG mode
- I don't say this is the implementation to choose
- I just say I hate to have my code being rewritten or write twice ...
Regards,
Michael
This archive was generated by hypermail 2b28 : Tue Nov 05 2002 - 08:27:04 PST