Don't have a Xilinx account yet?

  • Choose to receive important news and product information
  • Gain access to special content
  • Personalize your web experience on Xilinx.com

Create Account

Username

Password

Forgot your password?
XClose Panel
Xilinx Home
Reply
Regular Visitor
sdaau
Posts: 37
Registered: ‎07-13-2011
0
Accepted Solution

Debugging "WARNING:Xst:1426 - The value init of the FF/Latch ... hinder the constant cleaning" (fsm)

[ Edited ]

Hi everyone

 

I'm basically trying to write a state machine, which would simply give me a pulse at the second clock tick from start; the code is included below. In essence, it does simulate (below is post-par simulation):

 

 

... however, it generates the "WARNING:Xst:1426 - The value init of the FF/Latch ... hinder the constant cleaning" - and I'm not sure how to understand, or how to handle this warning. The machine has only three states - and I'm not sure if that may be the cause of the warning.

 

First of all, by calling in ISE:

 

  • Behavioral simulation: fuse gets called on .prj file (which contains path to raw *.vhd source files); generates .exe file
  • Synthesize: xst operates on fsmContainer.prj (via fsmContainer.xst) and thus on vhd sources; generates .ngc (.ngr) binary netlist file

During the synthesis step, I get the following warnings:

Analyzing FSM  for best encoding.
Optimizing FSM  on signal  with one-hot encoding.
-------------------
 State | Encoding
-------------------
 sta   | 001
 stb   | 010
 stc   | 100
-------------------
WARNING:Xst:1426 - The value init of the FF/Latch FFd3 hinder the constant cleaning in the block FSM.
   You should achieve better results by setting this init to 0.
....
=========================================================================
*                         Low Level Synthesis                           *
=========================================================================
WARNING:Xst:1426 - The value init of the FF/Latch FSM_FFd3 hinder the constant cleaning in the block FSM_0-parent.
   You should achieve better results by setting this init to 0.

...

 

Now the question is - what is this constant, whose "cleaning" is "hindered"? Since we cannot read directly the .ngc/.ngr files which are the output of .xst, only thing we can do is check the schematic: RTL schematic ("Launching RTL Schematic Viewer for fsmContainer.ngr"):

 

 

 ... and Technology schematic ("Launching Technology Schematic Viewer for fsmContainer.ngc"):

 

 

Interestingly, FFd3 exists only in RTL schematic (not in technology) - however, to see where this "init" comes from, we need to first convert the synthesis netlists back into (V)HDL. For that, the program "netgen" is used, which is called before any simulation step (other than behavioral) - and also, when you click:

 

  • "Generate Post-Synthesis Simulation Model": netgen operates on fsmContainer.ngc, and generates ./netgen/synthesis/fsmContainer_synthesis.vhd file.

If we now open this fsmContainer_synthesis.vhd file, we can finally that this FFd3 does not exist there:

> grep FFd3 ./netgen/synthesis/fsmContainer_synthesis.vhd
>

 ... (since that .vhd file actually corresponds to Technology Schematic). So we'd want to re-run netgen for the RTL netlist - however, netgen cannot run on .ngr files directly.

 

So we may want to try to directly generate "Post-Translate Simulation Model"... That calls:

 

  • Translate: ngdbuild - which creates .ngd file from .ngc
  • "Post-Translate Simulation Model": netgen, which from .ngd file, generates ./netgen/translate/fsmContainer_translate.vhd

... and again no FFd3 to be found.


It seems that the .ngr is generated only with the purpose of viewing as RTL schematic - and it cannot be converted back into HDL. With that in mind, the only "constant" I can see (related to FFd3), is the ground going into FFd3.D on the RTL Schematic. If we could convert the .ngr back to VHDL, I'd bet we'd find something like this (which I got from other piece of code with a similar warning, modified):
 

XST_GND : GND
  port map (
    G => N0
  );
XST_VCC : VCC
  port map (
    P => N1
  );
state_fsm_FSM_FFd3 : FD
  generic map(
    INIT => '1'
  )
  port map (
    C => clk_BUFGP_682,
    D => N0,
    Q => state_fsm_FSM_FFd3_657
  );

 

 ... and the "INIT => '1'" would be the 'init' mentioned in the error message (it being different from the constant value of GND, applied to the D input).

 

Now, the thing is that no other warnings are generated for this code all the way to post-par simulation. So what should I think about "FSM_FFd3 hinder the constant cleaning" - should I try to "fix" it somehow or not? I could maybe try with an attribute INIT in an *.ucf file - however, that wouldn't do much good, as FFd3 exists nowhere other than the .ngr netlist, apparently.

 

The only other problem I can see, is that - in post-par simulation, if the OFFSET is less than 90 ns, then the pulse doesn't fire. Could that be related to the "FSM_FFd3 hinder the constant cleaning" warning?

 

I'd appreciate any guidance in how to think about this warning,
Cheers!

 

 

PS: The code:

 

-- file: fsm_tri.vhd
---------------

library IEEE;
  use IEEE.STD_LOGIC_1164.ALL;
  use IEEE.NUMERIC_STD.ALL;

