As many of you had pointed out earlier, the idea of calling a Verilog task or function from a C function is not new, and has been there in CBlend/Superlog for some time. I am proposing the following at the risk of being redundant if a CBlend donation takes place in the future.

In any case, here are my proposals.

o A DirectC application shall be allowed to call a Verilog task or function from a C function similar to a call to another C function.

o If an external C function calls a Verilog task, no simulation time must elapse during the execution of that task. (This is, because a C function in DirectC is a zero-time event). However, no such restriction shall be in place when a Verilog task is called from a cmodule.

o The type of the arguments and the return type (for a Verilog function) shall be one of the types allowed by DirectC for a Verilog task or function calling a C function.

o The called Verilog task or function can be specified from the DirectC domain by Verilog full pathname. (This will allow us to call a specific Verilog task or function in the design hierarchy. We need to think about the actual syntax of this).

==================================================================

Previous emails on this subject:

On Sep 24 2002, Swapnajit Mittra wrote:
...
o It appears to me (and somebody pointed this out during the meeting too) that in DirectC there is no straightforward way of calling a Verilog task from C function. I mention this because I run a Verilog PLI related website and I get the question on how to call a Verilog task from C function (reverse direction of PLI) regularly. I believe CBlend of Superlog provides this already. I think we should consider providing this feature in SV-CC too.
...

On Sep 26 2002, Stuart Sutherland wrote:
...
I agree that there should be a mechanism for C functions to call Verilog tasks.
...

On Sep 26 2002, Alain Raynaud wrote:
...
3) Regarding calling Verilog tasks from DirectC, is there any technical reason why it can't be done (syntax, scheduling...)? Otherwise, I assume we could add it at some point, since there is so much demand for it. And it fits the idea above that C and Verilog modules and tasks could be swapped transparently.
...

On Sep 24 2002, Joao Geada wrote:
Swapnajit,
you are correct, DirectC includes no functionality for invoking Verilog tasks from within the C code, though it does posses mechanisms to wait on Verilog signals and to wait for a specific amount of time to pass. As many people seem interested in this other direction (C invoking Verilog), it seems reasonable that this be added to the DFLI requirements. Once it is in the requirements, we, as a committee, can work on extending the donations to support this capability.
...

On Oct 07 2002, Doug Warmke wrote:
...
*** C-calls-HDL task/function feature ***
DirectC lacks a C-calls-HDL task/function feature. We should add that feature with similar syntax. i.e. the function call looks like C, but in fact is implemented in SV. The linker/elaborator would bind the runtime image based on function name, just like a C linker. The CBlend binding mechanism allowed for that. Would there be any problem from the Synopsys/Co-Design point of view if that aspect of CBlend was resurrected in the SV standard?
...
(Please send me a pointer to any other email on this that I may have missed. I will add them to the list.)
- Swapnajit.

This will give a user complete independence to re-write, for example, cm_*().

This will be similar to the way a user-defined function $random overrides the system function by the same name in PLI.

Probably this is already true, but I could not find it mentioned in the VCS 6.2 DirectC User Guide.

- Swapnajit.

I believe this is already the case in VCS. I propose SV-CC makes this part of the requirement for DirectC i/f as this provides control to each Verilog module to re-define a task within its boundary.

- Swapnajit.

