[RobFPGA 35]

1 minute ago, Leka said:

Ну и почему тогда синтез на CPU проводят, а не на FPGA ?

Странный вопрос. Наверное потому что алгоритмы синтеза плохо параллелятся и не оптимальны для реализации в FPGA. Как в прочем и на GPU.        

[Leka 1]

32 minutes ago, RobFPGA said:

четкости и ясности исходного V/SV уже нет

Многолетний опыт использования сразу двух подходов (по способу задания типа присваивания) убедил меня, что используемый в V/SV подход существенно хуже во всех смыслах. 

[RobFPGA 35]

Just now, Leka said:

Многолетний опыт использования сразу двух подходов (по способу задания типа присваивания) убедил меня, что используемый в V/SV подход существенно хуже во всех смыслах. 

Только вас и убедил.  

[Leka 1]

А на чем м/б основано мнение того, кто сам не пробовал ?

"Я так думаю" ?

[RobFPGA 35]

1 minute ago, Leka said:

А на чем м/б основано мнение того, кто сам не пробовал ?

"Я так думаю" ?

На опыте использования V/SV, HLS, и на анализе рисков и возможного профита вашего подхода.       

[Leka 1]

4 minutes ago, RobFPGA said:

анализе рисков

И какие же риски? 

[RobFPGA 35]

1 minute ago, Leka said:

И какие же риски? 

Я уже когда-то писал  - 

Риски - 
Нестандартный синтаксис противоречащий концепции языка 
Сложность в понимании что происходит в коде без держания в голове типов всех переменных и увязки их взаимного положения между. 
Неоднозначность реализаций конструкций и как результат исключения и костыли в стиле. 
Дополнительная внешняя зависимость в пре-процессинге 
...

Профит  -

???  
 

Для меня описание конвейеров да и других логических конструкций в V/SV не представляет сложности.  Поэтому увы в профит нечего добавить. 

[Leka 1]

1 hour ago, RobFPGA said:

Нестандартный синтаксис противоречащий концепции языка

Неверно, способ задания типа присваивания вообще не затрагивает основную концепцию языка и синхронного дизайна:

1) присваивание любой внешней переменной возможно только в одном процедурном блоке (из нескольких),

2) отложенные присваивания выполняются синхронно (для всех процедурных блоков).

И ничто другое не входит в основную концепцию.

1 hour ago, RobFPGA said:

Сложность в понимании что происходит в коде без держания в голове типов всех переменных и увязки их взаимного положения между.

Неверно, процедурный блок - последовательный, поэтому взаимное положение переменных по-любому надо держать в голове, как и в программировании, совершенно независимо от типа переменной. 

Последовательность самих процедурных блоков м/б любой, тк присвоить внешней переменной можно только в одном процедурном блоке.

Областью видимости переменных легко управлять и внутри одного процедурного блока. 

1 hour ago, RobFPGA said:

Неоднозначность реализаций конструкций и как результат исключения и костыли в стиле.

В исходном V/SV полно неоднозначных конструкций, поэтому так много внимания уделяется стилю написания кода. Тип оператора присваивания - абсолютно лишняя сущность, тк для одной переменной все-равно запрещено смешивать разные типы присваиваний (и даже это не помогает убрать все неоднозначности). Выкинув лишнюю сущность - как раз убираем костыли.

[RobFPGA 35]

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 1]

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 35]

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 1]

17 minutes ago, RobFPGA said:

В  V/SV тип переменной определяется только ... типом переменной

Нет. Как ни объяви, результат синтеза будет зависеть только от типа процедурного блока. Только регистр, если присвоение в always_ff, и только провод(логика), если присвоение в always_comb. 

19 minutes ago, RobFPGA said:

Я например с удовольствием использую блокирующие в always_ff для промежуточных вычислений. 

Естественно, если запретить блокирующие в always_ff - можно будет забыть про использование оператора "for" в этих блоках.

[RobFPGA 35]

1 minute ago, Leka said:

Нет. Как ни объяви, результат синтеза будет зависеть только от типа процедурного блока. Только регистр, если присвоение в always_ff, и только провод(логика), если присвоение в always_comb. 

Еще раз - при чем тут синтез? Я пишу в 2-3 раза больше кода на V/SV для  симуляции. Поэтому не вижу никаких профитов для себя от вашего "упрощения" 

Если вам так удобно работать, и работодатель такое одобряет то на здоровье. Я видел много подобных попыток и странных решений для "упрощения" написания кода.
От сплошных макросов и нестандартных вендоровских расширений для V/SV со встроенными шаблонизаторами и различным синтаксическим сахаром, вплоть до C/C++, C#, Phython, и функциональных языков. 

[Leka 1]

22 minutes ago, RobFPGA said:

при чем тут синтез?

Ветка про синтезируемое подмножество HDL. 

 

 

[Leka 1]

Сейчас попробовал:

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