Subject: Re: Discussion On Channels
From: Kevin Cameron (Kevin.Cameron@nsc.com)
Date: Tue Aug 06 2002 - 14:22:00 PDT
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"
- 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.
Kev.
This archive was generated by hypermail 2b28 : Tue Aug 06 2002 - 14:24:18 PDT