Do we want to permit calling PLI functions from a DirectC call or prohibit it? The first might be a nice feature, but result in less opportunities for code optimizations (as a result you'll never know what a function really can do). My proposal is either to prohibit this or to define some definition that clearly identifies whether a DirectC function calls other API's functions or not ...

- Michael.

-Michael.

I've been reading the recent discussions about HDL-to-C and C-to-HDL funcion
and/or task calling and realized that we got into technical (and interesting:-)
issues [with a lot of C++ bias] while kind of deviating from the original
requirements.
The disccusion on requirements started in early August, added C-calls-HDL functionality
and then seemed to cease without any decided conlucions.
The requirements seem to have been neither accepted nor rejected.
Anyway, I believe there is some consensus on some "kernel" functionality at least.

DirectC SV-nonSV interface may be roughly divided into the four functionality
classes:
(1) SV call nonSV function (non-blocking, i.e. func. with no timing control)
(2) SV call nonSV task (blocking, i.e. func. that may contain timing control)
(3) nonSV call SV function (or a task with no timing control)
(4) nonSV call SV task (blocking)

Apart from this classification there is the separate issue of what data types
can be exchanged between the two domains.

The "kernel" functionality for sure includes (1).
In order to have something done, I'm proposing to discuss and accept this basic
functionality.
I tried to separate and isolate different issues, so they could be decided
independently, from less controversial to perhaps more controversial.
That way we might proceed gradually and find the agreement upon the
small technical issues one by one, rather than all of them at once.

That will leave the other three classes of functionality still open, but at least
we'll make some visible progress.

Observation:
-----------
There are two facets of the interface: SV side and a foreign language side.
IMO these two sides can be defined separately; the foreign programming language
and the actual function call protocol and argument passing mechanism should be
transparent to SV.

Proposition:
-----------
The SV side of the interface may and should look identical regardless of
what the foreign side of the interface will be eventually decided.

The specifics of the argument passing may be eventually reflected in tiny
modifications of the syntax agreed upon, similarly to VCS DirectC variations
of 'extern', 'extern "C"', 'extern "A"'.

(1) DirectC interface includes as a minimum the capability to call non-SV functions
and void functions (i.e. functions that return no result) from SV code.
Such functions will be hereinafter refered to as external functions (xf).

Note:
A symmetrical functionality, i.e. the capability of calling SV functions and tasks
from a non-SV domain is not precluded; it's merely not addressed in this proposal.

(2) xf executes in 0 time. In other words, no simulation time passes during
the execution of xf. Xf must not contain timing control.

Note:
The above property does not preclude calling foreign tasks, i.e. functions with
timing control.
Such functionality is simply not addressed in this proposal and may be added
as a next feature.

(3) The usage and syntax for calling xf is identical as for native SV functions
and tasks.

(a) any xf can be called as a void function, i.e. its call may occur as a statement,
and a result, if any, will be discarded.

(b) xf may have zero or more formal arguments.

(c) xf may have input, output and inout formal arguments.
(Types of a result and formal args will be discussed later.)

(d) The evaluation order of formal args follows general SV rules (is unspecified).

(4) xf may access only SV data objects explictly passed as actual arguments to
a xf call (must not acces data objects that have been not passed explicitly as
arguments of the particular call)

(5) Each xf must be declared. Such declaration will be further refered to as
external declarations.

(a) An external declaration specifies function name, optional function result
and types and directions of formal args.
It may also provide optional names for formal args. Formal arg names serve only
as comments and are otherwise meaningless.

(b) Escaped names are not allowed for xf.

(6) A scope of an external declaration is the whole design.
External declarations may occur anywhere in $root scope, ie. outside of modules,
interfaces, functions and tasks.

A name of xf should not classh with any name declared in $root scope.

An external declaration of xf need not to precede an invocation of that xf.

Regular name resolving rules apply to xf. Therefore local names declared
inside a module (or interface) will obscure xf name; $root.xf_name may be used
to resolve to global name.

Note:
Since xf may not be declared inside a module, currently there is no way to specify
xf as a part of a module intended to be a library module.
In Verilog a library module is self-contained in a sense that it does not refer
to non-local definitions other that the other modules.
In SV some new mechanism seems to be needed that would allow to link definitions
referenced in a library module with that module; such definitions include typedefs,
interfaces, external functions. Such mechanism should also provide means for linking
the external code (in a source or in an object form) with a library module.

(7) xf may have multiple declarations as long as they are all equivalent.
Two declarations are equivalent if they specify the same function result type,
the same number of formal args, and for each arg respectively, the same
direction and type.

Note:
The above definition of 'equivalence' is vague about ranges of packed
and unpacked structures and arrays (absolute bounds and the slope).
The question is which of the following forms will be considered as equivalent:
[8:1], [1:8], [7{0]. [0:7].
We may require the exact match or relax it and require only the same number of
elements.

(8) Syntax of an external declaration
An external declaration follows SV rules: arg direction defaults to input,
direction may be specified for a group of args.

external_declaration:
'extern' optional_function_type function_name '(' optional_arg_list ')' ';'

optional_function_type: 'void' | func_result_type

function_name: identifier

optional_arg_list: optional_direction group_of_args optional_groups_of_args

optional_direction: /*empty*/ | direction

direction: 'input' | 'output' | 'inout'

group_of_args: formal_arg | formal_arg ',' group_of_args

formal_arg: formal_arg_type optional_name

optional_name: /*empty*/ | identifier

optional_groups_of_args: /*empty*/
| direction group_of_args optional_groups_of_args

func_result_type and formal_arg_type will be discussed later.

(9) Arguments passing for xf is ruled by WYSIWYG principle:
What You Specify Is What You Get.

(The possible exceptions for packed and unpacked ranges will be discussed
later.)

If the actual arg does not match exactly the formal one, a temporary variable
of the type specified for the formal arg is created and passed as an actual arg.
For input and inout args, such temporary is initialized with the value of actual
arg with the appropriate conversion; for the output or inout arg, the value of
the temporary is assigned to the actual arg with the appropriate conversion.
The assignments between a temporary and the actual arg follow general SV rules
for assignments and automatic convertion.

(10) For the SV side of the interface, the semantics of arguments passing is as
if input args were passed by "copy-in", output args were passed by "copy-out"
and inout args were passed by "copy-in, copy-out".
The actual implementation of argument pasing is transparent and irrelevant
to the SV side of the interface.

(a) xf must not modify the values of its input args

(b) The initial values of formal output args are unspecified and may be
implementation dependent.

(c) For output and inout args the value propagation (i.e. value change events)
happens as if an actual arg was assigned a formal arg immediately after
control returns from xf.

Types of formal arguments and function result
----------------------------------------------

Note: Ideally, any SV data type would be allowed.
I'm not sure this is feasible, however.

(11) As the minimum the following basic types are allowed for function result type
and formal arguments:
- basic types: int, real, byte, type, short.
- scalars of types bit, logic
- new primitive types, to be introduced to SV: pointer, string

These are the minimal requirements; other types will be discussed later.

(12) New primitive types: pointer, string.

These types are meant solely for DirectC interface and are intended for passing
values from non-SV domain back into that domain, with ability to store them in
the interim on SV variables.
They do not introduce the dynamic data types into SV and generally have no
interpretation on the SV side.
Therefore only a minimal set of rudimentary features is proposed here.

The proposition to introduce these new types does not preclude full-fledged pointers,
should the committee decide to introduce them into SV.

Type 'pointer' represents a generic pointer, 'string' represent a pointer to
C-like string.

Note that typedef allows to define different pointer types, e.g.:
typedef pointer list;
typedef pointer queue;

The use of the types pointer and string is restricted as follows:

- pointer/string may be used as types of function result and formal arguments
of external functions as well as SV functions and tasks or as types of variables

- may not be used as types of module or interface ports

- may not occur in packed structs or unions

- may be used in assignments (if both sides are of the same type)
and as actual args to function/task calls

- 0 (unsized constant zero) may be used as a value compatible with any pointer or
string type

- the only applicable operations for the values of these types are comparisons
!=, == with 0 (unsized constant zero) or other values of the same type;
no arithmetic operations or other realtional operators are allowed on them

- may not be used in explicit or implicit sensitivity lists or posedge/negedge
or in continupos assignments

- the initial value of a variable of type pointer/string is 0 (unsized constant).

- a string literal, i.e. characters in quotes, e.g. "a text" occuring as an actual
argument for a formal arg of type string is interpreted as C-style string
rathet than as SV encoding of a bit vector.
(This rule may be enhanced to allow string literals in assignments to
variables of type string.)

More on types of result and formal args of xf
----------------------------------------------

Ideally, any SV and C/C++ data type would be allowed.
This would require that every SV data type is mapped upon some type in the
foreign language, and similarly, any C/C++ type is mapped upon some type in SV.
There is no obvious 1-to-1 correspondence between SV data types and C types.

Contrary to popular belief (?), there are no common types between SV and C
other than basic arithmetic types.
SV inherits from C but is not a superset of C.
Structures defined in C by and large are not valid SV structures.

[VCS DirectC avoids the problem by generating headers that map V types onto
C types, and by restricting function result types.]

Of course, it's possible to define inductively the set of data types that
would be valid and semantically equivalent in both languages.
It would be, however, impractical and confusing.
Commonly, definitions in C are convoluted, refer to #define constants, involve
conditional compilation, differently specify array's size, etc.

SV parser might support full C or C++ syntax, but this will only add the burden.

A type of a formal arg or func result of xf usually will not be be useful, if user
cannot declare her/his variable of that type (unless a clear rule is provided
for conversion between SV and non-SV types) that could be used as an actual arg.
So, are we to allow imported types in SV code?

(13) DirectC interface should not impose any constraints on how SV data types
are actually implemented.

We may specify that the layout of SV structs should be the same as the layout
used by a C compiler on the corresponding C structs.

We shouldn't specify the layout of 2- or 4-state vectors, as this may be
platform dependent.

(14) I propose to restrict the types allowed for formal args and func result
- in addition to the basic types listed in (22) - to:
- scalars of type bit and logic
- packed 1-dimensional vectors of type bit/logic
- unpacked 1-dimensional arrays of the above.

(15) All vectors/arrays will be normalized to [n:0] regardless of the original range and increasing or decreasing order of indexing.
For example [1:8], [8:1], [7:0] will be equivalent declarations of the size of
packed a vector or unpacked an array.

(16) For the convenience, the size of the packed dimension or the unpacked
dimension
or both dimension may remain unspecified; such cases will be refered to as open
vectors and open arrays.

This will allow to write a generic code good for different sizes.

If a formal argument is specified as an open vector or an open array, then the
actual
arg will match the formal one regardless of the size of its, respectively,
linearized packed or unpacked dimensions.

Here are the examples of types of formal args:
bit
logic
bit [8:1]
logic [0:31]
bit[]
bit [7:0] array [1:10]
logic array [1:10]
logic [31:0] array[]
logic [] array [3:1]
bit [] array []

Comment: empty [] denotes open vector or open array.

Keyword 'array' separates packed and unpacked dimension (refered here as a
vector and an array).

(17) I propose to further restrict the types of function result to "small"
values: logic, bit, or bit [n:1], n<=32,
plus basic types discussed earlier.

Andrzej .

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

It would be nice to be able to distinguish C and C++ functions when defining DirectC functions. Of course this is dependent on Kevin's proposal to support C++. But when I just have some simple C function, I am not sure whether I would like to think about all the additional C++ stuff.

Probably it would already help to extend the directC definition to permit access_mode ::= ( "A" | "C" | "C++" )

Just loud thinking

-Michael

extern [ "linkname" ] svname ( ansi-args ); 

I would like to formally create an issue surrounding
the notion of the viability of the DirectC "cmodule"
in our C API.

This issue was originally brought up on October 7th
in the email posting entitled "Technical Discussion
of DirectC". Since then (and especially today!) lots
more action has taken place on email.

I will copy a few excerpts from these mails as the
seed content of this issue. I hope we can discuss
it at the face to face meeting Thursday.

*** From Doug's posting October 7th ***
> Here are some observations on DirectC, along with
> some suggestions for using/modifying/abandoning
> particular features of the donation.
>
> *** DFLI features vs. modeling features ***
>
> DirectC is both a binding mechanism (DFLI) and a
> modeling medium. The special language constructs
> such as the event control statement are what I call
> the modeling medium. Some of the API calls fit into
> there as well. The "extern C" function syntax and
> "cmodule" syntax are the binding mechanisms. (DFLI)
>
> I would like to concentrate on the binding mechanisms.
> The modeling medium has capabilities that are redundant
> with SystemC and TestBuilder (and perhaps a few
> home-brewed C environments). I suggest it is out
> of the scope of SV to create C modeling semantics.
> If we were to create C modeling semantics, why not
> just use SystemC? It has support for hierarchy,
> multiple-driver resolution, channels, and a host of
> other interesting features. Or another C modeling
> facility out there? It doesn't seem like we should
> be making this kind of decision in the context of
> our charter.

*** From Stuart's posting on 10/24/02 ***
>
> It is important that everyone realize that with the
> current Cmodule capability in the current DirectC
> donation we already are talking about having
> threads/processes in C/C++ that have their own
> quickthreads stack, and these C/C++ threads/processes
> already need to have the ability to perform event
> notifications to the Verilog side, wait on Verilog
> events, etc.
>
> So if the current proposal already allows true C/C++
> processes that can suspend execution based on events/time,
> etc., what fundamental capabilities we talking about
> adding in the current discusion?
> I'd say:
>
> 1) Ability for a C/C++ process to call a normal C/C++
> function/method and have that function/method suspend
> execution, possibly waiting on some Verilog event.
> (This is useful for example in protocol modeling in C/C++.)
> 2) Ability for a C/C++ process to call a Verilog task and
> have that verilog task suspend execution on some event.
> 3) Ability for a Verilog process (always block, etc.) to
> call a normal C/C++ function/method and have that
> function/method suspend execution, possibly waiting
> on some Verilog event. (This is useful for example
> in protocol modeling in C/C++.)
>
> I should note that I find the current "cmodule" stuff very
> distasteful since it is neither Verilog nor C/C++, but a
> strange mixture of the two. No doubt the current
> implementation recognizes some of the strange Cmodule
> keywords and syntax, and similar to the C-preprocessor,
> converts it all into normal C++ for compilation. A far
> better solution is to just stick with C++ in the first place,
> since then the C/C++ code can then be compiled, debugged,
> linted, and understood by normal tools & users. I don't see
> anything in the current proposal that cannot be cleanly and
> concisely modeled in C++.
>

