myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] migrating from myHDL-0.5.1 to myHDL_0.6

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

Sami Al Dalahmah wrote:

...

> By the way does anyone have
> good experience in Icarus (maybe it is somehow unrelated to myHDL but it can
> be useful)? I ran into the issue when you have a python script using the
> function "os.system(*command*)" to run Icarus for compiling and simulating
> then GTKwave for showing the wave diagram, sometimes when you have a syntax
> error python just do not realize this and continue the script. Do you if
> Icarus can return a value that can be tested for errors that can help my
> script? Actually I asked the same question in the Icarus Wiki and they
> pointed to a Perl test suite that I can learn from, this requires investing
> time to learn Perl then translate it to Python, which is an option I like to
> make one my last ones.
> 
> Sorry for the long email and thank you for your time reading it.
> 

I thought there was a discussion about that last year or so on the
Icarus mailing list, but the only post I found was this from 2007:

http://www.nabble.com/gEDA-dev:-Icarus-Verilog-return-codes--td8653647.html

However, if I understand you right then you want to know when the
simulation failed, which might not be covered by that return code.

As Newell mentioned in another post, one way to solve that is not to use
os.system() but for example os.popen() instead. There you can read the
output of the application and in the test bench you can write some text
that can be search for in the calling python script.

Cheers,

Guenter

Re: [myhdl-list] migrating from myHDL-0.5.1 to myHDL_0.6

[Newell J. <pil...@gm...>]

On Mon, Jan 26, 2009 at 3:07 PM, Sami Al Dalahmah
<sam...@gm...>wrote:

> Dear All,
>
> Thank you for your response, it is really helpful especially Gunter's
> approach. But for now I think I will go with the straight forward one
> suggested by Jan. And I assume I should install the new VPI file of the 0.6
> for the cosimulation instead of the old one in the simulator (Icarus in my
> case), right?
>
> I really like the analyze/verify features, because they save me the script
> used to compile ans simulate the Verilog code. By the way does anyone have
> good experience in Icarus (maybe it is somehow unrelated to myHDL but it can
> be useful)? I ran into the issue when you have a python script using the
> function "os.system(*command*)" to run Icarus for compiling and simulating
> then


Just remember that you are simply programming in Python.  Therefore, there
are other ways of calling the command above (whether or not this would be
the right thing to do or not will depend on what you doing).  Look at Popen
in the subprocess module that comes with Python.  You can do try-except
blocks as well etc.

>>> help(os.system)

This will show you that os.system will give you an exit status.

This is the beauty of MyHDL....its in Python!

-- 
Newell

http://www.gempillar.com
Before enlightenment: chop wood, carry water
After enlightenment: code, build circuits

Re: [myhdl-list] migrating from myHDL-0.5.1 to myHDL_0.6

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

Dear All,

Thank you for your response, it is really helpful especially Gunter's
approach. But for now I think I will go with the straight forward one
suggested by Jan. And I assume I should install the new VPI file of the 0.6
for the cosimulation instead of the old one in the simulator (Icarus in my
case), right?

I really like the analyze/verify features, because they save me the script
used to compile ans simulate the Verilog code. By the way does anyone have
good experience in Icarus (maybe it is somehow unrelated to myHDL but it can
be useful)? I ran into the issue when you have a python script using the
function "os.system(*command*)" to run Icarus for compiling and simulating
then GTKwave for showing the wave diagram, sometimes when you have a syntax
error python just do not realize this and continue the script. Do you if
Icarus can return a value that can be tested for errors that can help my
script? Actually I asked the same question in the Icarus Wiki and they
pointed to a Perl test suite that I can learn from, this requires investing
time to learn Perl then translate it to Python, which is an option I like to
make one my last ones.

Sorry for the long email and thank you for your time reading it.

On Mon, Jan 26, 2009 at 10:38 PM, Jan Decaluwe <ja...@ja...> wrote:

> Sami Al Dalahmah wrote:
> > Dear Jan,
> >
> > Thank you for your response. Maybe I should have been more precise, what
> > I should have said was "installation guide" . I have myHDL 0.5.1 with
> > python 2.5 on Ubuntu, if I want to have the new myHDL 0.6, should I
> > remove the 0.5.1 version or remove a specific files in the bin
> > directory?
>
> There are no bin files, myhdl is installed as a directory somewhere in
> your Python path.
>
> Personally, I always use 'python setup.py install', as for all my
> Python packages. Usually I don't even bother to remove the old
> installation, although I admit that would be cleaner. (Note that
> for this to go wrong, a package's behavior should depend on the
> existence of superfluous files, which is rather strange behaviour.)
>
> Jan
>
> --
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
>     Python as a hardware description language:
>     http://www.myhdl.org
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
Best Regards
Sami Aldalahmeh

Re: [myhdl-list] migrating from myHDL-0.5.1 to myHDL_0.6

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

