Signal xx cannot be synthesized, bad synchronous description error

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

  1. Guest

    Hi

    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)
    begin

    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.
    , May 18, 2013
    #1
    1. Advertising

  2. On 18 Mai, 13:44, wrote:

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


    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)

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


    combinatorial process don't allow rising edge.
    Rising edge is only allowed in sequential process in the following
    style:

    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
    #2
    1. Advertising

  3. 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.
    , May 19, 2013
    #3
  4. 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
    , May 19, 2013
    #4
  5. 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
    Andy, May 20, 2013
    #5
  6. Andy Guest

    Warning:

    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
    Andy, May 20, 2013
    #6
  7. rickman Guest

    Re: Signal xx cannot be synthesized, bad synchronous descriptionerror

    On 5/19/2013 8:19 AM, wrote:
    > 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?


    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.

    --

    Rick
    rickman, May 20, 2013
    #7
  8. rickman Guest

    Re: Signal xx cannot be synthesized, bad synchronous descriptionerror

    On 5/20/2013 11:42 AM, Andy wrote:
    > Warning:
    >
    > 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.


    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.

    --

    Rick
    rickman, May 20, 2013
    #8
  9. Gabor Guest

    Re: Signal xx cannot be synthesized, bad synchronous descriptionerror

    On 5/20/2013 1:15 PM, rickman wrote:
    > On 5/20/2013 11:42 AM, Andy wrote:
    >> Warning:
    >>
    >> 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.

    >
    > 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.
    >

    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
    Gabor, May 21, 2013
    #9
  10. On 19 Mai, 15:46, wrote:
    > 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?


    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
    #10
  11. rickman Guest

    Re: Signal xx cannot be synthesized, bad synchronous descriptionerror

    On 5/21/2013 5:39 AM, Thomas Stanka wrote:
    > On 19 Mai, 15:46, wrote:
    >> 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?

    >
    > 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.


    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.

    --

    Rick
    rickman, May 21, 2013
    #11
  12. 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 ...
    begin
    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 =>
    null;
    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
    Andy, May 22, 2013
    #12
  13. Guest

    Le dimanche 19 mai 2013 15:46:57 UTC+2, a écrit :
    > 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 valuesof 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


    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.
    , May 22, 2013
    #13
  14. Andy Guest

    Rick,

    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
    Andy, May 22, 2013
    #14
  15. rickman Guest

    Re: Signal xx cannot be synthesized, bad synchronous descriptionerror

    On 5/22/2013 11:14 AM, Andy wrote:
    > Rick,
    >
    > 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.


    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.

    --

    Rick
    rickman, May 22, 2013
    #15
  16. Guest

    Hello

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

    Thanks!
    , Jun 19, 2013
    #16
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Takuon Soho
    Replies:
    5
    Views:
    703
    Charles Bailey
    Mar 9, 2005
  2. fpgawizz
    Replies:
    4
    Views:
    691
    dutchgoldtony
    Mar 4, 2005
  3. Zenock
    Replies:
    7
    Views:
    8,918
    vipinlal
    Mar 10, 2010
  4. Roman Himmes
    Replies:
    8
    Views:
    13,491
    Duane Clark
    Jun 22, 2005
  5. tarzandavid
    Replies:
    1
    Views:
    874
    jeppe
    Jun 13, 2008
Loading...

Share This Page