-- NEVER call port pins "in"; "out": ERROR:HDLCompiler:806 'Syntax error near "in"'!
ENTITY fsmContainer IS
  PORT (
    clk: IN STD_LOGIC;
    p_out: OUT STD_LOGIC
  );
END fsmContainer;


ARCHITECTURE structure OF fsmContainer IS

  -- 'dummy signals' - registers
  SIGNAL w_out : STD_LOGIC := 'Z';

  -- fsm states
  TYPE states_fsm IS -- ned: fsmContainer
  (
    stA,
    stB,       -- wait for in active low
    stC  -- signal for sampling
    --,stD        -- wait for in active hi
  );

  -- init fsm state vars
  SIGNAL state_fsm, next_state_fsm: states_fsm := stA;

-- implementation:
BEGIN

  -- assign 'wire' / registers
  p_out <= w_out;


  -- STATE MACHINES CODE =========
  sm_fsm: PROCESS(state_fsm) -- combinatorial process part
  BEGIN
    CASE state_fsm IS

      WHEN stA =>
        next_state_fsm <= stB;

      WHEN stB =>
          next_state_fsm <= stC;

      WHEN stC =>
        next_state_fsm <= stC;

      WHEN OTHERS =>
        next_state_fsm <= stA;

      -- WHEN stD =>
        -- next_state_fsm <= stA;

    END CASE;
  END PROCESS sm_fsm;

  out_sm_fsm: PROCESS(clk) -- synchronous process part --
  BEGIN
    IF (rising_edge(clk)) THEN -- returns only valid transitions;
      IF state_fsm = stB THEN --
        w_out <= '1';
      ELSE
        w_out <= '0';
      END IF;

      state_fsm <= next_state_fsm;
    END IF;
  END PROCESS out_sm_fsm;

  -- END STATE MACHINES CODE =====
END structure; -- ARCHITECTURE


------------------


-- file: fsm_tri_twb.vhd
---------------

library IEEE;
  use IEEE.STD_LOGIC_1164.ALL;
  use IEEE.NUMERIC_STD.ALL;

ENTITY fsm_tri_twb IS
END fsm_tri_twb;

ARCHITECTURE testbench_arch OF fsm_tri_twb IS

  COMPONENT fsmContainer
    PORT(
      clk:       IN STD_LOGIC;
      p_out:       OUT STD_LOGIC
    );
  END COMPONENT;

  -- 'wires'
  SIGNAL wCLK : std_logic := '0';
  SIGNAL wOUT : std_logic := 'Z';

  -- clock parameters
  constant PERIODN : natural := 20; -- can be real := 20.0;
  constant PERIOD : time := PERIODN * 1 ns;
  constant DUTY_CYCLE : real := 0.5;
  constant OFFSET : time := 90 ns; -- at least 90 ?!

-- implementation of workbench
BEGIN

  -- instances of components, and their wiring (port maps)...
  UUT : fsmContainer -- VHDL
  PORT MAP(
    clk => wCLK,
    p_out => wOUT
  );

  -- PROCESSES (STATE MACHINES) CODE =========

  -- clock process for generating CLK
  clocker: PROCESS
  BEGIN

    WAIT for OFFSET;

    CLOCK_LOOP : LOOP
      wCLK <= '0';
      WAIT FOR (PERIOD - (PERIOD * DUTY_CYCLE));
      wCLK <= '1';
      WAIT FOR (PERIOD * DUTY_CYCLE);
    END LOOP CLOCK_LOOP;
  END PROCESS clocker;

  -- END PROCESSES (STATE MACHINES) CODE =====
END testbench_arch; -- ARCHITECTURE

 

 

Super Contributor
pcurt
Posts: 209
Registered: ‎04-09-2008

Re: Debugging "WARNING:Xst:1426 - The value init of the FF/Latch ... hinder the constant cleaning" (fsm)

The following line of code is synthesizing your "INIT"

 

SIGNAL state_fsm, next_state_fsm: states_fsm := stA;

 That := is assigning both state_fsm and next_state the values "001" in the bitstream.  So when you power on the FPGA and program it, one particular flip-flop contains the value '1' instead and the other 2 contain '0'.

 

You can remove this warning by using a reset in your code, instead of an init.  In general, init statements should be avoided except in special cases where you must satisfy some power-on reset condition.

 

So add a top-level port called "reset" or something.  Then add an if-else statement like:

 

if rising_edge(clk) then
  if reset='1' then
    state_fsm <= stA;
  else
    state_fsm <= next_state_fsm;
  end if;
end if;

 

Since this is a synchronous reset, make sure you hold it high a few cycles in your testbench.  The tools should automatically connect this reset net to a global reset net, and your entire design will be held in reset while it's being programmed.  As soon as the DCMs say the clocks are stable (by default), the GSR will deassert and your state machine will start running.

Senior Engineer
EM Photonics, Inc.
Expert Contributor
rcingham
Posts: 2,115
Registered: ‎09-09-2010
0

Re: Debugging "WARNING:Xst:1426 - The value init of the FF/Latch ... hinder the constant cleaning" (fsm)

