Subject: [sv-bc] Re: Post 3.1
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Fri Apr 25 2003 - 10:46:16 PDT
I was wondering if post 3.1 we could look at re-implementing the
language (as suggested by Jay) in ways that will be backward
compatible with 3.1 and Verilog-2001 but will create a better
base for moving forward. It would mostly involve transfering
object and type definitions into (standard) header files, and
extending the type/class system to support more complicated
cases. E.g.:
1. Mailboxes and semaphores can actually be built by users
if you have a simple mutually exclusive locking mechanism
("mutex"), so you can add a Posix thread style mutex to the
language and re-create the mailbox and semaphore constructs
as classes built using mutexes in header files.
2. Types like "event" which now have bizarre declaration
and usage semantics can be redefined as a class based on
a more primitive object and the declaration and assignment
methods can be defined in the class. That would allow
users (and vendors) to base other types on the primitive
object which have more traditional Verilog behavior (i.e.
static declaration) which is more friendly to synthesis.
3. Rationalize the struct/class/module/interface declaration
mechanisms down to just module, and add preprocessor
commands so that you can morph syntax E.g.:
`morph(m,c) "struct m {c}" "module m; c endmodule"
struct foo { module foo;
int a; --> int a;
} endmodule
Changes of that type should free up keywords and reduce the
complexity of the core language. The core language would end
up at the IEEE and the header files would be managed by
Accellera.
Just some thoughts :-)
Kev.
This archive was generated by hypermail 2b28 : Fri Apr 25 2003 - 10:51:01 PDT