*** Andrej's posting on 11/06/02 ***

> There have been strong demands to add the capability to
> call a task from either of two languages, SV and a
> foreign language. Specifically, to be able to call
> SV tasks from C.
>
> IMO such mechanism is fully orthogonal to external modules.
> It will provide alternative means for synchronization.
>
> It's easy to observe that if C may call SV task and SV may
> call C task (i.e. a function that may block/wait/pass time),
> then the whole synchronization can be expressed in SV.
> Simple SV tasks may be defined in with wait, delay, etc.
> Such tasks can be then used on C side as synchronization
> primitives. So, C function would delay or wait by calling
> primitive SV task which contains the needed delay or wait.
>
> Resuming: external modules and external/exported tasks are
> two indepenedent and orthogonal mechanisms for synchronization.
>
> Are both these mechanisms needed or we will give up one of
> them and pursue only the other one?
>

*** Kevin Cameron wrote on 11/06/02 ***
>
> I'd say that between SV (with the enhancements tabled in
> the EC committee) and SystemC, "cmodule" is redundant
> functionality. If you can cross-call the callee
> probably shouldn't worry about who the caller is.
>

*** John Stickley wrote on 11/06/02 ***
>
> This is an intriguing idea. In fact, this is a nice
> solution for handling raw C environments where underlying
> kernel to kernel synchronization is not automatically
> handled or where the C environment does not even have
> a "kernel" per se.
>
> Each of these time advance primitives could essentially
> be task calls from C to SV and, voila ! You (as a user)
> have instantly created a time advance facility for C
> from scatch by just defining some simple SV primitive
> tasks. Nice idea.
>
> Alternatively in more sophisticated cases such as where
> you have say a SystemC kernel that is automatically
> synchronized with the SV kernel in the vendor supplied
> infrastructure, you would not need to use these primitives.
> You could then just have your "C task" use the native
> SystemC mechanisms for time advance.
>
> Either way the API itself does not get involved with
> time advance semantics.
>
> And, with this "C task" solution, we probably eliminate
> the need for c-modules altogether.
>

