Alexander S. wrote:
> design of Debouncer
Thats that very coding style why people say VHDL is extremly chatty:

1

process (ClockIn ,nResetIn,DebounceClockIn,DataTmp,DataIn)

2

variable DebounceStatus : std_logic_vector(1 downto 0);

3

begin

4

DebounceStatus(0) := DataTmp(0);

5

DebounceStatus(1) := DataTmp(3);

6

 if(nResetIn = '0') then

7

  DataTmp <= (others => '0');         -- Pipe Line

8

 elsif (ClockIn'event and ClockIn = '1') then

9

  case DebounceClockIn is

10

   when '1' =>

11

    DataTmp(0) <= DataIn;

12

    case DebounceStatus is

13

     when "00" =>

14

      DataTmp(2 downto 1) <= (others => '0');

15

     when "11" =>

16

      DataTmp(2 downto 1) <= (others => '1');

17

     when others =>

18

      DataTmp(3 downto 1) <= DataTmp(2 downto 0);

19

    end case;

20

   when others =>

21

    DataTmp <= DataTmp;

22

  end case;

23

 end if;

24

end process  PipeLine_Process;

BTW: there are way to much singals in the sensitivity list of that 
process. ClockIn and nResetIn would be enough, because the process must 
be recalculated by the simulator only when one of those two changes.

I prefer debouncing (and edge detection) with a shift register:
http://www.lothar-miller.de/s9y/archives/3-Tastenentprellung-mit-Schieberegister.html
(use Google translator, its German)
That way I find it much more easy to understand because its less chatty 
and straight forward.
Other ways to debounce are those:
http://www.lothar-miller.de/s9y/categories/5-Entprellung

Lothar M. wrote:

> BTW: there are way to much singals in the sensitivity list of that
> process. ClockIn and nResetIn would be enough, because the process must
> be recalculated by the simulator only when one of those two changes.

You're right .
 It's my old design.

Currently it's preferred to use synchronous Reset.

 Only in the old Quartus version was needed all inputs signals in the 
sensitive list.

 Regards Alex.

Lothar M. wrote:
> Thats that very coding style why people say VHDL is extremly chatty:
> [vhdl]

 But you can control synthesis process for max. speed.

 High level language have optimization by developments system and you 
don't know result.

 Regards alex.

Lothar M. wrote:
> I prefer debouncing (and edge detection) with a shift register:
> 
http://www.lothar-miller.de/s9y/archives/3-Tastenentprellung-mit-Schieberegister.html
> (use Google translator, its German)
> Other ways to debounce are those:
> http://www.lothar-miller.de/s9y/categories/5-Entprellung

 It's nice, but you use only one clock. If general gesign clock is some 
(1 - 50) MHz you can't design debounce for slow signals such as from 
mechanical switches.
 Regards Alex.

Alexander S. wrote:
> If general gesign clock is some (1 - 50) MHz you can't design debounce
> for slow signals such as from mechanical switches.
Have a second look on the code in the link. It includes a prescaler to 
reduce sampling speed.

Lothar M. wrote:
> Alexander S. wrote:

> It includes a prescaler to
> reduce sampling speed.

 Yes , you use additional 14 Bits counter and check it status by high 
system clock for reduce sampling speed.

 For my opinion : It's not good practice for high speed design.

Regards Alex.

Alexander S. wrote:
> Yes , you use additional 14 Bits counter and check it status by high
> system clock for reduce sampling speed.
Of course.
To get down from 50MHz to mechanical speed it simply needs 14 bits. Your 
design must do some similar dividing in real life. Such kind of 
"prescaler" won't work there:
DebounceClock   <= not DebounceClock after 101 nS;

> For my opinion : It's not good practice for high speed design.
Personal opinions doesn't matter in hardware. Synthesize the both 
designs and let the toolchain speak.

> practice for high speed design.
And one thing is for sure: counters are the fastest things you can build 
on FPGAs. There is special hardware for that job on the die (look at the 
carry chain).

Lothar M. wrote:
 Your
> design must do some similar dividing in real life. Such kind of
> "prescaler" won't work there:
> DebounceClock   <= not DebounceClock after 101 nS;

 DebounceClock

DebounceClock   <= not DebounceClock after 101 nS;
Debouncer_Tb.vhd

It's clock for simulation only.

 In the real design you can generate DebounceClock from slow clock which 
usualy present in the your design or generate it from slow clock 
generated by PLL.

 In this case you do not need tuning you Debounce components for each 
design and always use big counter.

 Regards Alex.

Lothar M. wrote:
> Alexander S. wrote:

> Personal opinions doesn't matter in hardware.

 You are right : I did not write it's rule of good practice design for 
high speed design.

> counters are the fastest things you can build
> on FPGAs.

 But it's present rules for design high speed counters and checking it 
states .

 Only if you use hardware components from manufactory library or use 
high speed design rules for design you will have :

fastest things you can build on FPGAs.

 Regards Alex.

Klakx wrote:

> What is your intention with such posts?

 I receive remarks and repair my design.

>
> For online storage github would be more suitable.


 What's : github ?

Alexander S. wrote:
> What's : github ?
https://www.google.com/search?q=github
Its a place you can get your designs into public. If I would paste three 
of the designs on my harddisk a day, then we would have much fun till at 
least next spring. But I don't. Why do you?

Alexander S. wrote:
> Klakx wrote:
>> What is your intention with such posts?
>  I receive remarks and repair my design.
A forum is a place for discussing particular questions and problems. But 
you post your designs without any questions to discuss about nor at 
least a description what the designs should be good for.

Lothar M. wrote:

> A forum is a place for discussing particular questions and problems. But
> you post your designs without any questions to discuss about

 My main question : are my designs according to good practice design and 
VHDL rules ?

nor at
> least a description what the designs should be good for.

 Design good if design work and make it application.

Description of design is the name of design.
If you need additional description you can ask me.

ktorkkelson wrote:
> @Alexander S. you are just a damn chat bot. Stop wasting people's time.
>
> Cheers ;)

  Save your time: you and others (such as you) not required to read my 
posts .

 If Moderator think as you, he can stop my participation in this forum.

Regards Alex.

Alexander S. wrote:
> My main question : are my designs according to good practice design and
> VHDL rules ?
There are no general "VHDL rules".
Or better: the most relevant "VHDL rules" are those in the synthesizers 
user guide.

See https://embdev.net/topic/498013?goto=6303958#6303958 also.

Lothar M. wrote:

> See https://embdev.net/topic/498013?goto=6303958#6303958 also.
 Thanx. I've repaired my design.

 Regards Alex.

Lothar M. wrote:
> Alexander S. wrote:
>> What's : github ?
> https://www.google.com/search?q=github
> Its a place you can get your designs into public.

 If I've understood right, it's for software only : not for hardware 
VHDL place.

 Regards Alex.

Alexander S. wrote:
> If I've understood right, it's for software only : not for hardware VHDL
> place.
Of course you can place hardware projects also:
https://github.com/topics/fpga

Or you can try to host your projects at https://opencores.org/projects