myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] intbv addition

[Sami Al D. <sam...@gm...>]

Hi,

I was experimenting with intbv(), and I found out for example if you have

a=intbv(3)[2:]
b=intbv(1)[2:]
c=a+b

the sum (c) is not 'intbv' class, its 'long' if I'm not mistaken. How
can we get the sum to be 'intbv' of the same bitwidth (in this case
2)?

-- 
Best Regards
Sami Aldalahmeh

Re: [myhdl-list] intbv return types and a fixed-point Object

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

>
>
> >
> > The change was to the _intbv.py.  All math operations were changed to
> > return a intbv type versus an int type.
>
> Thanks for the work, that really helps.
>
> In your example, the peformance hit is around 7%. Not dramatic perhaps,
> but not negligible either.
>
> On the other hand, we would probably get this back easily (and more) if
> _intbv.py is redone in C, which may make a lot of sense just like Signal.
>
> I still hesitate. If the reason is purely esthetics, that doesn't seem
> enough for the change. But if there is a valid technical reason, I have
> nothing against it either. What does the community think?
>
> Jan
>

If such performance improvements were attempted would it be better to focus
on the Signal class.  In the profiles I have captured the Signal class
consumes much more than intbv.

The C implementations get tricky, cross-compile multiple platforms etc.
 Before such an effort is undertaken it might make sense to simply define
the C interface.  The numpy folks have done something similar.  Defined
"ctypes" types.
http://www.scipy.org/Cookbook/Ctypes
http://mentat.za.net/ctpug-numpy/ctypes.html

If "ctype" types were defined for intbv and Signal that might be enough to
start implementing portions in C-code.
Ctypes might not be as efficient as actually embedding  C code but could be
a easier approach.  I don't have much experience in this area others may
want to comment.

Another major bottleneck is how python handles the generators (schedules
them)?  Would this be correct?  Is the simulation performance mainly
dictated by this?

It sounds like most are busy and this topic will have to be put on the back
burner.

Chris

Re: [myhdl-list] arithmetic trouble

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

On Sat, May 16, 2009 at 2:16 AM, Jan Decaluwe <ja...@ja...> wrote:

> Christopher L. Felton wrote:
>
> > But the questions can be asked, since the operation is broken into
> > intermediate steps, could the converter do this?  Could it automagically
> > break a complex operation into multiple steps?
>
> It could potentially do this, just as it now does resizes in VHDL.
> Of course it may not worth the trouble.
>
> > I believe you would have to be careful here though.  You do not want
> > complication or too much inference from the converter.  You would want a
> > very simple rule for Verilog that could be implemented.  There are many
> > scenarios where an intermediate result requires a larger bit-value.
> > Basically anytime a complex operation (equation) has an increasing and
> > decreasing component you can run into this simulation mismatch.  If we
> > prevent the operations we would have to prevent all combinations of
> > increasing and decreasing, such as:
> >   (a + b)  - c
> >   (a + b)  >> c
> >   (a * b)  - c
> >   (a * b)  >> c
> >   (a << b) - c
> >   (a << b) >> c
> > etc, etc.
> >
> > Some of these may not make sense (rarely used) but they are all (BOMK)
> > valid statements.  The verilog converter would have to restrict all of
> > these or handle all of them.  I don't know which is the best answer, yet.
>
> Implementing the restriction is probably easy to do: the right operand
> of certain operations (>>>, -) should be a plain name.
>
> I'm inclined to start with this solution. I guess most designers will
> find it acceptable.
>
> A fundamental solution would be easiest with a resize like in VHDL.
> Absent that, we would have to infer intermediate variables etc.,
> which would add all kinds of complexities. Probably not worth the
> effort at this point.
>
> Jan
>

Should we add this to the open task list (
http://www.myhdl.org/doku.php/dev:tasks)<http://www.myhdl.org/doku.php/dev:tasks>?
 As mentioned this is considered a bug because of the simulation mismatch.
 Think we have captured information on the issue.

Verilog will only use the largest "size" that exists in a expression.
 Intermediate results will only be as large as the largest declared reg /
wire.  This doesn't match how python handles the operations.

Since I have been following this issue, some, I can volunteer for this task.
 I just can't promise any fast results.

Chris

Re: [myhdl-list] [Fwd: myHDL RPM package for fedora ?]

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

Hi,

I maintain a MyHDL RPM package for openSUSE. Even though the build
service also provides the possibility to build for Fedora, at the moment
I don't have the time and experience to adjust the .spec file to build
for Fedora.

I am offering my .spec file here in case someone wants to base a Fedora
build on it.

Cheers,

Guenter


-------------------------------------------------------------------------


Name:           python-myhdl
Version:        0.6
Release:        1
Source:         myhdl-%{version}.tar.gz
License:        GPL
Autoreqprov:    on
BuildRoot:      %{_tmppath}/%{name}-%{version}-build
BuildRequires:  python-devel
Group:          Development/Libraries/Python
Summary:        Python module for digital logic development
Url:            http://myhdl.jandecaluwe.com
Packager:       Guenter Dannoritzer <dan...@we...>
%{py_requires}

%description
MyHDL is an open source Python package that lets you go from Python to
silicon.
With MyHDL, you can use Python as a hardware description and
verification language.
Furthermore, you can convert implementation-oriented MyHDL code to Verilog
automatically, and take it to a silicon implementation from there.

Authors:
--------
    Jan Decaluwe <ja...@ja...>

%prep
%setup -n myhdl-%{version}

%build
export CFLAGS="$RPM_OPT_FLAGS"
python setup.py build

%install
python setup.py install --prefix=%{_prefix} --root=$RPM_BUILD_ROOT
--record-rpm=INSTALLED_FILES

%clean
rm -rf "$RPM_BUILD_ROOT"

%files -f INSTALLED_FILES
%defattr(-,root,root)
%doc CHANGES.txt LICENSE.txt PKG-INFO README.txt
%doc example
%doc cosimulation


%changelog -n python-myhdl
* Fri Jan 09 2009 - dan...@we... - 0.6
- update to 0.6
* Mon Feb 05 2007 - dan...@we...
- initial package

[myhdl-list] [Fwd: myHDL RPM package for fedora ?]

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

See below a mail I received to package MyHDL for Fedora.
Looking for a volunteer ...


-- 
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] new example for MyHDL about opencores.org projects rewrite

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

