How to define reg ports?

[Chris Carlen]

Hi:

Which is the more common/better/more accepted way of making these
register port definitions, or doesn't it matter?:


module CB8CE(Q, TC, CEO, C, CLR, CE);
output reg [7:0] Q;
output reg TC, CEO;
input C, CLR, CE;

// stuff edited

endmodule


OR...

module CB8CE(Q, TC, CEO, C, CLR, CE);
output Q, TC, CEO;
input C, CLR, CE;

reg [7:0] Q;
reg TC, CEO;

// stuff edited

endmodule


Thanks for input.

Good day!


--
____________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarle@sandia.gov

 

[Allan Herriman]

On Wed, 25 Feb 2004 10:54:15 -0800, Chris Carlen
<crcarle@BOGUS.sandia.gov> wrote:

Hi:

Which is the more common/better/more accepted way of making these
register port definitions, or doesn't it matter?:


module CB8CE(Q, TC, CEO, C, CLR, CE);
output reg [7:0] Q;
output reg TC, CEO;
input C, CLR, CE;

// stuff edited

endmodule


OR...

module CB8CE(Q, TC, CEO, C, CLR, CE);
output Q, TC, CEO;
input C, CLR, CE;

reg [7:0] Q;
reg TC, CEO;

// stuff edited

endmodule

I use something else again:

module CB8CE (
output reg [7:0] Q,
output reg TC,
output reg CEO,
input wire C,
input wire CLR,
input wire CE
);

// stuff edited

endmodule

I don't know why you would want to list all of your ports more than
once (except maybe if your tool had bugs and couldn't compile this
perfectly legal Verilog).

Regards,
Allan.

 

[Chris Carlen]

Allan Herriman wrote:

On Wed, 25 Feb 2004 10:54:15 -0800, Chris Carlen
crcarle@BOGUS.sandia.gov> wrote:


Hi:

Which is the more common/better/more accepted way of making these
register port definitions, or doesn't it matter?:


module CB8CE(Q, TC, CEO, C, CLR, CE);
output reg [7:0] Q;
output reg TC, CEO;
input C, CLR, CE;

// stuff edited

endmodule


OR...

module CB8CE(Q, TC, CEO, C, CLR, CE);
output Q, TC, CEO;
input C, CLR, CE;

reg [7:0] Q;
reg TC, CEO;

// stuff edited

endmodule


I use something else again:

module CB8CE (
output reg [7:0] Q,
output reg TC,
output reg CEO,
input wire C,
input wire CLR,
input wire CE
);

// stuff edited

endmodule

I don't know why you would want to list all of your ports more than
once (except maybe if your tool had bugs and couldn't compile this
perfectly legal Verilog).

Regards,
Allan.

Wow, that's not something I expected could be done. I am used to C, in
which there are fairly fixed ways of defining things. Verilog seems
quite wiggly.

Thanks for the input!

--
____________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarle@sandia.gov

 

[Steven Sharp]

Chris Carlen <crcarle@BOGUS.sandia.gov> wrote in message news:<c1ir0n02c9j@enews2.newsguy.com>...

Which is the more common/better/more accepted way of making these
register port definitions, or doesn't it matter?:

It matters. It matters what your tools support and how portable you
want your code to be between tools.

Q;

This syntax is legal in Verilog-2001. It is not legal in Verilog-1995,
and may not be supported in all tools.

output Q, TC, CEO;
reg [7:0] Q;

This syntax is not legal in any standard. If the port is a vector,
then the vector range must appear on the port declaration as well
as the reg declaration, and both ranges must match. The correct
declaration would be

output [7:0] Q;
reg [7:0] Q;

The verboseness of this explains why Verilog-2001 added the more
compact combined port and net/reg declaration syntax. Many tools
are sloppy about enforcing the requirement for matching ranges,
so the illegal syntax may still work in those tools. It isn't a
good idea to rely on this.

Note that your examples are also sloppy in specifying the reg
ports explicitly, but letting the other ports default to being
nets. They really should be explicitly declared as nets. But
this default rule is actually part of the standard (explicitly
in the 2001 standard, and de facto in the 1995 language), and
it is common practice to take advantage of it for brevity. One
consequence of this practice is that if the `default_nettype
directive is used to change the net type of implicit nets to
something other than wire, these ports will change net type
also.

An even more compact port declaration syntax was added in
Verilog-2001, generally called "ANSI-C style" declarations.
These include the port and net/reg declarations in the port
list itself. This saves typing the port names an extra time.
However, it may not always be easier to read. It also doesn't
allow doing some of the more obscure things that can be done
with old-style port declarations.

 

[ABW]

"Steven Sharp" <sharp@cadence.com> wrote in message
news:3a8e124e.0402261146.7958eae@posting.google.com...
(cut)

Note that your examples are also sloppy in specifying the reg
ports explicitly, but letting the other ports default to being
nets. They really should be explicitly declared as nets. But
this default rule is actually part of the standard (explicitly
in the 2001 standard, and de facto in the 1995 language), and
it is common practice to take advantage of it for brevity. One
consequence of this practice is that if the `default_nettype
directive is used to change the net type of implicit nets to
something other than wire, these ports will change net type
also.

Then LRM 2001 deviates from de facto standard )

`default_nettype wor
module test(o);
output o;
assign o = 1'b1;
assign o = 1'b0;
endmodule

VXL and other simulators give 1 on output, which proves that 'o' became wor.
However 'o' falls under first rule from chapter 3.5 (which says it shall be
assumed wire) and does not fall under second rule (which says about
situations when `default_nettype is in control).

 

[ABW]

