Знаешь что такое цифровой автомат(FSM)!? Интересуешься цифровой схемотехникой? Если да, то вам будет интересно посмотреть решение одной проблем, которую часто игнорируют. Если нет, то вам придётся потратить дополнительно 5 минут на введение)
Для тех кто хочет загрузить свой мозг новой интересной задачей. Результаты вас удивят.
Программируемая Логика - увлекательный и своеобразный мир - к сожалению среди большинства из нас, знатоков Python, JS, Go, Java, C++ да и среди любителей Arduino и прочих микроконтроллеров она не так широко "распростирает свои руки".
Давно хотелось среди задачек и головоломок на "обычное" программирование внедрить на сайте и горстку упражнений из этой таинственной области. Мешало банальное отсутствие собственного опыта в ней (за исключением нескольких занятий по AHDL в далёкие вузовские годы).
Мотивация (или везение?) пришло с очередной новой работой - хотя она не связана с PLD/FPGA, но в моей текущей компании эти направления значительно развиты, есть и знатоки - которые подсказали кое-что по инструментам, по выбору языка - а заодно показали и репозиторий с "домашками" от их собственного курса... Я засучил рукава, добавил компилятор в "песочницу" и вот уже первые несколько заданий ждут энтузиастов :) Также ждём знатоков которые захотят помочь с идеями новых задач и верификацией существующих. Итак, переходим к подробностям...
Недавно у меня возникла потребность в том, чтобы смоделировать в ModelSim дизайн, использующий IP-ядра Xilinx. У меня не сработала стандартная схема с компиляцией исходников в Vivado и я решил попробовать скомпилировать всё самостоятельно. В итоге у меня всё получилось! Более того, я написал несколько Tcl-скриптов, которые помогают немного упростить этот процесс. Все, у кого возникла такая же потребность — прошу к прочтению.
Привет, Хабр! Принесли материалы с недавнего митапа для FPGA/ASIC/RTL-инженеров — добавляйте в закладки, чтобы посмотреть в свободное время. В докладах вас ждут:
• Шаблоны документов, которые нужны при функциональной верификации, и шаблон проекта для организации итеративной сборки.
• Обзор плюсов и минусов существующих систем для автоматизации тестирования на FPGA-стендах.
• Способ оценки производительности коммерческого ПЛИС-кластера и собственного решения.
Ребята из FPGA комунити каждый день делают небольшую подборку новостей из мира FPGA и делятся ею с читателями хаба FPGA. Внимание: возможны повторы!
В статье речь пойдёт о ПЛИС производства Xilinx, в частности Spartan-3 и Spartan-6, на которых эта идея была опробована. Применять её можно и в других семействах.
Очень кратко суть идеи: триггер (FF, flip-flop), который может менять своё состояние по фронту тактового сигнала, можно заменить на синхронное ОЗУ (distributed RAM), которое тоже может менять состояние одной своей ячейки по фронту тактового сигнала.
Ребята из FPGA комунити каждый день делают небольшую подборку новостей из мира FPGA и решили поделиться ею с читателями хаба FPGA. На этой неделе ~90 ссылок. Внимание: возможны повторы!
В предыдущей паре статей я рассуждал про ПЛИС Lattice. Давайте сегодня поговорим об эффективной разработке под них. Один наш крупный руководитель уверяет, что из разговоров с иностранными Заказчиками, он выяснил, что российских разработчиков считают пишущими классные вещи, но делающими это крайне медленно. Ну, разумеется, по сравнению с разработчиками из других стран. И разумеется, «классные» идёт на первом месте.
Один из методов обхода проблемы скорости разработки – использование готовой инфраструктуры для проектов. Я делал цикл статей про комплекс Redd, где продвигал использование готовой шинной инфраструктуры в среде разработки Quartus. Сначала это была честная процессорная система, потом – процессор мы изъяли, а шины – оставили.
Затем я делал пару циклов, где активно использовал данный подход. Мне приходилось дописывать только проблемно-ориентированные модули, остальное — среда разработки создавала за меня.
Есть ли что-то подобное для Lattice в частности и сцепки Yosys/NextPNR в целом? Вы не поверите! Решение не просто есть, но оно ещё и настолько кроссплатформенное, что подойдёт и для Yosys/NextPNR, и для Quartus, и для Vivado! И называется оно Litex. Итак, давайте попробуем поэкспериментировать с ним для подхода, который я уже давно продвигаю: «делаем штатную основу, а на неё нанизываем свои целевые блоки».
Однажды я решил ответить на сообщения в LinkedIn от рекрутерши безосовской компании Blue Origin, которая занимается разработкой и запуском космических аппаратов. Затем я прошел два раунда интервью: скрининг и 6-часовой марафон с дюжиной инженеров и менеджеров. Я не могу рассказать вопросы или описать диалоги с интервьирующими, потому что я подписал бумагу что не буду этого делать, но покажу пару вещей, о которых зашла речь еще до подписания бумаги, а также дам совет тем, кто хочет это повторить (совет кстати может быть применим не только при устройстве к Безосу, но и к Маску или Рогозину).
Одновременно с Blue Origin я интервьировался в другую компанию, интервью в которую по времени было такое же - час скрининга с инжиниринг-менеджером и шесть часов детальное интервью - но содержание было соовсем другое. Вообще обычно в электронных компаниях такое интервью - это просто марафон задачек на микроархитектуру (всякие извращенные FIFO, арбитры, кэши, кредитные счетчики), каверзные вопросы про тайминг (доходит до time stealing/time borrowing), пересечение тактовых доменов, дюжина способов оптимизации динамического энергопотребления при проектирования на уровне регистровых передач итд.
Но в компании Безоса все было по другому. Сначала нужно было написать эссе на тему "Что я думаю о космических кораблях бороздящих просторы Вселенной". Я написал следующее:
Добро пожаловать на очередной шабаш любителей испортить себе жизнь странным хобби! Репортаж с предыдущей вечеринки вы можете найти по ссылке. На ней мы практически «с нуля» создали модель начального уровня встраиваемого контроллера на базе RISC-процессора. Сегодня мы с вами будем добавлять ром ROM и попробуем обзавестись сравнительно несложной защитой памяти. И правда, что за встраиваемая система без ПЗУ? Прежде чем мы это сделаем, неплохо бы набросать некоторые детали конечной архитектуры нашей системы. Почему сейчас? Потому что ROM нужно будет разместить по каким-то адресам, как-то нужно будет управлять логикой защиты памяти, оставить что-нибудь «на вырост» и при этом где-то должно быть ОЗУ. Впрочем, описание будет небольшим ;-)
Перед нами девушка Лиля, с FPGA платой и учебником Харрис & Харрис в руках, на фоне самого высокого на Земле дерева Sequoia sempervirens, недалеко от Стенфорда в Silicon Valley.
Представьте, что вы приехали сюда в командировку в типичную электронную компанию. Усаживаетесь в офисе, входите со своего ноубука (в Америке их чаще называют лаптопами) в корпоративную сеть и пытаетесь что-то напечатать. А принтер не подсоединяется. Вы обращаетесь к ко-воркеру "Что делать?", а он вам говорит: "Обратитесь в IT". Вы в замешательстве "В Ай-Ти? А я что - не айтишник?"
Спокойствие. Если вы программист, вы не IT, вы software engineer и работаете в отделе Software Engineering Department. Если вы электронщик, вы тоже не IT, вы работаете в Hardware Engineering Department. IT Department - это другое, это отдельный от разработки отдел, это группа сисадминов, которые поддерживает внутри-корпоративную сетку и ведут учет выданых сотрудникам лаптопов.
Но это слишком тривиально, обсудим более интересный вопрос: вот все эти люди, которые пишут код на языке описания аппаратуры Verilog, который потом превращается в дорожки и транзисторы из silicon на фабрике - они программисты? Аппарентли, нет.
Собирая как-то в очередной раз разные ревизии для одного и того же проекта вручную, у нас возникла навязчивая мысль: а можно ли собирать это все автоматически по нажатию одной кнопки? Забегая вперед, сообщим, что мы решили эту проблему, причем мы упростили сборку проекта не только на локальном компьютере, но и запустили удаленную сборку на GitLab CI.
Если вы тоже задавались подобным вопросом, то вполне возможно, что наш опыт и полученное решение вам пригодятся, поэтому приглашаем к дальнейшему прочтению.
