Sequentially syncrhronous

Sorry, Guys. We're not quite done yet with the quadrature encoder. I tried 
to rewrite it as a synchronous process. The behavioral sim shows it working 
as intended. The post-route sim and onboard test don't work. 'debouncing' 
never changes state in the sim. The leds don't sequence when I twist the 
magic knob.

Can someone please look at the following and comment? I suspect it may be a 
mistiming on setting a_prev and b_prev. a_prev and b_prev are the sampled 
states of 'a' and 'b' during the previous clock. The intended function is 
that we test for a change in 'a'. If it's an active-edge change, it updates 
the count according the direction indicated by 'b'. The other edge of 'a' 
simply debounces to skip the noise. The next change in 'b' cancels the 
debounce.

In general, is it always this difficult and fraught with peril? I write 
 >2000 lines/month in C++ with only minor misspelling mishaps. These 50 lines 
have caused me more gray hairs than many whole systems.

Also, is there a way to tell XST to not treat reset as a clock? I haven't 
fully read up on configuration, having spent way too much time on this 
little time waster.

Last, .... is this really worth pursuing? I've been programming for 25 
years, and know that the greatest leassons come after the greatest pain. But 
there's also good pain, and just senseless injury. Is this not a suitable 
first Zen parable to contemplate? I'm goaded forward by the belief that 
there's a good lesson on synchronous systems lurking as the punchline.

(If it matters, the target is a Spartan-3A DSP starter kit board. ISE 10.1 
tools.)

Thanks.
Mike.

=====================================================
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

------------------
entity q_decode is
    Port ( a : in  STD_LOGIC;
           b : in  STD_LOGIC;
           clk : in  STD_LOGIC;
     rst : in  STD_LOGIC;
     leds : out std_logic_vector(7 downto 0));
end q_decode;

architecture Behavioral of q_decode is
 signal debouncing  : STD_LOGIC  := '0';
 signal a_prev, b_prev : STD_LOGIC := '0';
 signal a_start   : STD_LOGIC  := '0';
 signal count : std_logic_vector(3 downto 0) := "1001";
