Nick_K

Согласен, погорячился. Не бывает критических безопасных систем с гигагерцовыми клоками. В случае ведения цели или других "военных" вопросов именно термин безопасность отходит на второй план. Там главное безотказность, что можно достичь... десятичным мажоритированием или ещё каким-то интересным резервированием. Там ведь главное, чтобы оно не потерялось, а то что будет сбой (а он скорее всего будет, потому что мир не идеален + противник может использовать системы подавления), так это особо не колышит. Главное восстановить работу "сбойного" узла, до гипотетического появления сбоя на другом узле. Короче говоря это всё демагогия. А вот с точки зрения Вашего этого цикла, то 20 микросекунда - это как-бы и много и в то же время мало. Смотря что нужно достичь, что проверить, где сравнить состояния и т.д. Если это несколько каналов с загруженными Виртексами - то увы этого времени для дублированной системы, не хватит даже для обмена сервисными пакетами или проведения самотестирования, как одно их состояний главного цикла. Тут можно много гадать, но реально, как я понимаю, подойдёт только эксперимент. Реальный с прогоном. А тут таким особо никто не занимается

Если смотреть с точки зрения безопасности, то у Вас ниодна конструкция не сможет синтезоровать 5-ти значную переменную в двоичной логике. И отказы, увы, случаются, но опять же: и вероятность отказа мала и логика предотвращения данного отказа отсутствует в силу принципов работы синтезатора. Поэтому, как говорится "никто никому ничего не должен", но кое-чем в данном контексте можно пренебречь.

Смотря что для Вас typical. В PlanAhead'е (предшественник Вивады) можно было сгенерировать граничный репорт для заданной рабочей температуры. Не критическая, а, к примеру, та же комнатная. Там оно ориентировалось на какие-то таблицы внутренние и считало. Только смысл? Если кристалл обычно работает на одной температуре, но случись какой нежданчик, завсинет логика где-то или подключится много потребителей информации и температура скачкообразно вырастет -> все вычисления на смарку Именно поэтому работники институтов, где изобрели и улучшают PLL до сих пор зарабатывают на хлеб до сих пор.

Значит неиспользуемые состояния триггера enum {ST_IDLE = 0, ST_INIT = 1, ST_ADDR = 2, ST_DATA = 3, ST_CRC8 = 4, ST_PULS = 5} state оптимизируются тестовой средой. В таком случае смело выбрасывайте состояние default но сам кейс сделайте unique. И никаких проблем не будет

У MAX10 на борту есть автогенератор встроенный в PLL. Думаю у Спартана тоже такое должно быть. Искать конкретно в документах для PLL или DCM

Да, можно. Нужно найти enum сигнал с названиями стейтов и фактически поприсваивать ему разные переменные. Обычно enum в SV кодируется десятичными числами от 0, соответственно в Вашем enum {ST_IDLE, ST_INIT ...} state переменные будут закодированы ST_IDLE=0 , ST_INIT=1 и т.д. если присвоить в state 6 и 7 (там вроде бы всего 6 состояний), то должно сработать. Но есть нюансы: интерпретация симулятором может отличаться от синтезируемой конструкции. Тут можно посоветовать только явно указать значения для каждого елемента enum.

Сделайте ваш Кейс unique и выкиньте состояние dafault. Тогда Вы точно никогда не попадёте в него. Вообще default используется для явного кодирования, когда есть регистр на 3 разряда, а кодирует он, к примеру, только 6 значений. Тогда 2 состояния остаются непокрытыми и в случае ошибки, сбоя и т.д. и переходе в эти самые 2 необъявленные состояния, Ваш автомат будет возвращатся в дефолтное состояние. Когда же тип кодирования не задано (часто он one_hot) тогда в регистровом слове все состояния закодированы, а что ненужно, то оптимизированно (по крайней мере так задумывается). Соответственно необходимость в defolt'е отпадает, но прагмы синтексиса не разрешают писать без него.

К переменным, объявленным внутри автоматических функций, у Вас не будет никогда доступа. Ибо они дуструктятся сразу после обращения. С точки зрения объёмов тестирования, лучше пользовать автоматические. А ещё по той причине, что при параллельном вызове одной функции Вы можете увидеть неожиданные результаты. С другой стороны в автоматической функции нельзя переприсваивать переменные (насколько я видел), хотя возможно это просто "фокусы" моего тестового окружения.

Если в вашей лабораторной работе или в другом ТЗ не написано чёрным по белому "используйте неупакованный массив", то кроме как для памяти нигде и никогда не применяйте их. Создайте двухмерный упакованный массив и будет счастье. Для присвоения элемента массива, другому достаточно написать Data_1[0] <= Data_2[1], дальше векторы присвоят я сами (те которые [7:0]). Если будет упакованный массив, то для VHDL достаточно использовать такой же массив с теми же разрядностями (отсюда же и минус неупакованного массива)

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

Но это ведь не синтезируемая конструкция в классическом понимании (оно то синтезирует, но ни регистров ни комбинаторики не даст) Это обычная инверсия шины. То же самое, что: wire [31:0] swap_bits = [0:31] din; Большинство компиляторов этой конструкции не съедят, но фактически это честная конструкция.

@des00 именно это учебник и рекомендует. В самых первых экзамплах. И мы это уже обсуждали в другой теме :-)

А что в схемотехнике понимать под циклом? Огромный мультиплексор со счётчиком включённым на вход выбора порта? Или генерированная конструкция из тучи триггеров с какой-то логикой? Первый вариант в SV нужно так же писать ручками. Второй при правильно объявлении можно через цикл

Ну тут Вы загнули уже. В жизни не видел критических систем с гигагерцовыми клоками. Может на Атомных где-то и то сомневаюсь. Обычно все критические системы отличаются надёжностью и относительно медлительностью по разным причинам, от наличия времени принятия решения, до увеличения срока эксплуатации из-за деградирования. В добавок ко всему, то что Вы упомянули - не критическая система принятия решения. Которая по сути сама обрабатывает данные и сама принимает решения, а всё что извне - это мракобесие и 100% доверия оному нет. Если есть критические внешние устройства - это уже совсем другие дела. Это пол системы, или комплекс по мониторингу, или устройство защиты, или ещё какое-то чудо инженерной мысли, цель которого выявлять, когда включат тумблер и не приведи Маск коефициент дребезга у него будет больше положенного. Упомянутая мною система работает на 100MHz.

У нас всё честно. Есть дублированная система из 2х девайсов. Циклически они запускают полную проверку элементов памяти и комбинаторики (понятное дело, что в алгоритмы проверки с самотестированием). После чего обмениваются полученными результатами (по сути некие дампы). Если один из "братьев" находит несовпадение хотя-бы в одном бите, он переходит в безопасный отказ. Никаких восстановлений, исправлений ошибок и т.п. З.Ы. Забыл добавить, система раз в пол года меняется (железо) на такой же комплект, но после проверки в РЭА. Старый комплект везётся в РЭА, проверяется по новой и возвращается назад как резерв. По сути получается, что система не всё время 24/7 педалила, но комплекты старые остаются и не меняются на другие, соответственно надёжность системи можно оценить в половину времени.