Verilog "output" vs "output wire"

[NiHaoMike]

When declaring I/O ports (without registers) in Verilog, some examples I have seen use "input wire" and "output wire" while others simply use "input" and "output". Is there one that's a recommended practice or does it vary depending on coding style?

[SMB784]

I'm a bit of a verilog (and HDL in general) newb, but for my own coding style I always explicitly declare ports to be either wires or registers (or whatever else they may be).

Someone can probably chime in as to what the declaration of an input or an output defaults to, but I never leave that up to the compiler, I always explicitly declare it to be wire or reg just so I know what I am doing when I go back and read my code.

[pigrew]

I believe the default in Verilog is to assign it wire type. Personally, I always explicitly declare a port as a wire or reg.

SystemVerilog has a new type called logic which is automatically selects the proper type based on its usage in your module.

It's up to your own coding style. You could decide, for example, never to have ports of reg type (a fairly reasonable thing to do) so you'd never need to write the type. For other people reading your code, it's helpful to explicitly put the type in the declaration.

[Sal Ammoniac]

Use SystemVerilog and use "logic" everywhere.

This is 2020. SystemVerilog came out fifteen years ago and replaced Verilog eleven years ago.

[asmi]

I believe the default in Verilog is to assign it wire type. Personally, I always explicitly declare a port as a wire or reg.

You can change that using `default_nettype none directive. This way synthesizer will force you to specify each wire's type explicitly.

[Bassman59]

When declaring I/O ports (without registers) in Verilog, some examples I have seen use "input wire" and "output wire" while others simply use "input" and "output". Is there one that's a recommended practice or does it vary depending on coding style?

It's because the language is stupid.

Prior to Verilog-2001, your port interfaces were just a list of inputs and outputs. If you wanted an output port to be a reg type, below the port list you had a second list of those same signals but with the type declared. Reg and integer had to be declared explicitly, otherwise the signal defaults to a type wire. Many engineers got into the habit of indicating signal type (wire or reg) for all ports, and not using the implicit type wire.

(and people say that VHDL requires a lot of verbiage.)

Verilog-2001 allowed the designer to include the port type (wire or reg or integer) in the port list, eliminating the need for the second, redundant signal list. But, because the people who write documentation are lazy, and so are the people who write examples, too much code is written in the ancient idiom.

So you should always write your port lists with the type included. Or you should switch to SystemVerilog, which solves many of the annoyances of Verilog. Or you should use VHDL and let the compiler find your bugs instead of your customer.

[Sal Ammoniac]

Or you should use VHDL and let the compiler find your bugs instead of your customer.

I hear this a lot, and yes, I'll agree that the VHDL compiler will catch a lot of things that the SystemVerilog compiler won't, but this gives the impression that any VHDL that compiles is bug free. Nothing can be farther from the truth. You can have all sorts of logical errors in your HDL that the compiler won't catch, yet will make your design not work.

[Bassman59]

Or you should use VHDL and let the compiler find your bugs instead of your customer.

I hear this a lot, and yes, I'll agree that the VHDL compiler will catch a lot of things that the SystemVerilog compiler won't, but this gives the impression that any VHDL that compiles is bug free. Nothing can be farther from the truth. You can have all sorts of logical errors in your HDL that the compiler won't catch, yet will make your design not work.

The compiler catches the stupid shit that Verilog happily accepts.

There is no substitute for simulation and verification, followed by in-system verification. For any HDL or programming language.

[asmi]

The compiler catches the stupid shit that Verilog happily accepts.

No it doesn't. I see VHDLers are back to spreading BS

[Bassman59]

The compiler catches the stupid shit that Verilog happily accepts.

No it doesn't. I see VHDLers are back to spreading BS

that worked as expected!

[NiHaoMike]

Or you should switch to SystemVerilog, which solves many of the annoyances of Verilog.

That's not supported by Xilinx ISE last time I checked, which is a bit of a shame when the cheap Spartan 6 series is plenty for a lot of hobbyist projects.

Is there a guide for writing (regular) Verilog to be as close to SystemVerilog as possible? Kind of analogous to Python 2 vs Python 3 - at one point making all the code Python 3 compatible might not be feasible, but writing Python 2 code to be Python 3 compatible where possible really speeds up the eventual porting effort.