Sami Al Dalahmah wrote:
> Dear Jan,
> 
> Thank you for your response. Maybe I should have been more precise, what 
> I should have said was "installation guide" . I have myHDL 0.5.1 with 
> python 2.5 on Ubuntu, if I want to have the new myHDL 0.6, should I 
> remove the 0.5.1 version or remove a specific files in the bin 
> directory? 

There are no bin files, myhdl is installed as a directory somewhere in
your Python path.

Personally, I always use 'python setup.py install', as for all my
Python packages. Usually I don't even bother to remove the old 
installation, although I admit that would be cleaner. (Note that
for this to go wrong, a package's behavior should depend on the
existence of superfluous files, which is rather strange behaviour.)

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a hardware description language:
     http://www.myhdl.org

Re: [myhdl-list] migrating from myHDL-0.5.1 to myHDL_0.6

[Brendan R. <bre...@gm...>]

Sami Al Dalahmah <sami.dalahmah <at> gmail.com> writes:

> 
> 
> Dear Jan,
> 
> Thank you for your response. Maybe I should have been more precise, what I
should have said was "installation guide" . I have myHDL 0.5.1 with python 2.5
on Ubuntu, if I want to have the new myHDL 0.6, should I remove the 0.5.1
version or remove a specific files in the bin directory? Thank you for your time
and a job well done in myHDL.

Hi Sami,

I have separate virtual Pythons for most every tool or combination of tools that
I need.  I use virtualenv to do this and recommend it highly.  Doug Hellmann
even has a nice wrapper, that I also use:

http://www.doughellmann.com/projects/virtualenvwrapper/

Cheers,

- Brendan

Re: [myhdl-list] migrating from myHDL-0.5.1 to myHDL_0.6

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

Sami Al Dalahmah wrote:
> Dear Jan,
> Thank you for your response. Maybe I should have been more precise, what I
> should have said was "installation guide" . I have myHDL 0.5.1 with python
> 2.5 on Ubuntu, if I want to have the new myHDL 0.6, should I remove the
> 0.5.1 version or remove a specific files in the bin directory? Thank you for
> your time and a job well done in myHDL.

Hi Sami,

The upgrade is Python standard procedure and it depends on how you
installed MyHDL in the first place. If you have a RPM package (assuming
there is one for Ubuntu) you can just run the update process and it will
replace the old files.

If you used the easy_install, there is an update feature.

http://peak.telecommunity.com/DevCenter/EasyInstall#upgrading-a-package

Now with the source installation (python setup.py install) I have to
admit I always did it the rough way, by removing the site-package/myhdl
folder and install the new package. I am not sure whether there is also
something like an update feature?

Cheers,

Guenter

Re: [myhdl-list] migrating from myHDL-0.5.1 to myHDL_0.6

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

Dear Jan,
Thank you for your response. Maybe I should have been more precise, what I
should have said was "installation guide" . I have myHDL 0.5.1 with python
2.5 on Ubuntu, if I want to have the new myHDL 0.6, should I remove the
0.5.1 version or remove a specific files in the bin directory? Thank you for
your time and a job well done in myHDL.

On Sun, Jan 25, 2009 at 9:53 PM, Jan Decaluwe <ja...@ja...> wrote:

> Sami Al Dalahmah wrote:
> > Dear All,
> >
> > I think there should be a guide for migrating from myHDL-0.5.1 to 0.6 in
> > linux and windows.
>
> The What's New document is supposed to document the new features:
>   http://www.myhdl.org/doc/0.6/whatsnew/0.6.html
>
> For migration, I think the most important section is the one on
> backwards incompatible changes:
>
>
> http://www.myhdl.org/doc/0.6/whatsnew/0.6.html#backwards-incompatible-changes
>
> > Further more the manual should contain examples on
> > the new features.
>
> The most important features are conversion to VHDL and enhancements
> to the convertor capabilities. Consequently, the chapter on conversion
> has been rewritten completely:
>
>     http://www.myhdl.org/doc/0.6/manual/conversion.html
>
> Moreover, there is a new chapter dedicated to conversion examples,
> both in Verilog and in VHDL:
>
>     http://www.myhdl.org/doc/0.6/manual/conversion.html
>
> In the future, more in-depth examples, e.g. about test bench
> conversion, will be added to the on-line Cookbook.
>
> Regards,
>
> Jan
>
> --
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
>     Python as a hardware description language:
>     http://www.myhdl.org
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
Best Regards
Sami Aldalahmeh

Re: [myhdl-list] migrating from myHDL-0.5.1 to myHDL_0.6

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

Sami Al Dalahmah wrote:
> Dear All,
> 
> I think there should be a guide for migrating from myHDL-0.5.1 to 0.6 in 
> linux and windows. 

