[Flip-fl0p 4]

А Вы всё-же попробуйте описать FSM в нескольких процессах. Уверен, что скорее всего ошибка будет найдена.

[Golikov 0]

Охх... Сейчас я вам скажу в чем ваша беда, вы наверное имеете программную практику.

 

В описании железа надо понимать следующее, когда вы пишите :

 

if(condition) then
  a <= b;
  c <= d;
  e <= f;
end if;

 

 

вы пишите 3 независимых ифа, на самом деле вы написали

 

if(condition) then
  a <= b;
end if;

 

if(condition) then
  c <= d;
end if;

 

if(condition) then
  e <= f;
end if;

 

И надо понимать что эти 3 условия проверяются в разных частях кристалла, то есть в разное время, то есть там реально 3 схемы каждая проверяет свое значение condition, свою копию. Вы думаете что это происходит в один момент, потому что это все по фронту клока, но клок в разных частях схемы происходит в разное время. За синхронными сигналами следит синтезатор, чтобы они дошли до всех частей в то же время что и клок (это упрощенно, но смысл тот же). И создается ощущение что все произошло одновременно. А вот для асинхронных сигналов все не так, за ними никто не следит.

 

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

 

Это не мета-стабильность, это так называемые гонки сигналов, но смысл тот же. Когда вы асинхронный сигнал пропускаете через 2 триггера, он сразу попадает под надзор синтезатор и тот позаботиться чтобы он дошел в тот же клок ко всем приемникам. Осознайте эту штуку и сразу станет легче.

 

вид автомата на схемах реально странный, не знаю почему оно сначала было так, а стало сяк. Могу только предположить что есть какая-то неопределенность со знаком числа. Но как бы то там ни было в нем нет случайной составляющей. Он бы либо работал всегда, либо не работал бы никогда. Любые такие ошибки они алгоритмически определены и должны были повторяться из раза в раз.

 

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

 

 

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

[justontime 0]

Охх... Сейчас я вам скажу в чем ваша беда, вы наверное имеете программную практику.

Ну, давнее программистское прошлое действительно было, но вряд ли оно тут сказывается - я вроде довольно четко понимаю разницу между языком программирования и языком описания аппаратуры. Мало того, вроде мыслю тоже соответствующим образом (как минимум, стараюсь)...

 

В описании железа надо понимать следующее, когда вы пишите :

...

вы пишите 3 независимых ифа, на самом деле вы написали

 

...

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

 

Это не мета-стабильность, это так называемые гонки сигналов, но смысл тот же. Когда вы асинхронный сигнал пропускаете через 2 триггера, он сразу попадает под надзор синтезатор и тот позаботиться чтобы он дошел в тот же клок ко всем приемникам.

Вы книжки, случайно, не пишете ? :) На мой взгляд, это хороший пример практического объяснения теоретических вещей...

 

вид автомата на схемах реально странный, не знаю почему оно сначала было так, а стало сяк. Могу только предположить что есть какая-то неопределенность со знаком числа. Но как бы то там ни было в нем нет случайной составляющей. Он бы либо работал всегда, либо не работал бы никогда. Любые такие ошибки они алгоритмически определены и должны были повторяться из раза в раз.

Это, возможно, самая смущающая меня вещь...

 

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

Блин, мне настолько интересно стало, что попробую сейчас раздобыть плату (от своей я оторван на несколько недель), чтобы проверить практически. Единственное - триггеры оттянут момент запуска передачи байта на два периода тактовой частоты, что даст уменьшение скорости передачи на 25%, но это уже другая история...

 

Добавьте default в кейз, с индикацией ошибки и переходом в идле, это и правило хорошего тона, да и нужная штука.

Имеется ввиду "when others" ? Если да, то я вроде читал в паре мест, что для такой цели others ничего полезного не делает (причину не до конца понял, правда, и не задумывался сильно)...

 

[Golikov 0]

Имеется ввиду "when others" ? Если да, то я вроде читал в паре мест, что для такой цели others ничего полезного не делает (причину не до конца понял, правда, и не задумывался сильно)...

