myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Reference models

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

On 11/15/2012 8:20 AM, David Blubaugh wrote:
> Jan,
> Wonderful article on cellular automata within MyHDL !!!
> I was wondering if it would be possible to create a supercomputer within an array of FPGAs by utilizing both MyHDL and CELLULAR AUTOMATA ???
> David Blubaugh
>
>
>

David,

If I read the post correctly, nothing has been implemented in MyHDL 
(yet).  Jan showed how Python can be used to create a reference model 
(a.k.a the golden model).  Hopefully, the take away is: the relative 
efficiency to create the reference model with Python and the *bonus* 
UI/visualization because batteries are included.

If you follow APP you will notice there are 3 version of the game of 
life (cellular automata) being implemented.  From what has been posted 
thus far, this is a noteworthy accomplishment by Jan.  Quantifiable 
progress towards an implementation.

In Jan's previous post he issued a similar challenge to create a 
reference for an arbitrary length gray code and he provided the Python 
example.  The challenge had mediocre responses, IIRC there was one VHDL 
submission and no Verilog submissions.

I have had limited participation because I am in the same boat as 
others, extremely busy!  The last 3-4 months I have had approaching zero 
time outside work and family.

The other GOL posts
GOL contender #1
http://www.programmableplanet.com/author.asp?section_id=2030&doc_id=247372

http://www.programmableplanet.com/author.asp?section_id=2030&doc_id=251373

http://www.programmableplanet.com/author.asp?section_id=2030&doc_id=253338

GOL contender #2
http://www.programmableplanet.com/author.asp?section_id=2551&doc_id=252453

http://www.programmableplanet.com/author.asp?section_id=2551&doc_id=252957


Jan's previous
http://www.programmableplanet.com/author.asp?section_id=2438&doc_id=252295

A philosophical point.  There is a definite difference (regardless of 
language and technologies) that Jan's approach is top-down and 
verification driven.  From what has been posted thus far, the others are 
building up to the final system(?).

Regards,
Chris

Re: [myhdl-list] Reference models

[David B. <dav...@ya...>]

Jan,
Wonderful article on cellular automata within MyHDL !!!
I was wondering if it would be possible to create a supercomputer within an array of FPGAs by utilizing both MyHDL and CELLULAR AUTOMATA ???
David Blubaugh



--- On Thu, 11/15/12, Jan Decaluwe <ja...@ja...> wrote:

From: Jan Decaluwe <ja...@ja...>
Subject: [myhdl-list] Reference models
To: myh...@li...
Date: Thursday, November 15, 2012, 4:03 AM

I have blogged on APP about the significance of reference models
and how Python helps, based on a "Real Life" example.

http://www.programmableplanet.com/author.asp?section_id=2438&doc_id=254265&


-- 
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
     World-class digital design: http://www.easics.com


------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

[myhdl-list] Reference models

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

I have blogged on APP about the significance of reference models
and how Python helps, based on a "Real Life" example.

http://www.programmableplanet.com/author.asp?section_id=2438&doc_id=254265&


-- 
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
     World-class digital design: http://www.easics.com

[myhdl-list] Design West

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

Hello:

CLive Maxfield from APP suggested to participate with
a paper about MyHDL/Python in the Design West conference,
in the "Processors and Programmable Devices" that he
chairs.

http://www.ubmdesign.com

Deadline for abstract submission is TODAY however :-)

I really don't have time - too many things on my plate,
moreover I can't justify the long trip without a concrete
business aspect to it.

But perhaps a MyHDL'er nearer to the conference is
interested? I think a MyHDL paper will be welcomed.

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
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Status update

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

On Wed, Nov 7, 2012 at 10:16 AM, Jan Decaluwe <ja...@ja...> wrote:
> Hello:
>
> I haven't been able to track all recent activity here for two reasons.
>
> First, in the past months I have been working intensively on a very
> interesting design project (also involving MyHDL).
>
> Second, I have not yet given up on APP :-) and I have given it
> a lot of attention.
>
> The project has been taped-out now. I'm preparing for a new one
> (also involving MyHDL) but there will be some time left to make
> progress on MyHDL itself. I will start by catching up with the
> posts here.
>
> Regarding APP, I not really happy with how it works out so far.
> Consider my last post:
>
> http://www.programmableplanet.com/author.asp?section_id=2438&doc_id=252295
>
> It think it makes a strong and clear case for Python, but from the
> response my feeling is people still just don't get it, or are
> not willing to get it. For example, I spent a lot of effort
> in the comment section, not show to why Python is good choice
> to write reference models, but why reference models are a
> good idea in the first place. And apparently I didn't succeed!
> It's just so tiresome at times.
>
> Anyway, I have an even stronger post ready, and we'll see.
>
> Jan

Hi Jan,

glad that you are back :-)

If you have time, could you review some of the patches that I sent to
the list a few weeks ago? I'd like to know if I was going on the right
direction with them.

As for your recent blog posts I found them excellent. However I think
you should try to make the case for how one would integrate MyHDL into
an existing "traditional" workflow, as we have been recently
discussing in this list. I think that the "how to get from here to
there" question may be what makes it harder for people to imagine how
MyHDL could be useful for them, as opposed to a nice concept.

Cheers,

Angel

[myhdl-list] Status update

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

Hello:

I haven't been able to track all recent activity here for two reasons.

First, in the past months I have been working intensively on a very
interesting design project (also involving MyHDL).

Second, I have not yet given up on APP :-) and I have given it
a lot of attention.

The project has been taped-out now. I'm preparing for a new one
(also involving MyHDL) but there will be some time left to make
progress on MyHDL itself. I will start by catching up with the
posts here.

Regarding APP, I not really happy with how it works out so far.
Consider my last post:

http://www.programmableplanet.com/author.asp?section_id=2438&doc_id=252295

It think it makes a strong and clear case for Python, but from the
response my feeling is people still just don't get it, or are
not willing to get it. For example, I spent a lot of effort
in the comment section, not show to why Python is good choice
to write reference models, but why reference models are a
good idea in the first place. And apparently I didn't succeed!
It's just so tiresome at times.

Anyway, I have an even stronger post ready, and we'll see.

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
     World-class digital design: http://www.easics.com

Re: [myhdl-list] Meaning of the apostrophe that MyHDL adds after VHDL casts when using "concat"

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

On Tue, Oct 16, 2012 at 12:49 PM, Martin Thompson
<mar...@tr...> wrote:
> Angel Ezquerra <ang...@gm...> writes:
>
>> ~~~
>>     s_output <= unsigned'(s_input3 & s_input3);
>> ~~~
>>
>> Which synthesizes fine and without warning.
>>
>> What does the apostrophe mean?
>>
>
> This came up on comp.lang.vhdl recently:
> https://groups.google.com/d/msg/comp.lang.vhdl/C5ZaMbKujGo/fpXyOSFb5gEJ
>
> Andy says it very well:
>
>> type_name'(expression) is called a qualified expression. It explicitly
>> tells the compiler that the expression IS of type type_name. This is
>> used, as in your example, when the result of a function/operation is
>> ambiguous. These are often confusing, since such an ambigous expression
>> will work if assigned directly to an object or associated with a port
>> (which always has a defined type). Ambiguous expressions often involve
>> literal expressions like (7 downto 0 => '0'), in contexts where there
>> are multiple available types that fit the literal expression. No type
>> conversion is involved in a qualified expression.
>>
>> type_name(expression) is a built-in type conversion function that
>> automatically exists between closely related types (aggregates whose
>> elements are of the same base type). This is as close to a "cast" as
>> vhdl gets.
>>
>> conversion_function_name(expression) is an explicit type conversion
>> function that has to be written and compiled, and can convert between
>> any two types.
>
> Cheers,
> Martin

Awesome, thanks a lot Martin!

I am surprised I haven't seen this mentioned on the VHDL manuals and
tutorials that I've read. Probably I just missed it because it is also
quite difficult to search for it (google ignores apostrophes even if
you put double quotes round them)

Thanks,

Angel

Re: [myhdl-list] Meaning of the apostrophe that MyHDL adds after VHDL casts when using "concat"

[Martin T. <mar...@tr...>]

Angel Ezquerra <ang...@gm...> writes:

> ~~~
>     s_output <= unsigned'(s_input3 & s_input3);
> ~~~
>
> Which synthesizes fine and without warning.
>
> What does the apostrophe mean?
>

This came up on comp.lang.vhdl recently:
https://groups.google.com/d/msg/comp.lang.vhdl/C5ZaMbKujGo/fpXyOSFb5gEJ

Andy says it very well:

> type_name'(expression) is called a qualified expression. It explicitly
> tells the compiler that the expression IS of type type_name. This is
> used, as in your example, when the result of a function/operation is
> ambiguous. These are often confusing, since such an ambigous expression
> will work if assigned directly to an object or associated with a port
> (which always has a defined type). Ambiguous expressions often involve
> literal expressions like (7 downto 0 => '0'), in contexts where there
> are multiple available types that fit the literal expression. No type
> conversion is involved in a qualified expression.
> 
> type_name(expression) is a built-in type conversion function that
> automatically exists between closely related types (aggregates whose
> elements are of the same base type). This is as close to a "cast" as
> vhdl gets.
> 
> conversion_function_name(expression) is an explicit type conversion
> function that has to be written and compiled, and can convert between
> any two types.

Cheers,
Martin

-- 
mar...@tr... 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

[myhdl-list] Meaning of the apostrophe that MyHDL adds after VHDL casts when using "concat"

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

Hi,

this may be a very basic VHDL question but is something I have never
seen before.

