Synthesis warning...

K

kb33

Guest
Hi,

I prefer to separate out my sequential and combinational code. At the
beginning of the module, I usually have a single always block in which
the combinational values are assigned to the sequential values at the
clock edge. For example:

always @(negedge sys_clk)
begin

byte_counter <= #1 byte_counter_comb;

IP_protocol_n <= #1 IP_protocol_n_comb;
IP_src_addr_n <= #1 IP_src_addr_n_comb;
IP_dest_addr_n <= #1 IP_dest_addr_n_comb;

IP_protocol <= #1 IP_protocol_comb;
IP_src_addr <= #1 IP_src_addr_comb;
IP_dest_addr <= #1 IP_dest_addr_comb;

end

However, when I am trying to synthesize my code using Synplicity, I am
getting the following error for each bit of the above assigned signals:


"pkt_incom.v":134:3:134:8|Removing sequential instance
pkt_incom_top.IP_dest_addr[31] of view:primLib.dff(prim) because there
are no references to its outputs

The above code is in the file named pkt_incom.v, and this module is
instantiated in a top level module named as pkt_incom_top.v .
Mind you, the above assignments in pkt_incom.v (which are also the
outputs of this module) are being used in other peer modules. That is
why I am not able to understand the warning.

Thanks,
Kanchan
 
When the output pin is not used the tool removes the flip flop :
so double check that IP_dest_addr[31] signal is read at least once in
your design if not this bit is useless ! (and must be deleted)


kb33 wrote:
Hi,

I prefer to separate out my sequential and combinational code. At the
beginning of the module, I usually have a single always block in which
the combinational values are assigned to the sequential values at the
clock edge. For example:

always @(negedge sys_clk)
begin

byte_counter <= #1 byte_counter_comb;

IP_protocol_n <= #1 IP_protocol_n_comb;
IP_src_addr_n <= #1 IP_src_addr_n_comb;
IP_dest_addr_n <= #1 IP_dest_addr_n_comb;

IP_protocol <= #1 IP_protocol_comb;
IP_src_addr <= #1 IP_src_addr_comb;
IP_dest_addr <= #1 IP_dest_addr_comb;

end

However, when I am trying to synthesize my code using Synplicity, I am
getting the following error for each bit of the above assigned signals:


"pkt_incom.v":134:3:134:8|Removing sequential instance
pkt_incom_top.IP_dest_addr[31] of view:primLib.dff(prim) because there
are no references to its outputs

The above code is in the file named pkt_incom.v, and this module is
instantiated in a top level module named as pkt_incom_top.v .
Mind you, the above assignments in pkt_incom.v (which are also the
outputs of this module) are being used in other peer modules. That is
why I am not able to understand the warning.

Thanks,
Kanchan
 
As I mentioned in my posting, there are no outputs from my module that
are NOT being used in other modules. But I am still getting this
warning.

Thanks,
Kanchan
 
oups, sorry,
could you please provide the RTL code when the register
is fully read from the other block it will help a lot ...



kb33 a écrit :

As I mentioned in my posting, there are no outputs from my module that
are NOT being used in other modules. But I am still getting this
warning.

Thanks,
Kanchan
 
Thanks for taking an active interest in my problem. I am providing the
code from two files: the first file is named as pkt_incom.v, and the
second file is the top level structural instatiation module. Please let
me know if you need to see more code. As you can see, some of the other
modules instantiated in the top level are utilising the outputs of
pkt_incom.v . Strangely, I am not getting this warning for any of the
other modules.

Kanchan

Code from pkt_incom.v :

