myhdl-list

[myhdl-list] It should be possible to use a @process decorator wherever you can use @always

[Angel E. <ang...@gm...>]

It would be nice if myhdl defined @process as an alias for @always.
While it is a very minor thing, using @always feels somewhat alien
when you come to myhdl from VHDL. In addition I feel that the word
"process" is more descriptive than "always" in this context, and
matches better its use in MyHDL. Also, because always and always_comb
match the corresponding Verilog keywords, it gives the impression that
MyHDL is Verilog centric while I don't think that is the case. Thus
providing a way to make your code look more VHDL like would be nice.

To be clear I am not asking for @always to be _changed_ into @process.
I simply would like the myhdl package to define "process = always" so
that both can be used.

For similar reasons, I also think that @always_comb should have a more
VHDL-like alias, perhaps @process_comb or @combinational_process.

I know that I can just define these aliases on my own code, but it is
a bit annoying to have to do that on every myhdl file you write.

Cheers,

Angel

Re: [myhdl-list] It should be possible to use a @process decorator wherever you can use @always

[Jan C. <jan...@mu...>]

On 01/06/11 21:41, Angel Ezquerra wrote:
> It would be nice if myhdl defined @process as an alias for @always.
    . . .
Well, I've only used VHDL before, so am a likely candidate for 
persuasion, but, I also get easily confused, so would prefer not to 
have extra options, more complex manuals. &c.

Jan Coombs

Re: [myhdl-list] It should be possible to use a @process decorator wherever you can use @always

[Angel E. <ang...@gm...>]

On Wed, Jun 1, 2011 at 11:44 PM, Jan Coombs
<jan...@mu...> wrote:
> On 01/06/11 21:41, Angel Ezquerra wrote:
>> It would be nice if myhdl defined @process as an alias for @always.
>    . . .
> Well, I've only used VHDL before, so am a likely candidate for
> persuasion, but, I also get easily confused, so would prefer not to
> have extra options, more complex manuals. &c.

I am all for simple software an libraries, but I would say that this
addition would hardly make MyHDL more complex. Everything could stay
the same. After all it would just be a matter of doing:

process = always
process_comb = always_comb

In the MyHDL package, right after the corresponding decorator definitions.
People could continue to code in the exact same way, but we would have
a choice to use the Verilog-style or the VHDL-style decorators. A
simple mention once in the manual would probably be enough.

Cheers,

Angel

Re: [myhdl-list] It should be possible to use a @process decorator wherever you can use @always

[Günter D. <dan...@we...>]

On 02.06.2011 08:55, Angel Ezquerra wrote:
...
> 
> I am all for simple software an libraries, but I would say that this
> addition would hardly make MyHDL more complex. Everything could stay
> the same. After all it would just be a matter of doing:
> 
> process = always
> process_comb = always_comb
...

>From the stand point of implementation it is simple, but how about from
the standpoint of users?

Think about a new user who is not familiar with any HDL and you explain
her she can use either always or process to achieve that?

How would that compare to learning a new programming language and the
manual tells you that you can create i.e. classes with the keyword
'class' or if you wish also with the keyword 'klasse'.

In my opinion that would be very confusing for me if I learn a language new.


Cheers,

Guenter

Re: [myhdl-list] It should be possible to use a @process decorator wherever you can use @always

[Angel E. <ang...@gm...>]

On Sun, Jun 5, 2011 at 11:36 AM, Jan Decaluwe <ja...@ja...> wrote:
> On 06/02/2011 09:27 AM, Günter Dannoritzer wrote:
>> On 02.06.2011 08:55, Angel Ezquerra wrote:
>> ...
>>>
>>> I am all for simple software an libraries, but I would say that this
>>> addition would hardly make MyHDL more complex. Everything could stay
>>> the same. After all it would just be a matter of doing:
>>>
>>> process = always
>>> process_comb = always_comb
>> ...
>>
>>> From the stand point of implementation it is simple, but how about from
>> the standpoint of users?
>>
>> Think about a new user who is not familiar with any HDL and you explain
>> her she can use either always or process to achieve that?
>>
>> How would that compare to learning a new programming language and the
>> manual tells you that you can create i.e. classes with the keyword
>> 'class' or if you wish also with the keyword 'klasse'.
>>
>> In my opinion that would be very confusing for me if I learn a language new.
>
> I fully agree with that.
>
> There may sometimes be a good reason to change a name in
> favor of another one. However, I believe there should always be one
> clearly preferred one, and one clearly deprecated one that
> will be phased out over time.
>
> Defining equivalent aliases is a no-go. It is bound to create much
> more confusion than it would solve. I don't know of an example of a
> software language that does so, for good reasons.

Jan,

I understand your reasoning and I don't really disagree with it. Going
through your previous email I also understand why you chose the word
"always" rather than "process". However I find that a bit unfortunate
for two reasons:

- The MyHDL syntax has (in my humble and very inexperienced opinion)
more of a VHDL look than a Verilog look. I think that you have
strengthened that opinion with your recent blog posts in which you
criticized the way that Verilog "signals" work, compared to VHDL. It
is thus a bit unexpected that the basic building block of MyHDL is
named after a Verilog construct rather than a VHDL one.

- I personally find the word "always" quite disconnected from its
intended purpose (both in Verilog and in MyHDL), while I find the word
"process" much closer to what a MyHDL generator represents.

