[sv-bc] RE: [sv-ec] That modport direction issue again

After reading through Mantis 2114 I have a few comments.

Simulation tools are expected to accept the whole language.
Synthesis tools only accept a subset of the language that they
have designated as synthesizable. There will always be cases
where simulation tools accept a design, and synthesis tools
do not.

That aside, in System Verilog an effort was made to design
the language so that simulation tools could check the 
synthesizability of some constructs. This was the reason 
the always_comb was added to the language. To allow simulation
tools to enforce some of the rules that synthesis tools require.

Unfortunately, in the examples in 2114 you are not using 
always_comb to drive these signals. You are using initial blocks,
which are not synthesizable constructs. Simulators must allow 
multiple initial block processes to write to a single variable.

If you convert one of the drivers to an always_comb, as shown below,
then there is at least one major simulator that will flag this as
an error, although we do allow customers to turn off this error 
check and run the simulation anyway. 

interface I;
    logic L;
    modport MP (output L);
  endinterface

  module M (I.MP imp);
    always_comb
      imp.L = 1;
  endmodule

  module M2 (I.MP imp);
    initial
      #5 imp.L = 0;
  endmodule

  module top2;
    I i();
    M m(.imp(i.MP));
    M2 m2 (.imp(i.MP));
  endmodule

> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On 
> Behalf Of Jonathan Bromley
> Sent: Tuesday, October 16, 2007 2:26 PM
> To: sv-bc@eda.org; sv-ec@eda.org
> Subject: [sv-ec] That modport direction issue again
> 
> hi BC, EC,
> 
> On a number of previous occasions I've nagged away at the 
> issue of what it really means to have a modport with an item 
> of "output" direction, without getting a definitive result.  
> Synthesis implementors strongly take the position that it 
> represents a continuous assignment to the corresponding 
> interface item, but the LRM does not really justify this and 
> all the major simulators take the other position, that the 
> modport-type port represents an alias to the modport 
> instance.  The consequences of this divergence are unpleasant.  
> I have created Mantis 2114 to ask for clarification.
> 
> As I hope I've made clear in the bugnote, clarifying the LRM 
> in the synthesis implementors' favour would severely impact 
> the usability of interfaces and modports by outlawing some 
> obvious idioms, including certain uses of virtual interface 
> (which is why EC is copied, although I've marked the Mantis 
> for BC since they are primarily responsible for interfaces).
> 
> I am convinced that this is quite badly broken, and needs 
> fixing.  Unless someone can persuade me otherwise, I urge BC 
> to take a look at this and get it on to their agenda if at 
> all possible.  I'm happy to do the legwork of writing a 
> proposal if people can tell me what the consensus is.
> 
> Thanks
> --
> 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
> 
> The contents of this message may contain personal views which 
> are not the views of Doulos Ltd., unless specifically stated.
> 
> --
> This message has been scanned for viruses and dangerous 
> content by MailScanner, and is believed to be clean.
> 
> 
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.