Discussion On Channels

Subject: Discussion On Channels
From: Wolfgang.Ecker@Infineon.Com
Date: Mon Aug 05 2002 - 00:22:20 PDT

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

This archive was generated by hypermail 2b28 : Mon Aug 05 2002 - 00:30:21 PDT