The What's New document is supposed to document the new features:
   http://www.myhdl.org/doc/0.6/whatsnew/0.6.html

For migration, I think the most important section is the one on
backwards incompatible changes:

http://www.myhdl.org/doc/0.6/whatsnew/0.6.html#backwards-incompatible-changes

> Further more the manual should contain examples on 
> the new features.

The most important features are conversion to VHDL and enhancements
to the convertor capabilities. Consequently, the chapter on conversion
has been rewritten completely:

     http://www.myhdl.org/doc/0.6/manual/conversion.html

Moreover, there is a new chapter dedicated to conversion examples,
both in Verilog and in VHDL:

     http://www.myhdl.org/doc/0.6/manual/conversion.html

In the future, more in-depth examples, e.g. about test bench
conversion, will be added to the on-line Cookbook.

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a hardware description language:
     http://www.myhdl.org

[myhdl-list] migrating from myHDL-0.5.1 to myHDL_0.6

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

Dear All,
I think there should be a guide for migrating from myHDL-0.5.1 to 0.6 in
linux and windows. Further more the manual should contain examples on the
new features.

-- 
Best Regards
Sami Aldalahmeh

Re: [myhdl-list] Conversion of Signal(intbv(False))

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

Felton Christopher wrote:
>>>
>>> This can be worked around by adding bit width, Signal(intbv(False)
>>> [1:]).  But if this is done the code (or at least the example below)
>>> doesn't work, because the intbv type insn't a bool anymore.  Once the
>>> bit width is added it becomes an integer and the conditions will fail
>>> for a non-bool type.
>> What exactly doesn't work about that? Conversion seems to work fine,
>> and I don't immediately see what would be wrong with the Verilog or  
>> VHDL
>> code.
>>
>> Also, before going into the depth of the matter, what's against
>> simply using Signal(False) for the boolean signals?
>>
> 
> Sorry this is my error, I  was thinking only type intbv was  
> convertible and didn't cross my mind to use Signal(bool).  Quick look  
> through the manual and some past work didn't remind my brain.

Right, perhaps it is useful to post the documentation link for
others reading this:

   http://www.myhdl.org/doc/0.6/manual/conversion.html#supported-types

Even though intbv is the "workhorse" and does many of the things for
which you need a number of different types in other HDLs, it is
not the only type you can and should use.

bool and enum both have its uses and make things more explicit:
bool for boolean (and therefore single-bit) variables, enum
for state variables as in VHDL.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a hardware description language:
     http://www.myhdl.org

Re: [myhdl-list] Conversion of Signal(intbv(False))

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

>>
>>
>> This can be worked around by adding bit width, Signal(intbv(False)
>> [1:]).  But if this is done the code (or at least the example below)
>> doesn't work, because the intbv type insn't a bool anymore.  Once the
>> bit width is added it becomes an integer and the conditions will fail
>> for a non-bool type.
>
> What exactly doesn't work about that? Conversion seems to work fine,
> and I don't immediately see what would be wrong with the Verilog or  
> VHDL
> code.
>
> Also, before going into the depth of the matter, what's against
> simply using Signal(False) for the boolean signals?
>

Sorry this is my error, I  was thinking only type intbv was  
convertible and didn't cross my mind to use Signal(bool).  Quick look  
through the manual and some past work didn't remind my brain.

You are absolutely correct, in my case I should be using Signal(bool)  
and the intbv(bool) that I posted about is not relevant.

Thanks for the help as always!

Re: [myhdl-list] Conversion of Signal(intbv(False))

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

Christopher L. Felton wrote:
> Is it expected behavior that a Signal(intbv(<bool>)) is not converted?
> 
> Error recieved:
> Jan_17_2009 cfelton$ python no_bool.py
> Traceback (most recent call last):
>   File "no_bool.py", line 32, in <module>
>     convert()
>   File "no_bool.py", line 28, in convert
>     toVerilog(no_bool,clk,rst,a,b,sel,c)
>   File "/Library/Python/2.5/site-packages/myhdl/conversion/ 
> _toVerilog.py", line 111, in __call__
>     siglist, memlist = _analyzeSigs(h.hierarchy)
>   File "/Library/Python/2.5/site-packages/myhdl/conversion/ 
> _analyze.py", line 95, in _analyzeSigs
>     raise ConversionError(_error.UndefinedBitWidth, s._name)
> myhdl.ConversionError: Signal has undefined bit width: a
> 
> 
> This can be worked around by adding bit width, Signal(intbv(False) 
> [1:]).  But if this is done the code (or at least the example below)  
> doesn't work, because the intbv type insn't a bool anymore.  Once the  
> bit width is added it becomes an integer and the conditions will fail  
> for a non-bool type.

What exactly doesn't work about that? Conversion seems to work fine,
and I don't immediately see what would be wrong with the Verilog or VHDL
code.

