Перейти к содержанию

lexx

Свой
  • Публикаций

    118
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о lexx

  • Звание
    Частый гость
  1. quato_a выше уже высказал основную мысль, Четкое разделение по задачам и срокам (стараться их соблюдать, но всегда подразумевается изначальная поправка по срокам). Интерфейсы должны быть однозначно документально и подробно описаны, многие проблемы идут из-за недопонимания друг друга, даже если это кажется прозрачно. Один никак не потянет бОльшую часть проекта, основная идея может быть, но не все. Денег это не добавит (при нормальном руководстве нет супер звезд, но много профессионалов), только гемор и куча переработки (не всегда оплачиваемой). Поэтому изначально куча документации по дизайну, больше расскажешь - меньше проблем с интерфейсами. Далее стандартная имплементация, если не лезть на другую половину, то сроки можно предсказать. На какой размер/проект рассчитана команда, в зависимости от задачи размер и специализация тимы/тимов будут различны. Где-то дизайн/тестирование/имплементация это различные тимы, а где-то один человек, все по разному, зависит от уровня работ, величина и периодичность проектов. P.S. я больше по ASIC, с FPGA все немного по другому
  2. Сперва покажите timing report, а не временные диаграммы, смысла в них нет. Далее, если посмотрити на главу datapath optimization, там будет рассказно про разрядность на выходе, у вас она не align, в итоге оно не ложится идеально на designware компоненты. А вообще плохая идея переписывать "библиотечные элементы", там уже заоптимизировано все. По умолчанию синтезатор и так использует библиотеку, чтобы успеть по таймингам, площадь вторична.
  3. Цитата(AVR @ Sep 24 2017, 13:46) Что имеется ввиду под hex? Встречал у некоторых ПЛИСовиков заблуждение что Verilog работает только с файлами hex-формата и удивлялись когда я выводил в десятичной форме, а то и вовсе произвольного формата текст, и не только выводил но и загружал. Надеюсь речь не об этом, потому что мне неведомо откуда они взяли эту чушь. Я сильно далек от ПЛИС, только для прототипирования ASIC, но вообще да, без разницы в чем писать и читать (привычка с hex работать).
  4. Verilog позволяет как читать, так и писать в файлы (hex). Если нет времени на разборки высшего уровня, то все можно привести только к чтени и записи. Смена тестовых последовательностей через скрипт при запуске самого verilog-a. Я использую ncsim, так что unzip через tcl и на выходе только лог и дополнительная информация если тест провалился (с местом падения, чтобы делать дамп с этой точки). Но даже симуляция не заменит прототипирования на fpga, на входе/выходе тот же самый тестовый набор (дизай запускается, читает и выдает результат в ddr). День тестов заменяет год симуляций.
  5. На ASIC такой подход не сработает, тут сперва 10 раз отмеришь и проверишь, а потом все равно сидишь, нервничаешь и ждешь ревизии, чтобы вздохнуть когда все тесты пройдут. Human factor никто не отменял на SoC. У нас из языков только курс VHDL-я был и немного EDIF-а, но не не пригодилось от слова вообще. Если первый никак не используется, то второй только как промежуточный формат, файл которого никто и никогда не открывает. Язык можно выучить, но нужно понимание что и куда растет. Легко и просто работать когда выстроена структура разработки, тогда можно легко собрать план и график работ, а также еще останется на оптимизацию процесса.
  6. Цитата(Mad_max @ Sep 16 2017, 12:09) С ветерком вы доедете до своей лаборатории, где обложившись логическими анализаторами и всякими чипскопами будете долго грустить, разбираясь почему 1000 раз алгоритм отработал правильно,а на 1001 почему то нет Если на симуляцию этого уходит 1 день, то экономиться более 3-х лет (или у вас есть очень много лицензий, причем что в это момент делать остальным). А вот 1001-й как раз и можно запуститить на моделирование. Симуляция отличается от синтеза, результат может быть отличен, особенно для "кривого кода". Хотя сам "кривой код" мало влияет на синтез, просто размер будет больше.
  7. Цитата(Мур @ Sep 11 2017, 12:13) У меня это врожденное. Гарантируемая синтезабельность только в случае, если постоянно думаю о схемотехнике и макроячейке конкретной ПЛИС. CPLD, к примеру, имеет малый ресурс и каждый триггер на счету... "Жмет" фантазии с ходу... Встречал аспиранта, который зарекся с FPGA не связываться по причине, огромного времени компиляции проекта (даже более суток). От себя добавлю - при больших проектах(и бенчах) огромное время в симуляции ради просмотра крохотного места в дизайне... А все из-за параллельного принципа работы архитектуры(сжирающего ресурсы симулирующей машины). Если синтез идет больше 8ми часов, то ищите другие варианты, делите проект на части, это также часть работы. Заменяйте симуляцию на FPGA тест, день помучится с синтезом и потом ехать с ветерком. Если же баги падают постоянно, то конечно только симуляция (и опять таки делите проект на части, используйте простые модели вместо кучи кода). Все это является работой разработчика, требует определенных знаний и просто программист тут вряд ли справится
  8. Цитата(x736C @ Aug 2 2017, 21:37) Все верно. Именно поэтому более простой стрим он спокойно пережует, т.к. он создан в полном соответствии со стандартом, который в свою очередь допускает не использовать межкадровое сжатие и компенсацию движения. Именно об этом пытался сказать. Насчет серьезного и несерьезного — это мне всегда было непонятно. Как измерить это серьезно или это не серьезно? Кто и как это определяет? Когда в декодере есть куча разных вариантов, энкодер в свою очередь можно попросту имплементировать как I picture only, предсказание по одному угловому пикселю, блоки только 8х8. В итоге когда первый раз на это смотришь, то задумываешься - а что, так тоже можно было. Плюс даже минимальое отсутствие управлением квантователя и rate control. На выходе энкодер, с точки зрения тестирования, на порядок проще чем декодер (порядок - из собственного опыта).
  9. В качестве домашней поделки пойдет, на что-то серьезное оно уже не годится. Уровень P/B фреймов все гораздо серьезней. Хотя энкодер в каком-то смысле проще, чем декодер, можно урезать все по максмуму и все равно он будет кодиорвать, хоть и не так качественно как референс. Что вы имеете ввиду под стандартным/не стандартным декодером, по моему видению декодер либо поддерживает все согласно спекам, либо нет. В мобильных телефонах (поскольку он в железе) как раз изначально закладыватся полная имплементация до определенного level/profile.
  10. Цитата(Qimbo_Bob @ Jul 23 2017, 00:12) Оно по памяти в том виде, в котором есть, ничего почти не требует, есть только I кадры, которые почти на лету обрабатываются, памяти пару Block Ram кушает. Но заложена возможность добавления P и B кадров предсказания. Автор данного кода пишет, что коэффициент сжатия 1:10, с кадрами B было бы порядка 1:50, естественно в зависимости от типа входного видеосигнала (насколько там много всего движется). От I picture особого смысла нет, там только половина по железу, причем не самое сложное.
  11. Цитата(x736C @ Jun 3 2017, 15:49) Не все так просто. Задержка определяется не кодером, а декодером. Просто надо понимать, что мы говорим об одном и том же, говоря о задержке кодирования. Я имел в виду общую задержку от несжатого кадра до его отображения потребителю. И обычно, когда говорят о задержке кодирования, имеют в виду именно это. А не то, справится кодек или нет Чем сильнее коэффициент сжатия (это не только работа квантователя), тем, как правило, выше задержка, если не применяется IRE режим. Потому что, задержка больше тогда, когда больше разница между максимальным значением битрейта и средним. Не соглашусь, там на при передаче еще несколько этапов, куча буферов, так что декодер не влияет на скорость. Опять же, либо он успевает за 33 мс, либо нет. Отчасти скорость кодирования ограничена временем нахождения исходного кадра с буфере, а поскольку он поступает каждые 33 мс, то в среднем, это время на кодирование одного кадра. Все эти режимы простая фикция, хороший алгоритм для motion estimation & rate control определяет все. Можно сказать, что референсный алгоритм кодирования (с full search) закрывает все, а потом ищутся методы как не сильно потерять при оптимизации или минимизации/поиск алгоритма, который был бы балансом между качеством, битрейтом и скоростью кодирования.
  12. Цитата(x736C @ Jun 2 2017, 17:12) Либо мизерная задержка, но при этом или высокий битрейт, или низкое качество. Такой треугольник. Причем от цены напрямую не зависит. Не считая алгоритмов LME, IRE, функционал которых на задержу влияет. Не понимаю причем тут задержка, кодек либо успевает, либо нет. Битрей / качество (квантователь) это лямбда в rate control и является основной функцией энкодера.
  13. Цитата(Golikov A. @ Apr 13 2017, 23:59) Мы в таких местах делали ветвление через `ifdef ALTERA `elsif XILINX, не помню VHDL аналога, годная практика имхо Это как надо код писать, чтобы при синтезе оно отличалось ? Приведите пример такой конструкции. Все сходится и ни ошибки, ни warning-а при этом ? 1. LINT 2. SIM (ncsim например) 3. SYN 4. EC Наверняка что-то находится за гранью синтезируемой области, кто-то поддержал новую фичу, кто-то нет
  14. Если место нужно для обмена информацией между разными процессами/железом, то необходимо подтверждение записи данных в RAM. По шине они могут идти неопределенное время.
  15. Цитата(yes @ Mar 20 2017, 19:47) по-моему (пишу ради слежения за темой) Аналогично, ну и потролить немного. Не в укор выложвшему объявление. Интересно, на какой частоте мелкий ARM заведется при 65нм. Возможно работа сама по себе и не такая большая, но сколько всего надо собрать чтобы оно нормально заработало и на сколько граблей при этом наступить. Поэтому работа ради работы мало интересна, для того чтобы получить положительный результат нужно много усилий разных людей, тут одиночка мало что решает.