Xiang Li wrote:
> I agree with your idea completely. One big disadvantage of projects from 
> opencores.org is that many of them are lack of thorough verification. 
> Bugs are associated with them.  Python has its merit that it is an 
> object oriented programming language and nowadays object oriented idea 
> is widely applied in SoC verification. It might be possible that we can 
> build a new verification methodology using MyHDL. I will try it to see 
> the possibility.

So there you have the project that you were looking for. If you
can help to get this type of work on the rails, that would be
a great contribution.

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] new example for MyHDL about opencores.org projects rewrite

[Xiang Li <u46...@an...>]

I agree with your idea completely. One big disadvantage of projects from opencores.org is that many of them are lack of thorough verification. Bugs are associated with them.  Python has its merit that it is an object oriented programming language and nowadays object oriented idea is widely applied in SoC verification. It might be possible that we can build a new verification methodology using MyHDL. I will try it to see the possibility. 

----- Original Message -----
From: Jan Decaluwe <ja...@ja...>
Date: Wednesday, May 20, 2009 3:40 pm
Subject: Re: [myhdl-list] new example for MyHDL
To: myh...@li...

> Xiang Li wrote:
> > Hello all, I am a new user of MyHDL project. MyHDL is really a 
> good 
> > project, which is ideal for software guys who are familiar 
> with python 
> > and trying to do hardware development . I just wrote a 
> miniuart project 
> > using MyHDL(rewrote from the source code downloaded from 
> opencore 
> > website), for those novices who just come to the hardware 
> world, it is a 
> > very good example for you. 
> 
> Actually this may be a very good idea to combine learning by newbies
> and creating actual value: Redo opencores.org in MyHDL! I see a
> number of advantages:
> 
> * a large set of examples to choose from, at various complexity levels
> * newbies have a clear spec, in the form of the exising implementation
> * I'm sure many projects can be improved, especially in the area of
>   verification - MyHDL modeling might really help here
> * the end result also gives something back to the community, as you
>   would now be able to use the core in 3 HDLs thanks to 
> conversion.  The fact that all cores would be available in 
> both VHDL and
>   Verilog might be very interesting to opencores users.
> 
> I guess it's OK to use the existing opencores.org infrastructure
> to publish MyHDL cores.
> 
> 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
> 
> 
> -----------------------------------------------------------------
> -------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables 
> unlimited royalty-free distribution of the report engine 
> for externally facing server and web deployment. 
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] new example for MyHDL receiver key signals timing diagram

[Xiang Li <u46...@an...>]

The attachment is the timing diagram of receiver. From this small simple uart project, we can see that whether you are using verilog, VHDL or python to describe hardware, firstly, you should have hardware structure in your mind; secondly, timing diagram in your mind. <br><br>----- Original Message -----<br>From: Xiang Li &lt;u46...@an...&gt;<br>Date: Monday, May 18, 2009 10:57 pm<br>Subject: [myhdl-list] new example for MyHDL<br>To: myh...@li...<br><br><font style="font-style: normal; font-weight: normal; background-color: rgb(245, 248, 240); font-size: 14px;">&gt; </font>Hello all, I am a new user of MyHDL project. MyHDL is really a good project, which is ideal for software guys who are familiar with python and trying to do hardware development . I just wrote a miniuart project using MyHDL(rewrote from the source code downloaded from opencore website), for those novices who just come to the hardware world, it is a very good example for you. But if you are the experienced guys, then it might&nbsp; not be useful to you. This time I first attach one part of it, the receiver part source code and the generated verilog file, the others and document will be submitted in the next few days. &nbsp;  &gt; -----------------------------------------------------------------<br>&gt; -------------<br>&gt; Crystal Reports - New Free Runtime and 30 Day Trial<br>&gt; Check out the new simplified licensing option that enables <br>&gt; unlimited royalty-free distribution of the report engine <br>&gt; for externally facing server and web deployment. <br>&gt; http://p.sf.net/sfu/businessobjects&gt; _______________________________________________<br>&gt; myhdl-list mailing list<br>&gt; myh...@li...<br>&gt; https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] new example for MyHDL, transciver diagram is coming

