[alexadmin 0]

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

[Golikov 0]

если автомат асинхронный и меняется по изменению сигналов без клока, то 2 триггера на входе не помогут, еще дребезг надо устранять да и кучу всего делать, почему в автомате нет клока?

[tdocs.su 0]

Так до сих пор и не разобрались? Обаме бы ваши проблемы... :08:

[Golikov 0]

в своем автомате я уже разобрался, тут кто-то еще присоединился к теме, сейчас речь про него.

 

По моим вопросам все просто. Есть настройка безопасно имплиментировать автомат или нет. Без нее все состояния в который автомат по логике попасть не может будут выкинуты оптимизатором, с ней все состояния в которые автомат по логике попасть не может будут переведены в специальное состояние восстановления работы. Поэтому получается default нужен только в том случае если в него попадают действительно реальные состояния автомата в которые он может перейти, в противном случае он будет либо выкинут, либо состояния будут добавлены и без него.

[des00 25]

я чего-то не понимаю, у вас смена состояний автомат асинхронная что ли, по изменению входных сигналов?

 

если автомат асинхронный и меняется по изменению сигналов без клока, то 2 триггера на входе не помогут, еще дребезг надо устранять да и кучу всего делать, почему в автомате нет клока?

не внимательно читаете код, автомат не асинхронный.

 

Автор использует классическое двухпроцессное описание КА (один процесс регистровая логика, второй комбинационная), правда он еще слишком явно добавил аналог сигнала clock_enable в регистровую часть.

 

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

 

[Golikov 0]

а понятно...

 

что это ФТДИ понятно из комментария в начале автомата)

[slkhome 0]

я чего-то не понимаю, у вас смена состояний автомат асинхронная что ли, по изменению входных сигналов?

Смена состояний вообще задумывал синхронную да и описал вроде все именно как для синхронного варианта, тем более что конечный автомат без сихронности рассматривать, думаю, не возможно в дикой природе! Почему вы решили что он асинхронный? Может у меня там на самом деле так написано, но я не догоняю.

 

Я бы все же состояние s31 явно бы описал.

А входные rdy, miosio, miso у Вас асинхронные относительно clk?

Вообще описывал s31 и явно и так как в коде указано, но разницы никакой! Тем более что в вышенаписанных постах рекомендовали использовать и дефолтное условие.

А вот сигналы miosio и miso действительно асинхронные - приходят с наружи от внешней микрухи. Сигнал rdy синхронный, приходит от интерфейсного блочка (компонента), так же написанного на VHDL и прикрученного между этим автоматом и внешней микрухой.

 

если автомат асинхронный и меняется по изменению сигналов без клока, то 2 триггера на входе не помогут, еще дребезг надо устранять да и кучу всего делать, почему в автомате нет клока?

Автомат синхронный по сигралу clk, да еще есть и сигнал се.

 

Так до сих пор и не разобрались? Обаме бы ваши проблемы... :08:

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

 

не внимательно читаете код, автомат не асинхронный.

 

Автор использует классическое двухпроцессное описание КА (один процесс регистровая логика, второй комбинационная), правда он еще слишком явно добавил аналог сигнала clock_enable в регистровую часть.

 

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

Вообще, года 2 назад, когда это все было написано и применялось в первый раз, все было замечательно. Да и сейчас вся информация по интерфейсу передается без искажений, т.е. корректно вырабатываются ЧИП селект, клоки и данные под них для микросхемы ФТДИ, вот только некоторые байты повторяются по нескольку раз, либо выпадают. Т.е. КА перескакивает некотроые состояния напроч, совершенно в хаотичном порядке, или вообще влетает в какие-то левые состояния и виснет.

Написал достаточно много констрейнтов, и авомат стал работать стабильнее - пересатл влетать в неописанные, видимо, состояния, но среди описанных состояний перескакивает всеравно! Что делать вообще ума не приложу.

Описывал этот автомат и через CASE и IF Then - результат один. А без таких простеньких КА более менее законченные не тривиальные устройства не сделать! Всетаки вдимо Абама тут приложился. Да и самое страшное что результат один - независимо от того Альтера это или Ксилинкс. Лет 15 работаю с этими девайсами - а с такой фигней встретился впервые!

Может у кого еще есть какие-нибудь мысли этот счет?? Прошу поделитесь!

Изменено 1 июня, 2014 пользователем slkhome

[iosifk 3]

Написал достаточно много констрейнтов, и авомат стал работать стабильнее - пересатл влетать в неописанные, видимо, состояния, но среди описанных состояний перескакивает всеравно! Что делать вообще ума не приложу.

