Signal xx cannot be synthesized, bad synchronous description error

[rob...@gmail.com]

Hi

I need to make a kind of controller for a school project but i keep getting stuck 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.

[Thomas Stanka]

On 18 Mai, 13:44, robb...@gmail.com 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

[rob...@gmail.com]

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.

[rob...@gmail.com]

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

[Andy]

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]

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

[rickman]

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]

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

[Gabor]

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

[Thomas Stanka]

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

[rickman]

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

[Andy]

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 or afterward, assuming you included a reset assignment for output.

Andy

[celine.bo...@gmail.com]

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.

[Andy]

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

[rickman]

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

[rob...@gmail.com]

Hello

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

Thanks!