[Xiang Li <u46...@an...>]

It is very simple. just use openoffice.org drawing tools is ok. 

----- Original Message -----
From: Jose Cuello <jc...@gm...>
Date: Wednesday, May 20, 2009 1:25 pm
Subject: Re: [myhdl-list] new example for MyHDL, transciver diagram is coming
To: General discussions on MyHDL <myh...@li...>

> On Tue, May 19, 2009 at 9:26 PM, Xiang Li <u46...@an...> wrote:
>  Hi, 
> 
> This time I add a rough structure diagram of transceiver of UART program for your reference. Hopefully, it will help you to understand the code of UART transceiver. 
> 
> ----- Original Message -----
> From: Xiang Li <u46...@an...>
>  Date: Monday, May 18, 2009 10:57 pm
> Subject: [myhdl-list] new example for MyHDL
> To: myh...@li...
> 
> > Hello all, I am a new user of MyHDL project. MyHDL is really a good project, which is ideal for software guys who are familiar with python and trying to do hardware development . I just wrote a miniuart project using MyHDL(rewrote from the source code downloaded from opencore website), for those novices who just come to the hardware world, it is a very good example for you. But if you are the experienced guys, then it might  not be useful to you. This time I first attach one part of it, the receiver part source code and the generated verilog file, the others and document will be submitted in the next few days.    > -----------------------------------------------------------------
>  > -------------
> > Crystal Reports - New Free Runtime and 30 Day Trial
> > Check out the new simplified licensing option that enables 
> > unlimited royalty-free distribution of the report engine 
> > for externally facing server and web deployment. 
>  > http://p.sf.net/sfu/businessobjects> _______________________________________________
> > myhdl-list mailing list
> > myh...@li...
>  > https://lists.sourceforge.net/lists/listinfo/myhdl-list 
> ------------------------------------------------------------------------------
>  Crystal Reports - New Free Runtime and 30 Day Trial
>  Check out the new simplified licensing option that enables
>  unlimited royalty-free distribution of the report engine
>  for externally facing server and web deployment.
 > http://p.sf.net/sfu/businessobjects
> _______________________________________________
>  myhdl-list mailing list
 > myh...@li...
 > https://lists.sourceforge.net/lists/listinfo/myhdl-list
 > 
> 
> Nice diagram and it does help a lot more. Just curious, what software you use to generate those graphics? I've been trying to find a good free tool that does that, I've tried Dia but I don't like it very much. > 
> Thanks! > -----------------------------------------------------------------
> -------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables 
> unlimited royalty-free distribution of the report engine 
> for externally facing server and web deployment. 
> http://p.sf.net/sfu/businessobjects> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] future improvements suggestion

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

Xiang Li wrote:
> During the period that I was using MyHDL. I think there might be a 
> improvement in the future, maybe it can be another open task. As we have 
> seen that in verilog. we will define the module name and the associated 
> input/output pins like below:

One module's input is always another module's output :-)

As you use MyHDL for modeling and conversion, you will note that
it works well without input/output declarations. In fact, the only
thing what could we do with this is to check whether usage
and declaration match. This may make sense, but it is not the
philosophy of dynamic languages such as Python. In other words,
it's fine for VHDL/Verilog, but not for a Python-based HDL.

I'm agree that this info is useful for human readers. The Python way is
to document parameter and their purpose in the docstring of
a function. For examples see:
    http://www.myhdl.org/doku.php/cookbook:intro

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] new example for MyHDL

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

Xiang Li wrote:
> Hello all, I am a new user of MyHDL project. MyHDL is really a good 
> project, which is ideal for software guys who are familiar with python 
> and trying to do hardware development . I just wrote a miniuart project 
> using MyHDL(rewrote from the source code downloaded from opencore 
> website), for those novices who just come to the hardware world, it is a 
> very good example for you. 

Actually this may be a very good idea to combine learning by newbies
and creating actual value: Redo opencores.org in MyHDL! I see a
number of advantages:

* a large set of examples to choose from, at various complexity levels
* newbies have a clear spec, in the form of the exising implementation
* I'm sure many projects can be improved, especially in the area of
  verification - MyHDL modeling might really help here
* the end result also gives something back to the community, as you
  would now be able to use the core in 3 HDLs thanks to conversion.
  The fact that all cores would be available in both VHDL and
  Verilog might be very interesting to opencores users.

I guess it's OK to use the existing opencores.org infrastructure
to publish MyHDL cores.

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] new example for MyHDL, transciver diagram is coming

[Jose C. <jc...@gm...>]

On Tue, May 19, 2009 at 9:26 PM, Xiang Li <u46...@an...> wrote:

