Following is the first detailed draft of the changes required for a SystemC flavor. Some points are still being investigated; these are marked with *****. A final draft will be sent out as soon as these items are resolved.
Proposal for Group O (Issue 44), SystemC Flavor of PSL
===========================================
Detailed Changes
==============
30 Jan 2005
Section 2 - References
Add a reference to the OSCI SystemC standard, and perhaps also one to IEEE 1666 SystemC (which is currently under development). ******
Section 3 - Definitions
***** 3.1.20 False - add a sentence explaining what SystemC literals are interpreted as False
***** 3.1.51 True - add a sentence explaining what SystemC literals are interpreted as True
4.1, Abstract Structure; first paragraph - change "four flavors" to "five flavors"
4.1.2 Flavors; first paragraph
- change "four /flavors/" to "five /flavors/"
- add SystemC to the list of HDLs, after VHDL
4.1.2.4 GDL flavor - just before this, insert
4.1.2.4 SystemC flavor
In this flavor, all expressions of the Boolean layer, as well as modeling layer code, are written
in SystemC syntax (see OSCI Std SystemC). The SystemC flavor also has limited influence on
the syntax of the temporal layer. For example, ranges of the temporal layer are specified using
the SystemC-style syntax i,j.
4.2.1 Identifiers - second paragraph
- change "SystemVerilog and Verilog" to "SystemVerilog, Verilog, and SystemC"
4.3.2.1 HDL_UNIT - after the VHDL entry, add alternative
/ SystemC: /SystemC_class/_sc_module
4.3.2.2 HDL_MOD_NAME - after the VHDL entry, add alternative
/ SystemC: /SystemC_class/_sc_module_name
4.3.2.3 HDL_DECL and HDL_STMT
- in the definition of HDL_DECL, after the VHDL entry, add alternative
/ SystemC: /SystemC/_declaration (needs further definition) *****
- in the definition of HDL_STMT, after the VHDL entry, add alternative
/ SystemC: /SystemC/_statement (needs further definition) *****
4.3.2.4 HDL_EXPR
- change the title to HDL_EXPR and HDL_CLOCK_EXPR (to fix an oversight in the PSL v1.1 LRM)
- change the first paragraph to read
"Expressions shall be valid expressions in the underlying HDL description. This
applies to expressions appearing directly within a temporal layer property,
including those that appear within clock expressions, as well as to any sub-expressions
of those expressions. The definitions of HDL_EXPR and HDL_CLOCK_EXPR capture
this requirement, as shown in Box 5."
- after the VHDL entry, add alternative
/ SystemC: /C++/_Expression
- add the following to Box 5
Flavor Macro HDL_CLK_EXPR =
SystemVerilog: /SystemVerilog/_Event_Expression
/ Verilog: /Verilog/_Event_Expression
/ VHDL: /VHDL/_Expression
/ SystemC: /SystemC/_Event_Expression
/ GDL: /GDL/_Expression
- add the following production in support of the above:
SystemC_Event_Expr ::=
sc_event
| sc_event_finder
| sc_event_and_list
| sc_event_or_list
| sc_signal
| sc_port
4.3.2.5 HDL_RANGE - no change (not applicable to SystemC)
4.3.2.6 AND_OP, OR_OP, and NOT_OP
- in the definition of AND_OP, after the VHDL entry, add alternative
/ SystemC: '&&'
- in the definition of OR_OP, after the VHDL entry, add alternative
/ SystemC: '||'
- in the definition of NOT_OP, after the VHDL entry, add alternative
/ SystemC: '!'
4.3.2.7 RANGE_SYM, MIN_VAL, MAX_VAL
- in the definition of RANGE_SYM, after the VHDL entry, add alternative
/ SystemC: ','
- in the definition of MIN_VAL, after the VHDL entry, add alternative
/ SystemC: '0'
- in the definition of MAX_VAL, after the VHDL entry, add alternative
/ SystemC: 'inf'
4.3.2.8 LEFT_SYM and RIGHT_SYM
- in the definition of LEFT_SYM, after the VHDL entry, add alternative
/ SystemC: '('
- in the definition of RIGHT_SYM, after the VHDL entry, add alternative
/ SystemC: ')'
4.3.2.9 DEF_SYM - after the VHDL entry, add alternative
/ SystemC: '='
5.1.1 Bit expressions - add the following statement as a new paragraph after the VHDL statement:
"In SystemC, types sc_bit and sc_logic are Bit types."
5.1.2 Boolean expressions
- add the following statement as a new paragraph after the VHDL statement:
"In SystemC, type bool is a Boolean type."
- in the paragraph starting "Any Bit type is interpretable as a Boolean type", in the second sentence, change both occurrences of "Verilog and SystemVerilog" to "Verilog, SystemVerilog, and SystemC".
- in the paragraph starting "The return value from a PSL expressions ...", change the last sentence to read
"For Verilog, the return value is of the built-in logic type; for SystemVerilog,
the return value is of the built-in type logic; for VHDL, the return value is of
type /STD.Standard.Boolean/; for SystemC, the return value is of type bool."
(Note the correction of ',' => ';' before "for VHDL", as well as the addition of the clause for SystemC.)
5.1.3 BitVector expressions
- add the following statement as a new paragraph after the VHDL statement:
"In SystemC, each of the types sc_bv, sc_lv, sc_int, sc_uint, sc_bigint, and
sc_biguint is interpretable as a BitVector type."
- delete the paragraph starting "The return value from a PSL built-in function ...", because there are no built-in functions that return BitVector values (except for those that return AnyType values, which is more general, and there are already rules explaining that such functions return the same type as the input type).
5.1.4 Numeric expressions
- in the first paragraph after Box 15 ("In Verilog, any BitVector expression ..."), add the following final sentence:
"In SystemC, any expression of type bool, char, short, int, long, or long long,
or of types sc_bit, sc_logic, sc_int, sc_uint, sc_bigint, or sc_biguint, is interpretable
as a Numeric expression."
<what is the SystemCreturn type of a built-in function that returns a Numeric type (e.g., countones)?>
5.1.5 String expressions
- in the first paragraph after Box 16, add a final sentence identifying the SystemC string type. ******
5.2.1 HDL expressions
- update Box 18 to reflect the change to HDL_EXPR in 4.3.2.4
- in the paragraph starting "For each operator symbol in the HDL expression, ..." in the first bullet, add "SystemC" after Verilog and before GDL.
5.2.2 PSL expressions
- under Informal Semantics, in the second paragraph, change "Verilog or SystemVerilog" to "Verilog, SystemVerilog, or SystemC".
5.3 Clock expressions
- update Box 22 to reflect the changes to HDL_CLOCK_EXPR in 4.3.2.4
- add the following new paragraph after the paragraph starting "In the VHDL flavor, ..."
"In the SystemC flavor, any expression that SystemC allows to be used as the condition in an if statement can be used as a clock expression. In addition, any SystemC event expression can be used as a clock expression. Such a clock expression is considered to hold in a given cycle /iff/ it generates an event in that cycle."
6.2.1.7.1 Logical implication
- under Restrictions, add a new paragraph that reads:
"In the SystemC flavor, if the operator '->' appears in an expression and its left operand is a Boolean, then this expression shall be interpreted as a PSL logical implication, not as a SystemC member operation." ******
8. Modeling layer
- in the first paragraph, change the last sentence to include SystemC after VHDL.
- add a paragraph defining the modeling layer for SystemC. (It is not clear how to do this in a manner that is parallel with the others, since there is no 'synthesizable subset' for SystemC, unless perhaps we point to SystemC 1.0.) *******
A.3 HDL dependencies
- after the paragraph for VHDL (starting "For VHDL, ..."), add the following new paragraph:
"For SystemC, the PSL syntax refers to the following nonterminals of the OSCI SystemC syntax:
- expression
- sc_module
- sc_module_name
- declaration *******
- statement *******
[The reference above may be able to change to IEEE 1666 SystemC, if there is at least a draft IEEE SystemC LRM available to reference by the time we go to ballot.]
A.3.2 Flavor macros
Reflect the changes mentioned above, in 4.3.2.*, in this section
====================================================================
Original Sketch
============
28 Dec 2004
The following proposal presents a sketch of the definition of a SystemC flavor of PSL.
1. Flavor macros
The flavor macros would be extended with the following definitions, which follow the Verilog flavor for the most part, but also include references to a C++ nonterminal (constant_expression) and to SystemC class names:
DEF_SYM: '='
RANGE_SYM: ','
AND_OP: '&&'
OR_OP: '||'
NOT_OP: '!'
MIN_VAL: '0'
MAX_VAL: 'inf'
HDL_EXPR: /C++/_constant_expression
HDL_CLK_EXPR: SystemC_Event_Expr
HDL_UNIT: /SystemC_class/_sc_module
HDL_MOD_NAME: /SystemC_class/_sc_module_name
HDL_DECL: /SystemC/_declaration (needs further definition)
HDL_STMT: /SystemC/_statement (needs further definition)
HDL_RANGE: N/A
LEFT_SYM: '('
RIGHT_SYM: ')'
SystemC_Event_Expr would include the following:
sc_event, sc_event *,
sc_event_finder, sc_event_finder *,
sc_event_and_list, sc_event_and_list *,
sc_event_or_list, sc_event_or_list *,
sc_signal, sc_port
2. Data types
In the SystemC flavor, PSL type classes Bit, Boolean, BitVector, Numeric, and String would include the set of SystemC types shown in each case:
Bit:
bool,
sc_bit,
sc_logic
Boolean:
built in data types:
bool,
char,
unsigned char,
signed char,
short,
unsigned short,
int,
unsigned int,
long,
unsigned long,
long long,
unsigned long long
SystemC data types:
sc_bit,
sc_int,
sc_uint,
sc_bigint,
sc_biguint
sc_logic
BitVector:
sc_bv,
sc_lv,
sc_int,
sc_uint,
sc_bigint,
sc_biguint
Note that in SystemC, sc_bv and sc_lv do not have an implicit conversion to bool, which means that they can't be interpreted as true or false.
Numeric:
Same as Boolean
3. Event expression forms that can be used as clock expressions:
HDL_CLK_EXPR (above)
rose, fell (where the argument is a port or signal of bool or sc_logic)
4. SystemC types returned by endpoints and built-in functions:
bool (with the exception of prev()).
Possible Issues
============
There is a grammar conflict between PSL and C++. The following PSL/SystemC boolean expression is ambiguous:
a -> b
It could mean either "a implies b" or "member b of object pointed to by a". This conflict can only arise if someone writes a boolean expression using a pointer to a data structure that contains a member with the same name as another identifier in scope. In such a case, the "HDL" interpretation (member reference) should take precedence over the PSL interpretation (implication) to resolve the conflict. The user can rename their variables to avoid the conflict if it ever arises.
==================================================================
Received on Sun Jan 30 18:41:27 2005
This archive was generated by hypermail 2.1.8 : Sun Jan 30 2005 - 18:41:29 PST