DISABLE IMPLICIT DECLARATION OF WIRES in Verilog

As you might know, since verilog 2001, wires are implicitly declared in verilog.That means you can start using a net in verilog and assume as if you declared it as a single bit wire. The important thing to notice here is that as long as you use it as a single bit wire, you are safe.
If verilog was "C" , i would have appreciated this feature or called it as an "enhancement".

But it is not. Verilog is meant to write RTLs. While writing RTL, the more you are forced to be specific ,the lesser error prone you are making the environment.

Let me give you an example ,how it can screw you.

wire psel;

abc u_abc(
.PSEL(pselx),
...
)

xyz u_xyz(
.PSEL_SOC(psel),
...
)

SEE!!!

Lets say you meant to connect PSEL of module abc with PSEL_SOC of module xyz through a wire psel.
Now instead of connecting the PSEL of module abc with previously declared wire psel, you connected it with pselx (because you were using gvim and x is frequently used to delete items :)

Now since pselx is not a declared wire, you would have preferred verilog throwing an error but it declared pselx as an implicit declaration of the wire and carried on.
Result: Your connection remains floating, a BUG is born.

I have encountered this scenario today. and i thought there must be some way to disable this "feature" either in the compiler or in the language and this is what i found.

There is a compiler directive as

`default_nettype none

When used in a verilog file, will stop defining any undeclared net implicitly.

NICE.

Line Debugging in Simulation

There was time when during my functional simulation, the simulator hangs at one point and does't advance. I have seen times during simulations when the time advances but nothing comes up or changes in the waveform. That happens because your design (or processor in my case) is stuck at some point like a WFI or bus-hang kind of situations but this was different. This was the time when the time in the simulation didn't advance at all.This was something new for me. I didnt know how to debug the situation or to know what part of verilog code was causing the issue.After spending some time with the issue, i came across the term "line debugging". I had heard the term with respect to C/C++ where GDB serves the same purpose just didnt know it existed for verilog simulation too. So here is how it is done for ncsim simulation(i am sure similar options exists for all other simulators):


1.Compile your code with -LINEDEBUG option in both ncverilg and ncvhdl command lines.
2.Then when the simulator hangs,hit CTRL-C on the console window
3.Type "run -step" on console and open source browser.
4.Continue running "run -step " . You see a yellow line moves on the source code indicating what part of RTL is being executed.
5.Continue running until you figure out you have been here before :-)

This way you can easily find the piece of code which may cause a loop back. In my case that piece of code looked something like this:

always @* begin
a <= a|b;
end

With the presence of * for sensitivity list, both a and b comes under it. so whenever there is an event on a or b, the block gets executed which might cause a change in a again. This is a combinational loop in the design and is forbidden.

-linedebug option i found out later causes to slow down the simulation time a lot and hence should not be used unless you are line debugging.


Happy debugging!!!