Am looking for arcitecture of below code as a Finite State M

Guest
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_ARITH.all;
use IEEE.STD_LOGIC_UNSIGNED.all;
ENTITY debounce IS
PORT(pb, clock_100Hz : IN STD_LOGIC;
pb_debounced : OUT STD_LOGIC);
END debounce;
ARCHITECTURE a OF debounce IS
SIGNAL SHIFT_PB : STD_LOGIC_VECTOR(3 DOWNTO 0);
SIGNAL PREVIOUS : STD_LOGIC;
BEGIN
-- Debounce Button: Filters out mechanical switch bounce for around 40Ms.
-- Debounce clock should be approximately 10ms
process
begin
wait until (clock_100Hz'EVENT) AND (clock_100Hz = '1');
SHIFT_PB(2 Downto 0) <= SHIFT_PB(3 Downto 1);
SHIFT_PB(3) <= NOT PB;
If SHIFT_PB(3 Downto 0)="0000" THEN
PB_DEBOUNCED <= '0';
PREVIOUS <= '0';
ELSIF SHIFT_PB(3 Downto 0) = "1111" THEN
PB_DEBOUNCED <= '1';
PREVIOUS <= '1';
ELSE
PB_DEBOUNCED <= PREVIOUS;
End if;
end process;
end a;
 
On Thursday, December 17, 2015 at 9:04:39 PM UTC-5, rickman wrote:
On 12/17/2015 3:29 PM, disturbedspace1@gmail.com wrote:
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_ARITH.all;
use IEEE.STD_LOGIC_UNSIGNED.all;
ENTITY debounce IS
PORT(pb, clock_100Hz : IN STD_LOGIC;
pb_debounced : OUT STD_LOGIC);
END debounce;
ARCHITECTURE a OF debounce IS
SIGNAL SHIFT_PB : STD_LOGIC_VECTOR(3 DOWNTO 0);
SIGNAL PREVIOUS : STD_LOGIC;
BEGIN
-- Debounce Button: Filters out mechanical switch bounce for around 40Ms.
-- Debounce clock should be approximately 10ms
process
begin
wait until (clock_100Hz'EVENT) AND (clock_100Hz = '1');
SHIFT_PB(2 Downto 0) <= SHIFT_PB(3 Downto 1);
SHIFT_PB(3) <= NOT PB;
If SHIFT_PB(3 Downto 0)="0000" THEN
PB_DEBOUNCED <= '0';
PREVIOUS <= '0';
ELSIF SHIFT_PB(3 Downto 0) = "1111" THEN
PB_DEBOUNCED <= '1';
PREVIOUS <= '1';
ELSE
PB_DEBOUNCED <= PREVIOUS;
End if;
end process;
end a;

I rewrote the code to separate the state signals from the shift
register. Otherwise I'm not sure what you want to see. Are you looking
for some specific format for the FSM? There is no special format a
state machine has to be coded in unless your professor insists. I
didn't test any of this code. Oh, you should not use the
STD_LOGIC_UNSIGNED library. It is not a standard and works differently
with different vendors. Use the NUMERIC_STD library which *is* an IEEE
standard. Also, use "rising_edge()" instead of (clock_100Hz'EVENT) AND
(clock_100Hz = '1'). Lastly, using a wait statement may work for
synthesizable logic, but is not a great idea. Use a conditional and I
expect your circuit could use a reset. This is a *very* standard form
and is well supported.

I did find your signal "PREVIOUS" is superfluous. It is always assigned
the same value as PB_DEBOUNCED. Either you missed something in your
algorithm or you added this thinking it would do something useful but
never made it do that.

If you want the code to be in the form of a case statement based on the
state, you just need to make the conditionals specific to a state, but I
don't see any value in that.

Rick



library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_ARITH.all;
use IEEE.NUMERIC_STD.all;
ENTITY debounce IS
PORT(pb, clock_100Hz, Rst : IN STD_LOGIC;
pb_debounced : OUT STD_LOGIC);
END debounce;
ARCHITECTURE a OF debounce IS
SIGNAL SHIFT_PB : STD_LOGIC_VECTOR(3 DOWNTO 0);
SIGNAL PREVIOUS : STD_LOGIC;
BEGIN
-- Debounce Button: Filters out mechanical switch bounce for ~40ms.
-- Debounce clock should be approximately 10ms
process (clock_100Hz, Rst)
begin
if ('1' = Rst) then
SHIFT_PB <= (others => '0');
elsif (rising_edge(clock_100Hz)) then
SHIFT_PB(2 Downto 0) <= SHIFT_PB(3 Downto 1);
SHIFT_PB(3) <= NOT PB;
end if;
end process;

process (clock_100Hz, Rst)
begin
if ('1' = Rst) then
PB_DEBOUNCED <= '0';
PREVIOUS <= '0';
elsif (rising_edge(clock_100Hz)) then
if (SHIFT_PB = (others => '0')) then
PB_DEBOUNCED <= '0';
PREVIOUS <= '0';
elsif (SHIFT_PB = (others => '1')) then
PB_DEBOUNCED <= '1';
PREVIOUS <= '1';
else
PB_DEBOUNCED <= PREVIOUS;
end if;
end process;
end a;

--

Rick
Click to expand...

Thanks Rick for the response.. However I dont think thats what is the solution my professor is looking for. Copying the whole question as I got it.

"A very common approach to making sense of the strangeness of the real world is not to rely on sensors to trigger events, as we did in question one, but to use an internal clock in the the design. The DEBOUNCE.vhd module from lab7 does that:
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_ARITH.all;
use IEEE.STD_LOGIC_UNSIGNED.all;
ENTITY debounce IS
PORT(pb, clock_100Hz : IN STD_LOGIC;
pb_debounced : OUT STD_LOGIC);
END debounce;
ARCHITECTURE a OF debounce IS
SIGNAL SHIFT_PB : STD_LOGIC_VECTOR(3 DOWNTO 0);
SIGNAL PREVIOUS : STD_LOGIC;
BEGIN
-- Debounce Button: Filters out mechanical switch bounce for around 40Ms.
-- Debounce clock should be approximately 10ms
process
begin
wait until (clock_100Hz'EVENT) AND (clock_100Hz = '1');
SHIFT_PB(2 Downto 0) <= SHIFT_PB(3 Downto 1);
SHIFT_PB(3) <= NOT PB;
If SHIFT_PB(3 Downto 0)="0000" THEN
PB_DEBOUNCED <= '0';
PREVIOUS <= '0';
ELSIF SHIFT_PB(3 Downto 0) = "1111" THEN
PB_DEBOUNCED <= '1';
PREVIOUS <= '1';
ELSE
PB_DEBOUNCED <= PREVIOUS;
End if;
end process;
end a;
Express the architecture of this module as a Finite State Machine. There seem to be at least sixteen states, corresponding to the sixteen possible values of SHIFT_PB(3 downto 0)."
 
On 12/17/2015 3:29 PM, disturbedspace1@gmail.com wrote:
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_ARITH.all;
use IEEE.STD_LOGIC_UNSIGNED.all;
ENTITY debounce IS
PORT(pb, clock_100Hz : IN STD_LOGIC;
pb_debounced : OUT STD_LOGIC);
END debounce;
ARCHITECTURE a OF debounce IS
SIGNAL SHIFT_PB : STD_LOGIC_VECTOR(3 DOWNTO 0);
SIGNAL PREVIOUS : STD_LOGIC;
BEGIN
-- Debounce Button: Filters out mechanical switch bounce for around 40Ms.
-- Debounce clock should be approximately 10ms
process
begin
wait until (clock_100Hz'EVENT) AND (clock_100Hz = '1');
SHIFT_PB(2 Downto 0) <= SHIFT_PB(3 Downto 1);
SHIFT_PB(3) <= NOT PB;
If SHIFT_PB(3 Downto 0)="0000" THEN
PB_DEBOUNCED <= '0';
PREVIOUS <= '0';
ELSIF SHIFT_PB(3 Downto 0) = "1111" THEN
PB_DEBOUNCED <= '1';
PREVIOUS <= '1';
ELSE
PB_DEBOUNCED <= PREVIOUS;
End if;
end process;
end a;
Click to expand...

I rewrote the code to separate the state signals from the shift
register. Otherwise I'm not sure what you want to see. Are you looking
for some specific format for the FSM? There is no special format a
state machine has to be coded in unless your professor insists. I
didn't test any of this code. Oh, you should not use the
STD_LOGIC_UNSIGNED library. It is not a standard and works differently
with different vendors. Use the NUMERIC_STD library which *is* an IEEE
standard. Also, use "rising_edge()" instead of (clock_100Hz'EVENT) AND
(clock_100Hz = '1'). Lastly, using a wait statement may work for
synthesizable logic, but is not a great idea. Use a conditional and I
expect your circuit could use a reset. This is a *very* standard form
and is well supported.

I did find your signal "PREVIOUS" is superfluous. It is always assigned
the same value as PB_DEBOUNCED. Either you missed something in your
algorithm or you added this thinking it would do something useful but
never made it do that.

If you want the code to be in the form of a case statement based on the
state, you just need to make the conditionals specific to a state, but I
don't see any value in that.

Rick



library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_ARITH.all;
use IEEE.NUMERIC_STD.all;
ENTITY debounce IS
PORT(pb, clock_100Hz, Rst : IN STD_LOGIC;
pb_debounced : OUT STD_LOGIC);
END debounce;
ARCHITECTURE a OF debounce IS
SIGNAL SHIFT_PB : STD_LOGIC_VECTOR(3 DOWNTO 0);
SIGNAL PREVIOUS : STD_LOGIC;
BEGIN
-- Debounce Button: Filters out mechanical switch bounce for ~40ms.
-- Debounce clock should be approximately 10ms
process (clock_100Hz, Rst)
begin
if ('1' = Rst) then
SHIFT_PB <= (others => '0');
elsif (rising_edge(clock_100Hz)) then
SHIFT_PB(2 Downto 0) <= SHIFT_PB(3 Downto 1);
SHIFT_PB(3) <= NOT PB;
end if;
end process;

process (clock_100Hz, Rst)
begin
if ('1' = Rst) then
PB_DEBOUNCED <= '0';
PREVIOUS <= '0';
elsif (rising_edge(clock_100Hz)) then
if (SHIFT_PB = (others => '0')) then
PB_DEBOUNCED <= '0';
PREVIOUS <= '0';
elsif (SHIFT_PB = (others => '1')) then
PB_DEBOUNCED <= '1';
PREVIOUS <= '1';
else
PB_DEBOUNCED <= PREVIOUS;
end if;
end process;
end a;

--

Rick
 
On 12/17/2015 11:25 PM, disturbedspace1@gmail.com wrote:
On Thursday, December 17, 2015 at 9:04:39 PM UTC-5, rickman wrote:
On 12/17/2015 3:29 PM, disturbedspace1@gmail.com wrote:
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_ARITH.all;
use IEEE.STD_LOGIC_UNSIGNED.all;
ENTITY debounce IS
PORT(pb, clock_100Hz : IN STD_LOGIC;
pb_debounced : OUT STD_LOGIC);
END debounce;
ARCHITECTURE a OF debounce IS
SIGNAL SHIFT_PB : STD_LOGIC_VECTOR(3 DOWNTO 0);
SIGNAL PREVIOUS : STD_LOGIC;
BEGIN
-- Debounce Button: Filters out mechanical switch bounce for around 40Ms.
-- Debounce clock should be approximately 10ms
process
begin
wait until (clock_100Hz'EVENT) AND (clock_100Hz = '1');
SHIFT_PB(2 Downto 0) <= SHIFT_PB(3 Downto 1);
SHIFT_PB(3) <= NOT PB;
If SHIFT_PB(3 Downto 0)="0000" THEN
PB_DEBOUNCED <= '0';
PREVIOUS <= '0';
ELSIF SHIFT_PB(3 Downto 0) = "1111" THEN
PB_DEBOUNCED <= '1';
PREVIOUS <= '1';
ELSE
PB_DEBOUNCED <= PREVIOUS;
End if;
end process;
end a;

I rewrote the code to separate the state signals from the shift
register. Otherwise I'm not sure what you want to see. Are you looking
for some specific format for the FSM? There is no special format a
state machine has to be coded in unless your professor insists. I
didn't test any of this code. Oh, you should not use the
STD_LOGIC_UNSIGNED library. It is not a standard and works differently
with different vendors. Use the NUMERIC_STD library which *is* an IEEE
standard. Also, use "rising_edge()" instead of (clock_100Hz'EVENT) AND
(clock_100Hz = '1'). Lastly, using a wait statement may work for
synthesizable logic, but is not a great idea. Use a conditional and I
expect your circuit could use a reset. This is a *very* standard form
and is well supported.

I did find your signal "PREVIOUS" is superfluous. It is always assigned
the same value as PB_DEBOUNCED. Either you missed something in your
algorithm or you added this thinking it would do something useful but
never made it do that.

If you want the code to be in the form of a case statement based on the
state, you just need to make the conditionals specific to a state, but I
don't see any value in that.

Rick



library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_ARITH.all;
use IEEE.NUMERIC_STD.all;
ENTITY debounce IS
PORT(pb, clock_100Hz, Rst : IN STD_LOGIC;
pb_debounced : OUT STD_LOGIC);
END debounce;
ARCHITECTURE a OF debounce IS
SIGNAL SHIFT_PB : STD_LOGIC_VECTOR(3 DOWNTO 0);
SIGNAL PREVIOUS : STD_LOGIC;
BEGIN
-- Debounce Button: Filters out mechanical switch bounce for ~40ms.
-- Debounce clock should be approximately 10ms
process (clock_100Hz, Rst)
begin
if ('1' = Rst) then
SHIFT_PB <= (others => '0');
elsif (rising_edge(clock_100Hz)) then
SHIFT_PB(2 Downto 0) <= SHIFT_PB(3 Downto 1);
SHIFT_PB(3) <= NOT PB;
end if;
end process;

process (clock_100Hz, Rst)
begin
if ('1' = Rst) then
PB_DEBOUNCED <= '0';
PREVIOUS <= '0';
elsif (rising_edge(clock_100Hz)) then
if (SHIFT_PB = (others => '0')) then
PB_DEBOUNCED <= '0';
PREVIOUS <= '0';
elsif (SHIFT_PB = (others => '1')) then
PB_DEBOUNCED <= '1';
PREVIOUS <= '1';
else
PB_DEBOUNCED <= PREVIOUS;
end if;
end process;
end a;

--

Rick


Thanks Rick for the response.. However I dont think thats what is the solution my professor is looking for. Copying the whole question as I got it.

"A very common approach to making sense of the strangeness of the real world is not to rely on sensors to trigger events, as we did in question one, but to use an internal clock in the the design. The DEBOUNCE.vhd module from lab7 does that:
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_ARITH.all;
use IEEE.STD_LOGIC_UNSIGNED.all;
ENTITY debounce IS
PORT(pb, clock_100Hz : IN STD_LOGIC;
pb_debounced : OUT STD_LOGIC);
END debounce;
ARCHITECTURE a OF debounce IS
SIGNAL SHIFT_PB : STD_LOGIC_VECTOR(3 DOWNTO 0);
SIGNAL PREVIOUS : STD_LOGIC;
BEGIN
-- Debounce Button: Filters out mechanical switch bounce for around 40Ms.
-- Debounce clock should be approximately 10ms
process
begin
wait until (clock_100Hz'EVENT) AND (clock_100Hz = '1');
SHIFT_PB(2 Downto 0) <= SHIFT_PB(3 Downto 1);
SHIFT_PB(3) <= NOT PB;
If SHIFT_PB(3 Downto 0)="0000" THEN
PB_DEBOUNCED <= '0';
PREVIOUS <= '0';
ELSIF SHIFT_PB(3 Downto 0) = "1111" THEN
PB_DEBOUNCED <= '1';
PREVIOUS <= '1';
ELSE
PB_DEBOUNCED <= PREVIOUS;
End if;
end process;
end a;
Express the architecture of this module as a Finite State Machine. There seem to be at least sixteen states, corresponding to the sixteen possible values of SHIFT_PB(3 downto 0)."
Click to expand...

I guess your professor wants you to do it with a case statement based on
the 16 possible states of SHIFT_PB. I suggest you not bother with that
since it is a pointless exercise. Rather you should point out all the
bad programming mistakes he made in his code. I'm sure you will get
extra credit for that.

Really! Your professor sucks at VHDL coding!!! Tell him a professional
said so.

--

Rick
 
<disturbedspace1@gmail.com> wrote in message
news:1cd38a17-4cb3-424d-99ac-8c957e9ccfdc@googlegroups.com...
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_ARITH.all;
use IEEE.STD_LOGIC_UNSIGNED.all;
ENTITY debounce IS
PORT(pb, clock_100Hz : IN STD_LOGIC;
pb_debounced : OUT STD_LOGIC);
END debounce;
ARCHITECTURE a OF debounce IS
SIGNAL SHIFT_PB : STD_LOGIC_VECTOR(3 DOWNTO 0);
SIGNAL PREVIOUS : STD_LOGIC;
BEGIN
-- Debounce Button: Filters out mechanical switch bounce for around
40Ms.
-- Debounce clock should be approximately 10ms
process
begin
wait until (clock_100Hz'EVENT) AND (clock_100Hz = '1');
SHIFT_PB(2 Downto 0) <= SHIFT_PB(3 Downto 1);
SHIFT_PB(3) <= NOT PB;
If SHIFT_PB(3 Downto 0)="0000" THEN
PB_DEBOUNCED <= '0';
PREVIOUS <= '0';
ELSIF SHIFT_PB(3 Downto 0) = "1111" THEN
PB_DEBOUNCED <= '1';
PREVIOUS <= '1';
ELSE
PB_DEBOUNCED <= PREVIOUS;
End if;
end process;
end a;
Click to expand...

Well, here is how another professional logic designer would code this
circuit:
library IEEE;
use IEEE.STD_LOGIC_1164.all;
ENTITY debounce IS
PORT(pb, clock_100Hz : IN STD_LOGIC;
pb_debounced : OUT STD_LOGIC);
END ENTITY;
ARCHITECTURE a OF debounce IS
SIGNAL SHIFT_PB : STD_LOGIC_VECTOR(3 DOWNTO 0);
BEGIN
-- Debounce Button: Filters out mechanical switch bounce for around
40Ms.
-- Debounce clock should be approximately 10ms
process
begin
wait until rising_edge(clock_100Hz);
SHIFT_PB <= NOT PB & SHIFT_PB(3 Downto 1);
If SHIFT_PB="0000" THEN
PB_DEBOUNCED <= '0';
ELSIF SHIFT_PB = "1111" THEN
PB_DEBOUNCED <= '1';
End if;
end process;
END ARCHITECTURE;

This circuit doesn't do any arithmetic so you don't need
STD_LOGIC_ARITH, STD_LOGIC_UNSIGNED or numeric_std packages.
The PREVIOUS signal is superfluous.
There is no problem with using a single WAIT statement in a clocked
process. I have many multi-million-gate ASICs in the field where much
of the logic is coded that way. (Different designers have different
preferences/habits.)
This circuit doesn't really need a reset. After 4 clock cycles SHIFT_PB
will be in whatever state PB is in. PB_DEBOUNCED will be undefined for
a few clock cycles until PB settles down; but, so what?

Charles Bailey
 
On 1/1/2016 4:25 PM, tuclogicguy wrote:
disturbedspace1@gmail.com> wrote in message
news:1cd38a17-4cb3-424d-99ac-8c957e9ccfdc@googlegroups.com...
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_ARITH.all;
use IEEE.STD_LOGIC_UNSIGNED.all;
ENTITY debounce IS
PORT(pb, clock_100Hz : IN STD_LOGIC;
pb_debounced : OUT STD_LOGIC);
END debounce;
ARCHITECTURE a OF debounce IS
SIGNAL SHIFT_PB : STD_LOGIC_VECTOR(3 DOWNTO 0);
SIGNAL PREVIOUS : STD_LOGIC;
BEGIN
-- Debounce Button: Filters out mechanical switch bounce for around
40Ms.
-- Debounce clock should be approximately 10ms
process
begin
wait until (clock_100Hz'EVENT) AND (clock_100Hz = '1');
SHIFT_PB(2 Downto 0) <= SHIFT_PB(3 Downto 1);
SHIFT_PB(3) <= NOT PB;
If SHIFT_PB(3 Downto 0)="0000" THEN
PB_DEBOUNCED <= '0';
PREVIOUS <= '0';
ELSIF SHIFT_PB(3 Downto 0) = "1111" THEN
PB_DEBOUNCED <= '1';
PREVIOUS <= '1';
ELSE
PB_DEBOUNCED <= PREVIOUS;
End if;
end process;
end a;

Well, here is how another professional logic designer would code this
circuit:
library IEEE;
use IEEE.STD_LOGIC_1164.all;
ENTITY debounce IS
PORT(pb, clock_100Hz : IN STD_LOGIC;
pb_debounced : OUT STD_LOGIC);
END ENTITY;
ARCHITECTURE a OF debounce IS
SIGNAL SHIFT_PB : STD_LOGIC_VECTOR(3 DOWNTO 0);
BEGIN
-- Debounce Button: Filters out mechanical switch bounce for around
40Ms.
-- Debounce clock should be approximately 10ms
process
begin
wait until rising_edge(clock_100Hz);
SHIFT_PB <= NOT PB & SHIFT_PB(3 Downto 1);
If SHIFT_PB="0000" THEN
PB_DEBOUNCED <= '0';
ELSIF SHIFT_PB = "1111" THEN
PB_DEBOUNCED <= '1';
End if;
end process;
END ARCHITECTURE;

This circuit doesn't do any arithmetic so you don't need
STD_LOGIC_ARITH, STD_LOGIC_UNSIGNED or numeric_std packages.
Click to expand...

Yes, if this circuit stands alone, that is true. But it is likely part
of a larger circuit.


The PREVIOUS signal is superfluous.
There is no problem with using a single WAIT statement in a clocked
process. I have many multi-million-gate ASICs in the field where much
of the logic is coded that way. (Different designers have different
preferences/habits.)
Click to expand...

I don't think anyone said coding a wait statement would cause
"problems", at least not with the synthesis. But it is harder to code
with a reset. The wait statement replaces the sensitivity list and the
IF statement. To add a reset you have to include the reset in the
sensitivity list and also use an IF, so you are back to the conventional
method. So what is the point of using such an unconventional style?
Few books promote it and support for it in tools in question since I
have never seen it in the vendor's recommended code.


This circuit doesn't really need a reset. After 4 clock cycles SHIFT_PB
will be in whatever state PB is in. PB_DEBOUNCED will be undefined for
a few clock cycles until PB settles down; but, so what?
Click to expand...

So what is it doing while settling? If it powers up as all 1's when the
input is actually at 0 (or the inverse) at the start it may well see an
edge that is not there and put following logic into an unexpected state.
If nothing else, PB_DEBOUNCED needs to be reset to the appropriate
state.

--

Rick
 
"rickman" <gnuarm@gmail.com> wrote in message
news:n67mle$adf$1@dont-email.me...
There is no problem with using a single WAIT statement in a clocked
process. I have many multi-million-gate ASICs in the field where
much
of the logic is coded that way. (Different designers have different
preferences/habits.)

I don't think anyone said coding a wait statement would cause
"problems", at least not with the synthesis. But it is harder to code
with a reset. The wait statement replaces the sensitivity list and
the IF statement. To add a reset you have to include the reset in the
sensitivity list and also use an IF, so you are back to the
conventional method.
Click to expand...
That is true only if you are using an asynchronous reset. I discourage
young designers from using asynchronous resets and explain that they
should be used only when you need to reset a latch when the clock isn't
running. Otherwise, use a synchronous reset. A synchronous reset
shouldn't be in the sensitivity list. If you later decide that a latch
needs to be reset, just add an "if" statement to the clocked process.
There is no need to rewrite how the process is structured.
wait until rising_edge(clk);
if reset='1' then
latch <= '0';
else
latch <= next_state;
end if;

So what is the point of using such an unconventional style? Few books
promote it and support for it in tools in question since I have never
seen it in the vendor's recommended code.
Click to expand...
I guess conventional vs. unconventional depends on what you're used to
seeing.
The "wait until rising_edge(clk)" construct is well-documented as a way
of coding an edge-triggered latch.


This circuit doesn't really need a reset. After 4 clock cycles
SHIFT_PB
will be in whatever state PB is in. PB_DEBOUNCED will be undefined
for
a few clock cycles until PB settles down; but, so what?

So what is it doing while settling? If it powers up as all 1's when
the input is actually at 0 (or the inverse) at the start it may well
see an edge that is not there and put following logic into an
unexpected state. If nothing else, PB_DEBOUNCED needs to be reset to
the appropriate state.
Click to expand...
And what would the "appropriate state" be? Probably whatever state the
input is at currently. Normally, a circuit that is just sitting there
continuously sampling an input signal doesn't need to be reset, just let
it latch the input continuously.
In the case of this switch debouncer, the downstream logic is probably
being held reset until things settle down during power-on so there is
probably no reason for resetting the debouncer itself.

Charles Bailey
 
On 1/2/2016 10:19 AM, tuclogicguy wrote:
"rickman" <gnuarm@gmail.com> wrote in message
news:n67mle$adf$1@dont-email.me...
There is no problem with using a single WAIT statement in a clocked
process. I have many multi-million-gate ASICs in the field where
much
of the logic is coded that way. (Different designers have different
preferences/habits.)

I don't think anyone said coding a wait statement would cause
"problems", at least not with the synthesis. But it is harder to code
with a reset. The wait statement replaces the sensitivity list and
the IF statement. To add a reset you have to include the reset in the
sensitivity list and also use an IF, so you are back to the
conventional method.
That is true only if you are using an asynchronous reset. I discourage
young designers from using asynchronous resets and explain that they
should be used only when you need to reset a latch when the clock isn't
running. Otherwise, use a synchronous reset. A synchronous reset
shouldn't be in the sensitivity list. If you later decide that a latch
needs to be reset, just add an "if" statement to the clocked process.
There is no need to rewrite how the process is structured.
wait until rising_edge(clk);
if reset='1' then
latch <= '0';
else
latch <= next_state;
end if;
Click to expand...

I think that is bad advice. Rather than encourage a blanket reset that
wastes resources in inefficient ways, I think users should learn to use
the built in async reset in FPGAs properly. In some critical
applications an async reset is required since the clock may not be
running and a failsafe is needed to shutdown outputs in all cases.

I only use a sync reset when it is needed to assure proper startup at
the end of the async reset.


So what is the point of using such an unconventional style? Few books
promote it and support for it in tools in question since I have never
seen it in the vendor's recommended code.
I guess conventional vs. unconventional depends on what you're used to
seeing.
The "wait until rising_edge(clk)" construct is well-documented as a way
of coding an edge-triggered latch.
Click to expand...

Obviously we can argue this all day, but I have not seen a register
described using a wait statement in a single book on VHDL. Not once in
20 years. How many books show this method?


This circuit doesn't really need a reset. After 4 clock cycles
SHIFT_PB
will be in whatever state PB is in. PB_DEBOUNCED will be undefined
for
a few clock cycles until PB settles down; but, so what?

So what is it doing while settling? If it powers up as all 1's when
the input is actually at 0 (or the inverse) at the start it may well
see an edge that is not there and put following logic into an
unexpected state. If nothing else, PB_DEBOUNCED needs to be reset to
the appropriate state.
And what would the "appropriate state" be? Probably whatever state the
input is at currently. Normally, a circuit that is just sitting there
continuously sampling an input signal doesn't need to be reset, just let
it latch the input continuously.
In the case of this switch debouncer, the downstream logic is probably
being held reset until things settle down during power-on so there is
probably no reason for resetting the debouncer itself.
Click to expand...

"Probably"???

The appropriate state for PB_DEBOUNCED depends on how it is used in the
design. If the quiescent state is a 1 then default it to a 1.

--

Rick
 
"rickman" <gnuarm@gmail.com> wrote in message
news:n68rv6$otg$1@dont-email.me...
On 1/2/2016 10:19 AM, tuclogicguy wrote:
"rickman" <gnuarm@gmail.com> wrote in message
news:n67mle$adf$1@dont-email.me...
There is no problem with using a single WAIT statement in a clocked
process. I have many multi-million-gate ASICs in the field where
much
of the logic is coded that way. (Different designers have
different
preferences/habits.)

I don't think anyone said coding a wait statement would cause
"problems", at least not with the synthesis. But it is harder to
code
with a reset. The wait statement replaces the sensitivity list and
the IF statement. To add a reset you have to include the reset in
the
sensitivity list and also use an IF, so you are back to the
conventional method.
That is true only if you are using an asynchronous reset. I
discourage
young designers from using asynchronous resets and explain that they
should be used only when you need to reset a latch when the clock
isn't
running. Otherwise, use a synchronous reset. A synchronous reset
shouldn't be in the sensitivity list. If you later decide that a
latch
needs to be reset, just add an "if" statement to the clocked process.
There is no need to rewrite how the process is structured.
wait until rising_edge(clk);
if reset='1' then
latch <= '0';
else
latch <= next_state;
end if;

I think that is bad advice. Rather than encourage a blanket reset
that wastes resources in inefficient ways, I think users should learn
to use the built in async reset in FPGAs properly. In some critical
applications an async reset is required since the clock may not be
running and a failsafe is needed to shutdown outputs in all cases.

I only use a sync reset when it is needed to assure proper startup at
the end of the async reset.
Click to expand...
The last FPGA I worked on was a Xilinx Virtex-4. In the Virtex-4 user's
guide there is a fairly lengthy section that discusses synchronous vs.
asynchronous resets. They strongly recommend the use of synchronous
resets wherever possible and go on the explain how synchronous resets
use fewer FPGA resources.

I work mainly with IBM ASICs (now owned by Global Foundaries). I know
for a fact, because I deal with it everyday, that asynchronous resets
cause extra complications in timing analysis that don't exist with
synchronous resets. Also, the use of asynchronous resets causes the
netlist processing tools to insert additional test logic cells that
aren't required with synchronous resets.


So what is the point of using such an unconventional style? Few
books
promote it and support for it in tools in question since I have
never
seen it in the vendor's recommended code.
I guess conventional vs. unconventional depends on what you're used
to
seeing.
The "wait until rising_edge(clk)" construct is well-documented as a
way
of coding an edge-triggered latch.

Obviously we can argue this all day, but I have not seen a register
described using a wait statement in a single book on VHDL. Not once
in 20 years. How many books show this method?
Click to expand...

Lots. Here are a few:
In "The Designer's Guide to VHDL", by Peter J. Ashenden, page 608 (in my
edition), Figure A-1 "Four equivalent models of an edge-triggered
D-flipflop", the
wait until rising _edge(clk);
construct is the 2nd one listed.

Also, back on page 112 of the same book, where the author presents a
model for an edge-triggered flip-flop with asynchronous clear, he
includes this comment:
"If the flipflop did not have the asynchronous clear input, the model
could have used a simple wait statement such as
wait until clk='1';
to trigger on a rising edge."

In "Application-Specific Integrated Circuits", by Michael John Sebastian
Smith, in Chapter 10 VHDL, page 380, the first example given is of a
counter. The author uses a
wait until (Clock = '0');
construct.

Then the author goes into the details of the VHDL language and on page
422, where he describes the VHDL wait statement he says:
"The most common use of the wait statement is to describe synchronous
logic, as in the following model of a D flip-flop:
entity DFF is port (CLK, D : BIT; Q : out BIT); end;
architecture Behave of DFF is
process begin wait until Clk = '1'; Q <= D; end process;
end;
"

Then in section 12.6 VHDL and Logic Synthesis, sub-section 12.6.6
Sequential Logic in VHDL, page 597, it says:
"Sensitivity to an edge implies sequential logic in VHDL. A synthesis
tool can locate edges in VHDL by finding a process statement that has
either:
* no sensitivity list with a "wait until" statement
* a sensitivity list and test for " 'EVENT " plus a specific level
"

In the user's guide for IBM BooleDozer, a logic synthesis tool I used
for many years and still use for some purposes, it describes different
ways that latches (flip-flops) can be inferred by the tool and the "wait
until clk='1';" construct is one of ways listed.


In "HDL Chip Design", by Douglas J. Smith, on page 172, under the
heading "VHDL flip-flop inference", the author gives 4 examples:
Wait until (Clock'event and Clock = '1');
if (Clock'event and Clock = '0') then
wait until rising_edge(Clock);
if falling_edge(Clock) then


Charles Bailey
 
On 1/2/2016 8:59 PM, tuclogicguy wrote:
"rickman" <gnuarm@gmail.com> wrote in message
news:n68rv6$otg$1@dont-email.me...
On 1/2/2016 10:19 AM, tuclogicguy wrote:
"rickman" <gnuarm@gmail.com> wrote in message
news:n67mle$adf$1@dont-email.me...
There is no problem with using a single WAIT statement in a clocked
process. I have many multi-million-gate ASICs in the field where
much
of the logic is coded that way. (Different designers have
different
preferences/habits.)

I don't think anyone said coding a wait statement would cause
"problems", at least not with the synthesis. But it is harder to
code
with a reset. The wait statement replaces the sensitivity list and
the IF statement. To add a reset you have to include the reset in
the
sensitivity list and also use an IF, so you are back to the
conventional method.
That is true only if you are using an asynchronous reset. I
discourage
young designers from using asynchronous resets and explain that they
should be used only when you need to reset a latch when the clock
isn't
running. Otherwise, use a synchronous reset. A synchronous reset
shouldn't be in the sensitivity list. If you later decide that a
latch
needs to be reset, just add an "if" statement to the clocked process.
There is no need to rewrite how the process is structured.
wait until rising_edge(clk);
if reset='1' then
latch <= '0';
else
latch <= next_state;
end if;

I think that is bad advice. Rather than encourage a blanket reset
that wastes resources in inefficient ways, I think users should learn
to use the built in async reset in FPGAs properly. In some critical
applications an async reset is required since the clock may not be
running and a failsafe is needed to shutdown outputs in all cases.

I only use a sync reset when it is needed to assure proper startup at
the end of the async reset.
The last FPGA I worked on was a Xilinx Virtex-4. In the Virtex-4 user's
guide there is a fairly lengthy section that discusses synchronous vs.
asynchronous resets. They strongly recommend the use of synchronous
resets wherever possible and go on the explain how synchronous resets
use fewer FPGA resources.
Click to expand...

The chip wide global reset has a dedicated route in every Xilinx chip I
have ever worked with, not that this is all of them. A common reset
across the design is typically implemented using this global reset. If
you don't use an async reset, this resource is wasted. So clearly the
synchronous reset would use more resources.


I work mainly with IBM ASICs (now owned by Global Foundaries). I know
for a fact, because I deal with it everyday, that asynchronous resets
cause extra complications in timing analysis that don't exist with
synchronous resets. Also, the use of asynchronous resets causes the
netlist processing tools to insert additional test logic cells that
aren't required with synchronous resets.
Click to expand...

My comments were aimed at FPGA usage.


So what is the point of using such an unconventional style? Few
books
promote it and support for it in tools in question since I have
never
seen it in the vendor's recommended code.
I guess conventional vs. unconventional depends on what you're used
to
seeing.
The "wait until rising_edge(clk)" construct is well-documented as a
way
of coding an edge-triggered latch.

Obviously we can argue this all day, but I have not seen a register
described using a wait statement in a single book on VHDL. Not once
in 20 years. How many books show this method?

Lots. Here are a few:
In "The Designer's Guide to VHDL", by Peter J. Ashenden, page 608 (in my
edition), Figure A-1 "Four equivalent models of an edge-triggered
D-flipflop", the
wait until rising _edge(clk);
construct is the 2nd one listed.
Click to expand...

I think I have that one, I'll check when I get home. Even if it is
mentioned on one page, what does he show in all the actual examples of
registered logic through the book?


Also, back on page 112 of the same book, where the author presents a
model for an edge-triggered flip-flop with asynchronous clear, he
includes this comment:
"If the flipflop did not have the asynchronous clear input, the model
could have used a simple wait statement such as
wait until clk='1';
to trigger on a rising edge."

In "Application-Specific Integrated Circuits", by Michael John Sebastian
Smith, in Chapter 10 VHDL, page 380, the first example given is of a
counter. The author uses a
wait until (Clock = '0');
construct.

Then the author goes into the details of the VHDL language and on page
422, where he describes the VHDL wait statement he says:
"The most common use of the wait statement is to describe synchronous
logic, as in the following model of a D flip-flop:
entity DFF is port (CLK, D : BIT; Q : out BIT); end;
architecture Behave of DFF is
process begin wait until Clk = '1'; Q <= D; end process;
end;
"

Then in section 12.6 VHDL and Logic Synthesis, sub-section 12.6.6
Sequential Logic in VHDL, page 597, it says:
"Sensitivity to an edge implies sequential logic in VHDL. A synthesis
tool can locate edges in VHDL by finding a process statement that has
either:
* no sensitivity list with a "wait until" statement
* a sensitivity list and test for " 'EVENT " plus a specific level
"

In the user's guide for IBM BooleDozer, a logic synthesis tool I used
for many years and still use for some purposes, it describes different
ways that latches (flip-flops) can be inferred by the tool and the "wait
until clk='1';" construct is one of ways listed.


In "HDL Chip Design", by Douglas J. Smith, on page 172, under the
heading "VHDL flip-flop inference", the author gives 4 examples:
Wait until (Clock'event and Clock = '1');
if (Clock'event and Clock = '0') then
wait until rising_edge(Clock);
if falling_edge(Clock) then
Click to expand...

Ok, so it is included in books for completeness. Do you see any books
where it is used consistently through the book in most examples?

--

Rick
 
On Sun, 03 Jan 2016 03:20:40 -0500, rickman wrote:

On 1/2/2016 8:59 PM, tuclogicguy wrote:
"rickman" <gnuarm@gmail.com> wrote in message
news:n68rv6$otg$1@dont-email.me...
On 1/2/2016 10:19 AM, tuclogicguy wrote:
"rickman" <gnuarm@gmail.com> wrote in message
news:n67mle$adf$1@dont-email.me...
There is no problem with using a single WAIT statement in a clocked
process. I have many multi-million-gate ASICs in the field where
much of the logic is coded that way. (Different designers have
different preferences/habits.)

I don't think anyone said coding a wait statement would cause
"problems", at least not with the synthesis. But it is harder to
code with a reset. The wait statement replaces the sensitivity list
and the IF statement. To add a reset you have to include the reset
in the sensitivity list and also use an IF, so you are back to the
conventional method.
That is true only if you are using an asynchronous reset. I
discourage young designers from using asynchronous resets and explain
that they should be used only when you need to reset a latch when the
clock isn't running. Otherwise, use a synchronous reset. A
synchronous reset shouldn't be in the sensitivity list. If you later
decide that a latch needs to be reset, just add an "if" statement to
the clocked process.
There is no need to rewrite how the process is structured.
wait until rising_edge(clk);
if reset='1' then
latch <= '0';
else
latch <= next_state;
end if;

I think that is bad advice. Rather than encourage a blanket reset
that wastes resources in inefficient ways, I think users should learn
to use the built in async reset in FPGAs properly. In some critical
applications an async reset is required since the clock may not be
running and a failsafe is needed to shutdown outputs in all cases.

I only use a sync reset when it is needed to assure proper startup at
the end of the async reset.
The last FPGA I worked on was a Xilinx Virtex-4. In the Virtex-4
user's guide there is a fairly lengthy section that discusses
synchronous vs. asynchronous resets. They strongly recommend the use
of synchronous resets wherever possible and go on the explain how
synchronous resets use fewer FPGA resources.

The chip wide global reset has a dedicated route in every Xilinx chip I
have ever worked with, not that this is all of them. A common reset
across the design is typically implemented using this global reset. If
you don't use an async reset, this resource is wasted. So clearly the
synchronous reset would use more resources.
Click to expand...

Lurkers might be interested in reading Xilinx WP272.

"... applying a global reset to your FPGA designs is not a very good
idea and should be avoided"

This came in with (I think) Virtex 4. In design guides for earlier
families (e.g. up to Virtex 2 Pro) use of the global reset was
recommended.


http://www.xilinx.com/support/documentation/white_papers/wp272.pdf

There is also an XCELL article called "How do I reset my FPGA?" that is
worth reading.

Regards,
Allan
 
On 1/3/2016 9:09 AM, Allan Herriman wrote:
On Sun, 03 Jan 2016 03:20:40 -0500, rickman wrote:

On 1/2/2016 8:59 PM, tuclogicguy wrote:
"rickman" <gnuarm@gmail.com> wrote in message
news:n68rv6$otg$1@dont-email.me...
On 1/2/2016 10:19 AM, tuclogicguy wrote:
"rickman" <gnuarm@gmail.com> wrote in message
news:n67mle$adf$1@dont-email.me...
There is no problem with using a single WAIT statement in a clocked
process. I have many multi-million-gate ASICs in the field where
much of the logic is coded that way. (Different designers have
different preferences/habits.)

I don't think anyone said coding a wait statement would cause
"problems", at least not with the synthesis. But it is harder to
code with a reset. The wait statement replaces the sensitivity list
and the IF statement. To add a reset you have to include the reset
in the sensitivity list and also use an IF, so you are back to the
conventional method.
That is true only if you are using an asynchronous reset. I
discourage young designers from using asynchronous resets and explain
that they should be used only when you need to reset a latch when the
clock isn't running. Otherwise, use a synchronous reset. A
synchronous reset shouldn't be in the sensitivity list. If you later
decide that a latch needs to be reset, just add an "if" statement to
the clocked process.
There is no need to rewrite how the process is structured.
wait until rising_edge(clk);
if reset='1' then
latch <= '0';
else
latch <= next_state;
end if;

I think that is bad advice. Rather than encourage a blanket reset
that wastes resources in inefficient ways, I think users should learn
to use the built in async reset in FPGAs properly. In some critical
applications an async reset is required since the clock may not be
running and a failsafe is needed to shutdown outputs in all cases.

I only use a sync reset when it is needed to assure proper startup at
the end of the async reset.
The last FPGA I worked on was a Xilinx Virtex-4. In the Virtex-4
user's guide there is a fairly lengthy section that discusses
synchronous vs. asynchronous resets. They strongly recommend the use
of synchronous resets wherever possible and go on the explain how
synchronous resets use fewer FPGA resources.

The chip wide global reset has a dedicated route in every Xilinx chip I
have ever worked with, not that this is all of them. A common reset
across the design is typically implemented using this global reset. If
you don't use an async reset, this resource is wasted. So clearly the
synchronous reset would use more resources.


Lurkers might be interested in reading Xilinx WP272.

"... applying a global reset to your FPGA designs is not a very good
idea and should be avoided"

This came in with (I think) Virtex 4. In design guides for earlier
families (e.g. up to Virtex 2 Pro) use of the global reset was
recommended.


http://www.xilinx.com/support/documentation/white_papers/wp272.pdf

There is also an XCELL article called "How do I reset my FPGA?" that is
worth reading.
Click to expand...

Apples and Oranges. Xilinx is saying adding yet another global async
reset is a bad idea. App note 272 says,

When a Xilinx FPGA is configured or reconfigured, every cell is
initialized (Figure 6). This is the ultimate in master reset because
it covers far more than simple flip-flops. Configuration has the same
effect as a global reset, but it also initializes all RAM cells.


So clearly they are advocating the use of the built in Global Set/Reset
(GSR) which is activated at the end of configuration and can also be
activated by an external signal is desired. This is what I recommend
along with appropriate logic to make sure the async timing of the end of
GSR results in FSMs, counters, etc. starting up properly. The Xilins
app note shows this under the heading, "Strategy for the 0.01% of Cases".

The Xilinx paper goes on to explain the waste of resources when a global
reset is constructed from the fabric which includes both an async or
sync reset.

The app note falls short though by not giving example code for using the
global reset to initialize logic, but instead indicating this is somehow
"automatic". "There is no requirement to insert a reset for simulation
because nothing will be undefined." This is not true unless you code it
in or the simulator defaults to initial values ('0', '1') like your
chip, which I"m pretty sure none do. I suppose a post layout simulation
might do that, but not a pre-systhesis simulation.

--

Rick
 
Am Donnerstag, 17. Dezember 2015 21:29:27 UTC+1 schrieb disturb...@gmail.com:
> SIGNAL SHIFT_PB : STD_LOGIC_VECTOR(3 DOWNTO 0);

Declare this signal as a state and draw a complete bubble diagram for the code below. Eg (SHIFT_PB="0000") with PB=1 go to (SHIFT_PB=1000) else stay in that state.

Show your professor that buble diagram and tell him, the code itself is already a FSM, just not the best FSM for debouncing, but this is neither your fault, nor does he explicite ask you to write a better state machine for debouncing, as it is not clear, if there is a reason for having the output high for an additional clock cycle when the output and he writes "seems to be at least sicteen
states".

Else I agree with Rickman.

If you want a ++ mark draw a similar diagram with combination of PBDEBOUNCED, PREVIOUS and SHIFT_PB to show your prof that there are theoretically states that lead to different behavior but are not reachable e.g. (PB_SHIFT=1100 & PBDEBOUNCED=0 & PREVIOUS=1) would lead to an different output as the minimal FSM, but there is no explicite path to this state or similar states. A minimal FSM will deal with 16 states and on the bubble diagram level it is irrelevant if output is delayed by one clock cycle or not.

regards Thomas
 
IEEE STD 1076.6-2004 (IEEE STANDARD FOR VHDL REGISTER TRANSFER LEVEL SYNTHESIS), Section 6.1.2 Clock Edge Specification, requires both a level and an event part for the clock specification. Thus either clock'event or not clock'stable is required.

Many synthesis tools may support non-standard clock edge specifitions with no event part, but such descriptions are not portable and certainly should not be recommended.

Note that the IEEE standard rising_edge() and falling_edge() functions include both level and edge conditions, as well as strength stripping and verification of the previous value before the event and the value after (at) the event.

Wait statements, with appropriate expressions, are allowed by the standard. However, they tend to be less handy when asynchronous resets are used/required.

Also, an asynchronously reset register can be inferred from a concurrent assignment (again, in the standard):

q <= '0' when reset = '1' else d when rising_edge(clock);

It is not nearly as clean if you want a synchronously reset register...

Almost all of our projects require initialized outputs even without a clock.

Andy
 
On 1/4/2016 2:35 PM, Andy wrote:
IEEE STD 1076.6-2004 (IEEE STANDARD FOR VHDL REGISTER TRANSFER LEVEL
SYNTHESIS), Section 6.1.2 Clock Edge Specification, requires both a
level and an event part for the clock specification. Thus either
clock'event or not clock'stable is required.
Click to expand...

In a process the clock will be in the sensitivity list. So technically,
doesn't that imply an event any time the process runs?

--

Rick
 
On Monday, January 4, 2016 at 2:01:27 PM UTC-6, rickman wrote:
Rick,

In VHDL, every process is run once at time 0, delta 0, regardless of the sensitivity list.

Thus, even in a clocked process with only the clock in the sensitivity list, it the clock condition does not include the event part, then such a process will run as if clock edge had occurred (if the clock is already '1' at T0,d0).

That may not be how the hardware would behave, and result in simulation mismatches between gate & RTL, or real HW & RTL.

Wait statements are not fooled, nor are if statements if they include the event part.

And if asynchronous reset is used (and reset is in the sensitivity list), then the clock if-statement may evaluate true if there was an event on reset (like a falling edge), while the clock was (already) '1', thus erroneously behaving as if a clock edge was present.

To be safe, and not have different clock-edge-detection conditions for both synchronously and asynchronously reset registers, just include the edge part all the time. And rising_edge()/falling_edge() provide that for you in a much more readable manner.

Andy

On 1/4/2016 2:35 PM, Andy wrote:

IEEE STD 1076.6-2004 (IEEE STANDARD FOR VHDL REGISTER TRANSFER LEVEL
SYNTHESIS), Section 6.1.2 Clock Edge Specification, requires both a
level and an event part for the clock specification. Thus either
clock'event or not clock'stable is required.

In a process the clock will be in the sensitivity list. So technically,
doesn't that imply an event any time the process runs?

--

Rick
Click to expand...
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top