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.Received on Fri Jul 6 02:14:22 2007
This archive was generated by hypermail 2.1.8 : Fri Jul 06 2007 - 02:14:50 PDT