Обычное дело. Если входной сигнал имеет пологие фронты или дребезг на фронтах, то автомат их чудесно сожрет...

Все дело в том, что за "Лет 15 работаю с этими девайсами" ПЛИСы стали на порядок быстрее. И то, что раньше не воспринималось, то теперь прекрасно ловится...

Смотрите, какие сигналы дают лишние переходы и их фильтруйте небольшим цифровым фильторм...

 

[Golikov 0]

там есть как пишет автор автомата 2 асинхронных сигнала.

miosio и miso

что по ним делается

 

if (miso = '0') then

next_state <= s21;

 

if (miosio = '0') then

next_state <= s31;

 

теперь что будет если это сигнал измениться очень близко к фронту клока?

автомат начнет менять свое состояние, состояние не 1 бит, а несколько. Часть бит к моменту фронта клока смениться, часть еще нет, и по фронту вы обработаете левое состояние...

 

вам обязательно надо синхронизовать эти 2 сигнала с клоком, или работать по их клоку, и синхронизовать результат...

 

 

[slkhome 0]

Обычное дело. Если входной сигнал имеет пологие фронты или дребезг на фронтах, то автомат их чудесно сожрет...

Все дело в том, что за "Лет 15 работаю с этими девайсами" ПЛИСы стали на порядок быстрее. И то, что раньше не воспринималось, то теперь прекрасно ловится...

Смотрите, какие сигналы дают лишние переходы и их фильтруйте небольшим цифровым фильторм...

В том то и дело, что по внешним сигналам КА может перейти дальше по порядку состояний и дойти до проверки сигнала rdy, который синхронный, и по внутренним синхронным сигналам (rdy) он всеравно должен пойти по порядку, т.е. проскочить проверку сигнала rdy он не может ни как, но это происходит (наприме состояния s21 и s22, в которых проверяется только сигнал rdy, синхронный, внутренний сигнал ПЛИС).

[Golikov 0]

if (miso = '0') then

next_state <= s21;

 

спокойно можете попасть куда угодно проскочив 21 состояние, потому что в тот момент когда вы должны были перейти в 21 состояние, вы можете перейти в любое. Для этого достаточно сигналу мисо стать 0 поближе к клоку и все...

[tdocs.su 0]

if (miso = '0') then

next_state <= s21;

 

спокойно можете попасть куда угодно проскочив 21 состояние, потому что в тот момент когда вы должны были перейти в 21 состояние, вы можете перейти в любое. Для этого достаточно сигналу мисо стать 0 поближе к клоку и все...

Ведь русским по белому было сказано, что автоматы ифами не пишутся. Только кейсами. Уж сколько раз твердили миру...

[Golikov 0]

Ведь русским по белому было сказано, что автоматы ифами не пишутся. Только кейсами. Уж сколько раз твердили миру...

 

с чего вдруг? Более того синтезатор можно попросить кейз представлять ифами, ведь нет такой готовой конструкции... Более того эта часть выдрана из контекста, изначально она под кейзом. И смысл ее не в этом, а в том что состояние начинает меняться по изменению miso, а этот сигнал асинхронен к клоку. И если он произойдет очень близко к клоку, то смена может пройти не полная и автомат попадет черти куда

 

например

состояние 7 -- 0111

меняется на 8 1000

все 4 разряда меняются, и этот процесс происходит не одновременно, значит если такая смена начнет происходить близко к клоку, то по клоку может быть защелкнуто любое число от 0 до 15...

 

более того если в исходном автомате даже так окажется что меняется состояние 2 на 3, то есть как бы 1 бит и разночтений быть не может. Так вот нефига,может! Ибо синтезатор (во всяком случае ISE) находит автоматы и меняет номера состояний по своему усмотрению, по коду грея, например, и какой номер в какой переходит один синтезатор знает...

[slkhome 0]

if (miso = '0') then

next_state <= s21;

 

спокойно можете попасть куда угодно проскочив 21 состояние, потому что в тот момент когда вы должны были перейти в 21 состояние, вы можете перейти в любое. Для этого достаточно сигналу мисо стать 0 поближе к клоку и все...

Т.е. даже если есть строчки для дефолта и выше описан синхронный переход в текущее состояние?

process(cur_state, rdy, miso, miosio)

begin

 

next_state <= cur_state;

 

и

 

if rising_edge(clk) then

....

elsif ce = '1' then

----------

cur_state <= next_state;

---------------

[des00 25]

Т.е. даже если есть строчки для дефолта и выше описан синхронный переход в текущее состояние?

улететь может куда угодно, особенно весело смотреть как в one-hot автоматах появляются состояния когда стоит 2-3 единицы