Detect registers which are not reset

Question

When writing Verilog, I use a variety of "linters" that will give errors and warnings. These are my simulator (ModelSim), my compiler (Quartus II), along with a linter (Verilator). Together, I have good coverage for common pitfalls, such as bus size mismatches and inferred latches.

Unfortunately, none of the three tools detects registers which are not being reset. To see what I mean, consider the following.

reg a;
reg b;

always @(posedge clk_i or posedge rst_i) begin
  if(rst_i) begin
    a <= 1'b0; // Reset a
    // Ooops, forgot to reset b
  end else begin
    // Do stuff with a and b
  end
end

How can I have my tools automatically detect registers which are not being reset?

Answer 1

None of the tools you mentioned is a real linting tool. These tools are not supposed to give you a good linting coverage.

I saw two commercial linting tools and both had rules for detecting non-reset flops.

I see three options:

1. If the answer by David Kessner works for you - way to go.
2. Get a decent linting tool which will do the job.
3. Write a script which will detect non-reset flops.

Now, #2 may be not that simple. I don't know whether there are good free linters out there, and the professional ones are expensive and will take you a lot of time to setup.

#3 is the approach I would use. If you know any scripting language (Perl, Python, ...) it will take you one day at most to write a script which searches for non-reset flops. If you do not know any scripting language, there is StackOverflow where you can ask for a help - few days and you're done. This will also add another tool into your personal toolbox which is very valued among front-end designers - writing text processing scripts.

Good luck!

Answer 2

When I run Modelsim on my VHDL designs, it gives me warnings at Time=0ps about logic with 'X' or 'U' type input signals. I forget the exact warning message. Going through these warnings can tell me what I do not have initialized.

Answer 3

I rely on functional tests rather than linting tools for this, I tend to toggle reset and re-play parts of the test bench. If the device works correctly after reset, then you've either reset the state space sufficiently, or your test bench is no good!

Answer 4

Sometimes the design tools will output a series of reports that provide you with all sorts of interesting info. For example, Xilinx might call this a Map Report, which tells you what logical components were mapped to what physical components.

In the example above, reg a would be mapped to an FDCE (Flip flop, D, with asynchronous Clear, and clock Enable), while reg b would be mapped to an FDE (Flip flop, D, and clock Enable). This would tell you that reg b has no reset.