Also, before going into the depth of the matter, what's against
simply using Signal(False) for the boolean signals?



> 
> 
> from myhdl import *
> 
> def no_bool(clk, rst, a, b, sel, c):
>     """
>     Boolean intbv not supported?
>     """
>     @always(clk.posedge or rst.posedge)
>     def rtl():
>         if sel:
>             c.next = b
>         else:
>             c.next = a
> 
>     return rtl
> 
> def convert():
>     clk = Signal(intbv(False))
>     rst = Signal(intbv(False))
>     a   = Signal(intbv(False))
>     b   = Signal(intbv(False))
>     sel = Signal(intbv(False))
>     c   = Signal(intbv(False))
> 
>     toVerilog(no_bool,clk,rst,a,b,sel,c)
>     toVHDL(no_bool,clk,rst,a,b,sel,c)
> 
> if __name__ == '__main__':
>     convert()
> 
> 
> 
> Thanks
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     From Python to silicon:
     http://www.myhdl.org

[myhdl-list] Conversion of Signal(intbv(False))

[Christopher L. F. <cf...@uc...>]

Is it expected behavior that a Signal(intbv(<bool>)) is not converted?

Error recieved:
Jan_17_2009 cfelton$ python no_bool.py
Traceback (most recent call last):
  File "no_bool.py", line 32, in <module>
    convert()
  File "no_bool.py", line 28, in convert
    toVerilog(no_bool,clk,rst,a,b,sel,c)
  File "/Library/Python/2.5/site-packages/myhdl/conversion/ 
_toVerilog.py", line 111, in __call__
    siglist, memlist = _analyzeSigs(h.hierarchy)
  File "/Library/Python/2.5/site-packages/myhdl/conversion/ 
_analyze.py", line 95, in _analyzeSigs
    raise ConversionError(_error.UndefinedBitWidth, s._name)
myhdl.ConversionError: Signal has undefined bit width: a


This can be worked around by adding bit width, Signal(intbv(False) 
[1:]).  But if this is done the code (or at least the example below)  
doesn't work, because the intbv type insn't a bool anymore.  Once the  
bit width is added it becomes an integer and the conditions will fail  
for a non-bool type.


from myhdl import *

def no_bool(clk, rst, a, b, sel, c):
    """
    Boolean intbv not supported?
    """
    @always(clk.posedge or rst.posedge)
    def rtl():
        if sel:
            c.next = b
        else:
            c.next = a

    return rtl

def convert():
    clk = Signal(intbv(False))
    rst = Signal(intbv(False))
    a   = Signal(intbv(False))
    b   = Signal(intbv(False))
    sel = Signal(intbv(False))
    c   = Signal(intbv(False))

    toVerilog(no_bool,clk,rst,a,b,sel,c)
    toVHDL(no_bool,clk,rst,a,b,sel,c)

if __name__ == '__main__':
    convert()



Thanks

[myhdl-list] Archlinux package for MyHDL uploaded to AUR

[Jian L. <jia...@go...>]

Hi all,

I've made a packge of myhdl-0.6 for archlinux. You can find it at 
http://aur.archlinux.org/packages.php?ID=23075

Feel free to leave comments. And if you like it, vote for it.
Hopefully, we can push myhdl into archlinux community repo someday soon.:)

Best

Jian

[myhdl-list] [ANNOUNCE] MyHDL 0.6 released

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

I'm happy to announce the release of MyHDL 0.6.

MyHDL is a Python package for using Python as a hardware
description language.

The highlight of this release is conversion to VHDL, in
addition to the existing Verilog capability. Furthermore,
the convertible subset has been broadened substantially
beyond synthesizable logic, to support test bench conversion.

For a complete overview, see:
    http://www.myhdl.org/doku.php/overview

To check whether MyHDL can be useful to you, please read:
    http://www.myhdl.org/doku.php/why

To find out the details of what's new in this release:
    http://www.myhdl.org/doc/0.6/whatsnew/0.6.html

You can download the release from SourceForge:
    http://sourceforge.net/project/showfiles.php?group_id=91207

Best regards,

Jan Decaluwe

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a hardware description language:
     http://www.myhdl.org

Re: [myhdl-list] code generation compatibility with old Verilog/VHDL

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

Andrew Stone wrote:
> Thanks, for your reply, Jan!
> 
> I think that there may be a bug in the intbv bounds checking logic.
> Maybe because Python is a little too clever when you do two's
> complement by hand?
>>>> print (~5)+1
> -5
> 
> So I can't really do two's complement by hand to create negative
> numbers... see inline for more details. 

That may be right. Bit inversion on constrained intbv's works
differently though - if min>0, it will return positive numbers.
But even then, thinking about it, it may be much more complicated
than in Verilog to emulate signed behavior with only "unsigned"
intbv's. MyHDL strictly checks bounds, Verilog typically just
does operations compatible with 2's complement arithmetic, even
with only positive numbers.

 > also, I've included a couple
