Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
Интересный подход, но мне кажется, что он размывает мысленную связь между написанным кодом и представлением, как это будет выглядеть в RTL viewer.
Когда я пишу always @(posedge clk) if(a) b<= data; то я мысленно представляю, что это будет регистр с сигналом разрешения записи.
Когда я пишу always @(posedge clk) if(a) b<= data else b<=data2; то для меня это мультиплексор данных на входе регистра. Я так пишу и представляю. С вашим подходом такое мысленное представление не получится (или его труднее увидеть).
Причем я заметил, что громоздкие конструкции, где много if-else как правило выглядят в RTL viewer ужасно (много мультиплексоров) и схема в ПЛИС становится медленной, Fmax падает.
То есть, громоздкие конструкции с многими if-else, которые выбирают приоритет выполнения операций есть проблемы. Желательно их избегать, желательно не более 2х последовательных if-else. Синтезатор то их синтезирует — вроде бы проблем нет. Но будет ли удачно все потом упаковано фитером?
В вашем подходе так же присутствуют «незримые if-else» на которые вы предлагаете не обращать внимания, мол синтезатор справится. Эдакое движение в сторону высокоуровневых языков программирования.
Ну не знаю… не уверен…
Когда я пишу always @(posedge clk) if(a) b<= data; то я мысленно представляю, что это будет регистр с сигналом разрешения записи.
Когда я пишу always @(posedge clk) if(a) b<= data else b<=data2; то для меня это мультиплексор данных на входе регистра. Я так пишу и представляю. С вашим подходом такое мысленное представление не получится (или его труднее увидеть).
Причем я заметил, что громоздкие конструкции, где много if-else как правило выглядят в RTL viewer ужасно (много мультиплексоров) и схема в ПЛИС становится медленной, Fmax падает.
То есть, громоздкие конструкции с многими if-else, которые выбирают приоритет выполнения операций есть проблемы. Желательно их избегать, желательно не более 2х последовательных if-else. Синтезатор то их синтезирует — вроде бы проблем нет. Но будет ли удачно все потом упаковано фитером?
В вашем подходе так же присутствуют «незримые if-else» на которые вы предлагаете не обращать внимания, мол синтезатор справится. Эдакое движение в сторону высокоуровневых языков программирования.
Ну не знаю… не уверен…
Все верно, вы просто обладаете «схемным» мышлением и занимаетесь описанием именно схем. Плюсы вашего подхода максимальная эффективность, минусы он требует большего опыта, определенного типа мышления и вы лишаете синтезатор свободы творчества и вариантов оптимизации, во всяком случае ограничиваете.
Действительно я пытаюсь сместить акцент с описание схемы на описание результата, пытаясь упростить и ускорить процесс, перекладывая часть обязанностей на синтезатор. Сейчас много кто перестал считать такты контроллеров в угоду удобных шаблонов и архитектур. Я предлагаю такое же движение, но в области ПЛИС.
Действительно я пытаюсь сместить акцент с описание схемы на описание результата, пытаясь упростить и ускорить процесс, перекладывая часть обязанностей на синтезатор. Сейчас много кто перестал считать такты контроллеров в угоду удобных шаблонов и архитектур. Я предлагаю такое же движение, но в области ПЛИС.
Есть сомнения, что при таком описании асинхронного ресета он будет правильно воспринят при синтезе.
я тут вижу только синхронные ресеты, или я чего-то не понимаю?
Строго говоря есть документ со стандартными конструкциями описания под каждый синтезатор, и даже иногда семейство ПЛИС. Асинхронный сброс и установка входит в набор стандартных конструкций. Чтобы синтезатор правильно воспринял ту или иную конструкцию она должна быть описана согласно документу. Так что в общем случае ваши сомнения обоснованы, асинхронный сброс может быть обработан неверно в таком описании.
Но в предложенном варианте я ограничился синхронными схемами.
С асинхронными сигналами есть сложность связанная с тем что реально он работает по уровню, а в верилоге описывается как действие по фронту. То есть это некое такое соглашение что мы описываем так, хотя понимаем что работать будет эдак.
Но в предложенном варианте я ограничился синхронными схемами.
С асинхронными сигналами есть сложность связанная с тем что реально он работает по уровню, а в верилоге описывается как действие по фронту. То есть это некое такое соглашение что мы описываем так, хотя понимаем что работать будет эдак.
Ну т.е. это вы такой небольшой конвейер написали одним always блоком? — вполне стандартный подход. У меня даже была мысль когда-то написать небольшой процессор одним always-блоком.
Кстати современные SystemC синтезаторы поддерживают запись сигнала из разных процессов, если это происходит на разных тактах — просто вставляют мультиплескор. Запись сигнала из разных процессов на одном такте — undefined behavior.
Кстати современные SystemC синтезаторы поддерживают запись сигнала из разных процессов, если это происходит на разных тактах — просто вставляют мультиплескор. Запись сигнала из разных процессов на одном такте — undefined behavior.
Подход правильный. Я использую подобные конструкции для сигнала сброса на VHDL. Это прекрасно работает.
Но вот при сравнении VHDL и Verilog надо помнить, что VHDL имеет очень серьёзное преимущество. Это структуры, которые определяются типом record. Это позволяет очень сильно упростить описание сложных шин, например AXI. Но это уже есть в System Verilog
Но вот при сравнении VHDL и Verilog надо помнить, что VHDL имеет очень серьёзное преимущество. Это структуры, которые определяются типом record. Это позволяет очень сильно упростить описание сложных шин, например AXI. Но это уже есть в System Verilog
А в SystemC есть modular interfaces, которые позволяют посылать AXI транзакции с помощью простых function-call'ов вроде axi_master.send_write_request (address, data, flags)
Да и шаблоны в C++ мощнее чем record'ы в VHDL, можете ли вы например написать record для AXI payoad'a с параметризируемой шириной адреса и данных?
Написать могу. И даже в некоторых системах это будет промоделировано. С++ предлагает более высокий уровень программирования, сейчас это активно развивается и возможно будет активно использоваться. А может и не будет — пока это не понятно. А VHDL это имеет с 1976 года (если я не ошибаюсь). Лично я тип record использую ~16 лет.
Для начала, нужно выбрать язык описания. На текущий момент использование языков типа System Verilog, SystemC и т.п., именно для создания схем, больше похоже на сделку с дьяволом, чем на работу. Поэтому еще в строю старинные и базовые VHDL и Verilog.
Ну что за вопиющее ретроградство. SystemVerilog это надмножество Verilog'a и все конструкции там будут работать (за редчайшими исключениями). Но в SystemVerilog'e значительное количество приятных плюшек, в том числе затрудняющих стрельбу по задним конечностям (это я про синтез, удобство верификации SystemVerilog просто без шансов рвёт Verilog). Ознакомьтесь, пожалуйста, с документом «Verilog Gotchas». Там приводятся типичные ошибки, которые допускают программисты на Verilog/SystemVerilog и как их избегать. Думаю Ваш взгляд на best practices несколько изменится.
Что касается чисто философского вопроса: «думать как программист» vs «думать как схемотехник». По собственному опыту «воспитания» из «программистов обычных C/C++» -> «программистов обычных Verilog/SystemVerilog» пришёл к выводу, что пока не изменится мышление с, условно так скажем, «последовательного» на «параллельное» ничего хорошего из под них не получить. Есть, конечно, SystemC и подобные инструменты и когда-нибудь они будут доминировать, но пока качество генерации ни по размеру ни по частоте не дотягивает до грамотно написаного вручную кода. Собстна, ситуация напоминает историю с Assembler/C vs «языки с более высоким уровнем абстракции». Вот интел прикупил альтеру, ждём когда процесс программирования FPGA станет более человечным. Даёшь Java/C#-подобное для ПЛИСов =)
Естественно я пишу и на SystemVerilog тоже, а также я имею некоторый опыт проблем даже со стороны симуляторов по полноте поддержки систем верилога не говоря про синтезаторы. Именно поэтому пока бы я его не рекомендовал, особенно тем кто только начинает.
Да вы правы, все очень похоже на переход с ассемблера на С и далее, и аргументы примерно такие же. Поживем увидим чем дело кончится.
Спасибо за мнение, мне правда это важно.
Да вы правы, все очень похоже на переход с ассемблера на С и далее, и аргументы примерно такие же. Поживем увидим чем дело кончится.
Спасибо за мнение, мне правда это важно.
Естественно я пишу и на SystemVerilog тоже, а также я имею некоторый опыт проблем даже со стороны симуляторов по полноте поддержки систем верилога не говоря про синтезаторы. Именно поэтому пока бы я его не рекомендовал, особенно тем кто только начинает.Я, собственно, ограничен только Quartus/ModelSim, а потому не могу судить о поддержке SV в других инструментах. Но в этих поддерживается практически всё (впрочем, синтезатор Quartus'a несколько ограничен, но это экзотика).
Вот чего мне не хватает так это иерархии в SV. То есть в проекте не может быть два модуля с одним именем, поскольку namespace для модулей не завезли (package может содержать много чего, имитируя namespace, но модули содержать, увы, не может). VHDL предлагает концепцию library, что вполне может заменить namespace, но мне лень шлёпать по кнопкам в таком количестве. VHDL слишком «шумный» и строгий. Впрочем это его плюс в качестве самодокументации кода и отсеивания кучи ошибок уже на этапе компиляции (если VHDL скомпилировался, вероятность, что оно заработает правильно выше чем в SV).
Сталкивался с неполной поддержкой интерфейсов, а они по моему мнению составляют львиную долю преимуществ. Вам повезло у вас очень хорошая среда для SV. У ксалинкса большой бардак с этим, фактически 6 серию они по SV не поддержали. Некоторые АСИК тулзы тоже имеют неприятные приколы.
К сожалению приходится порой сталкиваться, в Vivado, к примеру, с сообщениями типа is not supported yet. Так что приходится быть осторожным…
в процессе прочтения статьи почему то вспомнилось высказывание — физик-ядерщик легко научится штукатурить, но вот штукатур никогда не запустит ядерный реактор. так и тут — «железячник» легко станет программистом, программист врядли станет «железячником».
автор предлагает за недостаток опыта платить — плохо написан код, синтезатор плохо уложит все в кристалл, никогда не получатся хорошие частоты в проекте. чтобы компенсировать это, прийдется покупать более дорогие плисины, с большим запасом по необходимым ресурсам. а хорошая плисина это не микруха за 5 рублей.
и таки да, чтобы синтезатор выдал хороший результат — его надо очень тонко настраивать. а это еще бОльший порог вхождения, нежели обладание «схемотехническим» складом ума. более того — и хороший программист должен быть «схемотехником». без знания того, как выполняется каждый конкретный оператор, откуда берутся операнды, сколько на это тратиться тактов и времени — невозможно писать хороший, быстрый код. но таких программистов еденицы. гораздо больше тех кто тупо накидывает операторы, а компилятор там сам разберется что и куда запихнуть. такие программисты часто заканчивают в макдональдсе на свободной кассе :)
автор предлагает за недостаток опыта платить — плохо написан код, синтезатор плохо уложит все в кристалл, никогда не получатся хорошие частоты в проекте. чтобы компенсировать это, прийдется покупать более дорогие плисины, с большим запасом по необходимым ресурсам. а хорошая плисина это не микруха за 5 рублей.
и таки да, чтобы синтезатор выдал хороший результат — его надо очень тонко настраивать. а это еще бОльший порог вхождения, нежели обладание «схемотехническим» складом ума. более того — и хороший программист должен быть «схемотехником». без знания того, как выполняется каждый конкретный оператор, откуда берутся операнды, сколько на это тратиться тактов и времени — невозможно писать хороший, быстрый код. но таких программистов еденицы. гораздо больше тех кто тупо накидывает операторы, а компилятор там сам разберется что и куда запихнуть. такие программисты часто заканчивают в макдональдсе на свободной кассе :)
Есть разные рынки. Иногда время выхода продукта на рынок определяет все дальнейшие продажи. Приборы на этом рынке очень дорогие, а продажи очень маленькие и потому совершенно не важно сколько вы потратили на плис 400 долларов или 1000. Ровно как не важно смогли вы выжать из спартана 6, например, 150 МГц, когда для вашей задачи хватает и 50. Также не надо забывать вопросы прототипирования и макетирования, проверили идею, а потом отдали на вылизывание и оптимизацию профессионалам.
Также не надо забывать вопросы прототипирования и макетирования, проверили идею, а потом отдали на вылизывание и оптимизацию профессионалам.Вот, кстати, да. Поиск инженера, который умеет
хммммм, только сейчас обратил внимание на ваше фио. на форуме электроники вроде есть персонаж с такими же. не вы, случаем ))?
Есть разные рынки. Иногда время выхода продукта на рынок определяет все дальнейшие продажи. Приборы на этом рынке очень дорогие, а продажи очень маленькие и потому совершенно не важно сколько вы потратили на плис 400 долларов или 1000
все верно. но можно же потратить не 1000 и не 400, а, к примеру, 100 :). и уложиться в требования и дополнительно навариться.
Также не надо забывать вопросы прототипирования и макетирования, проверили идею, а потом отдали на вылизывание и оптимизацию профессионалам.
покупать для обкатки тестового проекта плис за космические деньги… разумный подход :). конечно, если у вас таких идей в голове море, и все перспективные, и есть кому это потом спихивать для натягивания совы на глобус, то да — есть смысл 1 раз купить хорошую отладочную плату за хорошие деньги
в общем в чем в целом мне не понравилось в том что вы пропагандируете… русские инженеры всегда отличались умением слепить из г… на пулю, и выжать из минимального набора материалов максимальный результат. именно поэтому наше оружие самое эффективное, самое надежное и самое недорогое. а тот подход что вы пытаетесь оправдать — используют наши западные партнеры. пофиг на все, у нас есть технологии и бабки — мы можем себе позволить компенсировать непрофессионализм своих инженеров тоннами бабла. нужна нам частота 150, но из-за кривого проекта потолок 50? пофигу, чтобы успеть обработать поток данных сопоставимый со 150 мегагерцами, поставим 3 плисины по 50. и еще одну впендюрим — чтобы коммутировать потоки
Есть разные рынки. Иногда время выхода продукта на рынок определяет все дальнейшие продажи. Приборы на этом рынке очень дорогие, а продажи очень маленькие и потому совершенно не важно сколько вы потратили на плис 400 долларов или 1000
все верно. но можно же потратить не 1000 и не 400, а, к примеру, 100 :). и уложиться в требования и дополнительно навариться.
Также не надо забывать вопросы прототипирования и макетирования, проверили идею, а потом отдали на вылизывание и оптимизацию профессионалам.
покупать для обкатки тестового проекта плис за космические деньги… разумный подход :). конечно, если у вас таких идей в голове море, и все перспективные, и есть кому это потом спихивать для н
в общем в чем в целом мне не понравилось в том что вы пропагандируете… русские инженеры всегда отличались умением слепить из г… на пулю, и выжать из минимального набора материалов максимальный результат. именно поэтому наше оружие самое эффективное, самое надежное и самое недорогое. а тот подход что вы пытаетесь оправдать — используют наши западные партнеры. пофиг на все, у нас есть технологии и бабки — мы можем себе позволить компенсировать непрофессионализм своих инженеров тоннами бабла. нужна нам частота 150, но из-за кривого проекта потолок 50? пофигу, чтобы успеть обработать поток данных сопоставимый со 150 мегагерцами, поставим 3 плисины по 50. и еще одну впендюрим — чтобы коммутировать потоки
Не стоит вам так под одну гребенку русских инженеров.
Хорошие инженеры что у нас, что у них славятся умением найти правильный компромисс для решения поставленной задачи.
А бросаться в крайности и агрессивно на всех нападать удел неудачников.
Творческих успехов
Хорошие инженеры что у нас, что у них славятся умением найти правильный компромисс для решения поставленной задачи.
А бросаться в крайности и агрессивно на всех нападать удел неудачников.
Творческих успехов
агрессивно нападать? это где я нападал? примеры можно?
под одну гребенку? тут да, согласен — далеко не все наши инженеры образцовые специалисты.
все умеют находить компромисс? тоже согласен — правильный компромисс все умеют найти. только какие критерии для сравнения этих компромиссов? решение поставленной задачи? не подходит. а вот тактико-технические характеристики в проекции на затраты по их достижению — вот это уже ближе. и что то мне подсказывает что тут поле безоговорочно остается за нашими инженерами.
под одну гребенку? тут да, согласен — далеко не все наши инженеры образцовые специалисты.
все умеют находить компромисс? тоже согласен — правильный компромисс все умеют найти. только какие критерии для сравнения этих компромиссов? решение поставленной задачи? не подходит. а вот тактико-технические характеристики в проекции на затраты по их достижению — вот это уже ближе. и что то мне подсказывает что тут поле безоговорочно остается за нашими инженерами.
Подозреваю это от того, что оценка труда русского инженера — примерно на уровне посудомоя цивилизованной страны. Если годовая зарплата инженера как одна хорошая микросхема — то действительно, почему бы не поизгаляться?
> «железячник» легко станет программистом
Видел я результаты такого труда, не надо переоценивать возможности железячников.
Видел я результаты такого труда, не надо переоценивать возможности железячников.
У вас простой пример. Для сложных случаев, когда все таки хочется разбить на блоки большой кусок кода, наверное есть смысл вводить промежуточные сигналы и их в одном отдельном месте разгребать через приоритеты. Правильно мыслю?
Это скорее уже вопрос правильного деления на подмодули. Я не призываю чтобы на все устройство был один файл. Надо бить «программу» на функциональные блоки и на верхнем уровне работать уже с сигналами блоков.
кстати, зря не призываете )). плодить сущности и потом мудохаться с прокидыванием сигналов между блоками… это говорю как человек, который собирал итоговый проект для тестирования и отладки )). приходилось сталкиваться с крайностями — и с тем что внутри одного небольшого устройства чуть ли не каждый счетчик был вынесен в отдельный блок, и с тем что большое устройство (процессор, памяти, алу, блоки управления, итд итп) было описано одним куском кода — тупо подряд куча процессов, хрен пойми что откуда и куда идет, на что влияет и по какому принципу вообще этот сигнал назван.
сам придерживаюсь золотой середины — по минимум крупных блоков, собраных на топ-лвл, и в пределах одного блока все устройства работающие на 1 частоте описаны в одном процессе. логически разбиты на отдельные блоки (интерфейсные части, области управления, делители частоты, итд), снабжены понятными комментариями (начало-конец блока, назначение, пояснения по управляющим сигналам — что откуда и куда), но описаны все в одном месте
сам придерживаюсь золотой середины — по минимум крупных блоков, собраных на топ-лвл, и в пределах одного блока все устройства работающие на 1 частоте описаны в одном процессе. логически разбиты на отдельные блоки (интерфейсные части, области управления, делители частоты, итд), снабжены понятными комментариями (начало-конец блока, назначение, пояснения по управляющим сигналам — что откуда и куда), но описаны все в одном месте
кстати, свежий пример от вивады, на откуп (в том числе) которой предлагается отдавать львиную долю работы — убито 2 рабочих дня 3 инженеров на вычисление элементарной ошибки — два источника для одного сигнала. собирающий топ-лвл скопипастил блок и в одном месте не переименовал сигнал. и вивада схавала — ни одного ворнинга/еррора. схавали симуляторы — ни одной неопределенки при моделировании. а вот при отладке в железе начались чудеса…
Такая ошибка отлавливается на этапе синтеза. Если такого не происходит то вероятнее всего сигнал был объявлен как wor или wand которые могут иметь несколько источников. В этом случае незачем обвинять инструменты, они сработали как вы написали.
Виной произошедшему плохая архитектура вашего проекта, плохая структура кода и возможно бедная верификация.
Виной произошедшему плохая архитектура вашего проекта, плохая структура кода и возможно бедная верификация.
Без конкретного разбора примера неинтересно. Но если боитесь отстрелить себе ногу — пользуйтесь VHDL, там вольностей сильно меньше. Хотя в виваде да, немного странно. Multiple drivers оно обнаруживает не на синтезе а уже при трассировке кристалла.
И, главное, если не отдавать работу «виваде», то как?
И, главное, если не отдавать работу «виваде», то как?
Какой путь проходят Verilog файлы с момента написания до попадания в Flash память FPGA?
Вот при разработке на С это *.c-> *.i-> *.o-> *.elf-> *.bin.
А при Verilog разработке какой путь?
Как устроена пищеварительная система RTL синтезаторов?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
FPGA для программиста, простые рецепты