Please forgive me if this is not repeating something that's already been discussed, but I haven't found anything about it. When using SV interfaces to model interconnects (typically for synthesisable hardware design, or for component modelling at a rather low level quite close to RTL) I have often found it would be useful to have a modport with the special property that it is a singleton, i.e. at most one client module may connect a port to this modport. There is no direct support for this in SV. However, if the modport includes an "export function" and the client module then provides that function, it becomes erroneous (detected at elaboration time) for more than one client to connect. Furthermore, if code in the interface contains a call to the exported function, it becomes mandatory for exactly one client to connect. You can get the same effect with an exported task that is not declared "extern forkjoin" in the interface, but I suspect the function form will be more useful. My question: is this a reasonable interpretation, and usage model, for the LRM definition? If so, would it be helpful for the LRM to mention it explicitly? Its description of "extern forkjoin" is clear enough, but the implications of exported functions without "extern forkjoin" are not very clear from the LRM text. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 Email: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com This e-mail and any attachments are confidential and Doulos Ltd. reserves all rights of privilege in respect thereof. It is intended for the use of the addressee only. If you are not the intended recipient please delete it from your system, any use, disclosure, or copying of this document is unauthorised. The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Received on Thu Apr 20 00:56:45 2006
This archive was generated by hypermail 2.1.8 : Thu Apr 20 2006 - 00:56:51 PDT