//Module declaration
module pkt_incom (sys_clk, //The system clock
reset_n, //The active low reset
pkt_in, //8-bit bus for pkts
pkt_enab_n, //pkt is being Xmitted
IP_protocol_n, //IP protocol available
IP_protocol, //type of pkt carried
IP_src_addr_n, //IP src addr available
IP_src_addr, //IP Source address
IP_dest_addr_n,//IP dest addr avail
IP_dest_addr, //IP dest. address
UDP_src_port_n,//UDP Src. Port avail
UDP_src_port, //UDP Source port
UDP_dest_port_n, //UDP Dest port avail
UDP_dest_port, //UDP Destination port
RTP_Seq_Num_n, //RTP_Seq_Num available
RTP_Seq_Num, //RTP Sequence
No.
RTP_timestmp_n,//RTP Timestamp avail
RTP_timestmp, //RTP Timestamp (Delay)
RTP_SSRC_n, //RTP Sync Src avail
RTP_SSRC //RTP Synch Source );

//Input - Output declaration

input sys_clk,
reset_n,
pkt_enab_n;

input [7:0] pkt_in;

output IP_protocol_n,
IP_src_addr_n,
IP_dest_addr_n,
UDP_src_port_n,
UDP_dest_port_n,
RTP_Seq_Num_n,
RTP_timestmp_n,
RTP_SSRC_n;

output [7:0] IP_protocol;

output [31:0] IP_src_addr,
IP_dest_addr,
RTP_timestmp,
RTP_SSRC;

output [15:0] UDP_src_port,
UDP_dest_port,
RTP_Seq_Num;


//Register Declarations..

reg IP_protocol_n,
IP_protocol_n_comb, //Combinatorial logic
IP_src_addr_n,
IP_src_addr_n_comb, //Combinatorial logic
IP_dest_addr_n,
IP_dest_addr_n_comb, //Combinatorial logic
UDP_src_port_n,
UDP_src_port_n_comb,
UDP_dest_port_n,
UDP_dest_port_n_comb,
RTP_Seq_Num_n,
RTP_Seq_Num_n_comb,
RTP_timestmp_n,
RTP_timestmp_n_comb,
RTP_SSRC_n,
RTP_SSRC_n_comb;

reg [7:0] byte_counter; //COunter - incoming pkt bytes
reg [7:0] byte_counter_comb; //Combinatorial logic
reg [7:0] IP_protocol; //Transport pkt (UDP = 17)
reg [7:0] IP_protocol_comb; //Combinational Logic

reg [15:0] UDP_src_port,
UDP_src_port_comb,
UDP_dest_port,
UDP_dest_port_comb,
RTP_Seq_Num,
RTP_Seq_Num_comb;


reg [31:0] IP_src_addr,
IP_src_addr_comb,
IP_dest_addr,
IP_dest_addr_comb,
RTP_timestmp_comb,
RTP_SSRC,
RTP_SSRC_comb;

//Flip-flop Generation...

always @(negedge sys_clk)
begin

byte_counter <= #1 byte_counter_comb;

IP_protocol_n <= #1 IP_protocol_n_comb;
IP_src_addr_n <= #1 IP_src_addr_n_comb;
IP_dest_addr_n <= #1 IP_dest_addr_n_comb;
UDP_src_port_n <= #1 UDP_src_port_n_comb;
UDP_dest_port_n <= #1 UDP_dest_port_n_comb;
RTP_Seq_Num_n <= #1 RTP_Seq_Num_n_comb;
RTP_timestmp_n <= RTP_timestmp_n_comb;
RTP_SSRC_n <= #1 RTP_SSRC_n_comb;

IP_protocol <= #1 IP_protocol_comb;
IP_src_addr <= #1 IP_src_addr_comb;
IP_dest_addr <= #1 IP_dest_addr_comb;
UDP_src_port <= #1 UDP_src_port_comb;
UDP_dest_port <= #1 UDP_dest_port_comb;
RTP_Seq_Num <= #1 RTP_Seq_Num_comb;
RTP_timestmp <= RTP_timestmp_comb;
RTP_SSRC <= #1 RTP_SSRC_comb;

end


Code from pkt_loss_top.v :


//Module declaration
`include "define.v"

module pkt_loss_top (sys_clk,
reset_n,
pkt_enab_n,
pkt_in,
RTP_flow_inq_id, //Flow under inquiry
RTP_flow_inq_id_n, //RTP_flow_inq_id active
Pkt_lost, //NUmber of packets lost
Pkt_lost_n, //Pkt lost signal avail
inq_error_n );

//Input - Output declaration

input sys_clk,
reset_n,
pkt_enab_n,
RTP_flow_inq_id_n;

input [7:0] pkt_in;

input [`RTPFLOW_MSB:0] RTP_flow_inq_id;


output Pkt_lost_n,
inq_error_n;

output [`PKT_LOST_MSB:0] Pkt_lost;


//Wire Declerations..

wire IP_protocol_n,
IP_src_addr_n,
IP_dest_addr_n,
UDP_src_port_n,
UDP_dest_port_n,
RTP_Seq_Num_n,
RTP_timestmp_n,
RTP_SSRC_n,
RTP_pkt_n,
RTP_flow_id_n,
flow_buf_full_n,
Pkt_lost_n,
inq_error_n;
wire [`PKT_LOST_MSB:0] Pkt_lost;

