Nick_K

Из всех перечисленных угрожающих факторов первая половина легко отсеивается на этапе производства/верификации конечного устройства. От второй не так легко избавится, но так как ничего не вечно, делайте обязательное ТО с заменой на второй комплект скажем раз в год. И спите себе спокойно ибо Ваша консерватория будет работать по полной программе. В Спартане 6том я точно знаю, что конфигурацию можно перезаливать с проверкой контрольной суммы прошивки. Какова вероятность отказа чтобы и прошивка и контрольное слово изменились опасно одинаково? Думаю не очень)

Собственно да, тут не очевидно. Весь приведённый код - это автоматически сгенерированный враппер в BLOCK DESIGN интерфейсе. собственно то что подключается в конце - это и есть мною написанное IP ядро. Со всеми установками и параметрами (то которое подключается top_component inst). Собственно говоря я то не боюсь. Но проблема в том, что когда я буду перегенерировать BD (команда Generate Block Design) оно всё перезатрёт и опять по-новой. Может есть какой-то нюанс неучтённый, чтобы оно не трогало мой правленный враппер...

Доброго времени суток! Для облегчения жизни при сборке модулей в готовую систему решил сделать свой модуль как отдельное IP ядро с всеми необходимыми настройками параметров, включая размножение внутренних компонентов обработки, которые состоят из входного сигнала, логики+БРАМ, и выходной порт AXI. Всё написано на SystemVerilog и "выходной" порт AXI запихнут в отдельный интерфейс. Правдами и неправдами сумел собрать IP и договорится с bd что это и вправду компонент с AXI шинами (пришлось перегенерировать кучу портов и создать массу ненужных параметров, те которые с ID и USER). Для удобства создал параметр, который говорит сколько внутри размножено модулей и соответственно сколько входных сигналов и выодных AXIшин должно быть прокинуто. С помощью настройки Interface presence указал когда должны появляться порты (коих 32 штуки) по условию ($P_COMPONENT_NUM >N) для входных сигналов и AXI. Входные порты конфигурируются нормально без каких бы то ни было вопросов, все неиспользующиеся подвешиваются на 0. Но вот AXI начинает творить чудеса. BDувидел, что это AXI и что у него сконфигурированы все порты в соответствии с проприетарным интерфейсом "aximm", да вот только он пытается подключить все 32 AXI порта к несуществующим сигналам. В коде интерфейс сгенерированного топ файла IPядра выглядит где-то так: Тут ничего неординароного, а вот дальше генератор пытается создать и подключить все AXI порты: aximm S_AXI_0(); // Порт 0 присутствует assign S_AXI_0.WLAST = s_axi_0_s_axi_wlast; assign S_AXI_0.BREADY = s_axi_0_s_axi_bready; assign S_AXI_0.AWLEN = s_axi_0_s_axi_awlen; ... aximm S_AXI_1(); // Порт 1 присутствует assign S_AXI_1.WLAST = s_axi_1_s_axi_wlast; assign S_AXI_1.BREADY = s_axi_1_s_axi_bready; assign S_AXI_1.AWLEN = s_axi_1_s_axi_awlen; ... aximm S_AXI_2(); // Порт 2 отсутствует (не сконфигурирован) assign S_AXI_2.WLAST = s_axi_2_s_axi_wlast; assign S_AXI_2.BREADY = s_axi_2_s_axi_bready; assign S_AXI_2.AWLEN = s_axi_2_s_axi_awlen; ... aximm S_AXI_3(); // Порт 3 отсутствует (не сконфигурирован) assign S_AXI_3.WLAST = s_axi_3_s_axi_wlast; assign S_AXI_3.BREADY = s_axi_3_s_axi_bready; assign S_AXI_3.AWLEN = s_axi_3_s_axi_awlen; ... // И так все 32 порта из которых реально входит только 2 первых Ну и дальше идёт подключение к моему сгенерированному IP ядру. top_component inst ( .i_clk(i_clk), .s_axi_aclk(s_axi_aclk), .s_axi_aresetn(s_axi_aresetn), .s00_axi_0_s00_axi_araddr(s00_axi_0_s00_axi_araddr), .s00_axi_0_s00_axi_arprot(s00_axi_0_s00_axi_arprot), .s00_axi_0_s00_axi_arready(s00_axi_0_s00_axi_arready), ... // Конфигурация AXI Lite. Здесь всё нормально .S_AXI_0(S_AXI_0), // Подключён существующий порт .S_AXI_1(S_AXI_1), // Подключён существующий порт .S_AXI_2(S_AXI_2), // Подключён несуществующий порт. Который просто объявлен в топе .S_AXI_3(S_AXI_3), // Подключён несуществующий порт. Который просто объявлен в топе ... // И так далее до 31-го порта .i_signal_0(i_signal_0),// Подключён существующий вход .i_signal_1(i_signal_0),// Подключён существующий вход .i_signal_2(1'B0), // Подключён несуществующий вход. Который просто объявлен в топе .i_signal_3(1'B0), // Подключён несуществующий вход. Который просто объявлен в топе ... // И так далее до 31-го порта ); Как избежать такой ситуации? Нужно дополнительно указать какие-то параметры или вручную создать порты AXI? Этот файл генерируется автоматические и Xilinxпредупреждает: // DO NOT MODIFY THIS FILE.