> Hi,
>
> This time I add a rough structure diagram of transceiver of UART program
> for your reference. Hopefully, it will help you to understand the code of
> UART transceiver.
>
> ----- Original Message -----
> From: Xiang Li <u46...@an...>
> Date: Monday, May 18, 2009 10:57 pm
> Subject: [myhdl-list] new example for MyHDL
> To: myh...@li...
>
> > Hello all, I am a new user of MyHDL project. MyHDL is really a good
> project, which is ideal for software guys who are familiar with python and
> trying to do hardware development . I just wrote a miniuart project using
> MyHDL(rewrote from the source code downloaded from opencore website), for
> those novices who just come to the hardware world, it is a very good example
> for you. But if you are the experienced guys, then it might  not be useful
> to you. This time I first attach one part of it, the receiver part source
> code and the generated verilog file, the others and document will be
> submitted in the next few days.   >
> -----------------------------------------------------------------
> > -------------
> > Crystal Reports - New Free Runtime and 30 Day Trial
> > Check out the new simplified licensing option that enables
> > unlimited royalty-free distribution of the report engine
> > for externally facing server and web deployment.
> > http://p.sf.net/sfu/businessobjects>
> _______________________________________________
> > myhdl-list mailing list
> > myh...@li...
> > https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables
> unlimited royalty-free distribution of the report engine
> for externally facing server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
Nice diagram and it does help a lot more. Just curious, what software you
use to generate those graphics? I've been trying to find a good free tool
that does that, I've tried Dia but I don't like it very much.

Thanks!

Re: [myhdl-list] new example for MyHDL, transciver diagram is coming

[Xiang Li <u46...@an...>]

Hi, <br><br>This time I add a rough structure diagram of transceiver of UART program for your reference. Hopefully, it will help you to understand the code of UART transceiver. <br><br>----- Original Message -----<br>From: Xiang Li &lt;u46...@an...&gt;<br>Date: Monday, May 18, 2009 10:57 pm<br>Subject: [myhdl-list] new example for MyHDL<br>To: myh...@li...<br><br><font style="font-style: normal; font-weight: normal; background-color: rgb(245, 248, 240); font-size: 14px;">&gt; </font>Hello all, I am a new user of MyHDL project. MyHDL is really a good project, which is ideal for software guys who are familiar with python and trying to do hardware development . I just wrote a miniuart project using MyHDL(rewrote from the source code downloaded from opencore website), for those novices who just come to the hardware world, it is a very good example for you. But if you are the experienced guys, then it might&nbsp; not be useful to you. This time I first attach one part of it, the receiver part source code and the generated verilog file, the others and document will be submitted in the next few days. &nbsp;  &gt; -----------------------------------------------------------------<br>&gt; -------------<br>&gt; Crystal Reports - New Free Runtime and 30 Day Trial<br>&gt; Check out the new simplified licensing option that enables <br>&gt; unlimited royalty-free distribution of the report engine <br>&gt; for externally facing server and web deployment. <br>&gt; http://p.sf.net/sfu/businessobjects&gt; _______________________________________________<br>&gt; myhdl-list mailing list<br>&gt; myh...@li...<br>&gt; https://lists.sourceforge.net/lists/listinfo/myhdl-list

[myhdl-list] future improvements suggestion

[Xiang Li <u46...@an...>]

During the period that I was using MyHDL. I think there might be a improvement in the future, maybe it can be another open task. As we have seen that in verilog. we will define the module name and the associated input/output pins like below:

module modulename(
                                    pinname1,
                                    pinname2,
                                    ...
                                   );
input  pinname1;
output pinname2;
...

But in MyHDL, we define it like this
def modulename(pinname1, pinname2,...):

Obviously, MyHDL lack of a corresponding function to define the pinname as an input or output. As I think, it might be improved in the future.

Re: [myhdl-list] new example for MyHDL, transciver is coming

[Xiang Li <u46...@an...>]

Hi all,<br><br>The new miniuart transciver file is coming along with its generated verilog file. Hopefully, you will like it<br><br>----- Original Message -----<br>From: Xiang Li &lt;u46...@an...&gt;<br>Date: Monday, May 18, 2009 10:57 pm<br>Subject: [myhdl-list] new example for MyHDL<br>To: myh...@li...<br><br><font style="font-style: normal; font-weight: normal; background-color: rgb(245, 248, 240); font-size: 14px;">&gt; </font>Hello all, I am a new user of MyHDL project. MyHDL is really a good project, which is ideal for software guys who are familiar with python and trying to do hardware development . I just wrote a miniuart project using MyHDL(rewrote from the source code downloaded from opencore website), for those novices who just come to the hardware world, it is a very good example for you. But if you are the experienced guys, then it might&nbsp; not be useful to you. This time I first attach one part of it, the receiver part source code and the generated verilog file, the others and document will be submitted in the next few days. &nbsp;  &gt; -----------------------------------------------------------------<br>&gt; -------------<br>&gt; Crystal Reports - New Free Runtime and 30 Day Trial<br>&gt; Check out the new simplified licensing option that enables <br>&gt; unlimited royalty-free distribution of the report engine <br>&gt; for externally facing server and web deployment. <br>&gt; http://p.sf.net/sfu/businessobjects&gt; _______________________________________________<br>&gt; myhdl-list mailing list<br>&gt; myh...@li...<br>&gt; https://lists.sourceforge.net/lists/listinfo/myhdl-list

[myhdl-list] 回复： new example for MyHDL

[南昌 <gun...@ya...>]

Hi, I am a student who is now learning hardware design, and I was a graduate from software field with some experience in python. MyHDL really helps me to understand the idea of hardware design because it gives me an alternative way for me to understand the idea.  
But currently the examples with MyHDL is limited. The appearance of your new example is really helpful. I look forward to seeing more parts of your example 


