[sv-bc] {Disarmed} FW: [New comment] SV parameterized functions

From: Brad Pierce's Blog [mailto:no-reply@wordpress.com]
Sent: Monday, October 25, 2010 12:23 AM
To: Bresticker, Shalom
Subject: [New comment] SV parameterized functions


Sergey added a new comment to the post SV parameterized functions<http://bradpierce.wordpress.com/2010/04/28/sv-parameterized-functions>.


Sergey<http://bradpierce.wordpress.com/2010/04/28/sv-parameterized-functions#comment-2248> said on SV parameterized functions<http://bradpierce.wordpress.com/2010/04/28/sv-parameterized-functions>
2010/10/24 at 3:22 pm


In response to des00 on 2010/10/02 at 2:16 am:

I agree with Sergey. I don’t like the idea to use classes inside RTL code for synthesis. IMHO It’s wrong way to failure. Why you can’t do sometheing like VHDL aproach to detect operator bitwidth at function call?. It can be like this function logic [$:0] pipa (input logic [$:0] data) logic [$size(data)-1 : 0] [...]

Hallo everybody,
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).
Thanks for attention
Kind regards, Sergey

See all comments on this post here<http://bradpierce.wordpress.com/2010/04/28/sv-parameterized-functions#comments>.

[http://s.wordpress.org/about/images/logo-grey/grey-m.png]


WordPress.com<http://wordpress.com> | Thanks for flying with WordPress!
Manage Subscriptions<http://subscribe.wordpress.com/?key=55cc24d55a8457dd6ec2aef3404e6552&email=shalom.bresticker%40intel.com> | Unsubscribe<http://subscribe.wordpress.com/?key=55cc24d55a8457dd6ec2aef3404e6552&email=shalom.bresticker%40intel.com&c=uoHdX1Z%2BrPz44BX5kBFYK9O%5Ds%3D4OM%5Dm%7CsoJ1%5Dwx5%2F%255H> | Reach out to your own subscribers with WordPress.com.<http://wordpress.com/signup/?ref=email>


Trouble clicking? Copy and paste this URL into your browser: http://subscribe.wordpress.com
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.