> of the syntax errors that I'm getting in the verilog and vhdl
> compilation.  But I'd like to emphasize that if the problems are
> caused by the fact that my synthesis tool is old (2002) then pls don't
> fix just on my account! :-)  Instead let's think about whether
> compatibility with old systems is a priority for myHdl.  It may very
> well be.  For example Linux has a pretty thriving community of people
> putting it on old junker computers...

Very old and limited tools indeed seem to be the culprit, see further.
I would hesitiate very much to include this in the main MyHDL code
(why support abondoned tools?). However, it seems easy to fix your
issues locally by a few patches. (You could do this in a local
mercurial clone that still tracks future development.)


> Specific responses below:
> 
> Thanks for your help,
> Andrew



> The synthesis tool does not like the comma in @(reset,clk).  But it
> works if I use "or":

Verilog-2001.


>> There's no escape: you have to understand what Verilog/VHDL your
>> synthesis tool understands.
> 
> I hope this will not always be true -- for example most C programmers
> would be hard pressed to understand the generated assembly code.

Note that I wasn't talking about the synthesis tool output - that's
another subject. I was talking about the *input*.

I'm pretty sure it will stay like that for the following reason. It
would actually be pretty simple to design a HDL that could be
synthesized "completely". There have in fact be many attempts.
In fact people are still trying.

But all attempts have failed, and that should tell us something.
It tells us that such languages are too simple for serious
modelling and test benches. The kind of HDL that people want
is one that is very powerful for modeling/simulation in the first
place. Synthesis is just one thing that people want to do
with some of the models, and it naturally much more limited.
Note that software doesn't have this simulation / synthesis duality.

There is a reason why Verilog and VHDL are winners instead of the
myriad of implementation-centric attempts. MyHDL is happy to be
in the same camp.

> 
> One other issue was that in the generated code pck_myhdl_06dev10 there's a line:
> 
> attribute enum_encoding: string;
> 
> This line causes the error:
> pck_myhdl_06dev10.vhd (line 11, col 29):  (E56) Expected OF, but got :

Standard VHDL ...
This is only needed if you use enum types in MyHDL source code.

> 
> Next, my generated code looks like this:
> 
> -- File: bresStepTest.vhd
> -- Generated by MyHDL 0.6dev10
> -- Date: Mon Dec 22 22:50:13 2008
> 
> library IEEE;
> use IEEE.std_logic_1164.all;
> use IEEE.numeric_std.all;
> --use std.textio.all;
> 
> use work.pck_myhdl_06dev10.all;
> 
> entity bresStepTest is
>     port (
>         clk: in std_logic;
>         reset: in std_logic;
>         osc: in std_logic;
>         oscCount: inout unsigned(31 downto 0);
>         coils: inout unsigned(3 downto 0);
>         stepType: in std_logic
>     );
> end entity bresStepTest;
> 
> architecture MyHDL of bresStepTest is
> 
> signal nextPos: signed (31 downto 0);
> signal nextTime: signed (31 downto 0);
> signal loaded: std_logic;
> signal testTime: signed (31 downto 0);
> signal bresCircuit_timeLeft: signed (31 downto 0);
> signal bresCircuit_deltaTime: signed (31 downto 0);
> signal bresCircuit_deltaPos: signed (31 downto 0);
> signal bresCircuit_cPos: signed (31 downto 0);
> signal bresCircuit_curCtr: signed (31 downto 0);
> 
> begin
> 
> 
> BRESSTEPTEST_DRIVEMOTORCMDS: process (clk) is
> begin
> 
> And I get an error:
> main.vhd (line 38, col 46):  (E10) Syntax error at/before reserved symbol 'is'.


Consistent support for "is" keyword was introduced in VHDL-93.

Jan


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a hardware description language:
     http://www.myhdl.org

Re: [myhdl-list] convertion of Conditional Expressions in python2.5 and up

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

Jian LUO wrote:
> Hi Jan,
> 
> I've made a patch for conversion of  Conditional Expressions, e.g:
>     x = true_value if condition else false_value
> which is new in python 2.5 (not quite new as 3.0 is out :) )
> 
> This kind of expressions are widely used in both verilog and vhdl.
> I think it's worth to convert it as well, so I made the patch.(see
> attachment)
> 
> And don't worry about the python2.4. Conditional expression will not
> pass the syntax check in python 2.4 before it fails. So there is no lose
> at all.

Thanks, good to see that someone can make sense of the conversion
source code :-)

I'm going to push this to MyHDL 0.7. There are a few other syntactic sugar
features that will be added in that version, and Python 2.5 can be
made a requirement. Also, a unit test has to be added.