--- 09年5月18日，周一, Xiang Li <u46...@an...> 写道：


发件人: Xiang Li <u46...@an...>
主题: [myhdl-list] new example for MyHDL
收件人: myh...@li...
日期: 2009年5月18日,周一,下午8:22


Hello all, I am a new user of MyHDL project. MyHDL is really a good project, which is ideal for software guys who are familiar with python and trying to do hardware development . I just wrote a miniuart project using MyHDL(rewrote from the source code downloaded from opencore website), for those novices who just come to the hardware world, it is a very good example for you. But if you are the experienced guys, then it might  not be useful to you. This time I first attach one part of it, the receiver part source code and the generated verilog file, the others and document will be submitted in the next few days.   
-----下面为附件内容-----


------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects
-----下面为附件内容-----


_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list



      ___________________________________________________________ 
  好玩贺卡等你发，邮箱贺卡全新上线！ 
http://card.mail.cn.yahoo.com/

Re: [myhdl-list] new example for MyHDL

[Jose C. <jc...@gm...>]

On Mon, May 18, 2009 at 8:22 AM, Xiang Li <u46...@an...> wrote:

> Hello all, I am a new user of MyHDL project. MyHDL is really a good
> project, which is ideal for software guys who are familiar with python and
> trying to do hardware development . I just wrote a miniuart project using
> MyHDL(rewrote from the source code downloaded from opencore website), for
> those novices who just come to the hardware world, it is a very good example
> for you. But if you are the experienced guys, then it might  not be useful
> to you. This time I first attach one part of it, the receiver part source
> code and the generated verilog file, the others and document will be
> submitted in the next few days.
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables
> unlimited royalty-free distribution of the report engine
> for externally facing server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
Thanks for sharing this, I am in the same boat as you are, I am very
interested in hardware design but when you come from a software background
little 'gotchas' of hardware make it a chore to get used to.

Hopefully MyHDL will teach me how to translate the design patterns that I am
so used to in softtware into the proper hardware ones; and if I don't I at
least had fun coding it in Python! :)

On that note I'd like to thank Jan Decaluwe and the rest of the MyHDL
development team, I can see nothing but good things coming from this
project.

[myhdl-list] new example for MyHDL

[Xiang Li <u46...@an...>]

Hello all, I am a new user of MyHDL project. MyHDL is really a good project, which is ideal for software guys who are familiar with python and trying to do hardware development . I just wrote a miniuart project using MyHDL(rewrote from the source code downloaded from opencore website), for those novices who just come to the hardware world, it is a very good example for you. But if you are the experienced guys, then it might  not be useful to you. This time I first attach one part of it, the receiver part source code and the generated verilog file, the others and document will be submitted in the next few days.   

Re: [myhdl-list] a few questions relating to recursive designs

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

Geoffrey Brown wrote:
> I thought I'd plunge in with a recursive structure (an N-way mux) which 
> follows.  I'm embarrassed
> how long it took me to figure this out.   Now here are a few questions.
> 
> 1)  I wanted to use a selector both as a bit vector and an integer.  
> Naturally
>    I made a signal from an intbv, but found the hard way that the obvious
>    thing, picking off bits by slicing, doesn't give you what is needed 
> (in this
>    context) -- another signal which has a subset of the bits from the 
> original
> 
>    I resorted to the (ugly) approach of passing an integer through the 
> hierarchy
>    so I could do the bit selection at the leaves.  Another ugly solution 
> would
>    be to define the selector as a list of signals and slice this up.  
> The problem
>    with this approach is that at the top level of the design one has to 
> bridge
>    from the single intbv to list of signals.

As other examples illustrate, recursive designs work quite well if you can
use lists of signals.
You can also use intbv Signals in recursion, but then you have to create
intermediate signals and the logic that drives them explicitly. So it
can be done, but this solution would indeed be rather ugly.

Your examples touch the area of MyHDL that I'm least satisfied with:
sometimes there is a valid need to consider the slice/index of a
signal as a signal itself. Currently, this can't be done and it
would require some new ideas/concepts in MyHDL. I would like to
see a breakthrough here and I have some ideas, but that is a
vast subject for separate thread.

>    Any thoughts on a more elegant approach ?
> 
> 2) It appears that to work with lists of signals, one must ensure that 
> at the
>     instance level the list has been unpacked into individual signals and at
>    the top level these lists are built from individual signals.    Is 
> this correct ?

First, any restrictions are related to convertibility, not modeling.

At the very top level, there is the problem that it's unclear how to
map lists of signals to Verilog ports. But again, this is only at the
top level of a design. In other words, it is possible that some module
cannot be converted as a top level design, but is perfectly convertible
within a hierarchy.

I'm not exactly sure what you mean with the restriction at the instance level.

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] arithmetic trouble

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

Christopher L. Felton wrote:

> But the questions can be asked, since the operation is broken into 
> intermediate steps, could the converter do this?  Could it automagically 
> break a complex operation into multiple steps? 

It could potentially do this, just as it now does resizes in VHDL.
Of course it may not worth the trouble.