wire [`RTPFLOW_MSB:0] RTP_flow_id;

wire [7:0] IP_protocol;

wire [31:0] IP_src_addr,
IP_dest_addr,
RTP_timestmp,
RTP_SSRC;

wire [15:0] UDP_src_port,
UDP_dest_port,
RTP_Seq_Num;


pkt_incom pkt_incom_top (sys_clk, //The system clock
reset_n, //The active low reset
pkt_in, //8-bit bus for pkts
pkt_enab_n, //pkt is being Xmitted
IP_protocol_n, //IP protocol available
IP_protocol, //type of pkt carried
IP_src_addr_n, //IP src addr available
IP_src_addr, //IP Source address
IP_dest_addr_n,//IP dest addr avail
IP_dest_addr, //IP dest. address
UDP_src_port_n,//UDP Src. Port avail
UDP_src_port, //UDP Source port
UDP_dest_port_n, //UDP Dest port avail
UDP_dest_port, //UDP Destination port
RTP_Seq_Num_n, //RTP_Seq_Num available
RTP_Seq_Num, //RTP Sequence No.
RTP_timestmp_n,//RTP Timestamp avail
RTP_timestmp, //RTP Timestamp (Delay)
RTP_SSRC_n, //RTP Sync Src avail
RTP_SSRC //RTP Synch Source );



RTP_checker RTP_checker_top (sys_clk, //The system clock
reset_n, //The active low reset
pkt_enab_n, //pkt is being Xmitted
IP_protocol_n, //IP protocol avail
IP_protocol, //packet being carried
UDP_dest_port_n,//UDP Dest port avail.
UDP_dest_port, //UDP Dest. port
RTP_pkt_n //RTP pkt present
);

RTP_flow_gen RTP_flow_gen_top (sys_clk, //The system
clock
reset_n, //The active low reset
pkt_enab_n, //pkt is being Xmitted
IP_src_addr, //IP Source address
UDP_src_port, //UDP Source port
RTP_SSRC_n, //RTP Synch Src avail
RTP_SSRC, //RTP Synch Src
RTP_pkt_n, //RTP pkt present
RTP_flow_id, //RTP flow id number
RTP_flow_id_n, //RTP Flow id available
flow_buf_full_n //Buffer Full
);

RTP_Seq RTP_Seq_top (sys_clk, //The system clock
reset_n, //The active low reset
pkt_enab_n, //pkt is being Xmitted
RTP_flow_id, //RTP flow id number
RTP_flow_id_n, //RTP Flow id available
RTP_Seq_Num_n, //RTP_Seq_Num avail RTP_Seq_Num, //RTP
Sequence No.
RTP_flow_inq_id,//Flow being inquired
RTP_flow_inq_id_n, //RTP_flow_inq
Pkt_lost, //packets lost
Pkt_lost_n, //Pkts lost signal avail
inq_error_n //Inq. Flow Id. invalid
);

endmodule
 
I forgot to mention - there are two signals - RTP_timestmp_n and
RTP_timestmp, which are not being used
in any module (that's because I have to write the code for the module
that will use these signals). But this warning is there for all of the
other signals as well.

Kanchan
 
could you please provide just the RTL code that
generate the combo signal IP_dest_addr_comb[31];
and where IP_dest_addr[31] is read,
there might be some kind of boundary optimization and synplify
deletes your dest_addr MSB ...

i tried to get the same warning but rigth now i did not succeed !!
see below :

@N: CG364 :"rid.v":1:7:1:9|Synthesizing module rid
@W: CL169 :"rid.v":23:0:23:5|Pruning Register q_out_notused
@W: CL138 :"rid.v":23:0:23:5|Register 'q_out_stuck' is only assigned 0
or its old value; the register will be removed
module rid(
clk,
resetn,
en,
d_in,
q_out,
q_out_stuck
);
input clk;
input resetn;
input en;
input d_in;

output q_out;
output q_out_stuck;

reg q_out_stuck;
reg q_out;
reg q_out_notused;

always @(posedge clk or negedge resetn)
if (!resetn)
begin
q_out <= 1'b0;
q_out_stuck <= 1'b0;
q_out_notused <= 1'b0;
end
else if (en) begin
q_out <= d_in;
q_out_stuck <= 1'b0;
q_out_notused <= d_in;
end


endmodule


kb33 wrote:
I forgot to mention - there are two signals - RTP_timestmp_n and
RTP_timestmp, which are not being used
in any module (that's because I have to write the code for the module
that will use these signals). But this warning is there for all of the
other signals as well.

Kanchan
 
Hi,

I am providing the code for IP_src_addr. The vector is modified in the
file named pkt_incom.v, and it is used in another file named
RTP_flow_gen.v


Code from pkt_incom.v :

always @(negedge sys_clk)

IP_src_addr <= #1 IP_src_addr_comb;


//IP_src_addr_comb signal.....

always @(reset_n or pkt_enab_n or byte_counter or pkt_in or
IP_src_addr)
begin

if(~reset_n)
IP_src_addr_comb <= 0;

else
if(~pkt_enab_n)

casex (byte_counter)

34:
begin
IP_src_addr_comb[31:24] <= pkt_in;
IP_src_addr_comb[23:16] <= IP_src_addr[23:16];
IP_src_addr_comb[15:8] <= IP_src_addr[15:8];
IP_src_addr_comb[7:0] <= IP_src_addr[7:0];
end


35:
begin
IP_src_addr_comb[31:24] <= IP_src_addr[31:24];
IP_src_addr_comb[23:16] <= pkt_in;
IP_src_addr_comb[15:8] <= IP_src_addr[15:8];
IP_src_addr_comb[7:0] <= IP_src_addr[7:0];
end


36:
begin
IP_src_addr_comb[31:24] <= IP_src_addr[31:24];
IP_src_addr_comb[23:16] <= IP_src_addr[23:16];
IP_src_addr_comb[15:8] <= pkt_in;
IP_src_addr_comb[7:0] <= IP_src_addr[7:0];
end

37:
begin
IP_src_addr_comb[31:24] <= IP_src_addr[31:24];
IP_src_addr_comb[23:16] <= IP_src_addr[23:16];
IP_src_addr_comb[15:8] <= IP_src_addr[15:8];
IP_src_addr_comb[7:0] <= pkt_in;
end

default:
IP_src_addr_comb <= IP_src_addr;

endcase

else
IP_src_addr_comb <= 0;

end


The following code is from RTP_flow_gen.v :

assign temp_reg = {IP_src_addr, UDP_src_port, RTP_SSRC};


//The temp_ reg is used as follows.......


always @(reset_n or current_state or curr_buff_size or temp_reg)
begin

if (~reset_n)

for (l=0; l < `FLOW_ARR_SZ; l=l+1)
RTP_flow_array_comb[l] <= 0;

