Comments 41
Спасибо, интересно! Пишите еще. Интересно было бы если еще про отечественные побольше информации было и проектов для начинающих (только не мигание светодиодом).
И отдельно интересно было бы почитать про процессор с мультиклеточной архитектурой и его реальное применение.
И отдельно интересно было бы почитать про процессор с мультиклеточной архитектурой и его реальное применение.
Просто считайте, что отечественных ПЛИС нет. Так проще и соответствует реальной картине мира на 99.9%
Про отечественных разработчиков ПЛИС я только однажды слышал на одном форуме. Там речь была про ОАО «КТЦ „ЭЛЕКТРОНИКА“ г.Воронеж и их продукцию 5576ХС1Т, 5576ХС1Т1, 5576ХС2Т, 5576ХС3Т, 5576ХС4Т. Являются функциональными аналогами Altera. Для целей „попробовать“ это дорого. В принципе, я думаю, что знания в области разработки устройств с применением ПЛИС более-менее универсальные и разработчик хоть и без особого желания, но сможет перейти с Altera на Xilinx (и наоборот) или на что-то другое. Мультиклеты я не изучал, и не могу сказать, какое они имеют отношение к ПЛИС.
По поводу мигания светодиодиками — на этих выходных решил сделать небольшой проект и уложиться в „пару вечеров“. Сейчас готовлю статью и скоро можно будет поглядеть, что из этого вышло.
По поводу мигания светодиодиками — на этих выходных решил сделать небольшой проект и уложиться в „пару вечеров“. Сейчас готовлю статью и скоро можно будет поглядеть, что из этого вышло.
Мультиклет к ПЛИС не имеет никакого отношения. Но его, наверное, как и любой другой процессор, можно реализовать в ПЛИС, правда очень коряво и медленно.
А российские ПЛИС существуют только для военных, причем даже они пытаются использовать импорт там, где это возможно. Если вы не военный, то смело считайте, что российских ПЛИС не существует в природе.
А российские ПЛИС существуют только для военных, причем даже они пытаются использовать импорт там, где это возможно. Если вы не военный, то смело считайте, что российских ПЛИС не существует в природе.
За тот недолгий срок, что я работал программистом для FPGA, я твердо запомнил — никаких асинхронных элементов в ПЛИС. Лучше сделать чуть сложнее синхронную схему, чем потом все развалится.
Вы правы. Но иногда приходится делать что-то асинхронно. И надо себе отдавать полный отчет к чему это может привести — при очередной разводке может что-то куда-то уползти. А искать, понять и осознать что именно произошло, особенно если проект немаленький — ох это сколько порой времени может уйти. Поэтому такие линии надо ставить на временной контроль и после разводки обязательно проверять времянку.
А Вы не могли бы, пожалуйста, привести пример, когда действительно «приходится», т.е. без асинхронщины никак? У меня с ходу не получается такое придумать, но у меня совершенно минорный опыт.
Применение асинхронности оправдывается там, где нужна скорость и минимальные задержки.
В одном ТЗ меня сильно зажали по времени — сигнал со входа сразу должен был выдаваться на выход и под ним уже должны были быть данные. Данные-то я, понятно дело, готовил заранее и потом из небольшого буфера выдавал, но у меня не было возможности впихнуть выходной регистр на входной управляющий сигнал, т.к. работал на частоте, которая не могла обеспечить маленькую задержку. В результате он откуда-то выходил (вне моей схемы), я его ещё пару раз считывал (растягивал по схеме) и выдавал куда-то далее (хлопался он там где-то близко регистром или нет?) — вот и представьте какая длина у этой линии в ПЛИСе? Но это уже головная боль была у того, кто весь поект собирал. Наверное не от хорошей жизни так решили делать.
А вот когда я проект собирал. Возник казус с стыком отлаженных схем. Одна схема опрашивала две другие. Один сигнал управления (выбор схемы), второй — запрос готовности. А результат опроса уже анализировался на следюущем такте, т.е. сигнал-то еще надо было развести между двумя другими. Ну да, не продуман был стык. Схемы уже отлажены, никто не горит желанием переделывать) Поставил асинхронный мультиплексор и навесил на него временные ограничения благо частота была небольшая и там запас был хороший.
В одном ТЗ меня сильно зажали по времени — сигнал со входа сразу должен был выдаваться на выход и под ним уже должны были быть данные. Данные-то я, понятно дело, готовил заранее и потом из небольшого буфера выдавал, но у меня не было возможности впихнуть выходной регистр на входной управляющий сигнал, т.к. работал на частоте, которая не могла обеспечить маленькую задержку. В результате он откуда-то выходил (вне моей схемы), я его ещё пару раз считывал (растягивал по схеме) и выдавал куда-то далее (хлопался он там где-то близко регистром или нет?) — вот и представьте какая длина у этой линии в ПЛИСе? Но это уже головная боль была у того, кто весь поект собирал. Наверное не от хорошей жизни так решили делать.
А вот когда я проект собирал. Возник казус с стыком отлаженных схем. Одна схема опрашивала две другие. Один сигнал управления (выбор схемы), второй — запрос готовности. А результат опроса уже анализировался на следюущем такте, т.е. сигнал-то еще надо было развести между двумя другими. Ну да, не продуман был стык. Схемы уже отлажены, никто не горит желанием переделывать) Поставил асинхронный мультиплексор и навесил на него временные ограничения благо частота была небольшая и там запас был хороший.
Асинхронность оправдана только там, где физически без нее не обойтись — перевод сигнала между двумя асинхронными тактовыми сигналами. Во всех остальных случаях это равносильно ужину при свечах на бочке с порохом. У нас индусы умудрились зарелизить асинхронный контроллер. В результате одна микросхема заработала, а вторая нет. После чего я их заставил передать все на кондовую синхронную логику. Ну желающие рискнуть оптимисты всегда найдутся, но я бы не рекомендовал. Если не хватает скорости тактового сигнала — значит синхронизацию нужно делать более быстрым тактовым сигналом.
Проблема упирается в то, что не всегда в наличии присутствует желаемый набор тактов. Иногда можно себе встроенными DCM более высокую частоту сделать и на ней отработать. Перевод сигнала на высокую, перевод на низкую — в конечном счете каждый случай индивидуален и рассматривается есть ли в этом смысл вообще. Но у меня в некоторых проектах, например, запрещено использовать блоки DCM. Т.е. вот есть у тебя такты — вот на них и работать, счётчиком дели и т.д. Если кто-то где-то недодумал, то приходиться крутиться. На раннем этапе разработки, конечно, лучше заставить переделать.
Я бы не стал возводить синхронную работу схемы в безоговорочный принцип. Есть вещи, где некритичны задержки и допустима асинхронная схема. Просто разработчик должен понимать что это может за собой повлечь. И если есть возможность сделать всё по тактам — лучше делать по тактам)
Я бы не стал возводить синхронную работу схемы в безоговорочный принцип. Есть вещи, где некритичны задержки и допустима асинхронная схема. Просто разработчик должен понимать что это может за собой повлечь. И если есть возможность сделать всё по тактам — лучше делать по тактам)
Проблема-то не только в задержках. Проблема еще в том, что асинхронная схема подразумевает использование комбинационных сигналов для упраления другими частями схемы. Это подразумевает, что разработчик обязан обеспечить отсутствие паразитных импульсов на выходе таких комбинационных схем (простейший пример: нарисуйте схему двухвходового мультиплексора на элементах И-ИЛИ-НЕ с ненулевыми задержками элементов, и вы увидите, что когда оба его входа данных равны единице, то при переключении с одного на второй на выходе на некоторое время установится ноль). Но только в ПЛИСах комбинационная логика реализуется на LUT-ах, а в даташитах написано, что отсутствие паразитных импульсов на выходе LUT-ов не гарантируется.
Интересно было бы услышать про сравнение Verilog и VHDL для практических применений, в реальных проектах
Мне тоже интересно, но я пока не изучал VHDL.
А чего тут сравнивать? Примерно 95% коммерческих разработчиков IP (начиная с ARM) используют Verilog. А они, смею вас уверить, не враги сами себе.
VHDL, походу, начинает потихоньку умирать. Косвенное подтверждение тому отсутствие развитие этого языка в отличие от Veriloga. Я сам почти 20 лет назад начинал с VHDL, но уже как лет 8 его не использую — Verilog намного удобнее. Правда есть один момент неприятный — я люблю этот вопрос на собеседованиях задавать: вообще говоря, по стандарту Verilog-2001, нельзя использовать в процессе сигнал, заданный в списке чувствительности процесса. Таким образом Verilog «страхует» вас от намерения переползти в несинхронщину. А VHDL — позволяет, типа охота вам несинхронную схему городить — ну и городите.
А в целом, моё мнение, что VHDL, что Verilog себя изжили: слишком низкоуровневые. За языками типа SystemC будущее!
А в целом, моё мнение, что VHDL, что Verilog себя изжили: слишком низкоуровневые. За языками типа SystemC будущее!
Есть мнение, что языки типа SystemC были неудачным экспериментом, потому что за много лет так по-настоящему и не прижились и даже начали потихоньку умирать.
А Verilog живет, процветает и обвешивается расширениями, тем же SystemVerilog кстати.
А Verilog живет, процветает и обвешивается расширениями, тем же SystemVerilog кстати.
Это SystemC-то отмирает?! Особенно с учётом того, что Xilinx чуть ли уже не основным языком его в Vivado сделал?!
А SystemVerilog абсолютно ничего нового не добавляет к последней версии Veriloga в плане синтеза. Verilog'и, VHDL'и и прочие AHDL'и себя изжили. Они были хорошы пока ПЛИСины были относительно маленькие и многие ещё мыслили категориями 155ой серии. Сейчас писанина навороченных систем обработки сигналов на том жеубогом Верилоге приводит к тому, что вы занимаетесь ловлей блох в виде разъехавшихся тактов вместо того, что бы сосредоточится собственно на воплощении алгоритмов. Для плисоводов «от сохи», для которых плисоводство — это самоцель, проблем нет. Но для остальных это — проблема.
А SystemVerilog абсолютно ничего нового не добавляет к последней версии Veriloga в плане синтеза. Verilog'и, VHDL'и и прочие AHDL'и себя изжили. Они были хорошы пока ПЛИСины были относительно маленькие и многие ещё мыслили категориями 155ой серии. Сейчас писанина навороченных систем обработки сигналов на том же
Verilog, SystemVerilog (и SystemC) не только при разработке ПЛИС используется, но и при разработке ASIC тоже.
Вот, кстати, довольно профессиональное мнение по этому поводу от человека, имевшего отношение в том числе к разработке таких языков:
panchul.livejournal.com/473865.html
Вот, кстати, довольно профессиональное мнение по этому поводу от человека, имевшего отношение в том числе к разработке таких языков:
panchul.livejournal.com/473865.html
Наверное, это дело вкуса / привычки, но я изучал Verilog и VHDL примерно в одинаковом объёме, и для синтеза VHDL мне понравился намного больше. Мне кажется, что он проще, понятнее, предсказуемее и даёт меньше возможностей выстрелить себе в ногу. В Verilog большое несинтезируемое подмножество, и много синтаксического сахара. Много всяких нюансов надо держать в голове. Зато для верификации он, возможно, и проще (а есть ещё System Verilog для высокоуровневой верификации).
Пожалуй, стоит попробовать VHDL, потому что я тоже не любитель держать нюансы в голове.
Я как-то дома себе делал на ПЛИСе платку к компьютеру. Если интересно — посмотрите статью, в ней приведена программа на VHDL, привязанная к конкретному, совсем простому, устройству.
Как-то я озадачился такой трактовкой. В плане несинтезируемой части VHDL куда богаче (чем просто Verilog, SystemVerilog в свою очередь еще навороченней), равно как и куда многословнее. В то же самое время он выглядит более логичным в рамках общего набора конструкций /личное мнение/ и является более надежным за счет строгой типизации данных.
Плюс верилога — лаконичность (кроме бесящего begin — end) и возможность стрелять в ногу под любым углом (если есть на то необходимость).
Плюс верилога — лаконичность (кроме бесящего begin — end) и возможность стрелять в ногу под любым углом (если есть на то необходимость).
С интересом и упоением прочитал первые абзацы проповеди во славу ПЛИСоведения. Однако, в конце третьего абзаца, я неожиданно увидел влияние тлетворных сил! Призываю тебя автор — вернись на путь истинный! Отрекись от соблазнов быстрого написания и короткого кода. Трудолюбием, терпением и прилежностью проторишь ты себе дорогу к твоему будущему, вернувшись в лоно строгой типизации и контроля кода. Да будет ласкать твой взгляд красивый и гармоничный код VHDL!
Не разобраны самые типичные ошибки новичков (множество вложенных if, например) и почему их стоит избегать.
Лично у меня впечатление от общения с ПЛИС совершенно противоположное — если можно обойтись без них, то лучше обойтись. С этими корявыми языками (Verilog/VHDL) с ещё более корявыми синтезаторами, этой области, которая пропитана проприетарщиной и всеми её пороками до мозга костей, лучше избегать.
Лично у меня впечатление от общения с ПЛИС совершенно противоположное — если можно обойтись без них, то лучше обойтись. С этими корявыми языками (Verilog/VHDL) с ещё более корявыми синтезаторами, этой области, которая пропитана проприетарщиной и всеми её пороками до мозга костей, лучше избегать.
Я не сталкивался проблемой вложенных IF, расскажите подробнее.
Вы предпочитаете пользоваться готовыми микросхемами, которые с использованием «корявых языков, еще более корявых синтезаторов, проприетарщины и всех ее пороков» разработали другие люди?
Да. Потому что эти микросхемы доведены до нормального состояния. Они работают как описано (да, бывает неопределённое поведение, бывают даже аппаратные баги, но очень редко). И лично мне не придётся мучиться с тем, с чем уже намучились инженеры Intel, ST Microelectronics, Texas Instruments и т.д.
Усли же каждый у себя в гараже будет на ПЛИС клепать, то качество этих изделий будет… понятно какое. К тому же это удар по экосистеме — когда ты делаешь свою схему с нуля даже без софт процессора (а если и с ним, то кастомной архитектуры), то ты становишься оторван от всего богатства уже написанного кода, который можно было бы применить. Скажете, что можно будет использовать IP-ядра и делать их самим? Пока область IP-ядер находится в зачаточном состоянии. И видели бы вы, например, Memory Interface Generator (позволяющий реализовать контроллер памяти DDR1/2/3 и др.) или ядро 10 Gigabit Ethernet Mac от Xilinx — там столько всего гвоздями прибито не просто под ПЛИС конкретного производителя, а под конкретное семейство.
Усли же каждый у себя в гараже будет на ПЛИС клепать, то качество этих изделий будет… понятно какое. К тому же это удар по экосистеме — когда ты делаешь свою схему с нуля даже без софт процессора (а если и с ним, то кастомной архитектуры), то ты становишься оторван от всего богатства уже написанного кода, который можно было бы применить. Скажете, что можно будет использовать IP-ядра и делать их самим? Пока область IP-ядер находится в зачаточном состоянии. И видели бы вы, например, Memory Interface Generator (позволяющий реализовать контроллер памяти DDR1/2/3 и др.) или ядро 10 Gigabit Ethernet Mac от Xilinx — там столько всего гвоздями прибито не просто под ПЛИС конкретного производителя, а под конкретное семейство.
Отказ от микроконтроллеров конечно хорошо, да только в цене они выигрывают у ПЛИС… И даже не знаю что лучше — потратить лишние человеко-часы на хардкодинг на асме под ARM, или сделать то же на ПЛИС за 5 минут и забубенить на всю партию в 5000 девайсов. Склоняюсь все-таки к потраченным человеко-часам крутого кодера, ибо работа делается один раз, а потом тиражируется на 10-рублевые контроллеры на всю партию(и).
Да, могу согласиться. Тут нужно смотреть на задачу. Если это какой-то замысловатый алгоритм, то МК справится лучше. Да и на случай возможной доработки будет место для маневра. С другой стороны, есть задачи, которые на МК решать трудно или вовсе невозможно (например, генерация каких-нибудь сигналов на высоких частотах).
А вот обсуждать экономическую часть я больше не берусь. Мир экономики и финансов — он вообще другой. Я же из мира техники. Однажды я порассуждал с моим товарищем, у которого свой бизнес. Про ПЛИСы, которые мне просто интересны, про STM, стоимостью которого вообще можно пренебречь, про ARM. А им это вообще не интересно (изящность решения, полет творческо-технической мысли, перспективы развития). Из самых важных моментов он мне назвал: 1) сможешь ли ты в принципе с делать такое устройство; 2) как быстро ты сделаешь это устройство (чем быстрее, тем лучше). Про стоимость, ценообразование настоятельно рекомендовалось не рассуждать.
Но еще мне просто интересна ПЛИС, как платформа для разработки. Поэтому мы ее и обсуждаем.
А вот обсуждать экономическую часть я больше не берусь. Мир экономики и финансов — он вообще другой. Я же из мира техники. Однажды я порассуждал с моим товарищем, у которого свой бизнес. Про ПЛИСы, которые мне просто интересны, про STM, стоимостью которого вообще можно пренебречь, про ARM. А им это вообще не интересно (изящность решения, полет творческо-технической мысли, перспективы развития). Из самых важных моментов он мне назвал: 1) сможешь ли ты в принципе с делать такое устройство; 2) как быстро ты сделаешь это устройство (чем быстрее, тем лучше). Про стоимость, ценообразование настоятельно рекомендовалось не рассуждать.
Но еще мне просто интересна ПЛИС, как платформа для разработки. Поэтому мы ее и обсуждаем.
Значит, по своему многолетнему опыту я вам докладываю: есть совершенно чёткая линия, где работает проц, а где — плисина. Плисина работает там, где тупо не хватает скорости DSP-процессора и алгоритм имеет характер конвеерного, или, проще говоря, «беспрерывного однотипного молочения данных». Например, валятся у вас отсчёты с квадратурных АЦП от радиоприёмного фронт-енда. Частота оцифровки мегагерц так 150, разрядность — около 16. На каком, простите, проце вы будете ddc делать? От такого потока даже последние варианты интеловских каменюг задохнутся! Но с этой задачей легко справится даже чуть ли не первый Стратикс стоимостью 40 баксов.
Вообще, обычно грамотные ребята системы обработки строят на комбинации: ПЛИС + дээспишник или мощный арм. Плисина молотит всё, что быстро и однообразно (т.е. без сложных ветвлений), а проц добивает то, что медленно и с большим количеством «если». Это — правильный путь, всё остальное — способ попасть на счётчик у заказчика.
Вообще, обычно грамотные ребята системы обработки строят на комбинации: ПЛИС + дээспишник или мощный арм. Плисина молотит всё, что быстро и однообразно (т.е. без сложных ветвлений), а проц добивает то, что медленно и с большим количеством «если». Это — правильный путь, всё остальное — способ попасть на счётчик у заказчика.
Извиняюсь за ответ на очень старый коммент, но я соглашусь.
У меня STM32F407 очень тяжело справляется с преобразованием потока данных 24 бит 48k smp/s сначала в 24 бит 384k smp/s, потом в 9 бит 384k посредством дельта-сигма модуляции. А на МК возложена еще и куча других задач. Потому эту задачу я отвел для FPGA. Даже дешевый вариант Cyclone II (EP2C5T144C8N) справляется с преобразованием и дальнейшей обработкой этого потока просто на ура. По барабану даже на то, что там КИХ фильтр высокого порядка для апсемплинга.
Собственно, с этой задачи и началось мое освоение ПЛИС. Освоил быстро, благо с логической схемотехникой был знаком даже до освоения микроконтроллеров. В качестве языка выбрал Verilog. Писанины на нем меньше, чем на VHDL. Тот же КИХ писал сам. В железе заработал сразу, так как при разработке следовал стандарту: Строгая синхронщина, управляемая конечным автоматом. И так во всех функциональных модулях. Проект сложный, в нем я сразу столкнулся со всем многообразием методов отстрелить себе ногу. Столкнулся даже с синхронизацией между разными тактовыми доменами. Но все построил так, что Таймквесту достаточно было только сказать, какие и откуда у меня тактовые частоты и больше ничего ему не потребовалось.
Можете подсказать, есть ли практика использования FPGA для general purpose computaiton или еще даже для реализации внутренней логики приложений.
Есть ли в этом какой то реальный смысл и польза или овчинка выделки не стоит? Есть какие то наработки по использованию привычного opencl с fpga (хотя бы в виде конвертера в verilog)?
Есть ли в этом какой то реальный смысл и польза или овчинка выделки не стоит? Есть какие то наработки по использованию привычного opencl с fpga (хотя бы в виде конвертера в verilog)?
FPGA должна конфигурироваться под конкретную задачу, иначе проще и дешевле взять чип общего назначения. Из того, что вспомнилось:
Microsoft Bing использует аппаратное ускорение на базе FPGA Altera ссылка
OpenCL — модная тема у альтеры, опять же, последний год-два. Но каких они там успехов добились сказать сейчас не готов.
Microsoft Bing использует аппаратное ускорение на базе FPGA Altera ссылка
OpenCL — модная тема у альтеры, опять же, последний год-два. Но каких они там успехов добились сказать сейчас не готов.
Sign up to leave a comment.
ПЛИС — мои первые шаги