Synthesis

[eteam00]

From post #5 in this thread:

If a process is clocked (synchronous), only the clock (and any asynchronous set/reset) should be in the process sensitivity list.

I am unfamiliar with VHDL 'natural'.  I'm wondering why 'cuenta' is cast as 'natural' instead of 26-bit 'signal'.

If signals 'inc', 'dec', and 'start' are asynchronous inputs, they must be aligned to CLK_50MHZ clock domain before they are used by the state machine.  If they are not aligned to the state machine clock, they will cause the state machine to 'lock up'.  If they are switch inputs, they must also be de-bounced.

The inputs 'inc' and 'dec' are ignored while 'cuenta is counting.  Short assertion pulses on these inputs may not be recognised.

If 'tiempo' is a synchronous counter, your code permits 'tiempo' to decrement to -1 in both state machine states.  Perhaps you wish 'tiempo' to decrement no further than '0'.

-- Bob Elkind

[black_flowers]

If a process is clocked (synchronous), only the clock (and any asynchronous set/reset) should be in the process sensitivity list.

 and what happens with the input singnals?. I have seen a lot of state machines that includes those input signals in the sensitivity list. There are another way of doing it with two processes, one for "combinational logic" with signal inputs in the sensitivty list, and the other for "state memory"  with only clock and reset on the sensitivity list. But i don't know why i can't get this configuration working. I'm having trouble with this two process configuration in some other simple state machines, i have in mind to ask about that topic in another thread. So i can only do it with one process and with all input signals on the sensitivity list.

I could use 26-bit 'signal, there's no reason for using natural.

I can't understand what you mean with align those signals with CLK_50MHZ. What's this exactly??

And of course, the inputs are push-buttons so they need to be debounced, but i haven't done it yet.

And finally i don't really mind that the tiempo signal takes negative values.

once again, thanks for your help.

[eteam00]

I can't understand what you mean with align those signals with CLK_50MHZ. What's this exactly??

• You have an async input signal used by two different registers, A and B.

• The interconnect delay from input pin to register A is longer than the interconnect delay from input pin to register B.

• Register A 'sees' a delayed version of the async input.

• On any given rising clock edge, register A may 'see' a different level for the async input than register B, because of the difference in propagation delays from input pin to register input.

This problem is easily fixed by registering the async input, and using only the registered copy of the input throughout your design.  The registered copy of the async input is synchronous to the clock domain.  It is aligned with the clock.

-- Bob Elkind

[eteam00]

If a process is clocked (synchronous), only the clock (and any asynchronous set/reset) should be in the process sensitivity list.

 and what happens with the input singnals?. I have seen a lot of state machines that includes those input signals in the sensitivity list.

Correct me if I'm wrong (I'm not a VHDL wizard), but everything within this IF-THEN statement

if(rising_edge(CLK_50MHZ)) then

is clocked and synchronous (not combinatorial).

-- Bob Elkind

[gszakacs]

If a process is clocked (synchronous), only the clock (and any asynchronous set/reset) should be in the process sensitivity list.

 and what happens with the input singnals?

All inputs are only sampled on the clock edge.  This physically matches the nature of real

D flip-flops in the hardware.  They should not be in the list because your actual hardware

will not change state if some input other than the clock changes state, only at the clock

edge.  A sensitivity list does not describe all of the inputs to the logic (necessarily) but only

those that "trigger" the process to run.  A flip-flop is only triggered on a clock edge or

possibly during assertion of asynchronous set/reset.  And in the reset case there should

be no sensitivity to other inputs (that would describe a D latch instead of a set or reset).

I have seen a lot of state machines that includes those input signals in the sensitivity list. 

I would look again at those state machines.  Either they use two processes, one clocked with just the

clock and perhaps reset in the sensitivity list and one combinatorial with all inputs in the sensitivity list,

or they should use only one clocked process with just the clock and possibly reset in the sensitivity

list.  A clocked process that includes more signals in the list is wrong for synthesis, because it will

not match the simulation behavior.  In essence, synthesis uses standard templates to infer clocked

logic which ignore other signals in the list, and others to infer combinatorial logic which assume all

inputs are in the list.  Any code which doesn't match this paradigm has a chance of working differently

in hardware than in simulation.

-- Gabor

[black_flowers]

yes you are right, they used two process indeed but they were using clk,reset and NextState in the sensitivity list, so i suppose that NextState shouldn't be at sensitivity list neither.

So, i changed the sensitivity list and now it looks like this:

logica_estado: process(CLK_50MHZ)

 is it totally correct now?

Or course i need to add something for debouncing the inputs but i prefer to do it later.

And about the comment of eteam: "This problem is easily fixed by registering the async input, and using only the registered copy of the input throughout your design.  The registered copy of the async input is synchronous to the clock domain.  It is aligned with the clock."  I'm not very sure i have totally understood the reason why;  but i suppose that it's in order to avoid changes in inputs once we are into the process, is it right?

And finally i'm not very sure that the timer implementation was completely right for an fpga, is it?

[gszakacs]