> I believe you would have to be careful here though.  You do not want 
> complication or too much inference from the converter.  You would want a 
> very simple rule for Verilog that could be implemented.  There are many 
> scenarios where an intermediate result requires a larger bit-value.  
> Basically anytime a complex operation (equation) has an increasing and 
> decreasing component you can run into this simulation mismatch.  If we 
> prevent the operations we would have to prevent all combinations of 
> increasing and decreasing, such as:
>   (a + b)  - c
>   (a + b)  >> c
>   (a * b)  - c
>   (a * b)  >> c
>   (a << b) - c
>   (a << b) >> c
> etc, etc.
> 
> Some of these may not make sense (rarely used) but they are all (BOMK) 
> valid statements.  The verilog converter would have to restrict all of 
> these or handle all of them.  I don't know which is the best answer, yet.

Implementing the restriction is probably easy to do: the right operand
of certain operations (>>>, -) should be a plain name.

I'm inclined to start with this solution. I guess most designers will
find it acceptable.

A fundamental solution would be easiest with a resize like in VHDL.
Absent that, we would have to infer intermediate variables etc.,
which would add all kinds of complexities. Probably not worth the
effort at this point.

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] arithmetic trouble

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

Neal Becker wrote:

>>
> 
> I suppose (not tested) that using systemverilog cast on the operands before 
> the operation to cast to the wider result type would fix it?

Probably yes. How does this work, like resize in VHDL?

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] intbv return types and a fixed-point Object

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

Felton Christopher wrote:
>>>
>>
>> No, I think it would be straighforward. I expect that everything that
>> works now would continue working, except that you could do some
>> additional things. In particular, you could index and slice an
>> arithmetic expression.
>>
>> The only price would be simulation performance hit. The question is
>> whether this is worthwhile for a feature that is seldom (?) used.
>> Someone would have to analyze this in detail to make a good
>> decision. Perhaps the performance hit is irrelevant - I don't know.
>>
>> Jan
>>
> 
> 
> I took some time to profile this change.  I used the python built-in 
> cProfile.   Below are some numbers (warning lots of stuff below).  The 
> results are a little interesting.  The total time for the math ops 
> (__add__) effectively doubled.  But the overall simulation time 
> increased slightly.  From this limited test case (more needs to be done) 
> I would conclude that having the intbv math ops return and intbv type is 
> little effect on overall simulation performance.
> 
> The change was to the _intbv.py.  All math operations were changed to 
> return a intbv type versus an int type.

Thanks for the work, that really helps.

In your example, the peformance hit is around 7%. Not dramatic perhaps,
but not negligible either.

On the other hand, we would probably get this back easily (and more) if
_intbv.py is redone in C, which may make a lot of sense just like Signal.

I still hesitate. If the reason is purely esthetics, that doesn't seem
enough for the change. But if there is a valid technical reason, I have
nothing against it either. What does the community think?

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] arithmetic trouble

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

> Jan Decaluwe wrote:
>
>   
>> Christopher Felton wrote:
>>     
>>>     It works correctly if I break into 2 steps, where I use a tmp
>>>     variable of
>>>     _the correct bit width_ before shifting.
>>>
>>>     Is this a common issue with verilog simulators, or is mine just
>>>     broken?
>>>
>>>     Should my_hdl try to workaround this?
>>>
>>>
>>>
>>> I don't recall the exact rules off the top of my head, either.  But I
>>> think this is correct.  The language doesn't presume to know what the
>>> intermediate bit representation of the operator is (Verilog language).
>>>  If you want full precision for the multiply you have to do it in two
>>> steps as you indicated or have your output be the full range.
>>>
>>> BOMK everything is working correctly.  What you notice is a simulation
>>> mismatch?  The MyHDL simulates fine because the * uses full precision
>>> (infinite bits) and the bounds are not checked until the left hand side
>>> is assigned and that is after the shift.   Hmmmm, don't know if this
>>> would be a bug or not.  Not all aspects are convertible and this would
>>> fit that scenario.
>>>       
>> My rule is crystal-clear: if MyHDL code simulates fine and converts fine,
>> simulations should match. Otherwise, there is a bug - either in the
>> convertor or in the HDL simulator. For this it is not relevant whether
>> MyHDL does the "right" thing or not.
>>
>> So it looks like we have a bug here and now we have to find out
>> what it is. Of course, it may be that something cannot be reliably
>> converted, in which case the convertor should issue an error.
>>
>> Jan
>>
>>     
>
> I suppose (not tested) that using systemverilog cast on the operands before 
> the operation to cast to the wider result type would fix it?
>
>
>   
I don't think this would be a desired solution, because
  1.  Open-Source simulators (cver and icarus) will not support it.  As 
well as many of the synthesis tools.
  2.  In general, I think the converters try to use the lowest common 
denominator.  Meaning it uses the simplest, straight forward constructs 
of the underlying HDL (converting to).

But the questions can be asked, since the operation is broken into 
intermediate steps, could the converter do this?  Could it automagically 
break a complex operation into multiple steps? To enforce (match) the 
expected results of the MyHDL simulation.  I believe MyHDL (Python) has 
no limit on the intermediate value, the value isn't checked, verified 
till the assignment.  This would have to be implemented or restricted.  
Designers would have to realize large intermediate bit value could exist.