Oh, I see this issue was already discussed by BTF
(http://www.boyd.com/1364_btf/report/full_pr/79.html).

"ABW" <mhvalley@poczta.onet.pl> wrote in message
news:c1nfi0$p2u$1@nemesis.news.tpi.pl...

"Steven Sharp" <sharp@cadence.com> wrote in message
news:3a8e124e.0402261146.7958eae@posting.google.com...
(cut)
Note that your examples are also sloppy in specifying the reg
ports explicitly, but letting the other ports default to being
nets. They really should be explicitly declared as nets. But
this default rule is actually part of the standard (explicitly
in the 2001 standard, and de facto in the 1995 language), and
it is common practice to take advantage of it for brevity. One
consequence of this practice is that if the `default_nettype
directive is used to change the net type of implicit nets to
something other than wire, these ports will change net type
also.

Then LRM 2001 deviates from de facto standard )

`default_nettype wor
module test(o);
output o;
assign o = 1'b1;
assign o = 1'b0;
endmodule

VXL and other simulators give 1 on output, which proves that 'o' became
wor.
However 'o' falls under first rule from chapter 3.5 (which says it shall
be
assumed wire) and does not fall under second rule (which says about
situations when `default_nettype is in control).

 

[Steven Sharp]

"ABW" <mhvalley@poczta.onet.pl> wrote in message news:<c1nha7$2ng$1@nemesis.news.tpi.pl>...

Oh, I see this issue was already discussed by BTF
(http://www.boyd.com/1364_btf/report/full_pr/79.html).

This particular error in the standard was actually fixed before
balloting, but the IEEE mistakenly printed an earlier draft of
the standard.

 

[Steven Sharp]

Chris Carlen <crcarle@BOGUS.sandia.gov> wrote in message news:<c1l3d502eec@enews1.newsguy.com>...

Wow, that's not something I expected could be done. I am used to C, in
which there are fairly fixed ways of defining things. Verilog seems
quite wiggly.

C is a poor example for your point. The variations in legal Verilog
syntax are largely due to variations in C syntax.

C started with K&R style function declarations, with the argument
names declared in parentheses and their full declarations appearing
afterward. The original Verilog syntax was probably based partly
on this. The separate port and net/reg declarations don't have an
analog in C, because C doesn't declare argument directions (they
are all inputs, passed by value).

Then ANSI-C added a new syntax for function declarations, with the
full argument declarations appearing in the parentheses. Verilog-2001
followed suit by allowing a new syntax for module declarations, with
the full port declarations appearing in the port list (which are often
called "ANSI-C style" port declarations as a result). This required
combining the port and net/reg declarations into one. This may have
prompted allowing combined port and net/reg declarations in the old
position as well (or this might have been suggested independently,
I don't know).

So the wiggly nature of Verilog port declarations is largely caused
by the wiggly nature of C declarations.

 

[Chris Carlen]

Steven Sharp wrote:

Chris Carlen <crcarle@BOGUS.sandia.gov> wrote in message news:<c1l3d502eec@enews1.newsguy.com>...

Wow, that's not something I expected could be done. I am used to C, in
which there are fairly fixed ways of defining things. Verilog seems
quite wiggly.


C is a poor example for your point. The variations in legal Verilog
syntax are largely due to variations in C syntax.

C started with K&R style function declarations, with the argument
names declared in parentheses and their full declarations appearing
afterward. The original Verilog syntax was probably based partly
on this. The separate port and net/reg declarations don't have an
analog in C, because C doesn't declare argument directions (they
are all inputs, passed by value).

Then ANSI-C added a new syntax for function declarations, with the
full argument declarations appearing in the parentheses. Verilog-2001
followed suit by allowing a new syntax for module declarations, with
the full port declarations appearing in the port list (which are often
called "ANSI-C style" port declarations as a result). This required
combining the port and net/reg declarations into one. This may have
prompted allowing combined port and net/reg declarations in the old
position as well (or this might have been suggested independently,
I don't know).

So the wiggly nature of Verilog port declarations is largely caused
by the wiggly nature of C declarations.

Hmm. I suppose you are correct. I forgot about those old style C
declarations.

Thanks for the input.

Good day!



--
____________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarle@sandia.gov

 

[Chris Carlen]

Steven Sharp wrote:

Chris Carlen <crcarle@BOGUS.sandia.gov> wrote in message news:<c1ir0n02c9j@enews2.newsguy.com>...

Which is the more common/better/more accepted way of making these
register port definitions, or doesn't it matter?:


It matters. It matters what your tools support and how portable you
want your code to be between tools.


output reg [7:0] Q;


This syntax is legal in Verilog-2001. It is not legal in Verilog-1995,
and may not be supported in all tools.



output Q, TC, CEO;
reg [7:0] Q;


This syntax is not legal in any standard. If the port is a vector,
then the vector range must appear on the port declaration as well
as the reg declaration, and both ranges must match. The correct
declaration would be

output [7:0] Q;
reg [7:0] Q;

The verboseness of this explains why Verilog-2001 added the more
compact combined port and net/reg declaration syntax. Many tools
are sloppy about enforcing the requirement for matching ranges,
so the illegal syntax may still work in those tools. It isn't a
good idea to rely on this.

Indeed, it is sloppy. Not something I would want to make a habit of,
but just curious about why it was accepted. So I can blame the tool.

Note that your examples are also sloppy in specifying the reg
ports explicitly, but letting the other ports default to being
nets. They really should be explicitly declared as nets. But
this default rule is actually part of the standard (explicitly
in the 2001 standard, and de facto in the 1995 language), and
it is common practice to take advantage of it for brevity. One
consequence of this practice is that if the `default_nettype
directive is used to change the net type of implicit nets to
something other than wire, these ports will change net type
also.

Good point. I will always define them. I'll just have to decide
whether to do it the 1995 or 2001 way.



Thanks for the reply.

Good day!

--
____________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarle@sandia.gov