Looking at the VHDL code that MyHDL generates I noticed that when
using "concat" MyHDL adds an apostrophe (') between the casting
functions (e.g. unsigned or signed) and the parenthesis that contain
the actual signal concatenation.

For example, given two variables defined as follows in MyHDL:

~~~
    s_input = Signal(intbv(0)[16:])
    s_output = Signal(intbv(0)[32:])
~~~

The following MyHDL code, when placed on an @always block:

~~~
    s_output.next = concat(s_input, s_input)
~~~

becomes the following VHDL:

~~~
    s_output <= unsigned'(s_input3 & s_input3);
~~~

Which synthesizes fine and without warning.

What does the apostrophe mean?

Thanks!

Angel

Re: [myhdl-list] [PATCH 1 of 2 V3] intbv: add support for negative indexes and slice limits

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

Thank you for looking into this, Benoit,

I think this feature is interesting to be consistent with how regular
Python lists work. This is something that I expected to work out of
the box and I was surprised when it didn't. I also think it highlights
how working with a higher language such as Python can make it possible
to do things which are very hard or tedious using a lower level
language such as VHDL.

I hope Jan can comment on whether he thinks this is a good idea or
not. In any case it was a good opportunity for me to look at the
conversion code.

Regarding the tests, I did run the non conversion tests and they did
work fine. I agree that I should add some tests. I can add regular,
non-conversion tests for the first patch in the series, but adding the
conversion tests would be harder since I cannot run them! :-(

As for your comments regarding the code I agree that the error message
should be improved. I had it on my TODO but I forgot about it.

Once I get more feedback I'll change that along with any other issue
that my arise.

I think this feature should be added to Verilog as well, but I have no
experience with Verilog...

Cheers,

Angel


On Mon, Oct 15, 2012 at 12:17 PM, Ben <ben...@gm...> wrote:
> Hi Angel,
>
> Other than a preliminary discussion on the topic, and about why this
> feature is interesting, this patch should also greatly benefit from
> tests.
>
> While I wasn't able to get the conversion tests running on my system
> either (vlog, vcom, ... missing), the "core" one do work fine (once
> you installed pytest, and set the PYTHONPATH in the Makefiles). Could
> you look at this ?
>
> Stylistic remark inlined.
>
> Regards,
> Benoît.
>
> On Sun, Oct 14, 2012 at 12:54 AM, Angel Ezquerra
> <ang...@gm...> wrote:
>> # HG changeset patch
>> # User Angel Ezquerra <ang...@gm...>
>> # Date 1350077846 -7200
>> # Branch 0.8-dev
>> # Node ID c641c1ed333d6d03d9cee4a63df5111fe98574c8
>> # Parent  6f6571dbd495f197531f0406763ff10e4ce3b3ee
>> intbv: add support for negative indexes and slice limits
>>
>> Negative indexes are supported on regular python lists. They are very useful
>> when you want to refer to a position from the end of the list. This same concept
>> can be applied to intbv indexes and slices. Supporting negative indexes reduces
>> the need to use the len() function to calculate a position from the MSB of the
>> intbv.
>>
>> Note that converting negative indexes is not supported yet.
>>
>> diff --git a/myhdl/_intbv.py b/myhdl/_intbv.py
>> --- a/myhdl/_intbv.py
>> +++ b/myhdl/_intbv.py
>> @@ -127,11 +127,15 @@
>>                  j = 0
>>              j = int(j)
>>              if j < 0:
>> -                raise ValueError, "intbv[i:j] requires j >= 0\n" \
>> -                      "            j == %s" % j
>> +                j = self._nrbits + j
>> +                if j < 0:
>> +                    raise ValueError, "intbv[i:j] requires j >= 0\n" \
>> +                        "            j == %s" % j
>
> The extra indent is not needed over there, and the error message could
> benefit from clarification.
>
>>              if i is None: # default
>>                  return type(self)(self._val >> j)
>>              i = int(i)
>> +            if i < 0:
>> +                i = self._nrbits + i
>>              if i <= j:
>>                  raise ValueError, "intbv[i:j] requires i > j\n" \
>>                        "            i, j == %s, %s" % (i, j)
>> @@ -139,6 +143,8 @@
>>              return res
>>          else:
>>              i = int(key)
>> +            if i < 0:
>> +                i = self._nrbits + i
>>              res = bool((self._val >> i) & 0x1)
>>              return res
>>
>> @@ -153,14 +159,18 @@
>>                  j = 0
>>              j = int(j)
>>              if j < 0:
>> -                raise ValueError, "intbv[i:j] = v requires j >= 0\n" \
>> -                      "            j == %s" % j
>> +                j = self._nrbits + j
>> +                if j < 0:
>> +                    raise ValueError, "intbv[i:j] = v requires j >= 0\n" \
>> +                        "            j == %s" % j
>>              if i is None: # default
>>                  q = self._val % (1L << j)
>>                  self._val = val * (1L << j) + q
>>                  self._handleBounds()
>>                  return
>>              i = int(i)
>> +            if i < 0:
>> +                i = self._nrbits + i
>>              if i <= j:
>>                  raise ValueError, "intbv[i:j] = v requires i > j\n" \
>>                        "            i, j, v == %s, %s, %s" % (i, j, val)
>> @@ -174,6 +184,8 @@
>>              self._handleBounds()
>>          else:
>>              i = int(key)
>> +            if i < 0:
>> +                i = self._nrbits + i
>>              if val == 1:
>>                  self._val |= (1L << i)
>>              elif val == 0:
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] [PATCH 1 of 2 V3] intbv: add support for negative indexes and slice limits

[Ben <ben...@gm...>]

Hi Angel,

Other than a preliminary discussion on the topic, and about why this
feature is interesting, this patch should also greatly benefit from
tests.

While I wasn't able to get the conversion tests running on my system
either (vlog, vcom, ... missing), the "core" one do work fine (once
you installed pytest, and set the PYTHONPATH in the Makefiles). Could
you look at this ?

Stylistic remark inlined.

Regards,
Benoît.

On Sun, Oct 14, 2012 at 12:54 AM, Angel Ezquerra
<ang...@gm...> wrote:
> # HG changeset patch
> # User Angel Ezquerra <ang...@gm...>
> # Date 1350077846 -7200
> # Branch 0.8-dev
> # Node ID c641c1ed333d6d03d9cee4a63df5111fe98574c8
> # Parent  6f6571dbd495f197531f0406763ff10e4ce3b3ee
> intbv: add support for negative indexes and slice limits
>
> Negative indexes are supported on regular python lists. They are very useful
> when you want to refer to a position from the end of the list. This same concept
> can be applied to intbv indexes and slices. Supporting negative indexes reduces
> the need to use the len() function to calculate a position from the MSB of the
> intbv.
>
> Note that converting negative indexes is not supported yet.
>
> diff --git a/myhdl/_intbv.py b/myhdl/_intbv.py
> --- a/myhdl/_intbv.py
> +++ b/myhdl/_intbv.py
> @@ -127,11 +127,15 @@
>                  j = 0
>              j = int(j)
>              if j < 0:
> -                raise ValueError, "intbv[i:j] requires j >= 0\n" \
> -                      "            j == %s" % j
> +                j = self._nrbits + j
> +                if j < 0:
> +                    raise ValueError, "intbv[i:j] requires j >= 0\n" \
> +                        "            j == %s" % j

The extra indent is not needed over there, and the error message could
benefit from clarification.

>              if i is None: # default
>                  return type(self)(self._val >> j)
>              i = int(i)
> +            if i < 0:
> +                i = self._nrbits + i
>              if i <= j:
>                  raise ValueError, "intbv[i:j] requires i > j\n" \
>                        "            i, j == %s, %s" % (i, j)
> @@ -139,6 +143,8 @@
>              return res
>          else:
>              i = int(key)
> +            if i < 0:
> +                i = self._nrbits + i
>              res = bool((self._val >> i) & 0x1)
>              return res
>
> @@ -153,14 +159,18 @@
>                  j = 0
>              j = int(j)
>              if j < 0:
> -                raise ValueError, "intbv[i:j] = v requires j >= 0\n" \
> -                      "            j == %s" % j
> +                j = self._nrbits + j
> +                if j < 0:
> +                    raise ValueError, "intbv[i:j] = v requires j >= 0\n" \
> +                        "            j == %s" % j
>              if i is None: # default
>                  q = self._val % (1L << j)
>                  self._val = val * (1L << j) + q
>                  self._handleBounds()
>                  return
>              i = int(i)
> +            if i < 0:
> +                i = self._nrbits + i
>              if i <= j:
>                  raise ValueError, "intbv[i:j] = v requires i > j\n" \
>                        "            i, j, v == %s, %s, %s" % (i, j, val)
> @@ -174,6 +184,8 @@
>              self._handleBounds()
>          else:
>              i = int(key)
> +            if i < 0:
> +                i = self._nrbits + i
>              if val == 1:
>                  self._val |= (1L << i)
>              elif val == 0:
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

[myhdl-list] [PATCH 2 of 2 V3] toVHDL: add support for negative indexes and slice limits

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

# HG changeset patch
# User Angel Ezquerra <ang...@gm...>
# Date 1350086923 -7200
# Branch 0.8-dev
# Node ID 2ec0657ef6dbb262b3fc5fed0f9d4f30f82f528b
# Parent  c641c1ed333d6d03d9cee4a63df5111fe98574c8
toVHDL: add support for negative indexes and slice limits

This patch tries to detect negative indexes and slice limits and converts them
into indexes or limits relative to the highest bit position on the corresponding
bit vector (with -1 corresponding to the highest bit).

This is similar to what Python does with negative indexes for regular lists.

Two types of "negative indexes" are supported with this patch:

- Explicit negative numbers (e.g. -1, -3, etc)
- Explicit negative unary operator surrounding any other operation
(e.g. -(2 * 3))

Other cases in which the index may be negative are not detected. Despite this
limitation I think that this functionality can be quite useful.

As an example, the following simple test case converts fine with this patch:

~~~
#!/usr/env python
from myhdl import *

def test_module(rst, clk):
    '''This block generates the radio frame synchronization signal'''
    s_output = Signal(intbv(0)[16:])
    s_input = Signal(intbv(0)[16:])

    @always(clk.posedge, rst.posedge)
    def p_process():
        if rst == 1:
            s_input[-1] = 1
            s_input[-(3*2)] = 1
            s_output.next[-2] = s_input[-3]
            s_input[-1:-3] = 1
            s_input[-8:-14] = 1
        else:
            pass


    return instances()

clk, rst = [Signal(bool()) for n in range(2)]

if __name__ == '__main__':
    sync_inst = toVHDL(test_module3, rst, clk)
~~~

* ISSUES:

Mixing negative and positive limits on a single slice does not work fine. The
conversion side works ok, but the slice size inference is wrong.

diff --git a/myhdl/conversion/_toVHDL.py b/myhdl/conversion/_toVHDL.py
--- a/myhdl/conversion/_toVHDL.py
+++ b/myhdl/conversion/_toVHDL.py
@@ -1241,6 +1241,15 @@
         else:
             self.accessIndex(node)
 
+    def _isnegativeindex(self, astvalue):
+        if isinstance(astvalue, ast.Num):
+            if astvalue.value < 0:
+                return True
+        elif isinstance(astvalue, ast.UnaryOp):
+            if isinstance(astvalue.op, ast.USub):
+                return True
+        return False
+
     def accessSlice(self, node):
         if isinstance(node.value, ast.Call) and \
            node.value.func.obj in (intbv, modbv) and \
@@ -1278,11 +1287,17 @@
         if lower is None:
             self.write("%s" % node.obj._nrbits)
         else:
+            if self._isnegativeindex(lower):
+                # convert negative indexes into indexes from the MSB
+                self.write('%d + ' % node.value.obj._nrbits)
             self.visit(lower)
         self.write("-1 downto ")
         if upper is None:
             self.write("0")
         else:
+            if self._isnegativeindex(upper):
+                # convert negative indexes into indexes from the MSB
+                self.write('%d + ' % node.value.obj._nrbits)
             self.visit(upper)
         self.write(")")
         self.write(suf)
@@ -1293,6 +1308,11 @@
         self.visit(node.value)
         self.write("(")
         #assert len(node.subs) == 1
+        
+        if self._isnegativeindex(node.slice.value):
+            # convert negative indexes into indexes from the MSB
+            self.write('%d + ' % node.value.obj._nrbits)
+
         self.visit(node.slice.value)
         self.write(")")
         self.write(suf)

[myhdl-list] [PATCH 1 of 2 V3] intbv: add support for negative indexes and slice limits

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

# HG changeset patch
# User Angel Ezquerra <ang...@gm...>
# Date 1350077846 -7200
# Branch 0.8-dev
# Node ID c641c1ed333d6d03d9cee4a63df5111fe98574c8
# Parent  6f6571dbd495f197531f0406763ff10e4ce3b3ee
intbv: add support for negative indexes and slice limits

Negative indexes are supported on regular python lists. They are very useful
when you want to refer to a position from the end of the list. This same concept
can be applied to intbv indexes and slices. Supporting negative indexes reduces
the need to use the len() function to calculate a position from the MSB of the
intbv.

Note that converting negative indexes is not supported yet.

diff --git a/myhdl/_intbv.py b/myhdl/_intbv.py
--- a/myhdl/_intbv.py
+++ b/myhdl/_intbv.py
@@ -127,11 +127,15 @@
                 j = 0
             j = int(j)
             if j < 0:
-                raise ValueError, "intbv[i:j] requires j >= 0\n" \
-                      "            j == %s" % j
+                j = self._nrbits + j
+                if j < 0:
+                    raise ValueError, "intbv[i:j] requires j >= 0\n" \
+                        "            j == %s" % j
             if i is None: # default
                 return type(self)(self._val >> j)
             i = int(i)
+            if i < 0:
+                i = self._nrbits + i
             if i <= j:
                 raise ValueError, "intbv[i:j] requires i > j\n" \
                       "            i, j == %s, %s" % (i, j)
@@ -139,6 +143,8 @@
             return res
         else:
             i = int(key)
+            if i < 0:
+                i = self._nrbits + i
             res = bool((self._val >> i) & 0x1)
             return res
 
@@ -153,14 +159,18 @@
                 j = 0
             j = int(j)
             if j < 0:
-                raise ValueError, "intbv[i:j] = v requires j >= 0\n" \
-                      "            j == %s" % j
+                j = self._nrbits + j
+                if j < 0:
+                    raise ValueError, "intbv[i:j] = v requires j >= 0\n" \
+                        "            j == %s" % j
             if i is None: # default
                 q = self._val % (1L << j)
                 self._val = val * (1L << j) + q
                 self._handleBounds()
                 return
             i = int(i)
+            if i < 0:
+                i = self._nrbits + i
             if i <= j:
                 raise ValueError, "intbv[i:j] = v requires i > j\n" \
                       "            i, j, v == %s, %s, %s" % (i, j, val)
@@ -174,6 +184,8 @@
             self._handleBounds()
         else:
             i = int(key)
+            if i < 0:
+                i = self._nrbits + i
             if val == 1:
                 self._val |= (1L << i)
             elif val == 0:

[myhdl-list] [PATCH 0 of 2 V3] Add support for negative indexes _and_ slice limits

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

This third version of this patch series adds support for converting slices with negative limits.

The only limitation (other than the ones that also apply for indexes) is that you cannot mix positive and negative limits on the same slice.

That is, this will convert fine:

    s_my_signal[-1:-4]

But this will not work right:

    s_my_signal[-1:3]

This is because the size inference does not work right in this last case.

[myhdl-list] [PATCH 2 of 2 V2] toVHDL: add support for negative indexes

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

# HG changeset patch
# User Angel Ezquerra <ang...@gm...>
# Date 1350086923 -7200
# Branch 0.8-dev
# Node ID b8fa9fcfe7f2f4712c64b98da346191f57fef193
# Parent  c641c1ed333d6d03d9cee4a63df5111fe98574c8
toVHDL: add support for negative indexes

This patch tries to detect negative indexes and converts them into indexes
relative to the highest bit position (with -1 corresponding to the highest bit).

This is similar to what Python does with negative indexes for regular lists.

Two types of "negative indexes" are supported with this patch:

- Explicit negative numbers (e.g. -1, -3, etc)
- Explicit negative unary operator surrounding any other operation
(e.g. -(2 * 3))

Other cases in which the index may be negative are not detected. Negative
indexes are not supported for slices either (yet), just for simple one bit
index accesses. Despite these limitations I think that this functionality can be
quite useful.

As an example, the following simple test case converts fine with this patch:

~~~
#!/usr/env python
from myhdl import *

def test_module(rst, clk):
    '''This block generates the radio frame synchronization signal'''
    s_output = Signal(intbv(0)[16:])
    s_input = Signal(intbv(0)[16:])

    @always(clk.posedge, rst.posedge)
    def p_process():
        if rst == 1:
            s_input[-1] = 1
            s_input[-(3*2)] = 1
            s_output.next[-2] = s_input[-3]
        else:
            pass


    return instances()

clk, rst = [Signal(bool()) for n in range(2)]

if __name__ == '__main__':
    sync_inst = toVHDL(test_module3, rst, clk)
~~~

diff --git a/myhdl/conversion/_toVHDL.py b/myhdl/conversion/_toVHDL.py
--- a/myhdl/conversion/_toVHDL.py
+++ b/myhdl/conversion/_toVHDL.py
@@ -1293,6 +1293,19 @@
         self.visit(node.value)
         self.write("(")
         #assert len(node.subs) == 1
+        
+        def isnegativeindex(astvalue):
+            if isinstance(astvalue, ast.Num):
+                if astvalue.value < 0:
+                    return True
+            elif isinstance(astvalue, ast.UnaryOp):
+                if isinstance(astvalue.op, ast.USub):
+                    return True
+            return False
+        if isnegativeindex(node.slice.value):
+            # convert negative indexes into indexes from the MSB
+            self.write('%d + ' % node.value.obj._nrbits)
+
         self.visit(node.slice.value)
         self.write(")")
         self.write(suf)

[myhdl-list] [PATCH 1 of 2 V2] intbv: add support for negative indexes and slice limits

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

# HG changeset patch
# User Angel Ezquerra <ang...@gm...>
# Date 1350077846 -7200
# Branch 0.8-dev
# Node ID c641c1ed333d6d03d9cee4a63df5111fe98574c8
# Parent  6f6571dbd495f197531f0406763ff10e4ce3b3ee
intbv: add support for negative indexes and slice limits

Negative indexes are supported on regular python lists. They are very useful
when you want to refer to a position from the end of the list. This same concept
can be applied to intbv indexes and slices. Supporting negative indexes reduces
the need to use the len() function to calculate a position from the MSB of the
intbv.

Note that converting negative indexes is not supported yet.

diff --git a/myhdl/_intbv.py b/myhdl/_intbv.py
--- a/myhdl/_intbv.py
+++ b/myhdl/_intbv.py
@@ -127,11 +127,15 @@
                 j = 0
             j = int(j)
             if j < 0:
-                raise ValueError, "intbv[i:j] requires j >= 0\n" \
-                      "            j == %s" % j
+                j = self._nrbits + j
+                if j < 0:
+                    raise ValueError, "intbv[i:j] requires j >= 0\n" \
+                        "            j == %s" % j
             if i is None: # default
                 return type(self)(self._val >> j)
             i = int(i)
+            if i < 0:
+                i = self._nrbits + i
             if i <= j:
                 raise ValueError, "intbv[i:j] requires i > j\n" \
                       "            i, j == %s, %s" % (i, j)
@@ -139,6 +143,8 @@
             return res
         else:
             i = int(key)
+            if i < 0:
+                i = self._nrbits + i
             res = bool((self._val >> i) & 0x1)
             return res
 
@@ -153,14 +159,18 @@
                 j = 0
             j = int(j)
             if j < 0:
-                raise ValueError, "intbv[i:j] = v requires j >= 0\n" \
-                      "            j == %s" % j
+                j = self._nrbits + j
+                if j < 0:
+                    raise ValueError, "intbv[i:j] = v requires j >= 0\n" \
+                        "            j == %s" % j
             if i is None: # default
                 q = self._val % (1L << j)
                 self._val = val * (1L << j) + q
                 self._handleBounds()
                 return
             i = int(i)
+            if i < 0:
+                i = self._nrbits + i
             if i <= j:
                 raise ValueError, "intbv[i:j] = v requires i > j\n" \
                       "            i, j, v == %s, %s, %s" % (i, j, val)
@@ -174,6 +184,8 @@
             self._handleBounds()
         else:
             i = int(key)
+            if i < 0:
+                i = self._nrbits + i
             if val == 1:
                 self._val |= (1L << i)
             elif val == 0:

[myhdl-list] [PATCH 0 of 2 V2] Add support for negative indexes

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

This is a second, cleaner and more complete version of this patch series.

The first patch has not changed compared to the previous version of this patch series. On the other hand, the second patch should work much better, and should
support both negative numbers as indexes and explicit negative operations through
the negative unary operation.

[myhdl-list] [PATCH 2 of 2 RFC] toVHDL: add support for negative indexes

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

# HG changeset patch
# User Angel Ezquerra <ang...@gm...>
# Date 1350086923 -7200
# Branch 0.8-dev
# Node ID 1a024c51a10d48b9de7e5d0d3886e3498c4dcfbb
# Parent  c641c1ed333d6d03d9cee4a63df5111fe98574c8
toVHDL: add support for negative indexes

This is _very_ rough.

This patch tries to detect negative indexes and converts them into indexes
relative to the highest bit position (with -1 corresponding to the highest bit).

This probably breaks all sorts of things since it does not check if the index
is an integer or not, and the way it updates the slice node is probably wrong
as well.

However, the following simple test case converts fine with this patch:
~~~
#!/usr/env python
from myhdl import *

def test_module(rst, clk):
    '''This block generates the radio frame synchronization signal'''
    s_output = Signal(intbv(0)[16:])
    s_input = Signal(intbv(0)[16:])

    @always(clk.posedge, rst.posedge)
    def p_process():
        if rst == 1:
            s_input[-1] = 1
            s_output.next = s_input
        else:
            pass


    return instances()

clk, rst = [Signal(bool()) for n in range(2)]

if __name__ == '__main__':
    sync_inst = toVHDL(test_module3, rst, clk)
~~~

diff --git a/myhdl/conversion/_toVHDL.py b/myhdl/conversion/_toVHDL.py
--- a/myhdl/conversion/_toVHDL.py
+++ b/myhdl/conversion/_toVHDL.py
@@ -1293,6 +1293,12 @@
         self.visit(node.value)
         self.write("(")
         #assert len(node.subs) == 1
+        if node.slice.value.value < 0:
+            # convert negative indexes into indexes from the MSB
+            newindex = node.value.obj._nrbits + node.slice.value.value
+            node.slice.value = newindex
+            node.slice.value.n = newindex
+            node.slice.value.value = newindex
         self.visit(node.slice.value)
         self.write(")")
         self.write(suf)

[myhdl-list] [PATCH 1 of 2 RFC] intbv: add support for negative indexes and slice limits

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

# HG changeset patch
# User Angel Ezquerra <ang...@gm...>
# Date 1350077846 -7200
# Branch 0.8-dev
# Node ID c641c1ed333d6d03d9cee4a63df5111fe98574c8
# Parent  6f6571dbd495f197531f0406763ff10e4ce3b3ee
intbv: add support for negative indexes and slice limits

Negative indexes are supported on regular python lists. They are very useful
when you want to refer to a position from the end of the list. This same concept
can be applied to intbv indexes and slices. Supporting negative indexes reduces
the need to use the len() function to calculate a position from the MSB of the
intbv.

Note that converting negative indexes is not supported yet.

diff --git a/myhdl/_intbv.py b/myhdl/_intbv.py
--- a/myhdl/_intbv.py
+++ b/myhdl/_intbv.py
@@ -127,11 +127,15 @@
                 j = 0
             j = int(j)
             if j < 0:
-                raise ValueError, "intbv[i:j] requires j >= 0\n" \
-                      "            j == %s" % j
+                j = self._nrbits + j
+                if j < 0:
+                    raise ValueError, "intbv[i:j] requires j >= 0\n" \
+                        "            j == %s" % j
             if i is None: # default
                 return type(self)(self._val >> j)
             i = int(i)
+            if i < 0:
+                i = self._nrbits + i
             if i <= j:
                 raise ValueError, "intbv[i:j] requires i > j\n" \
                       "            i, j == %s, %s" % (i, j)
@@ -139,6 +143,8 @@
             return res
         else:
             i = int(key)
+            if i < 0:
+                i = self._nrbits + i
             res = bool((self._val >> i) & 0x1)
             return res
 
@@ -153,14 +159,18 @@
                 j = 0
             j = int(j)
             if j < 0:
-                raise ValueError, "intbv[i:j] = v requires j >= 0\n" \
-                      "            j == %s" % j
+                j = self._nrbits + j
+                if j < 0:
+                    raise ValueError, "intbv[i:j] = v requires j >= 0\n" \
+                        "            j == %s" % j
             if i is None: # default
                 q = self._val % (1L << j)
                 self._val = val * (1L << j) + q
                 self._handleBounds()
                 return
             i = int(i)
+            if i < 0:
+                i = self._nrbits + i
             if i <= j:
                 raise ValueError, "intbv[i:j] = v requires i > j\n" \
                       "            i, j, v == %s, %s, %s" % (i, j, val)
@@ -174,6 +184,8 @@
             self._handleBounds()
         else:
             i = int(key)
+            if i < 0:
+                i = self._nrbits + i
             if val == 1:
                 self._val |= (1L << i)
             elif val == 0:

[myhdl-list] [PATCH 0 of 2 RFC] Add support for negative indexes

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

Python lists have a natural way to access list itemps from the end of the list, which is to use negative indexes. These patches add this functionality to MyHDL.

The first patch adds negative index and slice limit support to the intbv class. I think this first patch is probably right and not very controversial (although I might be totally wrong, since this is my first attempt at making a serious modification to MyHDL).

The second patch is _very_ rough and probably breaks lots of things. It adds support for negative indexes (not slices) to the VHDL convertor. I'd really appreaciate any help with improving this patch in particular.

Comments are welcome!

Re: [myhdl-list] Problems converting an integer assignment into VHDL

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

On 10/11/2012 1:52 PM, Norbo wrote:
>
>> Yes, it seems that using an intermediate variable to get the value of
>> s_my_signal.max works fine and is an easy work around.
>>
>> That being said, is this technique to set a signal to all '1' the one
>> you guys would use? Or is there a more idiomatic way?
>
> I actually never came across this in that way before. Thanks for pointing
> it out, so i didn't have to run into it again!.
> When i did something similar the configuration looked somehow like this:
>
>
>     def somefunc(clk,in,out,sss,BIT_WIDTH=8):
>       sig1=Signal(intbv(0)[BIT_WIDTH:])
>       @always(clk.posedge)
>       def readbla():
>          sig1.next=(2**BIT_WIDTH)-1
>
>
> well and the other possibilities would be:
>
>       sig1=Signal(intbv(0)[8:])
>       const_AllOne=(2**sig1._nrbits)-1
>       @always(clk.posedge)
>       def readbla():
>          sig1.next=const_AllOne
> 		
>
> or the allready discussed quite similar one:
>
>       sig1=Signal(intbv(0)[8:])
>       const_AllOne=sig1.max-1
>       @always(clk.posedge)
>       def readbla():
>          sig1.next=const_AllOne
>
>
> iam not able to produce any other usefull way for this right now.
> But i actually also would prefer the direct use of the "signal.max".
> This seems to be at least somehow realated:
> http://sourceforge.net/mailarchive/message.php?msg_id=29738279
> MEP would be the next step right?.
>
>
> greetings
> Norbo
>

For me, I have adopted more of the 'intbv' versus a 'bv'.
I don't use the intbv(0)[8:] as much but rather use
intbv(0, min=0, max=256).  And usually /256/ will be some
variable, parameter (named argument), etc.

     sig_in = intbv(0, min=0, max=MaxInput)
     ...
     # set to max value
     sig_in.next = MaxInput-1

For me using the /local variable/ isn't a work around :)
Looking through some of my examples I don't often explicitly
set to the max.  Jan's essay on Ints is worth a read if you
have not.

http://jandecaluwe.com/hdldesign/counting.html

Regards,
Chris

Re: [myhdl-list] Problems converting an integer assignment into VHDL

[Norbo <Nor...@gm...>]

> Yes, it seems that using an intermediate variable to get the value of
> s_my_signal.max works fine and is an easy work around.
>
> That being said, is this technique to set a signal to all '1' the one
> you guys would use? Or is there a more idiomatic way?

I actually never came across this in that way before. Thanks for pointing  
it out, so i didn't have to run into it again!.
When i did something similar the configuration looked somehow like this:


   def somefunc(clk,in,out,sss,BIT_WIDTH=8):
     sig1=Signal(intbv(0)[BIT_WIDTH:])
     @always(clk.posedge)
     def readbla():
        sig1.next=(2**BIT_WIDTH)-1


well and the other possibilities would be:

     sig1=Signal(intbv(0)[8:])
     const_AllOne=(2**sig1._nrbits)-1
     @always(clk.posedge)
     def readbla():
        sig1.next=const_AllOne
		

or the allready discussed quite similar one:

     sig1=Signal(intbv(0)[8:])
     const_AllOne=sig1.max-1
     @always(clk.posedge)
     def readbla():
        sig1.next=const_AllOne


iam not able to produce any other usefull way for this right now.
But i actually also would prefer the direct use of the "signal.max".
This seems to be at least somehow realated:
http://sourceforge.net/mailarchive/message.php?msg_id=29738279
MEP would be the next step right?.


greetings
Norbo

Re: [myhdl-list] Problems using signal slices and variables

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

On 10/11/2012 11:17 AM, Angel Ezquerra wrote:
> On Thu, Oct 11, 2012 at 5:45 PM, Christopher Felton
> <chr...@gm...> wrote:
>> On 10/11/2012 6:10 AM, Angel Ezquerra wrote:
>>> Hi,
>>>
>>> I'm playing around with concatenating and slicing signals in MyHDL.
>>> I'm having some trouble with slicing in particular.
>>>
>>> I am having a hard time predicting what MyHDL will do when the code is
>>> converted to VHDL, and sometimes what I get seems wrong (or at least
>>> it is not what I expected).
>>>
>>> In particular, I've got the following code (note that the code has no
>>> purpose other than testing how MyHDL works):
>>>
>>>       s_input = Signal(intbv(0)[59:])
>>>       s_output = Signal(intbv(0)[59:])
>>>       s_slice = s_input(15, 0) # Use a shadow signal
>>>
>>>       @always(clk.posedge, rst.posedge)
>>>       def p_process():
>>>           if rst == 1:
>>>               max_value = s_input.max - 1
>>>               s_input.next = max_value
>>>               var_test = s_input[15:0] # I expect var_test to be a
>>> variable of range 14 downto 0, i.e. size 15
>>>               s_output.next = concat(s_input[15:0], s_input[30:15],
>>> s_input) # Total size: 15 + 15 + 30 = 60
>>>               s_output.next = concat(s_slice, s_input[30:15], s_input)
>>> # Total size: 15 + 15 + 30 = 60
>>>               s_output.next = concat(var_test, s_input[30:15], s_input)
>>> # Total size: 15 + 15 + 30 = 60
>>>           else:
>>>               pass
>>>
>>
>> Not following your math for the last concat
>>
>>   >  s_output.next = concat(var_test, s_input[30:15], s_input)
>>
>>      var_test = 15 (14 downto 0)
>>      s_input[30:15] = 15 (29 downto 15 )
>>      s_input = 59 (58 downto 0)
>>
>> trying to concat 89.
>>
>> In [63]: s_input = Signal(intbv(0)[59:])
>>       ...: s_output = Signal(intbv(0)[59:])
>>       ...: var_test = s_input[15:0]
>>       ...: len(concat(var_test, s_input[30:15], s_input))
>>       ...:
>> Out[63]: 89
>>
>> .chris
>
> Sorry Chris,
>
> I made a typo on my example. s_input is 30 bits long, not 60, i.e.
>
> s_input = Signal(intbv(0)[30:])
>
> The problem is that var_test is 30 bits long rather than 15 as I expected.
>
> Cheers,
>
> Angel
>

