Микропроцессор своими руками-5. По поводу начала проекта встроенного в FPGA микроконтроллера
Проектирование микропроцессорных ядер с конвейерной архитектурой для реализации в базисе ПЛИС фирмы Altera
Вы точно человек?
Только полноправные пользователи могут оставлять комментарии. TM Feed Хабрахабр Geektimes Тостер Мой круг Фрилансим. Хабрахабр Публикации Пользователи Хабы Компании Песочница. Многим известно, что во всех современных процессорах есть вычислительный конвейер. Бытует заблуждение, что конвейер — это какая-то фишка процессоров, а в чипах для других приложений к примеру, сетевых этого нет. Очень часто для достижения высокой производительности выбирают такие алгоритмы, которые легко конвейеризируются в чипе. Если интересно узнать о низкоуровневых подробностях, добро пожаловать под кат! Простой пример Рассмотрим следующий пример: В рамках этой задачи я пренебрег тем, что результат суммирования 8-битных чисел может быть большим, чем Вполне очевидный код на языке SystemVerilog для этой задачи: Выходы c Add0 и Add1 подаются на сумматор Add2. После суммирования результат кладется в регистры s1 и s2. Программирование 2,9k авторов , 6,6k публикаций. Разработка мобильных приложений 1k авторов , 2,8k публикаций. Разработка под Android 1k авторов , 2,3k публикаций. Разработка веб-сайтов 4,1k авторов , 9,6k публикаций. JavaScript 1,9k авторов , 4,1k публикаций. Open source 1k авторов , 2,3k публикаций. Машинное обучение авторов , публикаций. IT-стандарты авторов , публикация. Python авторов , 1,8k публикаций. Алгоритмы 1,3k авторов , 2,3k публикаций. Яндекс открывает технологию машинного обучения CatBoost 14,6k Добавить в закладки Иван Шевчук ishevchuk карма. Названо много pros за конвейеризацию, но забыты cons: А так здорово, ждем еще. Спасибо Вот и дискуссия появилась. Обратную связь я упомянул Бывает, схема к конвейризации не была готова, так как есть обратная связь, в связи с задержкой на такт ы , начала неправильно работать. С ЦОС я не работал: Для макисмального быстродействия тут надо 3 такта как минимум, которых у нас нет. Если вставлять задерки в петлю обратной связи, то характеристика фильтра начнет меняться и в конечном итоге рассыпется. В общем алгоритмы с обратными связями feed back — зло, feed-forward — наше все! Давно не занимаюсь ПЛИС, но статься понравилась, хорошо пишете: Если честно, AXI4-Stream я никогда не использовал. Если кто-то использовал оба интерфейса, буду признателен, если поделитесь сравнением и впечатлениями. Судя по картинкам с временными диаграммами, ничем принципиально они не отличаются: AMBA включая AXI4 сейчас стала по сути промышленным стандартом, поэтому если будете покупать какой-то готовый IP-блок, то там скорей всего будет AXI. По этой картинке я тоже принципиальной разницы не увидел, но у AXI4-Stream есть сигнал TUSER , который может быть произвольной длины. По описанию, туда можно положить какую-то информацию о пакете: В этой ситуации я просто параллельно Avalon-ST добавляю еще одну структуру куда складываю информацию о пакете. Здесь это из коробки, что может быть удобно Еще есть сигнал TDEST , который явно показывает, куда на какой порт надо передать этот пакет, в Avalon-ST этого нет, приходится это добавлять в вышеупомянутую структуру. Опыт работы с AXI у меня весьма эпизодический, но там, как я понимаю, есть фиксированный перечень сигналов в интерфейсе, который надо реализовывать всегда — из ARM это перешло и сюда. Хочу отметить, что во многих случаях можно обойтись без сигналов валидности. Тут всё что нужно знать об устройстве в целом — длина конвейера, то есть количество ступеней. Я таким способом генерировал видео. Конечно, если данные идут всегда, то смысла вводить сигнал валидности особо нет. С другой стороны, его задержанные братья будут явно показывать на какой стадии мы сейчас находимся, что может быть полезно при отладке. Конечно, процент тех и других случаев вряд ли кто-то подсчитывал: И всё же, чем больше статики, тем естественнее аппаратное решение, — проще логика, полнее загрузка конвейера. Железячник для простоты читаемости кода написал бы явный assign, без переприсвоения. Мои коллеги не против, из минусов этой записи я вижу лишь то, что могут получиться два мультиплексора, которые стоят друг за другом, что не очень хорошо по частотке. Если такое вылезает, то приходится переделывать на case. Либо еще есть какие-то минусы от такой записи? Разве FPGA-шник должен быть железячником? Если не затруднит, не могли бы Вы написать более читаемый вариант этого блока. Я понимаю, как это можно описать при помощи assign, но тот вариант, который приходит на ум мне, не кажется более читаемым. Может быть, Вы имеете в виду что-то другое. Кстати always в Верилоге довольно часто применяют для описания сложной комбинаторной логики, типа функций переходов автоматов и т. Гораздо нагляднее, чем городить?: Хм, загнал модуль в Квартус, но ни одного ворнинга не увидел. Ага, закрадывалась мысль, что используете или Synplify, или Vivado. Значит, Synplify более паранойный Защелкивание лишних данных мне никогда особо не мешало, но так как есть мысли переехать на Synplify, то, возможно, придется это учесть, спасибо! Если не секрет, в своих проектах Вы от всех предупреждений избавляетесь? Я сейчас сам не пишу код. Но поскольку наша контора продает RTL тем, кто делает ASIC-и, то к предупреждениям отношение очень серьезное. Наши индусы используют статический анализатор LEDA с нашим собственным набором правил вроде бы, переделанным из IBM-овского , и релиз не пропустят, если есть хоть одно предупреждение. Если есть какие-то false-positive предупреждения, то они индивидуально маскируются. Для такого случая наглядней assign, тк есть переприсвание в начале на неупомянутые в if биты. Это затрудняет понимание именно этого кода. Куда понятней тот же код, где явно описано три возможных вариант в столбик и где главное для понимания определены все биты: Я обратил внимание, именно, на сложность интерпретации переприсваивания и возможных ошибок при этом. Там нельзя сделать переприсваивание и ошибки, только 3 явных и главное полных состояния выхода. Я прекрасно понимаю, что это может быть неинтуитивно для тех, кто так не писал: Возможную проблему с латчем, если кто-то удалит первую строчку я тоже знаю. Никаких нарушений канонов либо устоявшихся рекомендаций например, смешивание блокирующих и неблокирующих присваиваний в одном always-блоке в таком написании я не вижу. Раньше я писал через assign как раз так, как Вы предлагаете, но у меня очень часто возникает задача в длинном слове поменять часть байт и через assign и кучу конкатенаций мне не нравилось делать, так как пишется много кода. Больше кода — больше ошибок: Такая подмена это более высокоуровневое написание, чем assign, следовательно, должна быть более интуитивным и понятным. Думаю, дело вкуса и не более. Большой разницы через assign либо через так как Вы предложили я не вижу. Мне приходится со структурами похожую операцию проделывать: SystemVerilog вас до добра не доведет: LEDA на такое не ругается: Должен быть спор VHDL vs SystemVerilog Сейчас всё быстро меняется, и если надо разрабатывать большие проекты, то там только SystemVerilog ИМХО. Хотя от приложения зависит, может если тим DSP, то тех извращений, что я делаю с данными, там не надо делать Правда, насколько я знаю, есть проблема в том, что не все синтезаторы поддерживают, но Synplify вроде впереди планеты всей и всё поддерживает. А сейчас это полный аналог assign. Разумеется это полный аналог assign, так как код делает то же самое. Я тоже предпочитаю assign, чтобы меньше букв писать, но когда логика на два экрана то assign уже не очень подходит. Удивлен, что раньше использовали assign, но аргументация такого перехода понятна. Для себя, если придется править, то может и быстрее. Но вот если передавать код, то другому разобраться в нем сложнее. Просто всегда встречал такой код у тех, кто из программирования пришел к написанию RTL. А так, на мой взгляд, более читаемое описание тут вряд ли получится. Что касается стандарта AXI4-Stream а также AXI4 и AXI4-Lite , то они в целом довольно удобные для использования, с некоторыми исключениями. Для управления процессом передачи данных используется два сигнала — TVALID и TREADY. TVALID поступает от источника и сигнализирует готовность данных на шине, TREADY поступает от приемника и подтверждает прием. В этом случае передача одного слова занимает один такт. Стандарт запрещает комбинационные безрегистровые связи между сигналами TVALID и TREADY, поэтому нельзя сначала проверить адрес и потом уже решить, могут ли данные быть приняты в этом же такте. В AXI4 которая с адресами есть еще такая проблема, что при передаче пакетов bursts нужно заранее знать длину пакета и выставить ее на шину. Нельзя передавать пакеты с неизвестной заранее длиной. Такое соглашение приводит к необходимости применения лишних буферов и логики там, где без них можно было бы обойтись. Еще одна проблема, присутствующая в AXI4 и AXI4-Lite — это то, что ведущее устройство master может запросить данные из ведомого slave и при этом не быть готово к их приему. Допустим, процессор считывает содержимое одного из регистров периферийного устройства. Как правило, такие регистры подключаются к шине данных через мультиплексор, который выбирает нужный регистр в зависимости от адреса. Так вот, к тому моменту, когда процессор будет готов принять данные, он может уже снять адрес с шины адреса. Поэтому приходится либо запоминать адрес и держать его на мультиплексоре, либо запоминать считанные данные после мультиплексора — ставить лишний регистр. Все это мелочи по сравнению с тем, что AXI может вернуть данные не в том порядке, в котором их попросил мастер. Ну, это по желанию. Эта же информация дублируется в разделе A6 во многих местах. Так что, если ведущее устройство хочет, чтобы все транзакции исполнялись в порядке поступления запросов, он может этого потребовать от шины и ведомых устройств. Здесь есть один нюанс. В спецификации AXI сказано: Объясните мне пожалуйста, зачем вникать в эти ньюансы работы AXI шины как будто других нет , если для работы с AXI шиной Xilinx предоставляет кучу вспомогательных IP ядер: AXI DMA, Datamover, AXI Master Interface и тд? Как раз сейчас столкнулся с проблемами в работе своего проекта в железе. Есть о чем подумать. И совсем не понял вот этот момент: Я вот ошибочно считал, что регистр будет запоминать данные по переднему фронту и проблема в том, что фронт клок придет раньше, чем установится состояние сумматоров, что приведет к тому, что запишется не то значение. Читаю про D-триггер, там речь о том, что по после переднего фронта С он начинает заносить значение в первый Т триггер и только после падения С уже подается на выход то, что там установилось. У вас же написано и показано на картинках , что данные на выход попадут только по следующему переднему фронту CLK. Здесь есть тонкий момент, о котором я не написал, но подразумевал. Считается, что схема полностью синхронная: Читаю про D-триггер, там речь о том, что по переднему фронту С он заносит значение в первый Т триггер и после падения С уже подается на выход. Если честно, такого никогда не видел…. Так выглядит функциональная симуляция в Квартусе кстати Попробуйте пример из сообщения чуть выше с sync подать в симуляцию, подав данные не по положительному фронту Какой конструкцией подаете сигналы x в Вашем примере? А какой смысл так писать тестовые модули? Они должны выдавать сигналы во времени именно так, как у меня на графике, так, как данные в реальном времени подаются на вход модулей, а не промежуточных регистров. Но зачем так делать? Надо как-то этот вопрос осветить, наверное. Смысл заключается в том, что бы сделать так, что бы эти сигналы были синхронны с клоком. Просимулирую, но уже позже А в реальной жизни сигналы синхронны с клоком? В симуляторе мы отсматриваем модель того, что происходит в жизни. Есть модель функциональная, а есть временная. Еще можно симулировать не RTL-код, а нетлист или гейты, и тогда еще более реальная жизнь происходит. Когда мы выбираем какой-то тип симуляции, то соглашаемся с теми допущениями, что в ней есть. Все эти картинки, это лишь то, как симулятор видит нашу схему на тех входных воздействиях, что в нее подали Разницу между функциональной и временной можно увидеть выше. К сожалению, из литературы по верификации мне ничего не приходит в голову хорошого и простого. Посмотрите примеры на testbench. В реальной жизни это зависит от сигналов. Если сигнал идет от АЦП с синхронным интерфейсом, который вы сами тактируете, то они будут синхронными. Если сигнал идет с кнопок, или с UART-а, или с другого устройства, которое работает на своей собственной частоте, независимой от частоты ПЛИС, то они не будут синхронными. В этом случае возможен вариант, когда входные сигналы изменятся слишком близко ко фронту клока в ПЛИС, что приведет к нарушению времени предустановки триггеров setup violation. С этим можно бороться путем добавления синхронизаторов. Чтобы была видна разница, я решил три теста одновременно показать в симуляторе: Мои все примеры на SystemVerilog А в чем разница, если в двух словах? Я вот только с приведением типов столкнулся. SystemVerilog это продолжение стандарта Verilog. Туда добавили кучу новых плюшек, как синтезируемых, так и не синтезируемых, которые упрощают и убыстряют разработку. Я предлагаю вынести создание клока в отдельный initial, что бы он не мешался. Какие я должен сделать из этого выводы? От куда берется эта задержка в 1 такт. Метки лучше разделять запятой. Сейчас Вчера Неделя Я являюсь причиной появления венгерской нотации в Android 8,8k Интересные публикации Хабрахабр Geektimes. Команда Media Player Classic объявила о возможной смерти проекта GT. Что нового в IntelliJ IDEA Raspberry Pi3 против DragonBoard. Отвечаем на критику GT. Применение принципа poka-yoke в программировании на примере PHP. Конец эпохи закона Мура и как это может повлиять на будущее информационных технологий GT. Что такое SMT и как оно работает в приложениях — плюсы и минусы. Анализируем карьеру игроков NHL с помощью Survival Regression и Python. Введение в нейронауки, I [Роберт Сапольски, Компьютерная мышка как точный датчик GT. Разделы Публикации Хабы Компании Пользователи Песочница. Информация О сайте Правила Помощь Соглашение Конфиденциальность. Услуги Реклама Тарифы Контент Семинары.
Конвейерные устройства на FPGA. Рассматриваются основные принципы конвейерной обработки. Кратко описывается архитектура FPGA и особенности построения на её основе конвейерных устройств. Приводятся комбинационные и конвейерные схемы для реализации операций суммирования и умножения. Сравниваются результаты их VHDL-синтеза. Делается вывод о целесообразности использования конвейеризации для этих устройств. С ростом производительности вычислительных средств растут и вычислительная сложность алгоритмов, а также требования по быстродействию со стороны пользователя. Реализовать обработку данных на данный момент можно на основе двух базовых аппаратных технологий: Обе технологии имеют как преимущества, так и недостатки. К преимуществам микропроцессоров можно отнести простоту разработки устройств на их базе, которая, в сущности, сводиться к написанию программного обеспечения. Всё большую популярность приобретает проектирование устройств на базе последней технологии, а именно FPGA field-programmable gate array. При этом затраты на разработку и сложность значительно возрастают, так как требуется специализированная среда разработки и отладочная плата. Почему же FPGA технология более привлекательна по сравнению с микропроцессорной технологией? Регулярная структура ПЛИС позволяет строить на основе одной микросхемы комплексы из нескольких устройств и даже несколько независимых устройств. Основным преимуществом ПЛИС является возможность реализации на их базе принципов параллелизма и конвейеризации [6]. Первый принцип заключается в возможности одновременного выполнения нескольких однотипных действий и реализуется в основном в виде дублирования устройств. Второй принцип позволяет разбить выполнение сложной задачи на ряд простых последовательных действий с одновременным совмещением их выполнения во времени. Рассмотрим принцип конвейеризации на основе работы конвейера команд процессора рис. Рассматриваемый конвейер состоит из пяти ступеней, каждая из которых выполняет определённое действие над командой. После завершения обработки текущей команды на текущем этапе, выполнение команды переходит на следующий этап, а на данный этап обработки поступает следующая команда. Допустим, что каждая ступень конвейера выполняет обработку за один такт, тогда после загрузки конвейера 5 тактов , выполнение команд будет производиться с периодом в один такт. Считая, что обычное не конвейерное выполнение команды занимает 5 тактов, имеем ускорение выполнения команд в 5 раз. Имеются, конечно же, ограничения и недостатки данного метода, но все они также решаемы в той или иной степени. Описанный принцип можно использовать и для ускорения выполнения других алгоритмов. В качестве простейшего примера конвейеризации на ПЛИС рассмотрим построение арифметического беззнакового сумматора. Для анализа реализации этого и всех последующих устройств используются результаты синтеза среды Xilinx Для того чтобы сделать вывод об эффективности конвейерной схемы, сначала синтезируем типовую схему комбинационного сумматора с входным и выходным переносами. Следует отметить, что при синтезе данного сумматора среда разработки использует оптимизированную схему суммирования, позволяющую увеличить быстродействие при использовании большего числа входов LUT. Конвейерный вариант данного сумматора будет иметь вид, показанный на рис. Теперь, для реализации сумматора на n разрядов при m ступенях конвейера необходимо те же n LUT и дополнительные регистры. Суммарное количество необходимых для реализации триггеров равно. Из полученной формулы можно сделать вывод, что результирующие затраты триггеров значительнее зависят от разрядности сумматора, чем от количества ступеней конвейера. Рассмотренная схема является типовой схемой конвейеризации и вместо сумматоров может быть использована любая комбинационная схема. Следует иметь в виду, что схема является синхронной, все триггера срабатывают по фронту сигнала синхронизации. Для упрощения цепи синхронизации и асинхронного сброса на схеме не указаны. Реализуем рассмотренную схему в структурном стиле, на основе параметризированных компонентов, в виде сумматора с цепочками регистров на входе и выходе [3]. Следует отметить, что при длине цепочки 2 и более, средство синтеза автоматически реализует цепочку на основе встроенного сдвигового регистра, что значительно уменьшает аппаратные затраты. Также необходимо помнить, что триггера, входящие в состав базовой ячейки также могут быть использованы в данной схеме. Результаты синтеза рассмотренного конвейерного сумматора в сравнении с комбинационным сумматором приведены в таблице 1. Таблица 1 — Результаты синтеза сумматоров. Из полученной таблицы можно сделать некоторые важные выводы. При двух ступенях конвейера, регистры практически полностью реализуются на тех же логических ячейках, на которых реализованы сумматоры. Затем использование ресурсов резко возрастает, а при количестве ступеней 8, 16, 32 изменяется незначительно, это связано с использованием встроенных сдвиговых регистров [1]. Помимо операций сложения и вычитания, на FPGA возможна также реализация устройств, выполняющих умножение и деление. Схема комбинационного умножителя приведена на рис. Принцип работы схемы основан на последовательном анализе бит первого множителя. Если бит, равен единице, то к частичному произведению прибавляется второй множитель. Время срабатывания и производительность данной схемы можно значительно увеличить, если обеспечить конвейеризацию вычислений [4],[7]. Схема усовершенствованного устройства показана на рис. Как и в случае с конвейерным сумматором, на схеме не приведены цепи синхронизации и асинхронного сброса. Суммарные затраты триггеров на реализацию данной схемы равны. Из данной формулы можно сделать вывод, что дополнительные затраты на конвейеризацию, так же как и основные затраты на построение сумматоров n 2 , растут пропорционально квадрату разрядности умножителя. Синтезируем рассмотренную схему, результаты синтеза приведены в таблице 2. Таблица 2 — Результаты синтеза умножителей. Из полученной таблицы можно сделать вывод, что быстродействие полученной схемы незначительно зависит от разрядности, а дополнительные аппаратные расходы на конвейеризацию с ростом разрядности стремятся к нулю. Это можно объяснить использованием в схеме входящих в состав логической ячейки триггеров и сдвигового регистра. В данной работе были рассмотрены основные принципы конвейеризации и их использование. Следует отметить, что использование данного метода обработки возможно не только при построении конвейерной обработки команд в микропроцессорных устройствах, но и при разработке практически любых устройств. Главной задачей, при реализации конвейерного варианта устройства, является обеспечение независимости работы текущей ступени конвейера на данном такте от результатов работы предыдущей ступени на этом же такте. Для реализации этого требования чаще всего можно использовать регистровые схемы. Были разработаны конвейерные схемы сумматора и умножителя, рассчитаны дополнительные затраты регистровых элементов при реализации этих схем в базисе дискретных элементов. Также, в работе были рассмотрены особенности структуры логической ячейки FPGA и её эффективного использования для построения устройств с конвейерной архитектурой [5]. В результате реализации разработанных ранее схем на FPGA были получены их синтезируемые VHDL-описания. На основе результатов синтеза можно сделать следующие выводы: Рассмотренные в этой работе принципы могут быть также использованы при построении более сложных устройств для работы в следующих сферах: Разряд-ность, n Число ступеней, m Комбинационный Конвейерный Затраты, LUTs Задержка, ps Затраты, LUTs Задержка, ps 2 4 8 2 4 8 16 32
Микропроцессор своими руками-5. По поводу начала проекта встроенного в FPGA микроконтроллера
Фан дэй официальный сайт каталог 2016
Сколько км от екатеринбурга до озера балтым
Удочкана судакасвоими руками
Стих сулеймана к хюррем
Способы перемещений в баскетболе
Горох белки углеводы