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

Зачем два триггера?
Второй триггер только для борьбы с возможной один раз в 473 млн. лет метастабильностью первого?
Ну даже если триггер войдёт в состояние метастабильности он всёравно из этого состояния "вывалится" либо в ноль либо в единицу.
Какая мне разница запустится альтера на один такт раньше или позже.


К сожалению мк не может контролировать синхронность работы плисок.
Мк работает на 32 Mhz. Он может лишь определить работают ли они в принципе.
Я был неправ, повторный сброс ничего не даст.


А вот это не могу представить как сделать.
Но в любом случае придётся прошивки менять, а я хочу сохранить текущую.
Поэтому придётся добавлять внешний триггер.
Хочу добавить всего один триггер что-то типа этого 74LVC1G79 и корпус SOT353-1 нравится.(найти бы еще сразу с инверсным входом клока).
А мне говорят что нужно два добавлять.
И я пытаюсь понять зачем два.

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

Уровнем на пине коммутировать сигнал сброса?
Т.е. или сброс поступает на первый или сразу на третий триггер?
Или ещё как?

У Вас снаружи сигнал для состоянии "сброс" какой уровень вырабатывается: ноль или единица? Я бы сразу накидал схемку...

Сброс - активный уровень ноль.
Буду признателен за схемку

Вход у счётчика инверсным не делал, учёл в И-Не.

Оба входа reset делаем с триггером Шмитта, обоим назначаем резистивную подтяжку к питанию.
У "ведущей" плиски внешний сброс подводим на пин reset_master, вход reset_slave_in оставляем просто висеть в воздухе (или, по желанию, цепляем к питанию), выход reset_slave_out тащим к "ведомой" дорожкой.
У "ведомой" вход reset_master оставляем висеть в воздухе (или подключаем к питанию), а на вход reset_slave_in подключаем выход от "ведущей", вывод reset_slave_out оставляем висеть в воздухе.
Таким образом, мы, конечно, теряем в ножках, но выигрываем в идентичности прошивки.
p.s. кстати, Вы знаете, что у Вас на выходах lpm_decoder в моменты переключения счётчика возникают "иголки"? Если их использовать далее без синхронизации, то может быть чёрти-что...

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

Конечно знаю, без синхронизации не использую.
Выходы декодера и дальнейшие производные подключены только на разрешающие входы триггеров.
А clk абсолютно всех триггеров подключены исключительно к одной глобальной входной частоте.
Т.о. я думаю что получил синхронный проект. Вроде работает как задумывал.
Чип "забит" на 96%. Но ноги свободные есть.


Ага, получится как будто два внешних отдельно стоящих триггера.
Только находиться они будут в максе.
Прикольно.

Т.е. вместо того, что бы добавить пару строк verilog кода в прошивку MAX'а вы хотите поставить 2 физических корпуса снаружи
Почему нельзя изменить прошивку?
Это определять должен сам MAX, и сообщать МК, что нужно всех сбросить. Но прошивку в придется конечно дорабатывать
У вас есть незадействованные ножки у MAX'ов? И сколько штук. И сколько ресурсов внутри MAX'ов свободно?
Исходя из этого можно прикинуть как реализовать синхронизацию

Большого опыта работы с альтерой не имею. Языков не знаю. Просто рисую блок-схему.
Любое изменение в проекте приводит к его неработоспособности.
Времени на разбирательство почему так происходит нету.
После очередной компиляции заработало как надо и больше трогать ничего не хочу.

Проблему решил без изменения прошивки и добавления триггеров. Всем спасибо.

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

А вот это очень и очень не хорошо
Вы уверены, что оно 'работает как надо'? Вы тесты (в системе моделирования) делали? А констрейны при синтезе задавали? Если нет, то ваши MAX'ы сломаются в самый неподходящий момент.

Тоже вариант, вполне рабочий. Проверьте только, с какой попытки происходит успешная запись. В 99.999% случаев должно быть с первой же. Если это не так, то что то все же добавить придется

Именно так и получается как правило с первой попытки всё ок.
Для проверки работоспособности сделал наоборот.
Добиваюсь именно не синхронного запуска.
Для увеличения вероятности не синхронного старта подал еще и на вход разрешения внешнего генератора 120MHz тот же сброс.
И считаю количество сбросов.
В 100% случаях в результате наблюдаю не синхронную работу максов.
Количество сбросов как правило 10-20 редко бывает и больше 60.


Результат работы наблюдаю визуально на мониторе.
Пока на двух изделиях всё гуд. Возможно в партии чего и вылезет.
Никакие констрейны при синтезе не задавал.
Не умею этого делать.
Только некоторым группам регистров указал fast output и режим компиляции speed.

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

Ой. Срочно научитесь - это не сложно. В вашем случае хватит пары строк (не знаю, где это прописывается у Alter'ы, сам работаю с Xiinx)
То, что онь работает 'на мониторе' на вашем столе совершенно не показатель. В партии обязательно что нибудь вылезет. Тем более, что вы работаете на довольно высоких (для MAX) частотах.

Поддерживаю Shivers. Там всей логики - от триггера, до триггера. Но в вашем случае есть еще и 2И-НЕ, которое не позволит разместить триггер в IO элементе.