Тоже хотелось бы вставить 5 копеек. Кроме negedge по клоку (за который отрубить руки не жалко) и неблокирующего присваивания, вкорне неверно утверждение «FPGA Altera Max 10, которая имеет 32 разрядную архитектуру». У ПЛИС нет никакой «архитектуры», FPGA-дизайнер сам создаёт нужную архитектуру, а то что Вы назвали 32-разрядной архитектурой — просто тип примитива 32*32, который:
а) может быть по-разному сконфигурирован
б) не обязан быть «квадратным»
Поэтому настоятельно рекомендую заменить параметр word_size в разрядности данных и адреса, на 2 разных параметра: word_length и addr_legth. Причём второй может быть производным от параметра ram_depth, по следующей закономерности addr_legth = $clog2(ram_depth) (clog2 для чистого Verilog'а придётся задать дефайнами).
Так будет и понятнее и не будет вводить в заблуждение.
З.Ы. И да, статья выглядит как добавление русских комментариев к файлу скачанному из недр Гита.
Глобально я согласен. Но вот ещё аргумент: все тулы ФПГАшника работают на TCL скриптах (Вивада, Моделсим, Альтера). Туда уже Пайтон не запихнуть, а основная разработка происходит именно там, по крайней мере у меня.
Так а чем же всё-таки хуже bash? Просто потому что не поддерживает фреймворки в VS Code или Notepad++? Те же действия использую для своих скриптов но написанные на чистом bash'е. Ничего криминального или сложного. Разве что когда нужен доступ на «незнакомый» сервер или новую линукс машину, не нужно убеждаться, что там есть Пайтон и т.п.
Про куллеры — согласен. И меня достаточно давно беспокоит этот вопрос. Главное НО — крышка процессора же из алюминия сделана! Как же тогда быть? Или там какой-то сплав не алюминиевого происхождения?
Тут ещё есть момент с DE. Мне к примеру нравится KDE, но софт, которым я пользуюсь имеет официальную поддержку только Ubuntu, SUSE, Red Hat и CentOS. Не то чтобы он не работал на других дистрибутивах, но если есть официальная поддержка, то оно и протестировано и в поддержке помогут. А не ставить неизвестный дистрибутив и потом удивляться, что где-то оно нефурычит.
Выполнить точные измерения реально, но зачем? Как эксперимент на коленке с вкраплениями «ненормального программирования» этого достаточно. Как реальный проект для конкретных задач… лучше не стоит себя обнадёживать. Да, такие схемы работоспособны как делитель при правильных констрейнах, но не более.
Что действительно важно, повторюсь, это понять принципы работы констрейнов, занятся floorplan'ом и зафиксировать синтезированную схему (можно жёстко, можно по partition'ам), а также написать сопутствующие констрейны.
Когда Вы добьётесь 100% повторяемости эксперимента для разных конфигураций и с различными компонентами (как часто бОльшего проекта или дублирование текущего в 3-4 местах), тогда вы пройдёте половину нужного пути.
Дальше придётся разобраться на каких примитивах это всё построено, почему на них и как они работают. Чем отличается DSP от сумматора на LUT'ах и т.п. Также рекомендую уменьшить разрядность счётчика до адекватного. Реально контролировать изменения в 20-50 единиц не требует 2^32 счётчика. Оно и места занимает и частоту садит.
Что же касается ответа на вопрос «как провести подобные измерения в Ваших условиях» дам подсказку и если будет желание можете попробовать решить: Вам нужно построить схему детектирования, которая будет работать на порядки быстрее анализируемого компонента. тогда с точностью этого порядка Вы сможете вычислить реальную генерированную частоту. По сути нужно погуглить фразу «time to digital converter», которая внесёт кое-какую ясность.
Ваши мега эксперименты попахивают филькиной грамотой. Не могут компоненты ПЛИС работать нормально на частотах выше 1ГГц (да и гигагерц — это почти фантастика), а то что у Вас получилось — это просто шум в кремние с «какой-то» фильтрацией, подогнанной для получения результатов высосанных с пальца.
И причина то не в глупости, а упрямстве скорее. Если бы Вы послушали знающих людей, они бы Вам рассказали, насколько шумит Ваш синтетический клок, какие методики есть устранения этого шума, а также показали вам вот такой документ для Kintex, где чёрным-по-белому написано, что максимальная частота работы единичного слайса (CPL), включительно FF, как составляющих, не может быть выше 5.5 ГГц (Setup + Hold), но при этом нужно учитывать время на Рутинг, который в Вашем случае произошёл как попало. С того же документа, можно выяснить, что максимальное время переключения мультиплексора порядка 0,4 нс — а это не более 2,5 ГГц рабочей частоты.
Если же заглянуть в документацию по Virtex-5, так там в табличке на с.28 и вовсе указаны максимальные рабочие частоты для компонентов, которые не превышают даже 500 МГц. Соответственно как у Вас получились фантастические измерения выше гигагерцов, при максимальных рабочих частотах кристалла до полугигагерца остаётся загадкой.
И это не говоря, про разброс в температурных режимах, про то, какой skew фронта у полученного «клока», про его джиттер (тут вообще страшно представить что творится) и шум.
Это написано не для оскорбления, но для того чтобы побудить автора разобраться что такое setup/hold флип-флопа, базовые принципы routing'а и фиксации проекта на floorlan, трассировки и констрейнов.
Дабы комментарий не показался голословным, у меня имеется проект по детектированию частот порядка 1.2 ГГц (расчётно) с внешнего источника, который реальную точность выдаёт не более 800-900 МГц. И схемы там накручены похлеще вашего счётчика (32-бит!!! ЗАЧЕМ? КАК?) с очень медленным компаратором и комбинационным сложением (для Xilinx есть сложение через CSA — намного менее ресурсоёмкое и быстрое).
А при чём тут RISC? Там и архитектура и микроархитектура абсолютно другая. Вопрос задавался об оценке работы на одинаковом процессоре. То есть зависимость именно софтверная.
И я бы не сказал, что небольшое количество быстрых инструкций лучше — i386 и x86-64 до сих пор занимают 100% десктопных PC. Почему? Наверное потому что они лучше. А всякие АРМы удел мобильных систем, потому что там очень нужна экономия заряда (и то половина мобильных ПК остаются на CISC архитектуре с огромным успехом).
Мне вот как разработчику на FPGA интересно было бы провести некоторые параллели или скорее узнать у осведомлённых, что лучше: одна и та же программа с использованием минимального набора инструкций или наоборот максимального с изменением типа инструкции каждый такт (желательно).
Для параллельных систем понятно, что чем больше распараллеливания, тем проще обработка.
Для процессорных с одной стороны нет разницы, но вот если задуматься… По сути набор одинаковых инструкций задействует одни и те же цепи логических элементов, соответственно тепловыделение данных микрозон будет больше. С другой стороны, если будет задействовано максимальное разнообразие инструкций, с частой сменой логических последовательностей между тактами, нагрев микрозон процессора будет меньше и теплоотвод увеличится (теоретически) и получится некое распределение инструкций. Соответственно меньше температура -> больше частота (меньше троттлинг).
Статья просто бомба. Сам не занимаюсь схемотехникой, но когда разрабатывал под ПЛИС часто приходилось со схемотехника и ломать голову над проблемами на платах.
Ещё бы кто-то написал полную статью справочник про типы пинов на микроконтроллерах. Все эти LVDS с Hi-Z, Pull-up и Pull-Down.
«По ту сторону закона Мура» будет ровно то, что сейчас творится на рынке мобильных процессоров, которые и радо бы загнулись уже, но неадекватный спрос порождает такое же предложение.
Поясню точнее — нужно больше производственной мощности, меньше тепловыделения/энергопотребления и самое важное — максимально оптимизированное ПО для этих задач.
Я часто слышу истории про геймдейвов, когда им не хватает оперативки и решение " а давайте добавим ещё в требования". Когда системы упрутся в потолок (условно, скорее всего такого не будет никогда) придётся заниматься оптимизацией потребляемых ресурсов; вырезанием ненужных библиотек и краеугольным камнем станет поддержка многопоточности/распараллеливания процессов (если верить неким слухам, то скоро AMD сможет представить 4 потока на 1 ядро).
Как было сказано, самое правильное решение — уменьшение рабочей частоты с сохранением производительности. Чем это можно добится? Как минимум задействовав несколько целевых ядер (как в мобильных телефонах), которые будут отвечать за свою узкую задачу. Или сделать реконфигурируемую систему — некий гибрид FPGA-CPU, с гибкостью первого и производительностью второго.
Чего это позволит добится? Ну как минимум уменьшение энергопотребления (опять таки в телефонах это самая первая задача). Как максимум… Никто не задумывался, почему есть 32-х слойные памяти и нет 2-х слойных процессоров? потому что теплоотвод не позволяет. Если же получится уменьшить теплогенерацию, то почему бы не «наслоить» одно ядро на второе (тут снова Мур будет в силе) или ядро на память или… В общем перспектив очень много.
Раз пошла такая бодяга, у меня есть тоже слово, которое хочется постоянно ввернуть:
concrete — первый перевод бетон, второй скорее относится к точный/достоверный, чем к конкретный (хотя и переводится как конкретный). Если хотите сказать конкретный/определённый человек, цвет, день — particular man, particular color, particular day.
Наличие двух значений 1.00e+18, скорее всего связано с параллельным подключением к каждому из слогаемых(умножаемых) по отдельности, что увеличивает скорость преобразования и избавляет от лишей логики (мультиплексоры и net'ы).
Обычно при комплектации состава, который проходит несколько «зон» с разными системами автоматики, используют универсальный доукомплектованый локомотив. В нём соединяют все системы с которыми придётся коннектится поездной бригаде на пути следования. Из-за этого Европейцы сильно страдали во время развития систем автоматики, так как там дорог мало, а государств много и приходилось цеплять по 3-4 системы в один локомотив. Сейчас бОльшая часть ЕС оборудована унифицированными системами, а СНГ-шные поезда далеко не заезжают. По сути до первой большой станции, где поменяют на «ихнюю» поездную бригаду и локомотив.
И тем не менее, почему по-вашему, ещё живёт и процветает VHDL? Причём он занимает чуть ли не половину проектов большой двойки. Всё потому что он настолько однозначен, что любая разработка на нём не принесёт двуякой трактовки и скрытых объявлений. А это зачастую решающий фактор в ответственных системах.
Ну и действительно, как сказал nerudo синтезируемые подмножество языка невелико. А вот разные примитивы для тестирования — они то и создают зачастую ненужные страницы описания.
Про перевод с HDL в LLHD не знал/недопонял. Идея неплохая, но ещё один слой в цепочке преобразований — ИМХО не самая лучшая идея. Опять таки повторюсь до момента получения синтезированного не листа — это лишь чрезвычайно малая доля разработки. Процентов этак 10-15 от силы. Самый большой геморрой начинается на уровне имплементации с констрейнами и плясками вокруг кривизны инструментов. Чего нельзя избежать ввиду проприетарности финальных этапов (P&R) для конкретного разработчика кристаллов
Дело в том, что и Verilog и VHDL — очень большие и сложные
Про VHDL полностью согласен, но на то есть свои причини (жёсткая типизация).
Про Verilog же категорически не соглашусь, а если быть точнее про его надстройку SystemVerilog. Он максимально гибок и предельно оптимизирован, если участь, что разработчик должен заниматься построением иерархических структурных моделей, а не лепить всю схему в один файл.
Опять таки структурное описание (на более высоком уровне) обусловлено как минимум двумя факторами:
1. Наличие проприетарных/авторских/встроенных IP ядер, которые часто и являются средством передачи различных технологий сторонним производителям без открытия «фирменных фишек»/патентов.
2. Более понятное с точки зрения електроники распределённое проектирование параллельных систем. Что также упрощает глобальное восприятие сложных проектов.
Так что приведённый пример нового языка физически плюсов никаких не приносит (если сравнивать по простоте с SV), а упрощение моделирования выглядит достаточно спорно как со стороны соответствия моделируемой конструкции реальному проекту, так и в дальнейшем применении (настоящие проблемы начинаются в месте когда виртуальные данные переходят в «железо»).
Опять же всё бы хорошо, если бы отраслевые предприятия (от Xilinx и Altera/Intel до Lattice и Gowin) стремились внедрить что-то новое. А так не все синтезаторы поддерживают стандарт VHDL-2002 (правила 2002 года) и весь функционал SystemVerilog. Что тогда говорить про кардинально новый язык.
P.S. Не подумайте я не злой хомяк, который отрицает всё новое. Просто мне кажется, что пройдёт ОЧЕНЬ много времени когда поддержу предложенного языка только начнут обговаривать. А до тех пор может случится так, что он уже и не понадобится ибо проектирование на HDL будет полностью вытеснено HLS'ами как это случилось с Ассемблером и его потомками
Пишу как разработчик Firmware (то есть в данной области разбираюсь не очень). А разве в настройках компилятора нет настроек-«стратегий», чтобы оптимизировать/порезать ненужное? При разработке Hardware это является самым основным в работе.
Очень интересная идея. И даже гипотетически сейчас вполне реализуемая за условно небольшие деньги. Если хардварно построить всё на единственной MPSoC FPGA с внушительным набором, то можно даже VR поднять. Правда будет достаточно примитивно и без разных красивых визуализаций. Но энергопотребление… Это вечная проблема. Хотя вохможно сделать многозадачную клавиатуру-хаб (с большим количеством дополнительных кнопок для, к примеру, быстрого переключения между виртуальными мониторами — ведь человек может смотреть только в одну точку одновременно) и пользоваться отображением на чём попадёт под руку (для мобильности) или через время появятся цветные мониторы на e-ink с вменяемой скоростью переключения — будет прикольно. Елинственное что очень нужно — это поменять интерфейс, который будет способствовать многофункциональности/многозадачности.
Чуть выше я ответил на вопрос. Добавлю, что хотя «продвигать» FPGA в массы и является благородной целью, тем не манее даже сами производители не всегда открывают полную документацию для разработчиков. Что приводит к куче инливидуальных разработок и неоднократных наступаний на грабли.
а) может быть по-разному сконфигурирован
б) не обязан быть «квадратным»
Поэтому настоятельно рекомендую заменить параметр word_size в разрядности данных и адреса, на 2 разных параметра: word_length и addr_legth. Причём второй может быть производным от параметра ram_depth, по следующей закономерности addr_legth = $clog2(ram_depth) (clog2 для чистого Verilog'а придётся задать дефайнами).
Так будет и понятнее и не будет вводить в заблуждение.
З.Ы. И да, статья выглядит как добавление русских комментариев к файлу скачанному из недр Гита.
Что действительно важно, повторюсь, это понять принципы работы констрейнов, занятся floorplan'ом и зафиксировать синтезированную схему (можно жёстко, можно по partition'ам), а также написать сопутствующие констрейны.
Когда Вы добьётесь 100% повторяемости эксперимента для разных конфигураций и с различными компонентами (как часто бОльшего проекта или дублирование текущего в 3-4 местах), тогда вы пройдёте половину нужного пути.
Дальше придётся разобраться на каких примитивах это всё построено, почему на них и как они работают. Чем отличается DSP от сумматора на LUT'ах и т.п. Также рекомендую уменьшить разрядность счётчика до адекватного. Реально контролировать изменения в 20-50 единиц не требует 2^32 счётчика. Оно и места занимает и частоту садит.
Что же касается ответа на вопрос «как провести подобные измерения в Ваших условиях» дам подсказку и если будет желание можете попробовать решить: Вам нужно построить схему детектирования, которая будет работать на порядки быстрее анализируемого компонента. тогда с точностью этого порядка Вы сможете вычислить реальную генерированную частоту. По сути нужно погуглить фразу «time to digital converter», которая внесёт кое-какую ясность.
И причина то не в глупости, а упрямстве скорее. Если бы Вы послушали знающих людей, они бы Вам рассказали, насколько шумит Ваш синтетический клок, какие методики есть устранения этого шума, а также показали вам вот такой документ для Kintex, где чёрным-по-белому написано, что максимальная частота работы единичного слайса (CPL), включительно FF, как составляющих, не может быть выше 5.5 ГГц (Setup + Hold), но при этом нужно учитывать время на Рутинг, который в Вашем случае произошёл как попало. С того же документа, можно выяснить, что максимальное время переключения мультиплексора порядка 0,4 нс — а это не более 2,5 ГГц рабочей частоты.
Если же заглянуть в документацию по Virtex-5, так там в табличке на с.28 и вовсе указаны максимальные рабочие частоты для компонентов, которые не превышают даже 500 МГц. Соответственно как у Вас получились фантастические измерения выше гигагерцов, при максимальных рабочих частотах кристалла до полугигагерца остаётся загадкой.
И это не говоря, про разброс в температурных режимах, про то, какой skew фронта у полученного «клока», про его джиттер (тут вообще страшно представить что творится) и шум.
Это написано не для оскорбления, но для того чтобы побудить автора разобраться что такое setup/hold флип-флопа, базовые принципы routing'а и фиксации проекта на floorlan, трассировки и констрейнов.
Дабы комментарий не показался голословным, у меня имеется проект по детектированию частот порядка 1.2 ГГц (расчётно) с внешнего источника, который реальную точность выдаёт не более 800-900 МГц. И схемы там накручены похлеще вашего счётчика (32-бит!!! ЗАЧЕМ? КАК?) с очень медленным компаратором и комбинационным сложением (для Xilinx есть сложение через CSA — намного менее ресурсоёмкое и быстрое).
И я бы не сказал, что небольшое количество быстрых инструкций лучше — i386 и x86-64 до сих пор занимают 100% десктопных PC. Почему? Наверное потому что они лучше. А всякие АРМы удел мобильных систем, потому что там очень нужна экономия заряда (и то половина мобильных ПК остаются на CISC архитектуре с огромным успехом).
Для параллельных систем понятно, что чем больше распараллеливания, тем проще обработка.
Для процессорных с одной стороны нет разницы, но вот если задуматься… По сути набор одинаковых инструкций задействует одни и те же цепи логических элементов, соответственно тепловыделение данных микрозон будет больше. С другой стороны, если будет задействовано максимальное разнообразие инструкций, с частой сменой логических последовательностей между тактами, нагрев микрозон процессора будет меньше и теплоотвод увеличится (теоретически) и получится некое распределение инструкций. Соответственно меньше температура -> больше частота (меньше троттлинг).
Статья просто бомба. Сам не занимаюсь схемотехникой, но когда разрабатывал под ПЛИС часто приходилось со схемотехника и ломать голову над проблемами на платах.
Ещё бы кто-то написал полную статью справочник про типы пинов на микроконтроллерах. Все эти LVDS с Hi-Z, Pull-up и Pull-Down.
Поясню точнее — нужно больше производственной мощности, меньше тепловыделения/энергопотребления и самое важное — максимально оптимизированное ПО для этих задач.
Я часто слышу истории про геймдейвов, когда им не хватает оперативки и решение " а давайте добавим ещё в требования". Когда системы упрутся в потолок (условно, скорее всего такого не будет никогда) придётся заниматься оптимизацией потребляемых ресурсов; вырезанием ненужных библиотек и краеугольным камнем станет поддержка многопоточности/распараллеливания процессов (если верить неким слухам, то скоро AMD сможет представить 4 потока на 1 ядро).
Как было сказано, самое правильное решение — уменьшение рабочей частоты с сохранением производительности. Чем это можно добится? Как минимум задействовав несколько целевых ядер (как в мобильных телефонах), которые будут отвечать за свою узкую задачу. Или сделать реконфигурируемую систему — некий гибрид FPGA-CPU, с гибкостью первого и производительностью второго.
Чего это позволит добится? Ну как минимум уменьшение энергопотребления (опять таки в телефонах это самая первая задача). Как максимум… Никто не задумывался, почему есть 32-х слойные памяти и нет 2-х слойных процессоров? потому что теплоотвод не позволяет. Если же получится уменьшить теплогенерацию, то почему бы не «наслоить» одно ядро на второе (тут снова Мур будет в силе) или ядро на память или… В общем перспектив очень много.
concrete — первый перевод бетон, второй скорее относится к точный/достоверный, чем к конкретный (хотя и переводится как конкретный). Если хотите сказать конкретный/определённый человек, цвет, день — particular man, particular color, particular day.
И тем не менее, почему по-вашему, ещё живёт и процветает VHDL? Причём он занимает чуть ли не половину проектов большой двойки. Всё потому что он настолько однозначен, что любая разработка на нём не принесёт двуякой трактовки и скрытых объявлений. А это зачастую решающий фактор в ответственных системах.
Ну и действительно, как сказал nerudo синтезируемые подмножество языка невелико. А вот разные примитивы для тестирования — они то и создают зачастую ненужные страницы описания.
Про перевод с HDL в LLHD не знал/недопонял. Идея неплохая, но ещё один слой в цепочке преобразований — ИМХО не самая лучшая идея. Опять таки повторюсь до момента получения синтезированного не листа — это лишь чрезвычайно малая доля разработки. Процентов этак 10-15 от силы. Самый большой геморрой начинается на уровне имплементации с констрейнами и плясками вокруг кривизны инструментов. Чего нельзя избежать ввиду проприетарности финальных этапов (P&R) для конкретного разработчика кристаллов
Про VHDL полностью согласен, но на то есть свои причини (жёсткая типизация).
Про Verilog же категорически не соглашусь, а если быть точнее про его надстройку SystemVerilog. Он максимально гибок и предельно оптимизирован, если участь, что разработчик должен заниматься построением иерархических структурных моделей, а не лепить всю схему в один файл.
Опять таки структурное описание (на более высоком уровне) обусловлено как минимум двумя факторами:
1. Наличие проприетарных/авторских/встроенных IP ядер, которые часто и являются средством передачи различных технологий сторонним производителям без открытия «фирменных фишек»/патентов.
2. Более понятное с точки зрения електроники распределённое проектирование параллельных систем. Что также упрощает глобальное восприятие сложных проектов.
Так что приведённый пример нового языка физически плюсов никаких не приносит (если сравнивать по простоте с SV), а упрощение моделирования выглядит достаточно спорно как со стороны соответствия моделируемой конструкции реальному проекту, так и в дальнейшем применении (настоящие проблемы начинаются в месте когда виртуальные данные переходят в «железо»).
Опять же всё бы хорошо, если бы отраслевые предприятия (от Xilinx и Altera/Intel до Lattice и Gowin) стремились внедрить что-то новое. А так не все синтезаторы поддерживают стандарт VHDL-2002 (правила 2002 года) и весь функционал SystemVerilog. Что тогда говорить про кардинально новый язык.
P.S. Не подумайте я не злой хомяк, который отрицает всё новое. Просто мне кажется, что пройдёт ОЧЕНЬ много времени когда поддержу предложенного языка только начнут обговаривать. А до тех пор может случится так, что он уже и не понадобится ибо проектирование на HDL будет полностью вытеснено HLS'ами как это случилось с Ассемблером и его потомками