Hi, All - Concerning dangling net detection. I have received great feedback from both Jonathan and Shalom on this possibility and would like to address some of the issues they raised and perhaps ask more questions. The idea behind this switch is to catch as many typos and mis-connects as early as possible. It may not be possible to find all the problems (I never thought it would be) but if there is a SIMPLE way to find many more bugs early in simulation (elaboration), I think the capability has merit. Some people believe that the `default_nettype none compiler directive solves many problems, but as I have outlined in exchanges soon to appear on John Cooley's deepchip.com, I believe `default_nettype none has serious flaws that make it worth avoiding. I have proposed two forms of the dangling net trappers: Compiler directives and a command line switch. Nobody has to use any of these capabilities, but I believe if they were available, they would be a highly favored approach to finding multiple problems. Shalom points out (with some support from Jonathan) that these capabilities should be in the domain of linting tools. Perhaps this is true, but I still believe there is extreme value in mandating that simulation compilers at least check for and report most of the problems. Some companies do not consider Verilog a serious design tool because it allows the user to get away with too many shortcuts that might prove fatal to a well-structured methodology. I don't want to go to extreme-typing like VHDL but there are some connection-checking capabilities that would be very beneficial in SystemVerilog. First, for designs and testbenches that one would like to check with surrounding code that one does not want to check or that is too difficult to instrument for dangle-checking, no-touch code can be easily surrounded with: `report_dangling off `include "mofile1.v" `include "myfile2.v" ... `include "myfilen.v" `report_dangling on (And remember, nobody is forced to use this capability) Then all of the files can be compiled with a -dangles switch (or some other switch-name with more gravitas ) Remember - usage of this switch is VERY OPTIONAL (but very useful). I believe both Shalom and Jonathan have mentioned that finding undriven nets is a good thing; that undriven nets are always bugs. I don't think there is any argument on this. I believe both Shalom and Jonathan have mentioned that there are times when drivers without loads are sometimes useful in a design. Shalom gave some great examples. I had mentioned the possibility for making continuous empty assignments of the form: assign () = scanin; I still think this form might be useful in places, but perhaps another option (not previously proposed) is to declare empty connection nets. How can we do this without adding new keywords, still make it somewhat intuitive and easy to code? I believe Jonathan and Shalom are big declaration proponents (I am not). But I would become a declaration proponent for unloaded driver-nets if I could make a declaration of the form: wire () scanin, ... <other driver-only-nets> Note the addition of the optional empty parentheses after the wire keyword. Verilog engineers are already used to empty parenthesis for named port connections. (1) no new keyword, (2) easy to code and it is in declaration form. Would we want wire () to also work for undriven nets? Based on Shalom and Jonathan's feedback, perhaps not (but I am open to discussion). Empty net declarations could also be place-holder net declarations (undriven and unloaded dangling nets). I would hope vendors would give me a switch to disable the empty wire () declarations to see how close I am to having all nets driven and loaded. Shalom has raised a few valid "weird" cases: Shalom mentioned that tools would have to do some synthesis analysis. I don't think this is necessarily true. I am interested in elaborated connectivity analysis, which by itself would prove very useful. I don't need to find every last problem, just the majority of the problems very quickly and to have the capability to put together a methodology that would allow me to catch all bugs, when followed. A couple of Shalom's interesting "weird" cases: [SB] assign a = b ? c : a; where a is not used anywhere else. Is a dangling? [Cliff] I could go either way on this example. I think this might be difficult to catch and that tools could call this a driver and a load and not report it. As far as I am concerned, this weird case could be legally missed if it made it easier to pass this proposal. [SB] b[31:0] = a [32:0] ; Is a[32] dangling? [Cliff] Yes, a[32] is dangling and should be reported unless the a-bus is declared as: wire () [32:0] a; // ignore unloaded drivers on a-bus. [SB] Even lint tools require iterations on their algorithms till they get them relatively bug-free. [Cliff] and I don't want this enhancement to be that complex. I believe we can easily identify 95%+ of the easy bugs and let linting tools take the tough connection algorithms. Maybe over time, vendors will complete on the thoroughness of their connectivity checker (??) [SB] 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. [Cliff] True. Linting tools can do this better, but I doubt if more than 30% of all Verilog designs are run through linters. I'm sure it is relatively common at big companies like Intel and Freescale, but not at smaller cash-strapped companies. Even at larger companies, I find engineers run the linters a time or two and then make "just a few changes that should not cause any problems." The compile option does require access to submodule definitions, but so does the simulator once we elaborate the design. Turn on the -dangles switch when it will help you the most and leave it off if it causes you grief. I anticipate that I would have it on by default. [SB] 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. [Cliff] I think we are finding common ground, except I would like to mandate this ability from all simulators. [SB] 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. [Cliff] A very valid concern, which is why I am looking for a simple syntax that helps far more than it could possibly hurt. Finding dangling connections or telling the tool I know about dangling wires with "wire ()" seems pretty simple. Many engineers already declare all wires (not me) and now they can indicate which wires are intentionally dangling with "()" and leave the rest for the elaborator to check. REMEMBER - turning on the switch is optional. And from Jonathan: [JB] > However, if you wish to pursue it, could I at least > suggest that: > (a) you avoid the word "dangles", which lacks gravitas Gotcha ... more gravitas! :-) How about: -crcdncd (Cliff's Really Cool Dangling Nets Compiler Directive) :-) The switch name is not critical to me. Searching for dangling nets seemed to make a good switch name, but on this I am easy. > (b) you consider separating the detection of undriven > and unloaded nodes (report_undriven, report_unloaded??) Yes, to some degree covered above. Flag undrivens, but allow "wire ()" declarations to notify of intended unloaded drivers. > 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?). Assertions, display command access, virtual interfaces and PLI are all excellent topics to discuss. Thanks! First cut from Cliff: Assertions and display commands seem to form sinks. Assertion action blocks could also form drivers. virtual interfaces may be a bit tougher. Perhaps they would require "wire ()" or "logic ()" declarations?? Thoughts? PLI arguments - I am not an expert on the topic. I am willing to consider options from experts. > 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. I was listening loud and clear when Jonathan and Shalom both gave this feedback. I think the optional "()" is not too intrusive for those who wish to use this option and many engineers are already declaring wires, now you can add 2 characters to the EXCEPTION declarations. For years, I have wanted to declare no-connect nodes, but knew that the "nc"-keyword declaration would be a hard-sell (probably very common net name). Just this weekend I thought of the empty parentheses on declarations to declare potential no-connects. It's simple, no new keywords and easy to apply. [JB] Surely this is precisely what attributes were designed for? If we decorate a module declaration with a suitable attribute, any tool that knows how to do so could then perform the checks indicated by the attribute. Those checks are then localised to the decorated module, and could even be overridden on individual nodes: (* REPORT_UNDRIVEN=1 *) module foo (input logic a, ...); // by default, all nodes of this module are checked for being driven (* REPORT_UNLOADED=1 *) logic [7:0] some_rtl_signal; // some_rtl_signal is checked for both driven and received (* REPORT_UNDRIVEN=0 *) wire might_be_floating; // might_be_floating is not checked at all This is possible, but I think the declarations using attributes this way could be extremely verbose and discouraging. I also think there are other problems with attributes the way they are currently defined in the standard that has discouraged their use altogether (arrrrgh!) Has anyone else wished for a $allsigs system function that would return all the nets within the current scope as a concatenated vector that could then be used for $isunknown testing during early simulation and disabled after 10-100 clock cycles? Of course, then I would want a way to do $allsigs(-{exception1, excep2,excep3,...,excepn}). Remember, finding nets with missing connections can be extremely useful, much more useful than just checking for net declarations and what I am proposing is used as an option-only. I think we can find many more bugs easily if we had this capability. Regards - Cliff ---------------------------------------------------- Cliff Cummings - Sunburst Design, Inc. 14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005 Phone: 503-641-8446 / FAX: 503-641-8486 cliffc@sunburst-design.com / www.sunburst-design.com Expert Verilog, SystemVerilog, Synthesis and Verification Training -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Sun Jul 8 20:57:07 2007
This archive was generated by hypermail 2.1.8 : Sun Jul 08 2007 - 20:57:25 PDT