Re: [sv-ec] class extension across hierarchical boundaries

<forwarding bounced email from Kaiming Ho>


-------- Original Message --------
From: Kaiming Ho <kmh@stretchinc.com>
Subject: Re: [sv-ec] class extension across hierarchical boundaries
To: sv-ec@server.eda.org
Date: Fri, 19 Oct 2007 15:38:47 -0700 (PDT)
Cc: kmh@stretchinc.com (Kaiming Ho)

    In response to some of Arturo's comments (below), I want to point out
what I think are dangerous assumptions (esp. coming from an EDA vendor) on
how users should be using SystemVerilog.  This ability to have classes in
modules (mixing functional and structural hierarchy), as well as arbitrary
extensions thereof is one of the 'new' and 'innovative' features of this
language.

   One must remember that users of SystemVerilog are generally design
and verification engineers, and undoubtably will come from a verilog
background.  There is no value in trying to copy other OO languages,
since the training of these users is generally not sufficiently strong to
appreciate, let alone understand the subtle aspects of this.  Put
this together with EDA R&D engineers, who actually have this training,
and we have a dangerous disconnect.

   A verification engineer will use SystemVerilog to do modeling and
verification because he/she does not want to use C++.  Making SV
follow aspects of C++ doesn't buy us anything -- might as well go
back to using C++ for modeling.  This makes SystemVerilog as a language
less valuable.

kaiming
> 
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
> Behalf Of Arturo Salz
> Sent: Friday, October 19, 2007 1:09 AM
> To: sv-ec@server.eda.org
> Subject: [sv-ec] class extension across hierarchical boundaries
> 
[..snip...]
> 
> Given all this complexity, we wonder what is the programming model that
> requires classes, which provide functional hierarchy, to also include
> structural hierarchy? No other object-oriented language such as C++ or
> Java include structural hierarchy. Yet, these languages are perfectly
> capable of handling the most demanding modeling problems with ease,
> using only functional hierarchy.
> 
> If a rational, coherent, and well understood programming model and
> methodology are developed then these restrictions could be lifted in a
> future release. But at present, we feel that it is best to limit P1800
> to the more restrictive, but well understood methodology.
>
[..snip...]
> 
> I stand by my previous assertion that mixing structural and functional
> hierarchies represents a new paradigm that does not exist in other
> mainstream OO languages, hence, I find it difficult to understand the
> motivation for explicitly introducing such a feature into SystemVerilog.
> It is a good practice to restrict a problematic feature until the issues
> associated with such a feature are better understood and hashed out. We
> can always loosen a previous restriction without creating backward
> compatibility issues or divergent implementations.
> 

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