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

    

lexx

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

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

  • Посещение

Репутация

0 Обычный

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

  • Звание
    Частый гость
  1. Симуляция обязательна для лакировки таймингов. Потребление оценивается для худшего и стандартного сценария в составе всего SoC. Информация из синтеза как некий сферический конь в вакууме и практически никому не нужна. Spyglass позволяет сделать кросс проверку результатов синтеза, а также позволяет проверить весь чип в составе разных блоков. 100% доверия тут нет, ошибаются все.
  2. ASIC, не FPGA. Только компиляция кода и запуск нескольких тестов. Симулятор ncverilog, в его последней реинкарнации. Окружение на perl-е, вызов симуляций также из него. P.S. Всегда возникает вопрос, а нужно ли оно мне вообще. Просто проверить код можно и вручную, запуск линта занимает не так и много времени, анализ вообще отдельный таск. Это не огромный С проект, где сборка занимает часы. Синтез отдельная задача минимум на 2 дня.
  3. Студент студенту рознь, но конечно уровень кода и знание софта требует времени. Опять же если этот софт был при практических занятий.
  4. Есть такая идея для текущего проекта. Собрать автосборку и проверку на ошибки при различных конфигурациях проекта (define). Исходники на Verilog, окружение на Perl, все хранится в CVS. Хочется автоматически при обновлении в CVS запускать компиляцию проекта с различными дефайнами и несколько простых тестов с выдачей результата. Возможно ли это осуществить?
  5. А что за проблема с бабками у Байкала? Вакансии интересные на hh висят.
  6. Согласен с вышеуказанным, проверка нетлиста. В дополнение добавлю power estimation, pda симуляция для оценки мощности.
  7. quato_a выше уже высказал основную мысль, Четкое разделение по задачам и срокам (стараться их соблюдать, но всегда подразумевается изначальная поправка по срокам). Интерфейсы должны быть однозначно документально и подробно описаны, многие проблемы идут из-за недопонимания друг друга, даже если это кажется прозрачно. Один никак не потянет бОльшую часть проекта, основная идея может быть, но не все. Денег это не добавит (при нормальном руководстве нет супер звезд, но много профессионалов), только гемор и куча переработки (не всегда оплачиваемой). Поэтому изначально куча документации по дизайну, больше расскажешь - меньше проблем с интерфейсами. Далее стандартная имплементация, если не лезть на другую половину, то сроки можно предсказать. На какой размер/проект рассчитана команда, в зависимости от задачи размер и специализация тимы/тимов будут различны. Где-то дизайн/тестирование/имплементация это различные тимы, а где-то один человек, все по разному, зависит от уровня работ, величина и периодичность проектов. P.S. я больше по ASIC, с FPGA все немного по другому
  8. Сперва покажите timing report, а не временные диаграммы, смысла в них нет. Далее, если посмотрити на главу datapath optimization, там будет рассказно про разрядность на выходе, у вас она не align, в итоге оно не ложится идеально на designware компоненты. А вообще плохая идея переписывать "библиотечные элементы", там уже заоптимизировано все. По умолчанию синтезатор и так использует библиотеку, чтобы успеть по таймингам, площадь вторична.
  9. Цитата(AVR @ Sep 24 2017, 13:46) Что имеется ввиду под hex? Встречал у некоторых ПЛИСовиков заблуждение что Verilog работает только с файлами hex-формата и удивлялись когда я выводил в десятичной форме, а то и вовсе произвольного формата текст, и не только выводил но и загружал. Надеюсь речь не об этом, потому что мне неведомо откуда они взяли эту чушь. Я сильно далек от ПЛИС, только для прототипирования ASIC, но вообще да, без разницы в чем писать и читать (привычка с hex работать).
  10. Verilog позволяет как читать, так и писать в файлы (hex). Если нет времени на разборки высшего уровня, то все можно привести только к чтени и записи. Смена тестовых последовательностей через скрипт при запуске самого verilog-a. Я использую ncsim, так что unzip через tcl и на выходе только лог и дополнительная информация если тест провалился (с местом падения, чтобы делать дамп с этой точки). Но даже симуляция не заменит прототипирования на fpga, на входе/выходе тот же самый тестовый набор (дизай запускается, читает и выдает результат в ddr). День тестов заменяет год симуляций.
  11. На ASIC такой подход не сработает, тут сперва 10 раз отмеришь и проверишь, а потом все равно сидишь, нервничаешь и ждешь ревизии, чтобы вздохнуть когда все тесты пройдут. Human factor никто не отменял на SoC. У нас из языков только курс VHDL-я был и немного EDIF-а, но не не пригодилось от слова вообще. Если первый никак не используется, то второй только как промежуточный формат, файл которого никто и никогда не открывает. Язык можно выучить, но нужно понимание что и куда растет. Легко и просто работать когда выстроена структура разработки, тогда можно легко собрать план и график работ, а также еще останется на оптимизацию процесса.
  12. Цитата(Mad_max @ Sep 16 2017, 12:09) С ветерком вы доедете до своей лаборатории, где обложившись логическими анализаторами и всякими чипскопами будете долго грустить, разбираясь почему 1000 раз алгоритм отработал правильно,а на 1001 почему то нет Если на симуляцию этого уходит 1 день, то экономиться более 3-х лет (или у вас есть очень много лицензий, причем что в это момент делать остальным). А вот 1001-й как раз и можно запуститить на моделирование. Симуляция отличается от синтеза, результат может быть отличен, особенно для "кривого кода". Хотя сам "кривой код" мало влияет на синтез, просто размер будет больше.
  13. Цитата(Мур @ Sep 11 2017, 12:13) У меня это врожденное. Гарантируемая синтезабельность только в случае, если постоянно думаю о схемотехнике и макроячейке конкретной ПЛИС. CPLD, к примеру, имеет малый ресурс и каждый триггер на счету... "Жмет" фантазии с ходу... Встречал аспиранта, который зарекся с FPGA не связываться по причине, огромного времени компиляции проекта (даже более суток). От себя добавлю - при больших проектах(и бенчах) огромное время в симуляции ради просмотра крохотного места в дизайне... А все из-за параллельного принципа работы архитектуры(сжирающего ресурсы симулирующей машины). Если синтез идет больше 8ми часов, то ищите другие варианты, делите проект на части, это также часть работы. Заменяйте симуляцию на FPGA тест, день помучится с синтезом и потом ехать с ветерком. Если же баги падают постоянно, то конечно только симуляция (и опять таки делите проект на части, используйте простые модели вместо кучи кода). Все это является работой разработчика, требует определенных знаний и просто программист тут вряд ли справится
  14. Цитата(x736C @ Aug 2 2017, 21:37) Все верно. Именно поэтому более простой стрим он спокойно пережует, т.к. он создан в полном соответствии со стандартом, который в свою очередь допускает не использовать межкадровое сжатие и компенсацию движения. Именно об этом пытался сказать. Насчет серьезного и несерьезного — это мне всегда было непонятно. Как измерить это серьезно или это не серьезно? Кто и как это определяет? Когда в декодере есть куча разных вариантов, энкодер в свою очередь можно попросту имплементировать как I picture only, предсказание по одному угловому пикселю, блоки только 8х8. В итоге когда первый раз на это смотришь, то задумываешься - а что, так тоже можно было. Плюс даже минимальое отсутствие управлением квантователя и rate control. На выходе энкодер, с точки зрения тестирования, на порядок проще чем декодер (порядок - из собственного опыта).
  15. В качестве домашней поделки пойдет, на что-то серьезное оно уже не годится. Уровень P/B фреймов все гораздо серьезней. Хотя энкодер в каком-то смысле проще, чем декодер, можно урезать все по максмуму и все равно он будет кодиорвать, хоть и не так качественно как референс. Что вы имеете ввиду под стандартным/не стандартным декодером, по моему видению декодер либо поддерживает все согласно спекам, либо нет. В мобильных телефонах (поскольку он в железе) как раз изначально закладыватся полная имплементация до определенного level/profile.