I tend to ignore these warnings. Is there some Fine Document that explains how deleterious the effect that is being warned against actually is?

------------------------------------------
"If it don't work in simulation, it won't work on the board."
Expert Contributor
awillen
Posts: 747
Registered: ‎11-29-2007

Re: Debugging "WARNING:Xst:1426 - The value init of the FF/Latch ... hinder the constant cleaning" (fsm)

[ Edited ]

pcurt wrote:

The following line of code is synthesizing your "INIT"

 

SIGNAL state_fsm, next_state_fsm: states_fsm := stA;

 That := is assigning both state_fsm and next_state the values "001" in the bitstream.  So when you power on the FPGA and program it, one particular flip-flop contains the value '1' instead and the other 2 contain '0'.

 

You can remove this warning by using a reset in your code, instead of an init.  In general, init statements should be avoided except in special cases where you must satisfy some power-on reset condition.


Actually, the opposite is the case: you should use an init value, and only use reset for those flip-flops for which it is really necessary. sdaau's approach is the better one.

The reset signal takes up valuable routing resources, whereas an initial value doesn't. Furthermore, the reset signal (and the clock and clock enable signals) are shared among the flip-flops in a slice, so two flip-flops with different reset signals can not be packed into the same slice, potentially increasing area usage; the initial values, in contrast, are per flip-flop.

 

For further information, see WP272 and WP275.

 


So add a top-level port called "reset" or something.  Then add an if-else statement like:

 

if rising_edge(clk) then
  if reset='1' then
    state_fsm <= stA;
  else
    state_fsm <= next_state_fsm;
  end if;
end if;

 

Since this is a synchronous reset, make sure you hold it high a few cycles in your testbench.  The tools should automatically connect this reset net to a global reset net,


No, they don't. They'll treat it just like a normal net, connected to an ordinary IO pin. Resets take up normal routing resources.

 


and your entire design will be held in reset while it's being programmed.  As soon as the DCMs say the clocks are stable (by default), the GSR will deassert and your state machine will start running.

The whole FPGA will be held in its inital state as long as it is being programmed. After that is done, the sequential elements will be released (i.e. start working), independent of whether all DCMs are locked or not.

 

 

Regarding that warning message: ignore it. The "constant" XST is rambling about, is your state_fsm register – if you gave it the initial value of 0, then it would never change and could be replaced by a constant (which is not what you want). XST can sometimes be a little dense about these things. If anything, this message should be an "Info", not a "Warning".

 

 

Edit: This is post #666. Nice.



Signature:
1. Google your question before asking it.
2. If Google doesn't find a solution, post your question in a detailed, comprehensive, and clear way.
3. If someone answers your question, mark the post with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left).
Expert Contributor
eteam00
Posts: 8,087
Registered: ‎07-21-2009
0

Welcome back, Adrian

Edit: This is post #666. Nice.

 

Welcome back, Mark of the Dxxxl Adrian!

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
Expert Contributor
awillen
Posts: 747
Registered: ‎11-29-2007
0

Re: Welcome back, Adrian


eteam00 wrote:

Edit: This is post #666. Nice.

 

Welcome back, Mark of the Dxxxl Adrian!

 

-- Bob Elkind


:-D
Thanks Bob, glad to be back!

 

#667, now it's a clock frequency.



Signature:
1. Google your question before asking it.
2. If Google doesn't find a solution, post your question in a detailed, comprehensive, and clear way.
3. If someone answers your question, mark the post with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left).
Regular Visitor
sdaau
Posts: 37
Registered: ‎07-13-2011
0

Re: Debugging "WARNING:Xst:1426 - The value init of the FF/Latch ... hinder the constant cleaning" (fsm)

Hi all,

 

Many, many thanks for the great answers - much appreciated!

 


pcurt wrote:

The following line of code is synthesizing your "INIT"

 

SIGNAL state_fsm, next_state_fsm: states_fsm := stA;

 That := is assigning both state_fsm and next_state the values "001" in the bitstream.  So when you power on the FPGA and program it, one particular flip-flop contains the value '1' instead and the other 2 contain '0'.

 



awillen wrote:

Regarding that warning message: ignore it. The "constant" XST is rambling about, is your state_fsm register – if you gave it the initial value of 0, then it would never change and could be replaced by a constant (which is not what you want). XST can sometimes be a little dense about these things. If anything, this message should be an "Info", not a "Warning".


Many thanks for these - my greatest problem was to relate to what do the "init" and the "constant" in the warning message mean...

 

 


awillen wrote:

The reset signal takes up valuable routing resources, whereas an initial value doesn't. Furthermore, the reset signal (and the clock and clock enable signals) are shared among the flip-flops in a slice, so two flip-flops with different reset signals can not be packed into the same slice, potentially increasing area usage; the initial values, in contrast, are per flip-flop.

 

For further information, see WP272 and WP275.


Awesome, awesome docs - thanks for the reference! Wish I stumbled upon them earlier (then again, I probably would not have understood them without this problem to provide context)..

 

 


awillen wrote:

#667, now it's a clock frequency.


We're out of the danger zone now :)

 

 

Thanks for setting me straight on this one, everyone,

Cheers!