*** Andrzej wrote on 11/06/02 ***
>
> You are right that within the space of C++ based HDL-s
> "cmodule" is redundant functionality, definitely inferior
> to SystemC.
>
> But we are not talking about HDL in C/C++.
> We are talking about interface between SV and C/C++.
> IMO external module is a powerful and convenient
> mechanism for connecting "something" to SV. I don't care
> how it's implemented in C++. Perhaps SystemC could be
> plugged-in as an implementation of external modules?
> I'm focusing on the SV side of the interface. And from
> that perspective communication via ports seems natural
> and attractive.
>

More to follow on this ISSUE, I hope!

Regards,
Doug Warmke

I'd like to formalize the issue of direct vs. abstract parameters. Several people have expressed that they don't like having an either/or approach to parameters.

My feeling is that we can have direct access for simple types that are easy to understand and document. Best performance will result, and usability will be fine.

For complex types, we need an abstract interface. Also, if extern "C" tasks are supposed to drive signals in the HDL design, an API call (probably one already in PLI) will be needed anyways.

Let's get some discussion going on this issue.

Regards,

Doug

I just wanted to squeeze in one last requirement issue before today's deadline for issues.

I would like to request a simple attribute that we can add to extern/export declarations called queueable.

What this does is to gives the compiler a hint that a function call can be queued rather than having to wait for a full round trip confirmation that the callee has been called and has returned.

