[alexPec 3]

Всем доброго дня.

 

Делаю проект на lattice icecube 2 (чип ice40lp1k). Простой уарт, код приложен. Постоянно дает ошибку приема. На приложенной картинке осциллографом снял выведенные на ноги чипа сигналы входной (uart 230400bps) и сигнал sample, т.е. момент, когда делается выборка бита. Зеленым обвел места, где стейт-машина в состоянии "0" (ожидает старт-бита). В нормальном режиме видно, что когда машина выходит из этого состояния (принят старт-бит) через половину битового периода (в середине бита) делается выборка и проверяется, действительно ли это старт-бит. А вот когда возникает ошибка приема (обведено синим) - выборка (почему-то????) делается через бит после начала старт-бита, и натыкается на "1", и делает вывод что старт-бит неверный. Как по этому коду стейт-машина может выйти из состояния "0" с загрузкой НЕ половины битового периода я своим мозгом уже не понимаю. Грешу на времянки, но судя по отчету (приложен) запас большой - подаю 39МГЦ, он говорит что может и на 63МГц работать. Может не там смотрю?

Хотя с другой стороны в симуляторе алдек все идеально.

В реальности ошибка возникает совсем не обязательно именно в этом месте. Может принять нормально 5-6 пакетов по 8 байт, и никаких ошибок. Может выдать ошибку в другом байте пакета - т.е. ошибки случайные. От чего зависят - не понятно.

Прошивку сначала пробовал на своей плате, потом когда заметил глюки залил в ICEBLINK40, новая демо-плата, включал до этого один раз. Ведет себя один в один. Пришлось только генератор поставить на 39МГЦ.

Частота ошибок зависит от разводки в чипе - добавил на выход пару сигналов - стало реже, еще добавил - стало чаще ошибки выдавать.

Все работает (точнее, не работает ) от одного клока, клок с генератора SG8002 3.3В 39МГц. Никаких переходов между клоковыми доменами. Констрейн делаю только один - на входной клок, файл тоже приложил. В компиляторе он видит входной клок как 39МГц.

 

Может не дописал чего в констрейны?

 

У кого какие мысли? Буду рад любым...

lattice.rar

[SM 0]

Синхронизируйте вход rx:

 

input rxd;

reg rx, rx_ff;
always @(posedge clk)
    {rx, rx_ff} <= {rx_ff, rxd};

 

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

[alexPec 3]

Большое спасибо, SM!!!

 

После синхронизации все стало нормально. Как обычно, дело было не в бобине...

 

Даже стыдно немного, как я такое пропустил :)

 

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

[Dr.Alex 0]

Метастабильность называется.

Неловко конечно поправлять самомго SMа :-))))))))) но метастабильность тут совершенно не при чём. Просто из-за её исчезающе малой вероятности. Надоело слушать как каждый уверяет будто видел метастабильность. Это примерно как акулу на удочку поймать.

А проблема именно в том, о чём и написано в начале вашего поста:: rx используется в разных местах, соответственно задержки до разных триггеров разные, и часто (ЧАСТО!!) бывает, что один триггер зафиксировал текущее состояние rx, а другой - прошлое, и стэйт-машина идёт вразнос.

А убедиться в этом просто (теоретически):: сделать не "двойной" синхронизатор, а всего через один триггер пропустить. И всё по-прежнему будет работать.

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

[SM 0]

А убедиться в этом просто (теоретически):: сделать не "двойной" синхронизатор, а всего через один триггер пропустить. И всё по-прежнему будет работать.

 

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

 

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

[Dr.Alex 0]

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

Об этом и спору нет.

 

это та же метастабильность, только в рамках многобитного регистра целиком, а не в аналоговом смысле этого термина для отдельно взятого триггера.

Такой трактовки метастабильности я не знал, ну да и ладно.

[Timmy 1]

Такой трактовки метастабильности я не знал, ну да и ладно.

По-моему, метастабильностью называется кратковременное неустойчивое зависание выхода триггера в средней точке, вследствие нарушения setup/hold. А случай ТС называется, вроде, гонкой сигналов. То есть фронт rx бежит наперегонки с клоком, и на один триггер прибегает раньше фронта клока, на другой - позже, в результате защёлкивается в разных тактах и логика работы схемы нарушается. При этом setup/hold могут соблюдаться. Вероятность поймать ошибку при гонке сигналов гораздо выше, чем от метастабильности.

[SM 0]

А случай ТС называется, вроде, гонкой сигналов.

 

Чисто в целях пояснения моего понимания терминологии:

 

Как я понимаю терминологию, логические гонки - это процесс возникновения глитчей в комбинаторных и асинхронных схемах в результате задержек распространения сигналов, и не очень применим к синхронным схемам в принципе (ну, разве что, когда логикой клок делается - мультиплексоры клоков, гейтилки, прочие формирователи). Поэтому и применил к данному случаю термин метастабильность, так как:

1) Результат на выходе никак не отличим от случая, когда было физическое состояние метастабильности в ее аналоговом смысле - и так, и сяк, защелкнуто неверное данное.

2) Сбой в любом случае обусловлен нарушением setup или hold времянки по какому-то из путей от внешнего входа "rx" относительно клока clk - или поздно сменилось данное, что хотя бы один из триггеров - конечных точек не успел его защелкнуть, или влетел в метастабильность в аналоговом смысле, или недодержали данное с тем же эффектом.

 

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

 

При этом setup/hold могут соблюдаться.

Но это не этот случай. Защелкивание неверного данного тут обусловлено именно попаданием фронта сигнала rx в окно "tsu...th", когда этот сигнал не имеет права меняться для корректного защелкивания всеми конечными точками. Да, для самих триггеров, отдельно взятых, возможно и выдержались Tsu/Th, а возможно и нет - это никому не известно, но в целом для сигнала rx - было обязательное нарушение либо Tsu, либо Th.