lembrix

Это не ложь, это просто статистика :) К химии и физике эти теоретические параметры надежности отношения не имеют. Наработка на отказ равная 10 млн. часов (1141 год) означает, что если включить одновременно 1141 ПЛИС, то за год работы примерно одна выйдет из строя. И под отказом, вроде как, понимается не сбой, а полный отказ микросхемы.

Странно. Я тоже думаю, что вот эти неактивные интервалы между строками и кадрами (front porch, back porch) допускается менять в определенных пределах. Разумеется pixel clock при этом тоже плавает. Но на параметры изображения это не должно влиять, разрешение и частота кадра остаются постоянными (частота строк может при этом совпадать, а может и нет). Я делал вывод изображения на промышленную матрицу, в спецификации на нее было указаны разрешенные диапазоны для всех этих porch-ей. Например, Vertical front porch: min = 7, recomended = 51, max = 100. Правда, horizontal back porch и vertictal back porch по спецификации менять не разрешалось, они были заданы строго. А по задаче, самое универсальное решение это буфер на весь кадр в DDR-памяти.

Я, если что, тоже только недавно начал осваивать UVM. У меня в конце теста выводится такая сводка каким-то стандартным механизмом: # --- UVM Report Summary --- # # ** Report counts by severity # UVM_INFO : 11 # UVM_WARNING : 6 # UVM_ERROR : 0 # UVM_FATAL : 0 # ** Report counts by id # [DISP] 1 # [Questa UVM] 2 # [RNTST] 1 # [TEST_DONE] 1 # [TPRGED] 6 # [uvm_test_top.env] 4 # [uvm_test_top.env.in_agent.driver] 1 # [uvm_test_top.env.out_agent.driver] 1 # ** Note: $stop : ../vip/tb_top.sv(97) # Time: 260012 ns Iteration: 62 Instance: /tb_top У вас такой нет? Кроме того, вывожу по привычке свой отчет вида "TEST PASSED/FAILED" и какие-то подсчитанные вручную параметры в extract_phase класса конкретного теста.

Для этого используются суффиксы: `uvm_analysis_imp_decl(_TX) `uvm_analysis_imp_decl(_RX) ... uvm_analysis_imp_TX #(uart_item, uart_sb) transmitted; uvm_analysis_imp_RX #(uart_phy, uart_sb) received; ... function void write_TX(...); ... function void write_RX(...); ...

Да, напрямую и с питанием от HDMI. В этой памяти должен содержаться блок данных определенной структуры называемый EDID. Он нужен для PnP и содержит информацию о режимах поддерживаемых монитором. Только нужен какой-то девайс для записи этого EDID по I2C в EEPROM. Сам EDID можно считать из монитора или создать вручную. Есть несколько программ для этого, я использовал Phoenix EDID Designer. Есть еще удобная программа для расшифровки EDID - Monitor Asset Manager (раньше называлась moninfo) от EnTech. Ей можно проверить, что созданный файл корректный. Можно заставить видеокарту выдать сигнал и при отсутствии I2C. Надо лишь в драйвер монитора нужный EDID подсунуть.

И на сегодняшний день есть достаточное количество причин не использовать начальную инициализацию регистров. 1. Только для динамически реконфигурируемых схем, не поддерживается в ASIC. 2. Накладывает ограничение на синтез, такие регистры не могут быть оптимизированы. 3. Использование инициализации вместо сброса ограничивает reuse модуля в других проектах где сброс реально нужен. 4. Нет гарантии поддержки инициализации всеми синтезаторами. 5. В случае использования инициализации вместо сброса нет задержки на время стабилизации клока от PLL 6. В случае использования инициализации вместо сброса нет возможности задержки выхода схемы из сброса. 7. В случае использования инициализации вместо сброса нет возможности сброса схемы в процессе работы 8. Не поддерживается ALTERA Partial Reconfiguration. 9. Стандарты могут требовать сброса в явном виде.

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

Триггер Шмидта не помогает, потому что он от пологих фронтов, когда сигнал плавно меняет свое состояние от "0" до "1". А при дребезге проблема в другом, сигнал достигает полного уровня логической "1" вызывая переключение что обычного входа, что входа с триггером Шмидта, а затем возвращается к уровню логического "0", и так несколько раз.

Я бы попробовал разбить проект таким образом, чтобы можно было верифицировать "медленную" и "быструю" часть независимо друг от друга.

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

Правильным подходом было бы оставить этот вопрос в стороне, и сконцентрироваться на том, как такую ситуацию не допустить.

Так у Альтеры тоже два такта на чтение. По фронту 1 выставил адрес, по фронту 2 адрес защелкивается в обязательном входном регистре блока памяти, по фронту 3 можно забирать данные с выхода. А можно включить регистр выходных данных и тогда будет еще 1 такт задержки. Хотя в тех семействах с которыми я работаю используется только M9K память. В MLAB, кажется, можно отключать регистр по входу адреса и тогда действительно чтение будет в 1 такт.

Завялено требование в 0.5 м, а SPI-flash обычно существенно ближе.

Любую "не тривиальную схему" можно составить из "тривиальных модулей" в альтернативу использования FSM. Не понятна, все таки, логика по которой это написано, или логика по которой это работает? Если первое, то это вопрос стиля кодирования. А если второе, то надо смотреть конкретный код.

Результат то различный, но в обоих случаях не неправильный. Что попросили, то и получили. И вывод и этого примера, как по мне,такой, что не надо использовать "Х". А "if else" можно спокойно использовать и для комбинационных схем.

Ну понятно, для симулятора это разные схемы: (1 | X) = 1, а (o1==1) = FALSE, при o1 =Х . А для синтезатора X означает, что он может оптимизировать схему как ему надо.

Сдается мне, в оригинальном примере где-то присутствовал Х. Но он потерялся, а без него фокуса не получится.

Доводы против использования инициализации регистров вместо сброса: 1. Только для реконфигурируемых схем, ASIC не поддерживается. 2. Нет гарантии поддержки инициализации всеми синтезаторами. 3. Нет возможности сброса схемы в процессе работы. 4. Нет задержки на время стабилизации клока от PLL. 5. Нет возможности задержки выхода схемы из сброса. 6. Не поддерживается ALTERA Partial Reconfiguration. 7. Некоторые стандарты требуют сброса в явном виде.

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

А я вижу в момент спада 5-го бита нормальную работу счетчика, 6-ой бит переключается и все старшие биты ведут себя соответственно счетчику. А тактовый сигнал для signal tap правильный?

Субъективная составляющая может быть такая. Допустим сотрудник сертификационного органа человек ответственный. Посчитает он нормальной проверку глазами миллионов цифр?

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

Modelsim как утилита не может быть сертифицирован. Поддержка DO-254 c его стороны выражается в том, что верификация сделанная с помощью его инструментов формально сертифицируема.

Имеется в виду, два устройства сделанных по одному ТЗ, но разными людьми и на разной элементной базе.

Да ,я уже понял что фигню написал. Он у вас cинхронный с CLOCK, так что это все не надо. Проблема в том, что у вас CLOCK выход PLL, а не порт, поэтому source должен быть [get_pins "соотв. выход PLL"]