The best way to see if your code is correct is to simulate it.  I would expect that you'd

find at least one problem if you had simulated:

signal EstadoActual: TipoEstados; -- Uninitialized state variable used in a process with no reset

signal EstadoActual: TipoEstados := Esperando; - Initialize the state variable for both simulation and synthesis

The point Bob made about asynchronous inputs is not easy to understand and often

misinterpreted as being a "metastability" problem.  What you need for this code to work well

is "clean" signals from the pushbuttons.  You can do this in a separate "debounce" process.

A typical switch debouncer simply samples the switch at a rate slow enough that bouncing

will settle out between two sample times.  You can think of a mechanical switch turning

on like dropping a ball on the ground.  The switch is on while the ball touches the ground.

If the ball takes two seconds to finish bouncing and come to rest on the ground, then you

can "sample" the ball (is it on the ground now?) no more often than once every two seconds

and be sure that your sample will only go from 0 (not on the ground) to 1 (on the ground) once.

Note that any sample before the ball is dropped is guaranteed to be 0.  Any sample after

the ball comes to rest is guaranteed to be 1.  A sample taken while the ball is bouncing

can be 0 or 1.  The sampling period should be st such that at most one sample will be

taken while the ball bounces.  So if the red sample is taken while the ball bounces you have

00001111111

or

00000111111

In either case you only have a single transition from 0 to 1.  If you sample too fast, you

can have more than one "red" sample allowing:

00001011111

Hope this explains the problems.

-- Gabor

[eteam00]

And about the comment of eteam: "This problem is easily fixed by registering the async input, and using only the registered copy of the input throughout your design.  The registered copy of the async input is synchronous to the clock domain.  It is aligned with the clock."  I'm not very sure i have totally understood the reason why;  but i suppose that it's in order to avoid changes in inputs once we are into the process, is it right?

Let me try to explain once again.  Here is a snippet of your code:

if(inc='1')then -- when press the inc button,signal tiempo is increased.
   if(not vIncAnterior) then
   tiempo<=tiempo+1;
   vIncAnterior:=true;
   end if;

Notice that the multi-bit counter tiempo and the state bit vIncAnterior all change state on the same clock edge, based (in part) on the asynchronous input inc.

What is the timing relationship between the signal inc and the clock edge used to change tiempo and vIncAnterior?  It's unknown and variable, of course, because inc  is an asynchronous input.

Each of the registers must be directly or indirectly connected to the inc input signal, and these connections vary in length, depending on where the various registers are located in the FPGA.

Let's say the propagation delay (mostly interconnect) between the inc package pin and the registers for tiempo and vIncAnterior is as short as 1nS for the shortest connection and as long as 2nS for the longest connection.

If the signal inc changes from '0' to '1' only 3nS before the clock rising edge, then all the registers will see a '1' when they are clocked.  If the signal inc changes from '0' to '1' only 1.5nS before the clock rising edge, then some of the registers will see a '1' when they are clocked, because the propagation delay from inc package pin to register input is nice and short.  Some of the registers will see a '0' when they are clocked, because the propagation delay from inc package pin to register input is longer.

Because of the variation in propagation delays between the inc input pin and the register inputs, some register bits will 'see' the inc signal change on one clock rising edge and other register bits will see the inc signal change on the next clock rising edge.

What do you think would happen to the tiempo counter if some of the counter bits 'incremented' in one clock cycle and the rest of the counter bits 'incremented' in the next clock cycle?

Does this make sense?

The solution is to register the inc input signal, and use the registered copy of the inc signal for all of the registers which use the inc signal.  The registered copy of the inc signal is aligned to the clock rising edge.  Changes of the registered copy of the inc signal can be guaranteed to reach all of the register bits in the same clock cycle.

-- Bob Elkind

[bassman59]

---

eteam00 wrote:

From post #5 in this thread:

If a process is clocked (synchronous), only the clock (and any asynchronous set/reset) should be in the process sensitivity list.

I am unfamiliar with VHDL 'natural'.  I'm wondering why 'cuenta' is cast as 'natural' instead of 26-bit 'signal'.

---

Type natural is a non-negative integer, essentially integer range 0 to 2**32-1. I use natural for counters pretty much all the time (except of course when the count must be negative). The caveats with natural are:

a) it actually holds 31 bits of information even though it's 32 bits wide, and

b) when you use it, since it is by default 32-bits wide, you should constrain it with a range so you don't get a whole lot of unused flipflops and your comparators don't get huge and all of the other reasons to constrain it.

And it is better to use natural (or integer, or unsigned), than rely on std_logic_arith and its crappy functions for incrementing and decrementing std_logic_vectors, which are not "numerics" in the sense that the bit sequence 1001 doesn't necessarily mean 9. It might be negative.

[bassman59]

---

black_flowers wrote:

 There are another way of doing it with two processes, one for "combinational logic" with signal inputs in the sensitivty list, and the other for "state memory"  with only clock and reset on the sensitivity list. 

---

That's called a "two-process state machine," and you should never ever ever use them in any design ever.