Книжек не пишу, но тут могу рассказать в чем дело.

Когда вы добавляете это состояние вы здорово увеличиваете схему. Например, у вас есть автомат в режиме оне-хот из 3 бит. Ваши допустимые состояния 001, 010, 100. При штатной работе он в других режимах не бывает. Но как только вы добавите default (others) вы сразу добавляете обработку всех остальных комбинаций 011, 101, 110, 111, 000. Причем уже левых, невозможных, состояний больше чем рабочих. И чем длиннее состояние, тем больше перевес.

А дальше у разных фирм разная концепция оптимизации. Допустим ксалинкс без явного указания делать безопасные автоматы выкидывает default, если в ходе работы нет переходов в состояние описанное в дефолте. А при указании использовать безопасное кодирование, сам добавляет default, даже если его не было. Альтера действует иначе, и состояние дефолт по умолчанию не выкидывает, но вроде как и сама не добавляет.

 

Переходы в оне-хот автомате это снять единичку в одном бите и поставить в другом. Лично нарывался на ошибку где из-за гонки сигналов единичка снималась, а другая не ставилась. Состояние становилось 0, и автомат вис. И на альтере за счет дефалта работа восстанавливалась, а на ксалинксе умирало насмерть. Поэтому теперь всегда стараюсь делать дефалт хотя бы с 1 рабочим состоянием под ним (чтобы автомат не повис навсегда и не оптимизировалось как ненужное), а также обязательно добавляю индикацию перехода в это состояние, чтобы понимать что где-то есть ошибка. Без этого выше описанная проблема не была длительное время обнаружена на альтере.

 

уменьшение скорости передачи на 25%, но это уже другая история...

это просто не верное решение проблемы%) На самом деле эта задача решается через FIFO. Данные в него поступают на частоте работы схемы. Внутри фифо делается пересинхронизация на частоту работы SPI. И данные с FIFO выходят на частоте SPI с управляющими сигналами на той же частоте. И в итоге у вас просто задержка начала передачи, а не снижение скорости. В обратную сторону, для принятых данных тоже FIFO, но с обратным частотным переходом.

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

[Flip-fl0p 4]

Не очень уверен как конкретно работает на Altera при описании автоматов конструкция

WHEN OTHERS =>

Есть подозрение что CASE смотрит только на то, что описано в перечисляемых типах.

Например объявлены типы S1, S2, S3, S4. И CASE смотрит только на них. Соответственно и конструкция WHEN OTHERS => работает только тогда, когда какое-то из состояний не описано. И если автомат перейдет в это неописанное состояние, то автомат выполнит переход по условию WHEN OTHERS =>.

Для того, чтобы автомат сам выходил из невозможных состояний в Altera необходимо применять директивы синтезатору:

     
ATTRIBUTE SYN_ENCODING : STRING;                               -- Атрибуты синтеза
ATTRIBUTE SYN_ENCODING OF STATE_MACHINE_TYPE : TYPE IS "SAFE"; -- Для синтеза SAFE машины состояний

UPD

Только-что проверил: если описаны все переходы в состояниях, то в Altera конструкция WHEN OTHERS => значения не имеет. Проверял по максимальной частоте Timequest и по technology map viewer. Никаких изменений конструкция WHEN OTHERS => не вносит.

Изменено 14 июня, 2017 пользователем Flip-fl0p

[Golikov 0]

возможно в альтере по умолчанию включен именно безопасный автомат, потому и others уже учтен изначально.

 

 

[Flip-fl0p 4]

возможно в альтере по умолчанию включен именно безопасный автомат, потому и others уже учтен изначально.

Изначально он выключен. И включается только атрибутами синтеза.

UPD

Хотя я несколько ошибся. Изначально он выключен, и включается как атрибутами синтеза, так и в настройках Quartus.

Изменено 14 июня, 2017 пользователем Flip-fl0p

[_sda 0]

ATTRIBUTE SYN_ENCODING : STRING; -- Атрибуты синтеза

ATTRIBUTE SYN_ENCODING OF STATE_MACHINE_TYPE : TYPE IS "SAFE"; -- Для синтеза SAFE машины состояний[/code]