begin
 process (clk, rst, a, b)
 begin
  if (rst = '1') then
   a_start <= a;
   a_prev <= a;
   b_prev <= a;
   debouncing <= '0';
   count <= "0101";
  elsif (clk'event and clk = '1') then
   if (debouncing = '0') then
    if (a /= a_prev) then
     debouncing <= '1';
     if (a /= a_start) then -- active edge of 'a'
      if (b = '1') then
       count <= count + 1;
      else
       count <= count - 1;
      end if;
     end if;
    end if;
   else  -- debouncing = '1'
    if (b /= b_prev) then -- b changed sense in this clock cycle.
     debouncing <= '0';
    end if;
   end if;
   -- save state of encoder pins for next clock cycle.
   a_prev <= a;
   b_prev <= b;
  end if;
 end process;


 with count select
  leds(7 downto 0) <=
   "00000001" when "0000",
   "00000011" when "0001",
   "00000010" when "0010",
   "00000110" when "0011",
   "00000100" when "0100",
   "00001100" when "0101",
   "00001000" when "0110",
   "00011000" when "0111",
   "00010000" when "1000",
   "00110000" when "1001",
   "00100000" when "1010",
   "01000000" when "1100",
   "11000000" when "1101",
   "10000000" when "1110",
   "10000001" when others;

end Behavioral;

On May 28, 6:50=A0am, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> Sorry, Guys. We're not quite done yet with the quadrature encoder. I tried=

> to rewrite it as a synchronous process. The behavioral sim shows it workin=
g
> as intended. The post-route sim and onboard test don't work. 'debouncing'
> never changes state in the sim. The leds don't sequence when I twist the
> magic knob.
>

This is always a symptom of a timing problem.  In your particular case
I suspect the timing of 'a' and 'b' relative to clk is not meeting the
setup/hold time requirements of the device (from your report file).
The signals 'a' and 'b' should be brought into only one flop, the
output of that flop should be fed into a second flop, the output of
that second flop can then be reliably used wherever you currently have
'a' and 'b'.

>
> In general, is it always this difficult and fraught with peril? I write
> =A0>2000 lines/month in C++ with only minor misspelling mishaps. These 50 =
lines
> have caused me more gray hairs than many whole systems.
>

Hardware design (even if written in a software like language such as
VHDL or Verilog) is not the same as software.  You can be well skilled
in the one discipline and at the same time be unskilled in the other.

> Also, is there a way to tell XST to not treat reset as a clock? I haven't
> fully read up on configuration, having spent way too much time on this
> little time waster.

What makes you think that it is using reset as a clock?

>
> Last, .... is this really worth pursuing? I've been programming for 25
> years, and know that the greatest leassons come after the greatest pain. B=
ut
> there's also good pain, and just senseless injury. Is this not a suitable
> first Zen parable to contemplate? I'm goaded forward by the belief that
> there's a good lesson on synchronous systems lurking as the punchline.
>

The punchline might be static timing analysis.  Signals don't just
'happen' when you want them to, you need to guarantee by design that
they arrive at the proper time relative to the clock.

Kevin Jennings

MikeWhy wrote:
> Sorry, Guys. We're not quite done yet with the quadrature encoder. I
> tried to rewrite it as a synchronous process. The behavioral sim shows
> it working as intended. The post-route sim and onboard test don't work.
> 'debouncing' never changes state in the sim. The leds don't sequence
> when I twist the magic knob.

I like Ray's process here:
http://groups.google.com/groups/search?q=quadrature+resolver+single+process
I've added an entity here:
http://mysite.verizon.net/miketreseler/quad_encode.vhd
RTL view looks good, but untested.

> In general, is it always this difficult and fraught with peril? I write
>>2000 lines/month in C++ with only minor misspelling mishaps. These 50
> lines have caused me more gray hairs than many whole systems.

How long did your first significant C++ project take?

  -- Mike Treseler

Instead of posting code and asking us to look at it, why don't you
debug the simulation???  That is what simulations are for.  If you
said it worked in pre and post layout simulation, but failed on real
hardware, then it would be a sticky problem that could justify asking
help.  But if it is failing in simulation, you can dig in and see
exactly why it is failing.

I am very surprised that this is working in pre-layout sim and failing
in post.  That is usually a timing problem and I can't imagine that
you have any timing problems.  Although the synchronization issue that
KJ mentioned is very valid.

To simplify reading your code you might want to break out the
different functions.  Debounce is normally something done separate
from the state machine you are implementing.  So put it in a separate
process and use a separate signal to drive the decoder process. Then
you have a nice clean signal you can look at to see if the debounce
process is working correctly.

I am also not too sure of your decoder algorithm.  It is a bit hard to
read because of the number of indents and the formatting in this
forum, but it looks like nothing is done with b transitions unless
they are preceded by an a transition.  I don't think that is an
optimal approach for a decoder, but maybe this is because you want to
handle higher speeds.  But if you are getting transitions faster than
the bounce settles, I don't think the encoder can be decoded.  So none
of this is clear to me.

Rick

On May 28, 6:50 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> Sorry, Guys. We're not quite done yet with the quadrature encoder. I tried
> to rewrite it as a synchronous process. The behavioral sim shows it working
> as intended. The post-route sim and onboard test don't work. 'debouncing'
> never changes state in the sim. The leds don't sequence when I twist the
> magic knob.
>
> Can someone please look at the following and comment? I suspect it may be a
> mistiming on setting a_prev and b_prev. a_prev and b_prev are the sampled
> states of 'a' and 'b' during the previous clock. The intended function is
> that we test for a change in 'a'. If it's an active-edge change, it updates
> the count according the direction indicated by 'b'. The other edge of 'a'
> simply debounces to skip the noise. The next change in 'b' cancels the
> debounce.
>
> In general, is it always this difficult and fraught with peril? I write
>  >2000 lines/month in C++ with only minor misspelling mishaps. These 50 lines
> have caused me more gray hairs than many whole systems.
>
> Also, is there a way to tell XST to not treat reset as a clock? I haven't
> fully read up on configuration, having spent way too much time on this
> little time waster.
>
> Last, .... is this really worth pursuing? I've been programming for 25
> years, and know that the greatest leassons come after the greatest pain. But
> there's also good pain, and just senseless injury. Is this not a suitable
> first Zen parable to contemplate? I'm goaded forward by the belief that
> there's a good lesson on synchronous systems lurking as the punchline.
>
> (If it matters, the target is a Spartan-3A DSP starter kit board. ISE 10.1
> tools.)
>
> Thanks.
> Mike.
>
> =====================================================
> library IEEE;
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.STD_LOGIC_ARITH.ALL;
> use IEEE.STD_LOGIC_UNSIGNED.ALL;
>
> ------------------
> entity q_decode is
>     Port ( a : in  STD_LOGIC;
>            b : in  STD_LOGIC;
>            clk : in  STD_LOGIC;
>      rst : in  STD_LOGIC;
>      leds : out std_logic_vector(7 downto 0));
> end q_decode;
>
> architecture Behavioral of q_decode is
>  signal debouncing  : STD_LOGIC  := '0';
>  signal a_prev, b_prev : STD_LOGIC := '0';
>  signal a_start   : STD_LOGIC  := '0';
>  signal count : std_logic_vector(3 downto 0) := "1001";
> begin
>  process (clk, rst, a, b)
>  begin
>   if (rst = '1') then
>    a_start <= a;
>    a_prev <= a;
>    b_prev <= a;
>    debouncing <= '0';
>    count <= "0101";
>   elsif (clk'event and clk = '1') then
>    if (debouncing = '0') then
>     if (a /= a_prev) then
>      debouncing <= '1';
>      if (a /= a_start) then -- active edge of 'a'
>       if (b = '1') then
>        count <= count + 1;
>       else
>        count <= count - 1;
>       end if;
>      end if;
>     end if;
>    else  -- debouncing = '1'
>     if (b /= b_prev) then -- b changed sense in this clock cycle.
>      debouncing <= '0';
>     end if;
>    end if;
>    -- save state of encoder pins for next clock cycle.
>    a_prev <= a;
>    b_prev <= b;
>   end if;
>  end process;
>
>  with count select
>   leds(7 downto 0) <=
>    "00000001" when "0000",
>    "00000011" when "0001",
>    "00000010" when "0010",
>    "00000110" when "0011",
>    "00000100" when "0100",
>    "00001100" when "0101",
>    "00001000" when "0110",
>    "00011000" when "0111",
>    "00010000" when "1000",
>    "00110000" when "1001",
>    "00100000" when "1010",
>    "01000000" when "1100",
>    "11000000" when "1101",
>    "10000000" when "1110",
>    "10000001" when others;
>
> end Behavioral;

KJ wrote:
> On May 28, 6:50 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
>> Sorry, Guys. We're not quite done yet with the quadrature encoder. I tried
>> to rewrite it as a synchronous process. The behavioral sim shows it working
>> as intended. The post-route sim and onboard test don't work. 'debouncing'
>> never changes state in the sim. The leds don't sequence when I twist the
>> magic knob.
>>
> 
> This is always a symptom of a timing problem.  In your particular case
> I suspect the timing of 'a' and 'b' relative to clk is not meeting the
> setup/hold time requirements of the device (from your report file).
> The signals 'a' and 'b' should be brought into only one flop, the
> output of that flop should be fed into a second flop, the output of
> that second flop can then be reliably used wherever you currently have
> 'a' and 'b'.

This very well could be a timing issue but another possible cause of 
this could be the writing of simulatable code but not synthesizable 
code.  Looking at the code, I see the signals a and b in the sensitivity 
list of the process which could cause the else statement to get 
evaluated asynchronously in simulation however for synthesis, the 
sensitivity list is likely ignored (generally with a warning) and thus 
processed differently.  I suggest removing the a and b signals from the 
sensitivity list and see if the behavioral simulation still works.  My 
guess is that may reveal your issue however if that does not, then I do 
suggest looking more closely at the synthesis logs as well as timing 
analysis to ensure it is not another synthesis mis-match issue or timing 
issue.


>> In general, is it always this difficult and fraught with peril? I write
>>  >2000 lines/month in C++ with only minor misspelling mishaps. These 50 lines
>> have caused me more gray hairs than many whole systems.
>>
> 
> Hardware design (even if written in a software like language such as
> VHDL or Verilog) is not the same as software.  You can be well skilled
> in the one discipline and at the same time be unskilled in the other.

It is all what you are used to.  I can not write C++ worth a lick so it 
would likely take me a long time to write a program using it however I 
feel I am very proficient with VHDL and Verilog.

>> Also, is there a way to tell XST to not treat reset as a clock? I haven't
>> fully read up on configuration, having spent way too much time on this
>> little time waster.
> 
> What makes you think that it is using reset as a clock?

I imagine you are referring to XST using a global buffer for the reset 
signal.  In general this should not cause any issues and many times can 
be the right thing to do but if you want to go to prevent that behavior, 
tell XST you want an IBUF on the reset signal by adding the following 
attribute:

attribute BUFFER_TYPE : string;
attribute BUFFER_TYPE of rst: signal is "IBUF";

This will force it to use a regular I/O instead of a global buffer.

Hope this helps and do not get too discouraged.  If you are just 
learning, I could also suggest you try Verilog over VHDL.  I am not 
trying to start the holy wars of languages but many do feel it is less 
of a leap from C to Verilog than VHDL.  Again, I am not trying to start 
a language debate so please leave do not let my statement start one.

--  Brian


>> Last, .... is this really worth pursuing? I've been programming for 25
>> years, and know that the greatest leassons come after the greatest pain. But
>> there's also good pain, and just senseless injury. Is this not a suitable
>> first Zen parable to contemplate? I'm goaded forward by the belief that
>> there's a good lesson on synchronous systems lurking as the punchline.
>>
> 
> The punchline might be static timing analysis.  Signals don't just
> 'happen' when you want them to, you need to guarantee by design that
> they arrive at the proper time relative to the clock.
> 
> Kevin Jennings

On May 28, 11:24=A0am, Brian Philofsky
<brian.philofsky@no_xilinx_span.com> wrote:
> KJ wrote:
> > On May 28, 6:50 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
>
> This very well could be a timing issue but another possible cause of
> this could be the writing of simulatable code but not synthesizable
> code. =A0Looking at the code, I see the signals a and b in the sensitivity=

> list of the process which could cause the else statement to get
> evaluated asynchronously in simulation however for synthesis, the
> sensitivity list is likely ignored (generally with a warning) and thus
> processed differently. =A0

Having 'a' and 'b' in the sensitivity list is not the problem.  The
structure of the code is
process(...)
begin
if (rst =3D '1') then
   ...assignements here
elsif (clk'event and clk =3D '1') then
   ...assignements here
end if;
end process;

There are no assignments to anything outside of the if statement.
That if statement is of the form for flops with async presets/resets.
Having 'extra' signals in the sensitivity list will not result in any
difference between simulation and synthesis.  If it does, then contact
the synthesis tool provider and submit a bug report.

KJ
I suggest removing the a and b signals from the
> sensitivity list and see if the behavioral simulation still works. =A0My
> guess is that may reveal your issue however if that does not, then I do
> suggest looking more closely at the synthesis logs as well as timing
> analysis to ensure it is not another synthesis mis-match issue or timing
> issue.
>
> >> In general, is it always this difficult and fraught with peril? I write=

> >> =A0>2000 lines/month in C++ with only minor misspelling mishaps. These =
50 lines
> >> have caused me more gray hairs than many whole systems.
>
> > Hardware design (even if written in a software like language such as
> > VHDL or Verilog) is not the same as software. =A0You can be well skilled=

> > in the one discipline and at the same time be unskilled in the other.
>
> It is all what you are used to. =A0I can not write C++ worth a lick so it
> would likely take me a long time to write a program using it however I
> feel I am very proficient with VHDL and Verilog.
>
> >> Also, is there a way to tell XST to not treat reset as a clock? I haven=
't
> >> fully read up on configuration, having spent way too much time on this
> >> little time waster.
>
> > What makes you think that it is using reset as a clock?
>
> I imagine you are referring to XST using a global buffer for the reset
> signal. =A0In general this should not cause any issues and many times can
> be the right thing to do but if you want to go to prevent that behavior,
> tell XST you want an IBUF on the reset signal by adding the following
> attribute:
>
> attribute BUFFER_TYPE : string;
> attribute BUFFER_TYPE of rst: signal is "IBUF";
>
> This will force it to use a regular I/O instead of a global buffer.
>
> Hope this helps and do not get too discouraged. =A0If you are just
> learning, I could also suggest you try Verilog over VHDL. =A0I am not
> trying to start the holy wars of languages but many do feel it is less
> of a leap from C to Verilog than VHDL. =A0Again, I am not trying to start
> a language debate so please leave do not let my statement start one.
>
> -- =A0Brian
>
>
>
> >> Last, .... is this really worth pursuing? I've been programming for 25
> >> years, and know that the greatest leassons come after the greatest pain=
. But
> >> there's also good pain, and just senseless injury. Is this not a suitab=
le
> >> first Zen parable to contemplate? I'm goaded forward by the belief that=

> >> there's a good lesson on synchronous systems lurking as the punchline.
>
> > The punchline might be static timing analysis. =A0Signals don't just
> > 'happen' when you want them to, you need to guarantee by design that
> > they arrive at the proper time relative to the clock.
>
> > Kevin Jennings- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

"KJ" <kkjennings@sbcglobal.net> wrote in message 
news:148a2566-df59-4dc1-9644-f231a378a9eb@t54g2000hsg.googlegroups.com...
On May 28, 6:50 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> Sorry, Guys. We're not quite done yet with the quadrature encoder. I tried
> to rewrite it as a synchronous process. The behavioral sim shows it 
> working
> as intended. The post-route sim and onboard test don't work. 'debouncing'
> never changes state in the sim. The leds don't sequence when I twist the
> magic knob.
>

This is always a symptom of a timing problem.  In your particular case
I suspect the timing of 'a' and 'b' relative to clk is not meeting the
setup/hold time requirements of the device (from your report file).
The signals 'a' and 'b' should be brought into only one flop, the
output of that flop should be fed into a second flop, the output of
that second flop can then be reliably used wherever you currently have
'a' and 'b'.

===================

'a' and 'b' are driven by a hand turned rotary encoder.

I tried buffering them into flops with concurrent statements, a_next and 
b_next, and used a_next and b_next internally. This caused 'a' and 'b' to 
not get routed at all, along with all logic associated with them. The 
circuit was reduced to only those parts lighting the leds.

>>>>>>>>>>>>>>



> Also, is there a way to tell XST to not treat reset as a clock? I haven't
> fully read up on configuration, having spent way too much time on this
> little time waster.

What makes you think that it is using reset as a clock?

======
The synthesis report:

 Number of GCLKs:                         2  out of     24     8%

...

Clock Information:
------------------
-----------------------------------+------------------------+-------+
Clock Signal                       | Clock buffer(FF name)  | Load  |
-----------------------------------+------------------------+-------+
sys_rst_pin                        | IBUF+BUFG              | 1     |
sys_clk_pin                        | BUFGP                  | 7     |
-----------------------------------+------------------------+-------+

Asynchronous Control Signals Information:
----------------------------------------
-------------------------------------------------------------+---------------------------+-------+
Control Signal                                               | Buffer(FF 
name)           | Load  |
-------------------------------------------------------------+---------------------------+-------+
sys_rst_pin                                                  | IBUF 
| 5     |
Inst_q_decode/a_prev_and0000(Inst_q_decode/a_prev_and00001:O)| 
NONE(Inst_q_decode/b_prev)| 2     |
Inst_q_decode/a_prev_and0001(Inst_q_decode/a_prev_and00011:O)| 
NONE(Inst_q_decode/b_prev)| 2     |
-------------------------------------------------------------+---------------------------+-------+

I suppose if I understood what that said, a_prev_andxxxxx are the cause of 
my difficulties.

"rickman" <gnuarm@gmail.com> wrote in message 
news:357b1d3e-c34e-4ee0-be9d-cb681a4960e3@8g2000hse.googlegroups.com...
> Instead of posting code and asking us to look at it, why don't you
> debug the simulation???  That is what simulations are for.  If you
> said it worked in pre and post layout simulation, but failed on real
> hardware, then it would be a sticky problem that could justify asking
> help.  But if it is failing in simulation, you can dig in and see
> exactly why it is failing.

A fair comment; I often give similar advice.

I removed the rst handling, and now it simulates post-route, but still fails 
in hardware. Could it be the ports? They're configured LVTTL with PULLDOWN. 
The encoder switches are normally-open, grounded, and pulled to VCC when 
they close.

> I am very surprised that this is working in pre-layout sim and failing
> in post.  That is usually a timing problem and I can't imagine that
> you have any timing problems.  Although the synchronization issue that
> KJ mentioned is very valid.

What's really troubling is that something so apparently simple can be 
unstable. I wasn't asking for debug help so much, but help identifying what 
constructs are stable when synthesized and which are prone for trouble. I 
also wasn't expecting trouble.

The synthesis report now says this: "No asynchronous control signals found 
in this design." The only change was to remove rst.

Examining the post-route sim gives no hint where it can be going wrong, or 
what might be borderline. Debounce is a flipflop with clock-enable, 
presumably gated to flop state appropriately. I was concerned about the c-e 
relationship to storing the state for comparison in the next clock cycle, 
but assignment to a_prev and b_prev occur after the clock-enable. It all 
looks as intended.

> To simplify reading your code you might want to break out the
> different functions.  Debounce is normally something done separate
> from the state machine you are implementing.  So put it in a separate
> process and use a separate signal to drive the decoder process. Then
> you have a nice clean signal you can look at to see if the debounce
> process is working correctly.

It turns out that debouncing _is_ the state machine. It drives the counter 
up or down 1 count, which in turn drives the lookup decoder. It was easier, 
and I thought just as clear, to write the single line increment/decrement 
inline.

>
> I am also not too sure of your decoder algorithm.  It is a bit hard to
> read because of the number of indents and the formatting in this
> forum, but it looks like nothing is done with b transitions unless
> they are preceded by an a transition.  I don't think that is an
> optimal approach for a decoder, but maybe this is because you want to
> handle higher speeds.  But if you are getting transitions faster than
> the bounce settles, I don't think the encoder can be decoded.  So none
> of this is clear to me.

On the clock rising edge:
    Check for state change on 'a' if we're not debouncing.
        If 'a' changed state, ignore further changes (debouncing).
        If the change is a rising edge on 'a',
            'b' is the direction of movement.
            Increment or decrement the count accordingly.
    Otherwise, we're already debouncing.
        Clear debounce on the next 'b' change.

It would be more clear to restructure it explicitly as a FSM with the 2 
states. I will do so.

On May 28, 1:12=A0pm, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> "rickman" <gnu...@gmail.com> wrote in message
>
> news:357b1d3e-c34e-4ee0-be9d-cb681a4960e3@8g2000hse.googlegroups.com...
>
> > Instead of posting code and asking us to look at it, why don't you
> > debug the simulation??? =A0That is what simulations are for. =A0If you
> > said it worked in pre and post layout simulation, but failed on real
> > hardware, then it would be a sticky problem that could justify asking
> > help. =A0But if it is failing in simulation, you can dig in and see
> > exactly why it is failing.
>
> A fair comment; I often give similar advice.
>
> I removed the rst handling, and now it simulates post-route, but still fai=
ls
> in hardware. Could it be the ports? They're configured LVTTL with PULLDOWN=
.
> The encoder switches are normally-open, grounded, and pulled to VCC when
> they close.
>
> > I am very surprised that this is working in pre-layout sim and failing
> > in post. =A0That is usually a timing problem and I can't imagine that
> > you have any timing problems. =A0Although the synchronization issue that=

> > KJ mentioned is very valid.
>
> What's really troubling is that something so apparently simple can be
> unstable. I wasn't asking for debug help so much, but help identifying wha=
t
> constructs are stable when synthesized and which are prone for trouble. I
> also wasn't expecting trouble.
>
> The synthesis report now says this: "No asynchronous control signals found=

> in this design." The only change was to remove rst.
>
> Examining the post-route sim gives no hint where it can be going wrong, or=

> what might be borderline. Debounce is a flipflop with clock-enable,
> presumably gated to flop state appropriately. I was concerned about the c-=
e
> relationship to storing the state for comparison in the next clock cycle,
> but assignment to a_prev and b_prev occur after the clock-enable. It all
> looks as intended.
>
> > To simplify reading your code you might want to break out the
> > different functions. =A0Debounce is normally something done separate
> > from the state machine you are implementing. =A0So put it in a separate
> > process and use a separate signal to drive the decoder process. Then
> > you have a nice clean signal you can look at to see if the debounce
> > process is working correctly.
>
> It turns out that debouncing _is_ the state machine. It drives the counter=

> up or down 1 count, which in turn drives the lookup decoder. It was easier=
,
> and I thought just as clear, to write the single line increment/decrement
> inline.
>
>
>
> > I am also not too sure of your decoder algorithm. =A0It is a bit hard to=

> > read because of the number of indents and the formatting in this
> > forum, but it looks like nothing is done with b transitions unless
> > they are preceded by an a transition. =A0I don't think that is an
> > optimal approach for a decoder, but maybe this is because you want to
> > handle higher speeds. =A0But if you are getting transitions faster than
> > the bounce settles, I don't think the encoder can be decoded. =A0So none=

> > of this is clear to me.
>
> On the clock rising edge:
> =A0 =A0 Check for state change on 'a' if we're not debouncing.
> =A0 =A0 =A0 =A0 If 'a' changed state, ignore further changes (debouncing).=

> =A0 =A0 =A0 =A0 If the change is a rising edge on 'a',
> =A0 =A0 =A0 =A0 =A0 =A0 'b' is the direction of movement.
> =A0 =A0 =A0 =A0 =A0 =A0 Increment or decrement the count accordingly.
> =A0 =A0 Otherwise, we're already debouncing.
> =A0 =A0 =A0 =A0 Clear debounce on the next 'b' change.
>
> It would be more clear to restructure it explicitly as a FSM with the 2
> states. I will do so.

Is somebody trying to re-invent the wheel?
Haven't we been through this in a seemingly endless thread?
Didn't I point out two perfect and compact solutions?
How much effort do we intend to waste on such a clearly-defined non-
problem ?
Peter Alfke

"Peter Alfke" <peter@xilinx.com> wrote in message 
news:e3a18ba3-db21-498c-840a-3b36ce73246f@u12g2000prd.googlegroups.com...

> Is somebody trying to re-invent the wheel?

Most likely...but also most likely not in order to invent a better wheel but 
to learn.

> Haven't we been through this in a seemingly endless thread?

Yes

> Didn't I point out two perfect and compact solutions?

Others posted solutions as well, don't take all the credit.

> How much effort do we intend to waste on such a clearly-defined non-
> problem ?

If you feel that you're wasting your time, then perhaps you should choose 
not to do that.

KJ