Перейти к содержанию
    

Verilog. Параметризируемые функции.

за линк спасибо, будет время покурю немного.

доступ к базе данных коммитета всё-таки есть (хоть он и не анонсирован и естественно с ограничением прав)

http://www.eda.org/svdb/

пароль и логин: guest

вопрос о параметризации функций имеет ключ № 696

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

кстати интересно, что у Bluespec SystemVerilog поддерживается параметризация всего чего угодно(темплетизация), а они члены коммитета 1800; могли бы просто передать свою спецификацию для нового стандарта, но чего-то как-то не передают - на собраниях говорят - "а, ну, мы это несколько лет назад уже решили" - но ничего конкретного не делается. а жаль

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

ну, что ж вот так вот предлагается решать данную проблему в будущем стандарте

http://www.eda.org/svdb/file_download.php?...69&type=bug

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

таки нашел более менее красивое решение проблемы

Есть ещё далеко не красивое, зато совершенно "дубовое" по совместимости со всем чем угодно решение: объявлять функцию через параметризованный `define и вызывать его в модуле, объявляя тем самым локальную функцию с заданными именем и значением параметра.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

ну, что ж вот так вот предлагается решать данную проблему в будущем стандарте

http://www.eda.org/svdb/file_download.php?...69&type=bug

бред, не дождемся мы этого до синтеза, тогда как нужно сие в основном при синтезе.

 

Есть ещё далеко не красивое, зато совершенно "дубовое" по совместимости со всем чем угодно решение: объявлять функцию через параметризованный `define и вызывать его в модуле, объявляя тем самым локальную функцию с заданными именем и значением параметра.

уж слишком лобовое и не сильно удобное решение %)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

бред, не дождемся мы этого до синтеза, тогда как нужно сие в основном при синтезе.

именно это я им и говорю:

1) I think it break the rule that may be phrased something like ”I will get what I expect to get”. I think the SV community got to the understanding that the standard becoming too tangled (once you noted that as well in your blog). I think the proposed approach helps it to be even more complicated, less intuitive and less plain. The approach IMHO does not differ much from the trick with interfaces with the only exception the one do not have to instantiate an object. It is a pity, that the initial sense of entities becomes perverted. Now a class can be seen something like parameterizable library of subroutines(could be seen as not full-fledged package). I really do not understand this logic.

2) as I mentioned before the synthesis software vendors are very inertial. they will have to accept and realize the idea that classes are synthesizable constructions. They will have to say in their manuals ”Classes are synthesizable, but only those that are … /and here is a long list of constraints that should eventually result effectively just in parameterizable functions/”. I do not think that they will be very enthusiastic in rewriting their compilers to introduce a new synthesizable substance and a lot of rules restricting the other possible use of classes inside a synthesizable code.

3) Moreover I see it not attractive for them from the point of view of marketing. I see it is much more beneficial for product promotion to give a slogan ”We now support a newly approved syntax for functions”, than to say ”We now support classes for synthesis BUT … and so and so and so (which actually means that it works only for function parameterization)”.

мне в общем тоже кажется именно в такой формулировке "такой подход - это бред"

возражение по существу такое:

I am just as worried when we start adding more syntax to a language already overburdened with syntax just because of a marketing perception issue.

C++ class are already synthesizable by commercially availible tools and there’s no reason other than perception to think that SV class are not synthesizable...

кто хочет высказать свою точку зрения (без мата) можно это сделать здесь http://bradpierce.wordpress.com/2010/04/28...ized-functions/

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

возражение по существу такое:

он глубоко ошибается, он точно вышел на SV от железа?

 

В чем проблема поступить как в VHDL, сделать определение размера параметра при вызове функции (уже не помню как эта техника там называется). Да, в VHDL есть отдельный тип для векторов, а в SV нет. Но в чем проблема сделать так :

 

function logic [$:0] pipa (input logic [$:0] data)
  logic [$size(data)-1 : 0] tmp; 
  for (int i = 0; i < $size(data); i++) begin 
    if (data[i]) tmp = bla -bla -bla;
  end 
  return tmp;
endfunction

Т.е. при декларации функции указываем открытые пределы операнда, а функции $size/low/high в стандарте уже определены. Всё, никакой другой мнемоники вводить не надо, символ $ есть в стандарте, он используется для очередей и для задания бесконечной длительности ассерта.

 

кто хочет высказать свою точку зрения (без мата) можно это сделать здесь http://bradpierce.wordpress.com/2010/04/28...ized-functions/

боюсь моего английского не хватит %)

 