In the future, may I suggest to use mercurial to make patches? The
whole process is described here:

     http://www.myhdl.org/doku.php/dev:patches

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     From Python to silicon:
     http://www.myhdl.org

Re: [myhdl-list] [bug] typo in _toVHDL.py

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

Jian LUO wrote:
> Hi Jan,
> 
> in _ConvertFunctionVisitor.writeInputDeclarations
> enchar = ";" should be endchar = ";"

Thanks, I have added a unit test that exposes this
issue, and solved it in the public repo.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     From Python to silicon:
     http://www.myhdl.org

[myhdl-list] [bug] typo in _toVHDL.py

[Jian L. <jia...@go...>]

Hi Jan,

in _ConvertFunctionVisitor.writeInputDeclarations
enchar = ";" should be endchar = ";"


Gruss

Jian

[myhdl-list] convertion of Conditional Expressions in python2.5 and up

[Jian L. <jia...@go...>]

Hi Jan,

I've made a patch for conversion of  Conditional Expressions, e.g:
     x = true_value if condition else false_value
which is new in python 2.5 (not quite new as 3.0 is out :) )

This kind of expressions are widely used in both verilog and vhdl.
I think it's worth to convert it as well, so I made the patch.(see
attachment)

And don't worry about the python2.4. Conditional expression will not
pass the syntax check in python 2.4 before it fails. So there is no lose
at all.

btw. Thanks and good job!  MyHDL is so sexy, that I plan to use it in my
next
project to write a synthesizable cpu.

Best

Jian

Re: [myhdl-list] code generation compatibility with old Verilog/VHDL

[Andrew S. <g.a...@gm...>]

Thanks, for your reply, Jan!

I think that there may be a bug in the intbv bounds checking logic.
Maybe because Python is a little too clever when you do two's
complement by hand?
>>> print (~5)+1
-5

So I can't really do two's complement by hand to create negative
numbers... see inline for more details.  Also, I've included a couple
of the syntax errors that I'm getting in the verilog and vhdl
compilation.  But I'd like to emphasize that if the problems are
caused by the fact that my synthesis tool is old (2002) then pls don't
fix just on my account! :-)  Instead let's think about whether
compatibility with old systems is a priority for myHdl.  It may very
well be.  For example Linux has a pretty thriving community of people
putting it on old junker computers...

Specific responses below:

Thanks for your help,
Andrew

On Tue, Dec 23, 2008 at 6:09 AM, Jan Decaluwe <ja...@ja...> wrote:
> G.A...@gm... wrote:
>> Hi myHdlers,
>>
>> I'm using an old cypress CPLD: CY37000 chip and so I'm using an old
>> synthesis tool: Warp 6.3 (2002). I'm seeing some compile errors in both
>> the generated Verilog and VHDL code and I'm assuming that they have to
>> do with using a very old synthesis tool.
>
> Probably, but not necessarily. MyHDL can convert much more than can
> reasonably be synthesized. For better info, you'd have to tell us
> more about the kind of compile errors you get.

Hmm, I don't think that its that kind of error.  For example the latch
code from the doc:

def latch(reset, d, q):
    @always_comb
    def logic():
        if reset == 0:
            q.next = d

    return logic

Instantiated like this:

latch_circuit = latch(reset,clk,latchout)

Gives this:

always @(reset, clk) begin: _hwtest_latch_circuit_logic
    if ((reset == 0)) begin
        latchout <= clk;
    end
end

The synthesis tool does not like the comma in @(reset,clk).  But it
works if I use "or":

always @(reset or clk) begin:


>
> There's no escape: you have to understand what Verilog/VHDL your
> synthesis tool understands.

I hope this will not always be true -- for example most C programmers
would be hard pressed to understand the generated assembly code.

>
> With MyHDL, there's an additional complication: you have to understand
> how get supported HDL code out of the convertor. With a little practice,
> this shouldn't be hard, as there is a pretty close mapping from
> the MyHDL input to the HDL output.

Yes, its great!  I'm not having much trouble reading the verilog output.

>
>> In the Verilog code, I was able to make small changes to get my design
>> to synthesize, until I hit a problem that Warp 6.3 does not support
>> signed regs... *sigh*. I'm guessing this is rare enough that no one is
>> interested in putting automatic generation of signed logic in the
>> myHdl->Verilog generator?
>
> Indeed. Your option here is to do what Verilog designers had to do for a
> very long time (until the language had signed): emulate signed behavior
> manually using unsigneds only.

I think that there may be a bug here...  It still triggers the
negative assertion in myhdl.

Specifically in myhdl:

cPos = Signal(intbv(0)[32:])
deltaPos = Signal(intbv(0)[32:])
nextPos = Signal(intbv(0)[32:])

sometime later:
print cPos
print nextPos
deltaPos.next = (~(cPos-nextPos))+1

output:

199
0
> /me/fpga/myhdlcode/varstep.py(51)step()
-> deltaPos.next = (~(cPos-nextPos))+1
(Pdb) c
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "varstep.py", line 150, in <module>
    simulate(10 * 1000)
  File "varstep.py", line 148, in simulate
    sim.run(timesteps)
  File "/me/fpga/myhdl/repo/myhdl/_Simulation.py", line 132, in run
    waiter.next(waiters, actives, exc)
  File "/me/fpga/myhdl/repo/myhdl/_Waiter.py", line 137, in next
    clause = self.generator.next()
  File "/me/fpga/myhdl/repo/myhdl/_always.py", line 105, in genfunc
    func()
  File "varstep.py", line 51, in step
    deltaPos.next = (~(cPos-nextPos))+1
  File "/me/fpga/myhdl/repo/myhdl/_Signal.py", line 194, in _set_next
    self._setNextVal(val)
  File "/me/fpga/myhdl/repo/myhdl/_Signal.py", line 253, in _setNextIntbv
    self._next._checkBounds()
  File "/me/fpga/myhdl/repo/myhdl/_intbv.py", line 85, in _checkBounds
    (self._val, self._min))
ValueError: intbv value -199 < minimum 0
>>>

>
>> So I noticed that Warp 6.3 does support signed logic in VHDL, so Great!
>> I can use the cool new 0.6 feature! Well...no. There are errors in the
>> VHDL synthesis also, and I don't know VHDL at all...
>>
>> Is there any interest in supporting old versions? Some of the problems
>> seem to be simple syntax changes, or optional libraries (for example, in
>> vhdl "use std.textio.all" (no textio library found).
>
> std.textio is actually only required for printing. I guess I could
> make the convertor more intelligent by only including it when needed.
> On the other hand, it's a standard package that any VHDL tool should
> know about.
>

One other issue was that in the generated code pck_myhdl_06dev10 there's a line:

attribute enum_encoding: string;

This line causes the error:
pck_myhdl_06dev10.vhd (line 11, col 29):  (E56) Expected OF, but got :

Next, my generated code looks like this:

-- File: bresStepTest.vhd
-- Generated by MyHDL 0.6dev10
-- Date: Mon Dec 22 22:50:13 2008

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
--use std.textio.all;

use work.pck_myhdl_06dev10.all;

entity bresStepTest is
    port (
        clk: in std_logic;
        reset: in std_logic;
        osc: in std_logic;
        oscCount: inout unsigned(31 downto 0);
        coils: inout unsigned(3 downto 0);
        stepType: in std_logic
    );
end entity bresStepTest;

architecture MyHDL of bresStepTest is

signal nextPos: signed (31 downto 0);
signal nextTime: signed (31 downto 0);
signal loaded: std_logic;
signal testTime: signed (31 downto 0);
signal bresCircuit_timeLeft: signed (31 downto 0);
signal bresCircuit_deltaTime: signed (31 downto 0);
signal bresCircuit_deltaPos: signed (31 downto 0);
signal bresCircuit_cPos: signed (31 downto 0);
signal bresCircuit_curCtr: signed (31 downto 0);

begin


BRESSTEPTEST_DRIVEMOTORCMDS: process (clk) is
begin

And I get an error:
main.vhd (line 38, col 46):  (E10) Syntax error at/before reserved symbol 'is'.

[myhdl-list] [patch] convertion of Conditional Expressions in python2.5 and up

[Jian L. <jia...@go...>]

Hi Jan,

I've made a patch for conversion of  Conditional Expressions, e.g:
    x = true_value if condition else false_value
which is new in python 2.5 (not quite new as 3.0 is out :) )

This kind of expressions are widely used in both verilog and vhdl.
I think it's worth to convert it as well, so I made the patch.(see 
attachment)

And don't worry about the python2.4. Conditional expression will not
pass the syntax check in python 2.4 before it fails. So there is no lose 
at all.

btw. Thanks and good job!  MyHDL is so sexy, that I plan to use it in my 
next
project to write a synthesizable cpu.

Best

Jian

Re: [myhdl-list] [new] design flow question

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

Newell Jensen wrote:

>     I recently used this technique to write a simple high-level
>     behavioral model for a memory structure with a very complicated
>     Verilog model.
> 
> Yeah, unfortunately I am not as keen on myhdl as you are (I mean, you 
> wrote it and all).  If I could do this for the CPU, bus, UART, and the 
> Verilog Wishbone wrapper that I need to make for my DDR2 SDRAM (Xilinx 
> Core Generator generated) I would be set.
> 
> However, I don't see that happening unless I knew what to do etc. and 
> unfortunately I don't.

At least I saved you some frustration up-front :-) No matter how keen I
may be on myhdl, it's more important to be honest and avoid frustration.
Using MyHDL without simulation will get you into trouble. To simulate,
you need models. At this point, MyHDL doesn't have a library like
opencores. It's that simple.