else

casex (current_state)

`UPDATE_ARRAY:

RTP_flow_array_comb[curr_buff_size] <= temp_reg;


default:

for (l=0; l < `FLOW_ARR_SZ; l=l+1)
RTP_flow_array_comb[l] <= RTP_flow_array[l];


endcase
end


Thanks,
Kanchan
 
I may have missed something but it seems that you provided only RTL
code for source packet, and we need IP_dest_addr[31] code to analyze
the warning
of synplify. please copy past the RTL code that generated the following
warning :
"pkt_incom.v":134:3:134:8|Removing sequential instance
pkt_incom_top.IP_dest_addr[31] of view:primLib.dff(prim) because there
are no references to its outputs
maybe you solved your problem !
Correct me if i'm wrong but i don't see any reference to the previous
register IP_dest_addr[31] ??
please include `define values ... to be sure that loops are correctly
set,

Renaud
 
Hi Renaud,

Unfortunately, the problem is very much there. I am getting this "no
references to its outputs" error for all the outputs, namely:
IP_protocol, RTP_SSRC, IP_src_addr, UDP_src_port and UDP_dest_port. As
for IP_dest_addr, I realised that I had actually not used this in any
of the other modules (as you must have observed from the top level
description), and I am sorry about not checking this beforehand. But
all the other outputs are being used in other modules, and the code
that I have presented in my previous email is that of IP_src_addr. Any
suggestions?

Kanchan
 
Hi Kanchan,

i wrote small testbench for your RTL code,
everything seems ok and it synthesis well. So if you still have the
same issue
do not hesitate to send me by email your bench and the code
that raised the same problem, i will try to understand !
build a small testcase,

Renaud



kb33 wrote:
Hi Renaud,

Unfortunately, the problem is very much there. I am getting this "no
references to its outputs" error for all the outputs, namely:
IP_protocol, RTP_SSRC, IP_src_addr, UDP_src_port and UDP_dest_port. As
for IP_dest_addr, I realised that I had actually not used this in any
of the other modules (as you must have observed from the top level
description), and I am sorry about not checking this beforehand. But
all the other outputs are being used in other modules, and the code
that I have presented in my previous email is that of IP_src_addr. Any
suggestions?

Kanchan
 
Thanks Renaud. I will send you the code over the weekend. I appreciate
your help.

Kanchan
 

Welcome to EDABoard.com

Sponsor

Back
Top