Размножением операций/модулей/памяти/т.д. можно заниматься в любом виде. Хоть троированием на одном кристалле, хоть дублированием на 10 платах. Вопрос для чего это нужно. Как я упоминал - для повышения отказоустойчивости можно в одном кристалле поднять 3 модуля и работать по мажоранте 2 из 3. Но безопасность такого устройства уменьшится неизбежно. И тем более будет ниже, чем реализация на 3 кристаллах с внешним мажоритарным элементом ( в связи с физическими отказами). Поэтому главный вопрос чего Вы пытаетесь добится и зачем. p.s. Когда пытаетесь обратится к кому-то лично пишите через @, а то я бы мог и не увидеть вашего поста, если бы не пересматривал форум каждый день:) @DeadCadDance Тут есть огромный вопрос. Если Вы пихаете ПЛИСину в ядерный реактор или запускаете в космос, тогда и вправду нет смысла. А если у вас эксплуатация в серверной комнате в закрытом помещении, то для повышения отказоустойчивости вполне сгодится. В моей практике было использование троированного канала (2v3), который обрабатывал запросы от человеко-машинного интерфейса и это всё в составе системы обеспечения надёжности (с доказательством безопасности). Никто не жаловался)

А ну в данном случае вопрос снят. Это действительно та ещё проблема.

Впервые вижу такое утверждение. Что значит "пиратчина"? Кто из потребителей готового продукта (если таковы имеются вообще) будет спрашивать как вы залили данные в EEPROM? Может вы на заводе или субподрядчика сразу заказали с подготовленной прошивкой и потом просто впаяли? Где параметр "честности" прошивки? Понимаю ПО, если у вас на конторе только пиратские лицензии на неподдерживаемые чипы или что-то подобное.

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

Честно, не сталкивался с таким. Все временные констрейны прописываю в XDCи не морочу голову. Там (Vivado)есть даже какой-никакой интерфейс, который позволяет с матом напополам прописывать нужные констрейны. По остальным вопросам увы не подскажу. Нужно смотреть нужные констрейны и место применения. В своих проектах я просто обходился асинхронным интерфейсом + логика согласования, поэтому ничего особо и не констрейню

Мы делали систему управления на ЖД транспорте, которая подтверждена соответствующими сертификатами безопасности и отказоустойчивости. В общем как упомянул @Alex сделайте резервирование или дублирование (в зависимости что важнее надёжность или безопасность соответственно) и пользуйте на здоровье. Но вот с системой тестирования - это сложнее. Есть разные техники и алгоритмические решения. Это всё нужно вычитывать и решать как и куда применить. В один пост форума не влезет.

А зачем смотреть OSVVM? Я глядел-глядел, толку ноль. Если есть проектировщик на SV, можно сделать покрытие 100% даже кода на VHDL, там полно фич и инструкций, которые залезут в недри. И не придётся разбираться в непонятном инструменте, которой к тому же не везде поддерживается (в связи с описанием конструкций на VHDL-2008

Вообще вся память на кристалле двухпортовая - не принципиально. Но всё зависит от верхнего автомата. Если у вас есть Управляющий FSM у которого одно положение - приём Маков (самое длительное по времени), но есть и состояния актуализации, перезаписи, другие состояния (минимальные по времени), тогда можно обойтись однопортовой RAM. В противном случае задействуйте 2 порта. Напоминание: с некоторыми оговорками нельзя писать/читать по одной и той же ячейке памяти (да оно вам и не нужно, но возможна коллизия раз в год)

используйте unsigned logic нужной разрядности (да хоть [200:0]) и не будет забот. Вопрос только как оно будет объявление воспринимать (я не пробовал такого). Второй вопрос - это как оно будет в кристалле. Для таких шин данных нужна сильная оптимизация и не исключено что кода. Если конечно кроме фильтра там ещё что-то есть. Так что советую сначала подумать как оно будет в кристалле выглядеть, возможно при правильной оптимизации отпадёт нужда в длинных параметрах

Наоборот проще некуда. При заполнении таблицы актуальности данных сформируйте для каждой записи в таблицу счётчик максимальной величины (к примеру по 4 бита на счётчик) тогда при проходе состояния актуализации декрементируйте все значения на 1, в результате у вас данные устареют на 16 проходе без обновления. Что в RAM, что на распределённой логике - описание раз плюнуть.

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

Это по JTAG в кристал что-ли? Или просто в тестбенче в виртуальной среде? З.Ы. Немного оффтоп, как через SDK посмотреть содержимое памяти, которая подключена к AXI шине? Видел там монитор памяти, но она только для дебага и видимо для внутренней памяти АРМа. Плата Zynq MPSoC