[SOLVED] register removal concern during XST operation

[syedshan]

hi all

recenlty I faced the message during synthesis that

INFO:Xst:2261 - The FF/Latch <flag_ddrtx> in Unit <Inst_tr_ctrl> is equivalent to the following FF/Latch, which will be removed : <refresh_dcycle>

Although it is just INFO, not a warning, so I should find this thing after synthesis, but when I tried to find find it to connect on chipscope signals, I cannot find it, meaning the signal has been removed during synthesis. Note that this is an important signal, hence I have to change the synthesis setting such that TURN OFF 'Equivalent Register Removal' hence later I got that signal, but I am concerned why it behaves like this, since the signal 'refresh_dcycle' is an important signal...following is one usage of it (which clearly shows it must not be removed, or else whole logic will be void...right?)

if(refresh_dcycle = '1') then
cmd_cnt <= (others =>'0'); cmd_finish_reg <= '0';
elsif(refresh_dcycle = '0') then
if(tr_cmd_val = '1' and tr_last_cmd ='0') then cmd_cnt <= cmd_cnt + '1';
elsif(tr_cmd_val = '1' and tr_last_cmd ='1' and cmd_finish_reg = '0') then
cmd_cnt <= (others =>'0'); cmd_finish_reg <= '1';
end if;
....


...

if(refresh_dcycle = '1') then
fetchcmdNadd <= '1';
--command signals
cmd_finish_reg_fetched <= '0';
app_en <= '0';
addr_fifo_rd <= '0';
add_reg <= (others => '0');
cmd_reg <= (others => '0');
...
...

bests
Shan

 

[TrickyDicky]

Is it a latch or a flip flop? (is this in a clocked process?)
XST Has determined that flag_ddrtx has the same behavior as refresh_dcycle and removed it.

 

[syedshan]

Thanks for reply,

they both are flipflops, yes it is a clocked process working at rising edge.

Yes I understand it removed it, but the thing is refresh_dcycle is used to control other processes in ' if ' statement. So after removing it, will at gate level the flag_ddrtx will take its place since on the contrary, it seems XST removed refresh_dcycle and let flag_ddrtx there since I can see this signal after synthesis for chipscope trigger selection but not the refresh_dcycle.

 

[TrickyDicky]

XST just builds a load of logic and wires. It will connect anything that needs refresh_dcycle to flag_ddrtx instead. It can be annoying when this happens and you can no longer find the refresh signal for a timing constraint or similar so you sometmes have to watch for these warnings. You should also be able to apply constraints or attributes to stop XST doing the register merge.

 

[syedshan]

hello

please see in following...

I have receivedFF/latch trimming message even after 'Equivalent Register Removal' deassertion...What to do
the thing is that my signal is multiplying by 4, what ever the value, so hence it has LSB 2 bits always '0'...but the XST categorically regect to synthesize it as a logic...Hence I think this will ultimately change the design as well...please see warning (infact error) and and code below

WARNING:Xst:1293 - FF/Latch <XY_plane_1> has a constant value of 0 in block <Inst_dout_module>. This FF/Latch will be trimmed during the optimization process.
WARNING:Xst:1293 - FF/Latch <XY_plane_0> has a constant value of 0 in block <Inst_dout_module>. This FF/Latch will be trimmed during the optimization process.

signal sig_levels : integer range 0 to 1023;

process(clk)
begin
...
...
...
--rising_edge
...
if(xxx) then
 sig_levels <= siga * sigb * 4;
end if;

end process;

...
...

 

[TrickyDicky]

this sounds pretty normal. And Synthesisors are usually fairly good at keeping the same logic. I have never had one (only Quartus and Synplify mind) build logic that wasnt functionally correct.

As your design has a *4, there are bits that are always 0, so why does it need a register for them? anything connected to them will just be connected to 0. Hence why its a warning, and not an error.

 

[syedshan]

yes actually I also think so as you said...so it means that my logic wont become from lets say 1600 to 400 or 40_000 to 10_000, right...It will be compared to same thing that I want?