UPD. написал дейву ответ, но мой пост не отображается %(

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В чем проблема поступить как в VHDL, сделать определение размера параметра при вызове функции (уже не помню как эта техника там называется).

unbounded arrays кажись это называется. такую идею им тоже подкидывали. но есть такое впечатление, что команда оторвалась уже от реальности и обратной связи с народами не имеет (или имеет, но минимум) вот и варятся в своём соку. а ведь хороший стандарт и окончательно загубить могут - придётся обратно на Paranoid-HDL ползти :(

UPD. написал дейву ответ, но мой пост не отображается %(

там прикаких-то условиях включается режим пре-модерирования(анти-спам)

 

Т.е. при декларации функции указываем открытые пределы операнда, а функции $size/low/high в стандарте уже определены. Всё, никакой другой мнемоники вводить не надо, символ $ есть в стандарте, он используется для очередей и для задания бесконечной длительности ассерта.

мне всё-таки больше нравится идея с явной передачей параметров, потому что думаю, одними пакованными массивами потребности могут и не ограничится

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

запостил ещё немного ответа в ответ на

I am just as worried when we start adding more syntax to a language already overburdened with syntax just because of a marketing perception issue.

C++ class are already synthesizable by commercially availible tools and there’s no reason other than perception to think that SV class are not synthesizable...

ответ:

There is some more criticism I would like to give out about the question. I hope it can be helpful:

(in general)

I would agree that syntax is a bit overburdened, but worse is that being overburdened the language still does not meet some basic needs. And the broader parameterization is an example.

It seems to me that the source of this distortion is a) a poor feedback mechanism from the broad community of end user to the "narrow" community of thinkers, i.e. the committee: there is no forum for broad discussion and ideas selection, which can be helpful for the committee; b ) it seems there is no ranking system for language innovations that are going to be introduced in the standard and there is no long-term planning of the language future(a strategic roadmap).

(in particular)

1) My concern about vendors vs. class synthesis was not for the sake of vendors' comfort. I know a lot of more trivial things that the majors still haven't realized properly. So the matter was really the time when an end user will be able to enjoy subroutines templatization after the standard will see the light. I'm talking about the users that chose the tools from the majors and do not rely on small-caps, who are typically more advanced in their solutions but at the same time less stable in the market (I guess these users are the majority).

2) The approach with classes will normally mean 1 class = 1 function. Is it not a potential threat for name space? It was from my experience that when I was using the interface mechanism for function templatization a function name was easy to invent, but I always stuck when I had to give a name to the correspondent interface declaration. It was because I feel that a name should match functionality. But what is the functionality of an interface in this case? Just a container for a function. This means the interface should have the same name as its function has + something that will differentiate them. It will be the same problem with classes for me.

3) I always use self-commenting names, which means at least a dozen of characters. It is not anymore an innocent "a=C#(4)::DECODER_f(decoder_in);" it will be something like "some_value_name_st=some_function_name_cl#(4)::some_function_name();" minimum. Again, from my experience it looked a bit ugly, coz the difference between interface and class function calls will only be in "#(4)::", i.e. the same endless codelines.

4) Normally templetization in HDLs is needed for HW designers, because modeling and verification guys are not so interested in precise data-formats and accurate functionality at the signal level. Let's forget for a while about ESL synthesis, which has not become yet a default way for synthesis (and it is not clear when it will be so). HW designers are not programmers and they did not have to know what OOP is, and often they do even want know it. It is just because they always lived in the world of objects without OOP. Their objects are modules, interfaces, signals. HDLs utilize procedural language paradigm which conform with templatization without any add-ons. Is it humane to force them to study OOP without a real need except for function templatization? I'm not sure that OOP, which just mimics objective world in programming world, is a virtue for languages that naturally have objects in their concept (please, note that I mean only HW design, not modelling or verification, where classes are absolutely good, and I do not mean ESL synthesis, which has undefined future yet).

неравнодушных прошу высказываться на видном месте, а то протащат темплетизацию через классы - у них на этот счёт большой энтузиазм в комитете

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

неравнодушных прошу высказываться на видном месте, а то протащат темплетизацию через классы

на всякий случай добавлю: если вы считаете, что это бесполезно и ни к чему не может привести, то это не так. эти предложения и комментарии читают в комитете (пример http://eda-stds.org/sv-bc/hm/10632.html), так что будущее стандарта может зависеть и от ваших интересных идей

;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

будущее стандарта может зависеть и от ваших интересных идей

Моя идея (не совсем по теме, правда) - не ставить точку с запятой после объявления модуля, как принято при определении функций в языке C. Есть же module ... endmodule - все однозначно определяет начало и конец. В-общем, сблизить с языком C по-максимуму.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Моя идея (не совсем по теме, правда) - не ставить точку с запятой после объявления модуля, как принято при определении функций в языке C.

ну, на это-то комитет точно не пойдёт - это я вам 500% даю. слишком радикально и функциональности не меняет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

ну, на это-то комитет точно не пойдёт - это я вам 500% даю. слишком радикально и функциональности не меняет.

Я понимаю. Мне только любопытно, почему это не было сделано сразу. Как вариант - разрешить ставить или не ставить ";"

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я понимаю. Мне только любопытно, почему это не было сделано сразу. Как вариант - разрешить ставить или не ставить ";"

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...