Комментарии 9
PS: про «минусаторов»:
хотя, лично мне, как автору, от их действий становится грустно и обидноне обращайте внимания — карма у вас положительная, все статьи в плюсе, пишите еще.
Увидел эту статью. Задумался. Прочитал первую статью цикла. Задумался еще больше, так как занимаюсь аналогичными вещами и вообще не приходило в голову решать такие проблемы в данной концепции.
Если я правильно понимаю — ваш REDD должен программироваться быстро, удобно и в этом главное его качество.
Какая оптимизация? Вы же сами впихнули в него ПЛИС и для данной задачи — генерации меандра она подходит идеально. Только без NIOSа, а с голой логикой. А управлять этим всем вы будете с Linuxа. Зачем вы залазите в эти дебри?
Но давайте я обосную свой вариант. Одна из задач, которые решаются комплексом, требует либо генерации каких-то данных, либо их сбора. К концу цикла я как раз планирую сделать собиратель информации. Именно с этой целью, в систему добавлено ОЗУ. Работа с ОЗУ требует какой-то сложной логики. Её можно реализовать на автоматах или в виде программы для процессора. На автоматах всё делается быстро, надёжно и красиво, Но вот модифицируется — долго и со скрипом. Поэтому надо сразу проектировать качественно и вдумчиво, что не согласуется с концепцией быстрой разработки, при которой возможны ошибки и переделка частей кода. Значит, нужен процессор. Под него всё модифицируется быстрее. Но чтобы система на процессоре была более-менее поворотлива по скорости — надо держать в уме некоторые вещи… Вот эти вещи в данном цикле я и рассказываю…
А пользоваться ими или нет — решает каждый сам.
А меандр — он просто красиво на иллюстрациях выглядит. Все разрывы хорошо видны. Поэтому на нём и показываю. Сам меандр ради меандра проще получить в коде на Verilog, о чём в цикле тоже уже были статьи (вот эта и вторая половина вот этой). Но он тут — не цель, а средство для иллюстрирования. Подробности, почему всё показывается на осциллографе — в этой статье. Я пытался получить раскладку по тактам, пока не вышло. Приходится показывать вот так.
Но давайте я обосную свой вариант. Одна из задач, которые решаются комплексом, требует либо генерации каких-то данных, либо их сбора. К концу цикла я как раз планирую сделать собиратель информации. Именно с этой целью, в систему добавлено ОЗУ. Работа с ОЗУ требует какой-то сложной логики. Её можно реализовать на автоматах или в процессоре. На автоматах всё делается быстро, надёжно и красиво, Но вот модифицируется — долго и со скрипом. Поэтому надо сразу проектировать качественно и вдумчиво, что не согласуется с концепцией быстрой разработки. Значит, нужен процессор. Под него всё модифицируется быстрее. Но чтобы система на процессоре была более-менее поворотлива по скорости — надо держать в уме некоторые вещи… Вот эти вещи в данном цикле я и рассказываю…
Обратите свое внимание на тех, кто уже делал такие вещи. Например Speedgoat. ПЛИС людям нужна только тогда, когда без нее не обойтись и это на самом деле не так уж много задач.
Я бы вам рекомендовал в этом случае вместо того, чтобы учить людей программировать под ПЛИС, создать самим библиотеку прошивок под ПЛИС в вашем REDD + драйвер к ним, которые бы решали наиболее востребованные задачи. Например, как вы уже здесь описывали — быстрый функциональный генератор на ПЛИС. Или ту же систему сбора данных с записью в ОЗУ в реальном времени, откуда ваш Линуксовый драйвер уже спокойно мог бы забирать данные не в реальном времени.
Тогда большинству ваших пользователей вообще не придется заморачиваться с программированием ПЛИС — они ее просто будут прошивать под нужную библиотеку и просто пользоваться, сократив свое время.
А уж вы постарайтесь сделать все медленно, но правильно.
А уж вы постарайтесь сделать все медленно, но правильно.Не все готовы ждать. Кто не готов — тем я показываю, как они могут сделать уже сегодня. Причём набросать процессорную систему можно даже не владея Verilogом. Достаточно где-то взять нужные кубики (например, из примеров к этому циклу)
Больше подходов, хороших и разных! Выбор — это всегда замечательно!
И есть ещё одна вещь… Всё, что я рассказываю — не замыкается на Redd. Кто-то прочтёт и применит на макетной плате с Ali Express. Может, даже спасибо скажет.
Больше подходов, хороших и разных! Выбор — это всегда замечательно!
Ну тут есть еще один подход, о котором я не упомянул — HDL Coder, DSP Builder, System Generator и т.д. Тот, кто не знает Verilog, скорей всего захочет обратиться к этим тулам для ускорения, так как опять же в большинстве случаев к ПЛИС обращаются по причине того, что процессор не успевает работать в реальном времени и надо как-то ускориться.
Система на чипе им в этом случае не нужна, а нужны просто блоки для коммуникации с хост-процессором, которые вы можете предоставить. Кстати у вас для этого выбран USB/RS232, я бы предложил PCIe — он почти не требует софт-процессора и при этом имеет memory -mapped интерфейс, который все понимают.
Для PCIe нужна ПЛИС с индексом GX, а это — сразу другая цена (опыт-то в этом деле есть, подробнее — тут). Мы пока решили обойтись без неё, так как нам кажется, что нет реальных целей, оправдывающих это удорожание. По этой же причине не стали использовать и USB3.0 мост от FTDI (там бы сразу увеличилось число используемых ног ПЛИС, так что кроме цены самого моста набежала бы цена другого класса платы и прочего). Возможно, потом признаем ошибку, но под текущее ТЗ и синхронного параллельного канала FT245-SYNC хватает.
Добавлю ещё, что если писать в память, реализованную на PCIe средствами центрального процессора, то скорость получалась у меня не ахти. 4 мегабайта в секунду, что ли. Дело было в 2012-м году, кое-что уже забылось. Использование простенького блока DMA, как рекомендуется в PCIe примерах от Альтеры давало тот же эффект. SGDMA я тогда не стал осваивать, но сделал свой блок DMA. Он уже выжимал из PCIe 1x нормальную производительность. Но DMA — это всё равно драйвер и прочие извращения. Короче, хрен редьки не слаще. Работа на выделенном процессоре ничуть не хуже.
Узнал что помимо verilog'а и рисовании схем можно делать *так.
А ещё, есть случаи, когда иначе — невозможно. Например, попробовал я положить стандартный библиотечный компонент PCIe ядра на схему… Получился такой ёжик! И все торчащие из него иголки надо куда-то подключить! Стал смотреть учебники, оказалось, что рекомендуемый вариант — именно через процессорную систему. Тогда всё получается красиво и компактно. Причём процессор в ту систему можно не включать, ведущим будет именно блок PCIe.
Второй случай, где без такого варианта не обойтись, я даже описывал. Вот тут. Как раз, когда разбирался с решением той проблемы, узнал, что можно выносить систему на верхний уровень и обходиться в проекте без написания кода на языке (VHDL/Verilog) вообще, так как прослойка — не обязательна.
Публикации
Методы оптимизации кода для Redd. Часть 1: влияние кэша