I suggest you use Verilog to tie things together and simulate at the
top level.

If you still want to experiment with MyHDL, do it bottom-up for some
module that you may have design and verify separately. After conversion,
you can then include into the Verilog top-level.

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     From Python to silicon:
     http://www.myhdl.org

Re: [myhdl-list] [new] design flow question

[Newell J. <pil...@gm...>]

On Tue, Dec 23, 2008 at 2:53 AM, Jan Decaluwe <ja...@ja...> wrote:

> Newell Jensen wrote:
> > I wanted to ask some questions that are similar to the ones that Neal
> > asked.  I am new to HDL design in general but love programming in
> > Python.  However, I think I will be using a bunch of the open source
> > cores that are on OpenCores.org.
> >
> > I would love to start using MyHDL on a regular basis but as of now I
> > don't really see how I can use MyHDL with all the OpenCores that I would
> > be using (I am new so if the answer is obvious than excuse me for my
> > ignorance...I am still learning).
> > It would really be nice if there was a way to wrap these cores for use
> > in MyHDL so that in the end I could have a Top Level MyHDL
> > implementation with embedded cores from OpenCores.
> >
> > Any ideas if this is possible?
>
> The trick is to include an instantiation of the core using user-defined
> code hooks. As Gunter suggests, you should find sufficient documentation
> on this.
>
> I'd just like to add a methodology note. It is always desirable to do
> simulation, not just using MyHDL as a convertor. Simulation will find
> problems that the convertor won't (and can't).
>
> Unfortunately, this means you still need a MyHDL model for such a core.
> However, note that when you use a user-defined code hook, the convertor
> stops converting at that point. So you can write a model at the highest
> level possible using all tricks in the Python book without being
> concerned about convertibility.
>

Some of the cores that I am using from OpenCores.org are a CPU....which I
would have no idea on how to do this.  I wish I did, but I am still new to
all this for the most part.


>
> I recently used this technique to write a simple high-level
> behavioral model for a memory structure with a very complicated
> Verilog model.


Yeah, unfortunately I am not as keen on myhdl as you are (I mean, you wrote
it and all).  If I could do this for the CPU, bus, UART, and the Verilog
Wishbone wrapper that I need to make for my DDR2 SDRAM (Xilinx Core
Generator generated) I would be set.

However, I don't see that happening unless I knew what to do etc. and
unfortunately I don't.

Thanks for all the suggestions to everyone though.


>
>
> Jan
>
> --
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
>      From Python to silicon:
>     http://www.myhdl.org
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
Newell

http://www.gempillar.com
Before enlightenment: chop wood, carry water
After enlightenment: code, build circuits

Re: [myhdl-list] code generation compatibility with old Verilog/VHDL

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

G.A...@gm... wrote:
> Hi myHdlers,
> 
> I'm using an old cypress CPLD: CY37000 chip and so I'm using an old 
> synthesis tool: Warp 6.3 (2002). I'm seeing some compile errors in both 
> the generated Verilog and VHDL code and I'm assuming that they have to 
> do with using a very old synthesis tool.

Probably, but not necessarily. MyHDL can convert much more than can
reasonably be synthesized. For better info, you'd have to tell us
more about the kind of compile errors you get.

There's no escape: you have to understand what Verilog/VHDL your
synthesis tool understands.

With MyHDL, there's an additional complication: you have to understand
how get supported HDL code out of the convertor. With a little practice,
this shouldn't be hard, as there is a pretty close mapping from
the MyHDL input to the HDL output.

> In the Verilog code, I was able to make small changes to get my design 
> to synthesize, until I hit a problem that Warp 6.3 does not support 
> signed regs... *sigh*. I'm guessing this is rare enough that no one is 
> interested in putting automatic generation of signed logic in the 
> myHdl->Verilog generator?

Indeed. Your option here is to do what Verilog designers had to do for a
very long time (until the language had signed): emulate signed behavior
manually using unsigneds only.

> So I noticed that Warp 6.3 does support signed logic in VHDL, so Great! 
> I can use the cool new 0.6 feature! Well...no. There are errors in the 
> VHDL synthesis also, and I don't know VHDL at all...
> 
> Is there any interest in supporting old versions? Some of the problems 
> seem to be simple syntax changes, or optional libraries (for example, in 
> vhdl "use std.textio.all" (no textio library found).

std.textio is actually only required for printing. I guess I could
make the convertor more intelligent by only including it when needed.
On the other hand, it's a standard package that any VHDL tool should
know about.

> BTW, As a quick "fix" it might be nice to put the language version in 
> the comment so that people know what the generated code is targeted to.

I guess you mean the Verilog or VHDL version? At this moment this is
just based on an estimated conservative common ground.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     From Python to silicon:
     http://www.myhdl.org