Subject: Re: Discussion On Channels
From: sv-xx@grfx.com
Date: Sun Aug 11 2002 - 19:29:04 PDT
> From - Sun Aug 11 11:42:25 PDT 2002
>
> 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
Likewise, see below...
> -----Ursprüngliche Nachricht-----
> Von: Kevin Cameron [mailto:Kevin.Cameron@nsc.com]
>
> 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.
That's what the $lock does - it suspends or spins until the resource becomes
available (sorry I didn't make that clear).
> 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.
That's where the tools are supposed to tell you you did a bad thing.
> - 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).
CSP is a programming style, you don't have to use it if you don't want to.
> However, if you want provide a connection to unix pipes then you can rely on a predefined package
> with messages only.
There are no standard packages for Verilog in the sense that VHDL uses.
> 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?
That's in the last channel proposal I sent out.
>
>
> - Wolfgang
>
I think you have raised a good point, the semantics of Verilog are that the kernel can
switch execution from one process to another at the statement level so the possibility
of undesirable behavior is quite high and the concept of a "critical section" is
something we should add to SystemVerilog. However, the VHDL "monitor" is probably too
heavy handed, the approach I prefer is to add the minimum syntax and semantics that
let you implement what you need - the lock/unlock mechanism might work, but I only
suggested it because I thought you might be able to build "monitors" on top of it
and what we already have.
Regards,
Kev.
This archive was generated by hypermail 2b28 : Sun Aug 11 2002 - 19:37:31 PDT