It turns out that this simple extension to our function call interface elegantly opens up a whole facility to implement the equivalent of SystemC channels, Berkeley sockets, message queues, Unix named pipes, etc.

Ironically, the OpenVera LRM has a similar facility called the VSV interface. So they apparently recognized the need to have something above and beyond DirectC for this type of capability.

But what this proposal does is it gives you the entire capability without adding a whole new API to support it.

With an ultra simple modification of DirectC, you can cleanly support a socket type of channel like VSV did.

This is extremely useful for creating efficient 1-way blocking and non blocking channels between SV processes and C threads. Queueable functions are ideal for implementing efficient, optmized streaming channels between models.

And, in an implementation, if you've paid the price to imiplement DirectC function calls, with slightly more work you can get this feature almost for free.

The only requirement of queueable functions they can only have input arguments, no outputs. Think of these as one way transaction channels that the infrastructure can queue to arbitrary depth before blocking the caller.

Here's an enhanced syntax that shows the queueable attribute:

extern_decl ::= extern [attribute {, attribute}] return_type fname ( [arg {,arg} );

attribute ::= pure | queueable

export_decl ::= export [attribute {, attribute}] [scopename{::scopename}::]fname ["cname"];

scopename ::= modulename|interfacename

attribute ::= pure | queueable

By placing the queueable attribute on the function declarations the user is hinting to the compiler that it can do this one-way optimization. In many cases that will save having to send extra messages in the opposite direction when the function call returns. Remember, even if the function has a void return argument, a return confirmation message is still required on a non-queueable function call.

I've attached a revision of my PowerPoint proposal that adds this.

-- johnS

Hi all,

Since today is the deadline [ and we Germans always need to have the last word ;-) ] I would like to enter another proposal I already said once, but forgot to include in the ISSUE list:

Provide all parameters declared as INPUT (and only them) with the const keyword on the C side of the API. By doing so the compiler on the C side can validate that the corresponding C value is not being overwritten. IMHO it makes sense to use such built-in functionality whenever it is possible -- especially at no cost.

-Michael