[sv-bc] RE: areas of implementation divergence

Here is a (by no means complete) list of Mantis issues that I have seen users report as leading to different behaviors from different vendors

902	Instantiating gates, primitives and modules in interfaces
1169	task/function port lists and internal block item declarations
1171	named port connections for implicit ports with same name
1712	Clarifications needed on foreach iteration
1801	Problem with omitted foreach iterator before dynamic array iterator
2429	Behaviour of virtual function call from base class constructor - should be defined
2686	Ballot comment #69: Bit/Part-select errors should be reported uniformly.
2769	clarify which compiler directives can be specified within design elements
2841	non-integral function actual argument allowed in a constraint expression?
2902	syntax description for rand_mode and constraint_mode uses :: instead of . - and task instead of function void
4177	process state question



> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> Rich, Dave
> Sent: Monday, March 02, 2015 11:20 PM
> To: Steven Sharp; erik.seligman@intel.com; Maidment, Matthew R; sv-
> bc@eda.org; sv-ec@eda.org
> Subject: [sv-bc] RE: areas of implementation divergence
> 
> This list is going to be hard to produce in time for Friday's meeting while many
> of us are at DVCon.
> 
> If you look at only the SV-BC category, there are 173 open issues. Many of
> these are slightly above editorial LRM issues. Some are as simple as 4759 (is '0
> allowed in a concat) The divergence is one tool produces an error, another
> tools allows it. Here it's easy to assume that allowing it will interpret it to
> mean 1'b0.
> 
> Then there are all the Macro issues.
> 
> I don't have time to add more to this list, I could spend hours.
> 
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> Steven Sharp
> Sent: Monday, March 02, 2015 5:03 PM
> To: erik.seligman@intel.com; Maidment, Matthew R; sv-bc@eda.org; sv-
> ec@eda.org
> Subject: [sv-ec] RE: areas of implementation divergence
> 
> I think this is in a slightly different category.  The LRM is clear that this is not
> allowed, so this is not ill-defined.
> 
> There may be divergence because some implementations have chosen to
> support non-standard extensions to the LRM.  Some of those could be
> considered to be the "fault" of the LRM, for being unnecessarily restrictive or
> inconsistent.  But it still isn't the same as the language being ill-defined by the
> LRM.
> 
> 
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> Seligman, Erik
> Sent: Monday, March 02, 2015 1:36 PM
> To: Maidment, Matthew R; sv-bc@eda.org; sv-ec@eda.org
> Subject: [sv-ec] RE: areas of implementation divergence
> 
> The question of whether a bound [N] is supported in packed array
> declarations, as in http://www.eda.org/svdb/view.php?id=325 , might be an
> example here.
> 
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> Maidment, Matthew R
> Sent: Monday, March 02, 2015 12:03 AM
> To: sv-bc@eda.org; sv-ec@eda.org
> Subject: [sv-bc] areas of implementation divergence
> 
> All.
> 
> During discussions about the next PAR, it has been raised several times that
> there are problematic areas in the language that are causing implementation
> divergence.  Would some of you please reply to this thread identifying
> specific areas of the language that are ill-defined and are leading to this
> divergence?
> 
> 
> Thanks.
> 
> Matt
> 
> 
> --
> 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.
> 
> 
> 
> 
> --
> 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.
> 
> 


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