Jump to content

    
Sign in to follow this  
Leka

Как лаконично описывать конвейеры ?

Recommended Posts

1 minute ago, Leka said:

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

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

Share this post


Link to post
Share on other sites
32 minutes ago, RobFPGA said:

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

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

Share this post


Link to post
Share on other sites
Just now, Leka said:

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

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

Share this post


Link to post
Share on other sites
1 minute ago, Leka said:

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

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

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

Share this post


Link to post
Share on other sites
1 minute ago, Leka said:

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

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

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


Профит  -

???  
 

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

Share this post


Link to post
Share on other sites
1 hour ago, RobFPGA said:

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

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

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

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

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

1 hour ago, RobFPGA said:

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

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

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

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

1 hour ago, RobFPGA said:

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

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

Share this post


Link to post
Share on other sites
7 minutes ago, Leka said:

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

Различия в типах присваивания и вытекающее из этого различия в поведения переменных при вычислении в блоках это и есть одна из концепций языка.
И в самом языке нет концепции синхронного дизайна. Это лишь принцип того как вы будете реализовывать конкретный дизайн используя все средства языка. 

12 minutes ago, Leka said:

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

Вы сначала ограничиваете себя только  "блокирующим" типом так как в вашем представлении все вычисления идут по очереди, а в реальности получается что это неблокирующие что уже вводит в заблуждение. Ну и в вашем блоке еще и мешаются assign присвоения что вообще сбивает с толку. 

16 minutes ago, Leka said:

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

Это мы уже тоже обсуждали - опять же это искусственно придуманное вами ограничение себя же любимого, требующее костылей. Как пример описание синтезируемой dual-port памяти с разными клоками. Присвоение одной переменной значений в разных блоках.  :unknw:  Да еще и в зависимости от типа использованного присвоения может синтезироваться память с разным поведением. 

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

Ну а когда разработчику надо будет написать не синтезируемый тестбенчь ему придется забывать все эти "улучшения" вспоминая как на самом деле работают обычные присвоения в V/SV.
Нет уж  увольте - лучше я буду хорошо знать и уметь пользоваться просто V/SV :yes3:     

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
4 minutes ago, Leka said:

Уже почти 10 лет пишу, ни разу не столкнулся с какими-либо неудобствами. Блочная память и в V/SV всегда отдельными модулями идет. Для многоклоковых дизайнов в топ-модуле пишу основной код на своем языке, а многоклоковую часть - в модулях на V/SV.

:scratch_one-s_head: этим  все сказано о применимости этого "пластилина".  :unknw:

 

7 minutes ago, Leka said:

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

А при чем тут синтезатор? Мы ведь о языке говорили и  его "концепции" в вашем понимании -

9 hours ago, Leka said:

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

и я показал что нет, это не концепция (не запрет) языка,  а лишь досадное ограничение конкретной целевой платформы (железа). Раз в железе нельзя в один триггер одновременно писать из двух источников то и не допускается для синтеза делать присвоение более чем в одном блоке. Если можно (как в примере BRAM) - то пожалуйста.  А язык не запрещает это делать. И если синтезатор поймет и аппаратная платформа поддерживает то можете хоть в 2, хоть в 3 блоках присвоения делать. Ну для симуляции и подавно. Ну а в вашем подходе это именно костыль-ограничение который вы сознательно ввели и с которым мужественно боритесь используя голый V/SV  :wacko2: 
Ну а шаблоны написания кода для синтезатора это другая тема связанная с разработкой парсеров, и алгоритмов синтеза. И чаще всего проблемы с синтезом возникаю из непонимания разработчиком во что будет синтезирована та или иная конструкция. И IMHO "каша" в вашем стиле описании этому ни как не способствует. 

22 minutes ago, Leka said:

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

Это ничему не противоречит  Опять же ваше вольное трактование и придумывание сущностей которых нет.  В  V/SV тип переменной определяется только ... типом переменной  :biggrin: .
Ну а ложные представления IMHO это лишь результат некачественной учебы и недостатка знаний, а не сколько проблемы языка. 
Я например с удовольствием использую блокирующие в always_ff для промежуточных вычислений.   

Share this post


Link to post
Share on other sites
17 minutes ago, RobFPGA said:

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

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

19 minutes ago, RobFPGA said:

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

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

Share this post


Link to post
Share on other sites
1 minute ago, Leka said:

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

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

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

Share this post


Link to post
Share on other sites

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

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
	

- синтезируется в одиночную блочную память (клок по умолчанию). 

Но это повезло, что синтезатор понял. С двухпортовой не получилось, отрапортовал о нехватке ресурсов.

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

 

 

Edited by Leka

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this