RobFPGA 30 8 ноября, 2021 Опубликовано 8 ноября, 2021 · Жалоба 1 minute ago, Leka said: Ну и почему тогда синтез на CPU проводят, а не на FPGA ? Странный вопрос. Наверное потому что алгоритмы синтеза плохо параллелятся и не оптимальны для реализации в FPGA. Как в прочем и на GPU. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 8 ноября, 2021 Опубликовано 8 ноября, 2021 · Жалоба 32 minutes ago, RobFPGA said: четкости и ясности исходного V/SV уже нет Многолетний опыт использования сразу двух подходов (по способу задания типа присваивания) убедил меня, что используемый в V/SV подход существенно хуже во всех смыслах. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 30 8 ноября, 2021 Опубликовано 8 ноября, 2021 · Жалоба Just now, Leka said: Многолетний опыт использования сразу двух подходов (по способу задания типа присваивания) убедил меня, что используемый в V/SV подход существенно хуже во всех смыслах. Только вас и убедил. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 8 ноября, 2021 Опубликовано 8 ноября, 2021 · Жалоба А на чем м/б основано мнение того, кто сам не пробовал ? "Я так думаю" ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 30 8 ноября, 2021 Опубликовано 8 ноября, 2021 · Жалоба 1 minute ago, Leka said: А на чем м/б основано мнение того, кто сам не пробовал ? "Я так думаю" ? На опыте использования V/SV, HLS, и на анализе рисков и возможного профита вашего подхода. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 8 ноября, 2021 Опубликовано 8 ноября, 2021 · Жалоба 4 minutes ago, RobFPGA said: анализе рисков И какие же риски? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 30 8 ноября, 2021 Опубликовано 8 ноября, 2021 · Жалоба 1 minute ago, Leka said: И какие же риски? Я уже когда-то писал - Риски - Нестандартный синтаксис противоречащий концепции языка Сложность в понимании что происходит в коде без держания в голове типов всех переменных и увязки их взаимного положения между. Неоднозначность реализаций конструкций и как результат исключения и костыли в стиле. Дополнительная внешняя зависимость в пре-процессинге ... Профит - ??? Для меня описание конвейеров да и других логических конструкций в V/SV не представляет сложности. Поэтому увы в профит нечего добавить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 9 ноября, 2021 Опубликовано 9 ноября, 2021 · Жалоба 1 hour ago, RobFPGA said: Нестандартный синтаксис противоречащий концепции языка Неверно, способ задания типа присваивания вообще не затрагивает основную концепцию языка и синхронного дизайна: 1) присваивание любой внешней переменной возможно только в одном процедурном блоке (из нескольких), 2) отложенные присваивания выполняются синхронно (для всех процедурных блоков). И ничто другое не входит в основную концепцию. 1 hour ago, RobFPGA said: Сложность в понимании что происходит в коде без держания в голове типов всех переменных и увязки их взаимного положения между. Неверно, процедурный блок - последовательный, поэтому взаимное положение переменных по-любому надо держать в голове, как и в программировании, совершенно независимо от типа переменной. Последовательность самих процедурных блоков м/б любой, тк присвоить внешней переменной можно только в одном процедурном блоке. Областью видимости переменных легко управлять и внутри одного процедурного блока. 1 hour ago, RobFPGA said: Неоднозначность реализаций конструкций и как результат исключения и костыли в стиле. В исходном V/SV полно неоднозначных конструкций, поэтому так много внимания уделяется стилю написания кода. Тип оператора присваивания - абсолютно лишняя сущность, тк для одной переменной все-равно запрещено смешивать разные типы присваиваний (и даже это не помогает убрать все неоднозначности). Выкинув лишнюю сущность - как раз убираем костыли. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 30 9 ноября, 2021 Опубликовано 9 ноября, 2021 · Жалоба 7 minutes ago, Leka said: Неверно, способ задания типа присваивания вообще не затрагивает основную концепцию языка и синхронного дизайна: Различия в типах присваивания и вытекающее из этого различия в поведения переменных при вычислении в блоках это и есть одна из концепций языка. И в самом языке нет концепции синхронного дизайна. Это лишь принцип того как вы будете реализовывать конкретный дизайн используя все средства языка. 12 minutes ago, Leka said: Неверно, процедурный блок - последовательный, поэтому взаимное положение переменных по-любому надо держать в голове, как и в программировании, совершенно независимо от типа переменной. Вы сначала ограничиваете себя только "блокирующим" типом так как в вашем представлении все вычисления идут по очереди, а в реальности получается что это неблокирующие что уже вводит в заблуждение. Ну и в вашем блоке еще и мешаются assign присвоения что вообще сбивает с толку. 16 minutes ago, Leka said: Последовательность самих процедурных блоков м/б любой, тк присвоить внешней переменной можно только в одном процедурном блоке. Это мы уже тоже обсуждали - опять же это искусственно придуманное вами ограничение себя же любимого, требующее костылей. Как пример описание синтезируемой dual-port памяти с разными клоками. Присвоение одной переменной значений в разных блоках. Да еще и в зависимости от типа использованного присвоения может синтезироваться память с разным поведением. И все эти риски видны сразу, даже на тех малых и простых примерах что были тут. Попробуйте привести примеры в вашем стиле всего того многообразия конструкций что можно описать на обычном V/SV и которые применяются в разработке. Уверен еще всплывут другие костыли и нестыковки. Ну а когда разработчику надо будет написать не синтезируемый тестбенчь ему придется забывать все эти "улучшения" вспоминая как на самом деле работают обычные присвоения в V/SV. Нет уж увольте - лучше я буду хорошо знать и уметь пользоваться просто V/SV Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 9 ноября, 2021 Опубликовано 9 ноября, 2021 · Жалоба 8 hours ago, RobFPGA said: Различия в типах присваивания и вытекающее из этого различия в поведения переменных при вычислении в блоках это и есть одна из концепций языка. Тип присваивания - да, это основная концепция языка, cпособ задания типа присваивания - нет, это всего лишь способ реализации основной концепции. 8 hours ago, RobFPGA said: Вы сначала ограничиваете себя только "блокирующим" типом так как в вашем представлении все вычисления идут по очереди, а в реальности получается что это неблокирующие Все присваивания в процедурном блоке идут строго по очереди, как блокирующие, так и неблокирующие - в том смысле, что результат зависит от порядка. Для неблокирующих присваиваний порядок тоже важен. В V/SV настоятельно рекомендуется использовать только неблокирующее присваивание для регистров, и только блокирующие присваивания для логики - это фактически означает рекомендацию следовать однозначному соответствию между типом переменной (регистр/провод) и типом присваивания. Это противоречит тому, что в V/SV тип переменной (регистр/провод) определяется только типом процедурного блока, независимо от типа присваивания, и объявленного типа переменной. Отсюда у многих ложное представление о запрете неблокирующих присваиваний в always_comb, и блокирующих в always_ff. Сначала наломали дров (reg/wire/always в Verilog), и потом костылей понаделали (logic/always_comb/always_ff в SV). 8 hours ago, RobFPGA said: Как пример описание синтезируемой dual-port памяти с разными клоками. Присвоение одной переменной значений в разных блоках. Это как раз пример костылей, а не возможностей языка - описание должно строго следовать шаблону, чтобы синтезатор смог опознать стандартный блок. Небольшие изменения - и синтезатор засыпает на регистрах. 8 hours ago, RobFPGA said: Попробуйте привести примеры в вашем стиле всего того многообразия конструкций что можно описать на обычном V/SV и которые применяются в разработке. Уже почти 10 лет пишу, ни разу не столкнулся с какими-либо неудобствами. Блочная память и в V/SV всегда отдельными модулями идет. Для многоклоковых дизайнов в топ-модуле пишу основной код на своем языке, а многоклоковую часть - в модулях на V/SV. Понятное дело, что в коллективной работе выбора нет - только стандартный HDL, да еще вдобавок принятый стиль. У меня такого ограничения нет, тк не работа, а развлечение. Транслятор доработал, теперь "2D-песочницу" (~300 строк на Си) попробую перенести на HDL. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 30 9 ноября, 2021 Опубликовано 9 ноября, 2021 · Жалоба 4 minutes ago, Leka said: Уже почти 10 лет пишу, ни разу не столкнулся с какими-либо неудобствами. Блочная память и в V/SV всегда отдельными модулями идет. Для многоклоковых дизайнов в топ-модуле пишу основной код на своем языке, а многоклоковую часть - в модулях на V/SV. этим все сказано о применимости этого "пластилина". 7 minutes ago, Leka said: Это как раз пример костылей, а не возможностей языка - описание должно строго следовать шаблону, чтобы синтезатор смог опознать стандартный блок. Небольшие изменения - и синтезатор засыпает на регистрах. А при чем тут синтезатор? Мы ведь о языке говорили и его "концепции" в вашем понимании - 9 hours ago, Leka said: Последовательность самих процедурных блоков м/б любой, тк присвоить внешней переменной можно только в одном процедурном блоке. и я показал что нет, это не концепция (не запрет) языка, а лишь досадное ограничение конкретной целевой платформы (железа). Раз в железе нельзя в один триггер одновременно писать из двух источников то и не допускается для синтеза делать присвоение более чем в одном блоке. Если можно (как в примере BRAM) - то пожалуйста. А язык не запрещает это делать. И если синтезатор поймет и аппаратная платформа поддерживает то можете хоть в 2, хоть в 3 блоках присвоения делать. Ну для симуляции и подавно. Ну а в вашем подходе это именно костыль-ограничение который вы сознательно ввели и с которым мужественно боритесь используя голый V/SV Ну а шаблоны написания кода для синтезатора это другая тема связанная с разработкой парсеров, и алгоритмов синтеза. И чаще всего проблемы с синтезом возникаю из непонимания разработчиком во что будет синтезирована та или иная конструкция. И IMHO "каша" в вашем стиле описании этому ни как не способствует. 22 minutes ago, Leka said: В V/SV настоятельно рекомендуется использовать только неблокирующее присваивание для регистров, и только блокирующие присваивания для логики - это фактически означает рекомендацию следовать однозначному соответствию между типом переменной (регистр/провод) и типом присваивания. Это противоречит тому, что в V/SV тип переменной (регистр/провод) определяется только типом процедурного блока, независимо от типа присваивания, и объявленного типа переменной. Отсюда у многих ложное представление о запрете неблокирующих присваиваний в always_comb, и блокирующих в always_ff. Это ничему не противоречит Опять же ваше вольное трактование и придумывание сущностей которых нет. В V/SV тип переменной определяется только ... типом переменной . Ну а ложные представления IMHO это лишь результат некачественной учебы и недостатка знаний, а не сколько проблемы языка. Я например с удовольствием использую блокирующие в always_ff для промежуточных вычислений. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 9 ноября, 2021 Опубликовано 9 ноября, 2021 · Жалоба 17 minutes ago, RobFPGA said: В V/SV тип переменной определяется только ... типом переменной Нет. Как ни объяви, результат синтеза будет зависеть только от типа процедурного блока. Только регистр, если присвоение в always_ff, и только провод(логика), если присвоение в always_comb. 19 minutes ago, RobFPGA said: Я например с удовольствием использую блокирующие в always_ff для промежуточных вычислений. Естественно, если запретить блокирующие в always_ff - можно будет забыть про использование оператора "for" в этих блоках. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 30 9 ноября, 2021 Опубликовано 9 ноября, 2021 · Жалоба 1 minute ago, Leka said: Нет. Как ни объяви, результат синтеза будет зависеть только от типа процедурного блока. Только регистр, если присвоение в always_ff, и только провод(логика), если присвоение в always_comb. Еще раз - при чем тут синтез? Я пишу в 2-3 раза больше кода на V/SV для симуляции. Поэтому не вижу никаких профитов для себя от вашего "упрощения" Если вам так удобно работать, и работодатель такое одобряет то на здоровье. Я видел много подобных попыток и странных решений для "упрощения" написания кода. От сплошных макросов и нестандартных вендоровских расширений для V/SV со встроенными шаблонизаторами и различным синтаксическим сахаром, вплоть до C/C++, C#, Phython, и функциональных языков. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 9 ноября, 2021 Опубликовано 9 ноября, 2021 · Жалоба 22 minutes ago, RobFPGA said: при чем тут синтез? Ветка про синтезируемое подмножество HDL. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 9 ноября, 2021 Опубликовано 9 ноября, 2021 (изменено) · Жалоба Сейчас попробовал: module SimpleDP(q, d, ra, wa, we); input d, ra, wa, we; output q; reg [8:0] q; var [8:0] d; var [9:0] ra, wa; var we; begin reg [1023:0][8:0] ram; if(we) ram[wa] = d; q = ram[ra]; end endmodule - синтезируется в одиночную блочную память (клок по умолчанию). Но это повезло, что синтезатор понял. С двухпортовой не получилось, отрапортовал о нехватке ресурсов. Все-равно в реальных дизайнах блочную память всегда отдельным модулем нужно описывать. Изменено 9 ноября, 2021 пользователем Leka Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться