myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] It's a beautiful day

[Christopher F. <chr...@gm...>]

It is suppose to be over 100F here today with a heat index of 110F.

But seriously, good job!  This is exciting news.  When I get a chance I 
will try this on some of my projects and report back.

Chris

Re: [myhdl-list] It's a beautiful day

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

On Tue, Jun 7, 2011 at 3:28 PM, Angel Ezquerra <ang...@gm...> wrote:
> That is fantastic news!
>
> I'm pretty sure that the PyPy guys would love to hear about this
> success story. I believe they have a web page were they track packages
> that work with PyPy. It would probably be even better if MyHDL was on
> the Python Package Index (coincidentally named PyPi) since I think
> there are also some web pages which track the percentage of the
> packages in there war work with PyPi. Also, think they have a page,
> http://speed.pypy.org/, where they automatically run benchmarks
> comparing their performance to CPython's. It would be great if you got
> them to add a MyHDL benchmark to their list.
>
> Since PyPy has quite a lot of mindshare on sites such as HackerNews,
> reddit/programming, etc, if you manage to get "featured" by them (in
> their blog, or on their benchmark page, for example) you'd surely get
> a huge boost to the number of people that know about MyHDL.
>
> As for your performance comparison, I wonder if it would make sense to
> manually write equivalent VHDL and Verilog tests, and compare those to
> the automatically generated ones (with MyHDL). If the results are
> similar it would make a really strong case that Verilog and VHDL code
> generated with MyHDL is as efficient as code directly written in those
> languages. I know that is a concern to some people when they get
> introduced to MyHDL so anything that can prove that is not the case
> would be great.
>
> I would say that they only drawback of the PyPy apporach is that,
> AFAIK, there is currently no stand-alone windows installer. Hopefully
> that will be addressed by the PyPy guys soon.
>
> Cheers,
>
> Angel
>
>
> On Tue, Jun 7, 2011 at 2:15 PM, Jan Decaluwe <ja...@ja...> wrote:
>> A few weeks ago, I posted the following:
>>
>>> From: Jan Decaluwe <ja...@ja...>
>>> Newsgroups: gmane.comp.python.myhdl
>>> Subject: My take on MyHDL weaknesses - and solutions
>>> Date: Mon, 04 Apr 2011 11:00:23 +0200
>>> ...
>>> Solution 2: The PyPy project (future). Python doesn't have
>>> to be slow: by employing clever JIT techniques, performance
>>> can be improved drastically e.g. 5-10x. I believe that MyHDL
>>> is a good candidate for this type of optimization. The day
>>> this happens would be one of the most important ones in
>>> MyHDL's history: the performance limitations would for a
>>> large part go away, and it would be the ultimate validation
>>> of the concept: benefitting from advances without having to
>>> do anything yourself :-)
>>
>> I'm very happy to report that it looks like this day has
>> arrived now. PyPy 1.5 is compatible with Python 2.7, and
>> I'm seeing really spectacular speedup factors.
>>
>> I have documented my findings extensively here:
>>
>>     http://www.myhdl.org/doku.php/performance
>>
>> Obviously, I would like to create some buzz about this, but
>> I want to move carefully. First I would like to know if
>> people with relevant simulations get similar results.
>>
>> Feedback is therefore very welcome; I think everything needed
>> to get started is documented on the page mentioned above.
>>
>> 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
>>
>>
>> ------------------------------------------------------------------------------
>> EditLive Enterprise is the world's most technically advanced content
>> authoring tool. Experience the power of Track Changes, Inline Image
>> Editing and ensure content is compliant with Accessibility Checking.
>> http://p.sf.net/sfu/ephox-dev2dev
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>

Actually it seems there is a beta version of a windows (x32)
installer! You can get it from: http://pypy.org/download.html

Angel

Re: [myhdl-list] It's a beautiful day

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

That is fantastic news!

I'm pretty sure that the PyPy guys would love to hear about this
success story. I believe they have a web page were they track packages
that work with PyPy. It would probably be even better if MyHDL was on
the Python Package Index (coincidentally named PyPi) since I think
there are also some web pages which track the percentage of the
packages in there war work with PyPi. Also, think they have a page,
http://speed.pypy.org/, where they automatically run benchmarks
comparing their performance to CPython's. It would be great if you got
them to add a MyHDL benchmark to their list.

Since PyPy has quite a lot of mindshare on sites such as HackerNews,
reddit/programming, etc, if you manage to get "featured" by them (in
their blog, or on their benchmark page, for example) you'd surely get
a huge boost to the number of people that know about MyHDL.

As for your performance comparison, I wonder if it would make sense to
manually write equivalent VHDL and Verilog tests, and compare those to
the automatically generated ones (with MyHDL). If the results are
similar it would make a really strong case that Verilog and VHDL code
generated with MyHDL is as efficient as code directly written in those
languages. I know that is a concern to some people when they get
introduced to MyHDL so anything that can prove that is not the case
would be great.

I would say that they only drawback of the PyPy apporach is that,
AFAIK, there is currently no stand-alone windows installer. Hopefully
that will be addressed by the PyPy guys soon.

Cheers,

Angel


On Tue, Jun 7, 2011 at 2:15 PM, Jan Decaluwe <ja...@ja...> wrote:
> A few weeks ago, I posted the following:
>
>> From: Jan Decaluwe <ja...@ja...>
>> Newsgroups: gmane.comp.python.myhdl
>> Subject: My take on MyHDL weaknesses - and solutions
>> Date: Mon, 04 Apr 2011 11:00:23 +0200
>> ...
>> Solution 2: The PyPy project (future). Python doesn't have
>> to be slow: by employing clever JIT techniques, performance
>> can be improved drastically e.g. 5-10x. I believe that MyHDL
>> is a good candidate for this type of optimization. The day
>> this happens would be one of the most important ones in
>> MyHDL's history: the performance limitations would for a
>> large part go away, and it would be the ultimate validation
>> of the concept: benefitting from advances without having to
>> do anything yourself :-)
>
> I'm very happy to report that it looks like this day has
> arrived now. PyPy 1.5 is compatible with Python 2.7, and
> I'm seeing really spectacular speedup factors.
>
> I have documented my findings extensively here:
>
>     http://www.myhdl.org/doku.php/performance
>
> Obviously, I would like to create some buzz about this, but
> I want to move carefully. First I would like to know if
> people with relevant simulations get similar results.
>
> Feedback is therefore very welcome; I think everything needed
> to get started is documented on the page mentioned above.
>
> 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
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

[myhdl-list] It's a beautiful day

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

A few weeks ago, I posted the following:

> From: Jan Decaluwe <ja...@ja...>
> Newsgroups: gmane.comp.python.myhdl
> Subject: My take on MyHDL weaknesses - and solutions
> Date: Mon, 04 Apr 2011 11:00:23 +0200
> ...
> Solution 2: The PyPy project (future). Python doesn't have
> to be slow: by employing clever JIT techniques, performance
> can be improved drastically e.g. 5-10x. I believe that MyHDL
> is a good candidate for this type of optimization. The day
> this happens would be one of the most important ones in
> MyHDL's history: the performance limitations would for a
> large part go away, and it would be the ultimate validation
> of the concept: benefitting from advances without having to
> do anything yourself :-)

I'm very happy to report that it looks like this day has
arrived now. PyPy 1.5 is compatible with Python 2.7, and
I'm seeing really spectacular speedup factors.

I have documented my findings extensively here:

     http://www.myhdl.org/doku.php/performance

Obviously, I would like to create some buzz about this, but
I want to move carefully. First I would like to know if
people with relevant simulations get similar results.

Feedback is therefore very welcome; I think everything needed
to get started is documented on the page mentioned above.

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] Packaging for Fedora

[Shakthi K. <sha...@gm...>]

Hi,

Can you please update the LICENSE.txt in myhdl sources to reflect the
updated FSF address from:

   59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

to

  51 Franklin Street, Suite 500, Boston, MA 02110-1335

rpmlint is giving me E: incorrect-fsf-address.

Thanks!

SK

-- 
Shakthi Kannan
http://www.shakthimaan.com

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

[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/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

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] Clump'n and Lump'n

[Christopher F. <chr...@gm...>]

On 6/2/2011 1:41 PM, Uri Nix wrote:
> Hi,
>
> In my experience SystemC+Boost is functionally equivalent to MyHDL for
> system modelling, although the LA and PE for Python is an order of magnitude
> easier.
> Another significant advantage of Python is its cross platform portability
> (Windows, Unix, Linux, etc), which saves the hassle of deployment and
> managing different build chains.
>
> Cheers,
> Uri

Yes, I agree!  Using the numerical packages in Python is much easier. 
To your point I can open a Python shell and do the following:
 >> from numpy import *
 >> X = random.rand(3,3)
 >> matrix(X) * matrix(X[1,:]).transpose()
 >>
matrix([[ 0.53398746],
         [ 0.96773496],
         [ 1.01327792]])

#... expand to myhdl ...
 >> sX = Signal(matrix(X))
 >> sY = Signal(matrix(X[1,:].transpose())
 >> sX.next = sX * sY
#...

And easily incorporate into my design without much issue (the above is 
way too simple of an example).  I can quite easily do complicated system 
modeling; mixing cycle and bit-accurate if needed.

It has been awhile since I used SystemC (over 5 years?).  I remember it 
being difficult (relative) and I am a pretty proficient C/C++ 
programmer.  But it could have been that I gave up on SystemC when I 
started using MyHDL more :)

Then I can create all my plots for analysis right in my simulation, I 
don't have to post-process simulation results.

The only argument might be simulation speed.  But I am usually done with 
my development and simulations and onto the next item, before I would 
have completed a C* implementation, making the simulation speeds a moot 
point.

I have also found interface MyHDL with simulators to be easier than 
SystemC.  I guess it is the Python *batteries-included*!

Chris

Re: [myhdl-list] Clump'n and Lump'n

[Uri N. <ur...@gm...>]

Hi,

In my experience SystemC+Boost is functionally equivalent to MyHDL for
system modelling, although the LA and PE for Python is an order of magnitude
easier.
Another significant advantage of Python is its cross platform portability
(Windows, Unix, Linux, etc), which saves the hassle of deployment and
managing different build chains.

Cheers,
Uri

On 31 May 2011 19:54, Christopher Felton <chr...@gm...> wrote:

> <snip>
> >
> > On a scale 1-3, 1 being highest/best how would you rate the metrics
> > outlined in the paper? (The metrics are mainly time and resources, a
> > lower value in time and resources are better, hence 1 being best).
> >
>
>            MyHDL | JHDL | Verilog | VHDL | ImpC | HanC | SystemC | SV
> 1. LA        1      n/a      2        3     n/a    n/a     7        3
> 2. PE        1      n/a      2        2     n/a    n/a     3        3
> 3. OE        2      n/a      2        2     n/a    n/a     3        2
>
>
> Note : I can't declare the same level of competence in SystemC and SV as
> the others.
>
> .chris
>
>
>
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is
> safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Packaging for Fedora

[Christopher F. <chr...@gm...>]

On 6/1/2011 10:53 AM, Shakthi Kannan wrote:
> Hi,
>
> This is Shakthi from the Fedora Electronic Lab project, and I am
> interested in packaging MyHDL for Fedora.
>
> I would like to know is there any specific target FPGA boards that
> people here use or recommend to test the VHDL/Verilog code generated
> from MyHDL.

I use this board, http://www.dsptronics.com/product.html.  A couple 
other MyHDL'ers have used this board as well.  There are some examples 
available http://www.dsptronics.com/start.html.

There have been some recent thread-discussions on other development 
boards.  I believe, a plethora of boards are used by MyHDL'ers. 
Including Lattice boards, terasic Altera DE* boards, Digilent Nexsys, 
etc.  I don't know if there is "one" board that covers a majority of 
developers.  I imagine the MyHDL developers are diverse with many 
different needs and the number of boards used varies considerably.

Hope that helps.

Disclaimer: I have an interest in DSPtronincs, I do design consulting 
for them.

Regards,
Chris Felton

Re: [myhdl-list] Using MyHDL with existing infrastructure

[Christopher F. <chr...@gm...>]

On 6/2/2011 8:01 AM, Christopher Felton wrote:
> <snip>
>>
>> One important aspect I'd like to preserve is the ability to place a top
>> level port intended to be connected to the PowerPC deep within the
>> hierarchy of the design without having to bring the signals all the
>> way to the top level explicitly. I haven't seen a way to do this in
>> MyHDL, but it seems like it should be possible since the resulting
>> VHDL ends up with a flattened hierarchy anyway.
>>
<snip>
>       toVHDL(BurriedInstance, clk, rst, data_in, data_out)
>
(d'oh, hit send to early)

You will need the latest MyHDL release (0.7).  The only issue might be 
running MyHDL simulations.  You might want to use the __debug__ and 
define some simple logic to enable MyHDL simulations.

Below is a snippet of the VHDL generated:

architecture MyHDL of BurriedInstance is
begin
     P1:ppc port map(clk, rst, data_in, data_out);

end architecture MyHDL;

Regards,
Chris Felton

Re: [myhdl-list] Using MyHDL with existing infrastructure

[Christopher F. <chr...@gm...>]

<snip>
>
> One important aspect I'd like to preserve is the ability to place a top
> level port intended to be connected to the PowerPC deep within the
> hierarchy of the design without having to bring the signals all the
> way to the top level explicitly. I haven't seen a way to do this in
> MyHDL, but it seems like it should be possible since the resulting
> VHDL ends up with a flattened hierarchy anyway.
>
> I appreciate any suggestions. I'm happy to clarify anything that
> might be confusing.
>
> Thanks in advance,
> Glenn
>

Here is a small example to achieve what (I think) you are describing. 
More information can be found here,
http://www.myhdl.org/doc/current/manual/conversion_examples.html#conv-usage-custom

from myhdl import *

def BurriedInstance(clk, rst, data_in, data_out):

     # ... Some Code
     bi = nativeInstance(clk, rst, data_in, data_out)
     # ... Some More Code

     return bi  #other generators

def nativeInstance(clk, rst, data_in, data_out):

     @always(clk, rst, data_in)
     def pass_thru():
         pass
     data_out.driven = "wire"

     nativeInstance.vhdl_code = """
     P1:ppc port map($clk, $rst, $data_in, $data_out);
     """

     return pass_thru


if __name__ == '__main__':
     clk = Signal(False)
     rst = Signal(False)
     data_in  = Signal(intbv(0)[8:])
     data_out = Signal(intbv(0)[8:])
     toVHDL(BurriedInstance, clk, rst, data_in, data_out)


>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev

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

[myhdl-list] Using MyHDL with existing infrastructure

[glenn <jon...@ca...>]

Hello,
Currently I use Simulink with Xilinx System Generator to generate DSP designs 
in VHDL which I then use in a board with well defined peripherals and an
FPGA-PowerPC interface for setting/reading registers on the FPGA. To do this,
I have scripts that automatically generate a PCORE from the XSG design by
generating the necessary bbd and mpd files. The bbd file is trivial to 
generate.
To generate the mpd, which contains information about the top level ports of
the design, the tools are able to figure out the top level ports of the 
Simulink design. Special blocks are used to represent signals that should be
connected to the PowerPC bus. These blocks wrap the "gateway in/out" blocks 
that are used to instantiate a top level port.

I've taken a brief look at the code used by the toVHDL function, and it 
seems like it should be possible to do something similar. One way might be to 
define a subclass of Signal that when encountered by the analyzer provides 
information for the mpd file, but otherwise acts just like a normal signal.

One important aspect I'd like to preserve is the ability to place a top 
level port intended to be connected to the PowerPC deep within the 
hierarchy of the design without having to bring the signals all the 
way to the top level explicitly. I haven't seen a way to do this in 
MyHDL, but it seems like it should be possible since the resulting 
VHDL ends up with a flattened hierarchy anyway.

I appreciate any suggestions. I'm happy to clarify anything that 
might be confusing.

Thanks in advance,
Glenn

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

[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

[myhdl-list] Packaging for Fedora

[Shakthi K. <sha...@gm...>]

Hi,

This is Shakthi from the Fedora Electronic Lab project, and I am
interested in packaging MyHDL for Fedora.

I would like to know is there any specific target FPGA boards that
people here use or recommend to test the VHDL/Verilog code generated
from MyHDL.

Thanks!

SK

-- 
Shakthi Kannan
http://www.shakthimaan.com

Re: [myhdl-list] Clump'n and Lump'n

[Christopher F. <chr...@gm...>]

<snip>
>
> On a scale 1-3, 1 being highest/best how would you rate the metrics
> outlined in the paper? (The metrics are mainly time and resources, a
> lower value in time and resources are better, hence 1 being best).
>

            MyHDL | JHDL | Verilog | VHDL | ImpC | HanC | SystemC | SV
1. LA        1      n/a      2        3     n/a    n/a     7        3
2. PE        1      n/a      2        2     n/a    n/a     3        3
3. OE        2      n/a      2        2     n/a    n/a     3        2


Note : I can't declare the same level of competence in SystemC and SV as 
the others.

.chris

[myhdl-list] Clump'n and Lump'n

[Christopher F. <chr...@gm...>]

Hmmm, browsing the internet (instead of being focused and disciplined) I 
ran across this article

http://www1.cse.wustl.edu/~jain/cse567-08/ftp/fpgaprog/index.html#_Toc215239805 
.

The interesting point that caught my attention, was that MyHDL was 
clumped together with the C-based tools.  The author categorized MyHDL 
with ImpulseC, HandelC, SystemC, and JHDL.  The author dubbed these 
languages "Adapted Sequential HDL Programming Languages" (ASPL).  The 
goal of the study was to measure ASPLs against THDL (traditional HDLs 
i.e. Verilog/VHDL).  But I don't see any results for the proposed 
experiments.

Then the author proposes a method to measure the languages effectiveness 
based on :
   1. Language Acquisition [LA](time to learn the language, given??)
   2. Programming Efficiency [PE] (time to implement and debug design)
   3. Operational Efficiency [OE] (resources used)
(see the link for more information on the metrics)

These are tricky and somewhat subjective metrics (as the author states).

Anyone else have experience with the C/java based HDL languages?  How 
was the experience vs. MyHDL?

On a scale 1-3, 1 being highest/best how would you rate the metrics 
outlined in the paper? (The metrics are mainly time and resources, a 
lower value in time and resources are better, hence 1 being highest, 
lowest score wins!).

          MyHDL | JHDL | Verilog | VHDL | ImpC | HanC | SystemC | SV
1. LA
2. PE
3. OE


.chris

Re: [myhdl-list] Wrap-around support in MyHDL

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

On 05/30/2011 06:03 PM, Christopher Felton wrote:

> I didn't notice this in the previous draft but there is an error in the
> code examples; handling wrap using modulus (Wrap-around type proposals).

Of course. Go ahead and edit (it's a draft :-))

-- 
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] Wrap-around support in MyHDL

[Christopher F. <chr...@gm...>]

On 5/29/2011 4:55 PM, Jan Decaluwe wrote:
> On 05/20/2011 05:25 PM, Jan Decaluwe wrote:
>> As you like the proposal after putting the feature
>> back on the map, and I hear no objections, I'd like
>> to make some progress.
>>
>> This is definitely a 0.8 feature, so I will open
>> a 0.8-dev branch for development. I will also turn
>> the proposal into a MEP.
>
> http://myhdl.org/doku.php/meps:mep-106
>

I made a couple other small edits to the mep.  Typo and added a link. 
Feel free to remove :)

Chris

Re: [myhdl-list] Wrap-around support in MyHDL

[Christopher F. <chr...@gm...>]

On 5/29/2011 4:55 PM, Jan Decaluwe wrote:
> On 05/20/2011 05:25 PM, Jan Decaluwe wrote:
>> As you like the proposal after putting the feature
>> back on the map, and I hear no objections, I'd like
>> to make some progress.
>>
>> This is definitely a 0.8 feature, so I will open
>> a 0.8-dev branch for development. I will also turn
>> the proposal into a MEP.
>
> http://myhdl.org/doku.php/meps:mep-106
>

I didn't notice this in the previous draft but there is an error in the 
code examples; handling wrap using modulus (Wrap-around type proposals).

"""
   if count == N:
         count.next = 0
         some_decode_action()
     else:
         count.next = count + 1
...

     if count == N:
         some_decode action()

     count.next = (count + 1) % N
"""

The code snippets should be count == 0 or count = N-1, count will never 
actually equal N in the "%" case.  The first case will not act like a mod.

To double check my sanity, here is a small capture from a python session:
   In [176]: N = 2**3
   In [179]: count = intbv(0, min=0, max=N)
   In [180]: for ii in range(2*N):
      .....:     if count == N:
      .....:         print "Do some action"
      .....:     count[:] = (count + 1) % N
      .....:     print count
   1
   2
   3
   4
   5
   6
   7
   0
   1
   2
   3
   4
   5
   6
   7
   0
   In [181]: N
   Out[181]: 8


Chris