RE: [sv-bc] -dangles Proposal

I have not followed the last few mails closely, this supposedly being my
day off, but a few more general semi-random thoughts:

As some of the discussions have shown, these checks start to become much
more complex once you go beyond the synthesizable RTL subset, and I
don't think simulators should be getting into such specific
(synthesizable RTL) areas.

Lint tools typically do these checks, at least partly, by running
mini-synthesis of their own, and we certainly don't want simulators
doing that.

You find some interesting/weird cases, like:

assign a = b ? c : a;

where a is not used anywhere else. Is a dangling?

or

b[31:0] = a [32:0] ;

Is a[32] dangling?

Even lint tools require iterations on their algorithms till they get
them relatively bug-free.

Another advantage of lint tools for this type of stuff is that you can
run lint tools at an earlier stage than simulators. For example, lint
tools are much easier for separate compilation. That is, you don't need
the definition of an instantiated module in order to run the tool on the
instantiating module, and the tool will simply say it is treating the
instantiated module as a black box.

I would not object to simulators adding some simple checks of this sort,
but it should be a tool-dependent feature, not part of the language, and
lint tools will always do this better on the synthesizable part of the
design. However, the advantage of a simulator is that you can run this
type of checks, with its limitations, on any type of code.

I also agree that I don't want to have to start adding all sorts of
fluff around parts of my code just to suppress compiler warnings. This
is exactly what Cliff has warned about in other places, things which
make code verbose.

Shalom

> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
> On Behalf Of Jonathan Bromley
> Sent: Friday, July 06, 2007 12:14 PM
> To: Clifford E. Cummings; sv-bc@server.eda.org
> Subject: RE: [sv-bc] -dangles Proposal
> 
> Cliff,
> 
> As you're aware I'm not at all sure this should be a
> language feature - I'm of a mind to agree with Shalom
> that it is something a linter should sort out.  Later in
> this email I'll indicate a couple more things that might
> fly out of Pandora's box and start causing trouble.
> 
> However, if you wish to pursue it, could I at least
> suggest that:
> (a) you avoid the word "dangles", which lacks gravitas :-)
> (b) you consider separating the detection of undriven
>     and unloaded nodes (report_undriven, report_unloaded??)
> 
> Wearing my RTL designer's hat I invariably regard undriven
> nodes as a pernicious error, but I commonly create unloaded
> nodes and ports that I expect my synthesis tool to strip
> away; this is particularly true when designing re-usable,
> configurable blocks that may have optional features,
> but it's also handy when I create satellite code in
> support of assertions (and that's another point: does
> an assertion represent a sink of a signal?  What about
> a $display?  What about virtual interfaces, where sources
> and sinks may not be known until runtime?  PLI arguments?).
> 
> For such unloaded nodes, I don't really want to create
> artificial sinks just to keep a compiler directive happy;
> I'd far prefer to have a good lint tool and teach it about
> specific nodes that I don't want it to check.
> --
> 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.