I believe you would have to be careful here though.  You do not want 
complication or too much inference from the converter.  You would want a 
very simple rule for Verilog that could be implemented.  There are many 
scenarios where an intermediate result requires a larger bit-value.  
Basically anytime a complex operation (equation) has an increasing and 
decreasing component you can run into this simulation mismatch.  If we 
prevent the operations we would have to prevent all combinations of 
increasing and decreasing, such as:
  (a + b)  - c
  (a + b)  >> c
  (a * b)  - c
  (a * b)  >> c
  (a << b) - c
  (a << b) >> c
etc, etc.

Some of these may not make sense (rarely used) but they are all (BOMK) 
valid statements.  The verilog converter would have to restrict all of 
these or handle all of them.  I don't know which is the best answer, yet.

Re: [myhdl-list] arithmetic trouble

[Neal B. <ndb...@gm...>]

Jan Decaluwe wrote:

> Christopher Felton wrote:
>> 
>> 
>>     It works correctly if I break into 2 steps, where I use a tmp
>>     variable of
>>     _the correct bit width_ before shifting.
>> 
>>     Is this a common issue with verilog simulators, or is mine just
>>     broken?
>> 
>>     Should my_hdl try to workaround this?
>> 
>> 
>> 
>> I don't recall the exact rules off the top of my head, either.  But I
>> think this is correct.  The language doesn't presume to know what the
>> intermediate bit representation of the operator is (Verilog language).
>>  If you want full precision for the multiply you have to do it in two
>> steps as you indicated or have your output be the full range.
>> 
>> BOMK everything is working correctly.  What you notice is a simulation
>> mismatch?  The MyHDL simulates fine because the * uses full precision
>> (infinite bits) and the bounds are not checked until the left hand side
>> is assigned and that is after the shift.   Hmmmm, don't know if this
>> would be a bug or not.  Not all aspects are convertible and this would
>> fit that scenario.
> 
> My rule is crystal-clear: if MyHDL code simulates fine and converts fine,
> simulations should match. Otherwise, there is a bug - either in the
> convertor or in the HDL simulator. For this it is not relevant whether
> MyHDL does the "right" thing or not.
> 
> So it looks like we have a bug here and now we have to find out
> what it is. Of course, it may be that something cannot be reliably
> converted, in which case the convertor should issue an error.
> 
> Jan
> 

I suppose (not tested) that using systemverilog cast on the operands before 
the operation to cast to the wider result type would fix it?

Re: [myhdl-list] intbv return types and a fixed-point Object

[Felton C. <chr...@gm...>]

>>
>
> No, I think it would be straighforward. I expect that everything that
> works now would continue working, except that you could do some
> additional things. In particular, you could index and slice an
> arithmetic expression.
>
> The only price would be simulation performance hit. The question is
> whether this is worthwhile for a feature that is seldom (?) used.
> Someone would have to analyze this in detail to make a good
> decision. Perhaps the performance hit is irrelevant - I don't know.
>
> Jan
>


I took some time to profile this change.  I used the python built-in  
cProfile.   Below are some numbers (warning lots of stuff below).  The  
results are a little interesting.  The total time for the math ops  
(__add__) effectively doubled.  But the overall simulation time  
increased slightly.  From this limited test case (more needs to be  
done) I would conclude that having the intbv math ops return and intbv  
type is little effect on overall simulation performance.

The change was to the _intbv.py.  All math operations were changed to  
return a intbv type versus an int type.

This also suggests that a fair amount of simulation time is spent on  
other areas.  If these other areas are ever change to be more  
efficient this change could have more effect on overall performance.

Intbv Math returns Int Type
--------------Start Test Loop--------------
--------------End Test Loop----------------
10935715 function calls (10900641 primitive calls) in 26.753 CPU seconds

    Ordered by: standard name

    ncalls  tottime  percall  cumtime  percall filename:lineno(function)
         1    0.000    0.000   26.753   26.753 <string>:1(<module>)
        10    0.000    0.000    0.000    0.000 _Signal.py:155(_clear)
    351088    2.770    0.000    4.089    0.000 _Signal.py:162(_update)
    351088    1.268    0.000   14.802    0.000 _Signal.py:191(_set_next)
     35070    0.036    0.000    0.036    0.000 _Signal.py: 
204(_get_negedge)
     70250    0.107    0.000    0.107    0.000 _Signal.py: 
235(_setNextBool)
    280838    2.165    0.000   12.916    0.000 _Signal.py: 
245(_setNextIntbv)
    140496    0.157    0.000    0.157    0.000 _Signal.py: 
282(__nonzero__)
     69447    0.270    0.000    0.463    0.000 _Signal.py:300(__add__)
     70148    0.296    0.000    0.466    0.000 _Signal.py:308(__sub__)
     35074    0.166    0.000    0.264    0.000 _Signal.py:316(__mul__)
     35074    0.118    0.000    0.172    0.000 _Signal.py:420(__int__)
     35074    0.072    0.000    0.271    0.000 _Signal.py:437(__cmp__)
         1    0.000    0.000    0.000    0.000 _Simulation.py: 
