Signal xx cannot be synthesized, bad synchronous description error

Discussion in 'VHDL' started by robbevt, May 18, 2013.

  1. robbevt

    robbevt Guest


    I need to make a kind of controller for a school project but i keep gettingstuck on the same error. which is:

    "ERROR:Xst:827 - "D:/School/VHDL/ServoController/ControllerBeta.vhd" line 132: Signal nextstate cannot be synthesized, bad synchronous description. The description style you are using to describe a synchronous element (register, memory, etc.) is not supported in the current software release."

    I had the exact same error before, but then with a different signal above this line, and when i fixed that (i did not alter the code below line 132) this one popped up. Here is the code beginning from line 132:

    NEXT_STATE_DECODE: process (state, doneData, donePuls, SET, CLK)

    nextstate <= state;

    case (state) is
    when idle => if rising_edge(SET) then nextstate <= leesAdres; end if;

    when leesAdres => if (ADDRDATA = Address) then nextstate <= leesData;
    else nextstate <= idle; end if;

    when leesData => if doneData = '1' then nextstate <= geefPuls; end if;

    when geefPuls => if donePuls = '1' then nextstate <= idle; end if;

    when others => nextstate <= idle;
    end case;
    end process;
    end Behavioral;

    I don't quite understand where i could have gone wrong in such a small and relatively simple block of code, i'm using the language templates and they do it in the same way. The previous error got solved by changing a case statement to an if statement, but that shouldn't be necessary right?
    Any help would be very appreciated.

    If you need me to post the rest of the code just ask, i didn't include it now to reduce the clutter of my post.
    robbevt, May 18, 2013
    1. Advertisements

  2. This is a combinatorial process, it describes the logic behavior of
    pure combinatoric (the style for a statemachine is widely used in old/
    bad books, use search function to learn about that issue as fsm style
    has nothing to do with your problem and it is not wrong)
    combinatorial process don't allow rising edge.
    Rising edge is only allowed in sequential process in the following

    process (clk, asyncreset)
    if asyncreset = condition then
    -- resetstatements
    elsif rising_edge(Clk) then
    -- sequential statements

    with the asynchronous reset beeing optional

    I guess you like to stay in a state, till a signal rises from 0 to 1,
    this needs to be done by clocking that signal into a shiftregister and
    detect rising edge by xor the last two register of the shiftreg

    if rising_egde(Clk) then
    my_sr <= my_sr(my_sr'high-1 downto 0) & inputsignal; -- if
    inputsignal is syncronous to clk, use only 2 ff, or if you need it
    fast only 1 ff and xor with inputsignal, else use additional ff
    (typically 2)
    edge <= my_sr(my_sr'high) xor my_sr(my_sr'high -1); -- this means
    edge is stored in a ff, edge could be also generate outside clocked
    process to represent xor without ff
    end if
    Thomas Stanka, May 18, 2013
    1. Advertisements

  3. robbevt

    robbevt Guest

    Hi Thomas

    Thank you for your response.
    I understand what you mean, i didn't realize this wasn't allowed but it is quite logical once you think about it.

    Could i perhaps change the rising_edge(SET) statement by: if SET'event and SET='1' then ... or is this also wrong?

    Or should i let SET go through a D-flipflop so i can check if SET='1' and Q='0' with Q being the output of the flipflop.

    The reason i ask this i because i don't fully understand where to put this register, in a new process?

    Thanks again for your feedback.
    robbevt, May 19, 2013
  4. robbevt

    robbevt Guest

    After going over this a few times in my head, i think i now understand what to do.

    I make a new process with the sole purpose of storing the 2 latest values of SET (with the appropriate CLK), then i can change the rising_edge statement with an if (register(0) = '0' and register(1) = '1') then ...

    Could you confirm if i have this correctly?
    Thanks in advance
    robbevt, May 19, 2013
  5. robbevt

    Andy Guest

    I might use (assuming register is defined with a downto range) the following:

    if register = "10" then ...

    I would also use a more meaningful name like "edge" instead of "register".

    Andy, May 20, 2013
  6. robbevt

    Andy Guest


    XOR on the shift register contents will detect both falling AND rising edges!

    Note: While this problem (or any other) can be solved by correctly applying the two-process model (separate processes for combiinatorial logic and registers), the solution is much easier and more understandable in a single process model.

    Andy, May 20, 2013
  7. robbevt

    rickman Guest

    I'm not sure what your background is, but this is the sort of
    misunderstanding that happens when people with a software background
    start out writing HDL programs. HDL stands for "hardware description
    language" so it isn't programming as such, but rather describing the
    functionality of hardware. The functionality you are describing does
    not correspond to any hardware I am familiar with.

    Try drawing a block diagram of what you intend the logic to be. Draw
    blocks for registers and just use ovals for the combinatorial logic with
    some equations describing the logic function. Then you can easily code
    this by writing code with the boiler plate that Thomas gave you for the
    registers and the combinatorial equations can be in a combinatorial
    process or using concurrent statements.

    Once you learn where this takes you, you can omit the block diagrams
    just start coding in the future.
    rickman, May 20, 2013
  8. robbevt

    rickman Guest

    The caveat is that the single process model has *no* combinatorial
    outputs. So any output that decodes the state will have a clock cycle
    delay which may or may not matter in any given design.
    rickman, May 20, 2013
  9. robbevt

    Gabor Guest

    It's pretty easy to work around this issue. First, outputs that decode
    *only* the state can easily be external to the process, but as
    continuous assignments, avoiding the potential latch pitfalls of
    a two-process state machine where the next state is in the combinatorial
    process. Second, you can have outputs that change *with* the state
    rather than one cycle later if you assign them in the transition
    rather than the state, i.e. at the same time you assign the next
    state. Once you get used to thinking a cycle ahead, it gets quite
    easy to do, and I always prefer code where I can see as much as
    possible in one screen of statements.
    Gabor, May 21, 2013
  10. I can confirm this. You could check out the code sniplet in my first
    post. It is quick&dirty, as using 2 FF with 1 XOR detects falling and
    rising edges, so you need to check the content of the last shift
    register as well in order to see which edge you have.

    regards Thomas
    Thomas Stanka, May 21, 2013
  11. robbevt

    rickman Guest

    To detect just one edge, you use an AND gate with one input inverted.
    Invert the first FF and you have a falling edge detection. Invert the
    second FF and you get a rising edge detection.
    rickman, May 21, 2013
  12. robbevt

    Andy Guest

    Ah, but you CAN have combinatorial outputs driven from a synchronous process! But they cannot be a combinatorial function of an input to the process, they must be a combinatorial function of register(s) inferred by the process

    Structurally speaking, if you use a variable for the register, then any expressions in assignments from those variables occurring after the last (rst/clock) end-if will infer combinatorial logic after the register.

    process (rst, clk) is
    variable state is ...
    if rst then
    state := init;
    elsif rising_edge(clk) then
    case state is
    when init =>
    state := start;
    end case;
    end if;
    -- combinatorial outputs from registered variables
    ouput <= '0'; -- default to avoid latches
    case state is -- state is a register here
    when init | start =>
    output <= '1';
    when others =>
    end case;
    end process;

    This behavior/synthesis is documented in IEEE 1076.6-2002, the VHDL RTL Synthesis Standard. Note that it is the behavior that drives the synthesis result, not the structure of the process. The structure shown is one way to describe the behavior that results in combinatorial outputs from registers. Because state is accessed on a falling edge of the clock, when it was last assigned on a previous rising edge, the last reference to state is to a previously (in simulated time) stored value, the registered value of state is used. Because the output is updated (assigned) on both edges of the clock, it must be combinatorial.

    Note that if the output case statement was moved to before the final end-if, then output is registered, and the combinatorial logic for it is fed by the combinatorial value of state, which includes the update logic for state.But the cycle-accurate behavior of the state machine and of output is not changed whether the outputs are assigned within the clocked if-statement orafterward, assuming you included a reset assignment for output.

    Andy, May 22, 2013
  13. Le dimanche 19 mai 2013 15:46:57 UTC+2, a écrit :
    Yes, that's it.

    Just a question : do you really want to make an asynchronous FSM ? I you really want an asynchronous FSM you should delete CLK from the sensitivity list as it can lead to mismatch between simulation and synthesis.
    But as an old school gal I recommend to make your FSM synchronous. It will prevent you from many errors if you are new to VHDL.
    celine.boutet.perso, May 22, 2013
  14. robbevt

    Andy Guest


    I agree that designers need to be aware of what kinds of hardware are realizable and reliable in FPGAs/ASICs.

    And I agree that the designer needs to focus on the functionality (I call it behavior) of the HW.

    However, I completely disagree that a block diagram should desicribe separate registers and equations for combinatorial logic.

    The diagram should be hierarchical based on related behavior, and ultimately broken down into blocks of related behaviors that can be described in a sequential manner (a flow chart). Then I suggest coding clock-cycle-accurate, behavioral RTL models of the blocks (flow charts) from the diagram.

    Andy, May 22, 2013
  15. robbevt

    rickman Guest

    I have not seen flow charts used to describe hardware other than
    sequential functions like state machines. When designing logic, I am
    typically more concerned with the data paths and often use the block
    diagrams I described for that. I don't often have much need for flow
    charts for state machines since I typically code in a way that makes a
    flow chart redundant. But for newbies, I encourage the use of block
    diagrams to facilitate the mapping from flow charts to logic.
    rickman, May 22, 2013
  16. robbevt

    robbevt Guest


    Thank you all for your input, i will certainly be able to make it work with all this new information.

    robbevt, Jun 19, 2013
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.