Jim Foley, Director of R&D, Real Intent
Jim Foley, prior to his role as R&D Director at Real Intent, was Head for Power Analysis Products at Sequence Design, and has held product management and development roles at Cadence Design Systems. Jim received a BS in Electrical Engineering from Worcester Polytechnic Institute. Go Engineers!
Ascent Lint Rule of the Month: OPEN_INPUT
December 4th, 2012 by Jim Foley, Director of R&D, Real Intent
This is the second in our series on lint rules, where we discuss various coding issues and how to improve the quality of RTL designs. The lint rule for this month is OPEN_INPUT.
How many different ways can you express nothing? And do you mean the same thing each time?
It’s not as if Ascent Lint has a rule that will look for nothing and point out to you where nothing is discovered. There is a whole category of rules for this! Over 30 rules in the Omission category will point out nothing in various situations with the general expectation that there should be a coding element, but it is missing.
Not all nothings are necessarily the same, however. Consider these three module instantiations:
funcBlock inst1 (.aa(xx), .cc(zz));
funcBlock inst2 (.aa(xx), .yy(), .cc(zz));
funcBlock inst3 (xx, , zz);
Each of these instantiations connects part of arrays xx and zz to ports aa and cc respectively, and leaves input port yy connected to nothing. Any Verilog simulator will do the same thing with each of these, assigning the unconnected yy with the value ‘z. So Lint can just point out the three open port connections and call it a day, right? Well, let’s stop a moment and consider our options. Consider the two port lists for inst1 and inst2. In inst1, port yy is not there at all. Maybe somebody forgot about it! For inst2, the code says “here is port yy and it is specifically connected to nothing.” It’s not a case of anyone having forgotten anything. It may or may not be correct, but at least it’s intentional. On inst3, the positional port list requires that there must be something there for each port, even if that something is nothing, separated by commas. You could choose to think of this as being similar to inst2, where the connection to nothing to port yy is explicit. Is the nothing in the right place in the port list? Did somebody just hit the ‘,’ key by mistake, but manage to get the number of port connections right anyway? It’s less clear in this case. You could avoid the ambiguity with POS_PORT_LIST, but I will tell you about this rule at a future time.
Another thing to consider is that we don’t know what’s happening inside the module. What if, inside funcBlock, input yy is itself not connected to anything? Well, in that case, the most appropriate thing to connect yy to might very well be nothing. There’s no sense in coding logic to drive an input that the module won’t do anything with. With the extra unused input port, you can plan for future expansion when yy will enable funcBlock to provide new functionality, and Ascent Lint can gracefully ignore the missing driver where there’s nothing to receive it.
In summary, there are situations where nothing may be okay, and situations where nothing is explicitly intended, and can be distinguished from something that is just missing. The point is that Ascent Lint gives you options to report about each of these conditions – or not – as your design flow, methodology, and best judgement require.
So the OPEN_INPUT rule is not so trivial after all. Okay, it’s not 3D parasitic extraction, but Ascent Lint gives you the options to see the violations you care about, and not bother you for the ones you don’t, and that’s something!