Subject: External model ideas
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Fri Nov 15 2002 - 11:49:54 PST
Hello,
At the face-to-face last week I ended up with the action
item of proposing an interface for "external models".
I don't have anything LRM-like yet, but I do have a
proposal that we can use for debate and refinement.
My thoughts for requirements are:
1) Syntax consistency with SV external tasks/functions
2) Consistency with established VHDL syntax and semantics
The syntax for SV external function declarations is basically:
extern "C" <attributes> <function name> <parameters> ;
Refresher on VHDL external model syntax:
entity <Ename> <generics and ports> end;
architecture <Aname> of <Ename> is
attribute foreign of <Aname> : architecture is
"<implementation-specific information>";
begin
end;
Some interesting semantic points of VHDL external models:
a) At elaboration time, no declarative or body items of
foreign design units are elaborated. This applies to both
the foreign architecture and its associated entity.
b) When binding an external model into an instantiation,
the generics and ports of the model are bound as if the
model were not external. i.e. all type, size, and
direction requirements still apply.
c) It is possible for users to include declarative items
and statement parts (body) in foreign models. As mentioned
in a), these are ignored by the VHDL elaborator. As far as
I know, however, such items must be legal VHDL and must
pass through the VHDL analyzer.
d) It is common for VHDL simulators to include binding
information in the <implementation-specific information> field.
Shared object names and entry point functions are common.
******
For SV external models, I think we need to preserve those
semantic points from VHDL.
SV does have attributes via Verilog 2001 with syntax:
(* <info goes here> *)
I'm no expert on SV. One key of the VHDL style is that the
specific attribute name "foreign" is reserved and mentioned
in the LRM for the purpose of external models.
Does SV have similar reserved attribute names?
If not, should we start one up here?
Assuming the answer is yes, I would propose a
syntax as follows:
extern "C" module(<port list>);
<port declarations> // If ANSI-C style ports are not used
(* <foreign attribute> *) // Implementation-specific information
<all other module items>
endmodule
The requirements about generic and port binding carry over from VHDL.
The module's syntax must be legal and must be able to pass through
an SV analyzer.
The 'extern "C"' and (* <foreign attribute> *) are redundant.
The reason that the 'extern "C"' is there is for consistency
with SV external functions.
We may want to consider leaving the (* <foreign attribute> *)
as optional. Some implementations might not need it for
binding purposes - in that case simply the 'extern "C"' would do.
I don't know enough SV to make a good proposal on the exact
syntax of (* <foreign attribute> *). I would appreciate it
if someone else could step up to that one.
I'm looking forward to hearing your feedback here so that we
can refine this item down and get it into the hands of
the LRM-writing staff.
Thanks and regards,
Doug Warmke
This archive was generated by hypermail 2b28 : Fri Nov 15 2002 - 11:50:29 PST