Subject: AW: Discussion On Channels
From: Wolfgang.Ecker@Infineon.Com
Date: Sun Aug 11 2002 - 06:04:12 PDT
Dear Kevin,
I am sorry but I cannot agree with your comments. Please find my points inserted in
your comments at the end of this e-mail.
- Wolfgang
-----Ursprüngliche Nachricht-----
Von: Kevin Cameron [mailto:Kevin.Cameron@nsc.com]
Gesendet am: Dienstag, 6. August 2002 23:22
An: Wolfgang.Ecker@Infineon.Com
Cc: sv-ec@eda.org
Betreff: Re: Discussion On Channels
Wolfgang.Ecker@Infineon.Com wrote:
Hi,
I propose not to include channels in SystemVerilog but a lower level
construct called monitor.
The monitor has several advantages over the channel:
* Several types of channels might be used:
* Buffered (finite+size, infinite), non Buffered
* Synchronous / Asynchronous in reading/writing or both (for the
penalty of potential data lost)
* With or without specific accept function
* etc.
All of them have their benefits and are used in system description.
Having the monitor construct, a set of channels can be pre-implented
in a file (might relate to a package) and made general available.
This can be done without extending the language SystemVerilog too
much, restricting the modes of channels and giving the user the
freedom to implement their own channels
* Several other communication mechanisms as score boards, mail boxes,
concurrently accessed stacks or global memories can be implemented
as well as pure synchronisation mechanisms (e.g. any kind of semaphors).
As background: This construct (also available in Ada)
encapsulates values, concurrent access procedures to this values,
and instantiation code within an abstract data type. The monitor's
values may only be accessed via its access procedures and only one
process may active in the monitor at any time. The access procedures
are critical sections i.e. can be executed exclusively only.
Additionally an entry condition may be specified which must be
satisfied for the execution of access procedures. A monitor may have
a queue of processes which are waiting to access it. If the critical
region of the monitor is free the entry condition of all processes
accessing the monitor is checked. If more than one of the processes
have a true entry condition the process to enter the monitor is
selected non-deterministically.
I added a proposal for implementing them to the mail.
What's your opinion?
Regards, Wolfgang
As you describe it above I think it is something that you could implement
fairly easily on top of SystemVerilog interfaces. The missing construct
is a semaphore of some kind that lets you do real parallel processing
at the interface and restrict access to critical sections of code.
Something like a $lock system task might do e.g.:
task crit (input a, output b);
$lock(a,b); // wait for exclusive access
critical_func(a,b);
$unlock(a,b); // release
endtask
For simulators that don't do parallel processing the $lock and $unlock
wouldn't actually do anything. However users are unlikely to remember
to add the locks so you can also do the locking implicitly with a rule
like:
"No processes that directly share data will be active concurrently"
Your argument here is not valid in two cases:
1) The "critical_func" needs some time to execute (perhaps a protocol on
wires). The simualtor kernel must provide in every case (also a single
process solution) a mechanism to block other request to the critical section.
2) The "critical_func" calls other tasks, which enter critical regions. In this
case, the simulator kernel must be able to schedule tasks potententially
inside one simulation cycle.
- where "share" means read or non-blocking write, so a process that
may want to read 'a' can't be evaluated while another process is
active that might write to 'a'. Bridging into C/C++ would require
being able to cross-call the interface tasks and/or a PLI/VPI call to
request/release the locks.
A CSP approach doesn't share data so semaphores etc. are unnecessary
in users' code, which is why I'd prefer the channel construct I
described to be the primitive. Also it's relatively easy to connect
that kind of channel to a Unix pipe to get into other environments
without using PLI/VPI.
I agree with that point if "system verilog" restricts to CSP (was this decided, sorry I don't know).
However, if you want provide a connection to unix pipes then you can rely on a predefined package
with messages only.
Concerning the connection of channels to pipes, can you please specify the mechanism
how operating system settings of the pipe and verlog settings of the behavior of the channel
are brought together?
- Wolfgang
This archive was generated by hypermail 2b28 : Sun Aug 11 2002 - 06:16:14 PDT