72(_finalize)
         1    2.196    2.196   26.753   26.753 _Simulation.py:92(run)
     70249    0.295    0.000    1.320    0.000 _Waiter.py:123(next)
     70250    0.247    0.000   15.794    0.000 _Waiter.py:136(next)
     35073    0.338    0.000    2.967    0.000 _Waiter.py:51(next)
    140499    0.270    0.000   16.513    0.000 _always.py:98(genfunc)
         2    0.000    0.000    0.000    0.000 _delay.py:29(__init__)
    563219    0.421    0.000    0.421    0.000 _intbv.py: 
105(__nonzero__)
     69447    0.110    0.000    0.149    0.000 _intbv.py:187(__add__)
     70148    0.114    0.000    0.140    0.000 _intbv.py:195(__sub__)
     35074    0.071    0.000    0.083    0.000 _intbv.py:203(__mul__)
    279149    1.902    0.000    3.267    0.000 _intbv.py:36(__init__)
     35074    0.054    0.000    0.054    0.000 _intbv.py:406(__int__)
    315912    0.671    0.000    0.981    0.000 _intbv.py:424(__cmp__)
    559987    1.387    0.000    1.387    0.000 _intbv.py: 
76(_checkBounds)
    279149    0.584    0.000    3.851    0.000 _intbv.py: 
95(__deepcopy__)



Intbv Math returns Intbv Type
--------------Start Test Loop--------------
--------------End Test Loop----------------
11460400 function calls (11425326 primitive calls) in 28.543 CPU seconds

    Ordered by: standard name

    ncalls  tottime  percall  cumtime  percall filename:lineno(function)
         1    0.000    0.000   28.543   28.543 <string>:1(<module>)
        10    0.000    0.000    0.000    0.000 _Signal.py:155(_clear)
    351088    2.758    0.000    4.080    0.000 _Signal.py:162(_update)
    351088    1.286    0.000   14.785    0.000 _Signal.py:191(_set_next)
     35070    0.034    0.000    0.034    0.000 _Signal.py: 
204(_get_negedge)
     70250    0.114    0.000    0.114    0.000 _Signal.py: 
235(_setNextBool)
    280838    2.050    0.000   12.881    0.000 _Signal.py: 
245(_setNextIntbv)
    140496    0.169    0.000    0.169    0.000 _Signal.py: 
282(__nonzero__)
     69447    0.269    0.000    0.984    0.000 _Signal.py:300(__add__)
     70148    0.296    0.000    0.983    0.000 _Signal.py:308(__sub__)
     35074    0.159    0.000    0.530    0.000 _Signal.py:316(__mul__)
     35074    0.117    0.000    0.175    0.000 _Signal.py:420(__int__)
     35074    0.070    0.000    0.281    0.000 _Signal.py:437(__cmp__)
         1    0.000    0.000    0.000    0.000 _Simulation.py: 
72(_finalize)
         1    2.175    2.175   28.543   28.543 _Simulation.py:92(run)
     70249    0.285    0.000    1.291    0.000 _Waiter.py:123(next)
     70250    0.258    0.000   17.623    0.000 _Waiter.py:136(next)
     35073    0.321    0.000    2.976    0.000 _Waiter.py:51(next)
    140499    0.248    0.000   18.311    0.000 _always.py:98(genfunc)
         2    0.000    0.000    0.000    0.000 _delay.py:29(__init__)
    563215    0.417    0.000    0.417    0.000 _intbv.py: 
105(__nonzero__)
     69447    0.231    0.000    0.672    0.000 _intbv.py:187(__add__)
     70148    0.229    0.000    0.657    0.000 _intbv.py:195(__sub__)
     35074    0.132    0.000    0.356    0.000 _intbv.py:203(__mul__)
     35074    0.115    0.000    0.343    0.000 _intbv.py:261(__rshift__)
    488891    2.733    0.000    4.493    0.000 _intbv.py:36(__init__)
     35074    0.057    0.000    0.057    0.000 _intbv.py:406(__int__)
    315912    0.674    0.000    0.992    0.000 _intbv.py:424(__cmp__)
    769729    1.710    0.000    1.710    0.000 _intbv.py: 
76(_checkBounds)
    279148    0.606    0.000    3.890    0.000 _intbv.py: 
95(__deepcopy__)


def mathSys1(clk, rst, x, y, N_BITS = 14):
     """
     """

     M0 = 2**(N_BITS-1)
     M1 = 2**(2*N_BITS-1)
     M2 = 2**(20*N_BITS-1)
     sine = Signal(intbv(0, min=-M0, max=M0))
     v1   = Signal(intbv(0, min=-M1, max=M1))
     v1d  = Signal(intbv(0, min=-M1, max=M1))
     v2   = Signal(intbv(0, min=-2*M1, max=2*M1))
     v3   = Signal(intbv(0, min=-M2, max=M2))

     i1 = sine_table(clk, rst, sine, N_BITS=N_BITS)

     @always(clk.posedge)
     def rtl():
         if rst:
             v1.next  = 0
             v1d.next = 0
             v2.next  = 0
             v3.next  = 0
         else:
             v1.next  = x * sine
             v2.next  = v1 - v1d
             v1d.next = v1
             v3.next  = (v3 + v2) >> N_BITS
             y.next   = v3 - v1
             #print '.... ', v1, v1d, v2, v3, y

     return i1, rtl