А откуда Вы взяли этот атрибут? Вроде у Альтеры таких нет.

Altera

[Flip-fl0p 4]

А откуда Вы взяли этот атрибут? Вроде у Альтеры таких нет.

Altera

А я смотрел в готовых Template

 

Так и Вы смотрите другой атрибут. Я то применяю SYN_ENCODING.

Изменено 14 июня, 2017 пользователем Flip-fl0p

[_sda 0]

Ясно, не заметил что атрибут другой.

[Golikov 0]

Изначально он выключен. И включается только атрибутами синтеза.

UPD

Хотя я несколько ошибся. Изначально он выключен, и включается как атрибутами синтеза, так и в настройках Quartus.

И видать в настройках квартуса он как раз по умолчанию включен. А в ISE/Plan-ahead по умолчанию выключен. Или как то так... в целом не важно, главное что оно есть.

[Flip-fl0p 4]

И видать в настройках квартуса он как раз по умолчанию включен. А в ISE/Plan-ahead по умолчанию выключен. Или как то так... в целом не важно, главное что оно есть.

В quartus он по умолчанию выключен. Во всяком случае в моих версиях 13.1 Web edition, и 15.0 Web edition.

Да и судя по Help он везде должен быть по умолчанию выключен: http://quartushelp.altera.com/14.1/mergedP...ate_machine.htm

Так-что если нужна SAFE STATE MACHINE не забывать включать в настройках, или применять атрибуты синтеза.

Вот что пишет altera про автоматы:

You cannot implement a safe state machine by specifying manual recovery logic in your HDL source; the Quartus II software eliminates this logic while optimizing your design.

Изменено 14 июня, 2017 пользователем Flip-fl0p

[Golikov 0]

Видать кто-то включил эту опцию на том злополучном проекте:)

Мне казалось что я читал обратное, там 14.1 или 14.4 вроде был.

 

Ну значит поведение альтеры аналогично ксалинксу. Все оптимизируют несостоятельные дефолты.

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

[justontime 0]

Сколько интересного и практически полезного мне тут понарасказывали, спасибо !

 

А я попробовал засинхронизировать CmdStart, но не совсем классически (через пару триггеров), а просто устанавливать по спаду clk - чтобы к моменту проверки внутри FSM уже прошло половина периода тактовой частоты, и все гарантированно устаканилось. Ну что могу сказать, все вроде заработало...

 

Мало того, сейчас я вспомнил, что какое-то время назад у меня, похоже, была совершенно аналогичная проблема ! Только тогда я не сам писал автомат, а целиком взял готовый контроллер SDRAM (сейчас посмотрел - общий смысл конструкции ну очень похож на мой). И у меня там тоже был аналогичный асинхронный сигнал, и сбой возникал крайне похожим образом. Только тогда я не пытался вникнуть в проблему, а просто методом ненаучного тыка как раз и придумал засинхронизировать сигнал, после чего все заработало. Причем я тогда немного удивился, что это помогло - казалось, что разницы быть не должно. А сейчас благодаря объяснениям здесь картинка начинает складываться вполне логичная...

 

Поутрясаю все в голове, особенно попробую в деталях понять насчет default состояний...

Изменено 15 июня, 2017 пользователем justontime

[Golikov 0]

можно было и по переднему фронту. Так времянке даже легче будет, на распространение сигнала будет 1 такт, а не половина. Сигнал так же попадет под анализ синтезатора.

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

 

Один триггер который щелкает входной сигнал может быть в состоянии 0, 1, или Х - это если неудачно попал фронт. Это состояние рано или поздно свалиться к 1 или 0. И беда что остальные участники схемы смотрят на это состояние и по разному его видят, кто-то может его принять за 0, а кто-то за 1. Поэтому ставят второй триггер, чтобы он принял какое-то решение единолично, а остальные уже работали от него.

 

Вероятность поймать мета-стабильность сильно меньше чем вероятность поймать гонку в исходном примере, поэтому все и заработало. Но природу не обманешь, когда-то и это стрельнет, так что лучше все же 2 триггера.