Subject: AW: Discussion On Channels
From: Wolfgang.Ecker@Infineon.Com
Date: Sun Aug 11 2002 - 06:04:13 PDT
Dear Erich,
thank you for your recommendations. I added the paper only to give the sv-committee first informations about
monitors (I had no others when I typed the e-mail offroad). I will do my best to come up with a first proposal
in the next days.
Wolfgang
-----Ursprüngliche Nachricht-----
Von: Erich Marschner [mailto:erichm@cadence.com]
Gesendet am: Montag, 5. August 2002 15:31
An: Wolfgang.Ecker@Infineon.Com
Betreff: RE: Discussion On Channels
Hi Wolfgang,
I agree with your suggestion that monitors should be added to System Verilog. The monitor concept was the key element in Brinch Hansen's Concurrent Pascal, which enabled very elegant yet efficient design of multi-process software systems. We even thought seriously about including it in VHDL in the first round of IEEE standardization, but there was not enough support for it at the time.
I glanced over the proposal you attached - and noted that it is about adding monitors to VHDL, not to (System) Verilog. I suspect that a paper about VHDL will "fall on deaf ears" in the System Verilog committee. If you were to redraft the paper and focus it on System Verilog, I think the idea would be given more attention.
Regards,
Erich
-------------------------------------------
Erich Marschner, Cadence Design Systems
Senior Architect, Advanced Verification
Phone: +1 410 750 6995 Email: erichm@cadence.com
Vmail: +1 410 872 4369 Email: erichm@comcast.net
| -----Original Message-----
| From: Wolfgang.Ecker@Infineon.Com
| [mailto:Wolfgang.Ecker@Infineon.Com]
| Sent: Monday, August 05, 2002 3:22 AM
| To: sv-ec@eda.org
| Subject: Discussion On Channels
|
|
| 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 : Sun Aug 11 2002 - 06:16:17 PDT