That being said, given that my (very limited) background is VHDL, it
is entirely possible that had I worked with Verilog rather than with
VHDL I would have the opposite opinion and that I would find the use
of "always" natural and fitting :-)

Angel

Re: [myhdl-list] It should be possible to use a @process decorator wherever you can use @always

[Jan D. <ja...@ja...>]

On 06/05/2011 02:44 PM, Angel Ezquerra wrote:

>
> Jan,
>
> I understand your reasoning and I don't really disagree with it. Going
> through your previous email I also understand why you chose the word
> "always" rather than "process". However I find that a bit unfortunate
> for two reasons:
>
> - The MyHDL syntax has (in my humble and very inexperienced opinion)
> more of a VHDL look than a Verilog look.

I cannot agree with that. The syntax is Python's.

>  I think that you have
> strengthened that opinion with your recent blog posts in which you
> criticized the way that Verilog "signals" work, compared to VHDL. It
> is thus a bit unexpected that the basic building block of MyHDL is
> named after a Verilog construct rather than a VHDL one.

First, thanks for reading my blog posts.

The blog posts that your refer to are about nondetermism and how
to handle it in the language (or not). Therefore they are about semantics,
not syntax. The basic building block in VHDL to avoid nondeterminism
is a signal, and that is available under the same name in MyHDL.

The issue of sensitivity is unrelated to nondeterminism. However, it
is closely related to the semantics of process/always, as I argued
in another post. But that was not the subject of my blog posts, and I
consider it much less important than the issues of nondetermism.

More in general: my blog posts are part of a personal analysis
of HDL-based design. I will probably need a couple of years to say
everything I want to say. The issues are subtle. I may have strong
opinions and heavily criticize a particular aspect, but that does not
mean I am completely "anti" a particular HDL.

> - I personally find the word "always" quite disconnected from its
> intended purpose (both in Verilog and in MyHDL), while I find the word
> "process" much closer to what a MyHDL generator represents.

Personally, I think it's one of Verilog's better choices:

"always when this or that happens, do the following"

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     Analog design automation: http://www.mephisto-da.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] It should be possible to use a @process decorator wherever you can use @always

[Jan D. <ja...@ja...>]

On 06/01/2011 10:41 PM, Angel Ezquerra wrote:
> It would be nice if myhdl defined @process as an alias for @always.
> While it is a very minor thing, using @always feels somewhat alien
> when you come to myhdl from VHDL. In addition I feel that the word
> "process" is more descriptive than "always" in this context, and
> matches better its use in MyHDL. Also, because always and always_comb
> match the corresponding Verilog keywords, it gives the impression that
> MyHDL is Verilog centric while I don't think that is the case. Thus
> providing a way to make your code look more VHDL like would be nice.

Let me explain why I chose 'always' and not 'process'.

One of my goals with MyHDL is to stimulate the use of the synchronous
design template, which I believe is underused in traditional HDL design.

A major obstacle in Verilog is that it doesn't make a difference between
signals and variables, like VHDL. For this reason, MyHDL follows the
VHDL example here. Therefore, MyHDL is based on VHDL at the core.

However, in Verilog it is much easier to express that something
is sensitive to an *edge* instead of signal change. You can do that
right in the sensivity list. In VHDL, the edge sensitivtiy is hidden
somewhere in the code. For the synchronous design template, this
means that half of the time, the process is triggered for no reason.

For this reason, I chose Verilog's model for sensitivity. Reusing
'always' therefore seemed the logical choice. Moreover, the
syntactic similarity between the following two forms:

@always(clock.posedge, reset.negedge)

always @(posedge clock, posedge reset )

just seemed like a nice coincidence.

However, note that it was never was the intention to make MyHDL
"look" like Verilog or VHDL. MyHDL is implemented as pure Python
and tries to look like Python. On the other hand, when some
good concept can be re-used from earlier HDLs, there is no
reason to invent another name for it.

The bottom line is that 'always' and 'process' seem similar,
but are really quite different in the way sensitivity is
expressed.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     Analog design automation: http://www.mephisto-da.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] It should be possible to use a @process decorator wherever you can use @always

[Jan D. <ja...@ja...>]

On 06/02/2011 09:27 AM, Günter Dannoritzer wrote:
> On 02.06.2011 08:55, Angel Ezquerra wrote:
> ...
>>
>> I am all for simple software an libraries, but I would say that this
>> addition would hardly make MyHDL more complex. Everything could stay
>> the same. After all it would just be a matter of doing:
>>
>> process = always
>> process_comb = always_comb
> ...
>
>> From the stand point of implementation it is simple, but how about from
> the standpoint of users?
>
> Think about a new user who is not familiar with any HDL and you explain
> her she can use either always or process to achieve that?
>
> How would that compare to learning a new programming language and the
> manual tells you that you can create i.e. classes with the keyword
> 'class' or if you wish also with the keyword 'klasse'.
>
> In my opinion that would be very confusing for me if I learn a language new.

I fully agree with that.

There may sometimes be a good reason to change a name in
favor of another one. However, I believe there should always be one
clearly preferred one, and one clearly deprecated one that
will be phased out over time.

Defining equivalent aliases is a no-go. It is bound to create much
more confusion than it would solve. I don't know of an example of a
software language that does so, for good reasons.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     Analog design automation: http://www.mephisto-da.com
     World-class digital design: http://www.easics.com