Нажатие кнопки, Обработка события нажатия кнопки с помощью FPGA Опции

[aBoomest]

Добрый день. Прошу прощения за длинный пост. С ПЛИС работаю не впервые, однако возникла проблема. (причем совершенно неожиданно)
Не могу скомпилировать проект. В проект добавил только одну кнопку.
Написал тестовую программу. Та же ерунда. Итак:
В тестовой программе по нажатию кнопки делаю вкл/выкл светодиод.
ФАЙЛЫ:
UCF

Код

Net "Clock" Loc = "C9" | IOStandard = LVCMOS33;
Net "Led_2" Loc = "F8" | IOStandard = LVTTL | Slew = Slow | Drive = 8;
Net "Btn_Down" Loc = "K17" | IOStandard = LVTTL | PullDown;

VHD

CODE

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity MainBlinkingLed is
port (Clock: in std_logic;
Btn_Down: in std_logic;
Led_2: out std_logic);
end MainBlinkingLed;

architecture Behavioral of MainBlinkingLed is
shared variable Led2: bit := '0';
begin
prcBlnkLed2: process(Clock)
begin
if (Btn_Down = '1') then
Led2 := not(Led2);
end if;
end process prcBlnkLed2;
Led_2 <= '1' when Led2 = '0' else '0';
end Behavioral;

Проект не компилируется. Не проходит процесс Place&Route Пишет, что вывод Clock "не нагружен" и ещё вот это:
ERROR:Place:1018 - A clock IOB / clock component pair have been found that are not placed at an optimal clock IOB /
clock site pair. The clock component <Btn_Down_BUFGP/BUFG> is placed at site <BUFGMUX_X2Y1>. The IO component
<Btn_Down> is placed at site <IPAD93>. This will not allow the use of the fast path between the IO and the Clock
buffer. If this sub optimal condition is acceptable for this design, you may use the CLOCK_DEDICATED_ROUTE constraint
in the .ucf file to demote this message to a WARNING and allow your design to continue. However, the use of this
override is highly discouraged as it may lead to very poor timing results. It is recommended that this error
condition be corrected in the design. A list of all the COMP.PINs used in this clock placement rule is listed below.
These examples can be used directly in the .ucf file to override this clock rule.
< NET "Btn_Down" CLOCK_DEDICATED_ROUTE = FALSE; >

Схема подключения кнопки: подтянута к земле. При нажатии на на вход ПЛИС подается 3.3В (лог '1').
Если в код добавить функцию rising_edge(Clock) перед if-ом, то все компилируется и работает. Но хотелось изначально асинхронный процесс иметь, а тут получается синхронный. На просторах сети таких примеров с асинхронными схемами море: вот например асинхронный сброс триггера.
Ссылка

CODE

library IEEE;
use IEEE.std_logic_1164.all;

entity dff_async_rst is
port (data, clk, reset : in std_logic;
q :out std_logic);
end dff_async_rst;

architecture behav of dff_async_rst is
begin
process (clk, reset) begin
if (reset = '0') then
q <= '0';
elsif (clk'event and clk = '1') then
q <= data;
end if;
end process;
end behav;

Что делаю не так? Описание ucf для таких сигналов должно быть иное? Или еще какие глупости делаю?

[Golikov A.]

Далее - строка Led2 := not(Led2);, стоящая под if подразумевает синтез защелки (как минимум), а для этого нужен реальный клок.

почему оно такое подразумевает если нет clk'event? именно это вроде подразумевает клок...

Схема просто не определена полностью, что будет если Btn_Down != '1'?

Код

if (Btn_Down = '1') then
  Led2 := not(Led2);
else
  Led2 := 0;

и будет обычный элемент "И" на один вход которого подается Btn_Down, и not Led2 на второй его вход. Да схема будет работать как не пойми что, пока нажата кнопка она будет как генератор менять свои значения, и как кнопку отпустят становиться 0. Но если очень надо именно такое, то почему нет?


или же схема вида

Код

if (Btn_Down = '1') then
  Led2 := not(Led2);
else
  Led2 := Led2;

это у нас "исключающее ИЛИ" с одним входом Btn_Down, а на другой подан выход Led2. Да эта схема тоже дрянь, по причине того что пока нажата кнопка оно бешено меняется, а как кнопку отпускает замирает в прошлом состоянии. Но если снова надо, то почему нет?

А вот без else поведение схемы полностью не определено, и поскольку от того что на выходе могут быть разные варианты в зависимости от того что должно быть на выходе если кнопка не 1, то синтезатор и обиделся...

Понятно что вы скорее всего этого не хотели, и хотели чтобы эта схема 1 раз сменила свое состояние когда нажали кнопку, но для этого надо описать это по другому, как раз чтобы кнопка стала клоком для триггера. И нет никакой проблемы если этот сигнал заведен не на клоковую ногу ПЛИС. Надо просто поклясться синтезатору что вы знаете что делаете, и все будет хорошо.... это как раз
< NET "Btn_Down" CLOCK_DEDICATED_ROUTE = FALSE; >.


Ну естественно сигналы что виляют на результат надо внести в список чувствительности (это если по верилоговски выражаться, я так понимаю это типа под процесс в скобки их запихать)


Вот так мне кажется...

П.С. Удивительно что синтезатор тоже понял что вы хотели одной смены состояния леда, и начал городить схему где кнопка - клок, хотя из описания этого явно не следует... может у вас в схеме еще где то есть кнопка'event и это относится к этим местам? Перечитал, более того синтезатор не обижается на схему. Он пишет что вы входной сигнал клока никак не нагрузили, и он просто не знает куда его завести, и что вы клоком кнопку используете, и требует подписки что вы в курсе что она с не клокового контакта и все, ничего более... Но почему он так считает для меня реально загадка...

П.С.С. завод клока с не клоковой ноги грозит тем что сначала сигнал потянуть в ПЛИС до клокового дерева, а потом уже будут использовать как клок. А это выльется в то что будет большая задержка между фронтом на ноге и фронтом внутри плис. И это серьезно просадит тайминг, но более это ничем не грозит.

[Dondob]

Есть другое предложение - ловить фронт, отсчитывать гарантированное время успокоения, и считывать состояние. Просто и не затратно

[gridinp]

Есть другое предложение - ловить фронт, отсчитывать гарантированное время успокоения, и считывать состояние. Просто и не затратно

Лучше счетчик перезапускать в случае когда во время отсчета ещё один фронт пришел, тогда это ещё будет фильтровать наводки на кнопку, например наводку от радиостанции на пленочную клавиатуру