lexx

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

Он упоминает jpeg и разные MPEG-и, так что строчка в 8 пикселей, хотя для последних уже 16. Но точно не 0.25мс для всего кадра

В статье 0.25мс это одна строчка пикселей на 1080р 30 fps. На 60Гц как раз 8 энкодер и столько же декодер выйдет. Статья откровенно странная, даже понятия свои автор придумал, выход декодера DPB decoded picture buffer. И единственное для чего он нужен - это усреднение производительности и хранение референсных данных для декодирования. И чем меньше кадров для временного хранения, тем меньше будет задержка передачи видео, 1го вполне достаточно. Если поток не прерывается, то можно напрямую выводить на монитор с декодера (кстати это тоже занимает время).

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

В условиях стоит 8К кодек, все что ниже уже не подходит к задаче, следовательно это HEVC, VP9 или AV1. Последний отбрасываем ввиду сложности, у VP9 проблемы как таковым, остаётся только HEVC. Не обязательно использовать все фишки стандарта, оставьте только минимум. Полная поддержка декодера нам также не нужна, так что кромсаем все, что нам не нужно.

Вилка 1-3 К для 8К энкодера 30 fps, скорее всего HEVC и технология 5-7 нм (на 14 реально, но по потребляемой мощности не будет носимым), несерьёзно. Там только команда на 10 человек, если делать с нуля, займет год, но самим и хорошо.

Или внутренний счётчик, данные считывать только по нулевом значению, длинну привязать к частоте.

Тактирование заряжает ёмкости цепей, плюс токи утечки по питанию.

Нужен ID, т.е. таки он как бы платный. Под бесплатным понимается доступность для потребителя, поскольку ранее абсолютно все было только за деньги. С одной стороны, оно как бы и свободно, а с другой - только для "своих". Прямых ссылок нет, доступ через support.cadence.com -> learning -> online courses P.S. по окончанию курса идет тест (тест и раньше был бесплатен, но как с доступом на данный момент я не знаю) и после прохождения всего сертификат (подтверждаемый) / беджик для вставки, как в LinkedIn или просто как электронная ссылка (также подтверждаемые).

Некоторое время назад Cadence открыла бесплатный доступ к онлайн курсам по продуктам, а также Verilog/SV/VHDL/SystemC. Для доступа нужно официальным пользователем (доступ через страницу саппорта).

Аналогично. У меня слишком большой зоопарк компиляторов, нужно 100% решение. Но с другой стороны - довольно много банков памяти и нужно переделать мультиплексирование между ними.

Осуществляется доступ к внутренней памяти между двух блоков, в зависимости от значений только один из них работает с памятью в такт времени. Возможно ли сделать мультиплексирование (синтезируемое) между двумя masters к одному slave (sram) внутри интерфейса? Примеров куча, но, как пишут, синтезируемыми являются только функции.

По факту - он "чище" логику делает. После десятка синтезов обычного DC результат не может пройти Formality (timing либо сходимость), с next версией таких проблем не было. По идее DCG как раз лучше при работе с большими блоками и SRAM, поскольку если делать первоначальный netlist, то он не учитывает размещения и это может привести к проблемам. Мне приходилось дизайн делить на части и синтезировать снизу вверх, с экстрацией параметров и пересинтезом. В итоге результат без размещения получается хорошо, быстрая верификация, синтез, ECO, но потом плачут другие. Так, что решили отдать все на сторону, не хватает специалистов на такую узкую область.

Мне кажется сперва кое на чем остановиться: Размер чипа и способность его самому реализовать и Кому вы отдаете его на синтез. В случае синтеза из исходного RTL DCG flow позволит вам более гибко реализовать чип, чем при использовании netlist-а. Если размер чипа мал и есть кому его делать, то конечно внешная реализация только увеличит стоимость, но как уже было сказано, надо считать. И опять же, вы сами сможете полность реализовать чип, у вас есть опыт работы с фабрикой ? Воруют конечно многие, но если компания занимающаюся реализацией и закупившая лицензии на это и людей имеющих это делать, то какой ей смысл в этом, если после этого она теряют клиентов. Обратитесь к большим, тот же Синопсис например, я думаю, они смогут в ходе обсуждений рассказать как они это осуществляют и оценить стоимость работ/лицензий. Констрейны являются неотемлемой частью дизайна и я говорю о проектах, которые предварительно проверены, также в процессе реализации возможно что-то изменить (что чаще всего и возникает на этапе сборки чипа). Для этого есть ограничения компании, плюс к этому, вся работа происходит через удаленный доступ (есть целый раздел приложений для этого), где у вас отсутсвует всяческая возможность получить данные (printscreen можно ограничить на локальной машине). При правильно выстренном процессе работе это не мешает.

Как раз отдать синтез на сторону является нормальной идеей и на данный момент это общий тренд. Естественно, код, как минимум, должен по тайминги проходить начальный синтез. Линты и верификация на вашей стороне. От исполнителя только синтез до кристалла, включая dft. В стоимость включается не только DC, но также Formality, размещение на кристалле и тестирование. Плюс, на это нужны знающие люди, отлаженный процесс и машины.

А так всегда будет. На одного ресерчера нужно 3 инженера, к каждому из них по 2 тестировщика, team & project lead для контроля и коммуникаций. Если доводить проект до конца, то еще вагон людей на backend.

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

Сделайте еще один регистр, который меняет значение после reset, флаг того что действие было произведено. Исходный reset устанавливается только, если флаг еще не был установлен.

Обновление даже 1го компонента приведёт к повторному тестированию всей системы в целом. Использование FPGA позволяет шанс на ошибку, и если система работает, то обычно её не трогают. Есть ли смысл в этом? Потраченная сумма и время не компенсируют получаемых преимуществ.

Т.е. необходимо верифицировать FPGA с прошивкой, что он функционально соответствует исходному ТЗ и стандартам описываемым в ТЗ? Но в теме нет стандартов...

Грубо говоря, вы можете в любом месте вставить свою функцию, и она начнёт работу с нулевого времени. Событием для выполнения может быть как время, так и любое изменение сигнала. В коде нет main, указан только верхний уровень иерархии, а все остальное исполняется в параллели, все вместе, одновременно.

Это ущербной ТЗ, получается оно уже привязано к некой архитектуре. А должно быть абстрактным, С или какой другой язык с комментариями идеально подходит к этому ввиду простоты понимания и читабельности.

Исходники на С могут быть ТЗ. А вот HDL это уже вещь сама в себе. Могут тайминги не сойтись, или производительности недостаточно, тогда вполне возможно многое придётся переделывать. А вот С это и исходник и тесты.

Присоединюсь, что значит описывать приоритет? Код на HDL исполняется параллельно. Код "исполняется" событийно, т.е. после выражения always или же assign (присвоение). То что находится внутри блока имеет очерёдность, то фактически это комбинация if-else которая имеет единственное значение в данный момент времени. Все блоки работают одновременно, независимо от их расположения в коде.

https://www.theregister.com/2020/07/03/open_chip_hardware/ Я так понимаю исходники это чистый код с констрейнами, размер не более 10мм^2.