These seems to be a low-priority bug.  It is not functionally
broken but not optimal.  The attached is a slightly more
complete version, with a testbench.

The sourceforge bug tracker has been setup for bug reporting
but I don't think it has been used much.  Not sure the best
method to keep track of issues like this.

Regards,
Chris

Re: [myhdl-list] [PATCH V2] toVHDL: add signal attribute support

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

 On Thu, Oct 11, 2012 at 6:46 PM, Angel Ezquerra
<ang...@gm...> wrote:
> # HG changeset patch
> # User Angel Ezquerra <ang...@gm...>
> # Date 1349884148 -7200
> # Branch 0.8-dev
> # Node ID 6f6571dbd495f197531f0406763ff10e4ce3b3ee
> # Parent  58ac2e97c7efbe7e3c9784b8ac25218daa056e40
> toVHDL: add signal attribute support


This second version of this patch fixes an issue with the generated
VHDL. There was a missing semicolon.

Additionally, this makes the order of the attributes in the output
VHDL stable by sorting them.

Cheers,

Angel

Re: [myhdl-list] Problems converting an integer assignment into VHDL

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

On Thu, Oct 11, 2012 at 4:52 PM, Christopher Felton
<chr...@gm...> wrote:
> <snip>
>>
>>
>> so it turns out that the converter doesn't recognise the "s_my_signal.max"
>> as an const integer, but instead as a signal.
>> This seems to be also the case for the simulator.
>> e.g:  In a combinatorical process this leads to a -> combinatorical loop
>> error, when there is actually none.
>>
>>
>>       sigTest=Signal(intbv(0)[4:])
>>       @always_comb
>>       def comb_setConst():
>>         sigTest.next=int(sigTest.max)-1
>>
>>
>
> Yes, in a generator an "buried" constant can't be used.
> The converter will not walk down the structure (list,
> dict, class, etc) to find the value.  On the right hand
> side the only valid types are for conversion:
>
>      int, long, intbv, bool

Does this include the result of calling a function that returns one of
these types?

> A Signal can also be on the right hand side as lot as
> the Signal contains one of the above types.
>
>
> Another method vs. converting to an int would be
>
>     Max = sigTest.max
>     @always_comb
>     def com_setConst():
>         sigTest.next = Max-1
>
>
> The error that occurred in simulation is slightly different.
> Because you could use the above in an @always decorator and
> in simulation it will work but it will not convert.  The
> in / out is to protect from infinite recursive delta cycles.
>
>     @always_comb
>     def hdl():
>          sigTest.next = not sigTest
>
> Regards,
> Chris

I understand that (currently?) MyHDL limits the usage of containers in
synthesizable code. However, in this case I was not trying to use a
custom container that I created myself. I was trying to use one of the
fields of one of the built-in MyHDL data types.

Technical issues aside, wouldn't it make sense for MyHDL to support
those? This was quite surprising to me...

Angel