Handling unconnected signals

[Andreas Ehliar]

When I'm creating an RTL design I usually end up with quite a few
unconnected signals. As an example, in a processor I'm working on I
have put all control signals for a certain pipeline stage in one
large vector, something like this:


`define ALU_CTRL [2:0]
`define MAC_CTRL [5:3]
`define OTHER_STUFF [9:6]
`define YET_MORE_OTHER_STUFF [29:10]

// This define trick is quite ugly and it would be nicer to use
// SystemVerilog's interfaces here, but I would probably have
// the same problems.

And in the ALU module I can do something like:

case(pipeline_ctrl_execute`ALU_CTRL)
3'b000: result <= a + b;
3'b001: result <= a - b;
... and so on


The advantage is that the top level module is quite simple as I don't
have hundreds of control signals for the various modules all over the
place. The disadvantage is that I get hundreds of synthesis warnings
about unused signals. For example, when synthesizing the ALU I get
warned that pipeline_ctrl_execute[29:3] are unconnected. (With XST as
a synthesis tool I get one line for every signal that is unconnected
which is fairly annoying...)


So, a question for the group: How do you handle unconnected/unused
signals in a module?

Do you:
* Make sure that they never occur by painfully making sure that all
inputs are always used in some way in all modules?
* Ignore the problem and all warnings about unconnected signals in the
logfile?
* Add all "approved" unconnected signals to a logfile filter?
* Use verilog-mode's /*AUTOUNUSED*/? Doesn't work for partial signals(?)
* Something else?

/Andreas

 

[Rajkumar]

On Mar 18, 4:21 am, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote:

When I'm creating an RTL design I usually end up with quite a few
unconnected signals. As an example, in a processor I'm working on I
have put all control signals for a certain pipeline stage in one
large vector, something like this:

`define ALU_CTRL [2:0]
`define MAC_CTRL [5:3]
`define OTHER_STUFF [9:6]
`define YET_MORE_OTHER_STUFF [29:10]

// This define trick is quite ugly and it would be nicer to use
// SystemVerilog's interfaces here, but I would probably have
// the same problems.

And in the ALU module I can do something like:

   case(pipeline_ctrl_execute`ALU_CTRL)
       3'b000: result <= a + b;
       3'b001: result <= a - b;
       ... and so on

The advantage is that the top level module is quite simple as I don't
have hundreds of control signals for the various modules all over the
place. The disadvantage is that I get hundreds of synthesis warnings
about unused signals. For example, when synthesizing the ALU I get
warned that pipeline_ctrl_execute[29:3] are unconnected. (With XST as
a synthesis tool I get one line for every signal that is unconnected
which is fairly annoying...)

So, a question for the group: How do you handle unconnected/unused
signals in a module?

Do you:
* Make sure that they never occur by painfully making sure that all
  inputs are always used in some way in all modules?
* Ignore the problem and all warnings about unconnected signals in the
  logfile?
* Add all "approved" unconnected signals to a logfile filter?
* Use verilog-mode's /*AUTOUNUSED*/? Doesn't work for partial signals(?)
* Something else?

/Andreas

Hi,
I hope i understand your problem correctly. Here is my take
Why do you need to define the complete bus at ALU input, you can
surely get away defining the bus
at the ALU input as bus_ip[`ALU_CTRL-1:0], and connect the appropriate
bits to its instance at the top level,
You still have the bus at the top level, and you only declare/define
the appropriate bus at the lower level
modules

Rajkumar...

 

[Andreas Ehliar]

On 2009-03-24, Rajkumar <shubamshreyas@gmail.com> wrote:

I hope i understand your problem correctly. Here is my take
Why do you need to define the complete bus at ALU input, you can
surely get away defining the bus
at the ALU input as bus_ip[`ALU_CTRL-1:0], and connect the appropriate
bits to its instance at the top level,
You still have the bus at the top level, and you only declare/define
the appropriate bus at the lower level
modules

It sounds like you understand my problem correctly. In this case the
problem is that the indices into the control signal will not be the
same in the submodule as in the top level module. Although it could
perhaps be handled like this:

// In some header file
`define ALU_CTRL [2:0]
`define MAC_CTRL [5:3]

// In the top module
mac mac_inst(.opa(opa),.opb(opb),.ctrl(ctrl`MAC_CTRL),...);



And in the mac submodule I would handle it like:
module mac(
input wire [11:0] opa,opb,
input wire `MAC_CTRL ctrl,
// more I/Os...
);

...
always @* begin
case(ctrl`MAC_CTRL)


Although this would be a little more cumbersome for the case when I have
more than one control signals to a module. Also, I will not be able to use
verilog-mode's /*AUTOINST*/ for the ctrl signal any longer on the top level.


Anyway, as you say, this may be the best solution anyway, although I was
hoping for some better "trick".

/Andreas